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.

ITWL AWS Glosary Basic VPC

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

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.


ITWL AWS Glosary Region

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.

  • Legal reasons:  location of private data, privacy, and regulation. Technical reason
  • Technical reasons: ideally data centers should be as close as possible to the consumers of the infrastructure, our users.
  • Economic reason: prices for the IaaS are different in each region, I supposed prices vary depending on the cost of energy, taxes and regulation of the Region.

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.

Virtual Private Cloud


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.

VPC Subnet

AWS VPC Subnet

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:

  • 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 trough 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

ITWL AWS Glosary Availability Zone

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.

RDS Subnet

ITWL AWS Glosary RDS Subnet

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

AWS Security Groups

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:

  • 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.
    • 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. All internet)
    • Security Group: Name of a security group, the resources that have that Security Group assigned will be the destination.

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:

  • 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.


AWS 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

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 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

AWS Routing table

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.


AWS Internet

Represent the Internet.

Route 53

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

AWS EC2 Instance

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 DataBase

AWS MySQL Master

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.[:]

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Cloud Tutorials

Javier Ruiz Cloud and SaaS Expert

Javier Ruiz

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?

linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram