Planning a migration from AWS Outposts first-generation to second-generation

AWS Outposts extend AWS infrastructure, services, APIs, and tools to on-premises locations for workloads that require low latency, local data processing, or data residency. In April 2025, we announced the general availability of second-generation AWS Outposts. If you’re running workloads on first-generation AWS Outposts, we recommend developing a structured migration strategy to move to second-generation.

In this post, you learn how to plan and execute a migration from first-generation to second-generation Outposts. Second-generation Outposts should be deployed as new infrastructure since there is no in-place upgrade option. We cover the business case for upgrading, key architectural differences, tool selection based on data residency requirements, and a phased migration framework to minimize operational disruption.

Benefits of upgrading to second-generation Outposts

The business case for second-generation centers on three pillars:

• Performance density: The latest generation of AWS instances available on second-generation Outposts deliver 2x the vCPU, memory, and network bandwidth with up to 40% better performance compared to the AWS instances on first-generation Outposts. The latest instances add an additional 20% improvement within the same rack space and power draw.
• Simplified networking: Second-generation Outposts introduces a dedicated network rack that decouples compute from networking, allowing independent scaling, providing built-in network resilience handling device failures automatically, and eliminating multiple uplinks between compute racks and customer-managed switches. The network rack is included at no additional charge.
• New workload capabilities: Second-generation Outposts includes purpose-built accelerated networking instances (bmn-sf2e up to 200 Gbps, bmn-cx2 up to 800 Gbps), Amazon EBS gp3 volume support, and self-service local gateway (LGW) configuration via APIs.

First-generation vs second-generation technical comparison

Customers considering second-generation Outposts should be aware of the generational leap in compute, networking, and storage capabilities. The following table summarizes the key differences between first-generation and second-generation:

 Table 1: Technical Comparison

Network architecture changes in second-generation

Second-generation introduces a fundamentally redesigned network architecture centered on a dedicated Outposts network rack that serves as a central traffic aggregation hub for all connected compute and storage racks simplifying scalability. This replaces the Gen 1 model where each compute rack had its own Outpost Network Devices (ONDs) connecting directly to customer switches.

Decoupled compute and networking

The most significant architectural change is the separation of compute from networking. In first-generation, adding compute racks required additional network uplinks and customer switch modifications. With second-generation, you can add compute racks without modifying the networking infrastructure, providing flexibility and cost efficiency as workloads grow. The network rack uses four Link Aggregation Groups (LAGs) connections compared to first-generation’s two LAGs, and built-in network resilience automatically handles device failures without requiring user-managed High Availability design.

Self-service local gateway configuration

With second-generation, you can define local gateway (LGW) network configurations including IP addresses, VLAN, and BGP settings through APIs and the AWS Outposts console, rather than requiring AWS pre-installation configuration. Up to 10 isolated routing domains with independent network paths are supported, allowing Customer owned IP (CoIP) and Direct VPC Routing (DVR) configurations to coexist on the same Outpost.

Migration planning framework

AWS recommends a structured three-phase approach for transitioning workloads from first-generation to second-generation Outposts: Assess, Mobilize, and Migrate & Modernize.

Phase 1: Assess

The assessment phase begins with performing an inventory of all workloads on the first-generation Outpost, mapping dependencies, identifying instance types in use, and validating site readiness for second-generation power requirements. You can refer to the AWS Outposts User Guide for a list of supported instances to help determine target instance types on second-generation. Workloads should be organized into dependency groups—collections of applications and their underlying infrastructure that share technical or non-technical dependencies. These groupings determine migration order and capacity sizing.

Each workload should be evaluated against the 7 Rs framework (Rehost, Replatform, Repurchase, Refactor, Retire, Retain, Relocate) to determine the appropriate migration approach. Every workload requires defined recovery time objective (RTO) and recovery point objective (RPO) metrics to guide the appropriate migration and disaster recovery (DR) strategy.

Phase 2: Mobilize

During the mobilize phase, migration teams should install AWS Replication Agents on source servers (unless you are using a migration tool that supports Agentless migrations), configure staging subnets (in the Outpost’s parent region or on Outpost), set up VPC extensions, prepare launch templates with target instance types, and establish monitoring and alerting. Rollback procedures must be documented and tested.

In this phase, it is also critical to perform capacity planning. For EBS-based replication, plan for a 2:1 ratio of EBS volumes for near-continuous replication, plus a 1:1 ratio of Amazon S3 on Outposts. For example, 40 TB of workloads requires 80 TB of EBS capacity plus 40 TB of S3 capacity.

Phase 3: Migrate & Modernize

Execute migrations in dependency group waves. Perform testing before cutover, create AMIs, and launch instances on the new Outpost. Validate and archive source servers. Establish a clear time limit for identifying the problem, doing a root cause analysis, and deciding when to perform the cutover. If the problem and path to resolution cannot be articulated within the defined window, initiate rollback.

Table 2: Migration Phases

AWS-native migration tools

AWS provides multiple native services for migrating workloads between Outposts, each suited to different workload types and data residency requirements.

AWS Transform MGN

AWS Transform MGN uses a Region-based staging approach. The replication agent installed on first-generation source servers replicates data to staging subnets in the parent AWS Region over TCP 443 (control plane) and TCP 1500 (data replication). After cutover in the Region, AMIs are created and launched on the second-generation Outposts. MGN supports both agent-based and agentless replication (VMware only) and can operate over private networks for isolated environments. Note that MGN does result in egress charges.

This approach is best for workloads where data can transit through the Region and EC2 instance migrations can withstand a brief cutover window.

EBS Snapshots via Region

EBS snapshots of volumes on an Outpost are stored in Amazon S3 in the Region by default. These Region-stored snapshots can be used to restore volumes or launch instances on a different Outpost. Local snapshots stored on the Outpost cannot be copied to a Region or another Outpost.

This approach is best for simple volume migrations with acceptable downtime during snapshot creation and low-complexity workloads.

S3 Replication on Outposts

S3 Replication on Outposts enables automatic cross-Outpost object replication. You can configure S3 on Outposts to automatically replicate objects across different Outposts or between buckets on the same Outpost. This requires S3 Versioning enabled on both source and destination, classless inter-domain routing (CIDR) association between Outposts, and an IAM service role. Amazon CloudWatch metrics and Amazon EventBridge notifications provide replication monitoring.

This approach is best for object storage migration with zero-downtime asynchronous data movement between Outposts.

Migration tools decision matrix first-generation (Gen 1) to second-generation (Gen 2)

 Table 3: Migration Tools Matrix

Cutover execution and rollback strategies

Executing the actual workload transition requires careful orchestration to minimize business disruption while maintaining data integrity and service availability.

Rollback patterns

Three primary rollback patterns are recommended:

• Blue/Green Deployment: Maintains parallel environments with traffic switching via Amazon Route 53 weighted routing and Application Load Balancer target group switching for instant traffic redirection.
• Database Snapshot and Restore: Takes point-in-time snapshots before migration with rapid restore capability; rollback restores the pre-migration snapshot and replays critical transactions.
• Canary: Enables gradual user segment migration with routing flexibility back to the original system.

High availability during transition

During the migration period, rack-level spread placement groups distribute instances across multiple racks to improve fault tolerance. For highest resiliency, connecting each Outpost to a different Availability Zone enables multi-AZ resilient architectures with intra-VPC communication and Auto Scaling groups spanning both Outposts.

Post-migration optimization

After successful migration, take advantage of second-generation capabilities:

• Right-size instances using AWS Compute Optimizer, for example workloads running on C5.4xlarge may achieve equivalent or better performance on C7i.2xlarge due to the 40% performance improvement.
• Evaluate C8i/M8i/R8i instances for an additional 20% gain over C7i/M7i/R7i.
• Explore accelerated networking instances (bmn-sf2e, bmn-cx2) for workloads requiring ultra-low latency or high-throughput networking.
• Implement self-service LGW routing domains to segment network traffic without AWS intervention.
• Monitor performance metrics for 7–14 days against pre-migration baselines before decommissioning first-generation infrastructure.

Conclusion

Migrating from AWS first-generation Outposts to second-generation is not merely an infrastructure refresh – it is a strategic upgrade that delivers transformative improvements in compute density, networking resilience, and workload capability. With 2x performance gains from C7i/M7i/R7i instances, a dedicated network rack eliminating complex uplink management, and purpose-built accelerated networking instances enabling up to 800 Gbps bandwidth, second-generation enables organizations to run workloads that were previously impossible to run at the edge.Organizations should select migration tooling based on their data residency requirements; AWS Transform MGN should be used for standard workloads or supported third-party solutions. A wave-based migration approach, organized by dependency groups with clearly defined go/no-go decision points, minimizes risk while maintaining operational continuity.

Visit the AWS Outposts product page to learn more. To plan your first-generation to second-generation migration, reach out to your AWS account team, or visit the AWS Outposts contact page.