VPC ( Virtual Private Cloud) Configuration


This blog is Part 01 of a 02 part series related to custom VPC configurations

Part 01 discusses the following scenario

  • Creating a VPC with 02 subnets ( Public and Private )
  • Creating a bastion host server in the public subnet
  • Allowing the Bastion host to connect to the servers in the Private Subnet using RDP.

Part 02 will discuss the following

  • Configuring NAT Instances
  • Configuring VPC Peering
  • Configuring VPC flow Logs.

What is a VPC

VPC can be described as a logical Datacenter where AWS resources can be deployed.

The logical datacenter can be connected to your physical datacenter through VPN or direct connect. Details (https://blog.kloud.com.au/2014/04/10/quickly-connect-to-your-aws-vpc-via-vpn/)

This section deals with the following tasks.

  • Creating the VPC
  • Creating Subnets
  • Configuring Subnets for internet access

1 Creating the VPC

The following steps should be followed for configuring VPC. we can use the wizard to create a VPC but this document will focus on the detailed method where every configuration parameter is defined by the user.

Step 01.01 : Logon to the AWS console

Step 01.02 : Click on VPC

Step 01.03 : Select Your VPCs


Step 01.04 : Select Create VPC


Step 01.05 Enter the following details in the Create VPC option

  • Enter the details of the Name Tag
  • Enter the CIDR Block. keep in mind that the block size cannot be greater that /16.

Step 01.06: Click on Yes,Create


We have now created a VPC. The following resources are also created automatically

  • Routing table for the VPC
  • Default VPC Security Group
  • Network ACL for the VPC

Default Routing Table ( Route Table Id = rtb-ab1cc9d3)

Check the Routing table below for the VPC. If you check the routes of the route table, you see the following

  • Destination :
  • target : Local
  • Status: Active
  • Propagated: No


This route ensures that all the subnets in the VPC are able to connect with each other. All the subnets created in the VPC are assigned to the default route table therefore its best practice not to change the default route table. For any route modification, a new route table can be created and assigned to subnets specifically.

Default Network Access Control List ( NACL id= acl-ded45ca7)

Mentioned below is the snapshot of the default NACL created when the VPC was created.


Default security group for the VPC ( Group id = sg-5c088122)

Mentioned below is the snapshot of the default Security Group created when the VPC was created.


Now we need to create Subnets. Keeping in mind that the considered scenario needs 02 subnets ( 01 Private and 01 Public ).1.

2 Creating Subnets

Step 02.01 : Go to the VPC Dashboard and select Subnets


Step 02.02 : Click on Create Subnet


Step 02.03: Enter the following details in the Create Subnet window

  • Name Tag: Subnet IPv4 CIDR Block ) – “Availability Zone” = – us-east-1a
  • VPC : Select the newly created VPC = vpc-cd54beb4 | MyVPC
  • Availability Zone: us-east-1a
  • IPv4 CIDR Block :

Step 02.04: Click on Yes,Create


Now we have created subnet

We will use the same steps to create another subnet. in availability zone us-east-1b

  • Name Tag: Subnet IPv4 CIDR Block ) – “Availability Zone” = – us-east-1b
  • VPC : Select the newly created VPC = vpc-cd54beb4 | MyVPC
  • Availability Zone: us-east-1b
  • IPv4 CIDR Block :


3 Configuring subnets

Now that we have 02 subnets and we need to configure the as the public subnet and as the private subnets. The following tasks need to be performed for the activity

  • Internet Gateway creation and configuration
  • Route table Creation and configuration
  • Auto Assign Public IP Configuration.

3.1 Internet gateway Creation and Configuration ( IGW Config )

Internet gateways as the name suggest provide access to the internet. They are assigned to VPC and routing table is configured to direct all internet based traffic to the internet gateway.

Mentioned below are the steps for creating and configuring the internet gateway.

Step 03.01.01 : Select Internet Gateways  from the VPC dashboard and click on Create Internet Gateway


Step 03.01.02 : Enter the name tag and click on Yes,Create


The internet gateways is created but not attached to any VPC.( internet gateway Id = igw-90c467f6)

Step 03.01.03: Select the Internet Gateway and click on Attach to VPC


Step 03.01.04 : Select your VPC and click on Yes,Attach


We have now attached the Internet Gateway to the VPC. Now we need to configure the route tables for internet access.

3.2 Route Table creation and Configuration ( RTBL Config)

A default route table ( with id rtb-ab1cc9d3) was created when the VPC was created. Its best practice to create a separate route table to internet access.

Step 03.02.01 : Click on the Route Table section in the VPC Dashboard and click Create Route table


Step 03.02.02: Enter the following details in the Create Route Table window and click on Yes,Create

  • Name tag: Relevant Name = InternetAccessRoutetbl
  • VPC : Your VPC = vpc-cd54b3b4 | MyVPC


Step 03.02.03 : Select a newly created Route table( Route Table Id = rtb-3b78ad43 | InternetAccessRouteTbl) and Click Routes and then Edit


Step 03.02.04: Click on Add Another Route


Step 03.02.05 : Enter the following values in the route and click on Save

  • Destination:
  • Target : Your Internet Gateway ID  = igw-90c467f6 ( in my case )


Route table needs subnet associations. The subnets which we want to make Public should be associated with the route table. In our case, we would associate Subnet to the route table.

Step 03.02.06: Click on Subnet Associations


You should be able to see the message “You do not have any subnet associations”

Step 03.02.07: Click on Edit

24.GIFStep 03.02.08: Select the subnet you want to configure as a Public Subnet. In our case and Click on Save


03.03 Auto Assign Public IP Configuration

Both the subnets created ( and will not assign public IP addresses to the instances deployed in them as per their default configuration.

We need to configure the public subnet ( ) to provide Public IPs automatically.

Step 03.03.01: Go to the Subnets section in the VPC dashboard.

Step 03.03.02: Select the Public Subnet

Step 03.03.03: Click on Subnet Actions

Step 03.03.04: Select Modify auto-assign IP Settings


Step 03.03.05: Check the Enable Auto-assign Public IPv4 Addresses  in the  Modify Auto-Assign IP Settings Window and click on Save


After this configuration, any EC2 instance deployed in the subnet will be assigned a public IP.

4 Security

security group acts as a virtual firewall that controls the traffic for one or more instances. When you launch an instance, you associate one or more security groups with the instance. You add rules to each security group that allow traffic to or from its associated instances. You can modify the rules for a security group at any time; the new rules are automatically applied to all instances that are associated with the security group. When we decide whether to allow traffic to reach an instance, we evaluate all the rules from all the security groups that are associated with the instance.

We will create 02 security groups,

  • Public-Private ( Will contains access rules from Public Subnet to Private Subnet )
  • Internet-Public ( will contains the ports allowed from the internet to the Public Subnet )

Step 4.1  : Click on Security Groups in the Network and Security section

Step 4.2 : Click on Create Security Group


Step 4.3 : Enter the following details on the Create Security group Window and click on Create

  • Security Group Name : Public-Private
  • Description : Rules between Private subnet and Public subnets
  • VPC : Select the VPC we created in the exercise.
  • Click on Add Rules to Add the following rules
    • Type = RDP , Protocol = TCP , POrt Range = 3389 , Source = Custom :
    • Type = All ICMP – IPV4, Protocol = ICMP , Port Range = 0 – 65535 , Source = Custom,


Step 4.4 : Enter the following details on the Create Security group Window and click on Create

  • Security Group Name : Public-Internet
  • Description : Rules between Public and the internet
  • VPC : Select the VPC we created in the exercise.
  • Click on Add Rules to Add the following rules
    • Type = RDP , Protocol = TCP , POrt Range = 3389 , Source =Anywhere
    • Type = All ICMP – IPV4, Protocol = ICMP , Port Range = 0 – 65535 , Source = Anywhere


4 EC2 installation

Now we will deploy 02 EC2 instances . One EC2 Instances Named PrivateInstance in the subnet and one instance named PublicInstance in the subnet.

Public Instance Configuration :

  • Instance Name : Public Instance
  • Network : MyVPC
  • Subnet :
  • Auto-Assign Public ip : Use subnet setting ( enabled )
  • Security Group : Public-Internet security group
  • IAM Role : As per requirement

Private Instance Configuration :

  • Instance Name : Private Instance
  • Network : MyVPC
  • Subnet :
  • Auto-Assign Public ip : Use subnet setting ( disabled)
  • Security Group : Public-Private security group
  • IAM Role : As per requirement

Once the deployment of the EC2 instance is complete, you can connect to the PublicInstance through RDP and from there connect further to the Private instances.

Patching EC2 through SSM


Why Patch Manager?

AWS SSM Patch Manager is an automated tool that helps you simplify your operating system patching process, including selecting the patches you want to deploy, the timing for patch roll-outs, controlling instance reboots, and many other tasks. You can define auto-approval rules for patches with an added ability to black-list or white-list specific patches, control how the patches are deployed on the target instances (e.g. stop services before applying the patch), and schedule the automatic roll out through maintenance windows.

These capabilities help you automate your patch maintenance process to save you time and reduce the risk of non-compliance. All capabilities of EC2 Systems Manager, including Patch Manager, are available free of charge so you only pay for the resources you manage.

The article can be used to configure patching for instances hosted in AWS Platform.

You will need to have the necessary pre-requisite knowledge regarding, EC2, and IAM section of the AWS. If so then please read on.

The configuration has three major sections

  • EC2 instance configuration for patching
  • Default Patching Baseline Configuration
  • Maintenance Window configuration.

1  Instance Configuration

We will start with the First section which is configuring the Instances to be patched. This requires the following tasks.

  1. Create Amazon EC2 Role for patching with two policies attached
    • AmazonEC2RoleForSSM
    • AmazonSSMFullAccess
  2. Assign Roles to the EC2 Instances
  3. Configure Tags to ensure patching in groups.

Important: The Machines to be patched should be able to contact Windows Update Services.  Mentioned below article contains the URLS which should be accessible for proper patch management.


Mentioned below are the detailed steps for the creation of an IAM role for Instances to be Patched using Patch Manager.

Step 1: Select IAM —–> Roles and Click on Create New Role


Step 2: Select Role Type —-> Amazon EC2


Step 3: Under Attach Policy Select the following and Click Next

  • AmazonEC2RoleForSSM
  • AmazonSSMFullAccess


Step 4: Enter the Role Name and Select Create Role (At the bottom of the page)


Now you have gone through the first step in your patch management journey.

Instances should be configured to use the above created role to ensure proper patch management. (or any roles which has AmazonEC2RoleforSSM and AmazonSSMFullAccess policies attached to it.)


We need to group our AWS hosted servers in groups cause no one with the right frame of mind wants to patch all the servers in one go.

To accomplish that we need to use Patch Groups (explained later).

For example:

We can configure Patch manager to Patch EC2 instances with Patch Group Tag = Group01 on Wednesday and EC2 instances with Patch Group Tag = PatchGroup02 on Friday.

To utilize patch groups, all EC2 instances should be tagged to support cumulative patch management based on Patch Groups.

Congratulations, you have completed the first section of the configuration. Keep following just two to go.

Default Patch Baseline configuration.

Patches are categorized using the following attributes :

  • Product Type: like Windows version etc.
  • Classification: CriticalUpdates, SecurityUpdates, SevicePacks, UpdateRollUps
  • Severity: Critical,Important,Low etc.

Patches are prioritized based on the above factors.

A Patch baseline can be used to configure the following using rules

  • Products to be included in Patching
  • Classification of Patches
  • Severity of Patches
  • Auto Approval Delay: Time to wait (Days) before automatic approval)

Patch Baseline is configured as follows.

Step 01: Select EC2 —> Select Patch Baselines (under the Systems Manager Services Section)

Step 02: Click on Create Patch Baseline


Step 03: Fill in the details of the baseline and click on Create


Go to Patch Baseline and make the newly created baseline as your default.


At this point, the instances to be patched are configured and we have also configured the patch policies. The next section we provide AWS the when (Date and Time) and what (task) of the patching cycle.

Maintenance Windows Configuration

As the name specifies, Maintenance Windows give us the option to Run Tasks on EC2 Instances on a specified schedule.

What we wish to accomplish with Maintenance Windows is to Run a Command (Apply-AWSPatchBaseline), but on a given schedule and on a subset of our servers. This is where all the above configurations gel together to make patching work.

Configuring Maintenance windows consist of the following tasks.

  • IAM role for Maintenance Windows
  • Creating the Maintenance Window itself
  • Registering Targets (Selecting servers for the activity)
  • Registering Tasks (Selecting tasks to be executed)

Mentioned below are the detailed steps for configuring all the above.

Step 01: Create a Role with the following policy attached

  • AmazonSSMMaintenanceWindowRole


Step 02: Enter the Role Name and Role Description


Step 03: Click on Role and copy the Role ARN

Step 04: Click on Edit Trust Relationships


Step 05: Add the following values under the Principal section of the JSON file as shown below

“Service”: “ssm.amazonaws.com”

Step 06: Click on Update Trust Relationships (on the bottom of the page)


At this point the IAM role for the maintenance window has been configured. The next section details the configuration of the maintenance window.

Step 01: Click on EC2 and select Maintenance Windows (under the Systems Manager Shared Resources section)


Step 02: Enter the details of the maintenance Windows and click on Create Maintenance Windows


At this point the Maintenance Window has been created. The next task is to Register Targets and Register Tasks for this maintenance window.

Step 01: Select the Maintenance Window created and click on Actions

Step 02: Select Register Targets


Step 03: Enter Owner Information and select the Tag Name and Tag Value

Step 04: Select Register Targets


At this point the targets for the maintenance window have been configured. This leaves us with the last activity in the configuration which is to register the tasks to be executed in the maintenance window.

Step 01: Select the Maintenance Window and Click on Actions

Step 02: Select Register Task


Step 03: Select AWS-ApplyPatchBaseline from the Document section


Step 04: Click on Registered targets and select the instances based on the Patch Group Tag

Step 05: Select Operation SCAN or Install based on the desired function (Keep in mind that an Install will result in a server restart).

Step 06: Select the MaintenanceWindowsRole

Step 07: Click on Register Tasks


After completing the configuration, the Registered Task will run on the Registered Targets based on the schedule specified in the Maintenance Window

The status of the Maintenance Window can be seen in the History section (as Shown below)


Hope this guide does get you through the initial patching configuration for your EC2 instances in Amazon.

Also in AWS the configuration can be done using CLI as well. Lets leave that for another blog for now.

Thanks for Reading.

Service Strategy – How do you become Instrumental?

There is a well-known concept developed by Ronald Coase around organisational boundaries being determined by transaction costs.

This concept stated that organisations are faced with three decisions.

To make, buy or rent.

In some scenarios, it makes sense for organisations to own and operate assets, or conduct activities in-house, however, at other times you could seek alternatives from the open market.

When seeking alternatives from the open markets the key factor can be the transaction cost.

The transaction cost it’s the overall costs of the economic exchange between the supplier and customer with the objective of ensuring that commitments are fulfilled.

In the context of Service Strategy, why is it important to understand this concept?

In the current shift towards cloud computing, the service transaction has now drastically been minimised in cost. It’s critical to understand this.

I often think of this like catching a fish, let me explain.

It takes time

There are costs that will be incurred when attempting to catch that fish.

In Service Strategy the costs can be calculated as the time taken to find and select qualified suppliers for goods or services that are required.

The right bait

Proven fishermen will always be asking the question “what bait works here”. So when putting together your service strategy make sure you know who you are considering in transacting with.  Knowing the track record of your provider is crucial, ask around you will save yourself a lot of time. I’m quite dumbfounded when I hear of customers ‘still’ transacting with suppliers that no longer provide any real value. More time spent transacting in the excuse basket than providing the outcome that the customer is after. Particularly when it comes to delivering services.

Certain bait attracts certain fish

If you are considering the leap to Cloud computing, find suppliers who are proven in this area. It’s not like the traditional on-premise managed service computing model. It has changed, go with providers who are working in this space and have been for a considerable period of time.  For example, they get what right sizing is and how crucial it could be to your cost model.

How many hooks and sinkers are you prepared to lose?

Governance is the costs of making sure the other party sticks to the terms of the contract and taking appropriate action if this turns out not to be the case.

Governance is fundamentally an intertwining of both leadership and management. Leadership in the sense of understanding the organisation’s vision, setting the strategy and bringing about alignment. Management in the sense of how we actually implement the strategy. Setting the budget, working out the resources required and so forth.

It’s crucial that your Cloud Enterprise Governance Framework has these qualities, for example, a policy is formally documented management expectations and intentions which can be used to direct decisions and ensure a consistent approach when implementing leadership’s strategy. In the cloud-climate where change is constant, you need to be in a position to respond with greater agility. Your governance framework has the ability to move between the two.

Once again do your homework. Find out what their Cloud Computing Service Model entails. Roadmaps, framework, fundamentally what approach they take. It’s crucial that they have this in place in order to succeed.

So what does it take to get hooked?

The actual answer to how you become instrumental is by clearly understanding your service transaction. The net effect will be brokering real value.

This, in turn, is likely to lead you to as prevailing conditions change, boundaries of the firm contract or expand with decisions such as make, buy, or rent.

Is Service Strategy your Everest?

Essentially strategy is separating what to do versus what not to do.

It brings about alignment to your organisation’s vision.

In this blog, I will endeavour to cover why having a service management strategy is critical for your organisation and point you towards well-known principles that will help you scale it.

You could think of this like climbing a mountain.

It starts with your perspective.

Perspective – outlines your vision and direction.

What does Everest look like? What do you see?

In the context of service strategy, it’s how you see yourself in the market. How you differentiate yourself from the providers you engage. At Kloud we are relatively young when it comes to alternate service providers that have dominated the markets over the past, yet we have a sound vision, and that vision is the inevitable shift towards cloud computing. Having this perspective allows us to clearly understand what we are about as we continue to evolve our service strategy.

What route will you take to ascend Everest?

In the context of service strategy, it’s your position.

Position – describes the decision to adopt a well-defined stance. At Kloud we believe that from a service management perspective there is a new model (consumption-based service management) when it comes to delivering value. Have a read of a recent blog I published around this shift.


Your route will ultimately define the decisions you will continue to take amongst the many potential paths you will be presented to take.

You need a plan to make the ascent.

You can see the summit, you know the route you need to take but now it’s time to plan how your journey.

The Plan – describes the means of transitioning from ‘as is’ to ‘to be’. A plan might detail, ‘How do we offer high- value or low-cost services?’ Or, ‘How do we achieve and offer our specialised services?’ You need a plan that will detail how you will get there. It allows all involved to see what’s required to get you there.

The way you climb.

In the context of service strategy, it’s your pattern.

Pattern – describes a series of consistent decisions and actions over time.  Over a period of time, your climbing style will start to show. What do I mean? Well, are you risk adverse? Do you climb with or without a support ? In Service Strategy, this could be providing service with high availability or high value, this will soon develop into your pattern, what you consistently gravitate towards.

In summary requirements and conditions are ever changing. A service provider may begin with any one form and evolve to another.

As a service provider, you might begin with a perspective. The service provider might then decide to take on a position articulated through Company policies, capabilities and resources.

This position may then be achieved through the execution of a plan.

Once you have been able to achieve this, the service provider may maintain its position through a series of well-understood decisions and action over time: a pattern.

I encourage you to use all four Ps, Perspective, Position, Plan and Pattern. Move between all four as required, seeing the big picture while working through the details.


Exploring Cloud Adoption

At Kloud we get incredible opportunities to partner with global organisations.

Listening to and observing one of our established clients has inspired me to write about the change programme around Office 365 and how we can expand the approach.

The change management programme, in terms of adoption, is based on a user’s journey through the office 365 toolset. A sort of step by step approach incorporating exchange online and SharePoint online – building a workspace for each department which effectively will become the reference point in which you work from. In short, targeting adoption champions throughout particular business units and keeping them abreast of the Office 365 updates.

We have seen results through this approach but it’s here I want to drop a different thought into the equation.

It’s natural tendency to develop a well-trodden path, but what happens when you have a disparate group of individuals who don’t take this route?

Taking people on a well thought out journey could almost take the excitement out of the trip. Why not foster an environment that will allow individuals to explore the Office 365 toolset?

What do I mean? Office 365 is continuously evolving its services. Just look at the roadmap and you will see what I mean.

Think about the last trip you took. Did you perhaps decide to stop the car and explore the countryside? You could well have stepped off the beaten track and explored the unknown finding that place that no one told you about.

Rigorous change control programmes that try and control how people ,within the organisation , adopt the services could well stifle the opportunity that the Cloud is creating.

Here are some key thoughts when considering an explorative approach to adoption.

Pop-up Adoption

The pop-up store is a remarkable concept in today’s society. It is a fantastic way to introduce a new thought, concept or idea down the well-trodden route with an ability to create a short term experience that could prompt exploring. There is fantastic opportunity to create these pop-up adoption initiatives throughout the organisation to inspire alternate ways to being productive.

Your posture on Change Management

In cloud computing, we find that cloud suppliers have a wave of new features designed to change and enhance the productivity of the consumer. The consumer loves all the additional functionality that will come with the solution, however at most times does not understand what the full extent of the changes. Herein lies the challenge, how does the conventional IT department communicate the change, train up end users and ultimately manage change? We get ready to run all our time intensive checks so that people know exactly what is about to change, when and how it will change. Challenging, to say the least, but when you ramp this up, well to be specific multiply by a factor of a hundred.

It’s time-consuming and nearly impossible to manage in the current cloud climate.

Here is a thought that will take you to the extreme opposite.

Enable everything. Yes, that’s right, let the full power of Cloud permeate through your organisation. The more time you spend trying to control what gets released as opposed to what doesn’t, the more time you waste which can be better used to create more value. Enable it and let your early adopters benefit, explore, they could even coach the late bloomers, then let the remaining people go on a journey.


Use what you got to expose people to what they could adopt

Yammer is a great tool in the Office 365 toolset that will expose people to different opportunities in being productive. Exposing different toolsets to people causes them to explore what they don’t know.

The mobile phone will help

People have started to explore technology. The mobile age has stimulated this approach. The slogan “There is an app for that” could well be the tag line that has encouraged end users to explore the tools that are available to them.

The Adoption Map

Whenever one is navigating areas unknown we tend to develop visuals that will help us make sense of the space. The Adoption Map could be a great tool to visually show your people what is actually out there. Instead of being a mere passenger on the journey, they could help plot out their own coordinates. When people start learning for themselves it’s potentially the most powerful recipe for success.

This approach could alter the role of change managers to become change enablers. Instead of controlling change you are learning and innovating from it.

Adoption simple means to choose. We have a great opportunity to present them with as many services as possible from which to choose, you can potentially foster an environment that creates exploration. The ability to learn for themselves and ultimately to explore in the confounds of a boundary that is ever expanding.

Cloud Enterprise Governance

Organisational Strategies are currently being forged around SAAS, IAAS and PAAS in cloud computing.

What will the new Cloud Enterprise Governance framework look like?

Lack of Cloud Enterprise Governance can result in organisations not achieving strategically set directives as well as consumer loss of confidence.

This is challenging considering how fast cloud computing is currently being accelerated, at the same token, this also provides a fantastic opportunity to get it right.

Cloud computing is putting pressure on traditional governance ability to adapt and change.

It is critical that governance is addressed from a holistic point of view.

What does Governance mean?

Ensuring that policies and strategy are actually implemented, and correctly followed. Your ability to clearly define ownership, auditing, measuring, reporting and resolving any issues that are identified as a result thereof.

Some key thoughts to consider when putting your Cloud Enterprise framework together under a Cloud model.

Leading and Managing intertwined

This is where Governance gets interesting, sticking to the definition of Governance is fundamentally an intertwining of both leadership and management.

Leadership in the sense of understanding the organisation’s vision, setting the strategy and bringing about alignment.

Management in the sense of how we actually implement the strategy. Setting the budget, working out the resources required and so forth.

It’s crucial that your Cloud Enterprise Governance Framework has these qualities, for example, a policy is formally documented management expectations and intentions which can be used to direct decisions and ensure a consistent approach when implementing leadership’s strategy. In the cloud-climate where change is constant, you need to be in a position to respond with greater agility. It’s crucial that your governance framework has the ability to move between the two.

Your Evolvement (not involvement – that’s a given)

What are the new requirements that your Cloud model has outlined in its roadmap?

How you best position your organisation to maximise the offerings.

What has been launched? Hopefully, you are not caught out here, depending on your position on change management.

What’s currently being developed? What’s currently being rolled out? Important questions that need to be flushed out to ensure your evolution in cloud computing.

Cloud Enterprise Guiding Coalition

Experience at establishing a Cloud Enterprise Governance has shown that a carefully thought out group of individuals (Leaders and Managers) are critical in ensuring Cloud Service success.

A guiding coalition team does not have to be comprised solely of senior managers. A single champion cannot achieve success alone.

The end goal of establishing this team is not from a who has the power but more around experience, respect, versatility and trust. This team should be backed by an influential business or IT sponsor.

As the programme buy-in grows, and throughout the programme itself when more and more successes are achieved and benefits realised, this team should be increased to involve a wider range of people and functions.

The types of questions you need to be asking are, ‘Do we have the right people on board?’ and, if not, ‘Who should we have on board?’

Something to Remember


  • Lead and manage, intertwine the two at all levels.
  • Ensure you have a position of constant evolution.


  • Forsake building a Cloud Enterprise Governance framework.
  • Have clear markers on how you are assessing your operational performance, ensure that these indicators are accurately represented in the Cloud Enterprise Governance Coalition.

The Service Coin

We were recently invited by a customer to share on how we do managed services at Kloud, particularly around Microsoft Azure and Office 365.

During the conversation, I landed on an analogy that best articulated how we envision delivering service through the Cloud computing model.

I thought I would share that analogy.

Simply put service is a means of delivering value to customers, minus all the overhead of actually operating the service.

With that in mind let’s think about the service coin in terms of value in the economy called the cloud.

A service coin has three sides to it.

The first side of the coin can be known as the service management layer. It’s how the service will actually be delivered from a management perspective.

The framework that gets implemented, how we respond to demands, how we ensure availability, Incident Management, Change Management, Problem Management and various key processes that ensure services are being delivered.

The second side of the coin can be known as the operational layer. It’s how the service gets engineered.

We spend a lot of time at Kloud investing into this layer, instilling operational run books amongst other initiatives that will provide comprehensive steps on how to successfully run the service. They serve as an open book on how we engineer the service in the complexities of our customer’s environments.

At this layer, we will find;

Checklists, configuration documentation, patching cycles and so forth. It reads like a novel, well more of a technical manual to be precise. Our talented engineers love it.

Last but not least there is a third side of the coin, it’s actually the side on which it all rests, this can be known as the adoption layer. It’s where we ultimately take people on a journey on how to use the technology. I think it’s here that we find that a shift has taken place. People have started to explore technology. The Mobile age has stimulated this shift. The slogan “There is an app for that” could well be the tag line that has encouraged end users to explore the tools that are available to them.

Yes, some require hand holding but on the whole if we foster an adoption strategy that encourages people to explore what they have at their disposal we just might take productivity to a whole new level. Yes, we might have some other challenges, but these challenges are the one’s worth taking.

The adoption layer is potentially the most important layer in terms of service success, it’s what will introduce the value and actually introduce the coin into the organisations economy. Resulting in net productivity and the ultimate effect which is value.

The coin’s ultimate purpose is a medium for exchange. In the context of the service coin, it’s purpose is to ensure healthy exchange between the three sides.

One has to be prepared to spin the coin to get that perfect pattern.

Finally, the coin has an imprint; this is the part that signifies who the Coin belongs to. In our case, the Service Coin ultimately belongs to our customer. It’s their service, they entrust us to run the service, it’s of tremendous value to them. We get to hold it for the time that they allow us to.

Judging by the response from our client I think it resonated with what had always just been in his pocket. The Service Coin.

The art of managing a service

In the age of technology, it’s important to deliver value to customers in terms of outcomes. Service typifies what this means, providing value to the customer.

There is an art to managing a service, it’s here I want to focus the attention. “Art,” implies mastery of any sort of craft.  I love the picture this paints.  One could imply that managing a service is a mastering it, in turn mastering value.

Here’s a few pointers on how to do that.

Know thy customer

Relationship is key when it comes to managing a service. This might sound strange, how does managing a service (technological) fall into this category? Surely it’s all just binary? Either the service works or it doesn’t. Not necessarily, take the scenario where a service is in use and people don’t really use it. Relationship ensures you are listening to the people who utilize the service and understand if the value is in place. Having the ability to listen is crucial. Listeners have the ability to bounce their way to a positive outcome. Effectively an act of support, encouragement and growth which ultimately reflects value.


At Kloud we focus extensively on ensuring we have a healthy rhythm in place, it ensures we move faster, able to respond in a timely manner. It introduces agility onto our canvas.

Some examples of what we have at our heartbeat;

Daily Kuddle were we focus on what’s been happening, important Metrics and any of our customer’s challenges.

Weekly we take the time to improve what we do where we focus on news, numbers, customer and employee data, the one thing we personally each can do to improve our contribution.


This might seem odd in the context of this blog, it could even find its way under the rhythm but we need to call this out. The ability to discover events, make sense of them and determine the appropriate control action is critical to service management. Like an artist studies his canvas for its creativity expression, we study our systems to ensure its expression is of a healthy nature. It here we can build a visual of how we are progressing and touch it up if required.

Cost a new approach

Cost is an important factor when it comes to managing a service. Customers want to see value at this layer. Imagine the cost actually varying? Whereas a customer you see the cost decrease? At Kloud we have introduced consumption-based service management (to be fair, it’s not a new concept but a model that will potentially redefine the way services are being delivered). In this model the consumer pays for the value that you as the managed service provider will deliver on a consumption, rather than a fixed, basis.


Spending far to much time doing Post incident reviews as opposed to pre incident reviews. Governance is important to the way that we manage our services. We spend time ensuring we have a considerable and robust governance framework in place. This framework allows us to build on hindsight, stay relevant and anticipate what’s to come in the digital age.


This could be my all-time favourite.  I think of our team when this comes to mind.  Wikipedia describes passion as a very strong feeling about a person or thing. Passion is an intense emotion, a compelling enthusiasm or desire for something.  We care about the Cloud and the value that it will provide for the modern day organisation. It’s very essence will allow organisations to concentrate on their core business function therefore we passionately throw ourselves at our mission of the inevitable shift to the Cloud.

Something to Remember


  • Know thy customer, listen more than you talk.
  • Passion, care about your customer and the services you deliver.
  • Evaluate your cost, ensure you are competitive and relevant in today’s cost climate.


  • Forsake a healthy rhythm.
  • Ignore the events.

Accelerating Azure Multi Factor Authentication in Enterprise Organisation

At Kloud we get incredible opportunities to partner with organisations who are global leaders in their particular industry.

Recently we were asked to accelerate Microsoft’s Azure Multi factor authentication for Office 365 users in the cloud throughout an enterprise organisation.

This blog is not so much focused on the technical implementation (there is an incredible amount of technical documentation provided by Microsoft that covers this) but more around what we discovered whilst accelerating the technology throughout the organisation.

Implementing Microsoft multi-factor authentication for Office 365 users is relatively straight forward, it is actually quite easy from a technical point of view.

The technical steps as detailed by Microsoft;


Our approach was pieced into a few key building blocks.

Its post enablement that I want to take the time to focus on and I hope to stimulate a few thoughts around the areas that we spent the most time in the hope that it will help you successfully roll this out successfully to a large usage base. (thousands of people!)

We endeavoured to keep this relatively simple by focusing on the Standard Operating Environment and Communicating  around Azure Multi-Factor authentication.

Let us unpack these key points in a little more detail.

The Standard Operating Environment

With this particular enterprise organisation, they had a majority of their SOEs running an instance of Microsoft Office 2010.

The Office 2013 device apps support multi-factor authentication through the use of the Active Directory Authentication Library (ADAL).

Therefore a key task was to ensure all the office clients were able to support multi-factor authentication as outlined above.

As a result, a key dependency to accelerating Azure MFA was in having a reliable removal and installation package for Microsoft Office. e.g. automated the removal of Office 2010 and process for packaging any new Office 2013 plugins.  It’s important to factor this time into your deployment of Multi-Factor Authentication.

If you don’t have a package that removes and re-installs the correct version of Microsoft Office you will encounter a roadblock.

Under communicating the Multi-Factor Authentication transformation technology

I cannot stress how important the communication part actually is.

We decided on conducting  a couple wave of pilots over a short period of time. The benefit of this approach was to weed out any minor issues that might confuse the larger groups, taking a position of refining our learnings as we progress through the pilots in a healthy order.

We prioritised in the following groups;

  1. Technology group (Security and End-user Computing)
  2. Executive Team (Yes we did this early)
  3. Technology IT (the whole department in one go)
  4. We targeted two Business units (around 300 users combined)
  5. Bulk Azure Multi-Factor Authentication production rollout (all remaining Business units)

We noticed a few patterns with respect to communication, all very common as detailed as follows;

In the first group,

The Technology pilot we conducted a workshop, ensuring that they had all the relevant requirements beforehand  and stepped them through the enablement process. We find that they tend to stumble along initially and figure it out for themselves. Not a lot of noise is generated at this level and generally well received, which is fantastic bearing in mind that they are generally drivers around a more secure environment.

The second group,

The Executive Team are not overly concerned and generally welcome in the additional layer of security knowing the current climate around data loss and the publicity it can generate.  Its almost as if they are relieved it has finally arrived. They have an executive support team who are agile and ready to process any communication around the technology and how to successfully deploy.

In the third group,

The Technology department we find much more effort goes into communicating the technology, including workshops on the how and why, but some very visible senior individuals still behave in ways that are antithetical to the technology transformation. “Do I have to add this additional step to authenticate?” The net result is that cynicism among the people goes up, while belief in the communication goes down.  Its important to spend time at this layer (over communicate) to ensure they understand the importance of safeguarding the organisation’s data. I cannot stress how important the why is in this instance. It is at this level where having done the executive layer is crucial as they would have already seen the benefits of using multi-factor authentication and you would have the senior stakeholder actively engaged in the technology component.

Transformation is impossible unless tens, hundreds or thousands of people are willing to help, often to the point of making short-term sacrifices. “I know it’s a pain to click verify on the Azure Multi-Factor Authentication application but by doing so I am safeguarding my organisation’s data” They get this revelation by understanding why they are doing what they are doing, the very essence of communication.

Employees will not make sacrifices, even if they are unhappy with the status quo unless they believe that useful change is possible. Without credible communication, and lots of it, the hearts and minds of the team are never captured and you run the risk of another failed transformation project.

In more successful transformation pilots, we used all existing communication channels to broadcast the technology transformation. Our guiding principle was simple: Use whatever we can to communicate why Multi-factor authentication is critical to the organisation and how it will take place.

Perhaps even more important, most of the successful pilots of this change learned to “walk the talk.”  Communication comes in both words and actions. Nothing undermines change more than behaviour by important individuals that are inconsistent with their words.

Where we landed

The technology component is relatively straight forward the challenge lies in user adoption, spend most of your time in this space, over communicate  so people understand why you are making the leap forward! Your data will be all the safer for it.

Cloud and the rate of Change Management

At Kloud we get incredible opportunities to partner with organisations who are global leaders in their particular industry.

Listening to and observing one of our established clients inspired me to write about their approach to change management in the cloud around the SaaS model.

Let’s start by telling you a quick story about bubble wrap.

Bubble wrap has taken a very different journey to what it was originally intended for. It was meant to be used as wall paper. Who would of thought that to be the case?!

It turned out that at the time there was not a market for bubbled wallpaper and the product was slowly fading into oblivion had there not been innovative and outside-the-box thinking. Bubble wrap’s inventors approached a large technology company in the hope that it could be the packaging material for its fragile product – the result of which revolutionised the packaging industry and today bubble wrap is a household name for many reasons.

In cloud computing we find that cloud suppliers have a wave of new features designed to change and enhance the productivity of the consumer. The consumer loves all the additional functionality that will come with the solution, however at most times does not understand the full extent of the changes. Herein lies the challenge – how does the conventional IT department communicate the change, train up end users and ultimately manage change?

We get ready to run all our time intensive checks so that people know exactly what is about to change, when and how it will change which is challenging to say the least. However, when you ramp this up to cloud-speed it clearly becomes near impossible to manage.

Change can be likened to exercising your muscles. The more you train the stronger you get, and change management is no different – the more change you execute the better you will get at managing it.

Many organisations keep features turned off until they understand them. Like my client says “I think this is old school”.

The smartphone has been a contributor to educating people on the new way of handling change. It has helped gear people up to be more change ready so we should give the end user the credit that they deserve.

So what approach is my client taking?

Enable everything.

Yes, that’s right, let the full power of Cloud permeate through your organisation and recognise that the more time you spend trying to control what gets released as opposed to what doesn’t, the more time you waste which can be better used to create more value.

Enable features and let your early adopters benefit, then let the remaining people go on a journey. Sure, some might get it wrong and end up using the functionality incorrectly but this is likely to be the minority. Remember, most people don’t like change whether we like to admit it or not. As a result you need to spend listening to feedback and seeing how they interact with the technology.

Now let’s address the elephant in the room.

If we enable everything doesn’t it lead to chaos? Well let’s think this through by looking at the reverse. What would happen if we did not enable anything at all? Nothing. What does nothing lead to? Well, to be precise, nothing.

Think about when Henry Ford first rolled out the self-propelled vehicle which he named the Ford Quadricycle in an era where people struggled to look past horses. Did he ever dream that one day there would be electric cars? Probably not. Which is ironic considering he was introduced to Thomas Edison!

My point though? If you try and limit change you could very well be stifling progress. Imagine the lost opportunities?

Unlike bubble wrap which eventually will pop, Cloud services will continue to evolve and expand and so our way in handling change needs to evolve, adapt and change. Just maybe the only thing that has to pop is our traditional approach to change.