This book and its accompanying online resources are designed to be a complete preparation tool for your ANS-C01 exam.

The book is written in a way that means you can apply everything you’ve learned here even after your certification. The online practice resources that come with this book (Figure 1.1) are designed to improve your test-taking skills. They are loaded with timed mock exams, chapter review questions, interactive flashcards, case studies, and exam tips to help you work on your exam readiness from now till your test day.

Before You Proceed

To learn how to access these resources, head over to Chapter 16, Accessing the Online Practice Resources, at the end of the book.

Figure 1.1: Dashboard interface of the online practice resources

Here are some tips on how to make the most of this book so that you can clear your certification and retain your knowledge beyond your exam:

1. Read each section thoroughly.
2. Make ample notes: You can use your favorite online note-taking tool or use a physical notebook. The free online resources also give you access to an online version of this book. Click the BACK TO THE BOOK link from the dashboard to access the book in Packt Reader. You can highlight specific sections of the book there.
3. Chapter review questions: At the end of this chapter, you’ll find a link to review questions for this chapter. These are designed to test your knowledge of the chapter. Aim to score at least 75% before moving on to the next chapter. You’ll find detailed instructions on how to make the most of these questions at the end of this chapter in the Exam Readiness Drill – Chapter Review Questions section. That way, you’re improving your exam-taking skills after each chapter, rather than at the end of the book.
4. Flashcards: After you’ve gone through the book and scored 75% or more in each of the chapter review questions, start reviewing the online flashcards. They will help you memorize key concepts.
5. Mock exams: Revise by solving the mock exams that come with the book till your exam day. If you get some answers wrong, go back to the book and revisit the concepts you’re weak in.
6. Exam tips: Review these from time to time to improve your exam readiness even further

This chapter will cover the following topics:

• Elastic network interfaces
• Elastic IP addresses
• Subnet configuration and optimization
• Prefix lists
• Connectivity between AWS VPCs
• IP address overlap management

By the end of the chapter, you will understand how to configure elastic network interfaces (ENIs) and Elastic IP addresses (EIPs) and manage advanced IP address configurations, including handling IP address overlaps and preventing IP address depletion. You will have learned how to optimize subnet configurations to support auto-scaling and avoid IP address depletion using secondary CIDR blocks. This chapter will also help you gain an understanding of additional VPC networking services and features, and how to utilize VPC Reachability Analyzer and other tools to test and analyze network connectivity and troubleshoot issues.

All Amazon EC2 instances are connected to a specific VPC. This is done using ENIs. Within a VPC, an ENI is a construct that represents a virtual network interface card. Just as with any computer, server, or even mobile device, a network interface card is responsible for processing network traffic in and out of that instance. Network interface cards, often referred to as NICs, are also responsible for owning both the IP address (layer 3) and MAC address (layer 2) for the infrastructure they are attached to. ENIs connect AWS virtual machines and services to a VPC at the network layer and are commonly just referred to as network interfaces. For the sake of this certification guide, any time you hear a reference to a network interface, you can understand that to be an ENI.

ENIs are created and attached to instances. In turn, ENIs are bound to a single Availability Zone (AZ) and belong to a single subnet. When creating an ENI, you are required to specify the VPC and subnet where the ENI will reside. In addition, you can configure any IP setting, such as dynamic/static addressing, as well as settings such as TCP/UDP idle timeout tracking.

Note

Idle timeout is the amount of time it takes for a tracked TCP or UDP session on a specific ENI to time out after the last packet was received.

Primary Network Interfaces

All EC2 instances deployed require a primary network interface. An EC2 instance must always have a primary network interface attached, and the interface cannot be detached or deleted. You can attach additional ENIs to each EC2 instance. The maximum number of permitted network interfaces is defined per EC2 instance type.

Figure 1.2 shows EC2 instances with multiple ENIs attached to separate subnets. Keep in mind that since EC2 instances cannot span AZs, this means that all attached ENIs must also belong to a single AZ.

Figure 1.2: EC2 with dual ENI

As shown in the preceding diagram, Amazon EC2 instances can have multiple ENIs attached to them and these interfaces can be in different VPC subnets.

Note

An exhaustive list of EC2 instance types and their maximum number of supported network interfaces can be found here: https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html

Configuration of Network Interfaces

The configuration of an ENI can support several ways of assigning an IP address for the instance, but the configuration also controls certain behaviors for that network interface as well. The following sections will cover the assignment of IPv4 and IPv6 addresses and configurations for ENIs.

Auto-Assigned Public IPv4 Addresses

ENIs are attached to subnets within VPCs. Therefore, IP address on the ENI will belong to one of the CIDR blocks assigned to the VPC – more specifically, the subnet in which it resides. The IP address can be dynamically or statically assigned.

VPCs are commonly deployed with private, RFC 1918-based IPv4 address. However, subnets allow for the auto-assignment of public IPv4 addresses, as well. If an instance is deployed into a subnet that has this enabled, then a public IPv4 address is automatically associated with that instance. This public IPv4 address is automatically pulled from Amazon’s pool of public IP addresses. While this public IPv4 address is associated with the instance, it is technically set up with a one-to-one network address translation (NAT) to the address on the primary ENI.

It is important to understand that these auto-assigned addresses are not specifically allocated to your AWS account. They are somewhat ephemeral in nature and purely active based on the state of the instance. These addresses will automatically be released if the instance is stopped, hibernated, or terminated. Once an auto-assigned public IPv4 address is released, you will not be able to retrieve it.

For use cases that require persistent usage of public IPv4 addresses, it is recommended to use EIPs, which will be covered later in this chapter – for example, if you have an app server that requires a consistent public IP address to be used so that you can associate a DNS entry or have a single IP to whitelist on your own network for this application.

Auto-Assigned Private IPv4 and IPv6 Addresses

When instances are deployed, the residing subnet may also have enabled auto-assignment of IPv4 and IPv6 addresses. This means that when the primary ENI is launched into that subnet, it will automatically be assigned an IPv4 and/or an IPv6 address from the associated CIDR block. The subnet configuration settings that automatically provision new public IPv4 or IPv6 addresses when an ENI is created in the subnet are shown in Figure 1.3:

Figure 1.3: Subnet auto-assign IP settings

If the boxes in Figure 1.3 remain unchecked, no resources created within this subnet will receive automatic assignment of IPv6 addresses or IPv4 public addresses. Conversely, if every resource in this subnet should have one or both of these addresses, this setting can automate that process.

Note

The auto-assign IP address settings can be overridden when deploying an EC2 instance into the subnet if desired. During the launch, you can specify any specific IPv4 and IPv6 addresses you would prefer to use on the instance, assuming it is an address that belongs to the assigned CIDR blocks. You are also able to configure secondary IPs at the time of launch.

Termination Behavior

Once an ENI has been attached to an EC2 instance, you can change its termination behavior. This setting allows you to adjust whether the ENI will be terminated once the attached instance has been terminated. This can sometimes assist with ensuring resources are properly cleaned up if they are not needed after the parent instance is decommissioned. Refer to Figure 1.4 for a screenshot of this setting in the AWS Management console where this setting can be configured under the VPC | Network Interfaces | Actions menu:

Figure 1.4: ENI termination behavior

The termination behavior affects whether the ENI will be deleted if its attached EC2 instance is deleted.

Source/Destination Check

By default, all ENIs have a setting enabled that performs a source/destination check. When this setting is enabled, the ENI will ensure that any packets processed by the ENI have the ENI’s IP address in either the source or destination field of the IP header. This applies to both IPv4 and IPv6 traffic.

This setting must be disabled if the instance in question is performing any kind of process such as IP routing, NAT, or even firewall functions. This is common for things such as network virtual appliances (NVAs) because when performing a task such as IP routing or NAT, the traffic is rarely destined to go to that device, but through that device. This means that NVA devices are primarily focused on moving packets from endpoint to endpoint and are rarely the target device for data traffic. Refer to Figure 1.5 for a look at this setting in the AWS console:

Figure 1.5: ENI source/destination check

Attaching and Detaching ENIs

As the name suggests, ENIs are elastic and hence are able to scale up or down as demand requires, allowing them to exist outside the EC2 instances to which they are assigned, and able to move between them with ease. ENIs support attachment in three different scenarios, which are classified as hot, warm, and cold attachments:

• Hot attachment: Attachment while the instance is in the running state
• Warm attachment: Attachment while the instance is stopped
• Cold attachment: Attachment when the instance is initially being launched

Note

Hot and warm attachments are automatically recognized by instances running Amazon Linux or Windows Server. However, other operating systems may require secondary ENIs to be configured manually.

While you can attach multiple ENIs to an instance within the same subnet, it is important to note that this does not increase the network bandwidth to or from the instance. These limits are still bound to those of the EC2 instance type. As an example, a t2.micro EC2 instance can only have two total ENIs, while an m5.4xlarge instance can support up to eight.

Secondary ENIs can be detached in the same fashion, regardless of whether the instance is running or stopped. As noted before, the primary ENI cannot be detached.

Configuring ENIs

To configure a network interface, you can simply navigate to the EC2 dashboard of the AWS console, select Network Interfaces, and choose the Create network interface option. As shown in Figure 1.6, you must give the ENI a name and assign the subnet in which to create the interface:

Figure 1.6: Create network interface details

Creating an ENI is independent of an EC2 instance, but the specific capabilities of an ENI must be configured. These settings will persist with the ENI regardless of what instance or service it is attached to from the time of creation.

The ENI will be detached from any EC2 instance until it is attached and can only be attached to EC2 instances that can be deployed in that subnet.

An ENI can be created using the AWS CLI create-network-interface command.

For example, the following command will create an ENI using the AWS CLI:

aws ec2 create-network-interface \
  --subnet-id subnet-12345678 \
  --description "My ENI" \
  --groups sg-12345678 sg-87654321 \
  --private-ip-address 10.0.1.10

AWS gives you multiple ways to create and configure resources. The AWS console is fully click-based, while the AWS CLI allows resource creation via commands or automation. The result is the same.

The use of auto-assigned public IPv4 addresses can be useful, but they are somewhat ephemeral in nature. Often, you may need to allocate static IPv4 addresses for your AWS resources that are more controlled in nature and, again, elastic. You will use EIPs for these use cases. A perfect example of an EIP is when replacing a workload that has externally facing services that must be reachable via the same IP address; when the workload is replaced, the EIP can be migrated and associated with the new one.

An EIP is a public IPv4 address that is allocated and associated with your AWS account. Much like ENIs, these EIPs can be moved between resources as needed. EIPs are allocated first and then associated with specific resources. From an EC2 perspective, you can associate an EIP with either an EC2 instance or a network interface. When associating an EIP to an EC2 instance, the EIP will be associated with the IP address assigned to the primary network interface. Additionally, any EIPs assigned to secondary ENIs attached to an instance will also show up on the EC2 dashboard as being associated with the instance.

Note

EIPs can also be assigned to resources like elastic load balancers and NAT gateways.

When an EIP is reassigned from one instance to another, the public IPv4 address is reassigned and associated with the private IP of the interface on the new instance. If you recall the one-to-one NAT association that is built on the internet gateway (IGW), this NAT entry is what gets updated. This process is represented in Figure 1.7:

Figure 1.7: Reassociate an EIP

Reassociating an EIP is just configuring the one-to-one NAT entry on the internet gateway of the VPC.

Configuring Elastic IP Addresses

This section details the creation of an EIP both from the AWS console and using the AWS CLI. To configure an EIP, navigate to the EC2 dashboard of the AWS console, select Elastic IPs, and choose the Allocate Elastic IP address option. As shown in Figure 1.8, you must give the EIP a name and define what AWS network border group to allocate the EIP from. This is a geographic representation of the AWS border and governs from which public IP address pool the IP should come.

Figure 1.8: Allocate EIP details

The main choice to make with an EIP is to which regional area the IP should be allocated; this should match the geographic area in which you expect to use the IP.

Next, you will need to associate the EIP with a resource. The process of associating the EIP with either an EC2 instance or a network interface is shown in Figure 1.9 and continued in Figure 1.10. Figure 1.9 shows the AWS console menu where the association action can be selected.

Figure 1.9: Associate Elastic IP address

This begins the process of choosing the ENI or EC2 instance with which to associate the Elastic IP.

Figure 1.10 offers two options: the EC2 instance (and its default network interface), or an ENI that is not the default network interface of an EC2 instance.

Figure 1.10: Associate EIP details

Selection of one or the other is a matter of whether the ENI will be associated with an EC2 instance that will use the interface in a dedicated fashion with the Elastic IP, or whether the EC2 instance will use its default network interface for traffic related to the associated Elastic IP.

An EIP can be created using the AWS CLI aws ec2 allocate-address command.

For example, the following code will allocate an EIP using the AWS CLI:

aws ec2 allocate-address --domain vpc

An EIP can be associated using the AWS CLI aws ec2 associate-address command.

For example, to associate an EIP using the AWS CLI, use this code:

aws ec2 associate-address --instance-id i-12345678 --allocation-id eipalloc-12345678

When deploying elastic and scalable solutions in the AWS cloud, you need to ensure that your VPC networks are properly configured to allow for that behavior. AWS services such as EC2 and Elastic Load Balancing (ELB) enable solutions to automatically horizontally scale dynamically based on capacity needs. This short section will detail some considerations that should be made when deploying subnets to support ELB and EC2 Auto Scaling.

Note

There will be a later chapter that dives deeper into Elastic Load Balancing and the details that come with ELB configuration.

Subnet Considerations for ELB

When deploying various types of elastic load balancers in AWS, the ELB will need to be mapped to specific subnets within the VPC that it belongs to. When this mapping is done, the ELB will have an ENI deployed into each of those subnets. These ENIs are fully managed by the ELB and cannot be moved to other resources such as an EC2 instance. However, it is important to consider that these ENIs will need to consume IP addresses out of each of the subnets as well.

This sort of mapping is common when using an ELB as the frontend connection of a website. The ELB becomes the internet-facing website DNS entry that customers connect to, and when the connections come into the ELB, the routing rules of the load balancer determine into which subnet the traffic is delivered. Delivering traffic to these subnets requires the ENI deployment.

This may seem like a small thing to consider when you need to only account for one IP address in each subnet for the ELB. While only a single IP address, it is important to consider this when deploying your subnets within a VPC, especially if multiple ELBs may reside there. If you are using something small such as /28 for your subnets, there are only 11 usable addresses (14 minus the 3 AWS addresses) to assign to resources. The addresses must be used sparingly.

Refer to Figure 1.11 for a simplistic view of multiple application load balancers mapped to the same subnets and consuming multiple addresses:

Figure 1.11: ALB with ENIs

ALBs are usually deployed in such a fashion for resiliency and redundancy in case an AZ is impacted by a failure.

Subnet Considerations for Auto-Scaling

When configuring EC2 Auto Scaling, you need to make similar considerations for the number of IP addresses that will be consumed out of your VPC subnets. Since EC2 Auto Scaling allows you to set minimum and maximum desired capacity units for EC2 instances, you will need to ensure your subnets have adequate IP addresses, not just for normal operation, but also to account for failure.

Take the following example. Trailcats has an Auto Scaling group (ASG) spread across three AZs within a VPC. During peak times, the maximum capacity on the ASG is configured for nine instances, so they are spread evenly across the AZs. If there is an AZ failure, then those instances will need to be redeployed in other subnets. In this scenario, all VPC subnets need to have enough IP addresses to account for all the EC2 instances that the ASG could deploy into the subnet during an AZ failure. Refer to Figure 1.12 to see an example of how the ASG could react to an AZ failure:

Figure 1.12: Subnets with auto-scaling configuration

Auto-scaling is both based on demand and resiliency; in the preceding figure, auto-scaling is being used for resiliency to ensure adequate resources are available.

Configuring rules for security groups or routes for route tables can sometimes be difficult to manage. When an organization has several CIDR blocks they need to allow access from or route to, maintaining all those entries can come with a management overhead to keep up with them. This can become quite cumbersome when you are responsible for maintaining these entries in multiple VPCs and potentially across multiple regions. Using managed prefix lists to maintain an up-to-date list of these CIDR blocks can make this process easier.

Prefix lists are lists that contain multiple IP CIDR blocks, which can be IPv4- or IPv6-based. These lists can then be referenced in rules belonging to security groups and route tables. In turn, if you have a prefix list containing 10 prefixes, a single security group rule or route table route entry will apply for all 10 of those prefixes. Prefix lists can be a good way to maintain consistency with security groups and/or route tables across all your resources and even between AWS accounts.

There are two types of prefix lists within AWS: customer-managed and AWS-managed.

Customer-Managed Prefix Lists

Customer-managed prefix lists are created and maintained by you within your AWS account(s). You are responsible for adding/removing IP prefixes from these lists as necessary. As prefixes are added/removed, any references to them in a security group rule or route table entry will automatically be updated in place.

A customer-managed prefix list is a regional construct, meaning it only exists within a single AWS Region. Here are a few other characteristics of customer-managed prefix lists to consider. A prefix list supports either IPv4 or IPv6 addressing, but not both. If you require the use of both, this task will require two separate prefix lists. A prefix list also requires a limit of the maximum number of prefix entries to be set. By default, the maximum number this value can be set to is 1,000. To help manage the life cycle of a prefix list, it also supports versioning. When entries are added/removed, a new version of the prefix list is automatically created and promoted. This allows for simple restoration to previous versions.

Be careful when referencing a prefix list in another resource. The number of prefix entries applies to the service quota for that resource. For example, if a prefix list with 25 entries is referenced in a VPC route table, then that is equivalent to 25 separate route entries. This can quickly consume entries and is inefficient.

Refer to Figure 1.13 for an example of a customer-managed prefix list within the AWS dashboard. Make note of the prefix list version, max entries, and address family.

Figure 1.13: Customer-managed prefix list

Customer-managed prefix lists offer granular logical grouping based on specific needs, but as with all custom features in the cloud, this granularity comes with strict limitations such as low maximum entries.

Note

Customer-managed prefix lists are also supported within AWS Transit Gateway (TGW) route tables, which will be covered later in this chapter.

AWS-Managed Prefix Lists

In addition to customer-managed prefix lists, there are also AWS-managed prefix lists. These can be referenced in a very similar fashion to customer-managed ones, but all the entries are owned and maintained by AWS. These prefix lists are automatically created within each AWS region and can be referenced as needed.

These prefix lists are created for several AWS services and are populated with all the IP prefixes associated with those services. These lists can be referenced by security groups or route tables to ensure resources can interact with these services in a secure manner.

Refer to Table 1.1 for a list of AWS-managed prefix lists and their corresponding names:

Table 1.1: AWS-managed prefix lists

These AWS-managed prefix lists make it simpler for customers to reference them when creating a policy that needs to reference AWS services.

Note

You can find more details about AWS-managed prefix lists here: https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html

Configuring Customer-Managed Prefix Lists

This section details the creation of a customer-managed prefix list from either the AWS console or AWS CLI.

To create a customer-managed prefix list, navigate to the VPC console of the AWS dashboard and select Managed prefix lists. This section contains both customer-managed and AWS-managed prefix lists. Select the Create prefix list option to create a new customer-managed prefix list. Next, you will define the name of the prefix list, the maximum number of entries, and any specific prefix entries. This process is shown in Figure 1.14:

Figure 1.14: Create prefix list details

The prefix list is a custom way to maintain a list of interesting prefixes that should be referenced in the same way – for example, you may wish to create a prefix list with the prefixes of all development resources across your VPCs; a prefix list can do this.

A customer-managed prefix list can be created using the AWS CLI aws ec2 create-managed-prefix-list command.

For example, to create a custom prefix list using the AWS CLI, follow the given code:

aws ec2 create-managed-prefix-list --prefix-list-name MyPrefixList --max-entries 10 --address-family IPv4 --entries Cidr=10.0.0.0/16,Description="My CIDR block"

The next section will cover how to connect VPCs together.

Amazon VPCs are great for housing applications within your AWS account, but it is rare that you will need only a single VPC. Many AWS customers use multiple VPCs. This can range from five VPCs in a single account or hundreds of VPCs across several AWS accounts. This is due to a number of factors; different teams may own different AWS accounts and VPCs, or there may be security concerns that require decentralizing workloads. The next sections will focus on building connectivity between your Amazon VPCs.

VPC Peering

One of the simplest ways to build connectivity between VPCs is using a VPC peering connection. VPC peering is a simple connection that is built between two VPCs. This peering does not use a specific type of gateway or external connection, so it does not possess any limits on throughput for connectivity across the peering.

Refer to Figure 1.15 for a visual of VPC peering:

Figure 1.15: VPC peering connection

In the preceding figure, you will see that there is a VPC peering connection built between VPC-A and VPC-B. Every VPC peering connection will have a VPC peering connection ID associated with it. That peering connection ID can then be used within the route tables of the VPC as a target for any route entries that are to use the VPC peering. In this example, VPC-A has an IPv4 CIDR of 10.1.1.0/24 and VPC-B has a CIDR of 10.2.2.0/24. Each VPC has local route tables configured with routes to the peered VPC CIDR. The target of the routes is the VPC peering connection ID, which is formatted as pcx-xxxxxxxxxx.

There are a few limitations and constraints you need to consider about VPC peering. This may influence your decision of whether to implement VPC peering for connectivity or choose something such as AWS TGW, which will be discussed in Chapter 5, Hybrid Networking with AWS Transit Gateway.

You may have occasions where VPCs have multiple VPC peering connections to other VPCs. As the number of VPCs within your environment grows, your number of VPC peering connections may also grow. It may be easy to assume that you could just “daisy-chain” VPCs together and essentially route through a central VPC to get to others. This is commonly referred to as a hub-and-spoke network.

However, you need to be aware that VPC peering connections are non-transitive. This means that traffic cannot transit through a VPC and across another VPC peering connection. Refer to Figure 1.16 as an example:

Figure 1.16: Non-transitive VPC peering

There are three VPCs in this example, with VPC-B peered to both VPC-A and VPC-C. Any traffic from VPC-A or VPC-C destined for VPC-B will be permitted and vice versa. However, any traffic destined from VPC-A to VPC-C will be blocked due to the non-transitive nature of VPC peering. For a transitive solution, it is often recommended to use a service such as AWS TGW. Alternatively, you could opt for a full-mesh VPC peering solution. This means that every VPC is peered to every other VPC. As you may imagine, once the number of VPCs reaches a certain scale, managing this number of VPC peering connections can turn out to be a difficult task.

Note

This non-transitive nature also applies to services such as internet gateways, NAT gateways, Direct Connect, and gateway endpoints. In other words, VPC peering cannot be used for resources in a VPC to access these services within another VPC.

Overlapping CIDR Blocks

When creating a VPC peering connection, the two VPCs cannot have overlapping IP CIDR blocks. This applies to both IPv4 and IPv6, with both primary and secondary IP blocks considered. If you attempt to create a VPC peering between VPCs with overlapping CIDRs, the peering connection will fail.

Inter-Region Maximum Transmission Unit (MTU)

Creating VPC peering connections between VPCs that reside in different AWS regions is a supported configuration. However, it is important to consider that the MTU across inter-region peering connections is 1,500 bytes. This differs from intra-region peering connections, which support a jumbo MTU, or 9,001 bytes. This can be an important consideration with traffic that may have issues with the fragmentation of payloads, that is, a packet larger than 1,500 bytes needing to be fragmented into multiple packets and sent across VPC peering.

Refer to Figure 1.17 for an example:

Figure 1.17: Inter-region VPC peering

Within a region, the MTU is much higher, and applications could use jumbo frames. However, traffic between AWS regions is restricted to a standard 1,500 bytes and the applications must be able to detect this and adjust the packet payload size accordingly.

The VPC peering connection between VPC-A and VPC-B in region us-east-1 has an MTU of 9,001 bytes. The inter-region peering between VPC-A in us-east-1 and VPC-C in ap-southeast-2 has an MTU of 1,500 bytes.

Other Considerations for VPC Peering Connections

There are several other characteristics of VPC peering connections that need to be considered when using this solution for providing inter-VPC connectivity. A few of them are listed here:

• Routing across VPC peering connections is all dependent on static routes. This means all route tables must be updated within both VPCs to ensure bidirectional communications.
• The number of VPC peerings per VPC is limited by a service quota. The default amount is 50 peering connections, but this is adjustable up to 125.
• You cannot create multiple VPC peering connections between two VPCs.
• Unicast reverse path forwarding is not supported for VPC peering. Therefore, if multiple VPCs with the same CIDR block are peered to the same VPC, you will need to implement longest match route table entries to achieve symmetric traffic.

Note

For a full list of VPC peering limitations, refer to the AWS documentation page here: https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-basics.html#vpc-peering-limitations

Provisioning Process for VPC Peering Connections

Provisioning a VPC peering connection is a multi-step process. The process includes a VPC requesting to peer with another VPC, then that request being approved before the VPC peering connection is established. The VPC initiating the peering connection request is known as the requester VPC and the receiving VPC is known as the accepter VPC.

This process is quite simple when peering VPCs within the same AWS account, as the request and the approval can all be done within the account. However, this process is allowed across AWS accounts, so the requester VPC could be in one AWS account, while the accepter VPC is in another AWS account. The accepter VPC could be within an account that is under the same AWS Organization or a separate one.

A VPC peering connection will go through a series of stages within both the provisioning and deprovisioning processes. These stages represent the current state of the peering connection and whether it is ready for use. The stages are outlined here:

• Initiating request: The request to form a VPC peering connection has been made and is in the initiation state. From here, the process will move to pending acceptance, unless there is a failure.
• Failed: The VPC peering connection has failed after initiation. The peering connection cannot be recovered from this state – it must be re-initiated.
• Pending acceptance: The VPC peering connection has been initiated and is awaiting approval from the accepter VPC.
• Expired: The peering connection has expired.
• Rejected: The accepter VPC has rejected the request for a VPC peering connection to be created.
• Provisioning: The accepter VPC has accepted the peering request and it is in the process of being provisioned.
• Active: The VPC peering connection is active and ready for use. VPC route tables can be updated with route entries to use the VPC peering connection ID as the target.
• Deleting: The current VPC peering connection has been requested for deletion and is in the process of being removed.
• Deleted: The VPC peering connection has been removed and is no longer available for use.

Understanding the VPC peering connection status will give insight into whether the connection is active and usable or whether there is a problem.

Configuring VPC Peering Connections

This section details the creation of a VPC peering connection both from the AWS console and using the AWS CLI.

To configure an EIP, you can simply navigate to the VCP dashboard of the AWS console, select Peering connections, and choose the Create peering connection option. The process and required VPC peering details are shown in Figure 1.18.

Figure 1.18: Create VPC peering details

VPC peering can be initiated to the same account or between AWS accounts; in either case, the VPCs that can be peered will show up in the drop-down menu.

Once the VPC peering connection has been created, it will need to be accepted. This can take place in the same AWS account or a separate one. You will navigate again to the Peering connections section within the account of the accepter VPC and approve the pending request as shown in Figure 1.19.

Figure 1.19: Accept VPC peering

Before the VPC peer is active, the request must be accepted, either by the same account or the other account to which the request was made.

A VPC peering connection can be created using the AWS CLI command:

aws ec2 create-vpc-peering-connection

For example, to create a VPC peering request using the AWS CLI, use the following command:

aws ec2 create-vpc-peering-connection --vpc-id vpc-12345678 --peer-vpc-id vpc-87654321 --peer-region us-west-2

A VPC peering connection can be accepted using the following AWS CLI command:

aws ec2 accept-vpc-peering-connection

As an example, to accept a VPC peer request, use the following AWS CLI command:

aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-12345678

Hub-and-Spoke VPC Architectures

As mentioned before, one common network topology that is used for connecting multiple IP networks together is hub-and-spoke. This topology is composed of a central “hub” network that then has connections with separate spokes. Typically, all traffic is backhauled through these hubs when attempting to talk to another network outside of their own. Given that VPCs are non-transitive, it is not possible to build this topology within AWS simply using VPC peering connections. You have the option to use a concept called a transit VPC to achieve this topology. In addition, you need to properly evaluate when to use this transit VPC or a service such as AWS TGW. This section will cover both topics.

Since hub-and-spoke networks cannot be directly achieved with VPC peering connections, an alternative solution is the transit VPC. The concept of a transit VPC is based on the use of IPsec VPN connectivity over the top of the standard VPC connectivity. This can be achieved by deploying NVAs into a central VPC and then configuring a series of IPsec VPN tunnels from these appliances to other VPCs. Additionally, these appliances could build IPsec connectivity to on-premises or other third-party networks. For building connectivity to other Amazon VPCs, you have a couple of options when using a transit VPC:

• Option 1: Build IPsec connectivity from the NVAs in the transit VPC to virtual private gateways (VGWs) residing in the spoke VPCs
• Option 2: Build IPsec connectivity from the NVAs in the transit VPC to additional NVAs within the spoke VPCs

Both options are outlined in Figure 1.20:

Figure 1.20: Transit VPC options

In Figure 1.20, both the preceding options have the option to utilize either static or dynamic routing for overlay connectivity via IPsec tunnels. The dynamic routing option is fully dependent on the capabilities of the vendor used for the NVA. The VGW will only support Border Gateway Protocol (BGP) as a routing protocol.

Consider a scenario where Trailcats had a need for expanded connectivity due to some quota limitation, such as a maximum number of routes in the VPC routing table, or if connecting to a third-party vendor that required a different connectivity solution than that offered by native cloud networking. This is common when working with vendors and a major driver of enterprises adopting NVA-based solutions.

The strength of Option 1 in this situation is that a minimal deployment of NVAs might meet the needs of vendor connectivity while allowing workload VPCs to be connected to the vendor and each other. This option works so long as there is no need to propagate large amounts of routes to the workload VPCs, as the VPC route tables have a low maximum number of routes.

The weakness of this option is evident in that a large portion of connectivity becomes manual – namely, the VPC route tables and the VPN connections to the VPC-attached VGWs.

Option 2 requires more up-front work to deploy NVAs to workload VPCs, but often these solutions are software-defined, which facilitates route exchange and connectivity between the NVAs.

The weakness of this option is it requires far more life cycle management of NVA instances and potential software problems if the NVA vendor releases software with bugs or other problems.

Note

More details on AWS transit VPCs can be found at the following URL: https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html

During AWS cloud deployment, you may need to provide connectivity between resources that have overlapping IP address ranges. This could be for several reasons, such as a developer configuring a VPC without checking whether the IP address range was available within their IP address manager (IPAM) solution or even a merger/acquisition between two companies. Nonetheless, from a networking perspective, you may be tasked with making connectivity happen. This short section will touch on how to accomplish this with AWS NAT gateways, but there is another method using AWS PrivateLink covered later, in Chapter 3, Networking Across Multiple AWS Accounts.

Using Private NAT Gateways for IP Overlaps

As mentioned in the previous chapters, AWS NAT gateways can be used to allow private subnets to talk to resources on the public internet or even other private resources within the AWS cloud or on-premises. Allowing communication between resources with overlapping IP address space can be one of those particular use cases. Refer to the following example.

Trailcats has acquired another company called Mountain Felines (MF), which also uses the AWS cloud for its applications. An MF VPC needs to communicate with some Trailcats resources, but it is using an IPv4 CIDR that is already in use by a Trailcats VPC, 10.100.0.0/16. Trailcats has attached the acquired MF VPC to their existing AWS TGW but cannot have two routes to the same destination. To allow the two VPCs to communicate with other resources, a secondary CIDR is used within the VPC to house an AWS NAT gateway. The NAT gateway can then be used as the next hop for traffic from the overlapping subnets to any other resources. This (in addition to some DNS adjustments) would allow for the VPC to initiate and establish connectivity. This is shown in Figure 1.21:

Figure 1.21: Overlapping IP space with NAT gateways

The use of a private NAT gateway allows workloads with overlapping IPs to communicate; the nature of a NAT gateway requires that the workload using the NAT gateway is the one to initiate the communication. This is why if both sides initiate communication, a NAT gateway is needed for each subnet.

Note

This same behavior could not be achieved with VPC peering because two VPCs cannot be peered together if they have overlapping CIDR ranges.

The following table includes some AWS service quotas you should be aware of for the AWS ANS-C01 exam. Service quotas are artificial limitations put in place by AWS to ensure that no single customer can impact other customers through resource denial.

Table 1.2: VPC service quotas

Note

These service quota details were pulled directly from the following AWS documentation pages:

https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html

https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-connection-quotas.html

In this chapter, you looked deeper into AWS networking components that can be used to build upon the fundamental networking services. This chapter focused on building connectivity and on how to control connectivity in certain scenarios. Advanced VPC networking concepts such as ENI, EIP, VPC peering, and prefix lists are a necessary foundation upon which the rest of this guide will be built. The next chapter focuses on monitoring the traffic and performance of VPCs.

Apart from mastering key concepts, strong test-taking skills under time pressure are essential for acing your certification exam. That’s why developing these abilities early in your learning journey is critical.

Exam readiness drills, using the free online practice resources provided with this book, help you progressively improve your time management and test-taking skills while reinforcing the key concepts you’ve learned.

HOW TO GET STARTED

• Open the link or scan the QR code at the bottom of this page
• If you have unlocked the practice resources already, log in to your registered account. If you haven’t, follow the instructions in Chapter 16 and come back to this page.
• Once you log in, click the START button to start a quiz
• We recommend attempting a quiz multiple times till you’re able to answer most of the questions correctly and well within the time limit.
• You can use the following practice template to help you plan your attempts:

The above drill is just an example. Design your drills based on your own goals and make the most out of the online quizzes accompanying this book.

First time accessing the online resources?

You’ll need to unlock them through a one-time process. Head to Chapter 16 for instructions.