Extend your VPCs - Amazon Virtual Private Cloud
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China.

Extend your VPCs

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.

  • Amazon Outposts brings native Amazon 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 Amazon compute and storage services to the edge of telecommunication carriers' 5G networks.

Amazon 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 Amazon Wavelength FAQs.

Extend your VPC resources to Local Zones

Amazon Local Zones allow you to place resources closer to your end users, and seamlessly connect to the full range of services in the Amazon Region using familiar APIs and tool sets. You can extend your VPC Region by creating a new subnet that has a Local Zone assignment. When you create a subnet in a Local Zone, you extend the VPC to that Local Zone.

To use a Local Zone, you follow a three-step process:

  • First, opt in to the Local Zone.

  • Next, create a subnet in the Local Zone.

  • Finally, launch select resources in the Local Zone subnet, so that your applications are closer to your end users.

A network border group is a unique set of Availability Zones or Local Zones from which Amazon advertises public IP addresses.

When you create a VPC that has IPv6 addresses, you can choose to assign a set of Amazon-provided public IP addresses to the VPC, and 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 cannot move between network border groups. The us-west-2 network border group contains the four US West (Oregon) Availability Zones. The us-west-2-lax-1 network border group contains the Los Angeles Local Zones.

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.

  • You can assign Local Zones to subnets using the Amazon Virtual Private Cloud Console, Amazon CLI, or API.

  • 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).

  • You can request the IPv6 Amazon-provided IP addresses and associate them with the network border group for a new or existing VPC.

    Note

    IPv6 is supported in the Los Angeles Local Zones only.

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

For information about working with Local Zones in Linux, see Local Zones in the Amazon EC2 User Guide for Linux Instances. For information about working with Local Zones in Windows, see Local Zones in the Amazon EC2 User Guide for Windows Instances. Both guides contain a list of available Local Zones and the resources that you can launch in each Local Zone.

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 Elastic IP addresses.

    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 (IPv4).

  • 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 Amazon Direct Connect location in a Region. The on-premises data center has an Amazon Direct Connect connection to the Amazon Direct Connect location.

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 Amazon Site-to-Site VPN User Guide.

  • A Direct Connect connection. Amazon recommends that you use one of the following locations for the best latency performance to the LA Local Zones:

    • T5 at El Segundo, Los Angeles, CA (Amazon recommends this location for the lowest latency to the LA Local Zone)

    • CoreSite LA1, Los Angeles, CA

    • Equinix LA3, El Segundo, CA

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

  • A Direct Connect gateway. For information about creating a Direct Connect gateway, see Create a Direct Connect gateway in the Amazon 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 Amazon Direct Connect User Guide.

  • A private virtual interface on the connection from the Amazon 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 Amazon 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.


					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 in your VPC.

  • 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

Extend your VPC resources to Wavelength Zones

Amazon Wavelength allows developers to build applications that deliver ultra-low latencies to mobile devices and end-users. Wavelength deploys standard Amazon compute and storage services to the edge of telecommunication carriers' 5G networks. Developers can extend an Amazon Virtual Private Cloud (VPC) to one or more Wavelength Zones, and then use Amazon resources like Amazon Elastic Compute Cloud (EC2) instances to run applications that require ultra-low latency and connect to Amazon 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, Amazon CloudTrail, and Amazon CloudFormation. The services in Wavelength are part of a VPC that is connected over a reliable, high bandwidth connection to an Amazon 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 Amazon 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, Amazon 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 Amazon Region. For more information, see Amazon 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 in your VPC. 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 Amazon Outposts

Amazon Outposts offers you the same Amazon hardware infrastructure, services, APIs, and tools to build and run your applications on premises and in the cloud. Amazon 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 Amazon Outposts see Amazon Outposts.

Amazon VPC spans across all of the Availability Zones in an Amazon Region. When you connect Outposts to the parent Region, all existing and newly created VPCs in your account span across all Availability Zones and any associated Outpost locations in the Region.

The following rules apply to Amazon Outposts:

  • The subnets must reside in one Outpost location.

  • A local gateway handles the network connectivity between your VPC and on-premises networks. For information about local gateways, see Local Gateways in the Amazon Outposts User Guide.

  • If your account is associated with Amazon Outposts, you assign the subnet to an Outpost by specifying the Outpost ARN when you create the subnet.

  • By default, every subnet that you create in a VPC associated with an Outpost inherits the main VPC route table, including the local gateway route. You can also 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 that needs to be routed to the on-premises network.