How AWS Partners Can Get Started with AWS Outposts – By Knowing What it’s Not

By Adrian SanMiguel, Principal Partner Solutions Architect – AWS Outposts

In speaking with AWS Partners of all sizes and areas of expertise, one thing has become clear to me—there is a growing need for getting more robust, more powerful Amazon Web Services (AWS) technology to the edge, in more clever ways than before.

AWS Outposts is exactly that.

AWS Outposts is a service that allows customers to run a subset of AWS services—on fully managed AWS hardware—located in their own data center, remote office, production plant, or virtually anywhere they want them to be. The art of the possible, as cliché as it can sometimes be, really does start there.

This is because after an Outpost has been installed and connected to a local network, customers can launch and run a host of AWS services locally:

Figure 1 – Services that run locally within AWS Outposts.

An AWS Outpost is seamlessly connected to an AWS Region where it has access to the full suite of AWS services managed from a single plane of glass, the AWS Management Console.

I will help both customers and AWS Partners understand how Outposts can help—by sharing information about what it is and what it’s not. In reading this post, you will have a firm understanding of AWS Outposts and how it can best be positioned for your customers and prospects.

AWS Outposts is not private cloud; it’s the extension of the AWS Region into your facility.

The idea of being able to have AWS-specific hardware in the data center or colocation facility is attractive, and I often hear this declaration: “Great! I can do AWS in my facility because I don’t trust the public cloud!” This is often one of the first comments I get from an AWS Partner or customer, regardless of the vertical or use case they’re working in.

The single most important thing to remember is that AWS Outposts is not a private cloud, nor should it be thought of as one. At its root, Outposts is a logical and physical extension of the AWS Cloud in your location. It’s a true extension of the AWS Region into your location of choice, and it’s the same hardware same Nitro technology you would find in the region.

You may be thinking, “Well, if it’s not a private cloud equivalent, then what’s the point?” There are a variety of ways to look at this, but think of the reasons private cloud came to be: customers tend to have hard requirements regarding ultra-low latency access from on-premises resources. This can be as complex systems such as mainframe and proprietary hardware (think Sun Solaris or HP-UX), or maybe petabytes of data in on-premises storage arrays.

In many instances, these workloads and applications were never possible to get into the cloud, or incredibly complex to do so. In a previous role, I worked with a customer to migrate 150 petabytes of data to AWS—and Snowmobile was out because the data had to service on-premises workloads *and* the cloud simultaneously. Thankfully, this is no longer the case. It’s particularly exciting for me personally—and speaks loudly—in the world of gaming.

With AWS Outposts, customers like Riot Games are able to bring ultra-low latency closer to their player base, and dramatically change the latency experience for gamers globally. When ten-thousandths of a second (also known as “peeking”) is the difference in reaction time that measures a decision in a win or a loss, that latency reduction is a game-changer and truly levels the playing field.

Service Link is your lifeline back to the region, and you can’t leave home without it.

The first and most important thing to keep in mind with AWS Outposts is that it must be connected at all times with its parent region.

Think back to growing up and playing in the yard or street with your friends; if your folks lost sight of you, there was probably some yelling happening. If you didn’t reply fast enough, or not at all, that could lead to an angry parent. In my experience, trouble followed if I wasn’t where I said I’d be or was given permission to be. The same concept applies here.

During the AWS Outposts Site Access Validation (SAV) and the site creation and ordering process, it’s important to keep this in mind. This is because you’ll be going through an exercise of showing and telling AWS everything about your site. This serves as a commitment that you will 1) put your Outposts rack(s) where you say you will; 2) keep it there; and 3) provide reasonable assurances you’ll keep it online at all times because it needs to establish and maintain region connectivity via Service Link at all times.

If any of these three things are not true, please bear in mind that AWS Outposts is not designed to be run offline, or disconnected from its parent region. This should be a warning sign for your prospecting.

It’s important to call out that public internet connectivity comes up quite a bit, and this is an acceptable means to connect back to the partner AWS Region. More often than not, this tends to be used as a backup connectivity mechanism, usually via MPLS or leased lines that are already present in their facilities. If your customer may have a barrier to entry with leased lines, and only has the ability to come over public Internet, rest assured this will likely work for you.

However, just because you can potentially connect AWS Outposts over the public internet, it doesn’t necessarily mean it’s the right solution. Some locations, such as onboard cruise ships and farms, merit additional discovery and conversations. This is because such locations tend to run into challenges where internet connectivity is spotty at best, or outright not available. If this is the case, the AWS Snow family is usually the better fit for the workload.

Speed and throughput matter in everything, especially with AWS Outposts connectivity.

As of the time of this writing, it’s a hard requirement to have egress speed back to the region of at least 1 Gbps, as this is the lowest speed in which AWS Outposts is supported. For some customers and Partners, this is difficult to accomplish due to local leased line costs.

With ongoing launches of service refinements, such as that of Amazon Elastic Block Store (EBS) local snapshots on AWS Outposts, you now have the options to take steps in reducing the overall bandwidth requirement needed by your Outposts in the event there is only a 1Gbps single link supplying a facility, as is the case with many customers.

If you’re in such a position where there is a single link for your site, this chart shows how we recommend you configure your edge devices the Outposts rack will connect to. You’ll only need a 1Gbps link to satisfy the minimum Service Link needs, as shown below.

Bear in mind that region-based services such as the Amazon Elastic Container Registry (ECR) will require Amazon Machine Images (AMIs) copied over the wire, through the aforementioned Service Link, and onto the AWS Outpost in order to launch new containers. Local snapshots residing in Amazon S3 on Outposts help mitigate this need for EC2-based deployments, saving precious bandwidth.

With that said, the guiding light here is to remember that services such as AWS Backup or Amazon DynamoDB, if leveraged in the Outpost rack, have their Control Plane based in the region. This means all API calls, and most interactions are leaving the Outpost rack for some purpose. Yes, this includes things one wouldn’t imagine, such as AWS Identity and Access Management (IAM).

An example of what this looks like is below; this is a sample architecture of how some of your instances in the AWS Outpost rack would communicate with the Control Plane of services within the parent region. This communication flow is how the use of services that are region-only, such as AWS Transit Gateway, would traverse over your Service Link.

Figure 2 – How an AWS Outpost rack’s resources communicate with in-region services.

Additionally, if you are running a talkative service or application in region, such as a Cassandra ring or Galera cluster, you’ll want to make sure you have both a consistent and low-latency connection into wherever you place your AWS Outposts rack(s).

Conclusion

With these three points to bear in mind, you will be on your way to delighting your customers by using AWS Outposts to solve their business problems.

As a bonus, Systems Integrators (SIs) and Independent Software Vendors (ISVs) may wish to pursue the AWS Outposts Ready designation. This AWS Partner Network (APN) program exists to show prospective customers you have demonstrated the capabilities and knowledge to support their workloads on AWS Outposts.

Remember that you’ll be using Outposts as a true AWS Region extension into your facility. Keep it connected at all times, and keep the bandwidth discussions at 1Gbps+ and you’ll be in a good position to continue working with the customer to qualify their workload.

Please refer to this post when customers speak to you regarding AWS Outposts. Always start with the workload you’re considering for Outposts when scoping and validating their needs, and understand where you should proceed with caution.

If you have any questions or points of feedback, feel free to reach out to your APN representative, or to me directly via the comments.