Best practices for naming and using AWS Infrastructure with Terraform and Ansible.
The following are the basic infrastructure building blocks that you need to understand in order to build solutions on top of AWS Cloud offering.
AWS has very curated documentation specifying in great detail each element. This post doesn't pretend to substitute the official documentation that is available at https://aws.amazon.com/documentation/
In this post, you will find a quick description of each element and tips and suggestions on how to use the infrastructure following our best practices and adjusting what can be done to the available budget.
We like to control and understand every piece of the infrastructure.
In our examples and demos, the AWS infrastructure is completed recreated. AWS pre-created infrastructure like VPC, Subnets and Route Tables is not used and it is actually manually deleted.
AWS has data centers in many countries around the world, some countries even have more than one group of data center.
Data centers that are near each other in a country, form a region, AWS has 18 geographic Regions.
Usually, the selection of the Regions that are going to be used for our rented infrastructure (IaaS or Infrastructure as a Service) should take into consideration legal, technical and economic reasons.
Most of our demos will be using the US East (N. Virginia) Region, that is called us-east-1 because it has the lowest prices across all AWS Regions. Prices can be checked using the AWS Simple Monthly Calculator.
A Virtual Private Cloud (VPC) is a logical group of resources that are isolated from other VPCs and other customers of the Public Cloud.
A VPC uses a customer-selected private IP address range that is further assigned to different VPC Subnets (see below) distributed in private and public zones, and different availability zones that are interconnected trough routers and traditional IP network routing.
IT Wonder Lab best practice for maximum isolation of environments (development, testing and production) is to create a different VPC for each environment. Some times it is not possible to archive that level of isolation due to budget availability, lack of availability of private IP ranges, lack of VPN's, or other constraints.
A VPC Subnet is defined by a subrange of the network IP addresses assigned to the VPC.
IT Wonder Lab best practice is to distribute sub nets in more than one Availability Zone and have private and public zones to achieve:
In most of our examples, the VPC will be distributed in at least the following Subnets (all combinations of Availability Zone and Public/Private)
If we are sharing the VPC for multiple environments, I recommend creating different VPC Subnets for each environment, for example for a production and a pre-production/testing environment the following subnets will be created.
Be aware that we don't recommend creating a big amount of subnets or using them as security groups or firewall rule sources.
Each AWS Region has at least two data centers that are located in different locations to achieve high availability in case of failure.
By having the infrastructure replicated in different data centers that are close to each other but isolated from one another it is possible to build high availability solutions that are fast, economical and simple to build and run because the network latency between Availability Zones in the same Region is ultra-low and in case of catastrophe each Availability Zone can operate on isolation from the rest.
An RDS Subnet should be composed of two or more VPC Subnets that are located in different Availability Zones, the RDS subnet will be used to place RDS Instances (see below).
It is recommended to choose RDS instances in Multi-AZ configuration for production databases.
The Multi-AZ configuration places a Read/Write instance in one Availability Zone and a standby replica in a different Availability Zone. The data is synchronously replicated between the primary DB instance and the standby instance.
In case of failure, upgrade or maintenance, the standby replica is promoted and takes the role of the primary DB instance without manual intervention.
Applications using the RDS in Multi-AZ configuration connect to an endpoint that routes the traffic to the primary DB instance.
In most of our examples, an RDS Subnet will be created with the following private VPC Subnets.
If we are sharing the VPC for multiple environments, at least two RDS Subnets will be created:
The VPC Security Groups are the way AWS implements firewalls between instances in the VPC.
In a VPC all inbound and outbound network traffic is denied by default. In order to allow traffic, a security group is defined and rules are assigned to the Security Group.
Inbound traffic rules are defined by specifying at least:
Outbound traffic rules are defined by specifying at least:
Remember that since all traffic is denied, you need to allow outbound traffic in order to receive responses from your instances (i.e. a Web server needs to be able to send outbound traffic).
In all our demos you will find:
The router is a virtual network element that is created by AWS to apply the defined routing tables and connect VPC subnets, Availability Zones and external resources like the Internet Gateway.
Instances in the VPC have a private IP assigned to their network interface and instances placed in a Public Subnet are assigned also a public IP address.
The assigned public IP address is nor really attached to the instance network interface, the instance is not aware of having a public IP address, instead, the public IP address is used by the Internet Gateway to do a reverse NAT from the public IP Internet address to the instance private IP.
The Internet gateway is needed to replace in all outbound Internet traffic from the instances the private IP with a public IP and to do the opposite when a package is received from the Internet.
Only instances placed in public subnets and having a public IP address are able to receive traffic from the Internet.
Routing tables are needed to send traffic outside the VPC, for example, to send traffic to a VPN or to the Internet, either using an Internet Gateway or a NAT instance.
It is also possible to connect VPCs and route traffic between them.
Represent the Internet.
Route 53 is the DNS service provided by AWS. Hosted domain zones can be either public for Internet usage or private, limiting the service to instances in the VPC.
In our examples, it is used to register all the created instances with its public and private names. It is also used for manual registration of domain names, where AWS acts as registrar, offering privacy protection, multiple distributed geographic locations, and advanced capabilities.
AWS EC2 Instances are virtual servers that are launched with the requests hardware and operating system based on a source AMI (see below).
Most of the instances used during the demos are or type t2.micro as that type is included in the free tier:
T2 instances are Burstable Performance Instances that provide a baseline level of CPU performance with the ability to burst above the baseline.
t2.micro instances have 1 vCPU and 1GB of RAM, storage uses EBS (Elastic Block Storage).
RDS stands for Relational Database Service, it is the AWS offering or managed database engines like Oracle, MySQL, PostgreSQL, Aurora, and MS SQL Server.
We recommend using RDS instead of operating your own DataBase instances as it provides many advantages that will be difficult or expensive to achieve by yourself.
Amazon Machine Image (AMI) is the read-only initial root disk used to create new instances, there are many available AMI on the AWS Marketplace or Community AMIs pages and you can also build your own.
AMIs are used to start new instances with a selected operating system and predefined configuration.
In most of our demos, we will use an Ubuntu 16.04 HVM EBS SSD image provided by Canonical. Other releases or operating systems are available and can be used. The Ubuntu Linux distribution is widely used in the startup ecosystem and very popular among developers. We prefer to use the same operating system in all environments to avoid configuration issues.[:]
IT Wonder Lab tutorials are based on the diverse experience of Javier Ruiz, who founded and bootstrapped a SaaS company in the energy sector. His company, later acquired by a NASDAQ traded company, managed over €2 billion per year of electricity for prominent energy producers across Europe and America. Javier has over 25 years of experience in building and managing IT companies, developing cloud infrastructure, leading cross-functional teams, and transitioning his own company from on-premises, consulting, and custom software development to a successful SaaS model that scaled globally.
Are you looking for cloud automation best practices tailored to your company?