developersIO
I tried out CloudFormation's new feature, Express mode

I tried out CloudFormation's new feature, Express mode

CloudFormation Express mode has arrived. It is a new mode that allows deployments to complete without waiting for stabilization confirmation. In this article, we compared deployment times between normal mode and Express mode enabled without modifying the template, using an EC2 configuration that includes an IAM InstanceProfile.
AWS CloudFormationInfrastructure as CodeIaCAWS IAMAWS
2026.07.01

This page has been translated by machine translation. View original

Introduction

On June 30, 2026, Express mode was added to CloudFormation.

https://aws.amazon.com/jp/about-aws/whats-new/2026/06/aws-cloudformation-cdk/

Express mode is a new mode that completes deployments without waiting for stabilization checks (Eventual consistency checks). Here is a summary of the differences from normal mode.

Normal Mode Express Mode
Deployment completion timing After resource stabilization check completes After resource configuration application is confirmed
Stabilization check (Eventual consistency check) Waits until complete Deployment completes without waiting (continues in background)
Rollback Enabled by default Disabled by default
Temporary errors in dependent resources — CloudFormation automatically retries
Template changes — Not required
Additional charges — None

The official blog introduces this as "up to 4x faster."

https://aws.amazon.com/jp/blogs/aws/accelerate-your-infrastructure-deployments-by-up-to-4x-with-aws-cloudformation-express-mode/

Previously, I verified the same configuration using cdkd (a tool that deploys directly via SDK without going through CloudFormation). I confirmed that deploying an IAM Role + InstanceProfile + EC2 configuration was approximately 6.7x faster.

https://dev.classmethod.jp/articles/cdkd-deploy-6x-faster-than-cloudformation/

This article uses the same configuration to verify how much faster CloudFormation's Express mode alone can be. Rather than a direct comparison with cdkd, the focus is on the difference from CloudFormation's normal mode.

Verification

Verification Configuration

This is the same 5-resource configuration as the cdkd article.

IAM Role → IAM Policy
         → InstanceProfile → EC2 Instance ← SecurityGroup

Verification Environment

  • Region: ap-northeast-1 (Tokyo)
  • VPC: Default VPC
  • Instance type: t3.micro
  • AMI: Amazon Linux 2023 (x86_64)
  • AWS CLI: 2.35.13

CloudFormation Template

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Benchmark: IAM Role + InstanceProfile + SecurityGroup + EC2 (Express mode comparison)'

Parameters:
  VpcId:
    Type: AWS::EC2::VPC::Id
  SubnetId:
    Type: AWS::EC2::Subnet::Id
  AmiId:
    Type: AWS::EC2::Image::Id

Resources:
  BenchRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: sts:AssumeRole

  BenchPolicy:
    Type: AWS::IAM::Policy
    Properties:
      PolicyName: bench-policy
      Roles:
        - !Ref BenchRole
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Action: s3:GetObject
            Resource: '*'

  BenchInstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      Roles:
        - !Ref BenchRole

  BenchSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Benchmark security group
      VpcId: !Ref VpcId

  BenchInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro
      ImageId: !Ref AmiId
      SubnetId: !Ref SubnetId
      IamInstanceProfile: !Ref BenchInstanceProfile
      SecurityGroupIds:
        - !GetAtt BenchSecurityGroup.GroupId
      Tags:
        - Key: Name
          Value: bench-express-test

Deployment in Normal Mode

aws cloudformation create-stack \
  --stack-name bench-normal-mode \
  --template-body file://template.yaml \
  --parameters \
    ParameterKey=VpcId,ParameterValue=vpc-xxxxx \
    ParameterKey=SubnetId,ParameterValue=subnet-xxxxx \
    ParameterKey=AmiId,ParameterValue=ami-xxxxx \
  --capabilities CAPABILITY_IAM \
  --region ap-northeast-1

Result: 182 seconds (wall clock time from create-stack execution to aws cloudformation wait stack-create-complete completion)

Deployment in Express Mode

Simply add {"Mode": "EXPRESS"} to --deployment-config. No template changes are required.

aws cloudformation create-stack \
  --stack-name bench-express-mode \
  --template-body file://template.yaml \
  --parameters \
    ParameterKey=VpcId,ParameterValue=vpc-xxxxx \
    ParameterKey=SubnetId,ParameterValue=subnet-xxxxx \
    ParameterKey=AmiId,ParameterValue=ami-xxxxx \
  --capabilities CAPABILITY_IAM \
  --deployment-config '{"Mode": "EXPRESS"}' \
  --region ap-northeast-1

Result: 61 seconds (measurement method is the same as normal mode)

Deployment Time Comparison

Method Time Required Multiplier
CloudFormation Normal Mode 182 seconds 1.0x
CloudFormation Express Mode 61 seconds 3.0x

Stack Event Comparison

Let's compare stack events to see where the difference in time occurred.

Normal mode: 2 minutes 11 seconds waiting for InstanceProfile completion

It took 2 minutes 11 seconds from InstanceProfile's Resource creation Initiated to CREATE_COMPLETE.

00:46:18 | CREATE_IN_PROGRESS | AWS::IAM::InstanceProfile | Resource creation Initiated
00:48:29 | CREATE_COMPLETE    | AWS::IAM::InstanceProfile

Express mode: InstanceProfile completes in 1 second

In Express mode, InstanceProfile creation completes instantly.

00:53:01 | CREATE_IN_PROGRESS | AWS::IAM::InstanceProfile | Resource creation Initiated
00:53:02 | CREATE_COMPLETE    | AWS::IAM::InstanceProfile | Resource operation completed using Express Mode. It may continue becoming available in the background.

The following message was recorded, indicating that the deployment completed without waiting for stabilization to finish.

Resource operation completed using Express Mode. It may continue becoming available in the background.

A similar message was also recorded upon completion of the entire stack.

00:53:19 | CREATE_COMPLETE | bench-express-mode | Stack operation completed using Express Mode. Resources may continue becoming available in the background.
Full stack events for normal mode
00:45:54 | CREATE_IN_PROGRESS | bench-normal-mode   | User Initiated
00:45:59 | CREATE_IN_PROGRESS | BenchRole           |
00:45:59 | CREATE_IN_PROGRESS | BenchSecurityGroup  |
00:46:00 | CREATE_IN_PROGRESS | BenchRole           | Resource creation Initiated
00:46:01 | CREATE_IN_PROGRESS | BenchSecurityGroup  | Resource creation Initiated
00:46:02 | CREATE_IN_PROGRESS | BenchSecurityGroup  | Eventual consistency check initiated
00:46:07 | CREATE_COMPLETE    | BenchSecurityGroup  |
00:46:17 | CREATE_COMPLETE    | BenchRole           |
00:46:17 | CREATE_IN_PROGRESS | BenchInstanceProfile|
00:46:17 | CREATE_IN_PROGRESS | BenchPolicy         |
00:46:18 | CREATE_IN_PROGRESS | BenchInstanceProfile| Resource creation Initiated
00:46:18 | CREATE_IN_PROGRESS | BenchPolicy         | Resource creation Initiated
00:46:34 | CREATE_COMPLETE    | BenchPolicy         |
00:48:29 | CREATE_COMPLETE    | BenchInstanceProfile|
00:48:30 | CREATE_IN_PROGRESS | BenchInstance        |
00:48:32 | CREATE_IN_PROGRESS | BenchInstance        | Resource creation Initiated
00:48:44 | CREATE_IN_PROGRESS | BenchInstance        | Eventual consistency check initiated
00:48:44 | CREATE_COMPLETE    | BenchInstance        |
00:48:44 | CREATE_IN_PROGRESS | bench-normal-mode   | Eventual consistency check initiated
00:48:45 | CREATE_COMPLETE    | bench-normal-mode   |
Full stack events for Express mode
00:52:47 | CREATE_IN_PROGRESS | bench-express-mode  | User Initiated
00:52:52 | CREATE_IN_PROGRESS | BenchRole           |
00:52:52 | CREATE_IN_PROGRESS | BenchSecurityGroup  |
00:52:53 | CREATE_IN_PROGRESS | BenchRole           | Resource creation Initiated
00:52:54 | CREATE_IN_PROGRESS | BenchSecurityGroup  | Resource creation Initiated
00:52:54 | CREATE_IN_PROGRESS | BenchSecurityGroup  | Eventual consistency check initiated
00:52:55 | CREATE_COMPLETE    | BenchSecurityGroup  | Resource operation completed using Express Mode.
00:53:00 | CREATE_IN_PROGRESS | BenchRole           | Eventual consistency check initiated
00:53:02 | CREATE_COMPLETE    | BenchRole           | Resource operation completed using Express Mode.
00:53:00 | CREATE_IN_PROGRESS | BenchInstanceProfile|
00:53:00 | CREATE_IN_PROGRESS | BenchPolicy         |
00:53:01 | CREATE_IN_PROGRESS | BenchInstanceProfile| Resource creation Initiated
00:53:01 | CREATE_IN_PROGRESS | BenchInstanceProfile| Eventual consistency check initiated
00:53:02 | CREATE_COMPLETE    | BenchInstanceProfile| Resource operation completed using Express Mode. It may continue becoming available in the background.
00:53:02 | CREATE_IN_PROGRESS | BenchPolicy         | Resource creation Initiated
00:53:02 | CREATE_IN_PROGRESS | BenchPolicy         | Eventual consistency check initiated
00:53:02 | CREATE_COMPLETE    | BenchPolicy         | Resource operation completed using Express Mode.
00:53:02 | CREATE_IN_PROGRESS | BenchInstance        |
00:53:12 | CREATE_IN_PROGRESS | BenchInstance        | Resource creation Initiated
00:53:17 | CREATE_IN_PROGRESS | BenchInstance        | Eventual consistency check initiated
00:53:18 | CREATE_COMPLETE    | BenchInstance        | Resource operation completed using Express Mode.
00:53:17 | CREATE_IN_PROGRESS | bench-express-mode  | Eventual consistency check initiated
00:53:19 | CREATE_COMPLETE    | bench-express-mode  | Stack operation completed using Express Mode. Resources may continue becoming available in the background.

Of the 182 seconds in normal mode, waiting for InstanceProfile completion alone accounted for 2 minutes 11 seconds = 131 seconds (72% of the total).
In Express mode, this wait does not block the deployment, so the entire process completed in 61 seconds.

Notes

Here are things to know when using Express mode.

  • The --deployment-config option was added in AWS CLI 2.35.13 (released June 30, 2026). This option cannot be used with earlier versions
  • Rollback is disabled by default. On one hand, failures can be immediately fixed and retried, but on the other hand, resources in an incomplete state may remain. For production environments, consider specifying an option to enable rollback
  • Resources continue to stabilize in the background. Resources may not be fully available immediately after deployment completes. Normal mode is more appropriate for cases where you need to wait for stabilization before routing traffic
  • CloudFormation is said to retry temporary errors in dependent resources. Some timing-related errors, such as waiting for IAM propagation, may resolve without additional intervention
  • In CDK, it is planned to be enabled with cdk deploy --express (corresponding PR). As it was unreleased at the time of writing, this verification was conducted using only the CloudFormation API (AWS CLI)

https://dev.classmethod.jp/articles/dk-express-mode-deploy-time/

Summary

I verified CloudFormation Express mode using an IAM Role + InstanceProfile + EC2 configuration.
The deployment time was reduced from 182 seconds to 61 seconds, approximately 3.0x faster.

The main factor in the reduction was the 131 seconds that normal mode spent waiting for InstanceProfile completion. In Express mode, deployment completes without waiting for stabilization to finish, so this wait time no longer blocks the overall completion time.

No template changes were needed for this template, and it could be used simply by adding --deployment-config '{"Mode": "EXPRESS"}'. While it's important to be aware that stabilization continues in the background, this appears to be an effective time-saving measure for scenarios involving repeated deployments in development environments.

With Pre-deployment Validation announced on the same day, errors can now be detected before provisioning in CreateStack / UpdateStack as well. Especially in Express mode where rollback is disabled by default, the peace of mind from being able to catch errors before deployment becomes even greater. Details are verified in the following article.

https://dev.classmethod.jp/articles/cloudformation-cdk-pre-deployment-validation-all-stack-operations/

Share this article

AWSのお困り事はクラスメソッドへ