Create AWS CloudFormation Templates with Visual Studio


AWS CloudFormation is a wonderful service for automating your AWS builds – my colleagues have done a number of detailed walk-throughs in other blog posts.

AWS also provides a toolkit for Visual Studio as an extension of the IDE.  To get started, configure the extension with your AWS IAM Access Key ID and Secret Key and you will be able to use the new AWS explorer pane to explore all AWS services such as VPC, EC2, RDS, etc.

By installing the toolkit, it also automatically installed the AWS .NET SDK which included libraries to develop apps using AWS services using .NET classes.  With the AWS SDK support on the .NET platform, building applications and infrastructure leveraging AWS services using .NET easier.


Create and deploy your CloudFormation template in Visual Studio

To create a new CloudFormation template in Visual Studio, you simply add a new project: select AWS — File — New — Project.  Navigate to Templates — AWS and select AWS CloudFormation Project.


Once the project is created, you will be presented with the goodness of Visual Studio including Intellisense!


To deploy the template, right click the template and select Deploy to AWS CloudFormation


Troubleshooting notes

I came across an error whenever I deployed a new AWS CloudFormation template created in Visual Studio (I am using Visual Studio 2012 Premium edition).  The error indicated a syntax error; and after validating my template – it is clear that it is not a formatting error.

Deploying the same template directly on the AWS console or via an AWS Powershell command (test-cfntemplate) rendered the same result:


Test-CFNTemplate : Template format error: JSON not well-formed. (line 1, column 2)
 At line:1 char:1
 + Test-CFNTemplate -TemplateURL " ...
 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo : InvalidOperation: (Amazon.PowerShe...NTemplateCmdlet:TestCFNTemplateCmdlet) [Test-CFNTem
 plate], InvalidOperationException
 + FullyQualifiedErrorId : Amazon.CloudFormation.AmazonCloudFormationException,Amazon.PowerShell.Cmdlets.CFN.TestCF

Finding the solution took some searching, until I found a post indicating that this is caused by the default encoding used by Visual Studio: UTF-8 with BOM (Byte-Order-Mark).  Changing the default to UTF-8 without BOM fixed the issue.  This can be changed by selecting File — Advanced Save Options in Visual Studio.


Automate your Cloud Operations Part 2: AWS CloudFormation

Stacking the AWS CloudFormation

Automate your Cloud Operations blog post Part 1 have given us the basic understanding on how to automate the AWS stack using CloudFormation.

This post will help the reader on how to layer the stack on top of the existing AWS CloudFormation stack using AWS CloudFormation instead of modifying the base template. AWS resources can be added into existing VPC using the outputs detailing the resources from the main VPC stack instead of having to modify the main template.

This will allow us to compartmentalize, separate out any components of AWS infrastructure and again versioning all different AWS infrastructure code for every components.

Note: The template I will use for this post for educational purposes only and may not be suitable for production workloads :).

Diagram below will help to illustrate the concept:


Bastion Stack

Previously (Part 1), we created the initial stack which provide us the base VPC. Next, we will  provision bastion stack which will create a bastion host on top of our base VPC. Below are the components of the bastion stack:

  • Create IAM user that can find out information about the stack and has permissions to create KeyPairs and actions related.
  • Create bastion host instance with the AWS Security Group enable SSH access via port 22
  • Use CloudFormation Init to install packages, create files and run commands on the bastion host instance also take the creds created for the IAM user and setup to be used by the scripts
  • Use the EC2 UserData to run the cfn-init command that actually does the above via a bash script
  • The condition handle: the completion of the instance is dependent on the scripts running properly, if the scripts fail, the CloudFormation stack will error out and fail

Below is the CloudFormation template to build the bastion stack:

Following are the high level steps to layer the bastion stack on top of the initial stack:

I put together the following video on how to use the template:

NAT Stack

It is important to design the VPC with security in mind. I recommend to design your Security Zone and network segregation, I have written a blog post regarding how to Secure Azure Network. This approach also can be impelemented on AWS environment using VPC, subnet and security groups. At the very minimum we will segregate the Private subnet and Public subnet on our VPC.

NAT instance will be added to our Initial VPC “public” subnets so that the future private instances can use the NAT instance for communication outside the Initial VPC. We will use exact same method like what we did on Bastion stack.

Diagram below will help to illustrate the concept:


The components of the NAT stack:

  • An Elastic IP address (EIP) for the NAT instance
  • A Security Group for the NAT instance: Allowing ingress traffic tcp, udp from port 0-65535 from internal subnet ; Allowing egress traffic tcp port 22, 80, 443, 9418 to any and egress traffic udp port 123 to Internet and egress traffic port 0-65535 to internal subnet
  • The NAT instance
  • A private route table
  • A private route using the NAT instance as the default route for all traffic

Following is the CloudFormation template to build the stack:

Similar like the previous steps on how to layer the stack:

Hopefully after reading the Part 1 and the Part 2 of my blog posts, the readers will gain some basic understanding on how to automate the AWS cloud operations using AWS CloudFormation.

Please contact Kloud Solutions if the readers need help with automating AWS production environment

Xamarin Plugins

Cross-platform NuGet Packages

Xamarin Plugins are a special kind of NuGet package that let you easily add cross-platform functionality to your apps. Using NuGet to distribute Plugins means that anyone can create them, and of course consume them. The platforms supported by Plugins include Android, iOS, iOS Unified (64bit), Windows Phone 8, Windows Phone 8.1 RT and Windows Store.

Plugins abstract common device functionality or expose cross-platform APIs via a single interface

Plugins are small, have few or no dependencies, and provide a simple mechanism for accessing a single device function or feature. The following list represents some of the features you would expect to find on modern mobile devices.

  • GPS
  • Network Access
  • Battery Status
  • Vibration
  • Camera / Media
  • App cache
  • Speech-to-text

The aim of a Plugin is to expose one such feature using a singleton object (via an Interface) that hides the platform specific implementation on all platforms.

This approach in synonymous with using Inversion of Control (IoC) or Dependency Injection (DI) to invoke platform specific code from a shared project or a Portable Class Library (PCL).

Plugins Aren’t Components

… but they can be by following the Component creation and publishing guidelines.

A Xamarin Component gives developers the opportunity to distribute cross-platform libraries together in one neat package. When you add a Component to your Xamarin mobile project the correct platform implementation is automatically installed. Components are deployed by Xamarin and must be officially approved.

Plugins vs. Components

  • Components are normally used to offer cross-platform functionality at the UI level
  • Components typically integrate deeply into each platform they target

The above differences usually result in Components with diverging API implementations on each platform. As a consequence the use of the API becomes tightly coupled to each platform. In addition, very few Components target all of iOS, Android and Windows. Plugins, on the other hand, strive for a true cross-platform offering through one common API.

Plugin Development & Deployment

Plugins can be created by anyone and are a third-party driven part of the Xamarin ecosystem. Plugins do not need to be reviewed or approved by Xamarin.

In order to build a Plugin you will need Visual Studio and a business license of Xamarin (use a fully featured 30 day trial if you’re new to Xamarin). If you want to create and support your Plugins but have no intention to build and distribute apps, then you can apply for a special free license of Xamarin.

Publishing will require a NuGet user account. Alternatively an organisation can create an internal repository to host their cross-platform Plugins privately. However, if you do intend to contribute back to the Xamarin Community then ensure you publish your Plugin under an Open Source (OSS) friendly license like MIT.


Many Plugins have already been published so definitely checkout the packages repository at just in case your Plugin idea has already been developed. Alternatively you can view the Plugins offered in the Xamarin Component store.

Cross-platform “App Version” plugin

It’s common in almost every app to show the current version. Each platform uses a different approach for storing and retrieving this information, so abstracting this simple feature with a Plugin makes sense.

Quick Setup

  • Check your NuGet Package Manager is up to date. Ensure minimum version 2.8.3
  • Download and Install the Xamarin Plugin Template for Visual Studio
  • Create a project using the new Plugin template. The name of the solution needs to be simple because it will used throughout the Plugin code structure as a prefix and suffix for classes and file names.


With all projects created and initialized the screen shot below shows what your solution structure should resemble. Each platform being targeted has a corresponding project, with two additional portable (PCL) projects needed to complete the Plugin architecture.


The project called Version.Plugin.Abstractions is where we need to define the common API Interface. If you expand this project’s file structure you will see that an empty Interface has already been created for you by the template. For this walkthtough our interface is called IVersion.

At a minimum this Plugin needs to return the app’s version as a string, so we’ll add a getter property to our API.

/// Interface for Version
public interface IVersion
    /// Current App Version
    string Version { get; }

That’s it. With our simple API defined we just need to create concrete implementations for each targeted platform. When the template created each platform specific project, it added an implementation class with the name of your Plugin as the prefix.

IVersion for iOS implementation

// ./Version.Plugin.iOS/VersionImplementation.cs
public class VersionImplementation : IVersion
    readonly NSString _buildKey;
    readonly NSString _versionKey;

    public VersionImplementation()
        _buildKey = new NSString("CFBundleVersion");
        _versionKey = new NSString("CFBundleShortVersionString");

    /// Returns the app version with build number appended
    public string Version
            var build = NSBundle.MainBundle.InfoDictionary.ValueForKey(_buildKey);
            var version = NSBundle.MainBundle.InfoDictionary.ValueForKey(_versionKey);
            return string.Format("{0}.{1}", version, build);

IVersion for Android implementation

// ./Version.Plugin.Android/VersionImplementation.cs
public class VersionImplementation : IVersion
    /// Returns the app version
    public string Version
        get { return GetPackageVersion(); }

    static string GetPackageVersion()
            return Application.Context.PackageManager.GetPackageInfo(
                Application.Context.PackageName, PackageInfoFlags.MetaData).VersionName;
            return string.Empty;

The other platform implementations can be found in the sample code along with apps for testing each one.

CrossVersion Class

Using the API is the same on each platform. Example,

var version = CrossVersion.Current.Version;

As you can see the name of the class that exposes the API has the Plugin name as a suffix. This is the standard naming convention for accessing all Xamarin Plugins. For example, a cross-platform Plugin for “battery status” would be accessed with a CrossBattery class.

The CrossVersion class is located in the PCL called Version.Plugin. You may have noticed this class file is also linked into all of the platform specific projects. This simple yet powerful class ensures the correct IVersion implementation is loaded at runtime because it’s compiled into each assembly.

public class CrossVersion
    static readonly Lazy Implementation = new Lazy(() =>
        #if PORTABLE
        new VersionImplementation(),

    public static IVersion Current
            var version = Implementation.Value;
            if (version == null)
                throw new NotImplementedException(
                    "Don't use CrossVersion from your PCL without first installing the NuGet package in your main project first.");
            return version;

NuGet Deployment


Download NuGet.exe and add it to your solution root folder. This executable will be used via the command prompt.


NuGet.exe needs a specifications file in order to package your assemblies correctly. Add a NuSpec file to the solution and fill in appropriate details. The Plugin template installed a new file type allowing you to add one with most of the details filled in.



Make sure you fill in these required fields,

  • id
  • version
  • title
  • owners
  • authors
  • license and project urls
  • descriptions


From a command prompt switch to the Plugin root folder. Set your NuGet account key, which can be found on your NuGet account profile page.

nuget setapikey xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Ensure your project configuration is in release mode and rebuild the solution. Then from the command prompt run the NuGet package command.

nuget pack Version.Plugin.nuspec

The output of this command is a NuPkg file with all of your Plugin assemblies packaged together.



Before releasing the package to the public you’ll need to test it throughly. The best way is to create a test app project and install the Plugin with the NuGet package manager. Via the package manager settings, add another source location for the package manager to search.


The source path will be the root folder of your Plugin.


Check the Plugin installs correctly and the implementation works as expected.



Once you’ve fully tested the Plugin package, use the command prompt and your account key to publish.

nuget push Xam.Plugin.Version. xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Amazon Web Services (AWS) networking: public IP address and subnet list

Originally posted on Lucian’s blog over at

Amazon Web Services (AWS) has many data centre’s in many continents and countries all over the world. AWS has two key grouping methods of these data centres: regions and availability zones.

It can be very handy to either reference the IP address or subnet of a particular service in say a proxy server to streamline connectivity. This is a good practice to avoid unnecessary latency via proxy authentication requests. Below is an output of Amazon Web Services IP address and subnet details split into the key categories as listed by AWS via thier publishing of information through the IP address JSON file available here.

Sidebar: Click here to read up more on regions and availability zones or click here or click here. Included in these references is also information about the DNS endpoints for services that are therefore IP address agnostic. Also, If you’d like more details about the JSON file click here.

Read More

Skype for Business External Authentication

Microsoft Lync/Skype for Business has revolutionised the way people can communicate and collaborate in the workplace. With light weight and portable form factors coming into their own, devices have enabled businesses to rethink their communication strategy. Lync not only enables users to communicate using great device form factors, but also from wherever they may be located. The sense of a roaming lync identity brings freedom to how people choose to collaborate and office spaces, desks and name tags mounted above them, seem like a necessity of the past. The enablement of remote connectivity across these devices is pivotal in a Lync deployment, but sometimes isn’t entirely understood. In some circumstances security is of high concern for all forms of connectivity that can be done over the public internet, but you wouldn’t want to go without it. To remove remote access for users would be crippling the UC strategy that you were trying to put in place.

When we think about Lync/SFB with external authentication we first must articulate that there’s more than one form of authentication a user can attempt and there is many device types they can attempt authentication with. Therefore it can also be said that there is more than one endpoint and port on the edge of the corporate network listening, waiting and proxying these forms of authentication. What we need to do is make sure that each case is in a controlled and known measure to best suit your deployment.

Question: “So Arran what is secure?”

Answer: “Well the security policy should govern what is and isn’t classified as secure for you.”

The common device(s) attempting authentication are:

  1. Lync Office Client
  2. Mobile/Tablet app
  3. Windows 8 Store App

With these authentication types:

  1. NTLM
  2. TLS-DSK
  3. Passive (ADFS)

We aren’t going to talk about Kerberos cause we are concerned with external logins.


NTLM is usually well understood as a simple challenge/response authentication but if we look at it in Lync it means that every time a web ticket expires the same challenge authentication must be presented. Usually to make this simple to the end-user we allow them to cache/save the password to the device for re-authentication on our behalf.




NTLM will generally be a big ‘NO’ straight away if these conversations have started with a security team, so let’s look at Transport Layer Security Derived Session Key (TLS-DSK) as a certificate based authentication. Every Lync Front End Server is issuing a Lync User Certificate upon initial successful authentication and once the certificate is saved, the stored AD Credentials aren’t needed for the validity of the certificate which can range from 8 hours to 365 days (your choice). A key point to make about TLS-DSK is that if I have multiple devices I will receive my certificate for each. I will then use my certificate on each device to authenticate to Lync as me. Additionally the certificate I have stored is only trusted by Lync, not my entire domain or ADFS and can’t be used across other application or services.


TLS-DSK allows us to move away from the simple challenge authentication and subsequent re-authentications all together.

TLS-DSK is great!

We can configure the Edge Pool to only accept TLS-DSK protocol and refuse to play nicely with NTLM from the internet:

Set-CsProxyConfiguration -Identity "" -UseCertificateForClientToProxyAuth $true -UseKerberosForClientToProxyAuth $False -UseNtlmForClientToProxyAuth $False


Validate your settings:

Get-CsProxyConfiguration -Identity "" | format-list UseKerberosForClientToProxyAuth, UseNtlmForClientToProxyAuth, UseCertifcateForClientToProxyAuth


By disabling NTLM on the Edge Pool registrar (shown in the diagram above with Green – Internal and Blue -External) we can then understand that a client has to have obtained a Lync certificate from the internal Front End Servers when on-premises and not provisioned through an Edge proxy. The certificate can NOT be issued from external locations due to the authentication process breaking when the client requests a web ticket to start the process on the Edge Server using NTLM or Kerboros. This is then protected via additional forms of on-premises security;

  • The individual has gotten physical access to a site location through a perimeter locked entrance
  • The individual has gotten network layer 2 connectivity with a device on a access switch
  • The individual has an approved domain joined computer to gain access to domain services on the appropriate VLAN
  • The individual has supplied correct credentials of a provisioned Lync user account.

Sounds like a job for Tom Cruise hanging from the roof if you ask me. The end result is a Lync user certificate in the user store of the trusted machine. We should now be happy for the user to go out in the world with this device knowing that themselves and the managed device are who we think.


What if you would NOT like Lync to do any authentication.

“I have a centralised authentication services called Active Directory Federation Services (ADFS) and I would like to use it with Lync”.

Lync can be integrated with ADFS as your Secure Token Service (STS) and also provide a second factor if needed. You can then leverage forms based authentication or smart cards. There are a few tricks to enabling Lync Server with passive authentication, first of all to enable passive we must disable all other forms of authentication. As this is a ‘big bang’ approach to effectively disable all other authentication protocols per pool make sure you plan and test appropriately.


Lync Mobile Clients

Lync is a free download in each of the mobile stores and we can’t control if a trusted or untrusted device downloads it. So for our external access of the Lync 2013 mobile client we must feel comfortable with the authentication, which comes in the 3 forms that are available;

  • NTLM
  • Lync Certificate
  • Passive

NTLM once again maybe too basic to meet our requirements and we need to look at what else is on offer. We could potentially limit this device to only allow certificates through the Front End register on the internal network again, but have a look over Brendan Carius blog about mobility sign in and we realize that practically this isn’t the best method for mobile devices roaming with Lync apps. If we don’t want to move the whole way to ADFS for remote authentication with the Lync app we can protect our users and devices via whipping the initial NTLM credentials from the devices disk and memory via PowerShell mobility in band provisioning policy;

Set-CsMobilityPolicy -AllowSaveCredentials <$true/$false>

We can also disable EWS requests which does simple NTLM requests to exchange inside the app also;

Set-CsMobilityPolicy - AllowExchangeConnectivity <$true/$false>

Where does the authentication happen?

When I stated that there is “more than one endpoint on the edge of the corporate network, waiting and proxying these forms of authentication” this is because clients behave differently. Lync Office Client directs its authentication requests to the Lync Edge servers with SIP over TLS, while all mobile device apps will use a reverse proxy that has a published URL rule as all its signalling traffic is SIP over HTTPS while on a 3G/4G data network. So there is more then one ingress point for authentication to monitor. The Edge Server is inspecting all packets, while a Reverse Proxy can inspect the HTTPS traffics as it’s also splitting the traffic from frontend to backend.

Lync External Auth Flow


Options are available to change the way Lync can authenticate to your network. A greater understanding of the authentication endpoints, protocols and flows will aid you in being on top of your environment and smoothly rolling out external devices that are secure and trusted.

Let’s Hack It: Securing data on the mobile, the what, why, and how

Our solution to secure the mobile app data

Our solution to secure the mobile app data. It uses open source libraries and took a very minimal effort to implement

Here is the presentation of tonight’s talk. It was great to see so many passionate developers and business people at Melbourne Mobile. I have embedded the slides below and I hope you find it useful.

Talk Summary

This presentation is basically a summary of what I have learned and the experience I have had going through my recent project. In trying to secure the users data on the mobile device, I have come to learn quite few common flaws in the security implementation, I have learned more reasons why you need to protect the data on your mobile app, and have come to know and use few useful open source projects. I share my experience from this project hoping that it would help you gain some insight and protect your mobile app data easily.

I said in the presentation that you could start securing the app data by a couple of lines of code and I do mean it. In fact, if you use SQLCipher, then you could do that by only changing one line of code :). I have put the links to all my reference and the libraries I have used at the end of the slides.

Let's Hack It Presentation

Let’s Hack It Presentation

Finally, just in case you do not like Prezi, here is the slides as a PDF file:
Let’s Hack It, the presentation as PDF

Announcing KeyChain.NET: a unified API for using KeyChain on many platforms

Storing and accessing private keys and passwords can be a tricky task. How far do you need to go to protect your (and the user’s) data? This is where KeyChain on iOS comes in handy. It allows you to store keys in a (arguably) secure database. This has seen great improvements since iOS 8 and iOS devices (since iPhone 5S) equipped with a special A7 chip designed particularly for holding your keys. More on iOS KeyChain can be found on Apple’s website here. Android, on the other side has its KeyStore, which also gives you some level of protection, but leaves a major part of the implementation to your (the developer). Details of Android KeyStore can be found on Android SDK here.

While working on recent projects, I found myself needing to have a unified way of accessing the KeyChain on both platforms. I implemented the generic library and it’s been working very well, so I thought it would be nice to share the love with the community, so here it comes :)

KeyChain.Net offers developers a unified, simple-to-use api for storing, accessing, and deleting keys from the keyChain (or KeyStore). It also offers further customisation capabilities based on what the platform supports. For instance, iOS KeyChain supports seamless sync (of your private keys) with other iOS devices using iCloud. This can be achieved using KeyChain.Net by turning ON the autoSyncToiCloud setting.

The package is open source and it is hosted on GitHub here. Currently, I am supporting Xamarin iOS and Xamarin Android. I might add Windows Phone depending on the feedback I get.

Keychain nuget package

Keychain nuget package

The library can be found on Nuget here. I have put some sample code on the file on GitHub, and you could also look at the unit tests for information on how to use it. Tests are also available on Github.

Feel free to fork the repo on github and use it in any way you like or simply pull the nuget package to your project and enjoy it :). I would appreciate all feedback and if you have any issues or feature requests then please log them on Github.

Reachability.Net: A unified API for reachability (network connectivity) on Xamarin Android and iOS

Do you need to check for an active internet connection in your mobile app? Don’t we all do it often and on many platforms (and for almost all apps)? I found myself implementing it on iOS and Android and then pulling my implementation to almost all the mobile apps that I write. This is not efficient, and can be done better, right? :)

As a result I have created a library called Reachabiliy.Net which can be found as a nuget package for everything related to network connectivity. The library is open source and is hosted on Github. Currently, the solution only supports Xamarin iOS and Xamarin Android. I might add Windows Phone support and .NET 4.5 depending on the feedback I get. You will find examples listed on the main repository page.

I have included some sample code in the Github repostiroy.

The library provides a unified API across all platforms. The implementation of the library is based on the Xamarin Recipe on iOS, which can be found Xamarin’s Recipe Site. This is a good implementation and well tested.

On Android, the Xamarin Android recipe, is not really great and is based on the examples from the Android SDK docs, but it only checks whether the device is capable of connecting to the internet (or to wifi) or not and does not indicate the current connection status.

Therefore, I combined the Xamarin Android recipe with another check for connectivity to ensure correct results. More details on Reachability on Android can be found on this StackOverflow discussion.

OK, that’s all for me and I hope you enjoy using the library. Feel free to log any issues or feature requests on Github and I would love to hear your feedback.

Automate your Cloud Operations Part 1: AWS CloudFormation


What is Operations?

In the IT world, Operations refers to a team or department within IT which is responsible for the running of a business’ IT systems and infrastructure.

So what kind of activities this team perform on day to day basis?

Building, modifying, provisioning, updating systems, software and infrastructure to keep them available, performing and secure which ensures that users can be as productive as possible.

When moving to public cloud platforms the areas of focus for Operations are:

  • Cost reduction: if we design it properly and apply good practices when managing it (scale down / switch off)
  • Smarter operation: Use of Automation and APIs
  • Agility: faster in provisioning infrastructure or environments by Automating the everything
  • Better Uptime: Plan for failover, and design effective DR solutions more cost effectively.

If Cloud is the new normal then Automation is the new normal.

For this blog post we will focus on automation using AWS CloudFormation. The template I will use for this post for educational purposes only and may not be suitable for production workloads :).

AWS CloudFormation

AWS CloudFormation provides developers and system administrators DevOps an easy way to create and manage a collection of related AWS resources, including provisioning and updating them in an orderly and predictable fashion. AWS provides various CloudFormation templates, snippets and reference implementations.

Let’s talk about versioning before diving deeper into CloudFormation. It is extremely important to version your AWS infrastructure in the same way as you version your software. Versioning will help you to track change within your infrastructure by identifying:

  • What changed?
  • Who changed it?
  • When was it changed?
  • Why was it changed?

You can tie this version to a service management or project delivery tools if you wish.

You should also put your templates into source control. Personally I am using Github to version my infrastructure code, but any system such as Team Foundation Server (TFS) will do.

AWS Infrastructure

The below diagram illustrates the basic AWS infrastructure we will build and automate for this blog post:


Initial Stack

Firstly we will create the initial stack. Below are the components for the initial stack:

  • A VPC with CIDR block of : 65,543 IPs
  • Three Public Subnets across 3 Availability Zones :,,
  • An Internet Gateway attached to the VPC to allow public Internet access. This is a routing construct for VPC and not an EC2 instance
  • Routes and Route tables for three public subnets so EC2 instances in those public subnets can communicate
  • Default Network ACLs to allow all communication inside of the VPC.

Below is the CloudFormation template to build the initial stack.

The template can be downloaded here:

I put together the following video on how to use the template:

Understanding a CloudFormation template

AWS CloudFormation is pretty neat and FREE. You only need to pay for the AWS resources provisioned by the CloudFormation template.

The next bit is understanding the Structure of the template. Typically CloudFormation template will have 5 sections:

  • Headers
  • Parameters
  • Mappings
  • Resources
  • Outputs

Headers: Example:

Parameters: Provision-time spec command-line options. Example:

Mappings: Conditionals Case Statements. Example:

Resources: All resources to be provisioned. Example:

Outputs: Example:

Note: Not all AWS Resources can be provisioned using AWS CloudFormation and it has the following limitations.

In Part 2 we will deep dive further on AWS CloudFormation and automating the EC2 including the configuration for NAT and Bastion Host instance.

Amazon Web Services vs Microsoft Azure service comparison cheat sheet

Originally posted on Lucian’s blog at

I’m a big fan of both Microsoft Azure and Amazon Web Services. The two clouds are redefining the way web, apps and everything on the internet is made accessible from enterprise to the average user. Both for my own benefit and for yours, here’s a detailed side by side comparison of services as well as features available in each cloud:

Cloud Service Microsoft Azure Amazon Web Services
Locations Azure Regions Global Infrastructure
  NA Availability Zones
Management Azure Portal Management Console
Azure Preview Portal NA
Powershell+Desired State Configuration Command Line Interface
Compute Services
Cloud Services Elastic Beanstalk
Virtual Machines Elastic Compute Cloud (EC2)
  Batch Auto Scaling
RemoteApp Work Spaces
Web and Mobile Web Apps NA

Mobile Services Mobile SDK
API Management CloudTrail
NA Cognito
NA Mobile Analytics
SQL Databases Relational Database Service (RDS)
DocumentDB Dynamo DB
  Redis Cache Redshift
Blob Storage Simple Storage Service (S3)
Table Storage Elastic Block Store (EBS)
Queues Simple Queue Service (SQS)
File Storage Elastic File System (EFS)
Storsimple Storage Gateway
Analytics + Big Data
HDInsight (Hadoop) Elastic MapReduce (EMR)
Stream Analytics Kinesis
Machine Learning Machine Learning
Data Orchestration Data Factory Data Pipeline
Media Services
Media Services Elastic Transcoder
  Visual Studio Online NA
  BizTalk Services Simple Email Service (SES)
  Backup (Recovery Services) Glacier
  CDN CloudFront
Automation Automation OpsWorks
  Scheduler CodeDeploy + CodePipeline
Service Bus Simple Workflow (SWF)
Search CloudSearch
Networking Virtual Network Virtual Private Cloud (VPC)
  ExpressRoute DirectConnect
  Traffic Manager Elastic Load Balancing
  NA Route 53 (DNS)
 Management Services Resource Manager Cloud Formation
NA Trusted Adviser
Identity and Access Management
Active Directory Directory Service
NA Identity and Access Management (IAM)
Marketplace Marketplace Marketplace
Container Support Docker VM Extensions EC2 Container Service
Compliance Trust Centre CloudHSM
Multi-factor Authentication Multi-Factor Authentication Multi-Factor Authentication
Monitoring Services Operational Insights Config
Application Insights CloudWatch
Event Hubs NA
Notification Hubs Simple Notification Service (SNS)
Key Vault Key Management Store
Government Government GovCloud
Other services Web Jobs Lambda
NA Service Catalog
Office 365 Exchange Online WorkMail
Office 365 Sharepoint Online WorkDocs

For me this comparison is an exercise to allow me to reference quickly what the major services and features are on each cloud platform. I hope you can use it for reference if you’re needing to quickly know the equivalent service from one platform or the other.

Originally posted on Lucian’s blog at

Thank you,