Architect dual stack Amazon VPC with multiple IPv6 CIDR blocks

Introduction

With the increasing adoption of IPv6 on AWS, the need to create an easy-to-manage, hierarchical, and scalable IP addressing plan for Amazon Virtual Private Clouds (Amazon VPCs) becomes critical for customers. With IPv4, adding more CIDR blocks to a VPC was driven mainly by the need to increase the address space within a VPC. In IPv6, the address space is no longer a concern, and best practices for architecting scalable, easy-to-manage workloads take precedence. With the ability to add multiple IPv6 CIDRs to a VPC, you can use different IPv6 blocks to better segment you network infrastructure such as subnets, route tables, and security groups with different prefix ranges for different applications. Moreover, you can use a combination of BYOIPv6 and AWS-assigned CIDRs, and granularly control the IPv6 addresses that are routed in the internet, to achieve a clear separation of internal and external facing applications in your VPCs. Additionally, migration from one IPv6 address space to another is greatly simplified by this feature, as you’re no longer required to remove the existing IPv6 allocation and add a new one.

This post covers the use cases for multiple IPv6 CIDRs in the Amazon VPC, and provides guidance on how to accelerate your IPv6 adoption using a logical scalable addressing plan.

Prerequisites

Throughout this post, we’ll focus on the use cases presented, so we’re assuming that you have a basic understanding of the Amazon VPC functionalities, as well as the components like Internet Gateways, Egress-only Internet Gateways, Security Groups, Network ACLs, VPC Sharing, Amazon VPC IP Address Management (IPAM), AWS Transit Gateway, and AWS Direct Connect, in addition to how they work with IPv6. Refer to the IPv6 on AWS whitepaper for more detailed information on all of these constructs and how they support IPv6.

Getting Started

IPv6 CIDRs associated with Amazon VPCs can be added at creation time or post-creation by editing the VPC configuration. Furthermore, you can replace existing IPv6 CIDRs with new ones, as long as you don’t have any resources using IPv6 addresses. When configuring multiple IPv6 CIDRs on your VPC, you can add prefixes from the Amazon pool of addresses, or from your BYOIPv6 pools, in any combination that you need. Moreover, your BYOIPv6 pools can be managed through Amazon VPC IPAM or at an account level in Amazon Elastic Compute Cloud (Amazon EC2). It’s important to note that the IPv4 and IPv6 protocols and independent, so that you can edit each separately, without impacting the other stack.

Figure 1: Edit Amazon VPC IPv6 CIDRs

The following diagram shows an example of the options previously described, for the VPC IPv6 CIDRs: IPAM-allocated, Amazon-provided or account managed IPv6 CIDRs:

Figure 2: Adding a new CIDR to the Amazon VPC

Setup architecture

Our intended architecture, depicted in the following figure, uses two CIDR blocks in our VPCs: one that is AWS-assigned and routed in the Internet, and one configured using BYOIPv6 with Amazon VPC IPAM and not advertised to the Internet. The second IPv6 CIDR will only be routed in the internal network. Therefore, it’s part of a hierarchical, scalable addressing plan managed through IPAM.

Figure 3: Amazon VPC architecture with multiple IPv6 CIDRs

The IPv6 CIDR assigned from the AWS pool will be used for public-facing workloads in the VPC, such as Elastic Load Balancers (ELBs), public Amazon EC2 instances or web servers, and won’t be routed in the internal network. This design maps to a DMZ in the VPC, where we deploy the resources with a lower level of trust, and for which a separate set of security controls is enforced using security tools such as AWS Network Firewall or Gateway Load Balancer (GWLB) with third-party appliances. The BYOIPv6 CIDR associated to the VPC won’t be advertised to the Internet from AWS, and will accommodate workloads that require full privacy.

Routing controls with multiple IPv6 CIDRs

The need to secure internet connectivity at an organization level by implementing specific routing controls has motivated AWS customers to want to maintain a clear separation between the IPv6 CIDR blocks that are routed in the Internet and the ones that are considered for internal use only. With Amazon VPC currently supporting IPv6 addresses from the Global Unicast Address (GUA) space, i.e., prefixes that are routable in the Internet without requiring Network Address Translation (NAT), mechanisms to completely isolate private workloads running on IPv6 from any public facing traffic became critical, as part of an in-depth defense strategy.

The ability to associate multiple IPv6 CIDR blocks to a VPC allows you to completely segregate the Internet-facing section of a VPC from the internal-only routed resources and workloads. The routing controls add up to the overall strategy for implementing security at every layer of the network stack, and they shouldn’t be viewed as a sole mechanism for achieving the desired security posture. The adequate configuration of Network Access Control lists (NACLs), security groups, and firewall functions in the network is critical for a highly secure environment. See the following considerations for IPv6 security and monitoring on AWS.

In our setup, the IPAM-assigned IPv6 CIDR of the VPC isn’t routed in the Internet. The setting for the advertised status is configured on the Amazon VPC IPAM pool, as shown in the following figure:

Figure 4: Withdrawn IPv6 CIDR in Amazon VPC IPAM

The /48 IPv6 prefix associated with the pool that we used to allocate the /56 VPC IPv6 CIDR is “withdrawn”, which means that AWS isn’t advertising it on the Internet. Therefore, the prefix isn’t routed, making it fully private on AWS. At the VPC level, as our intention is to keep the Internal subnets fully private and not Internet routed, the CIDR allocation for each subnet is planned to meet the requirements:

Figure 5: Segmented VPC subnets with IPv6 CIDRs

Subnets using the AWS-assigned IPv6 space can be configured as public facing, with a route of ::/0 pointing to Internet Gateway. Furthermore, they can be private subnets, with default connectivity through the Egress-only Internet Gateway. Private subnets on IPv6 maintain the same security posture as on IPv4 – outbound Internet communication over IPv6 from instances and workloads in these private routed subnets is enabled, but all Internet generated communication is blocked.

Figure 6: Public and Private DMZ Subnets default route

For the subnets from the IPAM-assigned, not advertised IPv6 VPC CIDR, default route configuration can’t be configured through the IGW or EIGW, as the addresses aren’t routed in the Internet. Therefore, network connectivity for these subnets can be only achieved using private routing constructs, such as Amazon VPC peering, Transit Gateway, Direct Connect, or Amazon VPN.

For the purposes of this post, we’ve distilled private connectivity to a default route pointing to the Transit Gateway, which acts as the centralized routing hub for our network:

Figure 7: Private Internal Route table default route

Depending on the level of security and controls needed, you can also route the traffic from the DMZ in the internal network, either using the same AWS Transit Gateway and consequent route table, or an additional one that would impose a more secure inspection and filtering of traffic.

Figure 8: Routing separation and control for security

Amazon VPC Sharing controls with multiple IPv6 CIDRs

An important use case for multiple IPv6 CIDRs on a VPC is the ability to segregate the types of workloads by assigning them to specific subnets, depending on their role and connectivity needs. Connectivity-wise, the different routing policies can be mapped to the decision points that we mentioned above, and by further separating workloads based on IPv6 address ranges, you can facilitate a simplified VPC sharing strategy.

Let’s consider the VPC in the example above, and share subnets with different accounts based on their needs. For this post, we’ll consider that Accounts A, B, and C manage three different services, with separate connectivity needs. Service A needs Internet-connectivity so that Account A will receive a public subnet in each of the two AZs. Services B and C must be private, but Service B must not be able to directly access the internal network, as per the security policy, while Service C needs connectivity to the internal Shared Services. Service B will receive a Private DMZ Subnet in each AZ, while Service C will receive a Private Internal Subnet in each AZ.

Figure 9: VPC Sharing with multiple IPv6 CIDRs

Simplified migration to BYOIPv6

Finally, one of the benefits of associating multiple IPv6 CIDRs to a VPC is to facilitate migration between different addressing schemes. When starting on the IPv6 adoption journey, one of the first steps is creating a logical, scalable, and hierarchical addressing plan that lets you easily summarize regional blocks and environment-related blocks. The goal is to minimize the size of your route tables and the number of prefixes that you advertise over Direct Connect or Site-to-Site VPN connections. The ability to add multiple CIDRs on a VPC facilitates the transition to a hierarchical addressing plan by allowing you to use a BYOIPv6 CIDR from a block managed through Amazon VPC IPAM, as showed above, and gradually migrate your workloads to use the new IPv6 addresses.

Conclusion

This post helps you get started with multiple IPV6 CIDRs on an Amazon VPC. We’ve reviewed the most important use cases, benefits, and architectures that enable you to easily segment your network infrastructure at the network level, as well as control the reachability and connectivity of your AWS workloads. If you have questions about this post, then start a new thread on the Amazon Networking and Content Delivery Forum, AWS re:Post or contact AWS Support.

About the authors