Extending AWS to On-Premises with AWS Outposts - Hybrid Cloud Design and Operations
Extend AWS to on-premises for data residency and low-latency requirements. Learn about Outposts deployment models and Local Gateway design.
Outposts Use Cases
Outposts is a service that physically installs AWS infrastructure in your on-premises data center. There are three primary use cases. First, data residency requirements. When financial regulations or government requirements mandate that data be kept within a specific country or facility, Outposts lets you keep data on-premises while using AWS services. Second, low-latency requirements. It is effective when round-trip latency to the cloud is unacceptable for manufacturing line control or real-time data processing. Third, local data processing. It is used when large volumes of data are generated and need to be preprocessed locally before being transferred to the cloud. Specific industry examples include industrial IoT analyzing sensor data from factory equipment in real time, medical institutions processing MRI and CT scan images on-site, and financial institution trading systems requiring low-latency transaction processing.
Available Services and Network Design
AWS services available on Outposts include EC2, EBS, S3 (S3 on Outposts), RDS, ECS, EKS, EMR, and ElastiCache. These services are operated with the same APIs as Regional AWS and can be provisioned with CloudFormation or Terraform. The network communicates with Regional AWS via a service link connection and with the on-premises network via a Local Gateway (LGW). The service link is used for Outposts management traffic (control plane communication, metrics reporting, software updates) and access to Regional services, with a minimum bandwidth of 1 Gbps recommended. The LGW is controlled via route table entries in subnets within the VPC, configuring routing to on-premises VLANs. Using Customer-owned IP (CoIP) address pools, you can assign addresses from your on-premises address space directly to instances on Outposts, avoiding changes to existing firewall rules and access controls. Since the configuration extends VPC subnets to Outposts, integration with existing VPC designs is straightforward.
Operational Model and Costs
For Outposts racks, AWS handles installation, maintenance, hardware replacement, and software patching. The customer provides data center power, cooling, physical security, and network connectivity. Pricing is a 3-year subscription with three payment options: all upfront, partial upfront, and no upfront. There are no additional charges for EC2 instances or EBS volumes; compute and storage capacity are included in the subscription fee. Deploying Outposts requires a lead time of several weeks, and pre-verification of site power, cooling, and network requirements is important. Rack power requirements are approximately 5-15 kVA depending on configuration, and cooling must support the standard front-intake rear-exhaust rack design. A 42U rack footprint must be secured as physical installation space, with delivery path width and floor load capacity also verified in advance. For more details on Outposts, related books on Amazon are also available.
Choosing Between Outposts and Local Zones
Both Outposts and Local Zones provide edge computing, but their operational models differ fundamentally. Local Zones are small-scale data centers operated by AWS, with infrastructure in AWS facilities rather than customer premises. They are suitable for workloads that need reduced latency but do not require data to remain within a facility (game servers, video encoding, API servers close to end users). In contrast, Outposts are physically installed in the customer's data center, guaranteeing that data never leaves the premises. The most important criterion is whether data residency regulations exist. If regulations require data to be kept within a facility, Outposts is the only option. If only latency is an issue with no regulatory requirements, Local Zones offer simpler deployment with no upfront investment. Wavelength Zones are a further option placed within carrier base stations, specialized for ultra-low-latency on 5G networks.
Design Considerations and Service Link Disconnection Impact
The most important design consideration for Outposts is the behavior when the connection to the Region (service link) is severed. During a service link disconnection, locally running instances and communication via the Local Gateway continue, but launching or stopping new instances and control plane operations (API calls) cannot be executed. This means workloads are maintained during disconnection, but scale-out and recovery operations become impossible. Given this, for critical workloads, pre-provision sufficient capacity and consider static configurations that do not rely on Auto Scaling. S3 on Outposts data is retained locally and remains accessible during service link disconnection, but S3 control plane operations (bucket creation, policy changes) cannot be executed. Additionally, Outposts capacity cannot be elastically expanded like the Region, so sizing must account for peak workload demand. If capacity becomes insufficient, procuring additional racks incurs another lead time.
Summary
Outposts extends AWS infrastructure to on-premises, enabling a hybrid environment with the same operational model as the cloud. Run AWS services including EC2, EBS, S3, RDS, and ECS on-premises, operated with the same APIs and management tools as the Region. It addresses data residency and ultra-low-latency requirements while maintaining a cloud-native development experience. Understanding the distinction from Local Zones, the impact of service link disconnection, and planning capacity in advance are the keys to successful deployment.