Using Amazon Q Developer to Write CloudFormation

TL;DR

Amazon Q Developer can speed up CloudFormation work for boilerplate resources and parameterizing existing templates. It struggles with recently launched services and tends toward overly permissive IAM. Treat its output like a junior engineer’s PR: useful starting point, requires review.

Where Q Developer fits in our IaC workflow

We’ve been writing AWS CloudFormation for years across our marketplace patterns and client engagements. When Amazon Q Developer became generally available, we started experimenting with it for the repetitive parts of CloudFormation work: standing up new resources, parameterizing values, and translating existing templates into slightly different shapes.

This post walks through what we found.

Setup

Q Developer runs as an IDE plugin (we use it with VS Code and JetBrains) and as a CLI. For CloudFormation work we generally use the IDE integration since the chat context can reference open files.

You’ll need an AWS Builder ID or an IAM Identity Center user with Q Developer access. The free tier is enough to start experimenting.

Scaffolding a new resource

A common task: you have a CloudFormation template defining a VPC and an ECS cluster, and you need to add a parameterized Aurora PostgreSQL cluster.

Ask Q something like:

Add a parameterized Aurora PostgreSQL cluster to this template. Use the existing VPC subnets. Encrypt at rest. Default to db.r6g.large but allow override via parameter.

The output is mostly correct: the cluster, instances, parameter group, security group references, and parameters all look reasonable. But two things to watch for:

1. EngineVersion drift. Q tends to suggest engine versions that were current several months ago. Always check against the AWS docs for the latest available version before merging.
2. Security group rules. It will often produce overly broad ingress. We tighten this manually.

What it gets wrong

We hit consistent issues with:

• Recently launched services or features. Anything announced in the last six to twelve months. Q tends to either hallucinate property names or default to a previous-generation equivalent.
• IAM scoping. Asked to add an IAM role, Q reaches for * resources and broad action lists. We always ask it to scope down before accepting the output.
• Custom resource types. Property structures for newer resource types sometimes aren’t in Q’s training, and the suggestions look plausible but won’t validate.

How we’ve integrated it

Our team has settled on this loop:

1. Engineer drafts the change with Q.
2. Engineer reviews and tightens the output, paying particular attention to IAM.
3. PR goes through normal review with cfn-lint and cfn-nag in CI.
4. We tag PRs that used Q assistance so reviewers know to look closely at IAM.

The productivity gain on routine work is real, maybe a third faster on greenfield CloudFormation. On our marketplace pattern templates where the conventions are unusual, the gain is smaller.

What’s next

Q Developer’s agentic features will likely change this calculus. Agents that can iteratively run cfn-lint, fix issues, and re-validate sound much more useful than a one-shot completion. We expect to write about that in a future post.

If you’re just getting started with Q for IaC, our suggestion: try it on a boring task first. Add a tagged S3 bucket to an existing template. See what it produces. Get a feel for what to trust.