AWS VPC Routing
In this post I want to summarize some information about how routing in AWS works. This topic is well documented from AWS.
Virtual Private Cloud (VPC)
A virtual private cloud (VPC) is a virtual network dedicated to your AWS account. It is logically isolated from other virtual networks in the AWS Cloud. You can launch your AWS resources, such as Amazon EC2 instances, into your VPC.
Amazon Virtual Private Cloud (VPC) is the counterpart of Microsoft Azure’s Virtual Private Network (VNet).
Amazon Virtual Private Cloud (Amazon VPC) enables you to launch AWS resources into a virtual network that you’ve defined. This virtual network closely resembles a traditional network that you’d operate in your own data center, with the benefits of using the scalable infrastructure of AWS.
Source: https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html
When you create a VPC, you must specify a range of IPv4 addresses for the VPC in the form of a Classless Inter-Domain Routing (CIDR) block. For example, 10.0.0.0/16. This is the primary CIDR block for your VPC.
A VPC spans all of the Availability Zones in the Region. The following diagram shows a new VPC. After you create a VPC, you can add one or more subnets in each Availability Zone.
Source: https://docs.aws.amazon.com/vpc/latest/userguide/configure-your-vpc.html
When you create a new subnet in your VPC, you can set one of the availability zones which in your region is available. Below for example are the availability zones for the region eu-central 1(Europe/Frankfurt).
Regions and Zones
Amazon EC2 is hosted in multiple locations world-wide. These locations are composed of AWS Regions, Availability Zones, Local Zones, AWS Outposts, and Wavelength Zones.
- Each Region is a separate geographic area.
- Availability Zones are multiple, isolated locations within each Region.
- Local Zones provide you the ability to place resources, such as compute and storage, in multiple locations closer to your end users.
Local Zones
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-local-zones - AWS Outposts brings native AWS services, infrastructure, and operating models to virtually any data center, co-location space, or on-premises facility.
- Wavelength Zones allow developers to build applications that deliver ultra-low latencies to 5G devices and end users. Wavelength deploys standard AWS compute and storage services to the edge of telecommunication carriers’ 5G networks.
AWS operates state-of-the-art, highly available data centers. Although rare, failures can occur that affect the availability of instances that are in the same location. If you host all of your instances in a single location that is affected by a failure, none of your instances would be available.
Source: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html
Subnets
Depending on how you configure your VPC, subnets are considered public, private, or VPN-only:
- Public subnet: The subnet traffic is routed to the public internet through an internet gateway or an egress-only internet gateway. For more information, see Connect to the internet using an internet gateway.
Further also connections from the internet can be established to instances inside the public subnet if they had assigned a public IP address. - Private subnet: The subnet traffic can’t reach the public internet through an internet gateway or egress-only internet gateway. Access to the public internet requires a NAT device. But then external sources cannot initiate a connection to the private subnet.
- VPN-only subnet: The subnet traffic is routed to a Site-to-Site VPN connection through a virtual private gateway. The subnet traffic can’t reach the public internet through an internet gateway. For more information, see the AWS Site-to-Site VPN User Guide.
About how to set up a Site-to-Site VPN between AWS and your on-premise network you can read my following post.
When you create a subnet, you specify its IP addresses, depending on the configuration of the VPC:
- IPv4 only: The subnet has an IPv4 CIDR block but does not have an IPv6 CIDR block. Resources in an IPv4-only subnet must communicate over IPv4.
- Dual stack: The subnet has both an IPv4 CIDR block and an IPv6 CIDR block. The VPC must have both an IPv4 CIDR block and an IPv6 CIDR block. Resources in a dual-stack subnet can communicate over IPv4 and IPv6.
- IPv6 only: The subnet has an IPv6 CIDR block but does not have an IPv4 CIDR block. The VPC must have an IPv6 CIDR block. Resources in an IPv6-only subnet must communicate over IPv6.
Regardless of the type of subnet, the internal IPv4 address range of the subnet is always private—we do not announce the address block to the internet. For more information about private IP addressing in VPCs, see IP addressing.
Source: https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html
Public and private subnets
If a subnet is associated with a route table that has a route to an internet gateway, it’s known as a public subnet. If a subnet is associated with a route table that does not have a route to an internet gateway, it’s known as a private subnet.
In your public subnet’s route table, you can specify a route for the internet gateway to all destinations not explicitly known to the route table (0.0.0.0/0 for IPv4 or ::/0 for IPv6). Alternatively, you can scope the route to a narrower range of IP addresses; for example, the public IPv4 addresses of your company’s public endpoints outside of AWS, or the Elastic IP addresses of other Amazon EC2 instances outside your VPC.
Source: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html
Enable Internet Access for an AWS EC2 Instance
In order that an AWS EC2 instance can access the internet, the following prerequisites are needed:
- An internet gateway (IGW) attached to the VPC
- A route table attached to the VPC with a default route 0.0.0.0/0 which target is the IGW.
- A public IPv4 address or elastic IPv4 address attached to the EC2 instance. (An elastic IPv4 address is a static IPv4 address which does not change over time. It’s the same as a static IPv4 address in Azure)
- A security group attached to the instance that allows all outbound traffic (by default).
- A network ACL associated to the VPC which allows all outbound traffic (by default).
So in AWS all EC2 instances (VMs) needs an public IP address directly attached to it plus an internet gateway attached to the VPC the instance is homed.
There’s one exception when you using NAT devices for your private subnet.
To provide your instances with internet access without assigning them public IP addresses, you can use a NAT device instead. A NAT device enables instances in a private subnet to connect to the internet, but prevents hosts on the internet from initiating connections with the instances. For more information, see Connect to the internet or other networks using NAT devices.
In contrast in a Microsoft Azure VNet all VMs homed in a VNet can communicate outbound to the internet, by default. The technique behind is the same as for the AWS NAT device mentioned above.
Azure: Use Source Network Address Translation (SNAT) for outbound connections
Certain scenarios require virtual machines or compute instances to have outbound connectivity to the internet. The frontend IPs of a public load balancer can be used to provide outbound connectivity to the internet for backend instances. This configuration uses source network address translation (SNAT) to translate virtual machine’s private IP into the load balancer’s public IP address. SNAT maps the IP address of the backend to the public IP address of your load balancer. SNAT prevents outside sources from having a direct address to the backend instances.
Source: https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections
IP addresses and NAT
To enable communication over the internet for IPv4, your instance must have a public IPv4 address. You can either configure your VPC to automatically assign public IPv4 addresses to your instances, or you can assign Elastic IP addresses to your instances.
Your instance is only aware of the private (internal) IP address space defined within the VPC and subnet.
Here you can see an EC2 instance where a public IPv4 address is assigned. As mentioned the VM itself isn’t aware of the public IPv4 address and not directly assigned to.
The internet gateway logically provides the one-to-one NAT on behalf of your instance.
So when traffic leaves your VPC subnet and goes to the internet, the reply address field is set to the public IPv4 address or Elastic IP address of your instance, and not its private IP address. Conversely, traffic that’s destined for the public IPv4 address or Elastic IP address of your instance has its destination address translated into the instance’s private IPv4 address before the traffic is delivered to the VPC.
To enable communication over the internet for IPv6, your VPC and subnet must have an associated IPv6 CIDR block, and your instance must be assigned an IPv6 address from the range of the subnet. IPv6 addresses are globally unique, and therefore public by default.
In the following diagram, the subnet in Availability Zone A is a public subnet. The route table for this subnet has a route that sends all internet-bound IPv4 traffic to the internet gateway. The instances in the public subnet must have public IP addresses or Elastic IP addresses to enable communication with the internet over the internet gateway. For comparison, the subnet in Availability Zone B is a private subnet because its route table does not have a route to the internet gateway. Instances in the private subnet can’t communicate with the internet over the internet gateway, even if they have public IP addresses.
Internet Gateway
An internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet. It supports IPv4 and IPv6 traffic. It does not cause availability risks or bandwidth constraints on your network traffic.An internet gateway enables resources in your public subnets (such as EC2 instances) to connect to the internet if the resource has a public IPv4 address or an IPv6 address. Similarly, resources on the internet can initiate a connection to resources in your subnet using the public IPv4 address or IPv6 address. For example, an internet gateway enables you to connect to an EC2 instance in AWS using your local computer.
An internet gateway provides a target in your VPC route tables for internet-routable traffic. For communication using IPv4, the internet gateway also performs network address translation (NAT). For communication using IPv6, NAT is not needed because IPv6 addresses are public. For more information, see IP addresses and NAT.
There’s no additional charge for creating an internet gateway.
The route table that’s associated with your instance’s subnet has a default route to an internet gateway (0.0.0.0/0).
Routing between subnets
Each subnet must be associated with a route table, which specifies the allowed routes for outbound traffic leaving the subnet.
Every subnet that you create is automatically associated with the main route table for the VPC.
You can change the association, and you can change the contents of the main route table. For more information, see Configure route tables.
Below I had created a new VPC with the network address 172.29.0.0/16. During the creation also automatically a main route table is created as shown below.
By default the main route table will contain a local route for the entire VPC network. This will provide all resources within the VPC to talk to each other by default without any additional configuration.
By default all traffic between the subnets within your VPC are allowed. You can control inbound and outbound traffic for your subnets by using network ACLs as show below.
By design, each subnet must be associated with a network ACL. Every subnet that you create is automatically associated with the default network ACL for the VPC. You can change the association, and you can change the contents of the default network ACL. For more information, see Control traffic to subnets using Network ACLs.
Further you can also control inbound and outbound traffic on the instances directly by using security groups.
Below you will see an EC2 instance (VM) where a security group is assigned which allow inbound TCP traffic on port 3389 for RDP and outbound all traffic.
Routing between VPCs
A virtual private cloud (VPC) is a virtual network dedicated to your AWS account. It is logically isolated from other virtual networks in the AWS Cloud. You can launch AWS resources, such as Amazon EC2 instances, into your VPC.
A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. Instances in either VPC can communicate with each other as if they are within the same network. You can create a VPC peering connection between your own VPCs, or with a VPC in another AWS account. The VPCs can be in different Regions (also known as an inter-Region VPC peering connection).
AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separate piece of physical hardware. There is no single point of failure for communication or a bandwidth bottleneck.
A VPC peering connection helps you to facilitate the transfer of data. For example, if you have more than one AWS account, you can peer the VPCs across those accounts to create a file sharing network. You can also use a VPC peering connection to allow other VPCs to access resources you have in one of your VPCs.
When you establish peering relationships between VPCs across different AWS Regions, resources in the VPCs (for example, EC2 instances and Lambda functions) in different AWS Regions can communicate with each other using private IP addresses, without using a gateway, VPN connection, or network appliance. The traffic remains in the private IP space. All inter-Region traffic is encrypted with no single point of failure, or bandwidth bottleneck. Traffic always stays on the global AWS backbone, and never traverses the public internet, which reduces threats, such as common exploits, and DDoS attacks. Inter-Region VPC peering provides a simple and cost-effective way to share resources between regions or replicate data for geographic redundancy.
Source: https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
You can create a peering connection as follows.
AWS –> VPC –> Peering connections –> click on Create peering connection
Here I will select both of my VPCs which are also in the same account.
I also need to accept the request on the accepter VPC.
You can also configure DNS for the peering connection to resolve hosts in the different VPC.
To enable private IPv4 traffic between instances in peered VPCs, you must add a route to the route tables associated with the subnets for both instances. The route destination is the CIDR block (or portion of the CIDR block) of the peer VPC and the target is the ID of the VPC peering connection. For more information, see Configure route tables in the Amazon VPC User Guide.
So in my case I will first edit the main route table from the requester VPC (braincourt.de). Here I will add the network CIDR block from the target peer VPC (Accepter VPC) which is 172.29.0.0/16.
For the target (next hop) I will have to select VPC peering connection.
Btw. you will see here also the propagated routes from my on-premise network over BGB and the IPSec Site-to-Site VPN tunnel. For them the target (next hop) is the virtual private gateway.
About how to set up a route based S2S VPN between your on-premise network and AWS VPC, you can read my following post.
Next I also need to edit the main route table from the accepter VPC (braintesting.de). Here I will add the network CIDR block from the target peer VPC (Requester VPC) which is 172.28.0.0/16.
For the target (next hop) I will have to select VPC peering connection.
From now on routing traffic between both VPCs should work. You can still control inbound and outbound traffic for your subnets by using the network ACLs associated to it as shown further above.
In order to allow ICMP Echo request and reply messages for your EC2 instances, you also have to allow them on the local windows firewall. By default they will be blocked even if allowed by the security groups.
In my following post you will see how routing in a Microsoft Azure VNet works in contrast.
Links
What is Amazon VPC?
https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.htmlExample routing options
https://docs.aws.amazon.com/vpc/latest/userguide/route-table-options.htmlAmazon VPC Routing Enhancements Allow You to Inspect Traffic Between Subnets In a VPC
https://aws.amazon.com/blogs/aws/inspect-subnet-to-subnet-traffic-with-amazon-vpc-more-specific-routing/Connect to the internet using an internet gateway
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.htmlWhy can’t my Amazon EC2 instance connect to the internet using an internet gateway?
https://aws.amazon.com/premiumsupport/knowledge-center/ec2-connect-internet-gateway/
