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:
- Serverless workloads
- Containerized workloads running on Fargate
- 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.
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.
4) Next, we provision a production environment—fargate-prod-env
based on the above environment template.
- Follow the instructions for creating an environment, and enter values for the optional parameters, if desired.
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
. Choosefargate-env
as the Compatible environment template, and make sure that the CI/CD pipeline option is checked.
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.
6) Once the service has been deployed successfully, you will be able to reach it using the “serviceURL” output.
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!