AWS Proton (ending 7 October 2026)
This page exists so that a reader arriving from an old design document or a search result learns the service is closing rather than starting to build on it.
What Proton did
Section titled “What Proton did”Proton was a two-sided provisioning framework. A platform team authored versioned environment templates (shared infrastructure) and service templates (the infrastructure, monitoring and CI/CD pipeline for one application or microservice). Application developers then picked a service template and pointed it at a source repository, and Proton provisioned the resources, configured the pipeline and deployed the code.
Its distinguishing feature was version tracking: Proton identified every service instance running an outdated template version and could upgrade them together, which is the part that is genuinely awkward to rebuild.
It supported both AWS CloudFormation and Terraform as infrastructure-as-code providers.
What to use instead
Section titled “What to use instead”There is no single replacement; the pieces split up.
- AWS Service Catalog is the surviving AWS answer for publishing approved, versioned infrastructure that teams provision themselves. It covers portfolios, versioning, launch constraints and cross-account sharing.
- CloudFormation or the AWS CDK, held in a shared library or construct package, covers the template authoring. Versioning becomes a package version, and template upgrades become dependency bumps in each consuming repository.
- A CI/CD pipeline in your existing tooling — CodePipeline, GitHub Actions or equivalent — covers the deployment half. Proton’s pipeline generation was convenience, not capability.
- Terraform users keep their modules; the module registry already provides the versioning and reuse Proton wrapped around it.
If you are choosing now, the practical shape is a shared template or construct library plus Service Catalog for the self-service front door.