Every time a server configuration changes, a specific engineer manually clicks through the management console. The procedure exists only in their head, and others are too terrified to touch it. Every change takes time, and before anyone realizes it, the company has fallen into an "if that person leaves, nobody understands it" state. Even when using the cloud, teams unable to break free from this dependency on individuals and manual operations are surprisingly common.
In July 2026, AWS introduced a new capability targeting this "infrastructure provisioning wait time" directly: CloudFormation Express mode. Yet this is about more than just a speed-up tool. As the prerequisites for managing infrastructure with code (Infrastructure as Code, or IaC) fall into place, the next question that arises is a commissioning decision: should we keep writing that code in-house, or outsource it to an external partner? This article details the specifics of the announcement and outlines those decision criteria from a client's perspective.
What CloudFormation Express mode actually accelerates
First, let us establish the facts accurately. CloudFormation is AWS's native IaC service for defining infrastructure on AWS (servers, databases, networks, etc.) using templates (code) rather than manual processes, allowing resources to be created, modified, and deleted in batches. Express mode is a new operational mode added to shorten the time required for deployments (applying changes).
While AWS claims it is "up to 4x faster," this represents a maximum value based on the company's internal benchmarks and does not mean deployments will uniformly be four times faster for every configuration. The acceleration mechanism works as follows. Traditional mode waits after applying resource configurations until they are completely stabilized. For example, CloudFront distribution settings take several minutes to propagate to edge locations worldwide, and deployment was only marked complete after waiting for that propagation. Express mode treats deployment as complete once configuration application is confirmed, moving wait times for stabilization checks—such as propagation, traffic readiness, and cleanup—to the background, significantly slashing perceived wait time.
Consequently, the impact is greatest on resources with lengthy stabilization waits. Reports and benchmark articles highlight cases where a configuration combining CloudFront and S3 dropped from roughly 4 minutes 3 seconds in traditional mode to about 1 minute 2 seconds in Express mode, creating an SQS queue with a dead-letter queue went from over a minute to under 10 seconds, and deleting a Lambda function with remaining network interfaces went from 20–30 minutes down to seconds. Conversely, for resources that inherently have short stabilization waits, the difference is minor.
There is another critical specification that directly impacts outsourcing and operational decisions. Express mode disables rollback (automatic reversion on failure) by default. While designed to speed up the "fix and re-run immediately on failure" cycle, this conversely presupposes that operational teams take responsibility for post-failure cleanup. To use it, simply specify the mode in deployment settings via the AWS CLI, SDK, or Management Console, or append cdk deploy --express when using AWS CDK. It works out of the box with existing templates and nested stacks, with no additional charge across all commercial regions.
| Dimension | Traditional mode | Express mode |
|---|---|---|
| Completion criteria | Waits for stabilization | Completes upon confirming configuration application; stabilization continues |
| Where effects are most noticeable | ― | Resources with lengthy stabilization waits |
| Rollback | Enabled by default | Disabled by default (no rollback, in exchange for faster re-execution) |
| Additional fees | ― | None (all commercial regions) |
What changes for clients when managing infrastructure with IaC
Express mode is effective only because infrastructure is defined in code in the first place. This is the crux for commissioning teams. Replacing manual console operations with IaC transforms how infrastructure itself is handled, long before shortening wait times.
First, dependency on specific individuals is broken. Because configurations remain in repositories as templates, teams shift from a state where "only that one person can touch it" to one where "anyone can understand the setup by reading the code." Second, changes pass through records and reviews. A history of who changed what and why is preserved, allowing review prior to production release. Third, identical environments can be reproduced. Staging and production can be created from the exact same code, reducing incidents where "it worked in staging but behaves differently in production."
For the commissioning side, this delivers values like transferability, auditability, and resilience against downtime before "speed and cost." While shortening deployment lead time itself is detailed separately in Designing for Shorter Deployment Lead Times, acceleration tools like Express mode only function safely once this IaC foundation is established. Adding speed without a solid foundation when rollbacks are disabled risks doing nothing more than spreading failures faster.
At the same time, IaC carries operational overhead. Factoring in tool selection (CloudFormation / CDK / Terraform / OpenTofu, etc.), template design, state management, and permission and governance architectures, treating it as an afterthought and abandoning it turns it into technical debt. Selecting and standardizing tools is covered in Decision Framework for IaC Standardization, and setting up organizational controls is examined in Designing IaC Governance. This is where the commissioning decision comes into play.
How to decide between in-house and outsourcing
"Should we build and operate an IaC foundation with our own engineers, or entrust it to an external partner?" There is no one-size-fits-all answer. The decision becomes much easier to navigate when broken down across four dimensions: objective, frequency, talent, and risk.
| Decision criteria | Cases suited for in-house | Cases suited for outsourcing (custom development) |
|---|---|---|
| Frequency and strategic importance of changes | Infrastructure changes are routine and directly tied to business competitiveness | Changes are irregular, and the primary goal is establishing a stable foundation |
| Internal talent and team structure | Multiple engineers capable of continuously maintaining IaC | No dedicated personnel, or dependent on a single individual |
| Speed of launch | Desire to build up internal capabilities over time | Need to set up a secure foundation quickly and refine it on the go |
| Risk tolerance during incidents | In-house structure and procedures for incident response are in place | Desire to fortify defenses during design and proceed on a handover basis |
In reality, rather than choosing "entirely in-house" or "entirely outsourced," the majority adopt a hybrid combination. A common pattern is to outsource setup and standardization design, hand over templates and operating procedures internally, and then handle routine changes in-house. Safely leveraging features like Express mode—which disables rollbacks by default—requires operational planning beforehand for "who reverts what, and how, in the event of failure." Introducing speed while leaving this ambiguous is the single biggest pitfall to avoid in commissioning decisions.
When considering outsourcing, what matters more than a cheap price sheet is whether deliverables are handed over in a transferable format. Do templates and documentation remain company assets, and can operations continue even if the vendor steps away? Verifying this prior to contracting prevents a second wave of individual dependency where "it was built for us, but no one can touch it." When we support infrastructure setup or IaC adoption at GleamHub, architectures vary widely by requirements, so we do not offer fixed pricing packages; we provide tailored quotes after reviewing your needs (Contact Us).
Next steps to take
CloudFormation Express mode provides strong momentum for turning infrastructure from "something to wait on" into "something managed quickly and safely." However, its benefits can only be securely realized on a foundation where infrastructure is managed as code and rollback procedures for failures are engineered in advance. Speed is not the goal; it is the finishing touch placed on an auditable, transferable foundation.
As a next step, begin by taking stock of how much your infrastructure changes currently rely on manual operations. If areas remain that only a specific person can touch, that is your starting point for adopting IaC. From there, decide whether to cultivate in-house expertise or enlist external help to build the foundation, weighing change frequency against your team's reality. If you are uncertain about establishing infrastructure or automation workflows, reach out via Development, AI, and Automation Consultation to sort through your current setup together.
Sources
- Accelerate Infrastructure Deployments up to 4x Using AWS CloudFormation Express Mode | Amazon Web Services Blog
- AWS CloudFormation and CDK express mode speeds up infrastructure deployments by up to 4x | AWS What’s New
- AWS Launches "AWS CloudFormation Express Mode," Boosting Deployment Speed up to 4x | Publickey
- AWS Launches "AWS CloudFormation Express Mode," Boosting Deployment Speed up to 4x | ITmedia NEWS
