Public cloud regions solve most problems. Outposts exists for the residue of problems that regions cannot solve no matter how many Availability Zones or Local Zones AWS adds.

Three Forces That Cloud Regions Cannot Bend

AWS Regions are extraordinarily good at elastic compute, managed services, and global reach, but three forces consistently push workloads back toward on-premises hardware: physics, law, and legacy. Physics sets a hard floor on latency — light in fiber travels at roughly two-thirds the speed of light in a vacuum, so a round trip between, say, Chicago and the nearest AWS Region can already sit near the tolerance limit for a manufacturing control loop or a high-frequency trading algorithm, before any processing happens at all. Law is the second force: many industries face data residency and data sovereignty rules that require certain categories of data to physically remain within a specific building, city, or country, and sometimes never touch a network segment that is reachable from the public internet. Legacy is the third force: enormous amounts of enterprise value sits in on-premises systems — mainframes, industrial control systems, storage arrays — that are too risky, too expensive, or too tightly coupled to physically relocate, yet the applications sitting next to them still need cloud-native APIs to modernize.

What Existed Before Outposts

Before Outposts launched in 2019, organizations facing these constraints had two unsatisfying choices. The first was to run a fully separate on-premises stack — VMware clusters, OpenStack, or bespoke virtualization — and build a completely different automation, monitoring, and security toolchain for it than the one used in AWS, doubling the operational burden for every team that had to support both. The second was to accept the latency or compliance risk and run everything in the Region anyway, hoping the trade-off was acceptable. Outposts introduced a third option: identical AWS APIs, identical service behavior where possible, and identical operational tooling, running on hardware physically located wherever the workload’s constraints demand.

This section skips the beginner-level “what is an Outpost” definition and goes straight into the vocabulary and mechanics an intermediate builder actually needs to reason about deployments.

Outposts Racks vs. Outposts Servers

AWS ships Outposts in two physical forms, and the difference is not cosmetic — it changes what services are available and what scale is realistic. Outposts racks are full 42U industry-standard racks, delivered pre-cabled and pre-configured, that can hold compute, storage, and networking capacity comparable to a meaningful slice of an AWS Availability Zone, and they can be linked together to scale further. Outposts servers are single 1U or 2U rack-mountable servers designed for locations that cannot host a full rack at all — a retail store back room, a small clinic, a cell site — and they trade scale for footprint, supporting a narrower set of instance types and services.

Service Link: The Nervous System

Every Outpost maintains a persistent, encrypted network connection back to its “home” Region and, more specifically, to a chosen Availability Zone within that Region — this connection is called the Service Link. It is not simply a VPN for application data; it is the channel AWS uses to send configuration, software updates, monitoring telemetry, and control-plane commands to the Outpost, and to receive health and metrics data back. Understanding Service Link is the single most important intermediate concept in Outposts, because almost every constraint and failure mode in the service traces back to what does and does not depend on this link staying up.

Anchor Availability Zone and Parent Region

When an Outpost is ordered, the customer designates one parent Region and, within it, one anchor Availability Zone. The Outpost is logically treated as an extension of a subnet inside that Region’s VPC — the same VPC CIDR ranges, route tables, and security groups that govern resources inside the Region also govern resources on the Outpost. This is a deliberate design choice: it means a subnet can literally span from inside a Region’s Availability Zone out onto a physical rack sitting in a customer’s own building, with EC2 instances on both ends addressable within the same private IP space.

Supported Services Are a Subset, Not a Mirror

A frequent intermediate mistake is assuming an Outpost is a full miniature Region. It is not. AWS deliberately supports only a curated subset of services locally on the Outpost — principally EC2, EBS, and, on racks, Amazon S3 on Outposts, along with local instances of RDS, EKS, and ECS in supported configurations. Services with no meaningful “run locally” concept, such as many fully managed, globally distributed services, remain in the parent Region and are reached over Service Link. Every architecture decision on Outposts starts by asking: does this specific service run on the Outpost, or does it run in the Region and get reached through the Outpost’s connection to the Region?

graph TB
  subgraph REGION["AWS Region (Parent Region)"]
    AZ["Anchor Availability Zone"]
    CP["AWS Control Plane
(EC2, EBS, IAM, CloudWatch APIs)"]
    AZ --> CP
  end

  subgraph LINK["Service Link"]
    SL["Encrypted VPN Tunnels
(redundant paths)"]
  end

  subgraph SITE["Customer Premises"]
    subgraph OUTPOST["Outpost Rack / Server"]
      ONL["Outpost Networking Layer
(Local Gateway, Switches)"]
      OSC["On-Outpost Compute
(EC2 Instances)"]
      OST["On-Outpost Storage
(EBS Volumes, S3 on Outposts)"]
      ONL --- OSC
      ONL --- OST
    end
    CGW["Customer Gateway / Router"]
    LAN["On-Premises LAN / Local Applications"]
    ONL --> CGW
    CGW --> LAN
  end

  CP -- Service Link --> SL
  SL -- Service Link --> ONL

  style REGION fill:#111,color:#fff
  style SITE fill:#1a1a1a,color:#fff
  style LINK fill:#dc2626,color:#fff
        

Physical Layer

An Outposts rack arrives as a sealed, pre-racked, pre-cabled unit — AWS technicians install it, connect power and uplinks, and run the initial activation. Inside sits compute capacity (Nitro-based servers, the same underlying virtualization hypervisor used across EC2 in Regions), and, for the rack form factor, dedicated storage capacity for EBS volumes. Networking hardware inside the rack includes redundant switches that connect the compute and storage nodes internally and connect the whole unit outward to the customer’s network through the Local Gateway. Outposts servers are simpler: a single compute node with local NVMe storage, no separate storage array, and a smaller networking footprint suited to a single uplink.

Local Gateway (LGW) and Networking Components

The Local Gateway is the routing boundary between Outpost subnets and the customer’s on-premises network — conceptually similar to how an internet gateway is the boundary between a VPC and the public internet, except the LGW’s “outside” is the customer’s own LAN rather than the internet. Route tables on Outpost subnets can direct on-premises-bound traffic through the LGW, letting an EC2 instance on the Outpost talk directly and locally to, say, a factory PLC or a hospital imaging system, without that traffic ever needing to traverse the Service Link back to the Region.

Compute and Storage Components

On the compute side, Outposts supports a defined set of EC2 instance families — general purpose, compute optimized, memory optimized, and, on select configurations, GPU instances — but not the entire catalog available in a Region, because the hardware is fixed and finite. On the storage side, Outposts racks support EBS volume types (gp2, gp3, io1/io2 style semantics) backed by the physical storage array in the rack, and optionally S3 on Outposts, which provides an S3-compatible object storage bucket physically local to the rack for workloads that need object storage with local access patterns. Outposts servers, lacking a dedicated storage array, rely primarily on local NVMe-backed instance storage and do not support S3 on Outposts.

How an API Call Actually Travels

When a developer runs a command to launch an EC2 instance on an Outpost, the request does not go to the Outpost directly — it goes to the EC2 API endpoint in the parent Region, exactly like any other EC2 API call. The Region’s control plane authenticates and authorizes the request through IAM, validates it against the target Outpost’s known capacity, and then issues a placement and launch instruction that travels down the Service Link to the Outpost’s local control agent. That local agent, running on the Outpost’s own management infrastructure, is what actually instructs the Nitro hypervisor on the physical server to boot the instance. The instance itself, once running, serves application traffic entirely locally — but the act of launching, stopping, or modifying it always requires a round trip through the Region.

Local Data Plane, Remote Control Plane

This “local data plane, remote control plane” split is the defining internal mechanic of Outposts and the source of nearly every operational rule that follows. The data plane — the actual movement of application traffic between instances, storage volumes, and the local network — is designed to function entirely within the Outpost, independent of Service Link connectivity, once resources are already running. The control plane — creating, modifying, or terminating resources, evaluating IAM policy, and most monitoring pipelines — depends on the Region and therefore depends on Service Link being available.

Capacity Reservation and Placement

Because an Outpost has a fixed amount of physical hardware, AWS’s placement logic on an Outpost differs subtly from a Region. In a Region, EC2 can draw from an effectively enormous shared pool of hardware; on an Outpost, the control plane tracks exactly how much vCPU, memory, and EBS capacity remains on that specific physical unit, and a launch request that exceeds available capacity fails immediately with a capacity error rather than being satisfied from elsewhere. This is a meaningful shift in mental model: capacity planning on Outposts is closer to traditional on-premises hardware sizing than to the “infinite” elasticity assumption many engineers bring from Region-based EC2 usage.

From the moment an Outpost is ordered to the moment traffic flows through it in production, the resource moves through a distinct lifecycle worth understanding end to end.

Ongoing Data Flow Once Live

In steady-state operation, three distinct flows coexist. First, north-south application traffic moves between Outpost-hosted instances and on-premises systems through the Local Gateway, entirely inside the customer’s building. Second, control and management traffic — API calls, software updates, telemetry — flows over Service Link to and from the parent Region. Third, if instances on the Outpost also need to reach services that only exist in the Region, such as a fully managed database service with no local equivalent, or need to reach the public internet, that traffic likewise transits Service Link (or a separate direct internet path, if configured) back through the Region’s networking stack.

The Central Trade-off: Locality vs. Elasticity

Every Outposts design decision ultimately balances the same tension. A Region gives near-limitless elasticity but cannot guarantee physical locality of data or sub-millisecond local latency. An Outpost gives locality and low local latency but trades away elasticity, since capacity is bounded by whatever hardware physically sits in the rack. Experienced architects treat Outposts capacity planning the way they would treat traditional on-premises hardware sizing — forecasting peak demand in advance — rather than assuming the auto-scaling behaviors they are used to from Region-based workloads will absorb unexpected growth.

Latency Characteristics

The headline performance benefit of Outposts is local latency: traffic between an application instance and an on-premises system connected through the Local Gateway typically stays in the low single-digit-millisecond range, because it never leaves the building. This is the property that makes Outposts viable for manufacturing execution systems synchronizing with robotics, or trading applications that need to sit physically close to an exchange’s matching engine colocated nearby. By contrast, any traffic that must reach the Region — whether for a control-plane operation or a Region-only managed service — inherits normal wide-area network latency, typically in the tens of milliseconds depending on distance and network path.

Scaling Model: Vertical by Order, Not Elastic by Default

Scalability on Outposts works fundamentally differently from a Region. Within the bounds of installed capacity, standard EC2 mechanisms — Auto Scaling groups, load balancing across instances — work normally and can shift load among running instances or launch new ones up to the ceiling of available hardware. Scaling beyond that ceiling requires a physical action: ordering an additional Outpost server, or an additional rack (or additional capacity within an existing rack, where supported), which then must be delivered, installed, and registered before it contributes usable capacity. This turns scaling into a supply-chain and lead-time problem rather than a pure software problem, and it is why capacity forecasting is treated as a first-class design activity for Outposts deployments.

Network Throughput Considerations

Service Link connections are provisioned with a defined bandwidth based on the customer’s uplink, and this bandwidth is shared across management traffic, any Region-bound application traffic, and monitoring telemetry. Architects sizing an Outposts deployment need to separately account for local, on-premises-bound traffic (which never touches Service Link and is bounded mainly by the Outpost’s internal networking) versus Region-bound traffic (which is bounded by the provisioned uplink), since conflating the two leads to under-provisioned links that appear fine in testing but saturate under production load that leans more heavily on Region calls than expected.

There Is No Second Availability Zone On-Site

This is the single most important reliability fact about Outposts: a single Outpost is not internally divided into multiple Availability Zones. The AZ-redundancy model that Region-based architects rely on — spreading instances across two or three AZs so that a single data center failure does not take down the application — does not exist within one physical Outpost. A rack failure, a site power outage, or a local network failure can affect every resource on that Outpost simultaneously.

What Happens When Service Link Goes Down

Because the data plane is designed to function independently of Service Link, existing EC2 instances, EBS volumes, and local networking on the Outpost continue serving traffic during a Service Link outage. What stops working is anything that depends on the control plane: launching or terminating instances, modifying security groups through the API, most CloudWatch metric delivery, and any application calls that specifically need to reach a Region-only service. This is a deliberate design choice — AWS engineered Outposts so that a network interruption between the customer site and AWS does not immediately take down already-running production workloads, but it does freeze the ability to change them until connectivity is restored.

Redundant Uplinks

AWS recommends and typically provisions Service Link across at least two independent network paths where the customer’s site supports it, so a single fiber cut or single upstream provider outage does not sever the Outpost’s only connection to its parent Region. This redundancy protects the control plane connection, not the data plane, which as noted already survives Service Link loss on its own.

Blast Radius Thinking Applied To Outposts

Experienced architects borrow the “blast radius” framing from Region design and apply it directly to Outposts capacity planning. In a Region, an architect asks what fails if a single Availability Zone becomes unavailable, and designs so that the answer is “a portion of capacity, automatically absorbed elsewhere.” With Outposts, the equivalent question is what fails if this specific physical rack loses power, and the honest answer, absent a second Outpost, is “everything hosted on it.” Framing the Outpost itself as the unit of blast radius, rather than treating individual instances or subnets as independently resilient, keeps the availability conversation grounded in the actual physical reality of the hardware rather than in habits carried over from Region-based design.

Backup and Recovery Considerations

Because a single Outpost represents a concentrated physical failure domain, backup strategy deserves particular attention. EBS snapshots taken from volumes on an Outpost are typically stored back in the parent Region, meaning that even in a scenario where the physical rack itself is destroyed or permanently lost, point-in-time recovery data survives independently of the hardware. Teams building disaster recovery runbooks for Outposts deployments generally plan around two distinct failure scenarios: a temporary Service Link outage, where already-running workloads continue serving traffic and the main risk is an inability to make changes, and a catastrophic loss of the physical Outpost itself, where the recovery plan depends entirely on whether a second Outpost, a Region-based failover path, or both, were built into the original architecture.

Shared Responsibility, Physically Relocated

Outposts follows the standard AWS Shared Responsibility Model with one significant addition: because the hardware sits inside the customer’s own building, the customer takes on responsibility for physical security of the site itself — controlled access to the room, environmental controls, and protecting the rack from unauthorized physical tampering — responsibilities that in a Region belong entirely to AWS. AWS remains responsible for the security of the underlying Nitro hardware and hypervisor, encryption of the Service Link, and the software supply chain for the Outpost’s control agent.

Encryption in Transit

All traffic over Service Link is encrypted, protecting configuration data, control-plane commands, and telemetry as they traverse the connection between the customer site and the parent Region. This matters because Service Link, while logically private, typically rides over the customer’s own internet or private network uplink, and encrypting it removes the need to fully trust every network segment in between.

IAM Still Governs Everything

Because the control plane lives in the Region, every action taken against Outposts resources — launching an instance, modifying a security group, attaching a volume — is authorized through the same IAM policies, roles, and permission boundaries used everywhere else in the account. There is no separate, locally-managed identity system to configure on the Outpost itself; this is one of the strongest security advantages of the design, since it means an organization’s existing IAM governance, least-privilege policies, and audit trail through CloudTrail extend automatically to Outposts resources without a parallel system to secure and keep in sync.

Where Metrics Actually Live

CloudWatch metrics generated by resources running on an Outpost are collected locally and then shipped over Service Link to the Region for storage, alarming, and dashboarding — the same CloudWatch console and API surface used everywhere else in an AWS account. This means monitoring itself depends on Service Link connectivity: during a Service Link outage, new metrics cannot be delivered to the Region, creating a visible gap in dashboards even though the underlying workload may still be running perfectly well locally.

Hardware and Capacity Health

Beyond application-level CloudWatch metrics, AWS surfaces Outposts-specific health signals covering the physical hardware itself — capacity utilization against the physically installed ceiling, Service Link connection status, and hardware component health. These are essential for the capacity-planning discipline discussed earlier: teams need visibility into how close an Outpost is running to its hardware ceiling well before they hit a launch failure in production.

Logging Pipelines

Application and OS-level logs generated on Outposts instances typically flow through the same agents used in Region-based EC2 — a CloudWatch Logs agent, or a third-party log shipper — and, like metrics, that delivery depends on Service Link. Architects building for environments where Service Link outages are a realistic operational scenario often add local log buffering or local retention on the Outpost itself, so that logs generated during an outage are not lost but are simply delayed until connectivity returns.

Choosing Between Racks and Servers

The deployment decision starts with matching physical footprint and workload scale to the two form factors. Racks suit locations with real data-center-like facilities — sufficient power, cooling, and physical space — and workloads that need meaningful, growable compute and dedicated storage, such as a regional manufacturing plant running multiple production applications. Servers suit constrained footprints — a retail store, a clinic, a telecom edge site — where the workload is modest and the priority is minimal physical presence over raw scale.

Site Readiness Requirements

Before an Outpost can be ordered, AWS reviews the target site against defined power, cooling, physical space, and network uplink requirements, since the hardware, though managed by AWS, still consumes real electricity and generates real heat inside the customer’s building. Racks in particular have meaningful power and cooling demands comparable to a modest data-center footprint, and undersized facilities are a common cause of delayed or failed deployments.

Multi-Outpost and Multi-Site Strategies

Organizations with many locations — a national retail chain, a hospital network, a telecom operator — typically standardize a repeatable deployment pattern: the same instance types, the same subnet layout, the same monitoring configuration, replicated across every site’s Outposts server or rack. This turns what could be dozens or hundreds of bespoke deployments into a templated rollout, usually managed through infrastructure-as-code tooling that already understands ordinary AWS resource definitions, since Outposts resources are addressed through the same APIs as Region-based resources with an added Outpost identifier.

Integration With Existing AWS Environments

Because an Outpost’s subnet is an extension of an existing VPC, integration is largely additive rather than a rearchitecture: existing route tables, security groups, VPC peering, and Transit Gateway attachments continue to function, with the Outpost subnet simply appearing as another subnet within the address space. Teams already managing infrastructure through the AWS Cloud Development Kit, CloudFormation, or Terraform generally extend those same templates to include the Outpost subnet and its resources rather than maintaining a separate toolchain.

Ordering Lead Time As A Project Dependency

Unlike spinning up Region-based infrastructure, where capacity is available essentially on demand, ordering an Outpost involves manufacturing, shipping, and physical installation lead times that must be built into a project schedule as a hard dependency, similar to ordering traditional on-premises hardware from any vendor. Organizations that treat the Outposts order as something to initiate only once application development is largely complete frequently find the hardware becomes the critical path item that delays go-live, whereas organizations that place the order early, in parallel with application development and site readiness work, avoid that bottleneck entirely.

Refresh and Upgrade Cycles

Because the underlying hardware is owned and maintained by AWS but physically located at the customer site, hardware refreshes and capacity expansions follow a defined process closer to a managed service renewal than a customer-driven upgrade: AWS handles firmware updates and underlying hardware health remotely through Service Link wherever possible, while physical capacity additions or full hardware refreshes require a new site visit. Building an approximate refresh cadence into long-term capacity planning, typically aligned with the multi-year lifecycle of the physical hardware, helps avoid an unplanned capacity crunch late in an Outpost’s operational life.

Pattern: Local Processing, Regional Aggregation

A widely used pattern places latency-sensitive, high-volume raw processing on the Outpost — for instance, filtering and summarizing sensor data from a factory floor — and sends only the aggregated, much smaller result set over Service Link to the Region for long-term storage, cross-site analytics, or machine learning training. This minimizes both Service Link bandwidth consumption and the amount of raw data exposed outside the local site, while still letting the organization benefit from the Region’s broader analytics and storage services.

Pattern: Outpost as a Degraded-Mode Island

Given that the data plane survives a Service Link outage, some architectures deliberately design the application to keep functioning, in a reduced but acceptable capacity, purely on local resources during connectivity loss — queuing any Region-dependent actions locally and replaying them once Service Link is restored. This pattern is common in retail point-of-sale systems, where a store must keep processing transactions even if its connection to AWS is briefly interrupted.

Pattern: Hybrid Database Placement

For workloads needing a managed relational database with local latency, teams commonly run the database engine locally on the Outpost (using supported managed database configurations) for the hot, latency-sensitive path, while replicating data asynchronously to a fully managed instance in the Region for reporting, backup, and disaster recovery — combining local performance with the Region’s broader durability and analytics capabilities.

Common Mistake: Underestimating Site Readiness Timelines

Organizations frequently underestimate how long it takes to get a physical site — power circuits, cooling capacity, network cabling — ready to receive an Outpost, treating it as a software procurement timeline rather than a facilities project. Building site readiness into the project plan from day one, in parallel with the AWS ordering process, avoids the common scenario where the hardware arrives before the room is ready for it.

Common Mistake: Ignoring the Narrower Service Catalog

Teams sometimes design an application assuming a Region-equivalent service catalog will be available on the Outpost, only to discover late in the project that a specific managed service they planned to use locally has no on-Outpost equivalent and must instead be called over Service Link, changing the latency profile of that code path significantly. Validating the target service list against the specific Outpost configuration early in the design phase prevents this.