Containers

Introducing new templates to the AWS Proton template library

Today, we are announcing new additions to the AWS Proton sample template library. The library is a curated set of AWS Proton templates that use AWS best practices for popular applications such as a load-balanced web application or an Amazon API Gateway backed by AWS Lambda. You can use the library to deploy these common application architectures quickly, as a starting point to build your own templates, or to learn more about how Proton templates work.

Each service template comes with an AWS CodePipeline-based CI/CD pipeline and with application code that you can use to test the workflow end to end. Samples are available for both the Infrastructure-as-Code languages supported by Proton—AWS CloudFormation or HashiCorp HCL for Terraform.

For more details, visit the Template Library in the AWS Administrator Guide.

What is AWS Proton?

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.

The template library

Our library contains sample templates for both CloudFormation and Terraform. Use CloudFormation templates for AWS-managed provisioning, and Terraform templates for self-managed provisioning workflows. With AWS-managed provisioning, Proton handles infrastructure provisioning using AWS CloudFormation and appropriate AWS Identity and Access Management (IAM) roles. With self-managed provisioning, you can use custom workflows to provision infrastructure, and Proton will compile your template and submit a pull request to your infrastructure repository. Please see Proton self-managed provisioning to learn more.

You can use these templates to deploy common applications using AWS vetted architectures. Each template has a detailed description of its architecture and the required input parameters. Alternatively, you can use these templates as a starting point to create your own Proton templates or to explore different aspects of assembling a Proton template, such as separating environment and service resources, setting parameter requirements in schema files, passing parameters between environments and services, creating CI/CD pipelines, and more.

Proton template overview

In Proton, platform engineers separate infrastructure as code into environment and service templates. Environment templates define shared resources, like VPC and IAM roles, that are used by multiple services. Service templates define the infrastructure needed to deploy and maintain a single application. Environments are created by platform engineers using environment templates and typically represent stages in your software release management, such as development, staging, or production. Developers use service templates to create service instances in specific environments and, optionally, a service pipeline. A core job of platform engineers in Proton is to connect and coordinate the different tools needed for infrastructure provisioning and code deployments through these templates, and they can use the sample template library to get started with this process.

We provide sample templates for three common types of workloads:

  1. Serverless workloads
  2. Containerized workloads running on Fargate
  3. Containerized workloads running on self-managed EC2 hosts

The library has an environment template for each of these workload types. Each environment template supports multiple service templates. These service templates represent common types of services such as an internet-facing web service, a backend service, a scheduled task, or a worker service. Each environment template provisions all the resources required by its compatible services, such as networking, a private DNS-based namespace to support service discovery for the backend service, or a shared Simple Notification Service (Amazon SNS) topic for implementing service-to-service asynchronous communication using the worker service.

The library is broken down into three different repositories:

The first two repositories house Proton templates for CloudFormation and Terraform respectively. The application code repository provides sample code that can be run on the provisioned resources to demonstrate simple functionality. Currently, we have the following service templates in the library:

AWS CloudFormation

Application Service template Environment template Application code
Serverless workloads
1 Internet-facing request-driven Lambda service apigw-lambda-svc vpc-env lambda-ping-sns
2 Internet-facing request-driven App Runner service apprunner-svc ecs-static-website
3 Scheduled Lambda service scheduled-lambda-svc lambda-ping-sns
4 Worker Lambda service worker-lambda-svc lambda-worker
Containerized workloads running on Fargate
5 Internet-facing load balanced Fargate service load-balanced-fargate-svc fargate-env ecs-static-website
6 Backend Fargate service backend-fargate-svc ecs-backend
7 Scheduled Fargate task scheduled-fargate-svc ecs-ping-sns
8 Worker Fargate service worker-fargate-svc ecs-worker
Containerized workloads running on self-managed ECS hosts
9 Internet-facing load balanced ECS on EC2 service load-balanced-ecs-ec2-svc ecs-ec2-env ecs-static-website
10 Backend ECS on EC2 service backend-ecs-ec2-svc ecs-backend
11 Scheduled ECS on EC2 task scheduled-ecs-ec2-svc ecs-ping-sns
12 Worker ECS on EC2 service worker-ecs-ec2-svc ecs-worker

Terraform

Application Service template Environment template Application code
Serverless workloads
1 Internet-facing request-driven Lambda service apigw-lambda-svc vpc-env lambda-ping-sns
2 Internet-facing request-driven App Runner service apprunner-svc ecs-static-website
3 Scheduled Lambda service scheduled-lambda-svc lambda-ping-sns
4 Worker Lambda service worker-lambda-svc lambda-worker
Containerized workloads running on Fargate
5 Internet-facing load balanced Fargate service load-balanced-fargate-svc fargate-env ecs-static-website
6 Backend Fargate service backend-fargate-svc ecs-backend
7 Scheduled Fargate task scheduled-fargate-svc ecs-ping-sns
8 Worker Fargate service worker-fargate-svc ecs-worker
Containerized workloads running on self-managed ECS hosts
9 Internet-facing load balanced ECS on EC2 service load-balanced-ecs-ec2-svc ecs-ec2-env ecs-static-website
10 Backend ECS on EC2 service backend-ecs-ec2-svc ecs-backend
11 Scheduled ECS on EC2 task scheduled-ecs-ec2-svc ecs-ping-sns
12 Worker ECS on EC2 service worker-ecs-ec2-svc ecs-worker

How to use the sample library

Each sample template repository (one for AWS CloudFormation, one for Terraform) is structured to support template sync, which allows you to push, update, and publish templates directly from your Git repository. You can fork the sample template repository and specify your forked repository when you create a new environment or service template in Proton. Alternatively, you can download the template files, bundle them and upload them to S3 to create a template.

As an example, let’s deploy a static web application running on an internet-facing load balanced Fargate service using CloudFormation templates. We deploy a fargate-env and a load-balanced-fargate-svc to run the ecs-static-website application.

1) Fork the sample template repository.

UI screenshot of aws-proton-sample-templates with Fork highlighted

2) Set up the IAM roles needed for Proton, AWS CodeStar connection required for connecting to your template and application code repository, and register your repository in Proton.

3) Create the fargate-env template. Follow these instructions to register and publish the environment template.

  • Make sure you choose “Sync templates from Git” as the template bundle source.
  • Replace <github-username> with your username in the repository setting.
  • You can leave the Template bundle directory field empty.
  • The template name has to match the name of the directory that contains your template in the repository—in this case, fargate-env for template sync to work.

Sreenshot of UI showing Create environment template

4) Next, we provision a production environment—fargate-prod-env based on the above environment template.

Screenshot of the Configure environment UI

screenshot of the Configure Customer Settings UI

5) Now create the load-balanced-fargate-svc service template. Follow these instructions to register and publish the environment template.

  • Make sure you choose “Sync templates from Git” as the template bundle source.
  • Replace <github-username> with your username in the Repository setting.
  • You can leave the Template bundle directory field empty. Again, template sync requires that the template name matches the environment in the repository – in this case, load-balanced-fargate-svc. Choose fargate-env as the Compatible environment template, and make sure that the CI/CD pipeline option is checked.

Screenshot of the create service template ui

6) Before creating a service based on the above service template, make sure that the fargate-prod-env has been deployed successfully. Follow these instructions to create a service.

  • In the service repository settings, use your own GitHub repo containing the application code, or fork the sample application code repository.
  • Configure the input parameters for your service. If you use the provided application code repository, you can select the desired source code directory using the pipeline service_dir input – it will be set by default to the correct one for the template you choose.
  • For this example, we use the code for ecs-static-website. The service template has a detailed description of all the input parameters.

Screenshot of fargate-prod-env with "Deployment status succeeded" highlighted

Screenshot of Configure Service UI

Screenshot of Configure custom settings UI

6) Once the service has been deployed successfully, you will be able to reach it using the “serviceURL” output.

screenshot of the production-website UI

Conclusion

Use the AWS Proton sample template library as a starting point for deploying architectures that use AWS best practices or creating your own Proton sample templates. We intend to continue supporting and enhancing this library with new examples. We invite you to share your templates or suggestions by making a pull request to the repositories. Happy Proton-izing!

Rafa Alvarez

Rafa Alvarez

Rafa is a Principal Product Manager at AWS. He joined the Proton team at its inception. Before Proton, Rafa was working in Amazon Prime Video and, before that, worked in products in both startups and large corporations.

Saad Ahmed

Saad Ahmed

Saad Ahmed is a Senior Product Manager Technical at AWS Proton, based in the New York City area. He joined AWS 9 months ago after completing his MBA from Wharton. He has over 8 years of experience building products ranging from AI/ML processors to medical emergency devices.