AWS Site-to-Site VPN Migration Planning Guide

A practical guide to routes, redundancy, monitoring, validation and rollback when hybrid connectivity is part of an AWS migration.

An AWS Site-to-Site VPN is often treated as a prerequisite checkbox: create a customer gateway, configure two tunnels and continue with the migration. In practice, hybrid connectivity sits on the critical path for application access, identity, file services, ERP integrations, monitoring and support. A tunnel can be “up” while the application path is still unusable because of routes, DNS, firewalls, asymmetric return traffic or an untested dependency.

This guide focuses on the migration work around the VPN rather than the console steps for creating one. It is relevant whether the target uses a virtual private gateway, Transit Gateway or a broader network architecture.

Start with the application dependency map

List every traffic flow that must cross the connection during and after migration. For each flow, record source, destination, protocol, port, direction, expected volume, latency sensitivity, data sensitivity and business owner.

Include less obvious dependencies:

  • Active Directory, DNS, NTP and certificate services;
  • backup and replication traffic;
  • monitoring, patching and administrative access;
  • ERP, finance and printing integrations;
  • licence servers and third-party allowlists;
  • outbound callbacks from cloud workloads;
  • disaster-recovery and break-glass paths.

This map determines routing, security rules, bandwidth expectations and the order in which workloads can move. It also prevents “the VPN is working” from becoming a substitute for application validation.

Confirm address space and route ownership

Overlapping address ranges are one of the most expensive hybrid-network surprises. Compare on-premises networks, AWS VPCs, other cloud environments, partners and planned future ranges. If overlap exists, decide whether to renumber, use translation, isolate a workload or choose another integration pattern. Document the trade-off rather than hiding it inside a device rule.

Create a route matrix that identifies:

  • prefixes advertised or statically configured on each side;
  • the intended next hop and return path;
  • route propagation behavior;
  • priority relative to Direct Connect, other VPNs or internet paths;
  • owner of AWS route tables and on-premises routing;
  • how a route is withdrawn during rollback.

Dynamic routing with BGP can simplify route exchange and failure handling, but it still requires agreement on autonomous system numbers, advertisements and preference. Static routing may suit a small environment, provided every change is controlled and the return path is verified.

Design for both AWS tunnels

AWS Site-to-Site VPN connections provide two tunnels for redundancy. Configure and monitor both where the customer-gateway platform supports it. Confirm whether the on-premises device can use active/active paths safely or should prefer one tunnel. Test failover rather than assuming device templates handle it correctly.

Redundancy also needs to extend beyond the AWS endpoint. A second tunnel on the same physical firewall, internet circuit and power source does not protect against those shared failures. Record which failure modes the design covers and which remain accepted risks.

If the migration requires stronger availability, evaluate a second customer gateway, diverse internet connectivity or Direct Connect with VPN backup against business recovery requirements. Avoid presenting a more complex design as automatically better; it must be supportable by the team that will operate it.

Treat encryption settings as coordinated configuration

Agree on IKE version, encryption, integrity, Diffie–Hellman groups, lifetimes, pre-shared-key handling and inside-tunnel addressing. Use supported, current settings on both sides and keep secrets out of tickets or unprotected documents.

Configuration generated for a device family is a starting point, not proof that the deployed firmware and local policy behave identically. Review the actual configuration with the network owner. Record who can rotate pre-shared keys, how rotation will be scheduled and what telemetry indicates a negotiation failure.

Put DNS in the migration plan

Many hybrid failures are name-resolution failures. Decide how on-premises clients resolve private AWS names and how cloud workloads resolve required on-premises zones. If using Route 53 Resolver endpoints and forwarding rules, define their availability, security-group rules, query logging and ownership.

Test short names, fully qualified names, conditional forwarding and application-specific resolution. Confirm that DNS responses return reachable addresses for the requester. Split-horizon behavior should be intentional and documented.

Establish monitoring before cutover

Tunnel state alone is not enough. Monitor:

  • tunnel availability and state changes;
  • bytes in and out, packet loss and latency where measurable;
  • BGP session state and route count;
  • firewall denies and flow logs;
  • synthetic application checks across the path;
  • bandwidth saturation during replication or backup;
  • ownership and notification route for every alert.

Build a small dashboard and alert runbook before production relies on the link. The first response should identify whether the issue is tunnel negotiation, routing, filtering, DNS or the application itself.

Rehearse the cutover

Use a representative non-production workload to validate the complete path. Test user access, application calls, database connectivity, administration, monitoring, backup and recovery. Capture baseline latency and throughput so post-migration behavior can be compared with evidence.

For the production change, write a timed runbook:

  1. confirm both tunnel and route states;
  2. pause or control writes if the data plan requires it;
  3. complete final replication and validation;
  4. change DNS, routes or application configuration;
  5. run technical and business checks;
  6. observe the agreed health indicators;
  7. declare success or execute rollback before the cutoff.

Name the decision-maker and the latest safe rollback time. Keep the old route or service available for the agreed observation period if the data model permits it.

Be careful when changing the target gateway

AWS supports modifying the target gateway for a Site-to-Site VPN connection in certain migrations. AWS warns that the connection is temporarily unavailable while the target is changed and that VPC route tables may need to be updated. The exact routing and autonomous-system-number considerations depend on the gateway types. Review the current AWS target gateway modification guidance before planning that change.

Do not combine a gateway migration, firewall upgrade, address change and application cutover into one window unless there is a compelling reason. Separating changes makes validation and rollback far clearer.

Secure and operate the connection

Limit routes and firewall rules to required flows. A VPN encrypts traffic in transit; it does not decide whether every connected system should trust every other system. Preserve segmentation, log important flows and review rules after temporary migration paths are removed.

Assign operational ownership across both sides. The runbook should include AWS resource identifiers, on-premises device context, escalation contacts, configuration backup location, safe diagnostic commands and how to engage the internet provider if necessary.

Schedule periodic failover and recovery tests. Review tunnel settings, device support, routes and unused rules as the environment changes. Connectivity that was correct on migration day can drift into an undocumented dependency.

Connect the VPN plan to the wider foundation

Hybrid connectivity depends on account structure, identity, logging, change control, recovery and cost ownership. It therefore belongs inside the cloud-foundation roadmap, not beside it. Our Cloud Foundations service covers that shared operating layer, while the Data Steels AWS migration case study describes a real engagement combining workload migration, AWS management, site-to-site VPN support and ERP enablement.

Before the next migration window, use the Cloud Foundation Readiness Checklist to review network ownership, address planning, logging and recovery alongside the VPN. If you need an independent route and cutover review, book a consultation with the architecture team.