As introduced in my previous post AWS Outpost brings a lot of new possibilities to extend the reach of the AWS cloud to virtually any location. In this post, I’ll dive a little deeper and show you how to incorporate AWS Outposts in your AWS landing zone design.
Outpost Networking Fundamentals
I’ll start by giving a short introduction to the new networking constructs for AWS Outposts and how they are used to extend your VPC to AWS Outposts. Assuming you’re already familiar with the basic AWS VPC constructs, we’ll dive straight in. If not, you’ll find a great overview here.
An AWS Outpost is connected to a nearby AWS region that will act as the Home Region. To provide connectivity between the Outpost and the Outpost Service Control Plane in the home region a service link will be configured. The service link is used for management traffic as well as traffic between the workloads on the AWS Outpost and workloads hosted on AWS. AWS Outposts requires a connection that can provide at least 1 Gbps of bandwidth, preferably using a Direct Connect connection. Refer to the official AWS documentation for a detailed description.
Once operational, an AWS Outpost must be associated with one or more VPCs in the selected home region. After associating, subnets can be created to be used for your EC2 instances and other services. By creating these subnets you basically extend the VPC hosted in AWS to the AWS Outposts on-premises. The created subnets must use blocks from the same CIDR range(s) as the VPC. With the new subnets created, you can now use all the familiar networking constructs that you are used to in an AWS VPC, like route tables, security groups, and NACLs. In the example below the instances running on the AWS Outpost (C,D) can freely communicate with ones in the AWS subnets (A,B), if the associated security groups and NACLs allow it.
As shown in the picture above, the route table attached (top right) to the subnets specifies the default local route, enabling connectivity within the VPC. In addition, it has entries pointing towards a Transit Gateway and a new construct; the Local Gateway. The local gateway is used as a target to route traffic to workloads running on-premises, outside of the AWS Outposts. Instances that are running on the Outpost are assigned an Elastic IP from a Customer Owned IP Pool or CoIP. One or more CoIP pools are configured by AWS during installation and provide a range of IP addresses that are advertised by the Local Gateway to your local network over BGP. The Local Gateway performs network address translation (NAT) for instances on the Outpost that have an associated IP from the CoIP pool to enable connectivity to services on the on-premises network. At re:Invent 2020 it was announced that a new feature will be released, called Direct Routing, that will allow you to advertise the Outposts subnet ranges over the Local Gateway, removing the need for the CoIP pool.
Now that you have a basic understanding of the networking, I will show you how you can use AWS Outposts in your AWS Landing Zone design.
Extending the Landing Zone - Using AWS Transit Gateway
To enable connectivity from any other AWS account in your organization you can use AWS Transit Gateway to connect to the account owning the AWS Outpost. Using both VPC route tables and Transit Gateway route tables, traffic destined for the on-premises instances (and instances running on the AWS Outpost) is routed to the VPC that is associated with the AWS Outpost.
Possibly, the Home Region of the AWS Outpost is different from the main AWS region currently in use. In this case, AWS Transit Gateway Inter-region peering can be configured to enable traffic flows between these regions.
Extending the Landing Zone - Using a Shared VPC
Introduced at re:Invent 2018, VPC sharing allows you to share VPC subnets with multiple AWS accounts using Resource Access Manager. Since an AWS Outpost is directly associated with a single AWS account, using shared VPCs helps you to make the AWS Outpost available to other accounts.
In the diagram above you see two subnets, one private subnet in AWS and one Outpost subnet. The subnets are owned by account A and shared with account B, using AWS Resource Access Manager. With this setup both accounts are able to leverage the AWS Outpost. By default, we can only assign IPs from the CoIP-pool to instances running in Account A.This means that communication is only possible between the on-premises instances and the instances running in Account A.
To enable the same connectivity for Account B, a CoIP pool needs to be shared with this account as well. As explained in the beginning of this post, a customer owned IP-pool (CoIP) is needed to enable connectivity to the on-premises network using the local gateway. This can be the same pool as used by the instances in Account A or, alternatively, additional CoIP-pools can be requested through AWS support. When the additional pool is created and shared with Account B it can be used to assign IPs from a different range giving you granular control over which accounts use which IP-ranges.
If you want to learn more, I can recommend to read this really nice blog post on the AWS blog, which goes into much more details.
Conclusion
In this blog I’ve demonstrated two possible ways to integrate AWS Outposts in your Landing Zone designs. I’m curious to hear if you see or use any other ways to connect to your AWS Outposts.
Photo by Kotaro Ikawa on Unsplash
comments powered by Disqus