AWS Outposts racks FAQs

You can use Outposts racks to support your applications that have low latency or local data processing requirements. These applications may need to generate near real-time responses to end user applications or need to communicate with other on-premises systems or control on-site equipment. These can include workloads running on factory floors for automated operations in manufacturing, real-time patient diagnosis or medical imaging, and content and media streaming. You can use Outposts racks to securely store and process customer data that needs to remain on-premises or in countries where there is no AWS Region. You can run data intensive workloads on Outposts racks and process data locally when transmitting data to AWS Regions is expensive and wasteful and for better control on data analysis, backup and restore.

First-generation Outposts racks are supported in the following AWS Regions and customers can connect their Outposts to the following AWS Regions:

Second-generation Outposts racks are currently supported in the following AWS Regions and customers can connect their Outposts to the following AWS Regions:

Support for more Regions is coming soon.

First-generation Outposts racks can be shipped to and installed in the following countries and territories.

• NA - US, Canada, Mexico
• EMEA - All EU countries, United Kingdom (UK), Switzerland, Norway, Bahrain, the United Arab Emirates (UAE), Israel, South Africa, Gibraltar, Morocco, Nigeria, Kenya, Oman, Kazakhstan, Serbia, Qatar, Egypt, Iceland, Turkey, the Kingdom of Saudi Arabia*, Senegal, Jordan, Kuwait
• APAC - Australia, New Zealand, Japan, South Korea, Taiwan, Singapore, Indonesia, Malaysia, Thailand, the Philippines, Brunei, India, Vietnam, Bangladesh
• SA - Brazil, Colombia, Argentina, Chile, Peru, Ecuador, Trinidad and Tobago, Uruguay
• CA - Puerto Rico, Costa Rica, Panama, Guatemala

Second-generation Outposts racks can be shipped to and installed in the US and Canada.

Support for more countries and territories is coming soon.

* Customers deploying in the Kingdom of Saudi Arabia may require additional authorization. Contact your AWS Sales Representative to learn more.

No, we can deliver and install Outposts racks only in countries and territories where Outposts racks can be delivered and supported.

An Outpost relies on connectivity to the parent AWS Region. Outposts racks are not designed for disconnected operations or environments with limited to no connectivity. We recommend that customers have highly available networking connections back to their AWS Region. If interested in leveraging AWS services in disconnected environments such as cruise ships or remote mining locations, learn more about AWS services such as Snowball Edge, which is optimized to operate in environments with limited to no connectivity.

No, AWS Outposts racks leverage AWS designed infrastructure, and is only supported on AWS-designed hardware that is optimized for secure, high-performance, and reliable operations.

No, AWS Outposts racks are a fully managed service that provides you with native access to AWS services.

No, AWS Outposts racks provide fully integrated AWS designed configurations with built in top-of-rack switches and redundant power supply to ensure an ideal AWS experience. You can order as much compute and storage infrastructure as you need by selecting from the range of available Outposts rack options, or work with us to create a custom combination with your desired Amazon Elastic Compute Cloud (EC2), Amazon Elastic Block Store (EBS), and Amazon Simple Storage Service (S3) capacity*. These are pre-validated and tested to ensure that you can get started quickly with no additional effort or configuration required on-site.

*S3 on Outposts is currently available on first-generation Outposts racks only.

The primary benefits of second-generation Outposts racks include:

• Simplified scaling and built-in resiliency: The introduction of the Outposts network rack enables seamless deployment of AWS Outpost racks in on-premises or co-location spaces and enables decoupling of compute and networking. The network rack serves as a traffic aggregation layer and eliminates the need for multiple uplinks between compute racks and on-premises customer managed switches. The network rack also comes with built-in resiliency to handle switch failures, making it easier for customers to architect for high availability of their Outposts network.
• Supporting the latest in-Region EC2 instance types: With the new generation of Outposts racks, customers can run the latest generation x86-powered Amazon EC2 instances on-premises, starting with general purpose M7i instances, compute optimized C7i instances, and memory optimized R7i instances, adding to the choice of fifth generation comparable Amazon EC2 instances that the previous generation of Outposts racks already supports today. With M7i, C7i, and R7i instances, customers are able to run a broad range of on-premises workloads with even better performance. C7i, M7i, and R7i instances deliver 2x the vCPU, memory, and network bandwidth and up to 40% better performance compared to C5, M5, and R5 instances on first-generation Outposts racks.
• New purpose-built Outposts instance types: Second-generation Outposts racks introduce a new category of Outposts specific Amazon EC2 instances (e.g. Bmn-sf2e and Bmn-cx2) with accelerated networking, designed for ultra-low latency and throughput-intensive workloads. The Outposts accelerated networking instance category includes Bmn-sf2e instances—optimized for ultra-low latency and deterministic networking—and Bmn-cx2 instances—optimized for high throughput and low latency. These bare metal instances feature specialized network accelerator cards directly connected to top-of-rack (TOR) switches, ideally suited for workloads such as financial exchanges, real-time market data distribution, telecom 5G core, and media distribution. 

Yes, you can launch EC2 instances using the AMIs backed with EBS gp2 or gp3 volume types on second-generation Outposts racks, and gp2 volume type on first-generation Outposts racks.

Yes, support for more EC2 instances, including GPU-based instances, is coming soon.

EBS snapshots of EBS Volumes on Outposts racks are stored by default on Amazon S3 in the Region. If the Outpost is provisioned with Amazon S3 on Outposts you have the option to store your snapshots locally on your Outpost. EBS snapshots are incremental, which means that only the blocks on your Outpost that have changed after your most recent snapshot are saved. You can at any time restore (hydrate) EBS Volume on Outposts from the stored snapshots. To learn more, visit the EBS Snapshots documentation.

You can set resource-level IAM policies and permissions on your Outpost for EBS Local Snapshots on Outposts and AMI images to enforce data residency. Each account (or IAM user or role) can set up a data residency enforcement policy for single or multiple Outposts. This will block the creation or copy of local snapshots and images as well as API/CLI calls outside the specified Outposts rack ARN. All of the create, update, and copy operations are logged in CloudTrail audit logs, so you can track that local snapshots reside in your location. To learn more, visit the EBS Snapshots documentation.

S3 on Outposts, available on first-generation Outposts racks, is ideal for customers with data residency requirements or those in regulated industries that need to securely store and process customer data that needs to remain on premises or in locations where there is no AWS region. Additionally, customers can use S3 on Outposts to run data intensive workloads to process data locally and store on-premises. S3 on Outposts will also help if you have applications that need to communicate with other on-premises systems or control on-site equipment, such as within a factory, hospital, or research facility.

You can choose to establish Outposts rack service link VPN connection to the parent AWS Region via an AWS Direct Connect private connection, a public virtual interface, or the public Internet.

Yes, Application Load Balancer is available on Outposts racks in all AWS Regions where Outposts racks are available, except the AWS GovCloud (US) Regions.

Yes, with Amazon RDS on Outposts you can run managed Microsoft SQL Server, MySQL, and PostgreSQL databases on premises for low latency workloads that need to be run in close proximity to onpremises data and applications. You can manage RDS databases both in the cloud and on-premises using the same AWS Management Console, APIs, and CLI. For ultra low-latency applications, ElastiCache on Outposts enables sub-millisecond responses for real-time applications, including workloads running on factory floors for automated operations in manufacturing, real-time patient diagnosis, and media streaming.

Yes. Customer data can be configured to remain on Outposts racks using Amazon Elastic Block Store (EBS) and Amazon Simple Storage Service (S3) on Outposts, in the customer’s on-premises location or specified co-location facility. Well-architected applications using Outposts racks and AWS services and tools address the data residency requirements we most commonly hear from our customers. AWS Identity and Access Management (IAM) lets you control access to AWS resources. You can use IAM and granular data control rules to specify which types of data must remain on Outposts racks and cannot be replicated to the AWS Region. S3 on Outposts stores data on your Outpost by default, and you may choose to replicate some or all of your data to AWS Regions based on your specific residency requirements. ElastiCache on Outposts allows you to securely process customer data locally on the Outposts rack. Some limited meta-data (e.g. instance IDs, monitoring metrics, metering records, tags, bucket names, etc.) will flow back to the AWS Region.

To ensure your unique data residency requirements are met, we recommend you confirm and work closely with your compliance and security teams.

Yes. AWS Resource Access Manager (RAM) is a service that enables you to share your AWS resources with any AWS account or within your AWS Organization. RAM support lets you, the Outpost owner, create and manage Outpost resources — EC2 instances, EBS volumes, subnets, and local gateways (LGWs) centrally — and share the resources across multiple AWS accounts within the same AWS organization. This allows others to configure VPCs, launch and run instances, and create EBS volumes on the shared Outpost.

EC2 instances built on the AWS Nitro System, for general purpose, compute optimized, memory optimized, storage optimized, and GPU optimized with Intel Xeon Scalable processors are supported on AWS Outposts racks, and Graviton processors based EC2 instances are coming soon.

You can use Route 53 Resolver to resolve Domain Name Server (DNS) queries locally on Outposts racks, improving the availability and performance of your on-premises applications. When you enable Route 53 Resolver on Outposts, Route 53 automatically stores DNS responses on Outposts racks and provides continued DNS resolution for your applications even during unexpected network disconnects to the parent AWS Region. By serving DNS responses locally, Route 53 Resolver on Outposts also enables low-latency DNS resolution, improving the performance of your on-premises applications.

In addition, you can connect the Route 53 Resolvers on Outposts racks with DNS servers in your on-premises data centers through Route 53 Resolver endpoints. This enables resolution of DNS queries between the Outposts racks and your other on-premises resources.

Yes, support for more AWS services is coming soon.

Your site must support the basic power, networking and space requirements to host an Outpost. For first-generation Outposts racks deployments, an Outposts rack needs 5-15 kVA, can support 1/10/40/100 Gbps uplinks, and needs space for a 42U rack. For second-generation Outposts racks deployments, an Outposts compute rack needs 10-30 kVA and an Outposts network rack needs 8.89 kVA. Second-generation Outposts racks support 10/40/100 Gbps uplinks, and need space for two 42U racks. For more facility requirements, visit the Outposts racks configuration page. As Outposts racks require reliable network connectivity to the AWS Region, you should plan for a public internet connection. Customers must have Enterprise Support or Enterprise On-Ramp Support, which provides 24x7 remote support within 15 minutes or within 30 minutes depending on the Support plan selected.

At the end of your Outposts rack term, you can either renew your subscription and keep your existing Outposts rack(s), or return your Outposts rack(s). If you do not notify AWS which option you intend to take, your Outposts rack(s) will be renewed on a monthly basis, at the rate of the No Upfront payment option corresponding to your AWS Outposts rack configuration. For more information, see term end documentation here.

AWS Outposts racks themselves are HIPAA eligible, PCI, SOC, ISMAP, IRAP and FINMA compliant, ISO, CSA STAR, and HITRUST certified, and we expect to add more compliance certifications in coming months. You can see the latest certification status for AWS Services on Outposts rack on our Services in Scope page. AWS Services on Outposts racks like RDS or Elasticache Redis that have achieved certifications like PCI are also considered certified on Outposts rack. As AWS Outposts racks run at the customer’s data center, under the AWS Shared Responsibility model customers own the responsibility for physical security and access controls around the Outpost for compliance certification.

Yes, AWS Outposts racks are GxP compatible. AWS Outposts racks extend AWS services to AWS-managed infrastructure that is physically located at a customer site. Outposts racks capacity can be accessed locally over a local gateway that is mapped to the customer’s local network, in addition to having a connection path back to the AWS Region. You can learn more about using the AWS Cloud, including Outposts racks, for GxP systems here. GxP-regulated life sciences organizations using AWS services are responsible for designing and verifying their GxP compliance.

AWS provides services that allow data to be encrypted at rest and in-transit and other granular security controls and auditing mechanisms. In addition, customer data is wrapped to a physical Nitro Security Key. Destroying the device is equivalent to destroying the data.  As part of the shared responsibility model, customers are responsible for attesting to physical security and access controls around the Outpost, as well as environmental requirements for facility, networking, and power as published here. Prior to returning the Outposts rack hardware, the Nitro Security Key will be removed to ensure customer content is crypto shredded.

FedRAMP has granted authorization to AWS Outposts, excluding the hardware components of the service. The physical and environmental controls for the AWS Outposts protection while at the customers’ sites are the customers’ responsibilities. Customers and agencies can make a risk-based decision to use AWS Outposts or conduct a Type Accreditation to review the hardware components of AWS Outposts to process FedRAMP workloads. Assessment results previously conducted by the AWS Third Party Assessment Organization can be accessed via CapLinked.

Bmn-sf2 instances and Bmn-cx2 instances follow an updated Shared Responsibility Model. Customers are responsible for managing both the network accelerator cards inside Bmn-sf2e and Bmn-cx2 servers and the associated bare metal network switches. They can fulfill this responsibility through in-house IT personnel, AWS Professional Services, AWS Managed Services, or third-party service providers.  In the event of a failure with the network accelerator cards, customers can reach out to AWS for support.

When your Outpost is installed and is visible in the AWS Management Console, AWS will monitor it as part of the public Region and will automatically execute software upgrades and patches.

If there is a need to perform physical maintenance, AWS will reach out to schedule a time to visit your site. AWS may replace a given module as appropriate but will not perform any host or network switch servicing on customer premises.

EC2 instances and EBS volumes already attached to the instances on the Outpost will continue to operate normally and can be accessed locally through the local gateway. Similarly, AWS service resources such as ECS worker nodes continue to run locally. However, API availability will be degraded, for instance run/start/stop/terminate APIs may not work. Instance metrics and logs will continue to be cached locally for up to 7 days, and will be pushed to the AWS Region when connectivity returns. Disconnection beyond 7 days however may result in loss of metrics and logs. If you expect to lose network connectivity, we strongly recommend regularly testing your workload to ensure it behaves properly in this state when an Outpost is disconnected. For S3 on Outposts, all requests are authenticated and authorization using the regional AWS Identity and Access Management (IAM) service, then securely cached locally on the Outpost when used with SigV4. If the Outpost has no connectivity to the home AWS Region, existing users can continue to operate on existing buckets with all object operations for up to 12 hours. During disconnected periods, you can add and delete objects, but cannot create or add new buckets, new users, or change bucket policies. Once connectivity is restored, you can resume all bucket management updates.

As an example, information about instance health, instance activity (launched, stopped), and the underlying hypervisor system may be sent back to the parent AWS Region. This information enables AWS to provide alerting on instance health and capacity, and apply patches and updates to the Outpost. Your team does not need to implement your own tooling to manage these elements, or to actively push security updates and patches for your Outpost. For S3 on Outposts, certain data management and telemetry data, such as bucket names and metrics, may be stored in the AWS Region for reporting and management. When disconnected, this information cannot be sent back to the parent Region.

There are two mechanisms to increase your compute and storage capacity of your AWS Outposts racks. First, you can increase capacity by adding additional Outposts racks from the Outposts rack catalog. Second, if your existing Outposts racks have available power and positions within the rack, you can increase from a “small” to a “medium” or “large” configuration, or from a” medium” to a “large” configuration. Note: The 1U and 2U Outposts servers cannot be installed in the 42U Outposts form factor.