The Sandwich Responsibility Model: Introduced by AWS Outposts

I recently had the privilege of attending the AWS Partner Network Ambassador Global Summit in Seattle. A deep-dive session on Outposts triggered some thinking around the opportunities that Outposts offer.

What are AWS Outposts?

AWS Outposts bring native AWS services, infrastructure and operating models to virtually any data centre, co-location space, or on-prem facility. You can extend your on-prem environment to AWS and leverage cloud native services across both worlds: public cloud and on-prem.

The service is not in GA (general availability) yet, but we can expect it to go live soon. Looking at the overall capabilities, it is becoming clear that there will be a new Shared Responsibility Model for Outposts. The AWS Shared Responsibility Model defines which security controls are managed by AWS and which ones are managed by the customer. The new model will bring game changing simplifications for any hybrid-cloud operating model.

In this blog post, we will have a look at what the Shared Responsibility Model is going to look like. I hope you are not overly hungry - because it looks a little bit like a sandwich.

Why Would You Want Outposts?

Outposts are ideal for use cases that require a hybrid-cloud solution. This is usually driven by regulatory requirements where some data needs to be kept on-prem and other data - such as the public website - can be hosted in the public cloud.

Outposts bring some significant benefits for enterprise customers:

• Native cloud services across AWS and on-prem - You can use the same APIs across your on-prem and public cloud environment and you don’t need to build the entire IaaS stack.
• Simpler Operating Model - Outposts are fully managed. Therefore you can use the same tools and processes giving you a consistent environment management approach for both worlds.

What Do You Get?

Here is a subset of features that have been announced for the GA. Further features will gradually follow once the service is released.

• Compute and Storage - A selection of general purpose, compute optimised, memory optimised, and graphics optimised EC2 instance families.
• Networking - VPC extension and local networking - Seamless extension of a regional VPC to an on-prem location.
• Native cloud services - ALB, ECS and EKS, Amazon EMR for big data, and RDS for databases can all be launched on-prem. Private Link gateway endpoints can be used to connect privately to regional AWS services such as Amazon S3 and DynamoDB. How good is that?
• AWS tooling - AWS CloudFormation, Amazon CloudWatch, AWS CloudTrail and others can be used to run and manage workloads in the same way as your public cloud resources.

How Can You Get it?

The onboarding process is going to look like this:

1. Request Outposts - Either via the AWS Console or API

2. Connect - AWS needs to configure and connect hardware to your power and network facilities. AWS will require several specifications to make sure they bring the right hardware, including cables. 

3. Launch - As a customer you can then launch the Outposts services (cloud native on-prem) via API or the AWS Console.

How Does This Change the Shared Responsibility Model?

To answer this question, let's have a quick look at some existing Shared Responsibility Models.

If you opt-in for an IaaS model, then there is a lot you need to manage yourself - including network protection (e.g. security groups, Network ACLs) and much more, as illustrated in the diagram below:

Image from AWS Security Best Practices, 2016

Moving towards a PaaS model you need to take on fewer responsibilities because AWS is already managing the entire platform for you, as shown in the following picture:

Image from AWS Security Best Practices, 2016

Now let’s have a look at the Outposts Shared Responsibility Model: 

• The customer is responsible for the underlying on-prem infrastructure. 
• AWS is responsible for the Outposts infrastructure and also for all the APIs that Outposts integrate to (e.g. EC2, RDS, EBS, ECS, ElastiCache etc).
• The customer is then again responsible for the top layer – e.g. managing security groups or the ALB configuration.

The final version of the new Shared Responsibility Model has not yet been published by AWS. Considering the above capabilities however, it’s clear that there will be a new (additional) Shared Responsibility Model, which will look a little bit like a sandwich:

The new model will impact the way to manage the layers you are responsible for. This might sound complex, but having the opportunity to use native APIs across the board really does simplify your integrations and operating model.

The portion of ‘customer responsibility’ is getting smaller compared to an IaaS model. Having Outposts means your data can stay on-prem if it needs to – and you can still use the AWS APIs. It also means you can nicely integrate to your VPCs in the public cloud where you host all the other resources, such as your public website.

Key Takeaways

Outpost brings a new Shared Responsibility Model which moves some infrastructure responsibilities towards AWS. It therefore simplifies the customer’s operating model. By providing native cloud API for on-prem, it also streamlines your provisioning and management processes. Contino can help you with a Return on Investment model if you are considering this game changing service.