In the previous post, we explained the main building blocks for AWS network infrastructure and how we can utilize AWS VPCs to build isolated and managed virtual Data Centers in the AWS cloud.

In this post, we will outline how to design and build the AWS VPCs using Infrastructure as a Code utilizing Ansible to build all the Infrastructure.

 

Requirements

The following are the requirements in order to build and deploy this ** Ansible **  playbook.

• An AWS Account
• A User account with the  Administration privileges to create VPCs, Subnets, and IGWs (this is controlled by  Amazon Identity and Access Management or IAM).
• An Ansible server with boto3 installed on it (boto3 is the python library to interact with AWS API).

For the AWS Account, You can start exploring the AWS Cloud, using a free tier account which is free for the first 12 months as long as you use the AWS components within the free limit constraints. More about AWS free tier can be found on this link.

 

What we will Build

We will start deploying AWS VPCs across two AWS regions (in us-east-1 and eu-west-1), we will build the following VPCs.

• Production VPC in us-east-1 with 2 subnets across two AZs for redundancy.
• Development VPC in eu-west-1 with a single Subnet ( no redundancy in this case).
• Another production VPC in eu-west-1 with 2 subnets across two AZs for redundancy.

 

The below diagram outline the Network setup that we will build.

 

 

Building VPCs with Ansible

When using ansible to provision resources on the AWS, all the modules run locally on the ansible machine against the AWS API within each region. We reference each VPC as it is a host in the ansible inventory and we group all the VPCs within a specific region into a single group,  The ansible inventory is shown below

 

This setup allows us to easily group all the requirements for each VPC into a single YAML file under the host_vars and group all the group level requirements into another file under group_vars.

The below snippet outline how we design the overall Data model that describe the AWS VPC, subnets, IGW and route-tables and using all these data we will build the VPC and all the other components using the different ansible AWS modules.

User Authentication

All User interaction with AWS cloud is controlled by AWS IAM service, which is responsible for creating User accounts, provide user authentication, and assign privileges to these users. This service is a global Service which means it is not bound by a region so all the user attributes are enforced across all AWS regions.

In order to interact with the AWS API to query or build any resources within your account, you need to authenticate with the AWS API with your user credentials. AWS create two unique keys for each user for programmatic access through the API which is totally separate from the username and password you use for user authentication for GUI login. These keys are called access_key and secreate_access_key, these keys it must be generated by the user via the AWS GUI Console and it is available for download as a CSV file only once after creation.

In order to protect these confidential data while also saving them as ansible variables, we use ansible-vault to encrypt these keys and reference them within the all.yml file using these two variables (aws_keys and aws_secret_key). These variables are then injected into the following environment variables (AWS_SECRET_KEY and AWS ACCESS_KEY ) in the playbook and thus all the aws modules can find them for all the API calls that take place in each aws module, the below snippet outline this interaction

 

Building the VPC

The below snippet captures the tasks required to build the AWS VPC for each environment, we need to record the vpc_id (the unique identifier for the VPC by AWS Orchestration system) since we must reference it when creating all the other resources within the VPC (subnets, IGW, route tables, etc.. ). All the variables outlined below (like vpc_name and vpc_cidr) are retrieved from the variables associated with each VPC.

 

Building the Subnets

The below snippet outline the tasks need to build the subnets within each VPC.

 

Building the IGW

We attached the IGW, which provide our egress point from our local VPC to the internet to reach any destination and to reach other AWS services, not within the VPC (like S3 and DynamoDB).

 

Adjusting the Routing

At this point the VPC is attached to the IGW however no traffic will go to the IGW since we need to adjust the Routing table of each Subnet. By default, when we create a VPC a default route table is created for the VPC, the below snippet outline the default route table for us_prod VPC.

This Local Route referencing the CIDR whole CIDR for the VPC allows for intra-VPC routing (traffic between the subnets within the same VPC). In order to utilize the IGW that was attached with the VPC, we need to add a default route in this routing table. We also associate all the Subnets that we build within each VPC with this default Route table since in this scenario all the VPCs needes access to the Internet via the IGW. The below snippet outline the tasks which adjust the routing table for the VPC.

After the playbook is run the route table for the VPC will be as shown below

Conclusion

What did we do?

At this stage we have outlined how to build VPCs within the AWS cloud which can be though as virtual Data Centers within the cloud, and we created Subnets at this stage in order to provide more resiliency for the applications to utilize the underlying AWS Availability Zone construct and we have made all these subnets reachable through the internet.

We described the whole design using infrastructure as code concepts (utilizing Ansible variables to do so) and deployed the whole design using Ansible

What is Next?

There is still a lot for points which is still missing in the design like

• Security and how to restrict access to the resources in the cloud and how to secure them.
• High Availability, although we have utilized subnets to provide resiliency to the applications, However load balancers need to be in place in order to load balance the traffic between the servers in different subnets/AZs.
• At this point there is no connectivity between the different VPCs and each VPCs is isolated, How can we implement inter VPC routing and how can we connect the different VPCs if this is a requirement?
• In case the access requirements for the application is different (some are front end and some are backend with no need to access the internet) how can we implement these different access behaviors?
• How to connect our VPCs to on Prem data centers and how to implement routing between on Prem Data Centers and the Different VPCs.

 

All the above points we will try answer in the coming posts.

The source code for the playbook can be found in the following link.