---
title: "How AWS CloudFormation Turns a Template Into a Reconciled Stack"
description: "CloudFormation is a declarative reconciler: you describe the target state in a template, and it provisions, updates, and reports on the stack that results. Here is the loop."
---

# How AWS CloudFormation Turns a Template Into a Reconciled Stack

**Type:** [How it works](https://yomu.fyi/visual-explainers/category/how-it-works.md)

![A five-stage left-to-right flow diagram showing how AWS CloudFormation moves from a declarative template to a tracked stack, applies a change, verifies actual state against intent, and loops back to reconcile, with a feedback rail beneath the stages.](https://yomufyi.s3.us-east-1.amazonaws.com/visual-explainers/03de5b0d-b1ef-4bca-bf0b-af12ec5d72e9/image-ae85d22f-4c81-4cfb-95db-35b5cde5e398.webp)

> CloudFormation is a declarative reconciler: you describe the target state in a template, and it provisions, updates, and reports on the stack that results. Here is the loop.

## Explanation

CloudFormation is AWS's declarative infrastructure tool: you write the target state of your resources in a template, and it creates and tracks them as a stack. Because the stack owns each resource, you can attribute resource types back to the stack that deployed them and see which property configurations are actually in use. The useful mental model is a loop, not a one-shot script: declare intent, apply a change, then verify the real state against the template and reconcile any gap. That loop is what makes template-driven deployment repeatable and auditable, and it is the same pattern behind code-first configuration and agent-driven provisioning elsewhere.

## FAQ

### Why does CloudFormation track resources as a stack instead of running scripts?

A stack gives every resource an owner. Because CloudFormation records which stack deployed each resource type and which property configurations are in use, you can scope analysis and updates to real deployed resources instead of guessing from a script's side effects.

### How do I know a CloudFormation update actually landed?

Check the resulting state, not the success message. In the ThinkingBox benchmark, 67.24% of failed attempts still terminated cleanly and called a state-changing tool without error, with wrong field values in 77.61% of those cases. Treat verification against the template as its own step.

### Can coding agents write and change CloudFormation templates?

They can, if the template stays the source of truth. Supabase's code-first approach lets agents edit declarative files while a migration tool generates the changes, and config can be pulled back from the live system. The same pattern works for templates kept in version control.

**Tags:** [AWS](https://yomu.fyi/topic/aws.md), [AWS CloudFormation](https://yomu.fyi/topic/cloudformation.md), [Configuration Management](https://yomu.fyi/topic/configuration-management.md), [Deployment](https://yomu.fyi/topic/deployment.md), [GitOps](https://yomu.fyi/topic/gitops.md), [YAML](https://yomu.fyi/topic/yaml.md)

## Related reading

### [The Agent Said It Was Done. The Database Disagreed.](https://yomu.fyi/post/the-agent-said-it-was-done-the-database-disagreed.md)
- Company: [Hugging Face](https://yomu.fyi/company/hugging-face.md)
- Author: Tuhin Kundu
- Published: Oct 3, 2026
- Type: Benchmark

ThinkingBox, a benchmark from Microsoft and Hugging Face, grades AI agents on the database state and side effects they leave behind rather than on tool calls or final responses. In a common-set ablation covering 121,680 valid trials across 12 LLM models, 79,853 attempts failed executable checks, and 67.24% of those failures still terminated cleanly and invoked a state-changing tool without error, with wrong field values in 77.61% of them. The benchmark runs every task 20 independent times from identical clean backends, reporting pass@1, pass@20, and observed 20/20 consistency to separate capability from reliability. For example, Kimi-K3 solved 93.89% of tasks at least once but only 13.41% consistently, while Claude Opus 5 completed 47.53% of tasks on every attempt, and Claude Opus 5.5 gained no additional dependability over its predecessor despite higher pass@1. ThinkingBox is available through Hugging Face’s OpenEnv with MIT-licensed code and CDLA-Permissive-2.0 benchmark data.


### [Deploy Oracle Database step by step on Amazon EVS with FSx for ONTAP](https://yomu.fyi/post/deploy-oracle-database-step-by-step-on-amazon-evs-with-fsx-for-ontap.md)
- Company: [AWS](https://yomu.fyi/company/aws.md)
- Author: Satish Bhoi
- Published: Oct 2, 2026
- Type: Tutorial

This post provides step-by-step procedures to deploy Oracle Database on Amazon Elastic VMware Service (Amazon EVS) with Amazon FSx for NetApp ONTAP as NFS datastore storage. It covers provisioning storage volumes, mounting NFS datastores, installing Oracle 19c, and configuring SnapMirror replication for cross-region disaster recovery. The deployment uses FSx for ONTAP volumes pinned to SSD tier and presents them as VMDKs on NFS datastores, with Oracle accessing them as local XFS filesystems. Four migration paths are detailed for moving on-premises Oracle workloads, including SnapMirror-based replication for existing ONTAP environments and RMAN backup/restore for non-ONTAP storage. Day-2 operations such as snapshot backup, point-in-time recovery, and database cloning via SnapCenter FlexClone are also covered.


### [Deploy open source Regional availability tools in your VPC](https://yomu.fyi/post/deploy-open-source-regional-availability-tools-in-your-vpc.md)
- Company: [AWS](https://yomu.fyi/company/aws.md)
- Author: Stefan Janjic
- Published: Oct 2, 2026
- Type: Tutorial

Teams building multi-Region architectures on AWS need to know which services are available per Region, but want that data deployed inside their VPC under their governance. This post introduces Capability Insights for AWS, a self-hosted dashboard that auto-refreshes Regional availability data every 24 hours, and Workload Analysis, which scans CloudTrail and CloudFormation to filter services to only those your account uses. Capability Insights deploys a static website backed by API Gateway, Lambda, and EventBridge within your VPC, pulling data from the centralized AWS Capabilities by Region S3 bucket. Workload Analysis reduces the scope from over 200 services to typically 20-30, attributing each resource type to the specific CloudFormation stacks that deploy it and showing property configurations in use. The dashboard provides a targeted view of service availability, API operations, and CloudFormation resource types per Region, enabling focused gap analysis for Regional expansion planning and helping identify service-availability gaps.


### [Build anything: Supabase from code, and an MCP server for your app](https://yomu.fyi/post/build-anything-supabase-from-code-and-an-mcp-server-for-your-app.md)
- Company: [Supabase](https://yomu.fyi/company/supabase.md)
- Author: wenbo, laktek, jgoux, avallete, rand\_arete, katerina\_skroumpelou
- Published: Oct 2, 2026
- Type: Announcement

Supabase announced tools at Supabase Select that let coding agents manage backend configuration and deployment from code, eliminating the need for dashboard-only changes. Declarative Schemas 2.0 allows agents to edit SQL files as the source of truth, with pg-delta generating migrations, while config.toml holds settings like auth providers that can be pulled back from the dashboard. Local development now runs as native processes without Docker, supporting multiple instances per directory and working in environments like Claude Code’s sandbox, currently in alpha off by default. Supabase Compute provides long-running services in any language alongside the database, with configurable memory and CPU, public or private HTTP endpoints, and deployment via CLI or Management API. The new MCP server lets user agents interact with an app as the signed-in user, respecting existing RLS policies, built on @supabase/server and Supabase Middleware, with a headless app template available.


### [Lakebase Postgres branch-based restores for fast recovery at scale](https://yomu.fyi/post/lakebase-postgres-branch-based-restores-for-fast-recovery-at-scale.md)
- Company: [Databricks](https://yomu.fyi/company/databricks.md)
- Author: Cassie Murray, Carlota Soto
- Published: Oct 1, 2026
- Type: Explainer

Traditional Postgres point-in-time recovery is slow because compute and storage are coupled, requiring provisioning a new instance, restoring a snapshot from object storage to disk, and replaying WAL, leading to hours of downtime for large databases. In a survey of developers running 1TB+ production Postgres, 59% had a critical production failure and 30% were down for over three hours. Lakebase Postgres decouples compute and storage using safekeepers, a pageserver, and object storage, storing database history as an immutable timeline. A restore becomes a branch at a point in history, a metadata operation that does not copy data, making it near-instant regardless of database size. This eliminates data copies and WAL replay, so restoring a 100 TB database is as fast as restoring 10 GB, and agents can use restores as ordinary tool calls for versioning and undo.