Modernize 5G networks with second-generation AWS Outposts racks

Introduction

At MWC 2025, AWS announced the preview of a new AWS Outposts racks offering for high-throughput, network-intensive workloads. We are pleased to announce that this offering is now generally available as part of the second-generation Outposts racks launch. With this launch, Outposts empowers communication service providers (CSPs) to accelerate modernization of their on-premises telecom workloads such as 5G User Plane Function (UPF) and Radio Access Network (RAN) Central Unit (CU) function.

Telecom workloads consist of multiple domains such as RAN, packet core for mobile broadband Internet, IP Multimedia Subsystem (IMS) for voice communication, and Operational Support Systems/Business Support Systems (OSS/BSS) for management and operations. Each of these domains has unique requirements related to performance, security, privacy, data durability, fault tolerance, and resiliency. Consequently, CSPs operate multiple on-premises infrastructure stacks. Deployment and lifecycle management of these separate stacks across different geographical locations is complex, expensive, and time-consuming. AWS helps users address these challenges by offering a seamless cloud continuum experience, enabling users to operate their workloads across AWS Regions, AWS Local Zones, and Outposts on-premises, using the same AWS services and APIs.

Second-generation Outposts racks

The second-generation Outposts racks announced on April 29th, 2025 feature new Amazon Elastic Compute Cloud (Amazon EC2) bare metal instances called bmn-cx2 with a high-performance bare metal network fabric. This enables high throughput and high packets per second (pps) rates to meet the requirements of network-intensive workloads. The new bmn-cx2 instances are built on the same AWS Nitro System powering EC2 instances in AWS Regions and Local Zones today. Featuring fourth generation Intel Xeon Scalable Processors (Sapphire Rapids), bmn-cx2 instances have an 5:1 ratio of memory to vCPU. More than just conventional network bandwidth, they feature specialized network accelerator cards designed for the most latency-sensitive and throughput-intensive on-premises workloads. Today, the bmn-cx2.metal-48xl type with the following specifications is available.

Table 1: bmn-cx2 instance specifications

Accelerated network cards in bmn-cx2 instances not only offer up to 800 Gbps of bare metal network bandwidth operating at near line rate, but also support L2 networking such as VLANs, multicast and hardware-based Precision Time Protocol (PTP) to provide telecom workloads specific features such as L2-based network segmentation and accurate distribution of time and frequency over a packet-based network.

Customers using bmn-cx2 instances can extend the same enhanced security and performance benefits of the AWS Nitro System to the Outposts racks, while using the bare metal networking to suit the features and performance needs of telecom workloads. These workloads run in locations where hundreds of thousands of mobile users generate hundreds of Gigabits per second (Gbps) to Terabits per second (Tbps) of network throughput.

These Outposts racks also integrate seamlessly with other AWS services in AWS Regions and Local Zones for a consistent cloud experience. For example, CSPs can use AWS Telco Network Builder (TNB) to streamline the automation and lifecycle management of AWS Cloud infrastructure such as Amazon Virtual Private Cloud (Amazon VPC), subnets, Amazon Elastic Kubernetes Service (Amazon EKS) clusters, and Containerized Network Functions (CNFs) across multiple data centers. CSPs can use services such as Amazon CloudWatch, Amazon Managed Service for Prometheus, and Amazon Managed Grafana for observability. Furthermore, CSPs can use AWS analytics and machine learning (ML) services such as Amazon Athena, Amazon Bedrock, and Amazon SageMaker to streamline operations with analytics and correlation of network metrics data.

The Outposts racks for high-throughput and network-intensive on-premises workloads allow CSPs to deploy Independent Software Vendor (ISV) software using Amazon EKS and pre-validated EKS add-ons required to automate the deployment, management, and scaling of microservices-based 5G network functions. These Amazon EKS add-ons are essential for telecom network workloads and include 1) Multus, a Container Networking Interface (CNI) enabling users to attach multiple network interfaces and apply advanced network configuration to their network functions. Multus support allows ISVs to configure their EKS clusters to run multi-homed Kubernetes pods attaching to multiple network interfaces for network segmentation. 2) Single Root IO Virtualization (SR-IOV) CNI for providing pods dedicated network interfaces or virtual functions (VF) by using the SR-IOV capabilities of the underlying bare metal network adapters. SR-IOV CNI support is crucial for telecom network workloads to achieve the high-throughput capability provided by the Amazon EC2 bare metal instances. 3) Whereabouts, an IP Address Management (IPAM) CNI plugin for dynamic assignment of IP addresses to network interfaces created by the CNI. 4) Longhorn for supporting ReadWriteMany (RWX) persistent volume claims, as well as to ReadWriteOnce (RWO) provided by Amazon Elastic Block Store (Amazon EBS). With the availability of these add-ons, CSPs can deploy end-to-end 5G Core, IMS, and RAN CU workloads such as control plane and user plane network functions.

Second-generation Outposts racks enable CSPs to create multiple configurations to address compute, storage, memory, and networking requirements of a diverse set of workloads using the same infrastructure. For example, CSPs can deploy Outposts with any combination of bmn-cx2, general purpose, compute optimized, and memory optimized EC2 instances to deploy workloads across the telecom domains mentioned previously. This enables CSPs to address the deployment, operational, and integration complexity of managing disparate on-premises deployments across the entire topology of their networks, such as transport, RAN, Core, and Voice networks. Besides mixing the EC2 instance types, CSPs can start with a small two-rack Outposts deployment and scale to tens of racks.

Architectural patterns using second-generation Outposts racks

In this section, some of the architectural patterns for deploying telecom workloads across the AWS Cloud continuum are presented. Depending on factors such as use case, regulatory requirements, and existing deployments, CSPs can choose one or a combination of any of the deployment models presented in the following sections.

Scenario 1: Hybrid packet core deployment across AWS Regions and Outposts
For CSPs that have subscribers distributed across on-premises locations for such reasons as optimized transport latency and proximity to internet peering points/content distribution networks (CDNs), Outposts offers deployment of network-intensive workloads such as UPF closer to these on-premises locations while running control plane workloads in AWS Regions to achieve performant and resilient architectures (observe the following figure).

The 3rd Generation Partnership Project (3GPP) specifications define mechanisms for network function selection that can be applied in this hybrid architecture for fine-grained control over traffic distribution. For example, Access and Mobility Management Function (AMF) can choose the Session Management Function (SMF) based on subscriber data, network slice information, and requested data network such as the internet.

Deploying across multiple Availability Zones (AZs) and/or multiple AWS Regions allows CSPs to achieve high availability on one end and on the other hand use standard 3GPP procedures for intelligent steering of traffic to one or more of the available UPFs deployed on Outposts across different locations. This is based on characteristics such as current load, latency, use case, and service-specific parameters.

Outposts support multiple types of redundancy configurations with N+K being a typical one. It ensures service availability even with K simultaneous Outposts failures. For example, in an N+2 model, the system can tolerate the failure of up to two Outposts. This redundancy can span multiple Outposts in the same or different geographic locations to achieve the desired resiliency and availability objectives.

Figure 1: Hybrid packet core deployment across AWS Regions and Outposts

This hybrid architecture based on AWS Regions and AWS Outposts enables CSPs to optimize both performance and operational efficiency by placing UPFs close to subscribers while using the scalability and reliability of AWS Regions for control plane functions.

Scenario 2: Hybrid packet core deployment across AWS Regions and Outposts with disaster recovery in AWS Region
Similar to the preceding scenario, this architecture deploys control plane workloads in one or more AWS Regions while distributing UPF across multiple Outposts. However, this scenario adds a disaster recovery strategy that uses AWS Regions as locations for UPF capacity extensions, as can be seen in the following figure.

Under normal operations, UPFs on Outposts process subscriber traffic close to the network edge, minimizing latency and optimizing backhaul. The distributed UPFs follow standard redundancy models to handle routine failures. However, in catastrophic scenarios where multiple Outposts become unavailable simultaneously due to natural disasters, power outages, fiber cuts, or other major incidents, this architecture enables rapid recovery by activating dormant or on-demand UPF capacity in AWS Regions. This includes the horizontally scaled, redundant, and highly-available VPC component called Internet gateway (IGW) acting as a substitute for on-premises-based internet breakout. Combining IGW with Bring your own IP (BYOIP) to Amazon EC2 allows CSPs to bring part or all of their publicly routable IPv4 or IPv6 address range from the on-premises network to their AWS account and advertise it on the internet through AWS. In turn, this allows them to use these addresses as User Equipment IP (UEIP).

Figure 2: Hybrid packet core deployment across AWS Regions and Outposts with disaster recovery in AWS Region

Although this architecture could introduce more latency as traffic might traverse longer paths to AWS Regions-based UPFs, it provides a cost-effective insurance policy against catastrophic edge location failures.

Scenario 3: Complete packet core deployment on Outposts at customer premises
For cases where a Region isn’t available in the CSP area of interest, or where data residency necessitates both control plane and user plane workloads to be placed on-premises, CSPs can use Outposts for hosting both control plane and UPFs as depicted in the following figure. Building on the ability to mix-and-match various EC2 instance types in the same Outposts racks, control plane functions can be deployed on regular EC2 instances such as the C7i instance family while user plane workloads run on bmn-cx2 instances.

This model allows CSPs to meet certain requirements pertaining to keeping subscriber data and network operations within specific jurisdictions while still using AWS infrastructure and services. The architecture optimizes performance for local services and maintains operational consistency through the same AWS management tools, APIs, and services used in AWS Regions.

For resilience, CSPs typically deploy this architecture across multiple physical locations, each with its own Outposts deployment. This creates a distributed edge cloud that maintains service continuity even if one site experiences an outage. The control plane functions can be configured in active-active or active-standby modes across these sites, with automated failover mechanisms to ensure continuous service.

Figure 3: Complete packet core deployment Outposts at user premises

Besides enhanced mobile broadband (eMBB), other use cases that this architecture serves include private networks, fixed wireless access, and ultra-reliable low-latency communications (URLLC).

Scenario 4: AWS Region-based packet core deployment
In this scenario, the complete packet core is deployed in AWS Region(s). Both control and user plane workloads are deployed redundantly across multiple AZs and/or AWS Regions as shown in the following figure.

For 5G/4G packet core deployment, control plane functions such as Access and Mobility Management Function (AMF)/Mobility Management Entity (MME), Session Management Function (SMF)/SPGW-C, Policy Control Function (PCF)/Policy and Charging Rules Function (PCRF), Network Repository Function (NRF), Network Exposure Function (NEF), Unified Data Management (UDM)/Home Subscriber Server (HSS), and others are deployed at least across two AZs.

For use cases where the minimum distance between data centers must exceed the typical distance between two AWS AZs (up to 60 miles/100 km apart), CSPs can deploy across multiple AWS Regions. Similarly, the UPF is deployed in a geo-redundant cluster that can survive AZ and AWS Region-wide impacts. Geographies where both AWS Regions and Outposts are available CSPs usually prefer with the hybrid architectures explained previously for an optimal design that balances between the resiliency of AWS Regions, proximity of UPF to internet breakouts, latency, and data transfer cost.

Figure 4: AWS Region-based packet core deployment

Scenario 5: AWS Region-based IMS with hybrid packet core deployment
This scenario presents an architecture where the IMS for voice services is deployed in AWS Regions alongside the 5G/4G core control plane functions, while the UPF is distributed across multiple Outposts at the edge.

This hybrid approach creates two main traffic patterns as shown in the following figure: internet/data traffic flows directly from the UPF to the internet through local breakout points, while voice traffic and signaling between the 5G/4G core and IMS traverse the connection between Outposts and AWS Regions.

In this architecture, control plane functions such as AMF and SMF are deployed in AWS Regions for centralized management, while UPFs are strategically placed on Outposts closer to subscribers. The IMS components include but aren’t limited to the Call Session Control Functions (CSCF), Session Border Controller (SBC), Media Resource Function (MRF), and Telephony Application Server (TAS). They are deployed in AWS Regions to benefit from the elasticity and high availability of the cloud.

Figure 5: AWS Region-based IMS with hybrid packet core deployment

For CSPs transitioning from legacy networks, this model provides a pragmatic approach to modernization. It allows them to migrate voice services to the cloud while maintaining optimal data service performance through edge-deployed UPFs. The architecture is particularly beneficial for CSPs looking to gradually transform their network infrastructure without disrupting existing services.

Scenario 6: AWS Region-based IMS with UPF voice and Outposts-based UPF data
Building on the previous scenario, this model introduces a fine-grained approach to UPF deployment by separating UPF instances based on traffic type. In this model, the IMS and control plane functions remain in AWS Regions, but the user plane is split: UPF instances handling voice traffic are deployed in AWS Regions alongside the IMS, while UPF instances processing data traffic are deployed on Outposts at the edge. Voice traffic is identified and routed to the Region-based UPF, which has optimized connectivity to the IMS components, while internet-bound traffic is processed by the edge-deployed UPF on Outposts (observe the following figure).

Placing voice-specific UPF instances in AWS Regions close to the IMS allows this architecture to minimize the latency for signaling between the UPF and IMS components. This optimization could also enhance call setup times and improve overall voice service management. Furthermore, this approach reduces the amount of signaling traffic traversing between AWS Regions and Outposts.

Figure 6: IMS with UPF voice in AWS Region and UPF data in Outposts

Both Scenario 5 and Scenario 6 enable CSPs to use the high-performance networking capabilities of Outposts with bmn-cx2 instances, while Scenario 6 adds the flexibility to optimize voice traffic handling through AWS Region-based UPF deployment. This approach allows CSPs to tailor the deployment to their existing infrastructure, while maintaining the benefits of AWS consistent cloud experience across AWS Regions and Outposts.

Scenario 7: Hybrid packet core deployment with RAN CU and RIC
This scenario is similar to Scenario 1, where the packet core control plane runs in AWS Regions, while the UPF is distributed across multiple Outposts at the edge. For CSPs who want to deploy RAN CU and the near-Real Time RAN Intelligent Controller (RIC) in the same edge data center as the UPF, they can use the same Outposts racks. The non-Real Time RIC component can be deployed in AWS Regions, similar to the packet core control plane, as shown in the following figure.

The RAN CU runs critical protocols such as Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP), and it needs high-throughput, low-latency communication with both the RAN Distributed Unit (DU) and the packet core. Deploying RAN CU on Outposts racks with bmn-cx2 instances at the edge allows CSPs to achieve the performance requirements while maintaining operational consistency with their packet core deployment.

Deploying near-Real Time RIC on Outposts racks alongside RAN CU and UPF allows CSPs to implement time-sensitive functions such as interference management, Quality of Service (QoS) management, and radio connection management with minimal latency. Meanwhile, the non-Real Time RIC deployed in AWS Regions uses cloud-scale compute resources for network-wide optimization, using data from the OSS stack and applying artificial intelligence (AI)/ML capabilities to develop models that enhance RAN performance. This split deployment approach provides CSPs with both the edge performance needed for real-time operations and the cloud scale needed for advanced analytics and optimization while maintaining a consistent AWS infrastructure and management experience.

Figure 7: Hybrid packet core deployment with RAN CU and RIC

Conclusion

Different telecom workloads have different placement requirements, such as traffic aggregation locations, edge, and far edge locations depending on traffic distribution, processing, regulatory, compliance, and latency needs. To meet these requirements, CSPs need consistent cloud solutions that provide operational directness, infrastructure consistency, and architectural flexibility to deploy network workloads across different locations.

With the general availability of new AWS Outposts racks offering for high-throughput, network-intensive workloads, CSPs can meet the performance needs of telecom workloads using the same AWS services and APIs on-premises. The new AWS Outposts racks help CSPs address the deployment, operational, and integration complexity of managing disparate stacks on-premises. The AWS Cloud continuum provides a comprehensive toolkit for CSPs to modernize their networks:

• AWS Telco Network Builder (TNB) streamlines the automation and lifecycle management of AWS Cloud infrastructure such as VPC, subnets, Amazon EKS clusters, and Amazon EKS worker nodes for the 4G/5G/RAN/IMS workloads.
• AWS monitoring and observability services such as Amazon CloudWatch, Amazon Managed Service for Prometheus, and Amazon Managed Grafana provide unified management across the entire network topology.
• AWS analytics and ML services such as Amazon Athena, Amazon Bedrock, and Amazon SageMaker transform networks into intelligent platforms.

We invite you to explore how these architectural patterns can accelerate your network modernization journey. Contact your AWS account team today to learn more about Outposts for high-throughput, network-intensive workloads.