How do I migrate my Networking and Content Delivery resources to another region?

If you are migrating data from the Middle East (UAE) Region (me-central-1), then you might experience increased error rates as we continue making progress with restoration efforts. For additional information about recovery efforts and service updates that impact your AWS accounts, see the AWS Personal Health Dashboard. For assistance with this event, contact AWS Support through the AWS Management Console or the AWS Support Center.

This is part of a series of articles that provide general guidance on migrating resources form one Region to another. It covers the following services:

• Amazon API Gateway
• Amazon Route 53
• AWS Client VPN
• AWS Direct Connect
• AWS Network Firewall
• AWS Site-to-Site VPN
• AWS Transit Gateway
• AWS WAF
• Elastic Load Balancing (ELB), including Application Load Balancer and Network Load Balancer

For general guidance and a full list of domain and service-specific migration guides, see How do I migrate my resources to another region?

For other domains, see the following resources:

• How do I migrate my Security, Identity and Compliance resources to another region?
• How do I migrate my Compute and Container resources to another region?
• How do I copy an EBS Snapshot to another region using coldsnap and the EBS Direct APIs?
• How do I migrate my Database resources to another region?
• How do I migrate my Database resources to another region using a logical dump?
• How do I migrate my Storage resources to another region?
• How do I migrate my Application Integration resources to another region?

Amazon API Gateway

Key Considerations and Preparation

• API Gateway is a regional service
• REST APIs (v1), HTTP APIs (v2), and WebSocket APIs (v2) use different CLI namespaces
• Custom domain names and ACM certificates are regional and must be recreated
• Authorizers and integrations must exist in the target region
• WAF associations must be recreated separately
• KMS keys (if used) are regional

Identify and Export the API Definition

Determine the API type and export the definition for migration to the target region.

1. Identify the API type using API Gateway REST APIs or API Gateway HTTP APIs
2. Export the API definition via the Export a REST API from API Gateway console, the get-export CLI for REST APIs, or the export-api CLI for HTTP/WebSocket APIs

Import and Deploy the API in the Target Region

Use the exported definition to create the API in the new region and deploy it.

1. Import the API using the Develop REST APIs using OpenAPI in API Gateway console, the import-rest-api CLI for REST APIs, or the import-api CLI for HTTP/WebSocket APIs
2. Deploy the API using the Deploy REST APIs in API Gateway console or the create-deployment CLI

Recreate Regional Configuration

Recreate any additional regional resources that were associated with the original API.

1. Recreate Custom domain name for public REST APIs in API Gateway
2. Recreate Use API mappings to connect API stages to a custom domain name for REST APIs
3. Recreate Usage plans and API keys for REST APIs in API Gateway
4. Recreate Set up a private integration for VPC links
5. Recreate Use AWS WAF to protect your REST APIs in API Gateway
6. Review and recreate KMS configuration if applicable using Create a KMS key and Multi-Region keys in AWS KMS

---

Amazon Route 53

Key Consideration and Prerequisites

• Route 53 hosted zones (public and private) and domain registrations are global resources, not regional; they do not need to be migrated between regions
• Route 53 Resolver endpoints (inbound and outbound), forwarding rules, and DNS Firewall configurations are regional and must be recreated in the target region
• Health checks are global resources and do not need to be recreated per region, but new health checks should be created for any new endpoints deployed in the target region.
• Alias records that point to regional AWS resources (such as ELB, API Gateway, or CloudFront) must be updated to reference the corresponding resources in the target region
• Routing policies (failover, latency, geolocation, weighted) may need to be updated to include endpoints in the target region
• Private hosted zones must be associated with VPCs in the target region to enable DNS resolution for those VPCs
• If your domain's nameservers (NS records) point to a third-party DNS provider rather than Route 53, you must update DNS records at your external provider to point to the new AWS resources in the target region
• Review What is Amazon Route 53? for an overview of the service components

Update Records to Reference Target Region Resources

Alias records and other records that point to regional AWS resources must be updated to reference the new resources in the target region.

1. List existing records using the list-resource-record-sets CLI to identify records that reference source region resources
2. Update or create records to point to the target region resources using the Creating records by using the Amazon Route 53 console console or the change-resource-record-sets CLI
3. Review routing policies and update latency, failover, geolocation, or weighted records as needed using Choosing a routing policy

Associate Private Hosted Zones with Target Region VPCs

Private hosted zones must be associated with VPCs in the target region to enable DNS resolution within those VPCs.

1. Associate the existing private hosted zone with VPCsin the target region using the console or the associate-vpc-with-hosted-zone CLI
2. If a new private hosted zone is required, create one and associate it with the target region VPCs using the create-hosted-zone CLI with the --vpc parameter
3. Create the necessary records in the private hosted zone for the target region resources

Recreate Route 53 Resolver Endpoints and Rules

Resolver endpoints and forwarding rules are regional and must be recreated in the target region to enable hybrid DNS resolution.

1. Create inbound Resolver endpoints in the target region using Forwarding inbound DNS queries to your VPCs or the create-resolver-endpoint CLI with --direction INBOUND
2. Create outbound Resolver endpoints in the target region using Forwarding outbound DNS queries to your network or the create-resolver-endpoint CLI with --direction OUTBOUND
3. Recreate forwarding rules and associate them with VPCs in the target region
4. Recreate any DNS Firewall rule groups and associations in the target region

Recreate Health Checks for Target Region Endpoints

Health checks are global but may need to be created for new endpoints in the target region.

1. Create health checks for the new target region endpoints using Creating and updating health checks
2. Associate the new health checks with the corresponding DNS records (failover, latency, or weighted) in the hosted zone

Update External DNS Provider When SOA Is Outside Route 53

If your domain's SOA (Start of Authority) and DNS are managed by a third-party provider outside of Route 53, you must update the DNS records at your external provider to point to the new AWS resources in the target region.

1. Identify all DNS records at your external provider that reference AWS regional endpoints (such as ELB DNS names, API Gateway URLs, CloudFront distributions, or EC2 Elastic IPs in the source region)
2. Deploy the replacement AWS resources in the target region and note their new endpoints, DNS names, or IP addresses
3. Update the A, AAAA, or CNAME records at your external DNS provider to point to the new target region endpoints
4. If using CNAME records for ACM certificate validation, verify that the existing CNAME records remain in place; the same validation CNAME works across regions
5. Lower the TTL on affected records at your external provider before the cutover to reduce propagation delay, then restore the TTL after migration is confirmed
6. Verify DNS resolution from multiple locations to confirm the records are resolving to the target region resources

---

AWS Client VPN

Migrate AWS Client VPN to Another Region

• Client VPN endpoints cannot be migrated between regions - you must recreate the endpoint in the target region
• You cannot export private keys from ACM - generate new certificates if the originals are unavailable
• Client CIDR blocks cannot overlap with the VPC CIDR in the target region
• Maximum 5 target network associations per endpoint
• DNS servers must be reachable from associated subnets
• Connection logs require CloudWatch Logs permissions
• Plan for certificate renewal as ACM certificates expire
• Export your current endpoint configuration using the describe-client-vpn-endpoints CLI and document key details (CIDR, DNS, split tunnel, protocol, port, authentication options, logging)

Recreate Client VPN Endpoint in Target Region

Use this workflow to recreate your Client VPN endpoint with the same configuration in a new region.

1. Retrieve the server certificate ARN from the ACM console in the source region. If originals are unavailable, generate new server and client certificates
2. Import the server and client certificates into ACM in the target region
3. Create a Client VPN endpoint in the target region matching the source configuration (CIDR, DNS, split tunnel, protocol, port, and authentication options)
4. Associate target VPC subnets with the new endpoint
5. Configure authorization rules to control network access for connected clients
6. Apply security groups in the target region
7. Download the new client configuration file and add certificates if using mutual authentication

Cut Over to the New Client VPN Endpoint

Use this workflow after validating the new endpoint to transition users.

1. Distribute the .ovpn configuration file to test users and verify connectivity, DNS resolution, split tunnel behavior, and CloudWatch logs
2. Communicate the maintenance window to all users
3. Distribute the new configuration files and instruct users to import the new profile
4. Monitor CloudWatch logs to confirm successful connections
5. Decommission the old Client VPN endpoint in the source region

For additional guidance, review the AWS Client VPN Administrator Guide.

---

AWS Direct Connect

Migrate AWS Direct Connect Connectivity to Another Region

• Your existing Direct Connect Gateway can be reused across regions - a new physical connection is not required if you already have a Direct Connect Gateway
• Virtual Private Gateways and/or Transit Gateways must exist in the new region and be attached to the target VPC before associating with the Direct Connect Gateway
• Allowed prefixes must not overlap or conflict between associations
• Review the AWS Direct Connect + AWS Transit Gateway across multiple Regions and AWS public peering whitepaper and hybrid connectivity guidance for architecture patterns

Extend Direct Connect Gateway to a New Region

Use this workflow to connect your existing Direct Connect Gateway to resources in a new region using a new virtual interface.

1. Create a Virtual Private Gateway or Transit Gateway in the new region using the create-vpn-gateway or create-transit-gateway, and attach it to your VPC
2. Create a virtual interface for the new region - either a private virtual interface or a transit virtual interface depending on your architecture
3. Associate the Direct Connect Gateway with the VGW or TGW in the new region and configure the correct allowed prefixes following the VGW association guide or TGW association guide
4. Complete the customer gateway configuration on your router following the router configuration guide
5. Validate connectivity by verifying the BGP session, route propagation, network connectivity, Direct Connect Gateway associations, and CloudWatch metrics

Troubleshoot Direct Connect Connectivity Issues

Use this workflow if connectivity validation fails after migration.

1. Verify the VLAN ID matches on both the AWS side and customer router
2. Confirm BGP ASN, authentication key, and IP addressing are correct
3. Check that allowed prefixes do not overlap or conflict between associations
4. Verify route table associations and propagation settings in the new region
5. Review VPC security groups and network ACLs for the target VPC
6. Check Direct Connect location and port status in the console
7. Review the AWS Direct Connect troubleshooting guide for additional diagnostics

---

AWS Network Firewall

Migrate AWS Network Firewall to Another Region

• Network Firewall resources cannot be moved between regions - you must recreate them in the target region
• AWS does not provide backup or restore functionality for Network Firewall across regions
• Firewall endpoints are bound to specific subnets and Availability Zones - traffic inspection relies on endpoint ENIs referenced in VPC and Transit Gateway route tables
• Policies, rule groups, and service quotas must match between source and target regions
• CloudWatch Logs, S3 buckets, and Kinesis streams for logging must be configured per region
• Infrastructure as Code templates (Terraform/CloudFormation/SDK) for network and firewall resources are recommended
• For single-endpoint firewalls, an AZ failure stops traffic inspection. Multi-endpoint firewalls continue inspecting traffic in healthy AZs
• Review Network Firewall architectures and deployment models before starting

Recreate Network Firewall in Target Region

Use this workflow to recreate your complete Network Firewall configuration in a new region.

1. Deploy supporting infrastructure in the target region including VPC, subnets, Internet Gateway, NAT Gateways, and Transit Gateway with attachments across multiple AZs. Review deployment models with VPC routing enhancements for architecture guidance
2. Create the Network Firewall matching the source region configuration with endpoints across multiple AZs, or use the create-firewall CLI
3. Recreate stateless and stateful rule groups from the source region, then create a firewall policy with rule group associations matching the source evaluation order, or use the create-firewall-policy
4. Configure firewall logging by setting up CloudWatch Log Groups, S3 buckets, or Kinesis Data Firehose and enabling flow and alert logging, or use the update-logging-configuration
5. Update Network Firewall route tables and VPC route tables to direct traffic through firewall endpoints, ensuring each AZ routes to its local endpoint
6. Verify the firewall status is READY, all endpoints are operational, routing is correct, traffic flows through the firewall, and logs show rule enforcement

Troubleshoot Network Firewall Connectivity

Use this workflow if traffic inspection or connectivity issues occur after migration.

1. Verify firewall endpoints are in the correct subnets and Availability Zones
2. Check route table associations and confirm routes point to the correct firewall endpoints
3. Confirm security groups allow traffic to and from firewall subnets, and verify network ACLs allow required traffic
4. Check rule group capacity and service quotas in the target region
5. Validate stateful rule evaluation order matches the source region configuration
6. Review firewall logs for dropped packets and confirm logging destinations have correct permissions
7. Check for asymmetric routing issues and verify NAT Gateway and Internet Gateway configurations
8. Review the Troubleshooting Network Firewall guide and Network Firewall monitoring documentation for additional diagnostics

---

AWS Site-to-Site VPN

Migrate AWS Site-to-Site VPN to Another Region

• VPN connections cannot be migrated between regions - you must create a new VPN and all its components in the target region
• A Customer Gateway, Virtual Private Gateway (if used), and Transit Gateway (if used) must be created in the new region before creating the VPN connection
• Review the customer gateway device requirements and customer gateway best practices before starting
• Use the describe-vpn-connections CLI to document your existing VPN configuration before migration

Recreate Site-to-Site VPN in Target Region

Use this workflow to create a new Site-to-Site VPN connection in the target region.

1. Create a new Customer Gateway in the target region using the create-customer-gateway
2. Create a new Virtual Private Gateway using the create-vpn-gateway, or create a new Transit Gateway using the create-transit-gateway, depending on your architecture
3. Create a new VPN connection associating the Customer Gateway with the VGW or TGW
4. Download the VPN configuration file and apply it to your customer gateway device
5. Configure VPC route tables and security groups in the target region
6. Verify tunnel status is UP, BGP sessions are established, routes are propagated, and connectivity works in both directions

Troubleshoot Site-to-Site VPN Connectivity

Use this workflow if VPN tunnels fail to establish or connectivity issues occur after migration.

1. Verify the Customer Gateway public IP is reachable and firewall rules allow UDP 500 and UDP 4500
2. Confirm pre-shared keys match exactly between AWS and the customer gateway device
3. Check IKE version and encryption algorithm compatibility between both sides
4. Validate BGP configuration and ASN numbers if using dynamic routing
5. Verify NAT-T is enabled if the customer gateway device is behind NAT
6. Check route table associations and propagation settings in the VPC
7. Review VPC security groups and network ACLs for required traffic
8. Check for asymmetric routing issues between the two tunnels

For additional guidance, review the AWS Site-to-Site VPN getting started guide.

---

AWS Transit Gateway

Migrate AWS Transit Gateway to Another Region

• Transit Gateways cannot be migrated between regions - you must create a new Transit Gateway in the target region
• Understand your connectivity use case (VPC-to-VPC, VPC-to-on-premises, or both) before starting
• Prepare a network diagram of your current architecture to aid in recreating the setup
• Centralized inspection architectures require two or more isolated route tables
• Follow the Transit Gateway best design practices when setting up the new Transit Gateway

Recreate Transit Gateway for VPC-to-VPC Connectivity

Use this workflow to recreate Transit Gateway connectivity between VPCs in the target region.

1. Create a Transit Gateway in the target region using the create-transit-gatewayor follow the Transit Gateway getting started guide
2. Create VPC attachments to connect the Transit Gateway to your source and destination VPCs
3. Configure Transit Gateway route tables based on your use case following the Transit Gateway scenarios
4. Add static routes in your VPC route tables pointing to the Transit Gateway ID in each attached VPC

Add On-Premises Connectivity to Transit Gateway

Use this workflow after completing VPC-to-VPC setup to extend connectivity to on-premises networks via VPN or Direct Connect.

1. Create a VPN attachment for Site-to-Site VPN connectivity to the Transit Gateway
2. Associate your Direct Connect Gateway with the Transit Gateway and configure allowed prefixes following the Transit Gateway Direct Connect attachment guide and Direct Connect Transit Gateway guide
3. Configure Transit Gateway route tables for on-premises connectivity following the Transit Gateway scenarios

Validate and Troubleshoot Transit Gateway Connectivity

Use this workflow to verify the migration and resolve connectivity issues.

1. Verify all Transit Gateway and attachment states show as "available"
2. Confirm routes in both Transit Gateway and VPC route tables are correct with no blackhole routes
3. Test connectivity using ping and traceroute between endpoints
4. Check CloudWatch metrics for traffic flow and verify no packet drops
5. Confirm security groups and network ACLs allow the required traffic
6. Validate BGP sessions for VPN and Direct Connect attachments
7. Verify attachment subnet Availability Zones match Transit Gateway AZs and check for overlapping CIDR blocks
8. Review appliance mode settings if using centralized inspection architectures and check for asymmetric routing issues

---

Elastic Load Balancing (Application Load Balancer / Network Load Balancer)

Key considerations and Prerequisites

• Load balancers are regional resources and cannot be directly moved between regions — this process involves recreating the configuration in the target region
• Ensure supporting infrastructure exists in target region: VPC with appropriate subnets across multiple AZs, security groups, target instances/services (EC2, ECS, Lambda), and SSL/TLS certificates in ACM (critical for HTTPS/TLS listeners)
• Document current configuration including load balancer details, SSL/TLS certificates, listeners, target groups, and advanced settings
• Export all configuration details from source region: load balancer configuration, all listener configurations (including certificates), all target group configurations and attributes, listener rules, load balancer attributes, tags, and certificate details from ACM
• NLB IPs will change — update any firewall rules or IP allowlists
• If using AWS WAF with ALB, recreate Web ACLs in the target region

Migrate SSL/TLS Certificates

ACM-Managed Certificates (for AWS-issued certificates)

1. Request a new certificate in the target region using the same domain name and SANs as source, choose DNS validation method and optionally specify key algorithm. Request a certificate
2. Retrieve CNAME validation records from ACM and add records to your DNS provider (Route 53, GoDaddy, etc.). DNS validation
3. Monitor certificate status until "ISSUED" and verify certificate is valid before proceeding

Imported Certificates (for user-provided certificates)

1. Verify certificate files are available: certificate file (e.g. certificate.pem), private key file (e.g. private-key.pem), and certificate chain file (e.g. certificate-chain.pem)
2. Import all three files to ACM in the target region. Import certificates
3. Verify import successful and document new certificate ARN

Prepare Target Region Infrastructure

Complete this before creating the load balancer.

1. Create VPC resources if not existing: VPC with appropriate CIDR, subnets in multiple AZs, Internet Gateway (for internet-facing ELBs), and route tables configured.
2. Replicate security groups by creating security groups with same names as source, adding all ingress rules (HTTP, HTTPS, custom ports) and egress rules, and documenting security group IDs.
3. Ensure EC2 instances/containers/Lambda running in target region, verify resources in correct subnets, confirm security groups allow traffic from ELB, and test application health endpoints

Create Load Balancer in Target Region

Complete this after preparing infrastructure.

1. Create load balancer by choosing same type (application or network), selecting same scheme (internet-facing or internal), choosing subnets in multiple AZs, attaching security groups, configuring IP address type, and adding tags. Create ALB | Create NLB
2. Document new load balancer ARN and note DNS name for testing
3. Monitor status until "active" — typically takes 2-5 minutes

Create Target Groups

Complete this after creating the load balancer.

1. Create target group using same name (or add suffix like "-migrated"), matching protocol and port, selecting target VPC, and choosing same target type (instance, IP, Lambda, ALB). Create target group
2. Configure health checks by matching health check protocol, setting same health check path, configuring interval and timeout, setting healthy/unhealthy thresholds, and matching success codes. Health checks
3. Configure target group attributes: deregistration delay, stickiness (type, duration, cookie name), load balancing algorithm, cross-zone load balancing, and slow start duration (if used). Target group attributes
4. Register targets by adding EC2 instance IDs, IP addresses, or Lambda ARNs, matching port overrides if used, and verifying targets match source configuration. Register targets
5. Wait for targets to become healthy and troubleshoot any unhealthy targets before proceeding

Create Listeners and Attach SSL/TLS Certificates

Complete this after creating target groups.

1. Create listener by matching protocol (HTTP, HTTPS, TCP, TLS, UDP, TCP_UDP) and port number. Create listener
2. Attach certificate ARN for HTTPS/TLS listeners, select SSL policy (match source or use modern policy), and configure default action (forward, redirect, fixed-response). HTTPS listeners | SSL policies
3. Confirm certificate ARN is attached and verify certificate domain matches for HTTPS/TLS listeners
4. Add certificates for additional domains if using SNI and verify all certificates attached.
5. Recreate all listener rules with same priority for ALB, matching conditions (path, host, header, query string, source IP) and actions (forward, redirect, fixed-response, authenticate), and configuring URL rewrites if used. Listener rules
6. Verify default action works and test each rule individually

Configure Load Balancer Attributes

1. Complete this after creating listeners.
2. Match common attributes from source: deletion protection (enable after testing), access logs (S3 bucket and prefix), and cross-zone load balancing. Load balancer attributes
3. Configure ALB-specific attributes if applicable: idle timeout, HTTP/2 support, drop invalid headers, X-Forwarded-For settings, desync mitigation mode, and connection logs. ALB attributes
4. Configure NLB-specific attributes if applicable: client routing policy and cross-zone load balancing. NLB attributes

Verify Health Checks and SSL/TLS

Complete this before DNS cutover.

1. Verify all targets are healthy, investigate any unhealthy targets, and confirm health check metrics in CloudWatch. Troubleshoot unhealthy targets
2. Test HTTPS/TLS connection to load balancer DNS, verify certificate is valid and trusted, check certificate domain matches, test certificate chain completeness, verify TLS version support (1.2, 1.3), and test with multiple browsers/clients
3. Test all application endpoints, verify session persistence works, test all listener rules, and confirm redirects work correctly

---

AWS WAF

Migrate AWS WAF to Another Region

• AWS WAF resources cannot be moved between regions - you must recreate them in the target region
• Infrastructure as Code templates (Terraform/CloudFormation/SDK) for AWS WAF resources are recommended
• If your HTTP service application is fronted by CloudFront, consider associating AWS WAF with CloudFront instead of ALB. This allows the ALB to use CloudFront VPC Origin to keep the ALB within a private network, making future region switching easier without needing to migrate AWS WAF on ALB

Recreate AWS WAF Using JSON Configuration

This workflow requires manually creating dependent resources (IPSets, Regex pattern sets, Rule groups) in the target region before recreating the WebACL.

1. Create IPSets, Regex pattern sets, and Rule groups in the target region with the same names as the source region
2. Download the source WebACL JSON configuration from the AWS WAF Console by selecting your WebACL and clicking the JSON download button, or use AWS CLI: aws wafv2 get-web-acl --name YOUR_WEBACL_NAME --scope YOUR_SCOPE --region YOUR_SOURCE_REGION > waf_config.json (Scope values: CLOUDFRONT or REGIONAL)
3. Update the JSON file with the new ARNs for IPSets, Regex pattern sets, and Rule groups from the target region
4. Create a new WebACL in the target region using the updated JSON configuration

---

In collaboration with Nymus Booysen and Francesco Penta