Category Archives: AWS

Building a Multi-Cloud Network for less than $1 an Hour – Aviatrix Kickstart

This is the post I had been meaning to write for ages. How do you leverage Infrastructure as Code to build a multi-cloud network? It turns out you don’t have to write the code yourself. This is the beauty of Aviatrix Kickstart.

For less than $1 an hour, I was able to build a multi-cloud transit network with 2 spoke VPCs in AWS, 2 spoke VNets in Azure, a transit VPC in AWS, a transit VNet in Azure, and a peered connection between the two. Oh, and also 2 EC2 test instances in AWS for various tests. All within an hour.

The quickest way to build this would have been to script it in Terraform. But with Kickstart, a containerized environment handles this for you. So you don’t need to have Terraform skills or write any code.

Kickstart is a Docker image that you can download from here. All you need to run it are:

  • Docker. You can do this either by installing Docker Desktop on your client PC (Windows or Mac) or running it on an AWS EC2 Linux 2 AMI.
  • An AWS account and optionally an Azure account. I built the entire environment in AWS and Azure Free Tier accounts.

Once you run docker run -it aviatrix/kickstart bash, the script walks you through the process and allows you to configure the region, names of the resources, and CIDRs of the Aviatrix Controller as well as the Multi-Cloud Network Architecture (MCNA) Transits. It then leverages Terraform to issue several Day-Zero activities. Aviatrix Kickstart makes it so easy that I was able to build the following architecture in less than an hour without writing a line of code.

Check out these resources for more details:

  • Guide to building the environment
  • 10-minute video of demo
  • Test cases to try out once you’ve built the environment

Why I Joined Aviatrix

Earlier this month I joined Aviatrix Systems as a Solutions Architect with a focus on growing the Aviatrix Certified Engineer (ACE) program. I had gone through a journey of 2 years of immersing myself in Public Cloud platforms from training sites, such as A Cloud Guru and Linux Academy. Here are some of my observations during that period which led to my decision to join Aviatrix:

  • Cloud Networking is radically different from on-premises networking. For example,
    • In the on-prem world, network architects designed in layers (Core, Aggregation/Access). The world of Public Cloud is flat in order to meet the pace of DevOps.
    • Security principles, such as Defense-in-Depth have led to new constructs, such as IAM, Accounts, Organizations, Subscriptions, which were not prevalent in the on-prem world.
    • Cloud Vendors try their best to abstract the networking underlay constructs so that networking is represented as a black box to the cloud architect. To a certain extent they’ve done well (who honestly misses Spanning Tree?), but just because they don’t offer a mechanism to view these constructs, it doesn’t mean they no longer exist. In fact, Operations needs better visibility now than they did in the on-prem world.
  • While Cloud Vendors offer Networking Specialty certifications, they don’t provide any visibility into Day 2 Operations. And from an Architecture perspective, they trivialize the networking underlay. For example, they don’t provide solutions to real-world problems like overlapping subnets or end-to-end visibility.
  • Cloud vendors are incentivized by lock-in and have no real motivation for multi-cloud.
  • Enterprises find it easier to interpret multi cloud mostly in terms of governance and billing rather than infrastructure.
  • Cloud Training platforms such as A Cloud Guru and Udemy completely lack multi-cloud networking offerings. They have training courses on various cloud-first tools and technologies like Terraform, CloudFormation, Deployment Manager, Docker, Kubernetes, and certification courses for AWS, Azure, and GCP. But when it comes to multi cloud let alone multi cloud networking, they have not yet capitalized on the opportunity.
  • Enterprises need better instruction on the need for multi-cloud networking. Often when Enterprises say they need Cloud Infrastructure Architects, they really mean Cloud Application Architects. Yet, when they cross that bridge of multi-cloud (and they almost inevitably will), then they realize that application performance relies on a rock solid transit. And that is where Aviatrix shines.

Aviatrix is the pioneer in multi-cloud networking and is solving a really hard problem the right way – by simplifying. I’m looking forward to sharing some more of my learnings with you as I embark on this new journey.

What’s the Big Deal About Multi-Cloud Networking – Part 2

If you were experiencing issues with Zoom calls today, you were not alone.

But if you take a close look at today’s outage, it is clear that it was correlated with an AWS outage today.

In fact, most of Zoom runs on AWS, according to AWS. This is despite Oracle’s claim that millions of users run Zoom on Oracle Cloud. Zoom didn’t state the cause of the outage, but it is quite possible from these two charts that a well-architected transit network, such as the Aviatrix Multi-Cloud Network Architecture, could have prevented this outage.

Bringing Reference Architectures to Multi-Cloud Networking

Recently I attended Aviatrix Certified Engineer training to better understand multi-cloud networking and how Aviatrix is trying to solve its many problems, some of which I have experienced first-hand. Disclaimer: Since 2011, I’ve been an avid listener of the Packet Pushers podcast, where Aviatrix has sponsored 3 shows since December 2019.

Ever since I embarked on the public cloud journey, I have noticed how each of the big 4 vendors (AWS, Azure, GCP, and OCI) approach networking in the cloud differently from how it has been done on-premises. They all have many similarities, such as:

  • The concept of a virtual Data Center (VPC in AWS and GCP, VNET in Azure, VCN in OCI).
  • Abstracting Layer 2 as much as possible (no mention of Spanning Tree or ARP anywhere) from the user despite the fact that these protocols never went away.

However, there are many differences as well, such as this one:

  • In AWS, subnets have zonal scope – each subnet must reside entirely within one Availability Zone and cannot span zones.
  • In GCP, subnets have regional scope – a subnet may span multiple zones within a region.

Broadly speaking, the major Cloud Service Providers (CSPs) do a fairly decent job with their documentation, but they don’t make it easy for one to connect clouds together. They give you plenty of rope to hang yourself, and you end up being on your own. Consequently, your multi-cloud network design ends up being unique – a snowflake.

In the pre-Public Cloud, on-premises world, we would never have gotten far if it weren’t for reference designs. Whether it was the 3-tier Core/Aggregation/Access design that Cisco came out with in the late 1990’s, or the more scaleable spine-leaf fabric designs that followed a decade later, there has always been a need for cookie-cutter blueprints for enterprises to follow. Otherwise they end up reinventing the wheel and being snowflakes. And as any good networking engineer worth their salt will tell you, networking is the plumbing of the Internet, of a Data Center, of a Campus, and that is also true of an application that needs to be built in the cloud. You don’t appreciate it when it is performing well, only when it is broken.

What exacerbates things is that the leading CSP, AWS, does not even acknowledge multiple clouds. In their documentation, they write as if Hybrid IT only means the world of on-premises and of AWS. There is only one cloud in AWS’ world and that is AWS. But the reality is that there is a growing need for enterprises to be multi-cloud – such as needing the IoT capabilities of AWS, but some AI/ML capabilities of GCP; or starting on one cloud, but later needing a second because of a merger/acquisition/partnership. Under such circumstances, an organization has to consider multi-cloud, but in the absence of a common reference architecture, the network becomes incredibly complex and brittle.

Enter Aviatrix with its Multi-Cloud Network Architecture (MCNA). This is a repeatable 3-layered architecture that abstracts all the complexity from the cloud-native components, i.e. regardless of the CSPs being used. The most important of the 3 layers is the Transit Layer, as it handles intra-region, inter-region, and inter-cloud connectivity

Aviatrix Multi-Cloud Networking Architecture (MCNA)

Transitive routing is a feature that none of the CSPs support natively. You need to have full-mesh designs that may work fine for a handful of VPCs. But it is an N² problem (actually N(N-1)/2), which does not scale well in distributed systems. In AWS, it used to be that customers had to be able to address this completely on their own with Transit VPCs, which was very difficult to manage. In an attempt to address this problem with a managed service, AWS announced Transit Gateways at re:Invent 2018, but that doesn’t solve the entire problem either. With Transit Gateways (TGW), a peered VPC sends it routes to the TGW it is attached to. However, that TGW does not automatically redistribute those routes to the other VPCs that are attached to it. The repeatable design of the Aviatrix MCNA is able to solve this and many other multi-cloud networking problems.

Aviatrix has a broad suite of features. The ones from the training that impressed me the most were:

  • Simplicity of solution – This is a born-in-the-cloud solution whose components are:
    • a Controller that can even run on a t2.micro instance
    • a Gateway that handles the Data Plane and can scale out or up
    • Cloud native constructs, such as VPC/VNET/VCN
  • High Performance Encryption (HPE) – This is ideal for enterprises who, for compliance reasons, require end-to-end encryption. Throughput for encrypting a private AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect, or OCI FastConnect link cannot exceed 1.25 Gbps because virtual routers utilize a single core and establish only 1 IPSec tunnel. So even if you are paying for 10 Gbps, you are limited by IPSec performance and get only 1.25 Gbps performance. Aviatrix HPE is able to achieve line-rate encryption using ECMP.
  • CloudWAN – This takes advantage of the existing investment that enterprises have poured into Cisco WAN infrastructure. When such organizations need to connect to the cloud with optimal latency between branches and apps running in the cloud, Aviatrix CloudWAN is able log in to these Cisco ISRs, and configure VPN and BGP appropriately so that they connect to an Aviatrix Transit Gateway with the AWS Global Accelerator service for the shortest latency path to the cloud.
  • Smart SAML User VPN – I wrote a post on this here.
  • Operational Tools – FlightPath is the coolest multi-cloud feature I have ever seen. It is an inter-VPC/VNET/VCN troubleshooting tool that retrieves and displays Security Groups, Route table entries, and Network ACLs along all the cloud VPCs through which data traverses so you can pinpoint where a problem exists along the dataplane. This would otherwise involve approximately 25 data points to investigate manually (and that doesn’t even include multi-cloud, multi-region, and multi-account). FlightPath automates all of this. Think Traceroute for multi-cloud.

In the weeks and months to come, I’m hoping to get my hands wet with some labs and write about my experience here.

Creating a Multi-Tier Kubernetes App in GCP and AWS

This post details my experience with creating a simple multi-tier Kubernetes app using Google Cloud Platform (GCP) as well as Amazon Web Services (AWS) by taking advantage of the free tier accounts for each service. The app comprises a Redis master for storage, multiple Redis read replicas (a.k.a Slaves), and load-balanced web frontends. Kubernetes acts as a Frontend load balancer that proxies traffic to one or more of these Slaves (known as ‘container nodes’ in Kubernetes lingo). In order to manage these, I created Kubernetes replication controllers, pods, and services in this sequence:

  1. Create the Redis master replication controller.
  2. Create the Redis master service.
  3. Create the Redis slave replication controller.
  4. Create the Redis slave service.
  5. Create the guestbook replication controller.
  6. Create the guestbook service.


GCP has a few easy-to-follow tutorials for their main services. For Google Kubernetes Engine (GKE), the tutorial walks you through creating cluster to deploy a simple Guestbook application to the cluster.

AWS launched Amazon Elastic Container Service for Kubernetes (Amazon EKS) at re:Invent 2017 and it became Generally Available in June 2018.

For EKS, I generally followed the EKS documentation with the following observations:

  • Some pre-work was needed in EKS, such as:
    • Installing the latest AWS CLI. On the other hand, Google Cloud Shell in GCP makes it really simple to perform operation and administration tasks.
    • Installing a tool to use AWS IAM credentials to authenticate to a Kubernetes cluster. It’s not clear to me why exactly this is needed. The documentation for AWS IAM Authenticator for Kubernetes states “If you are an administrator running a Kubernetes cluster on AWS, you already need to manage AWS IAM credentials to provision and update the cluster. By using AWS IAM Authenticator for Kubernetes, you avoid having to manage a separate credential for Kubernetes access.” However, it appears to be a needless step. Why can’t Kubernetes clusters in AWS EKS leverage AWS IAM credentials directly?
    • In GCP, Google Cloud Shell includes the kubectl CLI utility. In AWS, you need to install it locally. Moreover, GCP made it far easier to configure the kubeconfig file by issuing the gcloud container clusters get-credentials pakdude-kubernetes-cluster –zone us-central1-a command. With EKS, I had to manually edit the kubeconfig file to populate the cluster endpoint (called anAPI server endpoint in EKS) and auth data (called a Certificate Authority in EKS).
  • Creating a Kubernetes cluster takes about 10 minutes in EKS, compared to just 2-3 minutes with GKE.
  • When creating the Kubernetes cluster in EKS, as per the documentation, You must use IAM user credentials for this step, not root credentials. I got stuck on this step for a while, but it is good practice anyway to use an IAM user instead of the root credentials.
  • In GKE, I ran into memory allocation issues when creating node pools that had machine type f1.micro, which are 1 shared vCPU, 0.6 GB memory. However, when I created the node pools with machine type g1-small (1 shared vCPU, 1.7 GB memory), things ran more smoothly. In EKS, t1.micro instances are not even offered; the smallest type of instance I could specify for the NodeInstanceType was t2.small.
  • The supported Operating Systems for nodes in GKE node pools are Container Optimized OS (cos) and Ubuntu. In EKS, you have to use an Amazon EKS-optimized AMI, which differs across regions. That difference, alone, opens up inconsistencies between the two implementations.
  • There is very little one can do at the AWS Console for EKS. Most of the work at the CLI or programmatically. For example, there is no way in AWS to check the status of worker nodes. You have to use the kubectl get nodes –watch command.

The sample GKE Frontend/Guestbook code was cloned from Git Hub. After setting it up, it gave this output:

umairhoodbhoy@pakdude713:~$ kubectl get pods
NAME                 READY     STATUS    RESTARTS   AGE
frontend-qgghb       1/1       Running   0          23h
frontend-qngcj       1/1       Running   0          23h
frontend-vm7nq       1/1       Running   0          23h
redis-master-j6wc9   1/1       Running   0          23h
redis-slave-plc59    1/1       Running   0          23h
redis-slave-r664d    1/1       Running   0          23h
umairhoodbhoy@pakdude713:~$ kubectl get rc
frontend       3         3         3         23h
redis-master   1         1         1         1d
redis-slave    2         2         2         23h
umairhoodbhoy@pakdude713:~$ kubectl get services
NAME           TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
frontend       LoadBalancer   80:30549/TCP   23h
kubernetes     ClusterIP     <none>           443/TCP        1d
redis-master   ClusterIP   <none>           6379/TCP       1d
redis-slave    ClusterIP    <none>           6379/TCP       23h

GCP GKE Guestbook Tutorial

The sample EKS Guestbook app was also cloned from Git Hub. After setting it up, it gave this output:

hoodbu@macbook-pro /AWS (608) kubectl get pods
NAME                 READY     STATUS    RESTARTS   AGE
guestbook-9lztg      1/1       Running   0          3h
guestbook-bb7md      1/1       Running   0          3h
guestbook-gx6sr      1/1       Running   0          3h
redis-master-qhk8h   1/1       Running   0          3h
redis-slave-7jlpb    1/1       Running   0          3h
redis-slave-8hsmg    1/1       Running   0          3h
hoodbu@macbook-pro /AWS (609) kubectl get rc
guestbook      3         3         3         3h
redis-master   1         1         1         3h
redis-slave    2         2         2         3h
hoodbu@macbook-pro /AWS (610) kubectl get services
NAME           TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)          AGE
guestbook      LoadBalancer     affaf9aae9039...   3000:30189/TCP   3h
kubernetes     ClusterIP      <none>             443/TCP          5h
redis-master   ClusterIP   <none>             6379/TCP         3h
redis-slave    ClusterIP   <none>             6379/TCP         3h
hoodbu@macbook-pro /AWS (611) 

AWS EKS Guestbook Tutorial

Obviously, these are just simple Guestbook applications and I only covered the ease of setting up Kubernetes. A more relevant measure of Kubernetes on either cloud platform would be the performance and scalability. I had no easy way of stress testing the apps. However, after going through this exercise in both AWS and GCP, it is clear where GCP’s strengths lie. AWS may be the dominant Public Cloud player, but launching EKS despite having its own Elastic Container Service (ECS) is an indication of how popular Kubernetes is as a container orchestration system. Running Kubernetes on AWS is incredibly cumbersome compared to running it on GCP. EKS is relatively new and I’m sure AWS will iron out the kinks in the months to come.