Cargando...
Cargando...
Run native AWS infrastructure and services on-premises for true hybrid cloud with local data residency and ultra-low latency.
AWS Outposts is a fully managed service that extends AWS infrastructure, services, APIs, and tools to virtually any on-premises or edge location. AWS physically delivers and installs rack-mounted hardware at your facility, and you use the same AWS Management Console, CLI, and SDKs to manage both your Outpost and your AWS Region workloads. It is the only AWS solution that provides actual AWS-owned hardware running in your data center, enabling true hybrid consistency rather than just connectivity.
Enable workloads that require low latency access to on-premises systems, local data processing, or strict data residency requirements to run on genuine AWS infrastructure without leaving the customer's facility.
Use When
Avoid When
EC2 instances on Outposts
Broad instance family support; specific instance types depend on Outpost configuration ordered
EBS volumes on Outposts
Local EBS storage; snapshots exported to Region S3
S3 on Outposts
Separate service from regional S3; data stays on Outpost; requires outpost-specific access points
RDS on Outposts (MySQL, PostgreSQL, SQL Server)
Managed RDS with local data residency; Multi-AZ supported
RDS Aurora on Outposts
Aurora is NOT supported on Outposts — critical exam trap
RDS Aurora Serverless on Outposts
Neither Aurora nor Aurora Serverless is available on Outposts
AWS Lambda on Outposts
Lambda is NOT supported on Outposts; use EC2 or ECS for compute
Amazon ECS on Outposts
Supported on both Outpost racks and Outpost servers
Amazon EKS on Outposts
Both extended clusters and local clusters supported on racks
Amazon EMR on Outposts
Supported on Outpost racks; useful for local big data processing
ElastiCache on Outposts
Supported on Outpost racks for local caching
Application Load Balancer (ALB) on Outposts
ALB can be deployed on Outposts for local load balancing
Network Load Balancer (NLB) on Outposts
NLB is not currently supported on Outposts
AWS Systems Manager integration
SSM manages Outpost instances identically to Region instances
AWS IAM and IAM Identity Center
Same IAM policies and roles apply; control plane remains in Region
VPC and Security Groups
Outpost subnets are extensions of Regional VPCs; all VPC features apply
Local Gateway (LGW)
Enables on-premises network routing from Outpost instances
AWS CloudFormation on Outposts
Infrastructure as Code works seamlessly with Outpost resources
AWS CloudWatch metrics for Outposts
Metrics sent to CloudWatch in the home Region
Hardware ownership
AWS owns, manages, and is responsible for hardware maintenance and replacement
Disconnected/offline operation
Running workloads continue during Region connectivity loss; management operations require connectivity
Dedicated Low-Latency Hybrid Backbone
high freqDirect Connect provides the high-bandwidth, low-latency, consistent network path between the Outpost and its home AWS Region. This is the recommended (and often required) connectivity pattern for production Outposts deployments. Without Direct Connect, control plane operations and data transfer rely on internet-based VPN, which introduces latency variability and bandwidth limitations.
Extended VPC Subnet Architecture
high freqOutpost subnets are created as extensions of an existing Regional VPC. Instances on the Outpost receive IP addresses from the VPC CIDR, participate in the same security groups and route tables, and communicate with Regional resources over the service link. This unified networking model is what makes Outposts feel like a seamless extension of the cloud.
Unified Hybrid Fleet Management
high freqSystems Manager (SSM) manages Outpost EC2 instances identically to Regional instances — patch management, Run Command, Session Manager, Parameter Store, and Inventory all work without modification. This eliminates the need for separate on-premises management tooling and provides a single operational pane of glass.
Tiered Edge Architecture
high freqOutposts and Local Zones solve different problems: Local Zones are AWS-managed infrastructure in metro areas (you share the hardware), while Outposts are dedicated AWS hardware in YOUR facility. Use Local Zones for latency-sensitive apps near population centers; use Outposts when you need hardware physically inside your own data center or factory for data residency or ultra-low local latency.
Local Data Residency with Managed Database
high freqRDS on Outposts runs the managed database service (MySQL, PostgreSQL, SQL Server) with the primary instance physically on the Outpost, satisfying data residency requirements. The Multi-AZ standby can be placed in the AWS Region for disaster recovery. AWS handles patching, backups, and failover — you get managed database operations with local data placement.
Centralized Identity for Hybrid Workloads
medium freqIAM Identity Center (formerly SSO) provides centralized authentication for both Regional and Outpost resources. Users access Outpost-hosted applications and management consoles through the same identity provider federation, eliminating separate on-premises identity silos.
Hybrid Content Delivery with Local Origin
medium freqCloudFront can use EC2 instances or ALBs on Outposts as custom origins. This pattern serves dynamic content generated locally (e.g., from on-premises databases) through CloudFront's global CDN for static asset caching and edge delivery, combining local compute with global distribution.
Resilient Local Kubernetes with EKS Local Clusters
medium freqEKS Local Clusters place the Kubernetes control plane on the Outpost itself, enabling full Kubernetes API operations even during loss of connectivity to the AWS Region. This is the pattern for manufacturing, retail, and edge environments where network reliability cannot be guaranteed but Kubernetes workloads must continue operating.
Aurora and Aurora Serverless are NEVER supported on Outposts. If an exam question requires a managed relational database with local data residency, the answer is RDS on Outposts (MySQL, PostgreSQL, or SQL Server) — never Aurora. This is the single most commonly tested Outposts fact.
Outposts subnets are EXTENSIONS of a Regional VPC — not separate VPCs, not separate accounts, not a different network construct. EC2 instances on Outposts get VPC CIDR IPs and participate in the same security groups, NACLs, and route tables as Regional instances. If a question asks about networking architecture for Outposts, the VPC extension model is the answer.
The Local Gateway (LGW) is the key networking component unique to Outposts. It enables traffic routing between Outpost instances and the on-premises network (your corporate LAN). It is NOT an Internet Gateway, NOT a Virtual Private Gateway, and NOT a Transit Gateway. Questions about 'how do Outpost instances communicate with on-premises servers' always involve the LGW.
Distinguish Outposts vs. Local Zones vs. Wavelength Zones in exam scenarios: Outposts = YOUR facility, dedicated hardware, data residency; Local Zones = AWS-managed metro edge, shared hardware, latency to city users; Wavelength Zones = 5G carrier network edge, ultra-low latency to mobile devices. The scenario description will tell you which is correct.
Aurora and Aurora Serverless CANNOT run on Outposts. For managed relational databases with on-premises data residency, the only answer is RDS on Outposts with MySQL, PostgreSQL, or SQL Server. This appears on every certification exam that covers Outposts.
Outposts subnets are extensions of a Regional VPC — not separate networks. The Local Gateway (LGW) is the unique networking component that routes traffic between Outpost instances and your on-premises network. Know this architecture cold for both SAA-C03 and SAP-C02.
Differentiate Outposts (YOUR facility, dedicated hardware, data residency) vs. Local Zones (AWS metro facility, shared hardware, city-level latency) vs. Wavelength (5G carrier edge, mobile latency). The scenario's location requirement determines which service is correct.
Outposts racks support a broader set of services (RDS, EKS, EMR, ElastiCache, ALB) while Outposts Servers (1U/2U) support a smaller subset (primarily EC2 and ECS). If an exam question describes a space-constrained location (retail store, branch office) needing managed databases or EKS, the answer is an Outpost rack, not a server.
S3 on Outposts is a SEPARATE service from Amazon S3. Data stored in S3 on Outposts stays on the Outpost by default — it does NOT automatically replicate to the AWS Region. To get regional copies, you must configure S3 Replication explicitly. The API endpoint format, ARN format, and access point requirements are all different from standard S3.
AWS Lambda is NOT supported on Outposts. If a question describes a scenario requiring serverless compute with local data residency, the correct approach is to use EC2 or ECS on Outposts, not Lambda. There is no way to run Lambda functions locally on Outposts hardware.
For EKS on Outposts, know the two modes: (1) Extended clusters — control plane in Region, worker nodes on Outpost, requires Region connectivity; (2) Local clusters — control plane ON the Outpost, works during connectivity loss. Exam scenarios about 'resilient Kubernetes during network outages' require EKS Local Clusters.
Outposts hardware is OWNED and MANAGED by AWS. AWS is responsible for hardware maintenance, upgrades, and replacement. You provide power, space, cooling, and network connectivity. This shared responsibility model distinction is tested — candidates sometimes assume customer owns the hardware because it's on-premises.
Direct Connect is the recommended connectivity solution between an Outpost and its home Region. While VPN over internet works, it introduces latency variability and bandwidth constraints. Exam scenarios involving production Outposts with high throughput or strict latency requirements should select Direct Connect as the connectivity layer.
Common Mistake
Aurora Serverless can run on Outposts to provide a managed, scalable database with local data residency.
Correct
Aurora (including Aurora Serverless v1 and v2) is NOT supported on Outposts at all. For managed relational databases with local data residency, only RDS on Outposts with MySQL, PostgreSQL, or SQL Server is available. Aurora's distributed storage architecture is fundamentally incompatible with the Outposts local storage model.
This is the #1 Outposts trap on certification exams. Candidates see 'managed database + data residency' and jump to Aurora because it's AWS's flagship managed database. Memorize: Aurora = Regional only. RDS on Outposts = MySQL, PostgreSQL, SQL Server only.
Common Mistake
Standard RDS Multi-AZ in an AWS Region satisfies on-premises data residency requirements because the data is replicated and protected.
Correct
Standard RDS Multi-AZ keeps ALL data (primary and standby) within AWS Regions. No data ever touches your on-premises facility. Only RDS on Outposts places the primary DB instance physically in your data center, satisfying data residency mandates. Multi-AZ protects availability, not location.
Regulatory requirements like GDPR, financial data sovereignty laws, and healthcare regulations often specify WHERE data must physically reside, not just how it's protected. 'Multi-AZ = data residency' is a dangerous conflation that appears repeatedly in exam scenarios.
Common Mistake
AWS Outposts is just a networking solution — it connects your on-premises systems to AWS through a dedicated link, similar to Direct Connect.
Correct
Outposts is physical infrastructure — actual AWS-owned servers and racks installed in your facility. You run EC2 instances, RDS databases, EKS clusters, and other AWS services directly on Outpost hardware. Direct Connect is a network connection; Outposts is compute and storage hardware. They are complementary, not equivalent.
Candidates confuse 'hybrid cloud connectivity' (Direct Connect, VPN) with 'hybrid cloud infrastructure' (Outposts). The exam will describe scenarios requiring local compute and ask you to choose between them. Key differentiator: if the workload needs to RUN locally (not just connect), the answer is Outposts.
Common Mistake
Outposts and Local Zones are interchangeable — both put AWS infrastructure close to users for low latency.
Correct
Local Zones are AWS-operated extensions of a Region in metropolitan areas — you share the infrastructure with other AWS customers and cannot place them inside your own facility. Outposts are dedicated AWS hardware delivered to YOUR specific location (your data center, factory, hospital). Local Zones serve latency-to-city-users scenarios; Outposts serve data-must-stay-in-my-building scenarios.
Both appear in the same exam question pool about 'low latency' and 'edge computing.' The decisive factor is: who owns/controls the location? If it's your facility → Outposts. If it's a metro area AWS facility → Local Zones. If it's a 5G carrier network → Wavelength.
Common Mistake
Self-hosting a database on EC2 on Outposts provides the same operational benefits as RDS on Outposts.
Correct
EC2-hosted databases require you to manage patching, backups, replication, failover, and parameter tuning yourself. RDS on Outposts is a fully managed service — AWS handles automated backups, Multi-AZ failover, engine patching, and monitoring. The operational burden difference is significant, and exam questions about 'minimizing operational overhead' with local data residency should point to RDS on Outposts, not EC2 with a self-managed database.
The 'managed vs. self-managed' distinction is a core AWS exam principle. Outposts doesn't change this — RDS on Outposts is still managed; EC2+MySQL is still self-managed. Don't let the on-premises context make you forget the fundamental managed service value proposition.
Common Mistake
If the Outpost loses connectivity to the AWS Region, all workloads stop running.
Correct
Running EC2 instances and workloads on an Outpost continue to operate during connectivity loss to the home Region. The control plane (console, API, new launches) requires connectivity, but existing running workloads are not interrupted. EKS Local Clusters extend this further by keeping the Kubernetes control plane operational on the Outpost itself during disconnection.
This misconception leads candidates to incorrectly dismiss Outposts for resilience-critical scenarios. The correct understanding is that Outposts provides local resilience for running workloads, with the Region providing management and broader AWS services.
ORCA for Outposts services: O=Only-EC2/ECS on Servers, R=RDS (MySQL/PostgreSQL/SQLServer only, Never Aurora), C=Containers (EKS+ECS on racks), A=ALB (yes) but Not NLB — remember ORCA swims locally, Aurora is too big for the pond.
LGW = 'Local Goes Where' — the Local Gateway is how traffic from Outpost instances goes WHERE it needs to on your on-premises network.
Outposts vs. Local Zones vs. Wavelength: 'YOUR building vs. THEIR city vs. 5G carrier' — location ownership is the key differentiator.
For data residency questions: 'If data must stay in your building, only Outposts will do the billing' — no other AWS service physically places primary data on-premises.
Pricing memory: Outposts = '3-year rack rental where AWS owns the rack' — you reserve capacity like Reserved Instances but for dedicated hardware you don't own.
CertAI Tutor · SAA-C03, SAP-C02, DEA-C01, CLF-C02 · 2026-02-22