AWS Outposts

AWS Outposts brings fully managed AWS infrastructure and services to virtually any customer site to support modernization of manufacturing workloads and business critical plant floor applications. With common infrastructure, services, APIs, and tools across their cloud and on-premises environments, manufacturers can become more agile, efficient, and competitive. AWS compute, storage, database, and other services run locally on Outposts, and users can access the full range of AWS services available in the Region to build, manage, and scale on-premises applications using familiar AWS services and tools. AWS helps manufacturers securely innovate and accelerate time to market with product and production design in the cloud by providing instant compute and storage scalability at a low cost. This results in improved Overall Equipment Effectiveness (OEE), deeper customer insights and increased value with improved product offerings. With AWS Outposts, this can be a seamless integration of their on-premises applications and AWS cloud services and tools.

  • Bring AWS services and infrastructure to virtually any customer site that runs time- and latency-sensitive plant floor applications
  • Improve IT efficiency and reduce operational risk with fully managed infrastructure
  • Modernize legacy applications and run them on-premises to meet low latency requirements
  • Use AWS tools to manage databases with services like RDS on Outposts
  • Innovate by seamlessly integrating on-premises data from AWS Outposts to AWS cloud AI, ML and analytics services
  • Provide a consistent AWS experience across cloud and on-premises
AWS Outposts

AWS Outposts Benefits

With AWS Outposts users can run Amazon EC2, Amazon EBS, Amazon S3, container-based services such as Amazon EKS, database services such as Amazon RDS on AWS Outposts and analytics services such as Amazon EMR on premises. Users can seamlessly extend the Amazon Virtual Private Cloud on premises and run some AWS services locally on Outposts and connect to a broad range of services available in the local AWS Region. Users can use the same AWS APIs, tools, and security controls to run, manage, and secure the applications on premises just as in the cloud.

AWS Outposts delivers a truly consistent hybrid experience by offering the same hardware infrastructure, services, APIs, management, and operations on premises as in the cloud. Unlike other hybrid solutions that require use of different APIs, manual software updates, and purchase of third-party hardware and support, Outposts provide a truly consistent developer and IT operations experience across on premises and cloud environments.

 

AWS Outposts is fully managed and supported by AWS. Users Outpost is delivered, installed, monitored, patched, and updated by AWS. With Outposts users can reduce the time, resources, operational risk, and maintenance downtime required for managing IT infrastructure. AWS Outposts allow users to choose from a wide selection of compute, memory, and storage options based on the needs. Outposts can be easily upgraded with the latest hardware and next-generation instances to run all of users native AWS and VMware applications.

Extended AWS On-premesis AWS Outposts enable users to develop one and deploy in the AWS cloud or on-premesis without having to rewrite your applications. With Outposts, you have the same hardware and software infrastructure and a consistent set of services and tools across the AWS cloud and on-premises environments to build and run modern, cloud-native applications anywhere, using industry proven and validated Intel Xeon Scalable processors. AWS Outposts allows users to securely store and process customer data that needs to remain on premises or in countries where there is no AWS region. 

AWS Outposts Features

Users can choose from a range of pre-validated AWS Outposts configurations offering a mix of EC2, EBS, and S3 capacity designed to meet a variety of application and data residency needs. Users can also contact AWS to create a customized configuration designed for your unique application needs.

Compute: AWS Outposts catalog includes options supporting the latest generation Intel powered EC2 instance types with or without local instance storage.

  • General purpose (M5/M5d) instances provide a balance of compute, memory, and network resources and can be used for general-purpose workloads, web and application servers, backend servers for enterprise applications, gaming servers, and caching fleets.
  • Compute optimized (C5/C5d) instances are optimized for compute-intensive workloads and deliver cost-effective high performance at a low price per compute ratio. They are suited for compute intensive applications such as batch processing, media transcoding, high performance web servers, high performance computing (HPC), scientific modeling, dedicated gaming servers and ad server engines, machine learning inference.
  • Memory optimized (R5/R5d) instances are designed to deliver fast performance for workloads that process large data sets in memory. They are well suited for memory intensive applications such as high-performance databases, distributed web scale in-memory caches, mid-size in-memory databases, real- time big data analytics.
  • Graphics optimized (G4dn) are designed to help accelerate machine learning inference and graphics-intensive workloads. They can be used for machine learning inference for applications like adding metadata to an image, object detection, recommender systems, automated speech recognition, and language translation. They also provide a very cost-effective platform for building and running graphics-intensive applications, such as remote graphics workstations, video transcoding, photo-realistic design, and game streaming in the cloud.
  • I/O optimized (I3en) provides dense Non-Volatile Memory Express (NVMe) SSD instance storage optimized for low latency, high random I/O performance, high sequential disk throughput, and offers the lowest price per GB of SSD instance storage on Amazon EC2. It is well suited for NoSQL databases (Cassandra, MongoDB, Redis), in-memory databases (SAP HANA, Aerospike), scale-out transactional databases, distributed file systems, data warehousing, Elasticsearch, analytics workloads.

Support for EC2 instances powered by Graviton processors such as C6g, M6g, and R6g is coming in 2021.

Storage: Amazon EBS: AWS Outposts offers local instance storage, and Elastic Block Store (EBS) gp2 volumes for persistent block storage. Just as in the AWS Region, users can use EBS gp2 volumes for boot or data volumes, and attach or detach EBS volumes to EC2 instances on users Outpost. It provides snapshot and restore capabilities and lets users increase volume size without any performance impact. All EBS volumes and snapshots on Outposts are fully encrypted by default. Any EBS snapshots will be stored using Amazon S3 in the Region associated with users AWS Outpost. EBS is offered in tiers of 2.7 TB, 11 TB, 33 TB, and 55 TB*.

  • Amazon S3: Amazon S3 on Outposts delivers object storage to the on-premises AWS Outposts environment. Using the S3 APIs and features available in AWS Regions today, S3 on AWS  Outposts makes it easy to store and retrieve data on users Outpost, as well as secure the data, control access, tag, and report on it.
  • Using S3 on Outposts, users can store data on the Outpost to meet local data residency requirements, or satisfy demanding performance by keeping data close to on-premises applications. S3 on Outposts provides a new Amazon S3 storage class, named ‘S3 Outposts’, which uses the S3 APIs, and is designed to durably and redundantly store data across multiple devices and servers on users Outposts.
  • To get started using S3 on AWS  Outposts, visit the AWS Outposts Management Console to order an Outposts configuration that includes S3 storage or to add S3 storage to an existing Outposts users can work with your account team.

Containers: Amazon ECS: Run highly scalable, high-performance container orchestration service that supports Docker containers and allows users to easily run and scale containerized applications on Outposts. With ECS on Outposts users can run containerized applications that require low latencies to on premises systems. Amazon ECS running on Outposts eliminates the need to install and operate users own container orchestration software, manage and scale a cluster of virtual machines, or schedule containers on those virtual machines in users on premises environments.

  • With simple API calls, users can launch and stop Docker-enabled applications and query the complete state of the application with the same ease as managing containers as in the cloud today.

Amazon EKS: Amazon EKS is a managed service that makes it easy to run Kubernetes on AWS without needing to install and operate users own Kubernetes control plane. Users can use EKS on Outposts to run containerized applications that require particularly low latencies to on premises systems.

  • With EKS on AWS Outposts, users can manage containers on premises with the same ease as managing containers in the cloud.

Databases: Amazon RDS on AWS Outposts: Amazon RDS on AWS Outposts supports MySQL and PostgreSQL database engines, with support for additional database engines coming soon. Amazon RDS makes it easy to set up, operate, and scale a relational database in the cloud. Amazon RDS provides cost-efficient and resizable capacity while automating time-consuming administration tasks including infrastructure provisioning, database setup, patching, and backups.

  • Users can run fully managed databases on premises for low latency workloads that need to be run in close proximity to on premises data and applications. Users can manage RDS databases both in the cloud and on premises using the same AWS Management Console, APIs, and CLI. 

Amazon ElastiCache on AWS Outposts: Amazon ElastiCache is a fully managed in-memory data store, compatible with Redis or Memcached, optimized for real-time applications with sub-millisecond latency. Amazon ElastiCache on AWS Outposts allows users to seamlessly set up, run, and scale popular open-Source compatible in-memory data stores on AWS Outposts capacities, as in the cloud. Users can build data-intensive apps or boost the performance of the existing databases by retrieving data from high throughput and low latency in-memory data stores.

  • Amazon ElastiCache on AWS Outposts enables real-time use cases like Caching, Session Stores, Gaming, Geospatial Services, Real-Time Analytics, and Queuing, when deployed for local-data processing and low-latency applications.

Data analytics: Amazon EMR: Amazon EMR clusters running on AWS Outposts in the data center, co-location space, or on premises facility provide a truly consistent and seamless hybrid cloud analytics experience. Users can deploy secure and managed EMR clusters in the data center in minutes. This gives business users the latest versions of Apache Spark, Apache Hive, and Presto to access critical on premises data sources and systems for big data analytics. When launching an EMR cluster into an AWS Outpost, users can use the EMR console, SDK, or CLI to specify the subnet associated with users AWS Outpost. Users EMR clusters run in the on premises Outpost instance and appear in the EMR console like any other cluster.

Upgrading services running on Outposts: As new versions of AWS services become available in the cloud, AWS services running locally on Outposts will be upgraded automatically to the latest version just as in the cloud today. Services such as Amazon RDS on AWS Outposts patch both OS and database engines within scheduled maintenance windows with minimum downtime.

Access regional services: AWS Outposts is an extension of the AWS Region. Users can seamlessly extend the Amazon Virtual Private Cloud on premises and connect to a broad range of services available in the AWS Region. Users can access all regional AWS services in the private VPC environment, for example, through Interface Endpoints, Gateway Endpoints, or their regional public endpoints.

VPC extension: Users can seamlessly extend your existing Amazon VPC to the Outpost in the on premises location. After installation, users can create a subnet in the regional VPC and associate it with an AWS Outpost just as they associate subnets with an Availability Zone in an AWS Region. Instances in Outpost subnets communicate with other instances in the AWS Region using private IP addresses, all within the same VPC.

Local gateway: Each Outpost provides a new local gateway (LGW) that allows users to connect your Outpost resources with users on premises networks. LGW enables low latency connectivity between the AWS Outpost and any local data sources, end users, local machinery and equipment, or local databases.

Load Balancer: Users can provision an Application Load Balancer (ALB) to automatically distribute incoming HTTP(S) traffic across multiple targets on the AWS Outposts, such as Amazon EC2 instances, containers, and IP addresses. ALB on AWS Outposts is fully managed, operates in a single subnet, and scales automatically up to the capacity available on the Outposts rack to meet varying levels of application load without manual intervention.

Private Connectivity: With AWS Outposts Private Connectivity, users can establish a service link VPN connection from your Outposts to the AWS Region over AWS Direct Connect. Private Connectivity minimizes public internet exposure and removes the need for special firewall configurations.

High availability: AWS Outposts are designed for high availability with redundant top of rack networking switches, power elements, and built-in, always active, additional capacity to enable reliable auto recovery workflows the same way as in AWS Regions. 

AWS tools: Users can access AWS tools running in the region such as AWS CloudFormation, Amazon CloudWatch, AWS CloudTrail, Elastic BeanStalk, Cloud 9, and others to run and manage applications on Outposts the same way as in the cloud.

Enhanced security with AWS Nitro: AWS Outposts builds on the AWS Nitro system technologies that enables AWS to provide enhanced security that continuously monitors, protects, and verifies users Outpost’s instance hardware and firmware. With AWS Nitro, virtualization resources are offloaded to dedicated hardware and software minimizing the attack surface. Finally, Nitro System’s security model is locked down and prohibits administrative access, eliminating the possibility of human error and tampering.

Security model: AWS Outposts have an updated shared responsibility model underlying security. AWS is responsible for protecting AWS Outposts’ infrastructure similar to how it secures infrastructure in the cloud today. Customers are responsible for securing their applications running on AWS Outposts as they do in the Region today. With AWS Outposts, customers are also responsible for the physical security of their AWS Outpost racks, and for ensuring consistent networking to the Outpost.

Securing data: Users can manage AWS Outposts manually to complete tasks such as adding tags and updating names and descriptions.

  • Data-at-rest: Data is encrypted at rest by default on EBS volumes, and S3 objects on Outposts.
  • Data-in-transit: Data is encrypted in transit between AWS Outposts and the AWS Region,through the Service Link.
  • Deleting data: All data is deleted when instances are terminated in the same way as in the AWS Region.
 

AWS Outposts Concepts

An AWS Outpost is a pool of AWS compute and storage capacity deployed at a customer site. AWS operates, monitors, and manages this capacity as part of an AWS Region. Users can create subnets on the Outpost and specify them when users create AWS resources such as EC2 instances, EBS volumes, ECS clusters, and RDS instances. Instances in Outpost subnets communicate with other instances in the AWS Region using private IP addresses, all within the same VPC.

  • AWS Outpost site: The customer-managed physical buildings where AWS will install the Outpost. A site must meet the facility, networking, and power requirements for users Outpost.

  • AWS Outpost configurations: Mixes of Amazon EC2 compute capacity, Amazon EBS storage capacity, and networking support. Each configuration has unique power, cooling, and weight support requirements.

  • AWS Outpost capacity: Compute and storage resources available on the Outpost. Users can view and manage the capacity for their Outpost from the AWS Outposts console.

  • AWS Outpost equipment: Physical hardware that provides access to the AWS Outposts service, including racks, servers, switches, and cabling owned and managed by AWS.

  • Service link: Network route that enables communication between users Outpost and its associated AWS Region. Each AWS Outpost is an extension of an Availability Zone and its associated Region.

  • Local gateway: A logical interconnect virtual router that enables communication between users AWS Outpost and their on-premises network.

AWS Outposts Rack

AWS Outposts are delivered as an industry-standard 42U rack. The Outpost rack is 80 inches (203.2cm) tall, 24 inches (60.96cm) wide, and 48 inches (121.92cm) deep. Inside AWS have hosts, switches, a network patch panel, a power shelf, and blank panels. Outposts are designed for high availability with redundant network switches and power connections. Customers can also provision their Outposts with additional capacity for additional resiliency.

  • Industry-standard 42U rack with Amazon EC2 compute and storage capacity
  • The same hardware and infrastructure platform, AWS Nitro System, that powers AWS environments; a VMware variant is also available
  • Supports a range of EC2 instance types: general purpose, compute optimized, memory optimized, graphics optimized, and I/O optimized. Outposts’ M, C, R, and I type instances are powered by Intel® Xeon® Scalable Processors 
  • Redundant active components including top of rack switches and hosts 
  • Centralized redundant power conversion unit and DC distribution system for energy efficiency, easy serviceability and higher reliability
  • AWS-optimized rack design for efficiency and performance 
  • Multiple racks can be configured as a single capacity pool 
  • Requires redundant network connection to an AWS Region through AWS Direct Connect with public VIF or Internet connection via ISP 
  • Applications are statically stable and workloads continue to be accessible over the local gateway/ local network. If network disconnect does occur, applications can continue to run on EC2 instances and access EBS volumes – they will still send and receive traffic from the local network
  • Requires standard server space (24”x48”x80” aisle clearance and aisle position), power (minimum 5kVA) and room cooling 
  • Deploy two Outposts racks to ensure redundancy and high availability

The “Manufacturing Applications on AWS Outposts and AWS Cloud” reference architecture illustrates a “hybrid cloud” framework. Level 0-1 (physical hardware devices and controllers) and level 2 (applications such as SCADA and Human Machine Interfaces) are sensitive to latency and must remain on-premises, together with the Manufacturing Operations Management Layer (Level 2-3) running on AWS Outposts.

Operations Technology
  • Machine layer (Levels 0-2): Includes device/sensor/plant-level process controls such as automation systems, supervisory control and data acquisition (SCADA), distributed control systems (DCS), programmable logic controllers (PLCs) and human machine interfaces (HMIs.) These are tightly integrated to end devices, and need low latency responses.
  • Manufacturing Operations Management layer (Levels 2-3): Comprises systems such as manufacturing execution systems (MES) and historian which capture and process data from the machine layer, connecting plant-level process controls with ERP. These applications can run in VMs or containers on an Outpost, and remain on-premises but be managed with the same AWS tools.
Information Technology
  • Planning layer (Levels 4-5): Includes top-level applications like enterprise resource planning (ERP), supply chain management (SCM), and customer relationship management (CRM). For most manufacturing organizations, these applications are not latency-sensitive, and can be run efficiently in the AWS cloud. IT teams in manufacturing organizations also want to modernize back-end IT workloads such as ERP, SCM and CRM, and migrate them to the cloud to leverage benefits such as reducing complexity, maintenance costs, and operating expenses.
Cloud Innovation On Premises

With AWS Outposts, applications can run locally on Amazon Elastic Compute (EC2) instances, which provide secure and resizable compute capacity on Amazon’s proven computing environment. Applications can also utilize a broad range of services running locally on AWS Outposts such as: 

  • Amazon Elastic Block Store (EBS): GP2 storage – easy to use, high performance block storage that meets the needs of most applications
  • Amazon Virtual Private Cloud (VPC): networking – which seamlessly integrates workloads running on AWS Outposts and in the Region
  • Amazon Relational Database Service (RDS):  for setting up, operating, and scaling relational databases such as PostgreSQL and MySQL
  • Amazon Elastic Container Service (ECS): a secure, reliable, and scalable container orchestration service
  • Amazon Elastic Kubernetes Service (EKS): a fully managed Kubernetes service
  • Amazon Elastic Map Reduce (EMR): a cloud-native big data platform for frameworks including Apache Spark, Hadoop, HBase, Presto, and Hive

They can also seamlessly access all the services in the Region and use standardized AWS tools and security controls to run, manage, and secure applications on premises and in the cloud. As AWS adds new services, they can leverage these capabilities locally or in region to rapidly innovate on premises just as they do in the cloud today.

AWS Outposts Cloud Innovation On Premises
AWS Outposts Cloud Innovation On Premises

AWS Outposts works

AWS Outposts

AWS Outposts is designed to operate with a constant and consistent connection between users AWS Outpost and an AWS Region. To achieve this connection to the Region, and to the local workloads on the on-premises environment, users must connect the AWS Outpost to their on-premises network. Users on-premises network must provide wide area network (WAN) access back to the Region and to the internet. It must also provide LAN or WAN access to the local network where your on-premises workloads or applications reside. An AWS Outposts extends an Amazon VPC from an AWS Region to an Outpost with the VPC components that are accessible in the Region, including internet gateways, virtual private gateways, Amazon VPC Transit Gateways, and VPC endpoints. An AWS Outpost is homed to an Availability Zone in the Region and is an extension of that Availability Zone that users can use for resiliency. The following are the network components for the Outpost. 

 

#01

Network components

 
 
VPCs and subnets

A virtual private cloud (VPC) spans all Availability Zones in its AWS Region. Users can extend any VPC in the Region to the Outpost by adding an Outpost subnet. To add an Outpost subnet to a VPC, specify the Amazon Resource Name (ARN) of the Outpost when users create the subnet.

  • AWS Outposts support multiple subnets. Users can specify the EC2 instance subnet when users launch the EC2 instance in the Outpost. Users cannot restrict the hardware server where the instance is deployed, because the Outpost is a pool of AWS compute and storage capacity.
  • Each AWS Outpost can support multiple VPCs that can have one or more Outpost subnets. 

Users create AWS Outpost subnets from the VPC CIDR range of the VPC where they created the Outpost. Users can use the Outpost address ranges for resources, such as EC2 instances that reside in the Outpost subnet. AWS does not directly advertise the VPC CIDR, or the Outpost subnet range to your on-premises location.

Local Gateway

A local gateway serves two purposes. It provides a target in the VPC route tables for on-premises destined traffic, and performs network address translation (NAT) for instances that have been assigned addresses from end users owned IP pool. Users can also use the local gateway for communication for internet-bound traffic. Each Outpost supports a single local gateway. Users can associate multiple VPCs with the local gateway. 

  • Users can attach the local gateway to a VPC to connect to users on-premises network. The local gateway provides connectivity between local network, or local gateway VLAN, and the VPC. The local gateway performs NAT of the Outpost instances’ IP addresses to Elastic IP addresses from a pool that is assigned to the local gateway. The local gateway NAT function is similar to how an internet gateway functions in an AWS Region.
  • The local gateway for the AWS Outpost enables connectivity from the Outpost subnets to all AWS services that are available in the parent Region, in the same way that users access them from an Availability Zone subnet. For example, users can access the Regional service endpoints over the public internet, or use interface VPC endpoints (AWS PrivateLink) to access them without going over the public internet. 
Customer-owned IP addresses

During the installation process, AWS uses information that users provide about the on-premises network to create an address pool, known as a customer-owned IP address pool (CoIP pool). AWS then assigns it to the local gateway for use and advertisement back to end users  network through BGP. Customer-owned IP addresses provide local or external connectivity to resources in the AWS Outpost subnets through users on-premises network. Users can assign these IP addresses to resources on the Outpost, such as EC2 instances, by allocating a new Elastic IP from the customer-owned IP pool, and then assigning this new Elastic IP to your EC2 instance. The following requirements apply to the customer-owned IP address pool:

  • Users need to be able to route the address in the network
  • The CIDR block must be a minimum of /26
 

When users allocate an Elastic IP address from end user owned IP address pool, they continue to own the IP addresses in the end users -owned IP address pool. Users are responsible for advertising them as needed on the internal networks or WAN.

  • Users can optionally share the end users owned pool with multiple AWS accounts in the AWS Organizations using the AWS Resource Access Manager. After sharing the pool, participants can allocate and associate Elastic IPs from the customer owned IP pool. 
Routing

By default, every Outpost subnet inherits the main route table from its VPC. Users can create a custom route table and associate it with an Outpost subnet. Users can include a local gateway as target when the destination is the on-premises network. A local gateway can only be used in VPC and subnet route tables that are associated with an Outpost. The route tables for Outpost subnets work as they do for Availability Zone subnets. Users can specify IP addresses, internet gateways, local gateways, virtual private gateways, and peering connections as destinations.

  • For example, each Outpost subnet, either through the inherited main route table, or a custom table, inherits the VPC local route. This means that all traffic in the VPC, including the Outpost subnet with a destination in the VPC CIDR remains routed in the VPC.

Users cannot configure a more specific range than the VPC CIDR local route on the Outpost for Outpost subnets. Outpost subnet route tables can include the following destinations:

  • VPC CIDR range: AWS defines this at installation. This is the local route and applies to all VPC routing, including traffic between Outpost instances in the same VPC.
  • Customer on-premises network: The local gateway routes this traffic for low latency routing to the on-premises network.
  • AWS Region destinations: This includes prefix lists for Amazon Simple Storage Service (Amazon S3), Amazon DynamoDB gateway endpoint, AWS Transit Gateways, virtual private gateways, internet gateways, and VPC peering.
DNS

By default, EC2 instances in Outposts subnets can use the Amazon Route 53 DNS Service to resolve domain names to IP addresses. Route 53 supports DNS features, such as domain registration, DNS routing, and health checks for instances running in your Outpost. Both public and private hosted Availability Zones are supported for routing traffic to specific domains. Route 53 resolvers are hosted in the AWS Region. Therefore, service link connectivity from the Outpost back to the AWS Region must be up and running for these DNS features to work.

  • Users might encounter longer DNS resolution times with Route 53, depending on the path latency between your Outpost and the AWS Region. In such cases, Users can use the DNS servers installed locally in your on-premises environment.
  • To use own DNS servers, users must create DHCP option sets for the servers and associate them with the VPC.  Users need to ensure that there is IP connectivity to these DNS servers.
  • Users might also need to add routes to the local gateway routing table for reachability. Because DHCP option sets have a VPC scope, instances in both the Outpost subnets and the Availability Zone subnets for the VPC will try to use the specified DNS servers for DNS name resolution.
Physical connectivity

An Outpost rack has two physical network devices that attach to users local network. An Outpost requires a minimum of two physical links between these Outpost network devices and users local network devices. An Outpost supports the following uplink speeds and quantities for each Outpost network device.

  • The uplink speed and quantity are symmetrical on each Outpost network device. If you use 100 Gbps as the uplink speed, users needs to configure the link with forward error correction (FEC CL91).
  • Outpost racks can support single-mode fiber (SMF) with Lucent Connector (LC), multimode fiber (MMF), or MMF OM4 with LC. AWS provides the optics that are compatible with the fiber that users provide at the rack position.

AWS Outposts uses the Link Aggregation Control Protocol (LACP) to establish two link aggregation group (LAG) connections to users Outpost network devices and to the  local network devices. The links from each Outpost network device are aggregated into an Ethernet LAG to represent a single network connection. These LAGs use LACP with standard fast timers.

  • To enable an Outpost installation at the site, users need to configure their side of the LAG connections on the network devices.
  • From a logical perspective, ignore the Outpost patch panels as the demarcation point and use the Outpost networking devices.
  • For deployments that have multiple racks, an Outpost must have four physical links between the aggregation layer of the Outpost network devices and users local network devices.

There are four physical connections between each Outpost network device and its connected local network device. AWS use Ethernet LAGs to aggregate the physical links connecting the Outpost network devices and the customer local network devices.

Virtual LANs

Each LAG between an Outpost network device and a local network device must be configured as an IEEE 802.1q Ethernet trunk. This enables the use of multiple VLANs for network segregation between data paths. Each Outpost has the following data paths between the on-premises network and its network:

  • Service link VLAN: Enables communication between the Outpost and the AWS Region for both management of the Outpost and intra-VPC between the AWS Region and Outpost. This VLAN provides access to the AWS Region, which enables the service link connection from the Outpost to be established back to the Region. The service link is a custom VPN or VPNs from the Outpost to the Region. It is connected to the Outpost that is configured in the Availability Zone when users purchase the Outpost.
  • Local gateway VLAN: Enables VPC traffic from your VPC to users local LAN. This VLAN enables instances running on the Outpost to communicate with users on-premises network. It also enables them to communicate with the internet through users on-premises network.
 

Users can configure the service link VLAN and local gateway VLAN only between the Outpost and your customer local network devices. An AWS Outpost is designed to separate the service link and local gateway data paths into two isolated networks. This enables users to choose which of users networks can communicate with services running on the Outpost. It also enables users to make the service link an isolated network from the local gateway network by using multiple route table on end users local network device, commonly known as Virtual Routing and Forwarding instances (VRF).

  • The demarcation line exists at the port of the Outpost network devices. AWS manages any infrastructure on the AWS side of the connection, and users manage any infrastructure on their side of the line.
Network layer connectivity

Each Outpost network device requires an IP address on each VLAN so they can communicate with the users local network devices to establish a BGP session. AWS recommend that customers use a dedicated subnet, with a /30 or /31 CIDR, to represent this logical point-to-point connectivity. AWS recommend that users do not bridge the VLANs between end users local network devices. Users need to establish two paths:

  • Service link path: To establish this path, specify a VLAN subnet with a range of /30 or /31 and an IP address for the service link VLAN on the Outpost network device.
  • Local gateway path: To establish this path, specify a VLAN subnet with a range of /30 or /31 and an IP address for the local gateway VLAN on the Outpost network device.
 

The connections from each Outpost network device to the customer device for the service link path and the local gateway path. There are four VLANs for this example:

  • VLAN A is for the service link path that connects the Outpost network device 1 with the customer local network device 1.
  • VLAN B is for the local gateway path that connects the Outpost network device 1 with the customer local network device 1.
  • VLAN C is for the service link path that connects the Outpost network device 2 with the customer local network device 2. 
  • VLAN D is for the local gateway path that connects the Outpost network device 2 with the customer local network device 2.

The Outpost establishes an external BGP peering session between each Outpost network device and the users local network device for service link connectivity over the service link VLAN. The BGP peering session is established between the /30 or /31 IP addresses provided for the point-to-point VLAN. Each BGP peering session uses a private Autonomous System Number (ASN) on the Outpost network device and an ASN that users choose for their customer local network devices. AWS provides the attributes as part of the installation process.

Consider the scenario where user have an Outpost with two Outpost network devices connected by a service link VLAN to two customer local network devices. Users configure the following infrastructure, and customer local network device BGP ASN attributes for each service link:

  • The service link BGP ASN. 2-byte (16-bit) or 4-byte (32-bit). The valid values are 64512-65535 or 4200000000-4294967294.
  • The infrastructure CIDR. This must be a /26 CIDR.
  • The users local network device 1 service link BGP peer IP address.
  • The users local network device 1 service link BGP peer ASN. The valid values are 1-4294967294.
  • The users local network device 2 service link BGP peer IP address. 
  • The users local network device 2 service link BGP peer ASN. The valid values are 1-4294967294. 

The service link infrastructure subnet is a /26 CIDR range that users provide during the pre-installation process. The service link range is used by the Outpost infrastructure to establish connectivity to the Region through the service link. The service link subnet is the Outpost source, which initiates the connectivity.

  • Outpost network devices advertise the /26 CIDR range as two /27 CIDR blocks to support link and device failures.
  • Users need to provide a service link BGP ASN and an infrastructure subnet CIDR (/26) for the Outpost. For each Outpost network device, provide the BGP peering IP address on the VLAN of the local network device and the BGP ASN of the local network device.
  • If users have a multiple rack deployment, they must have one /26 subnet per rack.
Local gateway BGP connectivity

The Outpost establishes an external BGP peering from each Outpost network device to a local network device for connectivity to the local gateway. It uses a private Autonomous System Number (ASN) that users assign in order to establish the external BGP sessions. Each Outpost network device has a single external BGP peering to a local network device using its local gateway VLAN.

The Outpost establishes an external BGP peering session over the local gateway VLAN between each Outpost network device and its connected customer local network device. The peering session is established between the /30 or /31 IPs that users provided when setting up network connectivity and uses point-to-point connectivity between the Outpost network devices and users local network devices. Each BGP session uses the private ASN on the Outpost network device side, and an ASN that you choose on the users local network device side. AWS provides the attributes as part of the pre-installation process.

Consider the scenario where the user have an Outpost with two Outpost network devices connected by a service link VLAN to two customer local network devices. Users configure the following local gateway and customer local network device BGP ASN attributes for each service link:

  • AWS provides the local gateway BGP ASN. 2-byte (16-bit) or 4-byte (32-bit). The valid values are 64512-65535 or 4200000000-4294967294.
  • Users provide the customer owned CIDR that gets advertised (public or private, /26 minimum).
  • Users provide the customer local network device 1 local gateway BGP peer IP address.
  • Users provide the customer local network device 1 local gateway BGP peer ASN. The valid values are 1-4294967294. For more information, see RFC4893.
  • Users provide the customer local network device 2 local gateway BGP peer IP address.
  • Users provide the customer local network device 2 local gateway BGP peer ASN. The valid values are 1-4294967294. For more information, see RFC4893.
Local gateway customer-owned IP subnet advertisement

During the pre-installation process, AWS creates an address pool, known as a customer-owned IP address pool. It is created based on information that users provide about the on-premises network. Users can create Elastic IP addresses from this pool, and then assign the addresses to resources on users Outpost, such as EC2 instances.

The local gateway translates the Elastic IP address to an address in the customer-owned pool. The local gateway advertises the translated address to users on-premises network, and any other network that communicates with the Outpost. The addresses are advertised on both local gateway BGP sessions to the local network devices.

Consider the scenario where the user has an Outpost with two Outpost network devices connected by a service link VLAN to two customer local network devices. The following is configured:

  • A VPC with a CIDR block 10.0.0.0/16.
  • A subnet in the VPC with a CIDR block 10.0.3.0/24.
  • An EC2 instance in the subnet with a private IP address 10.0.3.112.
  • A customer-owned IP pool (10.1.0.0/26).
  • An Elastic IP address association that associates 10.0.3.112 to 10.1.0.2.
  • A local gateway that uses BGP to advertise 10.1.0.0/26 to the on-premises network through the local devices.
  • Communication between users Outpost and on-premises network will use the COIP Elastic IPs to address instances in the Outpost, the VPC CIDR range is not used.

#02

Outpost connectivity

 
 

 

#03

Region connectivity

 
 

During AWS Outposts provisioning, a service link connection is created that connects the Outpost back to users chosen AWS Region or Outposts home Region. The service link is an encrypted set of VPN connections that are used whenever the Outpost communicates with users chosen home Region.

  • When selecting the private connectivity option for the Outpost, the service link VPN connection is established using an existing VPC and subnet that users specify. 

Alternatively, the Outpost is able to create the service link VPN back to the AWS Region through public Region connectivity. To do so, the Outpost needs connectivity to the AWS Region’s public IP ranges, either through the public internet or AWS Direct Connect public virtual interface. This connectivity can be through specific routes in the service link VLAN, or through a default route of 0.0.0.0/0.  After the service link is established, the Outpost is in service and managed by AWS. The service link is used for the following traffic:

  • Management traffic to the Outpost through the service link
  • Traffic between the Outpost and any associated VPCs
 

Outpost service links support an MTU of 1300 bytes. Users can use AWS Direct Connect, or an internet connection to connect to the AWS Region. For an optimal experience and resiliency, AWS recommends to use dual 1Gbps connections to the AWS Region. In the diagram below, the configuration extends the Amazon VPC from the AWS Region to the Outpost. An AWS Direct Connect public virtual interface is the service link connection. The following traffic goes over the service link and the AWS Direct Connect connection:

  • Control plane
  • Intra-VPC traffic between the Outpost and the AWS Region
Service link private connectivity using VPC

Users can select the private connectivity option in the console when creating their Outpost. Doing so, a service link VPN connection is established after the Outpost is installed using a VPC and subnet that the user specify. Which allows private connectivity by way of the VPC and minimizes public internet exposure.

When undoing the private connectivity for the Outpost needed, users need to contact AWS Enterprise Support.

Connectivity through the local gateway

The primary role of a local gateway is to provide connectivity from an Outpost to users local on-premises LAN. It also provides connectivity to the internet through the on-premises network. The local gateway can also provide a data plane path back to the AWS Region. If users already have connectivity between the LAN and the Region through AWS Site-to-Site VPN or AWS Direct Connect, they can use the same path to connect from the Outpost to the AWS Region privately.

  • The data plane path for the local gateway traverses from the Outpost, through the local gateway, and to users private local gateway LAN segment. It would then follow a private path back to the AWS service endpoints in the Region.
Redundant internet connections

When building connectivity from the AWS Outpost to the AWS Region, AWS recommend that users create multiple connections for higher availability and resiliency. 

  • If connectivity needed to the public internet, users can use redundant internet connections and diverse internet providers, just as existing on-premises workloads.
AWS Outposts private connectivity configuration that uses an AWS Direct Connect connection, virtual interface, and virtual private gateway
AWS Outposts private connectivity configuration that uses an AWS Direct Connect connection, virtual interface, and virtual private gateway

With Outpost sharing, Outpost owners can share their Outposts and Outpost resources, including local gateway route tables, with other AWS accounts under the same AWS organization. As an Outpost owner, users can create and manage Outpost resources centrally, and share the resources across multiple AWS accounts within the AWS organization. This allows other consumers to configure VPCs, launch and run instances, and create EBS volumes on the shared Outpost. In this model, the AWS account that owns the Outpost resources (owner) shares the resources with other AWS accounts (consumers) in the same organization. Consumers can create resources on Outposts that are shared with them in the same way that they would create resources on Outposts that they create in their own account.

The owner is responsible for managing the Outpost and resources that they create in it. Owners can change or revoke shared access at any time. They can also view, modify, and delete resources that users create on shared Outposts. Users are responsible for managing the resources that they create on Outposts that are shared with them. Users can’t view or modify resources owned by other users or by the Outpost owner. They also can’t modify Outposts that are shared with them.

Shareable Outpost resources

An Outpost owner can share the following Outpost resources with consumers.

Outposts: Consumers with access to this resource can:

  • Create and manage subnets on the Outpost.
  • Create and manage EBS volumes on the Outpost.
  • Use the AWS Outposts API to view information about the Outpost.

Local gateway route tables: Users with access to this resource can:

  • Create and manage VPC associations to a local gateway.
  • View configurations of local gateway route tables and virtual interfaces.
 

Subnets: Consumers with access to this resource can:

  • View information about subnets.

  • Launch and run EC2 instances in subnets.
Prerequisites for sharing Outposts resources
  • To share an Outpost resource within organization or an organizational unit in AWS Organizations, users need to enable sharing with AWS Organizations. 
  • To share an Outpost resource, users need to own it in your AWS account. Users cannot share an Outpost resource that has been shared with users.
  • To share an Outpost resource, users must share it with an account that is within their organization.

Outpost resource sharing integrates with AWS Resource Access Manager (AWS RAM). AWS RAM is a service that enables users to share their AWS resources with any AWS account or through AWS Organizations. With AWS RAM, users share resources they own by creating a resource share. A resource share specifies the resources to share, and the consumers with whom to share them. Users can be individual AWS accounts, organizational units, or an entire organization in AWS Organizations.

Sharing across Availability Zones

To ensure that resources are distributed across the Availability Zones for a Region, we independently map Availability Zones to names for each account. This could lead to Availability Zone naming differences across accounts. For example, the Availability Zone us-east-1a for users AWS account might not have the same location as us-east-1a for another AWS account.

To identify the location of the Outpost resource relative to the accounts, users must use the Availability Zone ID (AZ ID). The AZ ID is a unique and consistent identifier for an Availability Zone across all AWS accounts. For example, use1-az1 is an AZ ID for the us-east-1 Region and it is the same location in every AWS account.

  • Local gateway route tables are in the same AZ as their Outpost, so you do not need to specify an AZ ID for route tables.
Sharing an Outpost resource

When an owner shares an Outpost with a consumer, the consumer can create resources on the Outpost in the same way that they would create resources on Outposts that they create in their own account. Consumers with access to shared local gateway route tables can create and manage VPC associations. 

  • To share an Outpost resource, users must add it to a resource share. A resource share is an AWS RAM resource that enables users share their resources across AWS accounts. A resource share specifies the resources to share, and the consumers with whom they are shared. When sharing an Outpost resource using the AWS Outposts console, users add it to an existing resource share. To add the Outpost resource to a new resource share, users must first create the resource share using the AWS RAM console.
  • Users can share an Outpost resource they own using the AWS Outposts console, AWS RAM console, or the AWS CLI.
  • To share an Outpost or local gateway route table that you own using the AWS RAM console, see Creating a Resource Share in the AWS RAM User Guide.
  • To share an Outpost or local gateway route table that you own using the AWS CLI, Use the create-resource-share command.
Unsharing a shared Outpost resource

When a shared Outpost is unshared, consumers can no longer view the Outpost in the AWS Outposts console. They cannot create new subnets on the Outpost, create new EBS volumes on the Outpost, or view the Outpost details and instance types using the AWS Outposts console or the AWS CLI. Existing subnets, volumes, or instances created by consumers are not deleted. Any existing subnets consumers created on the Outpost can still be used to launch new instances.

  • When a shared local gateway route table is unshared, consumers can no longer create new VPC associations to it. Any existing VPC associations consumers created remain associated with the route table. Resources in these VPCs can continue to route traffic to the local gateway.
  • To unshare a shared Outpost resource that users own, they must remove it from the resource share. Users can do this using the AWS RAM console or the AWS CLI.
  • To unshare a shared Outpost resource that you own using the AWS RAM console, See Updating a Resource Share in the AWS RAM User Guide.
  • To unshare a shared Outpost resource that users own using the AWS CLI, Use the disassociate-resource-share command.
 
Shared Outpost resource permissions

Permissions for owners: Owners are responsible for managing the Outpost and resources that they create in it. Owners can change or revoke shared access at any time. They can use AWS Organizations to view, modify, and delete resources that consumers create on shared Outposts.

Permissions for consumers: Consumers can create resources on Outposts that are shared with them in the same way that they would create resources on Outposts that they create in their own account. Consumers are responsible for managing the resources that they launch onto Outposts that are shared with them. Consumers can’t view or modify resources owned by other consumers or by the Outpost owner, and they can’t modify Outposts that are shared with them.

Billing and metering

Owners are billed for Outposts and Outpost resources that they share. They are also billed for any data transfer charges associated with their Outpost’s service link VPN traffic from the AWS Region. There are no additional charges for sharing local gateway route tables. For shared subnets, the VPC owner is billed for VPC-level resources such as AWS Direct Connect and VPN connections, NAT gateways, and Private Link connections.

  • Consumers are billed for application resources that they create on shared Outposts, such as load balancers and Amazon RDS databases. Consumers are also billed for chargeable data transfers from the AWS Region.

#04

Shared Resources

 
 

 

Types of Outpost Racks

AWS Outposts 42U rack

AWS Outposts are delivered as an industry-standard 42U rack. The Outpost rack is 80 inches (203.2cm) tall, 24 inches (60.96cm) wide, and 48 inches (121.92cm) deep. Inside we have hosts, switches, a network patch panel, a power shelf, and blank panels. Outposts are designed for high availability with redundant network switches and power connections. Customers can also provision their Outposts with additional capacity for additional resiliency. AWS delivers it to users preferred physical site fully assembled and ready to be rolled into final position. It is installed by AWS and the rack needs to be simply plugged into power and network.

Host

Each Outposts rack comes pre-configured with a mix of EC2 instance capacity and EBS storage volumes that users  choose from a pre-curated catalog of configurations. The hosts populating the Outpost rack are typically 1U or 2U and 21 inches wide. 

  • Supported EC2 instances include: General Purpose M5, Compute Intensive C5, Memory Intensive R5, Graphics Optimized G4 and I/O Intensive i3en

AWS Outposts catalog includes options supporting the latest generation Intel powered EC2 instance types with or without local instance storage.

Networking

Seamlessly extend users existing Amazon VPC from an AWS Region to AWS Outposts in the on-premises location. Use the same VPC components that are accessible in the Region including internet gateways, virtual private gateways, Amazon VPC Transit Gateways, and VPC endpoints.

  • Network Switches: Every Outpost rack has two physical network devices that attach to users local network. To connect to users local network will need a minimum of two physical links between these Outpost network devices and users local network devices. AWS provides the optics that are compatible with the fiber that users provide at the rack position.
  • Patch panels: AWS Outposts supports the following uplink speeds and quantities for each Outpost network device. The uplink speed and quantity are symmetrical on each Outpost network device. 
Power

An AWS Outpost rack uses a centralized redundant power conversion unit and a DC distribution system in the backplane. This is handled with line mate connectors so users need to just snap the host into place to provide power. This improves reliability, cost, serviceability, and energy efficiency.

  • Redundant centralized power conversion unit: The Outposts power shelf supports three power configurations. The configuration of the power shelf depends on how the host capacity is racked.
  • Power connectors: 5KVA-15KVA power supply and redundant feeds supported.
  • Bus bar: A central power bus bar in the back to distribute power to each server. We have whips supporting a variety of common power types.

.

AWS Outposts 1U and 2U form factors

AWS Outposts 1U and 2U form factors are rack-mountable servers that will provide local compute and networking services to edge locations that have limited space or smaller capacity requirements. Outposts servers are ideal for customers with low-latency or local data processing needs for on-premises locations like retail stores, branch offices, healthcare provider locations, or factory floors.

AWS will deliver Outposts servers directly to users, and they can either have the onsite personnel install them or an AWS preferred third-party contractor. After the Outposts servers are connected to users network, AWS will remotely provision compute and storage resources so you can start launching applications.

Hardware specifications

The 1U form factor is suitable for 19-inch wide, 24-inch deep cabinets and uses an AWS Graviton2 processor to provide 64 vCPUs, 128 GiB memory, and 4 TB of local NVMe storage. The 2U form factor is suitable for standard 19-inch wide, 36-inch deep cabinets, and uses an Intel processor to provide up to 128 vCPUs, 512 GiB memory, and 8TB of local NVMe storage, with optional accelerators like AWS Inferentia or GPUs.

Networking

Seamlessly extend users existing Amazon VPC to your Outposts servers in your on-premises location, just as with a 42U Outposts rack. Outposts servers support RJ45 and SFP ports to connect to customer upstream networking devices or to other Outposts servers. AWS Outposts servers support 1 Gbps or 10 Gbps ports for network bandwidth.

Scalability

AWS Outposts servers can scale to meet users application needs. Users can scale from a single server to up to 6 servers to increase the compute and storage capacity required for larger workloads.

Run AWS Services locally

With Outposts servers users can run AWS services locally, such as Amazon EC2, Amazon ECS, Amazon EKS, AWS IoT Greengrass, and Amazon SageMaker Neo. Users can continue to use the same AWS services, APIs, control plane, tools, and hardware across all users locations.

Industry use cases

Retail: Run sales and security systems at all users retail shop locations for low-latency and local network access. Aggregate inventory data and analyze customer behavior using data lakes and machine learning models running in an AWS Region.

Healthcare clinics and hospitals: Process patient data close to the source by using on-premises compute to analyze IoT health data. Enable rapid retrieval of medical imaging and local data processing to accelerate medical diagnosis.

Manufacturing: Build manufacturing process control systems that respond in near real-time to factory floor equipment. Reduce error rates and improve users operational outcomes by processing data and images from the on-premises production line with AWS services, like IoT and machine learning.

Telecommunications: Use cloud services and tools to orchestrate, update, scale, and manage the lifecycle of Virtual Network Functions (VNFs) across cell sites. Deliver high performance and low-latency across thousands of edge locations while easily managing networking capabilities.

Security 

AWS Outposts

AWS Outposts is designed to be highly available. Outpost racks are designed with redundant power and networking equipment. For additional resilience, AWS recommend that users provide dual power sources and redundant network connectivity for users Outpost. AWS Outposts racks come with built-in tamper detection and an enclosed rack with a lockable door. The data stored on Outposts is encrypted and there is an encrypted network connection to the AWS Region. Plus there’s other security controls and auditing mechanisms that incorporate tools such as AWS CloudTrail and Amazon CloudWatch. Also, customer data is wrapped to a physical Nitro Secure key that customers can destroy, offering an added layer of data protection.

  • Encryption at Rest: Amazon EBS encryption is an encryption solution for users EBS volumes and snapshots. It uses AWS Key Management Service (AWS KMS) customer master keys (CMK). With Outposts, encryption is enabled by default. 
  • Encryption in transit: AWS encrypts in-transit data between users Outpost and its AWS Region. For more information, see Connectivity through service links. Use an encryption protocol such as Transport Layer Security (TLS) to encrypt sensitive data in transit through the local gateway to your local network.
  • Data deletion: When stopping or terminating an EC2 instance, the memory allocated to it is scrubbed (set to zero) by the hypervisor before it is allocated to a new instance, and every block of storage is reset.
  • Durability: On AWS Outposts, Amazon S3 and Amazon EBS are designed for 99.99 percent durability. Durability protects against data corruption and ensures data integrity and consistency.
  • Compliance: AWS infrastructure is certified for compliance with the following standards, so you can easily incorporate a backup solution that matches an existing compliance regimen.
  • Intel AES New Instructions (AES-NI): Intel AES-NI encryption instruction set improves upon the original Advanced Encryption Standard (AES) algorithm to provide faster data protection and greater security. All current generation EC2 instances support this processor feature.
  • VPC Flow Logs: function the same way as they do in an AWS Region. This means that they can be published to CloudWatch Logs, Amazon S3, or to Amazon GuardDuty for analysis. Data needs to be sent back to the Region for publication to these services, so it is not visible from CloudWatch or other services when the Outpost is in a disconnected state.

AWS Outposts brings fully managed AWS infrastructure and services to virtually any customer site to support modernization of manufacturing workloads and business critical plant floor applications. With common infrastructure, services, APIs, and tools across their cloud and on-premises environments, manufacturers can become more agile, efficient, and competitive. AWS compute, storage, database, and other services run locally on Outposts, and users can access the full range of AWS services available in the Region to build, manage, and scale on-premises applications using familiar AWS services and tools. AWS helps manufacturers securely innovate and accelerate time to market with product and production design in the cloud by providing instant compute and storage scalability at a low cost. This results in improved Overall Equipment Effectiveness (OEE), deeper customer insights and increased value with improved product offerings. With AWS Outposts, this can be a seamless integration of their on-premises applications and AWS cloud services and tools.

  • Bring AWS services and infrastructure to virtually any customer site that runs time- and latency-sensitive plant floor applications
  • Improve IT efficiency and reduce operational risk with fully managed infrastructure
  • Modernize legacy applications and run them on-premises to meet low latency requirements
  • Use AWS tools to manage databases with services like RDS on Outposts
  • Innovate by seamlessly integrating on-premises data from AWS Outposts to AWS cloud AI, ML and analytics services
  • Provide a consistent AWS experience across cloud and on-premises