Rivian accelerates production with second-generation AWS Outposts: Improving resiliency and reducing costs

AWS Outposts racks are a fully managed service that brings Amazon Web Services (AWS) infrastructure, services, APIs, and tools to customer datacenters, co-location spaces, or on-premises facilities. With Outposts, customers benefit from cloud capabilities while maintaining on-premises infrastructure and addressing requirements such as high performance and low latency at the factory edge. For critical manufacturing processes and workloads, Outposts delivers the reliability and security of AWS cloud services directly to the factory floor.

Second-generation Outposts racks bring significant improvements and new features, including enhanced networking capabilities with independent scaling of compute, storage, and networking resources, and support for the latest generation Amazon Elastic Compute Cloud (Amazon EC2) instances (seventh and eighth generation C, M, and R instance families). A key enhancement for manufacturing customers is the introduction of multiple local gateway (LGW) routing domains, which enables network segmentation and the flexibility to use both customer-owned IP (CoIP) and direct virtual private cloud (VPC) routing (DVR) modes on the same logical Outpost. In this blog post, we show how Rivian, a leading innovator in the electric vehicle market, is using this feature to support modern containerized workloads and highly available database architectures for their critical manufacturing workloads at the edge.

Rivian’s challenge and opportunity

Rivian has been using Outposts in their factory edge datacenter since 2021, where they run mission-critical applications supporting manufacturing systems running on-premises. Additionally, Rivian’s existing environment includes local line control, inspection, diagnostics, networking, and other typical manufacturing operations.

Rivian is ramping up production at its factory in Normal, IL to meet demands for the highly anticipated R2 model line set to begin customer deliveries in spring 2026. Rivian is also beginning vertical construction of its new factory in Stanton Springs, GA this year. To support this growth, Rivian needed to modernize their factory edge infrastructure while addressing three critical requirements:

• Reduce operational costs – Migrate legacy virtualization platform to native AWS services.
• Improve resiliency – Implement multi-Availability Zone (multi-AZ) architecture for mission-critical applications.
• Enhance performance – Use modern cloud-native architectures with Amazon Elastic Kubernetes Service (Amazon EKS).

With the release of multiple LGW routing domains on second-generation Outposts racks, Rivian was able to use existing architecture patterns for Intra-VPC communication across multiple Outposts with direct VPC routing and multi-AZ Amazon RDS on AWS Outposts which requires CoIP routing on their Outposts. By using this new feature, they could create a highly available, multi-AZ resilient architecture for their database and containerized applications across two of their Outposts racks to support their critical applications.

Solution: Multiple LGW routing domains on second generation Outposts

Using the multiple LGW routing domains feature, customers can create up to 10 active routing domains on the same logical Outpost, with each routing domain supporting either DVR or CoIP routing mode. Each routing domain has its own LGW virtual interface (VIF) group and LGW route table, allowing different VPCs to use the appropriate routing mode for their workload requirements. A VIF group is a collection of four virtual interfaces, and each VIF is mapped to a physical local aggregation group (LAG) and VLAN that uplinks to your local site network. Each LGW routing domain also requires a unique Border Gateway Protocol (BGP) peering session, allowing for logical network traffic isolation for each routing domain unless routing between domains is configured, and simplified network management. Figure 1 shows an example of how this feature could be set up.

Figure1 – Architecture diagram showing three routing domains

For Rivian, this meant they could architect a solution that delivers both cost savings and operational resilience:

• DVR routing domain for Amazon EKS workloads, enabling simplified networking, reduced latency, and multi-AZ resilient architecture for containerized applications
• CoIP routing domain for multi-AZ Amazon Relational Database Service (Amazon RDS) on Outposts PostgreSQL databases, providing automatic failover and high availability across two Outpost racks

With this architecture, Rivian has unlocked the following outcomes:

• Simplified licensing costs and improved performance using modern cloud-centered architectures by migrating to Amazon EKS
• Improvement in database resiliency with automated failover capabilities using multi-AZ Amazon RDS across two datacenters
• Reduction in operational overhead through managed AWS services

Architecture overview

Rivian’s second-generation Outposts deployment consists of two Outpost racks; each homed to a different Availability Zone in the AWS Region. The Outposts are connected through a customer-managed local network with redundant connectivity to help ensure high availability. The architecture uses two distinct routing domains:

Routing domain 1 (DVR mode)

• Supports Amazon EKS cluster running modernized manufacturing applications
• Uses intra-VPC communication using LGW across multiple Outposts for highly available container workloads
• Provides low-latency, high-throughput connectivity for edge applications

See Figure 2 for reference.

Figure 2 – Two Outpost racks in the same VPC can be configured to communicate over the Outpost local gateways

Routing domain 2 (CoIP mode)

• Supports multi-AZ Amazon RDS PostgreSQL databases for mission-critical data
• Uses customer-owned IP addresses allocated from CoIP pools for replication traffic
• Uses synchronous replication between primary and standby database instances across Outposts
• Provides automatic failover with zero data loss in case of software or infrastructure failure

See Figure 3 for reference.

Figure 3 – Multi-AZ Amazon RDS deployment across two Outposts

Each routing domain is associated with its own VPC, VIF group with unique VLAN associations, and LGW route table configured for the appropriate routing mode. This segmentation ensures that containerized workloads and database replication traffic remain isolated while both benefit from their optimal networking configuration. See Figure 4 for database write operation data flow.

Figure 4 – Primary and secondary write dataflow with multi-AZ

For connectivity to the AWS Region and cloud services, Rivian chose a resilient networking pattern featuring AWS Direct Connect for the primary service link connection and an internet-based connection as a backup, supporting redundant and highly available access to cloud control planes and extended storage services.

Implementing the solution

The implementation began with creating the necessary LGW routing domains on the second-generation Outposts rack.

For the DVR routing domain (EKS workloads)

1. Create an LGW VIF Group with BGP and VLAN routing information for the EKS network segment.
2. Create an LGW route table configured for direct VPC routing mode.
3. Create the LGW routing domain by associating the VIF group and route table.
4. Associate the EKS VPC to this routing domain.
5. To allow the EKS instances to access the Amazon RDS database, add a static route for the DVR VPC CIDR range to the CoIP route table. Configure subnet route tables and security groups to allow traffic between the EKS subnets and the RDS database subnet group.

For the CoIP routing domain (multi-AZ Amazon RDS)

• Create a separate LGW VIF Group with distinct VLAN associations for database replication.
• Create an LGW route table configured for CoIP routing mode with the appropriate customer-owned IP address pool.
• Create the second LGW routing domain by associating this VIF group and route table.
• Associate the database VPC to this routing domain.
• Add a static route to the CoIP LGW route table allowing traffic from the other Outposts CoIP pool. The CoIP pools from each Outpost should have a route in the LGW route table by the time you’re done.

This configuration helps ensure that each VPC uses the correct routing mode for its workload requirements.

Migrating to Amazon EKS

With the DVR routing domain established, Rivian began migrating to Amazon EKS. The migration process involved:

1. Assessment and discovery:

• Using local tools to assess compute and storage requirements from legacy platform.
• Analyzing application dependencies to determine containerization opportunities.
• Identifying applications suitable for direct migration to Amazon EKS versus those requiring refactoring.

2. Planning:

• Designing an Amazon EKS cluster architecture spanning both Outpost racks for high availability.
• Creating detailed migration runbooks with minimal downtime requirements.
• Planning for gradual cutover with rollback procedures.

3. Preparation:

• Creating Outpost subnets in the DVR routing domain VPC on both Outposts.
• Configuring subnet route tables to enable intra-VPC communication across Outposts using the local gateway.
• Deploying Amazon EKS extended cluster with the worker node group spread across their Outposts to support multi-AZ high availability.

4. Migration:

• Containerizing applications and deploying to Amazon EKS using Kubernetes manifests.
• For workloads requiring minimal refactoring, use Cirrus Data Migrate Cloud to lift-and-shift VMs and vSAN block storage to Amazon EC2 instances and Amazon EBS on Outposts.
• Implementing automated continuous integration and delivery (CI/CD) pipelines for application deployment.

5. Testing and validation:

• Conducting thorough testing of migrated applications in the new environment.
• Validating performance, latency, and functionality against operational requirements.
• Simulating failover scenarios to verify high availability configurations and understand application behavior in various failure scenarios.

Deploying multi-AZ Amazon RDS for PostgreSQL databases
Simultaneously, Rivian deployed highly available Amazon RDS PostgreSQL databases using the CoIP routing domain, following documented AWS best practice guidance for resilient Outpost and RDS design:

1. Creating Outpost subnets:

• Create subnets in the database VPC on both Outpost racks.
• Make sure each Outpost is anchored to a different availability zone. This can’t be changed after activation of your Outpost, so ensure each Outpost is anchored to a unique availability zone when ordering.

2. Associating VPC to LGW route tables:

• Associate the database VPC to the CoIP-configured LGW route tables on both Outposts. Multi-AZ Amazon RDS on Outposts deployments require the use of CoIP routing.
• This association allows RDS to determine which CoIP pools to allocate addresses from for replication.

3. Creating a DB subnet group:

• Create a DB subnet group with subnets on each Outpost.
• Make sure your LGW route table, subnet route tables, subnet security groups, and LAN configuration support routing between the two subnets.

4. Deploying Amazon RDS with multi-AZ:

• Create a RDS PostgreSQL database instance with the multi-AZ deployment option selected. Make sure the access type chosen is Customer-owned IP Address (CoIP).
• Amazon RDS automatically provisions primary and standby database instances using the subnets on each Outpost provided from the DB subnet group.
• RDS allocates CoIP addresses from the CoIP pools for the database instances that are used to direct replication traffic over your on-premises LAN.

Figure 5 – Example of DVR and COIP routing domain segmentation

With this configuration, Amazon RDS manages synchronous replication between the primary and standby database instances across the customer-managed local network. The performance of this interconnection is critical—Rivian ensured roundtrip time (RTT) latency between Outposts remained under the 5 ms threshold required for synchronous replication by using redundant high speed network connectivity. When a software or infrastructure failure occurs, RDS automatically promotes the standby database instance to the primary role and updates the DNS record, with applications automatically directed to the new primary through DNS resolution.

While initial workload identification, modernization, and replatforming efforts took careful planning across Rivian’s application owner and infrastructure teams, using cloud-centered architecture patterns reduces Rivian’s operational overhead offloading administrative tasks to AWS managed services, so they can build their applications to be more portable and resilient to failures as opposed to relying on legacy features of their infrastructure.

Considerations for implementation

If you’re considering implementing multiple LGW routing domains, you should consider:

• Network planning – Avoid overlapping IP addresses across routing domains to prevent routing conflicts. Plan VLAN associations carefully to align with existing on-premises network segmentation.
• Routing mode selection – Choose DVR mode for simplified networking using AWS assigned private IPs. Choose CoIP mode for services like multi-AZ Amazon RDS that require customer-owned IP addresses for replication, or when specific CIDR ranges are needed to integrate with on-premises networking.
• VPC association – Remember that each VPC can only be associated with one LGW routing domain per Outpost. Plan your VPC strategy accordingly, using separate VPCs for workloads requiring different routing modes. Static routes can be added to LGW route tables to allow inter-routing domain traffic.
• Replication network performance – For multi-AZ Amazon RDS, ensure the customer-managed local network has routing to allow traffic between Outposts, can meet the synchronous replication 5 ms round trip time requirement, and has redundant uplink cabling for high availability.
• Physical infrastructure – Ensure adequate physical space, power, and cooling are available in the datacenter for second-generation Outposts racks. See Site requirements for more information.

Conclusion

Rivian’s migration from legacy infrastructure to second-generation Outposts racks with multiple local gateway routing domains demonstrates how modern manufacturing operations can simultaneously achieve cost optimization and operational resilience. By using DVR routing for containerized workloads on Amazon EKS and CoIP routing for multi-AZ Amazon RDS databases, Rivian overcame previous technical limitations and built a robust factory edge infrastructure that met their needs for application modernization, high availability, network management, and reduced operational overhead.

The multiple LGW routing domains feature is only available on second-generation Outposts racks and represents a significant advancement for customers in regulated industries requiring network segmentation. This architecture provides Rivian with the foundation to scale production, meet R2 customer demand, and innovate rapidly with advanced technologies while AWS manages the underlying infrastructure. By working with AWS and developing a migration plan, Rivian overcame challenges and positioned themselves at the forefront of manufacturing innovation.