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:
Date | Change |
|---|
October 12, 2026 | Current planning date for teams preparing their transition |
October 29, 2026 | Standalone console stops accepting new customers |
December 7, 2026 | Standalone console shuts down and is no longer accessible |
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
Area | Benefit | Consideration |
|---|
Development workflow | Visual design remains available in the IDE | Developers need a working VS Code and Toolkit setup |
Infrastructure code | Templates can be maintained alongside application code | Teams must manage version control and review practices |
Deployment | Existing CloudFormation and SAM workflows can remain in place | Validate templates and test deployments independently |
Collaboration | Source-controlled templates make changes easier to review | Teams need clear ownership and branching practices |
Long-term maintenance | Infrastructure definitions are not tied to one browser console | Tooling and credentials still require maintenance |
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.
Join the conversation! Your thoughts help the community grow.