Using AWS Proton as a provisioning mechanism for Amazon EKS clusters

AWS customers have a number of options they can use to deploy Amazon Elastic Kubernetes Service (Amazon EKS) clusters. They can use the EKS console workflows, the eksctl CLI, the AWS Cloud Development Kit (AWS CDK), or several other options. There is often a single Ops-savvy user (or team) picking one of these options to define, deploy, consume and eventually maintain a Kubernetes cluster.

Many organizations are starting to implement a model where the deployment cycle mentioned above is shared between a so-called platform engineering team (responsible for defining the standards for these clusters) and developer teams (responsible for their applications).

If you are part of a team responsible for creating standards and governance for deployments while providing developers with self-service provisioning of Kubernetes clusters, this blog post is for you.

In this blog post, we will walk you through the benefits and the mechanics of using AWS Proton as a vending machine for Amazon EKS clusters. Think of this as a way to centrally define infrastructure configurations (in this case, an EKS cluster) that a platform engineering team can use to enable self-service deployments of centrally certified, consistent, and standardized configurations. In a separate GitHub repository, we provide detailed, step-by-step instructions on how to create a vending configuration and deploy your first cluster.

This solution is based on EKS Blueprints, a set of AWS curated templates to deploy fully configured EKS clusters. These blueprints are available for deployments with Terraform and CDK and could be used separately from this Proton-driven vending mechanism.

What is AWS Proton and how does it work?

AWS Proton is a managed service for platform engineers to increase the pace of innovation by defining, vending, and maintaining infrastructure templates for self-service deployments. With Proton, customers can standardize centralized templates to meet security, cost, and compliance goals. Proton helps platform engineers scale up their impact with a self-service model, resulting in higher velocity for the development and deployment process throughout an application lifecycle.

In most circumstances, customers using Proton do this by creating templates that allow two major types of resources:

• Shared core infrastructure components called environments (such as a VPC)
• Dedicated application infrastructure components called services (such as an application running on Fargate)

In a typical Proton context, the role of the platform engineer is to define both environment and service templates and to provision shared environments. The role of developers is to provision services for their application on top of existing environments.

The way Proton works is by rendering infrastructure-as-code (IaC) templates with the inputs provided at provisioning time. To do this, Proton needs to have knowledge about the IaC language being used to define the template. To date, Proton works with CloudFormation and Terraform.

This blog post (and its companion GitHub repository) will detail how to provision clusters using the EKS Blueprints for Terraform as a reference implementation. You can also use CloudFormation and can learn more about that on this Template bundles page.

What’s in it for the platform engineers and the developers?

At this point, you may be wondering why you would want to introduce Proton as a delivery mechanism for EKS clusters. We will cover some of these reasons.

These are the advantages for the platform engineers:

• A mechanism to vend fully vetted Kubernetes clusters based on company requirements and standards
• The ability to get out of the loop of having to provision Kubernetes clusters based on requests by internal users
• The ability to communicate to users (via the AWS console) about when a new version of a cluster template is available
• The ability to force-update the configuration of Kubernetes clusters when required (such as for compliance reasons)
• The ability to centrally view the information Proton tracks about the clusters deployed and their configurations

These are the advantages for the developers:

• Self-service capabilities to provision a fully functional and fully compliant EKS cluster using the AWS console or APIs
• A one-click experience for deployment of complex cluster configurations
• The ability to leverage Kubernetes sensible defaults and configuration best practices
• The ability to configure the cluster per your needs (size, version, add-ons, and more)
• A simplified upgrade experience for Kubernetes clusters
• A self-service workflow to obtain the parameters required to connect to the cluster and start working with it

Note that Proton per-se is not a cluster management and upgrade solution. Proton provides a way to guarantee consistent, controlled, and easy-to-use IaC templates. You need to determine your upgrade strategy and evaluate how your template will work. In the context of this solution specifically, we recommend that you check how the EKS Blueprints support upgrading to new versions of Kubernetes and what versions they support at any given point in time.

Proton creates a virtuous loop so that platform engineers can capture developer feedback and then update templates. The platform engineers become the product owners and the engineers of their products, so they can prioritize what goes into the templates based on popular demand. This solution makes it easier, faster, and smoother for platform engineers and developers to work together and collaborate.

Overview of the Proton configuration for vending Kubernetes clusters

Before we can fully appreciate the nature of this solution, we need to take a step back and create some context. One common pattern would be to deploy EKS clusters as shared Proton environments where several app developers can deploy Kubernetes apps as Proton services.

However, a lot of customers are telling us they are more interested in having Proton act as a vending machine for entire clusters that developers can consume flexibly within the broad spectrum of the Kubernetes ecosystem (as opposed to having developers consume predefined Proton application services templates via Proton APIs).

Because developers are directly creating environments on demand, rather than having the platform team manage environment creation, the solution proposed in this blog will assume that developers are able to deploy EKS clusters as Proton environments. Again, this is an exception to the traditional Proton pattern, but we believe it’s a useful model in the context of Kubernetes.

To better visualize these concepts, the following diagram shows two different approaches where Proton can be used. At the top is a more traditional scenario where a Proton environment is comprised of a VPC and an Amazon Elastic Container Service (Amazon ECS) cluster, provisioned by a platform engineer, and a Proton service is comprised of an Amazon ECS service (with an Application Load Balancer and its own deployment pipeline), provisioned by a developer. At the bottom is our specific solution where there is a Proton environment comprised of a VPC and an EKS cluster, provisioned by a developer.

Note that the diagram above calls out only who deploys what. It is important to remember that, regardless of who has deployed these environments and services, the platform engineering team owns all the templates involved, which embed best practices and guarantee the right degree of control.

Getting started

As mentioned, we have prepared a dedicated GitHub repository that includes all the steps to implement the EKS clusters vending machine described above. The repository focuses on the how-to, so in the rest of this blog post, we will create additional context about what you are going to do.

The GitHub repository hides some of the underlying richness (and relative complexity) about how the Proton and Terraform integration works. The repository contains both a sample Proton template for vending clusters based on the EKS Blueprints as well as a sample GitHub Actions workflow that mimics a basic Terraform pipeline. You can use this repository as a starting point, customize the template, and remove GitHub Actions to adjust it to your teams’ requirements.

If you intend to use this solution in production, we strongly recommend that you familiarize yourself with the details of integration. A good way to do this is by reading the AWS Proton Terraform Templates and the AWS Proton Self-Managed Provisioning blog posts. Additionally, familiarize yourself with the EKS Blueprints workflows, because at the end of the day, Proton is only a facade, and the nature of the templates you can create is as good as the flexibility the Terraform modules provide.

Using Proton as a vending machine for EKS clusters will allow your developers to provision clusters with an intuitive interface such as the following:

Once the cluster has been deployed, Proton will provide all the required information through Outputs to connect to the cluster via kubectl. Not shown in the example above is the fact that the platform engineering team can enable GitOps modules if developers prefer that approach to maintain their applications on the cluster being provisioned.

Proton will also empower your users to upgrade existing clusters to new versions as you update templates to include new Kubernetes versions, as shown here:

In addition to allowing developers to consume the cluster via standard Kubernetes APIs, this solution allows developers to take advantage of the new Kubernetes Resource View in the EKS console. This recently released feature provides a fully managed, out-of-the-box graphical user interface to explore and navigate all Kubernetes resources deployed inside the cluster:

Enough for a teaser. You are now ready to move to the GitHub repository and give it a try on your own AWS account!

Conclusions

In this brief blog post we have discussed the value of using Proton as a vending mechanism for EKS clusters, which allows platform engineers to define approved templates and allows developers to self-serve. This solution improves governance, scales the knowledge of platform engineering teams, and increases the agility of developers who use Kubernetes via self-service cluster provisioning and guided maintenance. In addition to providing an overview of how this solution can help your team, we offered a step-by-step workflow (via a GitHub repository) for an example implementation of a vending machine. Last but not least, we provided a number of links to other blogs to dive deeper into the Proton and Terraform integration that makes this solution possible.