Advanced VPC Networking

Advanced VPC Networking

• The AWS Certified Advanced Networking – Specialty (ANS-C01) exam focuses on advanced networking
• The chapter focuses on building blocks within a virtual private cloud (VPC), including network interfaces, public IP addresses, and connectivity

Interconnectivity between VPCs

• Several scenarios exist where interconnectivity between VPCs is needed within an AWS cloud environment
• Examples include two servers in separate VPCs communicating, or hundreds of VPCs accessing shared services in another VPC
• VPCs may need access to other AWS services such as S3 for storage
• Verifying connectivity is crucial
• Understanding VPC communication is important for the exam and real-world applications, where cloud deployments often involve multiple VPCs and services

Tips for Making the Most of the Book

• Read each section thoroughly
• Take ample notes using your preferred tool
• Online resources provide access to an online version of the book in Packt Reader for highlighting
• Chapter review questions are designed to test your knowledge, aim for at least 75% before moving on
• After scoring 75% or more on chapter review questions, review the online flashcards to memorize key concepts
• Revise by solving the mock exams and revisit weak areas
• Review exam tips to improve exam readiness

Chapter Topics

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

Goals for the End of this Chapter

• Configure elastic network interfaces (ENIs) and Elastic IP addresses (EIPs)
• Manage advanced IP address configurations, including handling IP address overlaps and preventing IP address depletion
• Optimize subnet configurations to support auto-scaling and avoid IP address depletion using secondary CIDR blocks
• Gain an understanding of additional VPC networking services and features
• Utilize VPC Reachability Analyzer and other tools to test and analyze network connectivity and troubleshoot issues

Elastic Network Interfaces (ENIs)

• All Amazon EC2 instances connect to a specific VPC
• An ENI is a construct that represents a virtual network interface card within a VPC
• Network interface cards (NICs) own the IP address (layer 3) and MAC address (layer 2) for their attached infrastructure
• ENIs connect AWS virtual machines and services to a VPC at the network layer
• "Network interface" is synonymous with "ENI"
• ENIs are created and attached to instances and are bound to a single Availability Zone (AZ) and belong to a single subnet
• When creating an ENI, specify the VPC and subnet where it resides
• Configure IP settings, like dynamic/static addressing, and TCP/UDP idle timeout tracking

Primary Network Interfaces

• All deployed EC2 instances need 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
• EC2 instances cannot span AZs, all attached ENIs must also belong to a single AZ

Configuration of Network Interfaces

• ENI configuration supports multiple ways of assigning an IP address
• It controls certain behaviors for that network interface
• The following sections cover IPv4 and IPv6 address assignments and configurations for ENIs

Auto-Assigned Public IPv4 Addresses

• ENIs attach to subnets within VPCs, so the IP address belongs to one of the VPC's CIDR blocks, specifically the subnet
• The IP address can be dynamically or statically assigned
• VPCs are commonly deployed with private, RFC 1918-based IPv4 addresses, but subnets allow for auto-assignment of public IPv4 addresses
• If enabled, a public IPv4 address is automatically associated with an instance deployed into a subnet, pulled from Amazon's pool
• This public IPv4 address is technically set up with a one-to-one network address translation (NAT) to the address on the primary ENI
• Auto-assigned addresses are not specifically allocated to your AWS account, they are ephemeral and active only based on the instance's state
• Addresses release automatically if the instance is stopped, hibernated, or terminated and cannot be retrieved
• For persistent usage of public IPv4 addresses, EIPs (Elastic IP Addresses) are recommended
• For example, if you have an app server that requires a consistent public IP address to be used to 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 enable auto-assignment of IPv4 and IPv6 addresses
• This will automatically assign IPv4 and/or IPv6 addresses from the associated CIDR block when the primary ENI is launched into that subnet

Subnet Auto-Assign Settings

• If the auto-assign settings are not selected, no resources created within the subnet will receive automatic assignment IP addresses
• Conversely, the auto-assign settings can automate the process for every resource in the subnet

Termination Behavior

• Termination behavior determines whether the ENI will terminate once the attached instance terminates
• This assists with ensuring resources are properly cleaned up if they are not needed after the parent instance is decommissioned
• This setting can be configured under the VPC | Network Interfaces | Actions menu

Source/Destination Check

• By default, all ENIs have source/destination check enabled
• With this setting enabled, the ENI ensures 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
• Disable the setting if the instance is performing any kind of process such as IP routing, NAT, or even firewall functions
• This is common for network virtual appliances (NVAs) which, when performing a task such as IP routing or NAT, the traffic is rarely destined to go to that device, but through that device

Attaching and Detaching ENIs

• ENIs can scale up or down as demand requires, exist outside assigned EC2 instances, and move between them
• ENIs support attachment in three scenarios:
  • 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 launched
• Multiple ENIs can attach to an instance within the same subnet, but it does not increase the network bandwidth to or from the instance
• Limits are still bound to those of the EC2 instance type -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 regardless of instance state
• The primary ENI cannot be detached

Configuring ENIs

• To configure a network interface, navigate to the EC2 dashboard, select Network Interfaces, and choose Create network interface
• Give the ENI a name and assign a subnet

ENI Configuration Details

• Creation is independent of an EC2 instance, but specific capabilities persist regardless of instance or service attachment
• 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
• ENIs can be created using the AWS CLI create-network-interface command

Elastic IP Addresses

• Auto-assigned public IPv4 addresses are ephemeral
• For static IPv4 addresses, allocate Elastic IP Addresses (EIPs)
• 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 allocated and associated with your AWS account
• Like ENIs, EIPs can be moved between resources
• EIPs are allocated first and then associated with specific resources
• From an EC2 perspective, 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
• Any EIPs assigned to secondary ENIs attached to an instance will also show up on the EC2 dashboard as being associated with the instance
• When reassigning an EIP from one instance to another, the public IPv4 address is reassigned and associated with the private IP of the interface on the new instance
• The one-to-one NAT association built on the internet gateway (IGW) gets updated
• Reassociating an EIP configures the one-to-one NAT entry on the internet gateway of the VPC

Configuring Elastic IP Addresses

• To configure an EIP, navigate to the EC2 dashboard, select Elastic IPs, and choose the Allocate Elastic IP address option using the AWS console and AWS CLI
• Specify a name and AWS network border group to allocate the EIP from
• The border group represents the AWS border and governs from which public IP address pool the IP should come

Key Choice When Making an EIP

• Define the regional area for the allocation - this should match the geographic area in which you expect to use the IP

Associating the EIP with a Resource

• Shown in Figures 1.9 and 1.10
• The AWS console menu is shown in Figure 1.9 where the association action can be selected

EC2 vs ENI selection

• Select 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

Subnet Configuration and Optimization

• When deploying elastic and scalable solutions in the AWS cloud, ensure VPC networks are properly configured 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 section details considerations for deploying subnets to support ELB and EC2 Auto Scaling

Subnet Considerations for ELB

• When deploying various types of elastic load balancers in AWS, the ELB needs to be mapped to specific subnets within the VPC that it belongs to
• When mapped, the ELB will have an ENI deployed into each of those subnets, ENIs are managed by the ELB and cannot be moved to other resources such as an EC2 instance
• These ENIs will need to consume IP addresses out of each of the subnets as well
• 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
• When the connections come into the ELB, the routing rules of the load balancer determine into which subnet the traffic is delivered, requiring ENI deployment
• It is important to consider this when deploying your subnets within a VPC, especially if multiple ELBs may reside there
• If you are using /28 for your subnets, there are only 11 usable addresses (14 minus the 3 AWS addresses) to assign to resources, must be used sparingly
• Application load balancers (ALBs) are usually deployed in 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, 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, ensure your subnets have adequate IP addresses
• Consider scenarios where an AZ failure occurs
• 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

Prefix Lists

• Configuring rules for security groups or routes for route tables can be difficult to manage
• Maintaining access from or route to several CIDR blocks comes with a management overhead
• Maintaining these entries in multiple VPCs and potentially across multiple regions can be cumbersome
• Managed prefix lists maintain an up-to-date list of these CIDR blocks
• Prefix lists contain multiple IP CIDR blocks, can be IPv4- or IPv6-based
• Lists can be referenced in rules belonging to security groups and route tables
• A single security group rule or route table route entry will apply for all prefixes in a prefix list
• This maintains consistency with security groups and/or route tables across all resources and even between AWS accounts

Types of Prefix Lists

• Customer-managed
• AWS-managed

Customer-Managed Prefix Lists

• They 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 update in place
• A customer-managed prefix list is a regional construct, meaning it only exists within a single AWS Region
• A prefix list supports either IPv4 or IPv6 addressing, but not both, so 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, at 1,000 by default
• Prefix list 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 and is inefficient

AWS-Managed Prefix Lists

• These prefix lists are automatically created within each AWS region and can be referenced as needed
• Create for several AWS services and 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
• AWS-managed prefix lists simplify referring to the AWS resources

Configuring Customer-Managed Prefix Lists

• To create a customer-managed prefix list, navigate to the VPC console in the AWS dashboard and select Managed prefix lists
• Select the Create prefix list option to create a new customer-managed prefix list
• Define the name of the prefix list, the maximum number of entries, and any specific prefix entries
• A prefix list is a custom way to maintain a list of interesting prefixes

Connectivity between AWS VPCs

• Amazon VPCs are great for housing applications within your AWS account, but it is rare that you will need only a single VPC
• Common for AWS customers to use multiple VPCs, from five in a single account to hundreds of VPCs across several AWS accounts
• Reasons range from different teams owning different AWS accounts and VPCs, to security concerns that require decentralizing workloads

VPC Peering

• A simple way to build connectivity between VPCs is using a VPC peering connection
• VPC peering is a simple connection 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
• Every VPC peering connection will have a VPC peering connection ID
• That peering connection ID can be used within the route tables of the VPC as a target for any route entries that are to use the VPC peering
• Route tables are configured with routes to the peered VPC CIDR
• The target of the routes is the VPC peering connection ID, which is formatted as pcx-xxxxxxxxxxx
• 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, discussed in Chapter 5, Hybrid Networking with AWS Transit Gateway

VPC Peering Caveats

• VPC peering connections are non-transitive, so traffic cannot transit through a VPC and across another VPC peering connection
• Three VPCs: VPC-B peered to both VPC-A and VPC-C
• Traffic from VPC-A or VPC-C destined for VPC-B will be permitted and vice versa
• Traffic destined from VPC-A to VPC-C will be blocked

Transit VPC

• For a transitive solution, it is often recommended to use a service such as AWS TGW
• To create a transit VPC, every VPC is peered to every other VPC, a full-mesh topology
• Once the number of VPCs reaches a certain scale, managing this number of VPC peering connections can turn out to be a difficult task
• VPCs cannot have overlapping IP CIDR blocks for creating VPC peering connections, applies to IPv4 and IPv6, with both primary and secondary IP blocks considered

Inter-Region Maximum Transmission Unit (MTU)

• Creating VPC peering connections between VPCs that reside in different AWS regions is a supported configuration
• The MTU across inter-region peering connections is 1,500 bytes
• Intra-region peering connections support a jumbo MTU, or 9,001 bytes
• Within a region, the MTU is much higher, and applications could use jumbo frames
• Traffic between AWS regions is restricted to a standard 1,500 bytes and the applications must adjust 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

Considerations for VPC Peering Connections

• Routing across VPC peering connections is all dependent on static routes
• Update 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, 50 by default, but adjustable up to 125
• You cannot create multiple VPC peering connections between two VPCs
• Unicast reverse path forwarding is not supported for VPC peering
• If multiple VPCs with the same CIDR block are peered to the same VPC, implement longest match route table entries to achieve symmetric traffic

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 establishing the VPC peering connection
• The initiating VPC is the requester VPC and the receiving one is the accepter VPC
• The process is simple when peering VPCs within the same AWS account
• It 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 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

VPC Peering Connection Stages

• 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 and 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

• To configure an EIP, navigate to the VCP dashboard of the AWS console, select Peering connections, and choose the Create peering connection option using both AWS console and CLI
• VPC peering can be initiated to the same account or between AWS accounts, and the VPCs to peer will show in the drop-down menu
• It must be accepted, either in the same or separate account
• Created peering connection can be accepted using the AWS CLI

Hub-and-Spoke VPC Architectures

• This topology composes of a central “hub” network that then has connections with separate spokes, where all traffic is backhauled through these hubs
• Because VPCs are non-transitive, it is not possible to build this topology within AWS simply using VPC peering connections
• Use a transit VPC to achieve this topology, or a service such as AWS TGW

Transit VPC

• Use of IPsec VPN connectivity over the top of the standard VPC connectivity
• Deploy NVAs into a central VPC and then configure a series of IPsec VPN tunnels from these appliances to other VPCs
• NVAs can build IPsec connectivity to on-premises or other third-party networks

Transit VPC Options

• Build IPsec connectivity from the NVAs in the transit VPC to virtual private gateways (VGWs) residing in the spoke VPCs
• Build IPsec connectivity from the NVAs in the transit VPC to additional NVAs within the spoke VPCs
• Both 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

Potential Scenario for Transit VPC

• Trailcat has an expanded connectivity due to some quota limitation, such as the maximum number of routes in the VPC routing table, or if connecting to a third-party vendor

Option 1 strength

• 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

Option 2 strength

• Often these solutions are software-defined, which facilitates route exchange and connectivity between the NVAs

IP Address Overlap Management

• Provide connectivity between resources that have overlapping IP address ranges
• Use AWS NAT gateways

Private NAT Gateways for IP Overlaps

• Allow private subnets to talk to resources on the public internet or even other private resources within the AWS cloud or on-premises
• Example: Trailcats has acquired 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
• That would allow the VPC to initiate and establish connectivity
• NAT gateway requires that the workload using the NAT gateway is the one to initiate the communication
• If both sides initiate communication, a NAT gateway is needed for each subnet

Service Quotas Quick Reference

• The following table includes some AWS service quotas to 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
• Network interfaces per instance varies by instance type, not adjustable
• Network interfaces per region limit is 5,000, adjustable by AWS, at AWS' discretion
• Elastic IP addresses per region default limit is 5, adjustable by AWS at AWS' discretion
• Elastic IP addresses per NAT gateway limit is 2, adjustable to 8
• Prefix lists per region limit is 100, adjustable by AWS at AWS' discretion
• Versions per prefix list limit is 1,000, adjustable by AWS at AWS' discretion
• Maximum number of entries per prefix list limit is 1,000, adjustable by AWS at AWS' discretion
• Active VPC peering connections per VPC limit is 50, adjustable up to 125

Summary

• Deeper look into AWS networking components to build upon the fundamental networking services
• Focus on building connectivity and controlling connectivity in certain scenarios
• Concepts such as ENI, EIP, VPC peering, and prefix lists are a necessary foundation for the guide

Exam Readiness Drill Instructions

• Apart from mastering key concepts, strong test-taking skills under time pressure are essential for acing your certification exam
• Use 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
• Open the link or scan the QR code at the bottom of this page
• If you have unlocked the practice resources, log in
• Click the START button to start a quiz
• Attempt a quiz multiple times
• Use the provided template to plan your attempts