Skip to main content
Cloud DevOps Solutions
Get a quote Talk to an engineer

Infrastructure as code

AWS CloudFormation Consulting for Reliable, Auditable AWS Deployments

AWS CloudFormation is Amazon's native infrastructure as code service: you describe resources in JSON or YAML templates and AWS creates, updates and rolls back stacks for you. We design stack boundaries, StackSets, change-set review and pipelines so AWS-only teams deploy safely, and we advise honestly when another tool fits better.

Key takeaways

  • CloudFormation is managed by AWS, so there is no state file or backend for you to secure and operate.
  • Stack boundaries, cross-stack references and deletion policies decide how safe your deployments are.
  • Change sets give a reviewable preview, and automatic rollback protects most failed updates.
  • It only manages AWS (and registered extensions), so multi-cloud estates need another approach.
  • Plain YAML templates become hard to maintain at scale, which is where CDK, modules or another tool come in.

What teams use AWS CloudFormation for

Multi-account landing zones

StackSets and service-managed permissions roll baseline roles, logging and guardrails across an AWS Organization.

Application stacks owned by one team

Networking, compute and data for a single service in a stack that moves with its code and pipeline.

Service Catalog and self-service

Approved templates teams can launch without holding broad IAM permissions.

Guardrails and compliance baselines

Account-level controls deployed consistently, with drift detection to confirm they have not been altered.

Stage-by-stage migration to another tool

Retaining and gradually retiring existing stacks while new work moves to Terraform or CDK.

What CloudFormation is and why AWS-only teams choose it

CloudFormation is the infrastructure as code service built into AWS. You write a template, submit it, and AWS builds a stack: it works out resource ordering, creates what is missing, updates what changed and attempts to roll back if something fails. You do not host a backend, manage a lock or secure a state bucket, because AWS holds that state for you.

For a team that runs only on AWS, that is a real benefit. New AWS features are often available through CloudFormation quickly, deployments are visible in the console and events log, and IAM can control exactly who may create or update stacks. Many AWS services, including CDK and SAM, compile down to CloudFormation, so understanding it helps even if you never write raw templates.

We cover AWS infrastructure delivery through our Terraform and infrastructure as code service, and we advise CloudFormation where it is the right answer.

Designing stacks that stay safe

Stack boundaries

The most consequential decision is what goes in which stack. A single stack containing a VPC, a database and an application means one update can touch everything, and a failed rollback leaves a large mess. We group resources by lifecycle and owner: network foundations, stateful data, then application layers that change often. Nested stacks and cross-stack exports can connect them, but exports create hard dependencies that block changes to the exporting stack, so we use them selectively and often prefer parameters or Systems Manager parameter lookups for loose coupling.

Change sets and replacement

Never update a production stack blind. A change set shows which resources will be added, modified or replaced. Replacement is the dangerous word: a property change on a database or encrypted volume can mean a new resource and a deleted old one. We read every change set for replacement and decide deliberately whether it is acceptable.

Protecting stateful resources

Use DeletionPolicy: Retain or Snapshot and UpdateReplacePolicy on databases, buckets and keys, enable termination protection on critical stacks, and apply stack policies to stop updates to named resources. These are cheap controls that prevent the worst outcomes.

Resources:
  DataBucket:
    Type: AWS::S3::Bucket
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      VersioningConfiguration:
        Status: Enabled
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: aws:kms
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

Multi-account rollout with StackSets

Where you manage many accounts, StackSets deploy one template to many accounts and regions. With AWS Organizations and service-managed permissions, new accounts can receive baseline roles, logging and guardrails automatically. We configure failure tolerance and maximum concurrency so a bad template stops early rather than spreading, and we test against a small organisational unit first.

StackSets add their own concerns: operations can be slow across many regions, and per-account customisation takes planning. For simple needs, a pipeline that deploys the same stack into each account may be easier to reason about.

Security and access

Pipelines should assume a dedicated CloudFormation service role with only the permissions the templates need, rather than running as an administrator. That keeps a compromised pipeline from having broad reach and lets you review permissions as a single artefact. Combine this with:

  • Linting with cfn-lint and policy-as-code checks such as cfn-guard before deployment.
  • Parameters that reference Secrets Manager or Systems Manager rather than literal values; avoid putting secrets in NoEcho parameters and treating that as protection.
  • CloudTrail for an audit record of stack operations.
  • Short-lived federated credentials for the CI system.

Cost and capacity

CloudFormation itself carries no charge for standard AWS resource types. Costs come from the resources you create and, for some third-party or extension types, handler operations. The practical cost to manage is human: large raw YAML templates are tedious, and teams often hit stack resource limits or struggle with Fn:: intrinsic functions. Tagging through stack-level tags, plus budgets by tag, gives cost visibility. We avoid quoting savings, since they depend on what is deployed.

Day-2 operations

Drift and rollback

Run drift detection on a schedule for critical stacks, and investigate differences rather than overwriting them. Learn the failure states: UPDATE_ROLLBACK_FAILED happens when AWS cannot restore a previous state, usually because someone changed a dependent resource out of band. Knowing how to continue a rollback and skip resources safely is part of our runbooks.

Template evolution

Templates drift in quality over time. We add automated checks, split oversized templates, retire unused parameters and move repeated patterns into modules or the CDK where a team prefers code. The reasoning on choosing between them is in our note on Pulumi.

Common failure modes

  • Monolithic stacks. Slow updates and a wide blast radius.
  • Export lock-in. An exported value cannot be changed while another stack imports it.
  • Surprise replacement. An unreviewed change replaces a stateful resource.
  • Custom resources without error handling. A Lambda-backed resource that never signals success hangs a stack for a long time.
  • Out-of-band edits. Console changes cause failed updates and rollbacks.

When CloudFormation is the wrong choice

If you operate on multiple clouds or manage SaaS providers alongside AWS, Terraform offers one workflow for all of it. If your team dislikes writing long YAML and wants real programming constructs, consider CDK or Pulumi. If you need to configure software on servers, use Ansible.

If you already have CloudFormation in production and want out, we work stack by stack using our CloudFormation to Terraform migration approach, with no resource recreated along the way. You can contact us to scope it.

Official documentation: docs.aws.amazon.com/cloudformation

How we work with AWS CloudFormation

  1. 01

    Review existing templates

    We map your stacks, dependencies, parameters and deletion behaviour, and flag anything that could cause a replacement.

  2. 02

    Define stack boundaries

    Resources are grouped by lifecycle and ownership, with stateful items separated from stateless ones.

  3. 03

    Standardise templates

    Parameters, tagging, naming and conditions are made consistent, with linting and policy checks in CI.

  4. 04

    Build the deployment pipeline

    Pull requests create change sets for review, and approved merges execute them using a dedicated deployment role.

  5. 05

    Add multi-account rollout

    StackSets distribute shared baselines with controlled regional and account ordering.

  6. 06

    Operate and migrate if needed

    Drift checks, stack policies and runbooks are added, or a staged move to Terraform begins if your needs have changed.

AWS CloudFormation compared with the alternatives

We recommend the tool that fits your team, not the one we know best. Here is when each option makes sense.

OptionChoose it when
AWS CloudFormationAWS CloudFormation is Amazon's native infrastructure as code service: you describe resources in JSON or YAML templates and AWS creates, updates and rolls back stacks for you.
TerraformChoose it for multi-cloud, a large provider ecosystem, or a plan workflow your team already knows. You take on state storage and locking.
AWS CDKChoose it if you want to write AWS infrastructure in TypeScript, Python or similar while still deploying through CloudFormation.
PulumiChoose it for general-purpose languages across several clouds, with its own state backend and a different operating model.
TerragruntChoose it only as a Terraform or OpenTofu wrapper to reduce repetition across many environments, not as an AWS-native option.

Tools we use alongside AWS CloudFormation

AWS CDKAWS SAMcfn-lintcfn-guardAWS Service CatalogAWS OrganizationsAWS CodePipelineGitHub ActionsAWS ConfigRainFormer2Terraform

Frequently asked questions

What is AWS CloudFormation used for?
CloudFormation is used to define AWS resources in YAML or JSON templates and deploy them as stacks. AWS handles ordering, creation, updates and rollback. It is common for repeatable environments, multi-account baselines through StackSets, and as the engine beneath AWS CDK and SAM.
CloudFormation or Terraform: which is better?
Neither is universally better. CloudFormation suits AWS-only teams who want AWS to manage deployment state and new service support through the service itself. Terraform suits multi-cloud work and teams that value its ecosystem and plan output. The decision turns on your platform footprint and skills.
Does CloudFormation have state?
AWS stores stack state for you, so you do not manage a state file, bucket or lock. That removes operational overhead and a class of state-corruption risk. The trade-off is less direct control over that state and fewer ways to restructure it.
How do you stop a CloudFormation update deleting data?
We use deletion and update-replace policies on stateful resources, termination protection on stacks, stack policies for critical resources, and always review a change set before executing. Where a property change would cause replacement, we plan a safe migration first.
What is CloudFormation drift detection?
Drift detection compares the live configuration of stack resources with the template and reports differences. It does not fix them. We run it regularly, treat results as an incident to reconcile, and note that not every resource type and property is supported.
Can you migrate CloudFormation stacks to Terraform?
Yes. We import existing resources into Terraform, confirm that a plan shows no changes, and then remove them from the stack with a retain policy so nothing is deleted. It is done stack by stack. See our dedicated migration guide for the full sequence.

Talk to an engineer about AWS CloudFormation

Book a free 30-minute call. We review your current setup and tell you honestly whether and how we can help.

Written by Saddique Khan, DevOps / SRE / Cloud Consultant Engineer. Last updated 2026-10-09.