Extend a VPC to a Local Zone, Wavelength Zone, or Outpost - Amazon Virtual Private Cloud

Extend a VPC to a Local Zone, Wavelength Zone, or Outpost

You can host VPC resources, such as subnets, in multiple locations world-wide. These locations are composed of Regions, Availability Zones, Local Zones, and Wavelength Zones. Each Region is a separate geographic area.

  • Availability Zones are multiple, isolated locations within each Region.

  • Local Zones allow you to place resources, such as compute and storage, in multiple locations closer to your end users.

  • AWS Outposts brings native AWS services, infrastructure, and operating models to virtually any data center, co-location space, or on-premises facility.

  • Wavelength Zones allow developers to build applications that deliver ultra-low latencies to 5G devices and end users. Wavelength deploys standard AWS compute and storage services to the edge of telecommunication carriers' 5G networks.

AWS operates state-of-the-art, highly available data centers. Although rare, failures can occur that affect the availability of instances that are in the same location. If you host all of your instances in a single location that is affected by a failure, none of your instances would be available.

To help you determine which deployment is best for you, see AWS Wavelength FAQs.

Subnets in AWS Local Zones

AWS Local Zones allow you to place resources closer to your users, and seamlessly connect to the full range of services in the AWS Region, using familiar APIs and tool sets. When you create a subnet in a Local Zone, you extend the VPC to that Local Zone.

To use a Local Zone, you use the following process:

  • Opt in to the Local Zone.

  • Create a subnet in the Local Zone.

  • Launch resources in the Local Zone subnet, so that your applications are closer to your users.

The following diagram illustrates a VPC in the US West (Oregon) (us-west-2) Region that spans Availability Zones and a Local Zone.


				A VPC with Availability Zones and a Local Zone.

When you create a VPC, you can choose to assign a set of Amazon-provided public IP addresses to the VPC. You can also set a network border group for the addresses that limits the addresses to the group. When you set a network border group, the IP addresses can't move between network border groups. Local Zone network traffic will go directly to the internet or to points-of-presence (PoPs) without traversing the Local Zone's parent Region, enabling access to low-latency computing. For the complete list of Local Zones and their corresponding parent Regions, see Available Local Zones in the AWS Local Zones User Guide.

The following rules apply to Local Zones:

  • The Local Zone subnets follow the same routing rules as Availability Zone subnets, including route tables, security groups, and network ACLs.

  • Outbound internet traffic leaves a Local Zone from the Local Zone.

  • You must provision public IP addresses for use in a Local Zone. When you allocate addresses, you can specify the location from which the IP address is advertised. We refer to this as a network border group, and you can set this parameter to limit the addresses to this location. After you provision the IP addresses, you cannot move them between the Local Zone and the parent Region (for example, from us-west-2-lax-1a to us-west-2).

  • If the Local Zone supports IPv6, you can request IPv6 Amazon-provided IP addresses and associate them with the network border group for a new or existing VPC. For the list of Local Zones that support IPv6, see Considerations in the AWS Local Zones User Guide

  • You can't create VPC endpoints in Local Zone subnets.

For more information about working with Local Zones, see the AWS Local Zones User Guide.

Considerations for internet gateways

Take the following information into account when you use internet gateways (in the parent Region) in Local Zones:

  • You can use internet gateways in Local Zones with Elastic IP addresses or Amazon auto-assigned public IP addresses. The Elastic IP addresses that you associate must include the network border group of the Local Zone. For more information, see Associate Elastic IP addresses with resources in your VPC.

    You cannot associate an Elastic IP address that is set for the Region.

  • Elastic IP addresses that are used in Local Zones have the same quotas as Elastic IP addresses in a Region. For more information, see Elastic IP addresses.

  • You can use internet gateways in route tables that are associated with Local Zone resources. For more information, see Routing to an internet gateway.

Access Local Zones using a Direct Connect gateway

Consider the scenario where you want an on-premises data center to access resources that are in a Local Zone. You use a virtual private gateway for the VPC that's associated with the Local Zone to connect to a Direct Connect gateway. The Direct Connect gateway connects to an AWS Direct Connect location in a Region. The on-premises data center has an AWS Direct Connect connection to the AWS Direct Connect location.

Note

Traffic within the US that is destined for a subnet in a Local Zone using Direct Connect does not travel through the parent Region of the Local Zone. Instead, traffic takes the shortest path to the Local Zone. This decreases latency and helps make your applications more responsive.

You configure the following resources for this configuration:

  • A virtual private gateway for the VPC that is associated with the Local Zone subnet. You can view the VPC for the subnet on the subnet details page in the Amazon Virtual Private Cloud Console, or use describe-subnets.

    For information about creating a virtual private gateway, see Create a target gateway in the AWS Site-to-Site VPN User Guide.

  • A Direct Connect connection. For the best latency performance, AWS recommends that you use the Direct Connect location closest to the Local Zone to which you'll be extending your subnet.

    For information about ordering a connection, see Cross connects in the AWS Direct Connect User Guide.

  • A Direct Connect gateway. For information about creating a Direct Connect gateway, see Create a Direct Connect gateway in the AWS Direct Connect User Guide.

  • A virtual private gateway association to connect the VPC to the Direct Connect gateway. For information about creating a virtual private gateway association, see Associating and disassociating virtual private gateways in the AWS Direct Connect User Guide.

  • A private virtual interface on the connection from the AWS Direct Connect location to the on-premises data center. For information about creating a Direct Connect gateway, see Creating a private virtual interface to the Direct Connect gateway in the AWS Direct Connect User Guide.

Connect Local Zone subnets to a transit gateway

You can't create a transit gateway attachment for a subnet in a Local Zone. The following diagram shows how to configure your network so that subnets in the Local Zone connect to a transit gateway through the parent Availability Zone. Create subnets in the Local Zones and subnets in the parent Availability Zones. Connect the subnets in the parent Availability Zones to the transit gateway, and then create a route in the route table for each VPC that routes traffic destined for the other VPC CIDR to the network interface for the transit gateway attachment.

Note

Traffic destined for a subnet in a Local Zone that originates from a transit gateway will first traverse the parent Region.


					Local Zone to transit gateway

Create the following resources for this scenario:

  • A subnet in each parent Availability Zone. For more information, see Create a subnet.

  • A transit gateway. For more information, see Create a transit gateway in Amazon VPC Transit Gateways.

  • A transit gateway attachment for each VPC using the parent Availability Zone. For more information, see Create a transit gateway attachment to a VPC in Amazon VPC Transit Gateways.

  • A transit gateway route table associated with the transit gateway attachment. For more information, see Transit gateway route tables in Amazon VPC Transit Gateways.

  • For each VPC, an entry in the VPC route table that has the other VPC CIDR as the destination, and the ID of the network interface for the transit gateway attachment as the target. To find the network interface for the transit gateway attachment, search the descriptions of your network interfaces for the ID of the transit gateway attachment. For more information, see Routing for a transit gateway.

The following is an example route table for VPC 1.

Destination Target

VPC 1 CIDR

local

VPC 2 CIDR

vpc1-attachment-network-interface-id

The following is an example route table for VPC 2.

Destination Target

VPC 2 CIDR

local

VPC 1 CIDR

vpc2-attachment-network-interface-id

The following is an example of the transit gateway route table. The CIDR blocks for each VPC propagate to the transit gateway route table.

CIDR Attachment Route type

VPC 1 CIDR

Attachment for VPC 1

propagated

VPC 2 CIDR

Attachment for VPC 2

propagated

Subnets in AWS Wavelength

AWS Wavelength allows developers to build applications that deliver ultra-low latencies to mobile devices and end-users. Wavelength deploys standard AWS compute and storage services to the edge of telecommunication carriers' 5G networks. Developers can extend a virtual private cloud (VPC) to one or more Wavelength Zones, and then use AWS resources like Amazon EC2 instances to run applications that require ultra-low latency and connect to AWS services in the Region.

To use a Wavelength Zones, you must first opt in to the Zone. Next, create a subnet in the Wavelength Zone. You can create Amazon EC2 instances, Amazon EBS volumes, and Amazon VPC subnets and carrier gateways in Wavelength Zones. You can also use services that orchestrate or work with EC2, EBS, and VPC, such as Amazon EC2 Auto Scaling, Amazon EKS clusters, Amazon ECS clusters, Amazon EC2 Systems Manager, Amazon CloudWatch, AWS CloudTrail, and AWS CloudFormation. The services in Wavelength are part of a VPC that is connected over a reliable, high bandwidth connection to an AWS Region for easy access to services including Amazon DynamoDB and Amazon RDS.

The following rules apply to Wavelength Zones:

  • A VPC extends to a Wavelength Zone when you create a subnet in the VPC and associate it with the Wavelength Zone.

  • By default, every subnet that you create in a VPC that spans a Wavelength Zone inherits the main VPC route table, including the local route.

  • When you launch an EC2 instance in a subnet in a Wavelength Zone, you assign a carrier IP address to it. The carrier gateway uses the address for traffic from the interface to the internet, or mobile devices. The carrier gateway uses NAT to translate the address, and then sends the traffic to the destination. Traffic from the telecommunication carrier network routes through the carrier gateway.

  • You can set the target of a VPC route table, or subnet route table in a Wavelength Zone to a carrier gateway, which allows inbound traffic from a carrier network in a specific location, and outbound traffic to the carrier network and internet. For more information about routing options in a Wavelength Zone, see Routing in the AWS Wavelength Developer Guide.

  • Subnets in Wavelength Zones have the same networking components as subnets in Availability Zones, including IPv4 addresses, DHCP option sets, and network ACLs.

  • You can't create a transit gateway attachment to a subnet in a Wavelength Zone. Instead, create the attachment through a subnet in the parent Availability Zone, and then route traffic to the desired destinations through the transit gateway. For an example, see the next section.

Considerations for multiple Wavelength Zones

EC2 instances that are in different Wavelength Zones in the same VPC are not allowed to communicate with each other. If you need Wavelength Zone to Wavelength Zone communication, AWS recommends that you use multiple VPCs, one for each Wavelength Zone. You can use a transit gateway to connect the VPCs. This configuration enables communication between instances in the Wavelength Zones.

Wavelength Zone to Wavelength Zone traffic routes through the AWS Region. For more information, see AWS Transit Gateway.

The following diagram shows how to configure your network so that instances in two different Wavelength Zones can communicate. You have two Wavelength Zones (Wavelength Zone A and Wavelength Zone B). You need to create the following resources to enable communication:

  • For each Wavelength Zone, a subnet in an Availability Zone that is the parent Availability Zone for the Wavelength Zone. In the example, you create subnet 1 and subnet 2. For information about creating subnets, see Create a subnet. Use describe-availability-zones to find the parent zone.

  • A transit gateway. The transit gateway connects the VPCs. For information about creating a transit gateway, see Create a transit gateway in the Amazon VPC Transit Gateways Guide.

  • For each VPC, a VPC attachment to the transit gateway in the parent Availability Zone of the Wavelength Zone. For more information, see Transit gateway attachments to a VPC in the Amazon VPC Transit Gateways Guide.

  • Entries for each VPC in the transit gateway route table. For information about creating transit gateway routes, see Transit gateway route tables in the Amazon VPC Transit Gateways Guide.

  • For each VPC, an entry in the VPC route table that has the other VPC CIDR as the destination, and the transit gateway ID as the target. For more information, see Routing for a transit gateway.

    In the example, the route table for VPC 1 has the following entry:

    Destination Target

    10.1.0.0/24

    tgw-22222222222222222

    The route table for VPC 2 has the following entry:

    Destination Target

    10.0.0.0/24

    tgw-22222222222222222

					Multiple Wavelength Zones

Subnets in AWS Outposts

AWS Outposts offers you the same AWS hardware infrastructure, services, APIs, and tools to build and run your applications on premises and in the cloud. AWS Outposts is ideal for workloads that need low latency access to on-premises applications or systems, and for workloads that need to store and process data locally. For more information about AWS Outposts, see AWS Outposts.

A VPC spans all Availability Zones in an AWS Region. After you connect your Outpost to its parent Region, you can extend any VPC in the Region to your Outpost by creating a subnet for the Outpost in that VPC.

The following rules apply to AWS Outposts:

  • The subnets must reside in one Outpost location.

  • You create a subnet for an Outpost by specifying the Amazon Resource Name (ARN) of the Outpost when you create the subnet.

  • Outposts rack - A local gateway handles the network connectivity between your VPC and on-premises networks. For more information, see Local gateways in the AWS Outposts User Guide for Outposts rack.

  • Outposts servers - A local network interface handles the network connectivity between your VPC and on-premises networks. For more information, see Local network interfaces in the AWS Outposts User Guide for Outposts servers.

  • By default, every subnet that you create in a VPC, including subnets for your Outposts, is implicitly associated with the main route table for the VPC. Alternatively, you can explicitly associate a custom route table with the subnets in your VPC and have a local gateway as a next-hop target for all traffic destined for your on-premises network.


				A VPC with Availability Zones and an Outpost.