A VPC spans an AWS region. A region contains two or more availability zones. A VPC contains subnets that are used to logically separate resources inside a region. A subnet cannot span across multiple availability zones. A subnet can either be a private subnet or a public subnet based on its accessibility from outside of VPC and if it can access resources outside of VPC.

Subnets are used for separating resources, such as web servers and database servers. They are also used for making your application highly available and fault-tolerant. By default, all resources in all subnets of a VPC can route (communicate) to each other using private IP addresses.

The ENI are available for EC2 instances running inside a VPC. An ENI can have many attributes, such as a primary private IPv4 address, a MAC address, one or more security groups, one or more IPv6 addresses, and so on. These attributes will move with ENI when an ENI is attached to an instance; when this ENI is detached from an instance, these attributes will be removed.

By default, every VPC has a network interface attached to every instance. This ENI is known as a primary network interface (eth0). This default ENI cannot be detached from an instance. You can, however, create and attach many additional ENIs to your instances inside a VPC.

One of the popular use cases of ENI is having secondary ENI attached to instances running network and security appliances, such as network address translation servers or load balancers. These ENIs can be configured with their own attributes, such as public and private IP address, security groups, and so on.

As you've learned about VPC, it essentially facilitates traffic in and out of a software-defined network. This traffic needs to know where to go, and this is achieved via route tables. A route table in VPC has rules or routes defined for the flow of traffic. Every VPC has a default route table that is known as the main route table. You can modify this main route table and you can create additional route tables.

Each subnet in VPC is associated with only one route table, however, one route table can be attached to multiple subnets. You use route tables to decide what data stays inside of VPC and what data should go outside of VPC, and that is where it plays a very important part in deciding data flow for a VPC.

In the following figure, you can see four route tables for two VPCs in my AWS account. You can see rules in the route table, and you see tabs for subnet associations as well:

Figure 2: AWS VPC route tables

An internet gateway allows communication between resources such as EC2 and RDS instances in your VPC and the Internet. It is highly available, redundant, and horizontally scalable; that is, you do not need to attach more than one internet gateway to your VPC in order to support an increase in traffic.

An internet gateway serves as a target for route table in VPC for all the traffic that is supposed to go out of VPC to the internet. Along with that, it also performs network address translation for all instances with public IPv4 addresses.

An Elastic IP Address is a public IPv4, static address that can be associated with any one instance or one network interface at a time within any VPC in your AWS account. When your application is dependent on an IP address, you would use an Elastic IP address instead of a regular public IP address because public IP addresses would be lost if the underlying instance shuts down for some reason. You can simply move your Elastic IP address to another instance that is up and running from a failed instance.

You first allocate an Elastic IP address and then associate it with your instance or network interface. Once you do not need it, you should disassociate it and then release it. If an Elastic IP address is allocated but not associated with any instance, then you will be charged by AWS on an hourly basis, so if you don't have a requirement for Elastic IP addresses, it is better to release them.

A VPC endpoints is a secure way to communicate with other AWS services without using the internet, Direct Connect, VPN Connection, or a NAT device. This communication happens within the Amazon network internally so your traffic never goes out of Amazon network. At present, endpoints are supported only for Simple Storage Service (S3). These endpoints are virtual devices supporting IPv4-only traffic.

An endpoint uses the private IP address of instances in your VPC to communicate with other services. You can have more than one endpoint in your VPC. You create a route in your route table for directing traffic from instance V2 in subnet 2 through your endpoint to your target service (such as S3), as shown in the following figure:

Figure 3: AWS VPC endpoints and route tables

You will often have resources in your VPC that will reside in private subnets that are not accessible from the internet. However, these resources will need to access the internet occasionally for patch update, software upgrade, and so on. A NAT device is used exactly for this purpose, allowing resources in private subnet to connect with either the internet or other AWS services securely. NAT devices support only IPv4 traffic.

AWS offers a NAT gateway, a managed device, and a NAT instance as NAT devices. Depending on your use case, you will choose either of them. AWS recommends a NAT gateway over a NAT instance as it is a managed service that requires little or no administration, is highly available, and highly scalable.

You can connect your VPC with one or more VPCs in the same region through the VPCs peering option. This connection enables you to communicate with other VPC using private IPv4 or private IPv6 addresses. Since this is a networking connection, instances in these VPCs can communicate with each other as if they are in the same network.

You can peer with VPCs in your AWS account or VPCs in other AWS accounts as well. Transitive peering is not allowed and VPCs should not have overlapping or matching IPv4 or IPv6 CIDR blocks. The following figure shows VPC peering between VPC A and VPC B. Note that the CIDR blocks differ for these two VPCs:

Figure 4: AWS VPC peering