Hybrid Cloud with AWS Outposts - Extending AWS to On-Premises

This article organizes the selection criteria between the rack type and the server type, and introduces the design of a hybrid cloud that runs EC2 / ECS / RDS on premises.

About 7 min readLast updated: 2026-10-31

Outposts Form Factors and Supported Services

Outposts Rack is a form in which a 42U rack designed by AWS is installed in an on-premises data center. You can run AWS services such as EC2 instances, EBS volumes, S3 on Outposts, RDS, ECS, and EKS on premises. AWS is responsible for hardware installation, maintenance, and software updates. Outposts Servers are provided in units of 1U or 2U servers, and are suited to use cases that place AWS compute at small sites such as retail stores, factories, and hospitals. A subset of EC2 and EBS is available.

Network Connectivity and Operations

Outposts requires a service link connection to its parent Region, which is connected through Direct Connect or VPN. Because the control plane (launching / stopping instances, sending CloudWatch metrics, and so on) is managed through the Region, the availability of the service link is important. The local gateway (LGW) controls routing between the on-premises network and Outposts subnets, and provides a path for on-premises applications to access resources on Outposts. VPC subnets on Outposts are created as an extension of the Region's VPC, and can communicate within the same VPC as the subnets in the Region.

Local Gateway and Data Residency

The local gateway (LGW) controls routing between Outposts and the on-premises network. In the LGW route table, you define routes to on-premises CIDR blocks and establish communication between EC2 instances on Outposts and on-premises systems. With a CoIP (Customer-Owned IP) pool, you can assign your existing on-premises IP addressing scheme to instances on Outposts and minimize changes to firewall rules. For data residency requirements, S3 on Outposts lets you keep data on premises while operating on it with the S3 API. EBS local snapshots keep backups on Outposts and achieve a configuration in which data is not transferred to an AWS Region.

Outposts Cost Structure

Outposts is a 3-year subscription, with payment options of all upfront, partial upfront, and no upfront. The rack type has a fixed monthly fee that includes EC2 and EBS capacity, and the same unit prices as equivalent resources in the Region apply. The server type (1U/2U) is intended for small edge environments and can be deployed at a lower cost than the rack type. Power, cooling, physical security, and network connectivity are borne by the user. The cost of the Direct Connect or VPN that meets the bandwidth requirements of the service link connection (minimum 1 Gbps, recommended 10 Gbps) also needs to be considered. You monitor the utilization of resources on Outposts with CloudWatch and regularly evaluate whether capacity is excessive or insufficient.

Situations Suited to Adoption

Outposts is chosen when you want to balance the convenience of the cloud with on-premises needs. For workloads that need to communicate with local equipment at low latency, such as factory production equipment and store systems, the cloud alone, with its distant data centers, cannot meet the requirements. Also, when laws, regulations, or policies require data to be kept in a specific location, Outposts lets you have an AWS environment close at hand. It is also suited to configurations that process large volumes of data locally and send only the results to the cloud. It meets the need to gain the AWS operational experience on site in situations where a full migration to the cloud is difficult.

Capacity Planning and Capacity Management

Because Outposts is physical equipment installed on your premises, its capacity is finite. Since it cannot be expanded without limit as in the cloud, you estimate a configuration that matches the workloads to be run in advance and place the order. After operations begin, you monitor the usage of compute and storage and continuously check whether capacity is becoming tight. You adjust allocations to use the limited resources efficiently. When an increase in demand is expected, you plan expansion early. Rather than using it without a ceiling as you would in the cloud, capacity management premised on physical constraints is the key to operating Outposts stably.

Availability and Behavior During Connection Failures

Outposts is managed through a dedicated connection to an AWS Region. If this connection is interrupted, creating new resources and performing management operations become impossible, but many workloads that are already running continue to operate locally. It is important to design so that work can be completed locally, so that on-site operations do not depend excessively on the state of communication with the Region. Critical systems are made redundant within Outposts to avoid single points of failure. You also define a data synchronization policy in advance so that consistency with the cloud side can be achieved when the connection is restored. A design that understands how far things can keep running during a failure is required.

Operations and Updates

Because AWS takes care of the physical maintenance and software updates of Outposts, users are freed from hardware management. On the other hand, because of the nature of being installed on site, users need to prepare the conditions of the installation environment, such as power and the network. Because resource monitoring and deployment can be performed with the same operating model as AWS in the cloud, operations teams can use familiar procedures as they are. It is also possible to integrate it with services in the Region and manage backups and monitoring in an integrated way. The ability to operate the same way as the cloud while being on premises is an advantage that lowers the management burden of hybrid environments.

Summary

Outposts extends AWS infrastructure and services to on-premises environments and addresses data residency and latency requirements. The local gateway controls the connection with the on-premises network, and S3 on Outposts lets you keep data on premises while operating on it with the S3 API. By choosing between the rack type and the server type, it covers a wide range of scales from data centers to edge environments.

References (Official AWS Resources)

The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.

If this page and the official documentation disagree, treat the official documentation as authoritative.

Why Auto Scaling Scales Out Fast but Scales In Cautiously - The Design Intent Behind Asymmetric Decision LogicThis article explains why EC2 Auto Scaling executes scale-out immediately while applying a cooldown period for scale-in, the flapping prevention mechanism, and the internal logic of target tracking scaling.Demand-Driven Infrastructure with AWS Auto Scaling - Designing and Optimizing Scaling PoliciesLearn how to use target tracking, predictive, and scheduled scaling policies effectively, and optimize costs with mixed instances policies that leverage Spot Instances.AWS Fault Domain Design - How the Three-Layer Structure of AZs, Regions, and Partitions Protects AvailabilityLearn why AWS infrastructure is designed with three layers of fault domains - AZs (fault isolation), Regions (geographic separation), and Partitions (political separation) - and how far failures propagate at each layer, with real-world examples.Distributed Systems Principles Learned from AWS Outages - How Past Major Incidents Reshaped ArchitectureUsing AWS's published incident reports as case studies - including the S3 outage (2017), Kinesis outage (2020), and the unique nature of us-east-1 - this article explains design principles such as Shuffle Sharding, Static Stability, and Cell-based Architecture.Why AWS Builds Regions Where It Does - The Hidden Criteria Behind Data Center Site SelectionWe explain the criteria AWS considers when deciding region locations, including power supply, geopolitical risk, data sovereignty legislation, network connectivity, and natural disaster risk, with concrete examples from specific regions.Why AWS Availability Zone IDs Differ Per Account - The Design Intent Behind AZ MappingExplains how us-east-1a maps to different physical AZs per account, why AZ IDs (use1-az1) were introduced, the design intent of even capacity distribution, and considerations for cross-account AZ specification.Batch Computing Infrastructure - Large-Scale Parallel Processing with AWS BatchLearn how to build large-scale batch processing with AWS Batch. Covers job queue design, auto-scaling compute environments, cost optimization with Spot Instances, and building batch infrastructure ideal for scientific computing and large-scale data processing.Broadcast-Quality Live Streaming - Building a Large-Scale Delivery Platform with AWS Elemental MediaLive and MediaPackageThis article explains a broadcast-quality live streaming platform built with AWS Elemental MediaLive and MediaPackage. It introduces real-time transcoding, DRM, ad insertion, and multi-CDN delivery.