AWS Basic VPC Elements
Best practices for naming and using AWS Infrastructure with Terraform and Ansible.
Basic AWS Infrastructure Building Blocks #
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 that specifies each element in great detail. This post does not pretend to replace the official 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 completely recreated. AWS pre-created infrastructure like VPC, Subnets and Route Tables is not used and it is actually manually deleted.
Region #
See AWS Regions and Availability Zones.
AWS has data centers in many countries around the world, and some countries have more than one group of data centers.
Data centers that are near each other form a Region. AWS has dozens of geographic Regions and keeps adding new ones.
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.
- Legal reasons: location of private data, privacy, and regulation.
- Technical reasons: ideally data centers should be as close as possible to the consumers of the infrastructure, our users.
- Economic reasons: the prices of the IaaS are different in each Region, probably because of the cost of energy, taxes and regulation.
Most of our demos will be using the US East (N. Virginia) Region, that is called us-east-1, because it is one of the Regions with the lowest prices. Prices can be checked with the AWS Pricing Calculator.
Virtual Private Cloud #
See AWS VPC.
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 through 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. Sometimes it is not possible to achieve that level of isolation due to budget availability, lack of availability of private IP ranges, lack of VPN’s, or other constraints.
VPC Subnet #
See AWS Subnets.
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 subnets in more than one Availability Zone and have private and public zones to achieve:
- Resource distribution: the infrastructure is distributed in different VPC to apply specific routing tables, DHCP options and technical or business organization of resources.
- High availability: by distributing the resources in many Availability Zones (see below) the system can be made highly available and tolerant to a single or even multiple data center failure.
- Isolation of resources: resources are placed either in public or in private networks. A public network assigns a public IP to each resource so it can be accessed through the Internet. In a private network, only private IPs are assigned to resources so there is no way to access the resources directly from the Internet.
In most of our examples, the VPC will be distributed in at least the following Subnets (all combinations of Availability Zone and Public/Private)
- Public VPC Subnet in Availability Zone A
- Public VPC Subnet in Availability Zone B
- Private VPC Subnet in Availability Zone A
- Private VPC Subnet in Availability Zone B
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.
- Public PRO VPC Subnet in Availability Zone A
- Public PRO VPC Subnet in Availability Zone B
- Private PRO VPC Subnet in Availability Zone A
- Private PRO VPC Subnet in Availability Zone B
- Public PRE VPC Subnet in Availability Zone A
- Public PRE VPC Subnet in Availability Zone B
- Private PRE VPC Subnet in Availability Zone A
- Private PRE VPC Subnet in Availability Zone B
Be aware that we don’t recommend creating a big amount of subnets or using them as security groups or firewall rule sources.
Availability Zone #
See AWS Regions and Availability Zones.
Each AWS Region has several Availability Zones (at least three), each made of one or more data centers 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.
RDS Subnet #
In AWS this is called a DB subnet group, see AWS RDS.
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.
- Private RDS Subnet
- Private VPC Subnet in Availability Zone A
- Private VPC Subnet in Availability Zone B
If we are sharing the VPC for multiple environments, at least two RDS Subnets will be created:
- Private PRO RDS Subnet
- Private PRO VPC Subnet in Availability Zone A
- Private PRO VPC Subnet in Availability Zone B
- Private PRE RDS Subnet
- Private PRE VPC Subnet in Availability Zone A
- Private PRE VPC Subnet in Availability Zone B
Security Group #
See AWS Security Groups and AWS Security Groups’ Best Practices.
The VPC Security Groups are the way AWS implements firewalls between instances in the VPC.
In a VPC all inbound network traffic is denied by default. To allow traffic, a security group is defined and rules are assigned to it.
Inbound traffic rules are defined by specifying at least:
- From port: open port range start (i.e. 443)
- To port: open port range end (i.e. 443)
- Protocol: TCP/UDP/ICMP, …
- Origin: the source of the inbound traffic can be an IP address block or a Security Group.
- CIDR block: IP address block (i.e. 172.16.32.0/19)
- Security Group: Name of a security group, the resources that have that Security Group assigned will be the origin.
Outbound traffic rules are defined by specifying at least:
- From port: destination port range start (i.e. 3306)
- To port: destination port range end (i.e. 3306)
- Protocol: TCP/UDP/ICMP, …
- Destination: the destination of the outbound traffic can be an IP address block or a Security Group.
- CIDR block: IP address block (i.e. 0.0.0.0/0 All internet)
- Security Group: Name of a security group, the resources that have that Security Group assigned will be the destination.
Security groups are stateful: the responses to allowed requests are allowed automatically. Outbound rules are needed for the connections that the instances initiate, for example to download updates.
In all our demos you will find:
- A default security group that allows:
- All outbound traffic (needed to send responses back and to update servers from public repos).
- Inbound SSH traffic from management workstations.
- Inbound monitoring traffic from monitoring servers.
- A specific security group for each type of instance that allows:
- Selected inbound traffic for the service that the instance provides, for example, inbound 3306/tcp for RDS Instances and source security group assigned to consumers of that service, for example EC2 instances accessing the RDS service.
- No outbound rules as those are covered by the default security group.
Router #
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.
Internet Gateway #
See AWS 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 not 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 #
See AWS Route Tables.
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 Gateway.
It is also possible to connect VPCs and route traffic between them.
Internet #
Represent the Internet.
Route 53 #
See AWS Route 53.
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.
EC2 Instance #
See AWS EC2.
AWS EC2 Instances are virtual servers that are launched with the requested hardware and operating system based on a source AMI (see below).
The instances used in the demos are small burstable instances (originally t2.micro, later t4g.micro), which are eligible for the free offer of AWS or have a very low cost:
Burstable performance instances provide a baseline level of CPU performance with the ability to burst above the baseline.
They have 1 GB of RAM, and their storage uses EBS (Elastic Block Store).
RDS Database #
See AWS RDS.
RDS stands for Relational Database Service, it is the AWS offering of 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.
AMI #
See AWS AMI.
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 the demos we use an Ubuntu HVM EBS SSD image provided by Canonical (Ubuntu 16.04 in the first demos, later releases in the newer tutorials). 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.