LGW – Incorporating AWS Outposts into Your On-Premises Data Center

A common reason customers deploy AWS Outposts is because they have something in their on-premises data center, such as a database, and the application has very tight latency or jitter requirements. It wouldn’t do much good if an EC2 instance on an AWS Outposts instance had to route back over the service link to get to an internet gateway or NAT gateway just to turn around and go back to the same data center:

Figure 5.8 – Outposts subnet routing to the internet via an internet gateway

Alternatively, if an EC2 instance on an AWS Outposts Rack deployment wishes to connect to the internet, it could do so by traversing the service link back to the region to utilize the internet gateway for the VPC:

Figure 5.9 – Paths to the internet

However, an LGW provides a more direct path for such instances to leave the VPC. LGWs are also what an instance would use to connect to a resource in the on-premises data center, such as the aforementioned database.

Elastic load balancers in AWS Outposts Rack deployments

An Application Load Balancer (ALB) can be used to distribute incoming HTTP(S) traffic to different types of resources on Outposts racks, such as EC2 instances and containers.

Available services

An AWS Outposts Rack deployment provides several locally available services that are manageable via the same APIs or Infrastructure as Code (IAC) tools, such as CloudFormation.

Amazon Route 53 Resolver

This service allows customers to provide on-premises resources with local DNS resolution. Outposts racks can use this capability to provide hybrid DNS functionality between an on-premises DNS server and a Route 53 Resolver through the use of inbound and outbound endpoints. This also provides customers with the ability to cache all DNS queries originating from the Outposts rack for improved application availability by eliminating additional DNS requests to be sent after the cached entry is made:

Figure 5.10 – Creation of an Amazon Route 53 Resolver

Note that the following capabilities will not be available during any network disconnect event that occurs between the deployment and parent region: health checks, control plane changes, DNS failover, cached entry retries which can result in stale responses, and of course connectivity to in-region VPC resources, even though DNS resolution for those resources will continue to function properly.