A living diagram from CloudFormation: regenerate the stack view after every deploy, nested stacks included

aws cloudformation get-template returns what you asked for: the template body as deployed, useful when the original file lives in a repo you cannot see from the pipeline. aws cloudformation describe-stack-resources returns what exists: every resource with its logical ID, resource type, physical ID, and status. The first is the design, the second is the inventory, and a diagram worth embedding in a wiki draws from both: types and relationships from the template, existence from the resource list.

For the one-off "turn this template into a picture" need, paste the template into the CloudFormation diagram generator; Datadef's AI import reads infrastructure-as-code text directly. This page is for the second deploy onward, when the picture has to keep up.

aws cloudformation get-template --stack-name data-platform \
  --query TemplateBody > template.json

aws cloudformation describe-stack-resources --stack-name data-platform \
  --query "StackResources[].{Type:ResourceType,Id:PhysicalResourceId}"

# Nested stacks to traverse: their physical ID is the child stack
aws cloudformation describe-stack-resources --stack-name data-platform \
  --query "StackResources[?ResourceType=='AWS::CloudFormation::Stack'].PhysicalResourceId"

In any CloudFormation setup past a certain size, the parent stack is mostly a list of AWS::CloudFormation::Stack resources, and the real infrastructure lives one level down. A diagram built from the parent alone shows three boxes and none of the system. The traversal is mechanical: each nested stack resource's physical ID is the child stack, so you call describe-stack-resources again per child, recursively.

The nesting also solves the layout question. Each nested stack becomes a zone in the diagram, network, compute, data, and cross-stack references, the Outputs one stack exports and another imports, become the edges between zones. That mirrors how the team actually thinks about the system, which is what makes the diagram readable instead of exhaustive.

One template is many possible stacks. Parameters and Conditions mean the same YAML deploys differently per environment, so a diagram generated from the file alone shows a superposition, not a system. Generating from describe-stack-resources on a named stack pins the diagram to one account, one region, one set of parameter values, which is what a reader of the wiki assumes anyway.

CloudFormation also knows when reality has drifted from the template: aws cloudformation detect-stack-drift plus describe-stack-resource-drifts reports resources modified outside the stack. A diagram regenerated from the resource list after a drift check is honest about the system as it runs, not as it was declared.

The loop belongs where the deploy already happens. After the pipeline stage that runs the deploy, CodePipeline, GitHub Actions, whatever drives it, add one step that pulls the resource list and asks an agent connected to Datadef's MCP server (registry io.datadef/mcp) to update the stack diagram: new resources in, deleted ones out, nested-stack zones preserved. The agent connection needs an API key, available on paid plans, and the MCP diagram server guide walks through it.

Stated plainly, because it matters: Datadef does not watch your AWS account or your repo. No deploy is detected automatically. The regeneration is one CLI-driven agent call in the pipeline, which for a team already running CloudFormation through CI is a five line addition.

Once the diagram lives at a public URL, the wiki side is passive: the embed image refreshes within minutes of any diagram change, so the page showing your stack never needs re-pasting. Teams documenting a whole platform on AWS usually pair this with a hand-curated overview like the one in the AWS data platform diagram guide.

The console can already visualize a single template, and for inspecting one file during authoring that is genuinely convenient. What it does not give you is a curated, embeddable view that spans nested stacks and survives in a wiki, which is the job here.

The embed requires the Datadef project to be shared public; a private project's embed URL returns 404, so stacks whose shape is itself confidential need an exported image instead, staleness accepted. And the loop redraws the architecture view only: it does not maintain runbooks, parameter documentation, or the prose around the diagram.

• CloudFormation diagram generator
• A living diagram from AWS CDK
• A living diagram from Terraform
• The MCP diagram server
• AWS data platform diagram