In the previous study note, we focused mainly on how AWS is organized from the infrastructure side and how you can organize your account(s) with users, groups, roles, and permissions. Now it’s time to dive into the Networking and Security network elements that AWS made available to isolate and connect IaaS infrastructure with managed services.
Amazon Virtual Private Cloud (Amazon VPC) enables you to launch AWS resources into a defined virtual network. This virtual network closely resembles a traditional network that operates in a physical data center, with the benefits of using the scalable infrastructure of AWS.
The following are the key concepts for VPCs:
- Virtual private cloud (VPC) — A virtual network dedicated to your AWS account.
- Subnet — A range of IP addresses in your VPC.
- Route table — A set of rules, called routes, that are used to determine where network traffic is directed.
- Internet gateway — A gateway that you attach to your VPC to enable communication between resources in your VPC and the internet.
- VPC endpoint — Enables you to privately connect your VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.
It is possible to access to create, access and manage a VPC via AWS Console, AWS CLI, AWS SDK, Query API.
Amazon VPC supports the processing, storage, and transmission of credit card data by a merchant or service provider, and has been validated as being compliant with Payment Card Industry (PCI) Data Security Standard (DSS)
There’s no additional charge for using a VPC. There are charges for the following VPC components: Site-to-Site VPN connection, PrivateLink, Traffic Mirroring, and a NAT gateway.
VPCs and subnets
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.
A subnet is a range of IP addresses in your VPC
To protect the AWS resources in each subnet, it’s possible to use multiple layers of security, including security groups and network access control lists (ACL).
Optionally it’s possible to associate an IPv6 CIDR block with your VPC and assign IPv6 addresses to the instances in the VPC.
If the account was created after 2013-12-04, it comes with a default VPC that has a default subnet in each Availability Zone. A default VPC has the benefits of the advanced features provided by EC2-VPC and is ready for you to use. The others new VPC created are non-default VPC.
When Amazon creates a default VPC, they do the following to set it up:
- Create a VPC with a size /16 IPv4 CIDR block (172.31.0.0/16). This provides up to 65,536 private IPv4 addresses.
- Create a size /20 default subnet in each Availability Zone. This provides up to 4,096 addresses per subnet, a few of which are reserved for internal use.
- Create an internet gateway and connect it to your default VPC.
- Create a default security group and associate it with your default VPC.
- Create a default network access control list (ACL) and associate it with your default VPC.
- Associate the default DHCP options set for your AWS account with your default VPC.
Note: IAM policies do not apply to these actions because you do not perform these actions. For example, if you have an IAM policy that denies the ability to call CreateInternetGateway, and then you call CreateDefaultVpc, the internet gateway in the default VPC is still created.
With a default VPC, it’s possible to perform the same actions as any other VPC like
- Add additional non-default subnets
- modify the main route table
- Add additional route tables
- Associate additional security groups;
- Update the rules of the default security group.
- Add AWS Site-to-Site VPN connections.
- Add more IPv4 CIDR blocks.
- Access VPCs in a remote Region by using a Direct Connect gateway. For information about Direct Connect gateway options, see Direct Connect gateways in the AWS Direct Connect User Guide.
By default, a default subnet is a public subnet, because the main route table sends the subnet’s traffic that is destined for the internet to the internet gateway. It’s possible to make a default subnet into a private subnet by removing the route from the destination 0.0.0.0/0 to the internet gateway. Obviously, no EC2 instance is able to access the Internet.
Instances that you launch into a default subnet receive both a public IPv4 address and a private IPv4 address, and both public and private DNS hostnames.
From time to time, AWS may add a new Availability Zone to a Region. In most cases, it’s automatically created a new default subnet in this Availability Zone for the default VPC within a few days.
If you created your AWS account after 2013-12-04, it supports only EC2-VPC and you have a default VPC in each AWS Region. If you created your AWS account before 2013-03-18, it supports both EC2-Classic and EC2-VPC in Regions that you’ve used before, and only EC2-VPC in Regions that you haven’t used. If you created your AWS account between 2013-03-18 and 2013-12-04, it may support only EC2-VPC. Alternatively, it may support both EC2-Classic and EC2-VPC in some of the Regions that you’ve used.
In case of the deletion of the default VPC, it’s possible to create a new one. Isn’t possible to restore a previous default VPC that you deleted, and you cannot mark an existing nondefault VPC as a default VPC.
The following are the key concepts for route tables.
- Main route table—The route table that automatically comes with your VPC. It controls the routing for all subnets that are not explicitly associated with any other route table.
- Custom route table—A route table that you create for your VPC.
- Edge association—A route table that you use to route inbound VPC traffic to an appliance. You associate a route table with the internet gateway or virtual private gateway, and specify the network interface of your appliance as the target for VPC traffic.
- Route table association—The association between a route table and a subnet, internet gateway, or virtual private gateway.
- Subnet route table—A route table that’s associated with a subnet.
- Gateway route table—A route table that’s associated with an internet gateway or virtual private gateway.
- Local gateway route table—A route table that’s associated with an Outposts local gateway.
- Destination—The range of IP addresses where you want traffic to go (destination CIDR). For example, an external corporate network with a
- Propagation—Route propagation allows a virtual private gateway to automatically propagate routes to the route tables. This means that you don’t need to manually enter VPN routes to your route tables.
- Target—The gateway, network interface, or connection through which to send the destination traffic; for example, an internet gateway.
- Local route—A default route for communication within the VPC.
The VPC has an implicit router and uses the route tables to control where network traffic is directed. Each subnet in the VPC must be associated with a route table, which controls the routing for the subnet (subnet route table). It’s possible to explicitly associate a subnet with a particular route table. Otherwise, the subnet is implicitly associated with the main route table.
Optionally it’s possible to associate a route table with an internet gateway or a virtual private gateway (gateway route table). This enables routing rules specification for inbound traffic that enters the VPC through the gateway.
Each route in a table specifies a destination and a target:
- Destination 0.0.0.0/0
- Target igw-12345678901234567
The destination for the route is
0.0.0.0/0, which represents all IPv4 addresses. The target is in this case, the internet gateway that’s attached to the VPC. (Use
::/0 for all IPv6 addresses)
When you create a VPC, it automatically has a main route table. The main route table controls the routing for all subnets that are not explicitly associated with any other route table. On the Route Tables page in the Amazon VPC console, you can view the main route table for a VPC by looking for Yes in the Main column.
By default, a custom route table is empty and you add routes as needed. When you use the VPC wizard in the console to create a VPC with an internet gateway, the wizard creates a custom route table and adds a route to the internet gateway.
Each subnet in your VPC must be associated with a route table. A subnet can be explicitly associated with a custom route table or implicitly or explicitly associated with the main route table.
You can associate a route table with an internet gateway or a virtual private gateway. When a route table is associated with a gateway, it’s referred to as a gateway route table. A gateway route table supports routes where the target is local (the default local route) or an elastic network interface (network interface) in your VPC that’s attached to your middlebox appliance.
You cannot associate a route table with a gateway if any of the following applies:
- The route table contains existing routes with targets other than a network interface or the default local route.
- The route table contains existing routes to CIDR blocks outside of the ranges in your VPC.
- Route propagation is enabled for the route table.
In addition, the following rules and considerations apply:
- You cannot add routes to any CIDR blocks outside of the ranges in your VPC, including ranges larger than the individual VPC CIDR blocks.
- You can only specify local or a network interface as a target. You cannot specify any other types of targets, including individual host IP addresses.
- You cannot specify a prefix-list as a destination.
- You cannot use a gateway route table to control or intercept traffic outside of your VPC, for example, traffic through an attached transit gateway. You can intercept traffic that enters your VPC and redirect it to another target in the same VPC only.
- To ensure that traffic reaches your middlebox appliance, the target network interface must be attached to a running instance. For traffic that flows through an internet gateway, the target network interface must also have a public IP address.
- When configuring your middlebox appliance, take note of the appliance considerations.
- When you route traffic through a middlebox appliance, the return traffic from the destination subnet must be routed through the same appliance. Asymmetric routing is not supported.
We use the most specific route in your route table that matches the traffic to determine how to route the traffic (longest prefix match).
If your route table references a prefix list, the following rules apply:
- If your route table contains a static route that overlaps with another route that references a prefix list, the static route with the destination CIDR block takes priority.
- If your route table contains a propagated route that overlaps with a route that references a prefix list, the route that references the prefix-list takes priority.
- If your route table references multiple prefix lists that have overlapping CIDR blocks to different targets, we randomly choose which route takes priority. Thereafter, the same route always takes priority.
- If the CIDR block in a prefix list entry is not valid for the route table, that CIDR block is ignored. For example, in a subnet route table, if the prefix-list contains an entry with a more specific CIDR than the VPC CIDR, that entry is ignored.
VPC connections and accesses
Your default VPC includes an internet gateway, and each default subnet is a public subnet. Each instance that you launch into a default subnet has a private IPv4 address and a public IPv4 address.
You can enable internet access for an instance launched into a nondefault subnet by attaching an internet gateway to its VPC (if its VPC is not a default VPC) and associating an Elastic IP address with the instance. Alternatively, to allow an instance in your VPC to initiate outbound connections to the internet but prevent unsolicited inbound connections from the internet, you can use a network address translation (NAT) device for IPv4 traffic. NAT maps multiple private IPv4 addresses to a single public IPv4 address.
An internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet. For further info check here: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html
An egress-only internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows outbound communication over IPv6 from instances in your VPC to the internet, and prevents the internet from initiating an IPv6 connection with your instances. For further info check here: https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html
You can use a NAT device to enable instances in a private subnet to connect to the internet (for example, for software updates) or other AWS services, but prevent the internet from initiating connections with the instances. For further info check here: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat.html
A Site-to-Site VPN connection consists of two VPN tunnels between a virtual private gateway or transit gateway on the AWS side, and a customer gateway device located in your data center. A customer gateway device is a physical device or software appliance that you configure on your side of the Site-to-Site VPN connection. For further info: https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html
A transit gateway is a network transit hub that you can use to interconnect your virtual private clouds (VPC) and on-premises networks. Further info here: https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html
AWS PrivateLink is a highly available, scalable technology that enables you to privately connect your VPC to supported AWS services, services hosted by other AWS accounts (VPC endpoint services), and supported AWS Marketplace partner services. You do not require an internet gateway, NAT device, public IP address, AWS Direct Connect connection, or AWS Site-to-Site VPN connection to communicate with the service. Traffic between your VPC and the service does not leave the Amazon network.
A VPC endpoint enables private connections between your VPC and supported AWS services and VPC endpoint services powered by AWS PrivateLink. A VPC endpoint does not require an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Further info here: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html.
You can create a VPC peering connection between two VPCs that enables you to route traffic between them privately. Instances in either VPC can communicate with each other as if they are within the same network.
AWS provides a high-performance and low-latency private global network that delivers a secure cloud computing environment to support your networking needs. AWS Regions are connected to multiple Internet Service Providers (ISPs) as well as to a private global network backbone, which provides improved network performance for cross-Region traffic sent by customers.