Amazon EMR on AWS Outposts
AWS Outposts is a fully managed service that extends AWS infrastructure, services, APIs, and tools to virtually any datacenter, co-location space, or on-premises facility for a truly consistent hybrid experience. Amazon EMR on AWS Outposts enables you to run Apache Spark, Hadoop, Hive, and other big data frameworks on Outposts hardware while maintaining the same EMR APIs, management console, and operational model as in an AWS Region.
When to Use EMR on Outposts
EMR on Outposts is designed for specific scenarios where cloud-only processing is insufficient. Consider Outposts when:
| Scenario | Why Outposts | Alternative If Not Required |
|---|---|---|
| Data residency / sovereignty | Regulations require data to remain in a specific physical location or country that lacks an AWS Region | EMR in the nearest AWS Region |
| Low-latency processing | Workloads must process data generated by on-premises systems with single-digit millisecond network latency | EMR in Region with Direct Connect |
| Large on-premises data gravity | Petabyte-scale datasets reside on-premises and cannot be migrated to S3 quickly; process locally while migrating in parallel | EMR in Region after data migration completes |
| Hybrid burst | Steady-state processing runs on-premises, burst capacity runs in the Region | EMR in Region with federated query |
| Disconnected or limited connectivity | Sites with unreliable WAN connectivity that need to continue processing during network interruptions | Not applicable — Outposts is the right fit |
When NOT to use Outposts:
If your data already resides in Amazon S3 or can be migrated there within your timeline — run EMR in the Region for full feature availability and elasticity.
If cost optimization is the primary driver — Outposts hardware has fixed capacity and does not benefit from Spot Instances or Serverless scaling.
If you need the latest EMR features immediately — Outposts may lag behind Region availability for certain capabilities.
Architecture Patterns
Pattern 1: Local Processing with Regional Management
The most common pattern: EMR clusters run on Outposts compute, the management plane (cluster creation, monitoring, step submission) operates from the parent Region, and results are replicated to S3 in the Region for downstream analytics.
Data flow:
On-premises data sources → local HDFS or S3 on Outposts → EMR processing on Outposts → results to regional S3
Cluster metadata and logs → parent AWS Region
Key consideration: Outposts must maintain network connectivity to the parent Region for cluster management operations. During a network disconnection, existing clusters continue running but cannot be managed remotely.
Pattern 2: Hybrid Processing (Split Workloads)
Run latency-sensitive or data-residency-bound workloads on Outposts while running elastic, bursty workloads in the Region:
On Outposts: Real-time ingestion, initial ETL, sensitive data processing
In Region: Large-scale batch analytics, ML training, ad hoc queries on aggregated/anonymized data
This pattern works well during migration — process locally while gradually shifting workloads to the Region as data migrates to S3.
Pattern 3: Disaster Recovery / Business Continuity
Maintain an Outposts-based EMR environment as a DR target for critical on-premises Hadoop workloads. If the primary on-premises cluster fails, jobs can fail over to EMR on Outposts with minimal data movement since data stays on-premises.
Deployment Considerations
Network Connectivity
Network connectivity between the Outpost and its parent AWS Region is critical:
Service link: A private, encrypted connection from Outposts to the parent Region for management traffic. Minimum 1 Gbps recommended for EMR workloads.
Local Gateway (LGW): Enables communication between Outposts subnets and your on-premises network for data ingestion from local sources.
VPC configuration: EMR clusters on Outposts run in a VPC subnet associated with the Outpost. Standard VPC networking rules (security groups, NACLs, route tables) apply.
Bandwidth planning: Size the service link bandwidth based on:
Log and metric upload volume (continuous)
Cluster creation/termination frequency
Step submission rate
Data replication to regional S3 (if applicable)
Supported Instance Types
Not all EC2 instance types are available on Outposts. The available types depend on your Outpost configuration (rack form factor and installed compute sleds). Common instance families supported for EMR:
General purpose: m5, m5d
Compute optimized: c5, c5d
Memory optimized: r5, r5d
Check your Outpost's available capacity in the AWS Outposts console or via the ec2 describe-instance-type-offerings --location-type outpost API call before sizing your EMR cluster.
Storage
Amazon EBS: On first-generation Outposts racks, only General Purpose SSD (gp2) volumes are supported for EMR node storage. Second-generation Outposts racks (announced June 2025) also support gp3 volumes. Check your Outpost rack generation before sizing EBS storage.
Local instance storage: Instance types with local NVMe (d-suffix) provide high-throughput local storage for shuffle and temporary data.
Amazon S3 on Outposts: Provides local object storage for workloads that need S3-compatible access without traversing the WAN. Note: S3 on Outposts has different capacity limits and pricing than regional S3.
HDFS: You can run HDFS on EMR core nodes for workloads that require HDFS semantics, though S3 on Outposts is preferred for new deployments.
Limitations and Considerations
In the event of a network disconnection between the Outpost and the parent Region, the following behavior applies:
Existing clusters continue to run, however no new clusters can be created.
New actions on existing clusters will fail, such as replacing an unavailable instance.
Other actions will be delayed, such as adding new steps to a running cluster or checking step status or sending CloudWatch metrics.
Existing clusters with terminate protection disabled may be terminated. Make sure to enable termination protection for production clusters.
Other external dependencies such as Amazon S3 (regional), DynamoDB, and Amazon RDS will not be accessible unless using S3 on Outposts or local data sources.
Additional limitations:
| Limitation | Impact | Workaround |
|---|---|---|
| No Spot Instances | Cannot use Spot for cost optimization | Use Reserved Instances or Savings Plans for Outposts capacity |
| Only gp2 EBS volumes | No gp3, io1/io2, or st1/sc1 volumes | Use instance store (d-suffix instances) for high-throughput needs |
| Limited instance types | Cannot use Graviton, latest-generation instances | Size clusters using available families; validate performance early |
| No EMR Serverless | Serverless deployment option not available | Use transient EMR on EC2 clusters for job isolation |
| No EMR on EKS | EKS deployment option not available on Outposts | Use standard EMR on EC2 |
| No Managed Scaling | Auto-scaling not supported on Outposts | Pre-provision capacity for peak; use custom scaling via CloudWatch alarms |
| Limited EMR features | Some features may not be available (check release notes) | Validate feature availability during POC |
Migration Considerations
If your target architecture includes EMR on Outposts as a transitional or permanent deployment:
Capacity planning is critical — Unlike the Region, Outposts has fixed capacity. Size your Outpost hardware order based on peak EMR workload requirements plus headroom for growth.
Test network disconnection behavior — Validate that your critical workloads survive a temporary loss of Region connectivity. Design jobs to be idempotent and include retry logic.
Plan for software updates — EMR release updates are applied from the Region. Ensure your change management process accounts for the network dependency.
Consider Outposts as a stepping stone — Many customers use EMR on Outposts during the migration period (processing data locally while migrating to S3), then move fully to EMR in the Region once data migration is complete.
For supported instance types and full configuration details, see EMR Clusters on AWS Outposts in the Amazon EMR Management Guide.