AWS Infrastructure Composer Is Being Retired as a Standalone Console

AWS Infrastructure Composer is approaching an important change that developers using visual infrastructure design tools should prepare for. AWS has announced that the standalone Infrastructure Composer console will stop accepting new customers on October 29, 2026, and will shut down on December 7, 2026.

The change does not mean that existing AWS infrastructure will stop working or that every Infrastructure Composer feature is disappearing. AWS CloudFormation templates, deployed stacks, and existing deployment workflows will remain unaffected. The visual authoring experience will also continue through the AWS Toolkit for Visual Studio Code.

For developers who use Infrastructure Composer to design serverless applications, the main task is to review how they access the tool, preserve their infrastructure templates, and move their design workflow to the supported experience before the shutdown date.

What Is AWS Infrastructure Composer?

AWS Infrastructure Composer is a visual infrastructure-as-code (IaC) tool for designing applications on AWS. It provides a drag-and-drop canvas where developers can add AWS resources, connect them, configure their relationships, and generate infrastructure templates.

Instead of writing an entire CloudFormation template manually, a developer can begin by arranging resources such as:

• Amazon API Gateway for exposing application endpoints

• AWS Lambda for running application code

• Amazon DynamoDB for storing application data

• Amazon S3 for object storage

• Amazon SQS for asynchronous message processing

Infrastructure Composer represents resources as visual cards. When developers connect and configure these cards, the tool generates or updates the corresponding infrastructure definition.

For example, a serverless order-processing application might contain an API Gateway endpoint connected to a Lambda function, with DynamoDB storing order information and SQS handling background processing.

The visual canvas helps developers understand the relationships between these resources. The generated template provides a version-controlled definition that can be reviewed, tested, and deployed.

Infrastructure Composer supports AWS CloudFormation resources and can be used with AWS Serverless Application Model (AWS SAM) workflows.

What Is Changing on December 7, 2026?

AWS is retiring the standalone Infrastructure Composer console, rather than removing the entire visual authoring capability.

The distinction matters because developers may assume that retiring the web console requires rebuilding their infrastructure or replacing every existing template. That is not the case.

The announced timeline is:

Existing customers who registered before the new-customer cutoff can continue using the standalone console during the transition period, until the shutdown date.

AWS recommends moving to the Infrastructure Composer experience available through the AWS Toolkit for Visual Studio Code.

The embedded visual experience in the CloudFormation console is also changing. AWS says it is being replaced with an improved visual infrastructure-as-code editor integrated directly into the CloudFormation console.

What Happens to Existing Applications and Templates?

The most important point for application teams is that the console retirement does not remove the infrastructure they have already deployed.

AWS has identified several areas that are not affected by the standalone console shutdown.

Existing CloudFormation stacks continue working

CloudFormation stacks created from Infrastructure Composer templates are not being retired as part of this change. Existing resources and deployment workflows continue to operate normally.

For example, if a production application uses API Gateway, Lambda, and DynamoDB, the retirement of the visual editor does not automatically stop those services or delete the deployed resources.

Teams should still maintain their usual deployment, monitoring, and recovery practices, but there is no need to recreate a working stack solely because the standalone editor is going away.

Saved templates remain available

CloudFormation templates stored locally or in Amazon S3 are not affected by the console retirement.

This is an important reason to keep infrastructure definitions outside a browser-only workflow. A saved template can be opened in a supported editor, reviewed in source control, and used by existing deployment pipelines.

Teams should verify that their latest templates are stored in a location they control rather than relying exclusively on a browser session or an unsaved editing state.

The VS Code integration remains available

AWS states that the full Infrastructure Composer visual authoring experience remains available through the AWS Toolkit for Visual Studio Code.

Developers can continue using a visual canvas and code editor in their local development environment. This provides a transition path without requiring teams to abandon visual infrastructure design.

How to Move Infrastructure Composer to Visual Studio Code

Teams currently using the standalone console should validate the alternative before the shutdown date. A practical migration process involves the following steps.

Step 1: Inventory your existing projects

Identify the CloudFormation and AWS SAM templates currently designed or maintained through Infrastructure Composer.

For each project, record:

• The location of the latest template

• The AWS services and resources it defines

• The deployment process that consumes it

• Any local files referenced by the template

• The team responsible for maintaining the infrastructure

This inventory helps prevent a common migration mistake: moving the editor workflow while overlooking files or dependencies needed to reproduce the application architecture.

Step 2: Save and version-control your templates

Ensure that each project has a saved infrastructure definition.

A typical repository might use the following structure:

order-processing/
├── template.yaml
├── src/
│   └── handler.py
├── tests/
│   └── test_handler.py
├── samconfig.toml
└── README.md

This is an illustrative AWS SAM project layout. The exact files depend on the application and deployment configuration.

The important point is that the infrastructure template, application code, configuration, and tests should be maintained together where appropriate.

Use Git or another version-control system to track changes. Commit a known-good version before changing the editing environment so that the team can compare generated templates and investigate unexpected differences.

Step 3: Install the AWS Toolkit for Visual Studio Code

Install the AWS Toolkit extension in Visual Studio Code and configure the required AWS credentials and permissions.

Follow your organization's approved authentication approach. Avoid storing long-lived access keys directly in project files or source control.

Once the Toolkit is ready, open the relevant CloudFormation or AWS SAM template. AWS documents several ways to launch Infrastructure Composer from VS Code, including the editor's Infrastructure Composer control, the file's context menu, and the Command Palette.

Step 4: Open and validate the template

Open the existing template in the visual editor and confirm that the expected resources and connections appear correctly.

Check that:

• All expected resources are present.

• Resource properties and references are preserved.

• Connections reflect the intended application architecture.

• Parameters and environment-specific values remain correct.

• Referenced files and application code are available.

Do not assume that a visual representation alone proves a template is deployable. The generated infrastructure definition remains the source that should be validated and reviewed.

Step 5: Test the deployment workflow

Use the team's existing validation and deployment process to confirm that the template still behaves as expected.

For AWS SAM projects, a basic validation command is:

sam validate --lint

This checks an AWS SAM template using the SAM CLI's validation and linting capabilities. The SAM CLI must be installed, and validation does not guarantee that a deployment will succeed or that the application is correct.

For a CloudFormation template, teams can also use the AWS CLI to validate its structure:

aws cloudformation validate-template \
  --template-body file://template.yaml

The command validates the template structure. It does not replace integration testing, permission checks, change-set review, or testing against the target environment.

Use a development or test environment before applying changes to production.

What About Lambda and Step Functions Integrations?

The retirement also affects some console entry points that previously opened Infrastructure Composer.

AWS says the Export to Infrastructure Composer option will be removed from the Lambda console. Similarly, the option to export a Step Functions state machine to Infrastructure Composer will be removed from its actions menu.

These changes affect the visual editing workflow, not the underlying Lambda functions or Step Functions state machines.

If a team uses these options regularly, it should document how the corresponding infrastructure templates will be created, stored, and maintained after the console changes.

A useful approach is to maintain infrastructure definitions in source control and open those definitions through a supported editor, rather than treating a console export as the only record of an application's architecture.

Common Mistakes to Avoid During the Transition

Assuming that deployed resources will be deleted

The standalone editor is being retired, but existing CloudFormation stacks and deployments are not being removed by this announcement. Do not initiate unnecessary infrastructure recreation simply to accommodate the editor change.

Waiting until the last day

A team may discover missing templates, inaccessible credentials, or unsupported local dependencies when it first opens a project in VS Code. Test the replacement workflow before December 7, 2026, rather than waiting until the standalone console becomes unavailable.

Treating visual validation as deployment validation

A diagram can look correct while the template contains invalid properties, incorrect permissions, or unsuitable configuration values. Validate the generated template and use the existing test and deployment pipeline.

Keeping the only copy of a template in an editing session

A browser-based workflow should not be the only place where infrastructure definitions exist. Store templates in a controlled location, commit changes to version control, and maintain a known-good version for recovery.

Ignoring deployment permissions

Opening a template in VS Code does not automatically guarantee that the user has the right AWS permissions to deploy it. Verify credentials, IAM policies, account selection, and environment configuration separately.

Benefits and Limitations of Moving to VS Code

For teams already using VS Code and Git-based infrastructure workflows, the transition may be relatively straightforward. Teams that depend heavily on the standalone console should allow time to inventory projects, configure the local environment, and test their deployment process.

Summary

AWS Infrastructure Composer's standalone console will shut down on December 7, 2026, after new-customer access ends on October 29, 2026. The change affects how developers access the visual authoring tool, not the continued operation of existing CloudFormation stacks or saved templates.

The recommended path is to move visual infrastructure design to the AWS Toolkit for Visual Studio Code, preserve templates in version control, and validate the existing deployment process.

For development teams, the priority is to complete the transition before the deadline without disrupting production infrastructure. Treat the change as an editor migration: inventory projects, preserve the source of truth, test the replacement workflow, and update team documentation.