THE AWS CERTIFIED ADVANCED NETWORKING – SPECIALTY EXAM OBJECTIVES COVERED IN THIS CHAPTER MAY INCLUDE, BUT ARE NOT LIMITED TO, THE FOLLOWING:

• Domain 2.0: Design and implement AWS networks
•  2.1 Apply AWS networking concepts
• Domain 4.0: Configure network integration with application services
•  4.3 Determine the appropriate configuration of DHCP within AWS

 Amazon Virtual Private Cloud (Amazon VPC) allows customers to define a virtual network within the AWS Cloud. You can provision your own logically-isolated section of AWS, similar to designing and implementing a separate, independent network that would operate in an on-premises data center.

This chapter will review the core components of Amazon VPC that you learned by studying for the prerequisite exam. The exercises at the end of this chapter will refresh the skills required to build your own Amazon VPC in the cloud. A strong understanding of Amazon VPC technologies and troubleshooting is required to pass the AWS Certified Advanced Networking - Specialty exam, and we highly recommend that you complete the exercises in this chapter.

Introduction to Amazon Virtual Private Cloud (Amazon VPC)

Amazon VPC is the networking layer for Amazon Elastic Compute Cloud (Amazon EC2), and it allows you to build your own virtual network within an AWS Region. You control various aspects of your VPC, including selecting your own IP address range, creating your own subnets, and configuring your own route tables, network gateways, and security settings. You can create multiple VPCs within a region, and each VPC is logically isolated, even if it overlaps or shares IP address space with another VPC. You can launch AWS resources, such as Amazon EC2 instances, into your VPC.

When you create a VPC, you must assign an IPv4 address range by choosing a Classless Inter-Domain Routing (CIDR) block, such as 10.0.0.0/16. You may select any IPv4 address range, but Amazon VPC treats the CIDR block as private. Amazon will not advertise the network to the Internet. To connect with the Internet, or to enable communication between your resources and other AWS Cloud services that have Internet endpoints, you can assign a globally unique, public IPv4 address to your resource. The initially-assigned IPv4 address range of the VPC cannot be changed after the VPC is created. A VPC IPv4 address range may be as large as /16 (65,536 addresses) or as small as /28 (16 addresses), and it should not overlap any other network to which the VPC is to be connected.

You may optionally associate an IPv6 address range to your VPC. The IPv6 address range is a fixed size of /56 (4,722,366,482,869,645,213,696 addresses) and is assigned to your VPC from Amazon’s own IPv6 allocation. The IPv6 addresses that you receive from Amazon are Global Unicast Address (GUA) space. Amazon advertises GUAs to the Internet, so these IPv6 addresses are public. If an Internet gateway (discussed later in this chapter) is attached to your VPC, then the VPCs are reachable over the Internet.

Your VPC can operate in dual-stack mode. This means that resources in your VPC can communicate over IPv4, IPv6, or both. Because Amazon VPC is dual-stack, however, IPv4 and IPv6 operate independently. You will need to configure the routing and security components of your VPC for each address family. Table 2.1 provides a comparison of IPv4 and IPv6 for Amazon VPC.

To simplify the initial user experience with Amazon VPC, AWS accounts have a default VPC created in each region with a default subnet created in each Availability Zone. The assigned CIDR block of the VPC will be 172.31.0.0/16. IPv6 is not enabled on the default VPC.

Figure 2.1 illustrates a VPC with an address space of 10.0.0.0/16, two subnets with different address ranges (10.0.0.0/24 and 10.0.1.0/24) placed in different Availability Zones, and a route table with the local route specified.

An Amazon VPC consists of the following concepts and components:

• Subnets
• Route Tables
• IP Addressing
• Security Groups
• Network Access Control Lists (ACLs)
• Internet Gateways
• Network Address Translation (NAT) Instances and NAT Gateways
• Egress Only Internet Gateways (EIGWs)
• Virtual Private Gateways (VGWs), Customer Gateways, and Virtual Private Networks (VPNs)
• VPC Endpoints
• VPC Peering
• Placement Groups
• Elastic Network Interfaces
• Dynamic Host Configuration Protocol (DHCP) Option Sets
• Amazon Domain Name Service (DNS) Server
• VPC Flow Logs

Subnets

A subnet is a segment of a VPC that resides entirely within a single Availability Zone. While a VPC spans all Availability Zones in a region, a subnet cannot span more than one Availability Zone. You may create zero, one, or more subnets in each Availability Zone. When creating a subnet, you specify the target Availability Zone and allocate a contiguous block of IPv4 addresses from the VPC CIDR block. You launch Amazon EC2 resources, like Amazon Relational Database Service (Amazon RDS), into one or more subnets.

The maximum size of a subnet is determined by the size of the VPC IPv4 CIDR range. The smallest subnet that you can create is a /28 (16 IPv4 addresses). For example, if you created a VPC with IPv4 CIDR 10.0.0.0/16, you could create multiple subnets of /28. You could also create a single subnet in a single Availability Zone of size /16. AWS reserves the first four IPv4 addresses and the last IPv4 address of every subnet for internal networking purposes. For example, a subnet defined as a /28 has 16 available IPv4 addresses; subtract the 5 IPs needed by AWS to yield 11 IPv4 addresses for your use within the subnet.

If an IPv6 address block is associated with your Amazon VPC, you may optionally associate an IPv6 CIDR block to an existing subnet. Each IPv6 subnet is a fixed prefix length of /64, and the CIDR range is allocated from the VPC’s /56 CIDR block. When you specify the IPv6 subnet address range, you control the last 8 bits of the subnet’s IPv6 prefix, called the subnet identifier. Figure 2.2 shows how the hexadecimal (Hex) and binary (Bin) representations align with their use (Use). For example, if your VPC is assigned 2001:0db8:1234:1a00::/56, you specify the value of the low order 8 bits.

In Figure 2.2, Subnet 1 uses a subnet identifier of 00, which yields the CIDR 2001:db8:1234:1a00::/64. Note that IPv6 notation does not require that leading zeros are shown, so 2001:0db8::/56 and 2001:db8::/56 are equivalent. Additionally, any single, contiguous section of the address that is consecutive zeros can be notated with double colons (::).

You can disassociate an IPv6 CIDR block from a subnet if no IPv6 addresses are in use. If no subnets have an assigned IPv6 CIDR, you can also disassociate the IPv6 CIDR from your Amazon VPC. You can request a new IPv6 CIDR from Amazon at a later time.

For both IPv4 and IPv6, subnets can be classified as public, private, or VPN-only. Table 2.2 shows how these distinctions compare, using Figure 2.3 as an example. Regardless of the type of subnet, the internal IPv4 address range of the subnet is always private (namely, not announced by AWS on the Internet), and the internal IPv6 address range is always a GUA (that is, announced by AWS on the Internet).

Default VPCs contain one public subnet in every Availability Zone within the region, with a netmask of /20.

Route Tables

Each subnet within a VPC contains a logical construct called an implicit router. The implicit router is the next hop gateway on a subnet where routing decisions are made. These routing decisions are governed by a route table, which includes a set of route entries. You can create custom route tables to define specific routing policies. Custom route tables may be associated with one or more subnets. Your VPC also contains a “main” route table that you can modify. The main route table is used for all subnets that are not explicitly associated with a custom route table.

Each route table entry, or route, consists of a destination and a target. The destinations for your route tables are either CIDR blocks or, in the case of VPC gateway endpoints (discussed later in this chapter), prefix lists. Targets of your route table can include Internet gateways, NAT gateways, egress-only Internet gateways (EIGWs), virtual private gateways (VGW), VPC gateway endpoints, VPC peers, and elastic network interfaces.

Each route table has one or more local route entries associated with the IPv4 and IPv6 CIDR blocks configured for your VPC. Every route table has an entry for the defined CIDR ranges with a target of “Local,” and these entries cannot be removed. You cannot add a more specific route to your route table than the local route. The local route table entries ensure that all resources in your VPC have a route to one another.

When the implicit router receives a packet, the next hop target is determined by a specific route priority. The route table includes local, static, and dynamic routes. The route for the VPC CIDR block is local. Explicitly configured routes are static. Dynamic routes originate through route propagation from a VGW (discussed later in this chapter). Table 2.3 describes the route priority order. Recall that Amazon VPC operates IPv6 in a dual-stack mode, meaning that routing evaluations are executed independently for IPv4 and IPv6.

You should remember the following points about route tables:

• Your VPC has an implicit router.
• Your VPC automatically comes with a main route table that you can modify.
• You can create additional custom route tables for your VPC.
• Each subnet is associated with a route table, which controls the routing for the subnet. If you don’t explicitly associate a subnet with a particular route table, the subnet uses the main route table.
• You can set a custom route table as the main route table so that new subnets are automatically associated with it.
• Each route in a table specifies a destination CIDR and a target; for example, traffic destined for 172.16.0.0/12 is targeted for the VGW.
• AWS uses a predefined route priority process to determine how to route the traffic.

IP Addressing

Resources in your VPC use IP addresses to communicate with each other and with resources over the Internet. Amazon EC2 and Amazon VPC support both IPv4 and IPv6 addressing protocols.

Amazon EC2 and Amazon VPC require you to use the IPv4 addressing protocol. When you create a VPC, you must assign it an IPv4 CIDR block. Amazon EC2 features like instance metadata and the Amazon DNS Server require the use of IPv4.

The IPv4 CIDR block that you allocate to your VPC is considered a private IPv4 address range by Amazon, regardless of whether or not the address block is routable on the Internet. To connect your instance to the Internet, or to enable communication between your instances and other AWS Cloud services that have public endpoints, assign public IPv4 addresses. There are multiple ways to assign public IPv4 addresses, and these methods are covered in this section.

You can optionally associate an IPv6 CIDR block with your VPC and subnets and assign IPv6 addresses from that block to the resources in your VPC. IPv6 addresses are public and reachable over the Internet. There are multiple types of IPv6 addresses. This section of the guide covers the types of IPv6 addresses and the methods used to assign IPv6 addresses to your Amazon EC2 instances.

IPv6 Addresses

The IPv6 protocol uses a variety of addresses for operation. For the exam, you should understand Link-Local Addresses (LLAs) and GUAs. LLAs are addresses from the reserved fe80::/10 IPv6 CIDR block. The LLA is a required “on-link” address used for a variety of IPv6 processes, including DHCPv6 and Neighbor Discovery Protocol. Think of the latter as the IPv6 version of IPv4’s Address Resolution Protocol.

The implicit router in your VPC is accessible through its LLA. Amazon VPC expects the LLA of a given interface to conform with the modified EUI-64 format in which the 48-bit MAC address of the elastic network interface is converted into a 64-bit interface ID. As shown in Figure 2.4, the modified EUI-64 address is created by flipping the seventh-most significant bit and inserting FF:FE into the address. The LLA is significant only to the link, or VPC subnet, on which the elastic network interface resides. LLA packet processing is enabled on your elastic network interface when you assign it a GUA.

Amazon maintains large IPv6 GUA allocations from Regional Internet Registries (RIRs). To communicate with the Internet over IPv6, your instance must use an Amazon GUA. To receive a GUA, associate an IPv6 block from Amazon’s public IPv6 pool with your VPC. Amazon will allocate to you a fixed-size /56 CIDR block for your VPC. Then, associate a fixed-size /64 IPv6 CIDR block to each subnet that requires IPv6. While you have no control over the /56 address allocation to your VPC, you assign the low-order byte of /64 IPv6 subnets. In subnets with IPv6 addresses, you can assign IPv6 addresses to your elastic network interfaces.

There are two ways to assign IPv6 addresses to your elastic network interface. You may assign the addresses automatically or manually at launch or after launch. Similar to IPv4, you can configure an attribute on your subnet to assign an IPv6 address automatically to new elastic network interfaces created in a given subnet. This attribute has the effect of automatically assigning an IPv6 GUA to your instance at launch. As with IPv4, you are able to override this attribute at launch. If you prefer to assign the value of the IPv6 GUA manually, you may specify the IPv6 address at launch to override automatic address assignment. Running instances may receive IPv6 addresses as well. When you assign an IPv6 address to a running instance, you can specify the IPv6 address or allow Amazon VPC to select an IPv6 address automatically for you.

Security Groups

A security group is a stateful virtual firewall that controls inbound and outbound network traffic to AWS resources and Amazon EC2 instances. All Amazon EC2 instances are launched with a security group. If a security group is not specified at launch, then the instance will be launched with the default security group for the VPC in which it is launched. An unmodified, default security group allows communication between all resources within the security group, and it allows all outbound traffic; all other traffic is denied implicitly. You may change the rules for the default security group, but you may not delete the default security group. Table 2.4 describes the settings of the default security group.

For each security group, you add rules that control the inbound traffic to instances and a separate set of rules that control the outbound traffic. For example, Table 2.5 describes a security group for web servers.

If your VPC has a peering connection with another VPC in the same region, you can reference security group IDs from the peer VPC. This allows you to create security groups that automatically accommodate changes in the peer network, including Auto Scaling events. If the peer VPC deletes a referenced security group, the rule in your security group is marked as stale.

Here are the important points to understand about security groups for the exam:

• You can create up to 500 security groups for each VPC.
• You can add up to 50 inbound and 50 outbound rules to each security group.
• You can associate up to five security groups with each network interface.
• You can specify allow rules but not deny rules. This is an important difference between security groups and network ACLs.
• You can specify separate rules for inbound and outbound traffic.
• By default, no inbound traffic is allowed until you add inbound rules to the security group.
• By default, new security groups have an outbound rule that allows all outbound traffic. You can remove the rule and add outbound rules that allow specific outbound traffic only.
• Security groups are stateful. This means that responses to allowed inbound traffic are allowed to flow outbound regardless of outbound rules and vice versa. This is an important difference between security groups and network ACLs.
• Instances associated with the same security group cannot communicate with each other unless you add rules to the security group allowing the security group to communicate within itself.
• You can change which security groups an instance is associated with after launch, and the changes will take effect in seconds.

Network Access Control Lists (ACLs)

A network ACL is another layer of security that acts as a stateless firewall on a subnet level. A network ACL is an ordered list of rules that AWS evaluates, starting with the lowest numbered rule, to determine whether traffic is allowed in or out of any subnet associated with the network ACL. Each network ACL has a final deny all rule that you cannot change. VPCs are created with a modifiable default network ACL associated with every subnet. The default network ACL allows all inbound and outbound traffic for IPv4. When you create a custom network ACL, its initial configuration will deny all inbound and outbound traffic until you create rules that allow otherwise. You may set up network ACLs with rules similar to your security groups in order to add another layer of security to your VPC, or you may choose to use the default network ACL that does not filter traffic traversing the subnet boundary. Every subnet must be associated with a network ACL. If you associate an IPv6 CIDR block with your VPC, Amazon automatically adds rules that allow all inbound and outbound IPv6 traffic.

Table 2.6 explains the differences between a security group and a network ACL. You should remember the following differences for the exam.

Internet Gateways

An Internet gateway is a horizontally-scaled, redundant, and highly available Amazon VPC component that allows communication between instances in your VPC and the Internet. An Internet gateway is a target in your VPC route tables for Internet-routable traffic.

In the case of IPv4, when traffic is sent from the instance to the Internet, the Internet gateway translates any private source IPv4 address to the associated public IPv4 address. An Amazon EC2 instance can receive a public IPv4 address either automatically at launch or dynamically using an IPv4 Elastic IP address. The Internet gateway maintains the one-to-one mapping of the instance’s private IPv4 address and public IPv4 address. When an instance receives traffic from the Internet, the Internet gateway translates the destination address (public IPv4 address) to the instance’s private IPv4 address, as appropriate, and forwards the traffic to the VPC.

Because your IPv6 addresses are allocated from Amazon’s GUA blocks, Amazon EC2 instances within a VPC are aware of their public IPv6 addresses. When traffic is sent from the instance to the Internet, the Internet gateway forwards the instance’s source IPv6 address unchanged. When an instance receives traffic from the Internet, the Internet gateway forwards the traffic to the Amazon EC2 destination instance with the matching GUA.

You must do the following to create a public subnet with Internet access:

• Create and attach an Internet gateway to your VPC.
• Create a route in the associated subnet route table to send non-local traffic (0.0.0.0/0 for IPv4 or ::/0 for IPv6) to the Internet gateway.
• Configure your network ACLs and security group rules to allow relevant traffic to flow to and from your instance.

You must do the following to enable an Amazon EC2 instance to send and receive traffic from the Internet:

• Assign a public IPv4 or Elastic IP address.
• Assign an IPv6 GUA.

You can specify a default route (0.0.0.0/0 for IPv4 or ::/0 for IPv6), or you can scope the route to a specific range of IP addresses. For example, you can define a route limited to the public IP addresses of your company’s endpoints outside of AWS.

Figure 2.5 illustrates a VPC with an IPv4 CIDR of 10.0.0.0/16, one subnet with an address range of 10.0.0.0/24, a route table, an attached Internet gateway, and a single Amazon EC2 instance with a private IPv4 address and an Elastic IP address. The route table contains two routes: the local route that permits intra-VPC communication and a default route that sends all non-local traffic to the Internet gateway (igw-id). Note that the Amazon EC2 instance has a public IPv4 address (Elastic IP address = 198.51.100.2); this instance can be accessed from the Internet, and traffic may originate from and return to this instance.

Network Address Translation (NAT) Instances and NAT Gateways

By definition, any instance that you launch into a private subnet in a VPC is not able to communicate directly with the Internet through an Internet gateway. That is, the subnet route table includes no routes to an Internet gateway. More importantly, connections originating from outside your VPC cannot reach instances inside your private subnet. IPv4 instances within private subnets may require outbound access to the Internet in order to apply security patches, update application software, or make Application Programming Interface (API) calls to Internet endpoints. AWS provides NAT instances and NAT gateways to allow IPv4 instances deployed in private subnets to gain outbound Internet access. For common use cases, we recommend that you use a NAT gateway rather than a NAT instance. The NAT gateway provides better availability, provides higher bandwidth, and requires less administrative effort than NAT instances. Note that although we use the term NAT to describe these two offerings, both NAT instances and NAT gateways perform many-to-one IPv4 translation, called Port Address Translation (PAT).

NAT is not supported for IPv6. One of the goals of the IPv6 protocol is to provide end-to-end connectivity. To create a private IPv6 subnet, see the section on the egress-only Internet gateway.

Egress-Only Internet Gateways (EIGWs)

One of the goals of the IPv6 protocol is to provide end-to-end connectivity. As such, Amazon does not support NAT, or Network Prefix Translation, for IPv6. Each instance that is enabled for IPv6 packet processing has at least one GUA. As the name implies, these addresses are unique and global in scope and are public, routable IPv6 addresses.

You probably have Amazon EC2 instances that should not be accessible from the Internet. With IPv4, this protection is accomplished in your VPC by creating a private subnet with a NAT instance or NAT gateway.

In order to provide a semantically similar experience to NAT for IPv6, Amazon created the egress-only Internet gateway (EIGW). The EIGW is a horizontally-scaled, redundant, and highly-available VPC component that allows outbound communication over IPv6 from your instances to the Internet. It prevents traffic originating on the Internet from connecting to your instances, however. Unlike a NAT instance or a NAT gateway, the EIGW performs no address translation function. The instance IPv6 address is visible end to end.

For the exam, you must understand the dual-stack nature of the Amazon VPC IPv6 implementation. When configuring a private subnet where instances need to communicate with the Internet, the IPv4 default route (destination) in the subnet’s associated route table will point to (target) a NAT instance or NAT gateway. In turn, the NAT instance or NAT gateway will reside within a public subnet with a default route pointing to an Internet gateway. For IPv6, that same route table for your private subnet will include a default route pointing to an EIGW attached to the VPC. Figure 2.6 shows a private subnet where IPv4 traffic is confined to the VPC but IPv6 traffic originating from within the VPC may access the Internet.

Virtual Private Gateways (VGWs), Customer Gateways, and Virtual Private Networks (VPNs)

You can connect an existing data center to your VPC using either hardware or software VPN connections. Both options make the VPC an extension of your data center. To create a VPN using AWS-provided VPN hardware, configure a virtual private gateway, a customer gateway, and a VPN connection.

The virtual private gateway (VGW) is a logical construct in your VPC that provides edge routing for AWS managed VPN connections and AWS Direct Connect (discussed later). For the exam, it is important that you understand that the VGW manages edge routing information that is separate from your VPC route tables. It is conceptually a next-hop router. To use AWS managed VPN connections, you must create and attach a VGW to your VPC.

A customer gateway represents the physical device or software application on the remote end of the VPN connection. The customer gateway must have a static IPv4 address. The customer gateway may reside behind a device performing NAT. You define the customer gateway in your VPC.

Once the VGW and the customer gateway have been created, the last step is to create a VPN connection. VPN tunnel negotiation must be initiated by the customer gateway. After the tunnel is negotiated and established, traffic can route over the tunnel. Figure 2.7 illustrates a single VPN connection between a corporate network and a VPC.

A single VPN connection consists of two Internet Protocol Security (IPsec) tunnels for high availability to the VPC. Amazon performs maintenance on the VPN from time to time. This maintenance may disable one of the two tunnels briefly.

You must specify the type of routing that you plan to use when you create a VPN connection. If the customer gateway supports Border Gateway Protocol (BGP), configure the VPN connection for dynamic routing. Otherwise, configure the connections for static routing. If you will be using static routing, you must enter the routes for your network that should be communicated to the VGW. To allow your resources to route traffic back to the corporate network through the VGW and across the VPN tunnel, you configure route propagation from or static routes to the VGW. There is further discussion of VPN options in Chapter 4, “Virtual Private Networks.”

Amazon will provide the information needed by the network administrator to configure the customer gateway and establish the VPN connection with the VGW.

A software VPN connection is established with your VPC when you launch an Amazon EC2 instance running VPN software. In this scenario, your instance must have a public IPv4 address, be accessible from the Internet, and have the correct ports and protocols enabled in the security group. You must also disable the Source/Destination Check attribute on the Amazon EC2 instance. Once configured, you update the relevant route tables to forward the appropriate destination networks to the target instance’s elastic network interface. When using an instance-based, software VPN endpoint, you are responsible for scalability, availability, and performance.

Here are the important points to understand about VGWs, customer gateways, and VPNs for the exam:

• The VGW is the AWS end of the VPN connection.
• The customer gateway is a hardware or software application on the remote end of the VPN connection.
• You must initiate the VPN tunnel from the customer gateway to the VGW.
• VGWs support both dynamic routing with BGP and static routing.
• The VPN connection consists of two tunnels for high availability to the VPC.

VPC Endpoints

A VPC endpoint enables you to connect your VPC privately to supported AWS services and VPC endpoint services (powered by AWS PrivateLink) without requiring an Internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. VPC endpoints are horizontally-scaled, redundant, and highly available. There are two types of VPC endpoints: interface and gateway. Interface endpoints (powered by AWS PrivateLink) use an elastic network interface in your VPC with a private IP address that serves as an entry point for traffic destined to a supported service. Gateway endpoints use a route table target for a specified route in your route table for supported services. Endpoints allow resources in your VPC to use their private IPv4 addresses to communicate with resources outside of their VPC. Resources in your VPC do not need public IPv4 addresses. Moreover, traffic between your VPC and the endpoint does not leave the Amazon network.

Gateway endpoints currently support communication with Amazon Simple Storage Service (Amazon S3) and Amazon DynamoDB. Interface endpoints support Amazon Kinesis Streams, Elastic Load Balancing API, Amazon EC2 API, Amazon EC2 Systems Manager (SSM), AWS Service Catalog, Endpoint services hosted by other accounts, and supported Marketplace partner services. Chapter 3, “Advanced Amazon Virtual Private Cloud (Amazon VPC),” covers endpoints services in more detail. Additional AWS Cloud services are expected to be added in the future.

Figure 2.8 shows an example route table (Subnet 1) that routes all Internet traffic (0.0.0.0/0) to an Internet gateway. Any traffic from the subnet that is destined for another AWS Cloud service (for example, Amazon S3 or Amazon DynamoDB) will be sent to the Internet gateway in order to reach that service.

Figure 2.8 also shows an example route table (Subnet 2) that directs traffic from the subnet that is destined for Amazon S3 in the same region to the gateway endpoint.

When using gateway endpoints for Amazon S3, you can further refine access control by creating bucket policies that use the VPC endpoint data. Using a VPC endpoint, your Amazon S3 bucket policy can allow access based on a VPC identifier or on a specific VPC endpoint identifier. Amazon S3 bucket policies do not, however, support policies based on IP addresses when using a VPC endpoint. Since you can create multiple VPCs with overlapping IP addresses, an IP-based bucket policy for evaluating VPC endpoints does not add any real measure of security.

VPC Peering

A VPC peering connection is a networking connection between two VPCs that enables instances in either VPC to communicate with each other as if they were within the same network. You can create a VPC peering connection between your own VPCs or with a VPC in another AWS account. VPC peering is supported in the same region or to another region within the same Amazon partition. Amazon provides encryption for VPC peer traffic between regions. A peering connection is neither a gateway nor an Amazon VPN connection, and it does not introduce a single point of failure for communication.

Resources within the AWS Cloud are each given a unique Amazon Resource Name (ARN). These ARNs are used in various ways, including the construction of Identity and Access Management (IAM) policies. The first element of an ARN is the partition. Partitions allow Amazon to group regions with common, but distinct, operational requirements into isolated administrative domains. Standard AWS Regions use the partition aws. Resources in China use the partition aws-cn. Resources in the AWS GovCloud (US) Regions use aws-us-gov.

Peering connections are created through a request/accept protocol. The owner of the initiating VPC sends a request to peer to the owner of the peer VPC. If the peer VPC is within the same account, it is identified by its VPC ID. If the peer VPC is within a different account, it is identified by account ID and VPC ID. The owner of the peer VPC has seven days either to accept or reject the request to peer with the requesting VPC before the peering request expires.

Once a VPC peer is established, both sides of the peer must add routes for the respective peer. Each route entry will use the peer connection ID (pcx-xxxxxxxx) as the target. If routes are not added, the VPC implicit router will not pass traffic across the peer. In Figure 2.9, VPC A would add routes to 10.0.0.0/16 through the peer connection. VPC B would add routes to 172.16.0.0/16 through the peer connection.

A VPC may have multiple peering connections. Peering is a one-to-one relationship between VPCs, meaning that two VPCs cannot have two peering agreements between them. In addition, peering connections do not support transitive routing, as depicted in Figure 2.9.

In Figure 2.9, VPC A has two peering connections with two different VPCs: VPC B and VPC C. Therefore, VPC A can communicate directly with VPC B and VPC C. Because peering connections do not support transitive routing, VPC A cannot be a transit point for traffic between VPC B and VPC C. In order for VPC B and VPC C to communicate with each other, a peering connection must be explicitly created between them.

If a peer is established within the same region, you can reference security groups in the peer VPC. Similarly, if a peer is established within the same region, you can enable DNS hostname resolution for the peer VPC. By default, if instances use the public DNS hostname of an instance in a peer VPC, the public IPv4 address is returned. Traffic to the instance flows over an Internet gateway. When DNS resolution is enabled on the peer, the private IPv4 address of the instance is returned instead. Traffic flows over the peer connection. Each VPC must enable DNS hostnames, local DNS resolution, and allow DNS resolution from the peering VPC. For IPv6, only public GUAs are used by Amazon VPC and Amazon EC2; therefore, traffic will flow through the peer connection, provided that the route tables are properly configured.

Here are the important points to understand about peering for the exam:

• You cannot create a peering connection between VPCs that have matching or overlapping CIDR blocks.
• Peering connections are confined to the same Amazon partition.
• Peers within the same region may reference security groups in the peer VPC.
• Peers within the same region may enable hostname resolution to receive private IPv4 addresses for peer instances.
• Amazon encrypts traffic between peers in different regions.
• VPC peering connections do not support transitive routing.
• You cannot have more than one peering connection between the same two VPCs at the same time.
• For certain applications (for example, web services), it may be more beneficial to use VPC endpoints. VPC peering will generally offer wider access to subnets and CIDR ranges. VPC endpoints allow connectivity between VPCs for specific applications. Jumbo frames are supported only between peers in the same region. IPv6 is supported only between peers in the same region.

Placement Groups

Placement groups are logical groupings of instances within a single Availability Zone. Instances in the placement group are proximate in the Amazon network infrastructure, delivering low-latency, high packet-per-second performance, and high network throughput. Placement groups are appropriate for workloads like High Performance Computing (HPC) when internode network performance is important. We recommend that you use instance types with enhanced networking (discussed later in Chapter 9, “Network Performance”) in your placement group.

Since a placement group causes instances to colocate in a section of the Amazon infrastructure, it is recommended that you start the number of instances that you need in a single launch. While it is possible to add and remove instances from a placement group, you run the risk that additional capacity may not be available in the section of the Amazon network where the placement group resides.

Here are important points to understand about placement groups for the exam:

• Placement groups are confined to a single Availability Zone.
• Maximum network throughput between any two instances is limited to the slowest instance.
• Network traffic outside of the placement group is limited to 25 Gbps for Amazon EC2 and Amazon S3 in the same region. Other traffic is limited to 5 Gbps.
• Placement groups support both IPv4 and IPv6.

Further information about placement groups is available in Chapter 9.

Elastic Network Interfaces

An elastic network interface is a virtual network interface that you can attach to an instance in a VPC. Elastic network interfaces are only available within a VPC and are associated with a subnet upon creation. Each elastic network interface has a primary IPv4 private address, a MAC address, and at least one security group. An elastic network interface may optionally have secondary private IPv4 addresses, one or more Elastic IP addresses, one public IPv4 address, and one or more IPv6 addresses. Attaching a second elastic network interface to an Amazon EC2 instance allows it to have network presence in different subnets. An elastic network interface created independently of a particular instance persists regardless of the lifetime of the instance to which it is attached; if an underlying instance fails, the IP address may be preserved by attaching the elastic network interface to a replacement instance. You cannot, however, detach the primary network interface of an Amazon EC2 instance.

Multiple elastic network interfaces allow you to use network and security appliances in your VPC, create dual-homed instances with workloads/roles on distinct subnets, or create a low-budget, high-availability solution. Elastic network interfaces can be attached to an instance while running (hot attach), when stopped (warm attach), or at launch (cold attach). However, multiple elastic network interfaces cannot be used for NIC teaming.

The maximum number of elastic network interfaces per instance and the number of IPv4 or IPv6 addresses supported on the elastic network interface vary based on the Amazon EC2 instance type.

Here are some important items to know about elastic network interfaces for the exam:

• Elastic network interfaces must have a primary, private IPv4 address and are always associated with at least one security group.
• Elastic network interfaces can be attached to an instance while running (hot attach), when stopped (warm attach), or at launch (cold attach).
• You cannot detach the primary network interface.
• An elastic network interface is confined to a single Availability Zone. When attaching multiple elastic network interfaces to an Amazon EC2 instance, the instance and the elastic network interfaces must all be in the same Availability Zone.
• NIC teaming cannot be used to increase bandwidth to or from an Amazon EC2 instance.

Dynamic Host Configuration Protocol (DHCP) Option Sets

Dynamic Host Configuration Protocol (DHCP) is a standard for passing configuration information to hosts on an IP network. The options field of a DHCP message contains the configuration parameters. Some of those parameters are the domain name, domain name server, and the NetBIOS node type.

AWS automatically creates and associates a DHCP option set for your VPC upon creation and sets two options:

• domain-name-servers: This defaults to AmazonProvidedDNS.
• domain-name: This defaults to the internal Amazon domain name for your region.

AmazonProvidedDNS is the Amazon DNS server. Amazon DNS, when enabled, allows Amazon EC2 instances to resolve domain names for destinations on the Internet and in a VPC peer in the same region.

The DHCP option sets of a VPC allow you to change how host and domain names are assigned to your Amazon EC2 resources. To assign your own domain name to your instances, create a custom DHCP option set and assign it to your VPC. You can configure the following values within a DHCP option set:

• domain-name-servers: The IP addresses of up to four domain name servers, separated by commas.
• domain-name: Specify the desired domain name (for example, mycompany.com).
• ntp-servers: The IP addresses of up to four Network Time Protocol (NTP) servers, separated by commas.
• netbios-name-servers: The IP addresses of up to four NetBIOS name servers, separated by commas.
• netbios-node-type: Set this value to 2.

Each VPC must have exactly one DHCP option set assigned to it.

Amazon Domain Name Service (DNS) Server

The Domain Name Service provides a standard mechanism to resolve a hostname to an IP address. Amazon VPC provides an integrated DNS server. DNS service and Amazon EC2 hostname resolution for instances within your VPC are enabled by default when your VPC is created using the console wizard. The Amazon VPC attribute enableDnsSupport determines whether or not the Amazon DNS server is enabled for your VPC. The Amazon VPC attribute enableDnsHostnames determines whether Amazon EC2 instances receive hostnames.

The Amazon DNS server runs on a reserved IP address at the base of the VPC IPv4 CIDR range, plus two. For example, the DNS server for a VPC using 172.16.0.0/16 is available from 172.16.0.2. The Amazon DNS server is also available at 169.254.169.253. The Amazon DNS server can integrate with Amazon Route 53 private hosted zones and AWS Directory Service (both described in Chapter 6, “Domain Name System and Load Balancing.”

If the domain-name-servers in your DHCP options is set to use the Amazon DNS server, your Amazon EC2 instance is assigned a private Fully Qualified Domain Name (FQDN) for the instance IPv4 address. If a public IPv4 address is assigned to the instance, a public FQDN is assigned as well. When instances within the VPC query the Amazon DNS server using the public FQDN of another instance within the VPC, the Amazon DNS server returns in the private IPv4 address. You can enable this same behavior between VPC peers in the same region.

Note that some AWS Cloud services, including Amazon EMR, require instances to resolve their own FQDN.

VPC Flow Logs

VPC Flow Logs is a feature of Amazon VPC that captures IP traffic flow information in your VPC. The flow data is stored in Amazon CloudWatch Logs. VPC Flow Logs can be enabled at the VPC, subnet, or network interface level. The logs are published approximately every 10 minutes. Table 2.7 indicates the information collected in the logs.

VPC Flow Logs are useful for a number of reasons, including anomaly detection and troubleshooting. Anomaly detection is covered in Chapter 8, “Network Security.” Logs are useful for troubleshooting as well. For example, when a record appears twice in the log for a packet inbound from the Internet to an Amazon EC2 instance, once with an ACCEPT action and once with a REJECT action, you will know that the network ACL was passed but the security group failed. The log shows this behavior because network ACLs are evaluated for traffic into a subnet before the security group of the target instance is evaluated.

VPC Flow Logs do not collect information in certain cases:

• Amazon EC2 instances communicating with the Amazon DNS server.
• Windows instances communicating with the Amazon Windows license activation server.
• Traffic to and from 169.254.169.254 for instance metadata.
• DHCP traffic.
• Traffic destined to the implicit router.

Summary

In this chapter, you reviewed core concepts of Amazon VPC and Amazon EC2. In its simplest form, Amazon VPC allows you to create your own private virtual network within the AWS Cloud. You can provision your own logically-isolated section of AWS in a way that is similar to designing and implementing a separate, independent network in a physical data center. Once your VPC is created, you can launch resources into your private network.

The core components of a VPC are as follows:

• Dynamic Host Configuration Protocol (DHCP) option sets
• IPv4
• Network access control lists (ACLs)
• Route tables
• Security groups
• Subnets

A VPC has the following optional components:

• Amazon Domain Name Service (DNS) server
• Elastic network interfaces
• Gateways (Internet gateway, EIGW, NAT gateway, VGW, and customer gateway)
• Virtual Private Networks (VPNs)
• IPv6
• NAT instances
• Placement groups
• VPC endpoints
• VPC Flow Logs
• VPC peering

Subnets can be public, private, or VPN-only. A public subnet is one in which the associated route table directs the subnet’s traffic to the VPC’s Internet gateway. A private subnet is one in which the associated route table does not direct the subnet’s traffic to the VPC’s Internet gateway. A VPN-only subnet is one in which the associated route table directs the subnet’s traffic to the VPC’s VGW and does not have a route to the Internet. Regardless of the type of subnet, the internal IPv4 address range of the subnet is private, and the internal IPv6 address range is an AWS-provided GUA.

Each subnet within a VPC contains a logical construct called an implicit router. The implicit router is the next hop gateway on a subnet where routing decisions are made. These routing decisions are governed by a route table. You can create custom route tables to define specific routing policies. Custom route tables may be associated with one or more subnets. Your VPC also contains a “main” route table that you can modify. The main route table is used for all subnets that are not explicitly associated with a custom route table. Each route table has one or more local routes that specify the IPv4 and IPv6 CIDR blocks associated with your VPC.

An Internet gateway provides a VPC gateway to the Internet. Internet gateways allow traffic originating from the Internet to reach Amazon EC2 instances with public IPv4 or IPv6 addresses. NAT gateways and NAT instances allow IPv4 traffic originating from within a subnet to reach the Internet. Traffic from the Internet cannot reach the Amazon EC2 instances behind a NAT gateway or NAT instance. Similarly, EIGWs allow IPv6 traffic originating from within a subnet to reach the Internet without allowing traffic inbound that originates from the Internet.

A VGW connects to the VPN endpoints on the AWS side of a VPN connection. A customer gateway is a physical device or a software application on the customer’s side of the VPN connection. Once these two elements of a VPC have been created, the last step is to create a VPN connection. Each Amazon VPN connection consists of two tunnels for high availability. A tunnel is established after traffic is generated from the remote end of the VPN connection the tunnel is negotiated.

A VPC endpoint enables you to create a private connection between your VPC and another AWS Cloud service or VPC without requiring access over the Internet or through a NAT instance, VPN connection, or AWS Direct Connect.

A VPC peering connection is a networking connection between two VPCs that enables instances in either VPC to communicate with each other as if they were within the same network. You can create a VPC peering connection between your own VPCs or with an VPC in another AWS account within an Amazon partition. VPC peering can also be used across regions. A peering connection is neither a gateway nor a VPN connection and does not introduce a single point of failure for communication. Peering connections in the same region can share security groups and DNS hostname resolution.

A security group is a virtual stateful firewall that controls inbound and outbound traffic to Amazon EC2 instances. When you first launch an Amazon EC2 instance into a VPC, you will specify the security group with which it will be associated or the default security group that will be applied. The default security group allows all instances associated with the default security group to communicate with each other and allow all outbound traffic. You may change the rules for the default security group, but you may not delete the default security group.

A network ACL is another layer of security that acts as a stateless firewall on a subnet level. VPCs are created with a modifiable default network ACL that is associated with every subnet, and it allows all inbound and outbound traffic. The default network ACL allows all inbound and outbound traffic. If you want to create a custom network ACL, its initial configuration will deny all inbound and outbound traffic until you create a rule that states otherwise.

Placement groups allow you to launch Amazon EC2 instances that are close to one another on the Amazon infrastructure. This network proximity allows for high-bandwidth, high packet-per-second, and high-throughput performance. Placement groups are particularly relevant for workloads with strict performance tolerances, like HPC.

An elastic network interface is a virtual network interface that you attach to an instance in a VPC. Each elastic network interface has a primary IPv4 private address, a MAC address, and at least one security group. Attaching a second elastic network interface to an Amazon EC2 instance allows it to be dual-homed. An elastic network interface created independently of a particular instance persists regardless of the lifetime of the attached instance; if an underlying instance fails, the IP address may be preserved by attaching the elastic network interface to a replacement instance. You cannot detach the primary network interface of an Amazon EC2 instance.

Amazon VPC supports both IPv4 and IPv6 addresses. You select an IPv4 CIDR between /16 and /28 when you create your VPC. An Elastic IP address is a static, public IPv4 address that you can allocate to your account from a regional IPv4 pool and release back into the regional IPv4 pool. Elastic IP addresses allow you to maintain a set of IP addresses that remain fixed while the underlying infrastructure may change over time. You may optionally associate an IPv6 CIDR of size /56 from Amazon’s GUA space to your Amazon VPC. You must enable IPv6 on your VPC, subnet, and Amazon EC2 instance to use the protocol.

The DHCP option sets element of a VPC allows you to direct Amazon EC2 hostname assignment to your own resources. In order for you to assign your own domain name to your instances, you create a custom DHCP option set and assign it to your VPC.

The Amazon DNS server provides DNS resolution within the Amazon VPC. Amazon DNS integrates with Amazon Route 53 and AWS Directory Service. When two VPCs within the same region are peered, you can enable DNS resolution for Amazon EC2 instances across the peering.

VPC Flow Logs provide a periodic view of network flow information. Log data is pushed to Amazon CloudWatch Logs approximately every 10 minutes. VPC Flow Logs are useful for understanding network traffic, including anomaly detection and troubleshooting.

Resources to Review

For further review, check out the following URLs:

• Amazon EC2: https://aws.amazon.com/documentation/ec2/
• Amazon VPC: https://aws.amazon.com/documentation/vpc/

Exam Essentials

Understand what a VPC is and its core and optional components. A VPC is a logically isolated network in the AWS Cloud. A VPC is made up of the following core elements: subnets (public, private, and VPN-only), route tables, security groups, network ACLs, IPv4, and DHCP option sets. Optional elements include gateways (Internet gateways, EIGW, NAT gateway, VGW, and customer gateway), Virtual Private Networks (VPNs), Elastic IP addresses, endpoints, peering connections, NAT instances, placement groups, elastic network interfaces, Amazon DNS, VPC Flow Logs, and IPv6.

Understand the purpose of a subnet. A subnet is a segment of a VPC’s IP address range where you can place groups of isolated resources. Subnets are defined by CIDR blocks—for example, 10.0.1.0/24, 10.0.2.0/24—and are contained within an Availability Zone.

Identify the difference between a public subnet, a private subnet, and a VPN-only subnet. If a subnet’s traffic is routed to an Internet gateway, the subnet is known as a public subnet. If a subnet doesn’t have a route to the Internet gateway, or if it does have a route to an EIGW, the subnet is known as a private subnet. If a subnet doesn’t have a route to the Internet gateway or EIGW but has its traffic routed to a VGW, the subnet is known as a VPN-only subnet.

Understand the purpose of a route table. Route tables contain routing rules that determine where network traffic is directed. Each subnet can have its own route table. These routing rules are executed by the implicit router using a route priority process. An unmodifiable local route exists in all route tables within the VPC, and it allows Amazon EC2 instances within different subnets of the same VPC to communicate with each other.

Understand the purpose of an Internet gateway. An Internet gateway is a horizontally-scaled, redundant, and highly-available Amazon VPC component that allows communication between instances in your VPC and the Internet. Internet gateways are fully redundant and have no bandwidth constraints. An Internet gateway provides a target in your VPC route tables for Internet-routable traffic and performs NAT for instances that have a private IPv4 to public IPv4 address mapping.

Understand what a NAT provides to a VPC. A NAT instance or NAT gateway enables instances in a private subnet to initiate outbound traffic to the Internet. This allows outbound Internet communication to download patches and updates, for example, but it prevents the instances from receiving inbound traffic initiated by nodes on the Internet.

Understand what an EIGW provides to a VPC. The IPv6 protocol was designed to provide end-to-end connectivity. As such, Amazon does not support NAT for IPv6. The EIGW enables instances in a private subnet to initiate outbound traffic to the Internet, but it prevents the instances from receiving inbound traffic initiated on the Internet.

Understand the role of a VGW. The VGW is a logical construct in your VPC that provides edge routing for AWS managed VPN connections and AWS Direct Connect (discussed in Chapter 5, “AWS Direct Connect”). The VGW maintains edge routing information that is separate from your VPC route tables. It is a next-hop router that makes routing decisions based on information received from the VPC and from the attached VPN or AWS Direct Connect connections.

Understand the components needed to establish a VPN connection from a network to a VPC. A VGW is attached to the VPN endpoints on the AWS side of the VPN connection between the Amazon network and the customer network. A customer gateway represents a physical device or a software application on the customer’s side of the VPN connection. The VPN connection consists of two IPsec tunnels, and the tunnel must be initiated from the customer gateway side.

Understand what benefits endpoints provide to a VPC. A VPC endpoint enables you to create a private connection between your VPC and another AWS Cloud service or VPC without requiring access over the Internet or through a NAT instance, a VPN connection, or AWS Direct Connect. Endpoints only support services within the local region.

Understand VPC peering. A VPC peering connection is a networking connection between two VPCs that enables resources in either VPC to communicate with each other as if they were within the same network. Peering connections are created through a request/accept protocol. Transitive peering is not supported, and peering is only available between VPCs within the same Amazon partition. Peers within the same region can share security group and Amazon DNS information. It’s also possible to peer between VPCs in different regions.

Know the difference between a security group and a network ACL. A security group applies at the network interface level. You can have multiple instances in multiple subnets that are members of the same security groups. Security groups are stateful, which means that outbound return traffic is automatically allowed, regardless of any outbound rules. A network ACL is applied on a subnet level, and traffic is stateless. You need to allow both inbound and outbound traffic on the network ACL in order for resources in a subnet to be able to communicate over a particular protocol. Traffic between instances in the same subnet are not evaluated by network ACLs.

Know what a placement group provides and why it is used. A placement group ensures that Amazon EC2 instances are launched in proximity to one another in the Amazon network. Placement groups are confined to a single Availability Zone. The result is low-latency, high packet-per-second performance, and high network throughput. Amazon EC2 instances used in placement groups should enable enhanced networking. Placement groups are used for applications that have strict network performance requirements.

Understand how elastic network interfaces are configured and used in a VPC. An elastic network interface is a virtual network interface that you can attach to an instance in a VPC. Elastic network interfaces are associated with a subnet. Each elastic network interface has a primary IPv4 private address, a MAC address, and at least one security group. An elastic network interface may optionally have secondary private IPv4 addresses, one or more Elastic IP addresses, one public IPv4 address, and one or more IPv6 addresses. Attaching multiple elastic network interfaces to an Amazon EC2 instance allows it to be multi-homed. Elastic network interfaces allow for the movement of network adapters in case of an underlying failure. The IP address may be preserved by attaching the elastic network interface to a replacement instance. You cannot detach the primary network interface of an Amazon EC2 instance.

Know the difference between a VPC public IP address and an IPv4 Elastic IP address. A public IP address is an AWS-provided IPv4 or IPv6 that is automatically assigned at launch to instances within a subnet. An Elastic IP address is an AWS-provided public IPv4 address that you allocate to your account and assign to instances or network interfaces on demand.

Understand what DHCP option sets provide to a VPC. The DHCP option sets element of an VPC allows you to direct Amazon EC2 hostname assignment to your own resources. You can specify the domain name for instances within an Amazon VPC and identify the IP addresses of custom DNS servers, NTP servers, and NetBIOS servers.

Understand the features of the Amazon DNS server. The Amazon DNS server is integrated into the VPC. It provides name resolution for both internal Amazon EC2 instances and for Internet DNS. The Amazon DNS server is located at both VPC CIDR+2 (for example, 10.0.0.2 for 10.0.0.0/16) and 169.254.169.253. When two peered VPCs within the same region enable the feature, Amazon DNS resolves internal Amazon EC2 hostnames across the peer connection. Amazon DNS integrates with Amazon Route 53 private hosted zones and AWS Directory Service.

Understand the capabilities and uses for VPC Flow Logs. VPC Flow Logs provide visibility into the network traffic flows in your VPC. The logs are stored in Amazon CloudWatch Logs approximately every 10 minutes. The logs can be enabled at the VPC, subnet, and network interface level. Log data is useful for determining anomalies in the network and for troubleshooting connectivity problems. When a secondary IP address on an elastic network interface is used as a destination, the logs capture the primary IP address of the interface in the log.

Exercises

The best way to become familiar with Amazon VPC is to build your own custom VPC and then deploy Amazon EC2 instances into it, which is what you’ll be doing in this section. You should repeat these exercises until you can create and decommission VPCs with confidence.

For assistance completing these exercises, refer to the Amazon VPC User Guide located at http://aws.amazon.com/documentation/vpc/.