AWS Infrastructure as Code: CloudFormation and CDK

For enterprise teams, infrastructure as code (IaC) on AWS usually means AWS CloudFormation, which turns a template into a stack of running resources, and the AWS Cloud Development Kit (CDK), which generates those templates from ordinary programming languages. This guide covers the operating questions a CTO or platform lead needs answered: how to change infrastructure safely, how to scale it across accounts, how to bring existing resources under code, and what has been retired since the first version of this post.

It takes a different angle from our general guide to infrastructure as code principles and benefits and our GCP infrastructure as code guide. Here the focus is AWS only: the tool choice, the safety controls and the governance model. For a wider tool comparison, see how to choose an IaC tool.

Which IaC tool should you use on AWS?

The honest answer depends on who writes the infrastructure and whether you run more than one cloud. The table sets out the options we see most often.

Many enterprises end up with CloudFormation or CDK for AWS-native landing zones and Terraform where teams already own it. The sensible rule is one tool per layer, with a named owner, rather than a free choice per team.

What has changed since the first CloudFormation guide?

How does AWS CloudFormation work?

You describe resources and their properties in a template, and CloudFormation provisions and configures them as a stack, managing the collection as a single unit. Deleting the stack deletes the resources in it. Templates are text, so you can keep them in version control and see what changed, who changed it and when, and you can revert to an earlier template version if needed. You create stacks through the console, API, AWS CLI or SDKs.

CloudFormation can only do what the permissions in play allow. To create an S3 bucket through a template, the caller needs permission to create buckets, and the same applies to deleting one. Access is controlled through AWS Identity and Access Management (IAM), which makes permissions the first governance control.

How do you change AWS infrastructure safely?

Three CloudFormation controls cover most of the risk. Used together they replace the old habit of editing in the console and hoping.

Make the change set review a required step in your pipeline for production stacks, and schedule drift checks so that console edits surface as findings, not surprises.

How do you scale IaC across accounts and existing resources?

Multiple accounts and Regions

StackSets let you create, update or delete stacks across multiple AWS accounts and Regions in one operation, from a single template defined in an administrator account. This is the usual route for baseline controls that every account must carry.

Resources that already exist

The IaC generator scans resources in your account that CloudFormation does not manage and generates a template, which you can import as a stack or migrate into a CDK app. It supports only resources that Cloud Control API supports in your Region, the scan expires after 30 days, and it only sees resources you have permission to read. That makes it a starting point for review, not a finished estate.

Source control as the control plane

With Git sync, CloudFormation monitors a repository for a template file and a stack deployment file, and updates the stack when you commit. If you use pull requests, it can comment on the pull request with the planned changes once you enable that feature. GitHub, GitHub Enterprise, GitLab, Bitbucket and GitLab self-managed are supported.

When should you use CDK instead of raw templates?

CDK is an open-source framework that provisions through CloudFormation, so you keep rollback and change sets. AWS notes that one short TypeScript class defining a VPC, an ECS cluster and a load-balanced Fargate service produces a CloudFormation template of more than 500 lines. If your engineers write that much YAML by hand, CDK is worth the move. If your team is mostly operations and the estate is small, plain templates are easier to audit. Either way, review the generated template before deployment.

What do governance, security and cost look like?

• Permissions: separate who can author templates from who can execute change sets in production. Drift detection also needs read permission for each supported resource and specific CloudFormation actions.
• Audit trail: version-controlled templates record what changed, who changed it and when. Add pull request review before Git sync applies a change.
• Operations layer: AWS Systems Manager gives a central view of nodes and can manage them without bastion hosts or SSH. Treat its documents and runbooks as code in the same repository.
• Cost: the benefit is mainly avoided rework and faster, repeatable environments. We do not quote savings figures here because none are published for CloudFormation itself.
• Agent actions: if AI agents will change infrastructure, ElixirData Context OS keeps governed context, versioned policy and decision traces in one decision layer above AI agents, and AgentGRC keeps autonomous agent actions inside policy, with the audit trail risk teams need.

What is a sensible adoption sequence?

1. Inventory the AWS accounts and tag what is managed by code and what is not.
2. Choose one tool per layer and name an owner for each.
3. Put templates in a repository, with pull request review and change set preview in the pipeline. Our AWS DevOps pipeline guide and AWS DevOps tools list cover the surrounding services.
4. Add rollback triggers for production stacks that have meaningful CloudWatch alarms.
5. Run drift detection on a schedule and treat findings as incidents.
6. Use StackSets for account baselines, then use the IaC generator to bring unmanaged resources under code.

What are the trade-offs, and when should you not use CloudFormation?

• CloudFormation works only for AWS resources. Estates that span clouds may prefer Terraform for consistency, at the cost of managing state yourself.
• Drift detection is not complete. It skips unsupported resources and some properties, so it does not replace access control.
• CDK adds a build and language dependency. Small teams with simple stacks may not need it.
• Change sets reduce risk but do not remove it.
• Do not start new work on OpsWorks.

To map one infrastructure decision your agents should make, and the context and policy it depends on, book a Context Workshop. See what happens in the workshop.

Frequently asked questions

What is infrastructure as code on AWS?

It is the practice of describing AWS resources in templates or code so that CloudFormation provisions them the same way each time. Templates can be versioned, reviewed and reused across Regions.

What is the difference between CloudFormation and CDK?

CloudFormation takes JSON or YAML templates. CDK lets you define infrastructure in TypeScript, JavaScript, Python, Java, C# or Go and deploys it through CloudFormation.

How do I preview a CloudFormation change?

Create a change set. It shows which resources will be added, modified or deleted and changes nothing until you execute it. It does not guarantee the update will succeed.

What does drift detection do?

It compares a stack's actual configuration with its template and reports resources that differ. It checks only explicitly set properties and supported resources.

Can I bring existing AWS resources under CloudFormation?

Yes. The IaC generator scans unmanaged resources and creates a template you can import as a stack or migrate into a CDK app, subject to the resource types Cloud Control API supports.

Is AWS OpsWorks still available?

No. OpsWorks Stacks, OpsWorks for Chef Automate and OpsWorks for Puppet Enterprise have reached end of life and are disabled for new and existing customers.