{"id":1090,"date":"2026-02-22T08:09:57","date_gmt":"2026-02-22T08:09:57","guid":{"rendered":"https:\/\/devopsschool.org\/blog\/uncategorized\/cloudformation\/"},"modified":"2026-02-22T08:09:57","modified_gmt":"2026-02-22T08:09:57","slug":"cloudformation","status":"publish","type":"post","link":"https:\/\/devopsschool.org\/blog\/cloudformation\/","title":{"rendered":"What is CloudFormation? Meaning, Examples, Use Cases, and How to use it?"},"content":{"rendered":"\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Quick Definition<\/h2>\n\n\n\n<p>CloudFormation is an infrastructure-as-code service for defining, provisioning, and managing cloud resources declaratively.<\/p>\n\n\n\n<p>Analogy: CloudFormation is like a blueprint and automated construction crew combined \u2014 you write the blueprint once and the crew builds, updates, or tears down the environment exactly as specified.<\/p>\n\n\n\n<p>Formal technical line: CloudFormation is a declarative provisioning engine that interprets templates, manages resource dependency graphs, and orchestrates lifecycle actions against supported cloud APIs.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">What is CloudFormation?<\/h2>\n\n\n\n<p>What it is \/ what it is NOT<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>It is an infrastructure-as-code (IaC) framework for declarative provisioning and lifecycle management.<\/li>\n<li>It is NOT a configuration management tool for OS-level package installation; it manages resources and high-level settings.<\/li>\n<li>It is NOT a generic workflow engine; its focus is resource creation, updates, drift detection, and deletion.<\/li>\n<\/ul>\n\n\n\n<p>Key properties and constraints<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Declarative templates describe desired state rather than imperative steps.<\/li>\n<li>Supports parameterization, mappings, conditions, and intrinsic functions.<\/li>\n<li>Maintains a state via the service&#8217;s stack objects rather than a separate external state file.<\/li>\n<li>Change sets enable previewing updates before execution.<\/li>\n<li>Drift detection checks live resources against the template.<\/li>\n<li>Nested stacks enable composition but increase complexity.<\/li>\n<li>Limits exist on template size, stack counts, and API rate limits; specifics vary \/ depends.<\/li>\n<li>IAM permissions required for resource actions; least-privilege often complex.<\/li>\n<\/ul>\n\n\n\n<p>Where it fits in modern cloud\/SRE workflows<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Source-controlled templates live next to application code or in a dedicated infra repo.<\/li>\n<li>CI pipelines validate templates, test change sets, and optionally deploy to staging.<\/li>\n<li>CD pipelines execute approved change sets to production with gating.<\/li>\n<li>Observability and alerting track stack operations, failures, and drift.<\/li>\n<li>Integrated into incident playbooks for resource rollbacks or recreations.<\/li>\n<li>Often combined with configuration managers, Kubernetes operators, and service meshes.<\/li>\n<\/ul>\n\n\n\n<p>Text-only diagram description<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Visualize a three-column layout: Left column is &#8220;Developers\/Infra Repo&#8221; with templates and CI; middle column is &#8220;CloudFormation Service&#8221; with stacks, change sets, and drift detection; right column is &#8220;Cloud Provider APIs&#8221; with compute, networking, storage, managed services. Arrows: templates -&gt; CloudFormation; CloudFormation -&gt; Cloud Provider APIs; telemetry flows back into Observability systems; CI\/CD orchestrates template validation and deploys change sets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CloudFormation in one sentence<\/h3>\n\n\n\n<p>CloudFormation is a declarative IaC service that translates templates into resource operations and manages resource lifecycles, dependencies, and drift for supported cloud services.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">CloudFormation vs related terms (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Term<\/th>\n<th>How it differs from CloudFormation<\/th>\n<th>Common confusion<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>T1<\/td>\n<td>Terraform<\/td>\n<td>External tool using state files and providers<\/td>\n<td>Both are IaC<\/td>\n<\/tr>\n<tr>\n<td>T2<\/td>\n<td>Pulumi<\/td>\n<td>Imperative SDKs for infra in general languages<\/td>\n<td>Code vs template debate<\/td>\n<\/tr>\n<tr>\n<td>T3<\/td>\n<td>Ansible<\/td>\n<td>Config management and imperative tasks<\/td>\n<td>Has IaC modules but not core focus<\/td>\n<\/tr>\n<tr>\n<td>T4<\/td>\n<td>Kubernetes manifests<\/td>\n<td>Declarative for k8s control plane only<\/td>\n<td>Not cloud resource provisioning<\/td>\n<\/tr>\n<tr>\n<td>T5<\/td>\n<td>CDK<\/td>\n<td>Generates CloudFormation templates programmatically<\/td>\n<td>Both can produce same artifacts<\/td>\n<\/tr>\n<tr>\n<td>T6<\/td>\n<td>Serverless framework<\/td>\n<td>High-level serverless app packaging<\/td>\n<td>Abstracts multiple infra details<\/td>\n<\/tr>\n<tr>\n<td>T7<\/td>\n<td>OpsWorks<\/td>\n<td>Configuration lifecycle service<\/td>\n<td>Different scope and patterns<\/td>\n<\/tr>\n<tr>\n<td>T8<\/td>\n<td>SAM<\/td>\n<td>Serverless app model that expands templates<\/td>\n<td>Often compiles to native templates<\/td>\n<\/tr>\n<tr>\n<td>T9<\/td>\n<td>CloudFormation Registry<\/td>\n<td>Extension mechanism for resource types<\/td>\n<td>Adds custom resource types<\/td>\n<\/tr>\n<tr>\n<td>T10<\/td>\n<td>Helm<\/td>\n<td>Package manager for Kubernetes apps<\/td>\n<td>Not for cloud infra outside k8s<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if any cell says \u201cSee details below\u201d)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Why does CloudFormation matter?<\/h2>\n\n\n\n<p>Business impact (revenue, trust, risk)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Predictable provisioning reduces downtime and accelerates feature delivery.<\/li>\n<li>Automated reproducibility lowers risk of configuration drift that could cause outages or data exposure.<\/li>\n<li>Faster recovery from incidents improves customer trust and reduces revenue impact.<\/li>\n<\/ul>\n\n\n\n<p>Engineering impact (incident reduction, velocity)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Templates act as a single source of truth; fewer manual changes means fewer surprises in production.<\/li>\n<li>Standardized modules and patterns increase developer velocity and reduce onboarding time.<\/li>\n<li>Automation enables safer experimentation and faster rollback paths.<\/li>\n<\/ul>\n\n\n\n<p>SRE framing (SLIs\/SLOs\/error budgets\/toil\/on-call)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SLIs might measure successful stack deployments per change or drift rate.<\/li>\n<li>SLOs can be defined around deployment success and template drift windows.<\/li>\n<li>Error budgets inform risk tolerance for schema changes during deployments.<\/li>\n<li>Toil reduced via reusable templates, CI validation, and automated rollbacks.<\/li>\n<li>On-call responsibilities include responding to stack failures, resource quota issues, and drift alerts.<\/li>\n<\/ul>\n\n\n\n<p>3\u20135 realistic \u201cwhat breaks in production\u201d examples<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Database subnet misconfiguration prevents replicas from joining cluster causing degraded read capacity.<\/li>\n<li>IAM policy mis-specified grants excessive permissions causing a security breach.<\/li>\n<li>Template parameter typo changes instance type to unsupported family causing stack update failure.<\/li>\n<li>Deleting a shared resource from a stack breaks multiple downstream services.<\/li>\n<li>Rate-limited API calls during bulk updates lead to partial failures and inconsistent states.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Where is CloudFormation used? (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Layer\/Area<\/th>\n<th>How CloudFormation appears<\/th>\n<th>Typical telemetry<\/th>\n<th>Common tools<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>L1<\/td>\n<td>Network<\/td>\n<td>VPCs subnets route tables and gateways defined as resources<\/td>\n<td>Subnet creation events and API errors<\/td>\n<td>Cloud provider console CI<\/td>\n<\/tr>\n<tr>\n<td>L2<\/td>\n<td>Compute<\/td>\n<td>EC2 ASGs instances launch configs<\/td>\n<td>Launch failures and instance health<\/td>\n<td>AutoScaling groups monitoring<\/td>\n<\/tr>\n<tr>\n<td>L3<\/td>\n<td>Storage<\/td>\n<td>S3 buckets EFS volumes and lifecycle rules<\/td>\n<td>PutObject errors and access logs<\/td>\n<td>Object storage metrics<\/td>\n<\/tr>\n<tr>\n<td>L4<\/td>\n<td>Database<\/td>\n<td>RDS clusters and parameter groups<\/td>\n<td>Deployment duration and failover events<\/td>\n<td>DB monitoring agents<\/td>\n<\/tr>\n<tr>\n<td>L5<\/td>\n<td>Serverless<\/td>\n<td>Functions APIs and permissions<\/td>\n<td>Invocation errors and throttle metrics<\/td>\n<td>Function observability<\/td>\n<\/tr>\n<tr>\n<td>L6<\/td>\n<td>Kubernetes<\/td>\n<td>EKS cluster nodes and IAM roles<\/td>\n<td>Node join events and kube errors<\/td>\n<td>k8s monitoring tools<\/td>\n<\/tr>\n<tr>\n<td>L7<\/td>\n<td>CI\/CD<\/td>\n<td>Pipelines roles and triggers defined in infra<\/td>\n<td>Pipeline run success rates<\/td>\n<td>CI systems integration<\/td>\n<\/tr>\n<tr>\n<td>L8<\/td>\n<td>Security<\/td>\n<td>IAM roles policies and guards<\/td>\n<td>Policy change events and violations<\/td>\n<td>Security scanning tools<\/td>\n<\/tr>\n<tr>\n<td>L9<\/td>\n<td>Observability<\/td>\n<td>Logging storage alarms dashboards<\/td>\n<td>Alert counts and dashboard loads<\/td>\n<td>Monitoring platforms<\/td>\n<\/tr>\n<tr>\n<td>L10<\/td>\n<td>Edge<\/td>\n<td>CDN distributions and WAF rules<\/td>\n<td>Cache hit rates and blocked requests<\/td>\n<td>Edge config tools<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">When should you use CloudFormation?<\/h2>\n\n\n\n<p>When it\u2019s necessary<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You must provision native cloud resources supported by the service.<\/li>\n<li>When you require integration with cloud provider features like drift detection and change sets.<\/li>\n<li>When governance requires service-managed state and native IAM controls.<\/li>\n<\/ul>\n\n\n\n<p>When it\u2019s optional<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>For purely ephemeral sandbox environments where simpler scripts suffice.<\/li>\n<li>When using higher-level frameworks that already generate and manage templates (CDK, SAM).<\/li>\n<\/ul>\n\n\n\n<p>When NOT to use \/ overuse it<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid using CloudFormation for frequent in-instance configuration tasks; use configuration management or containers.<\/li>\n<li>Don\u2019t model extremely high-churn ephemeral objects in large stacks; prefer smaller, short-lived stacks or alternative tools.<\/li>\n<li>Avoid baking secrets in templates or using templates for secret rotation.<\/li>\n<\/ul>\n\n\n\n<p>Decision checklist<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you need provider-native lifecycle and drift detection and use provider-managed services -&gt; Use CloudFormation.<\/li>\n<li>If you prefer language-based SDKs with imperative logic -&gt; Consider Pulumi or CDK compiling to templates.<\/li>\n<li>If you need multi-cloud unified authoring -&gt; Consider Terraform or an abstraction layer.<\/li>\n<\/ul>\n\n\n\n<p>Maturity ladder: Beginner -&gt; Intermediate -&gt; Advanced<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Beginner: Single stack for app with parameters and outputs, stored in repo, deployed via basic CI.<\/li>\n<li>Intermediate: Modular stacks, nested stacks or cross-stack references, change set gating, automated tests.<\/li>\n<li>Advanced: Modular registries and private modules, stack sets across accounts, drift policies, policy-as-code, automated rollback playbooks, integration with GitOps and chatops.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How does CloudFormation work?<\/h2>\n\n\n\n<p>Components and workflow<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Template: Declarative JSON\/YAML file describing resources and relationships.<\/li>\n<li>Stack: An instantiation of a template with parameter values and stack lifecycle.<\/li>\n<li>Change Set: A preview of proposed changes to a stack.<\/li>\n<li>Stack Events: Logs of create\/update\/delete actions and statuses.<\/li>\n<li>Drift Detection: Tooling to compare live resources to template expectations.<\/li>\n<li>Registry and resource types: Extendable resource providers.<\/li>\n<\/ul>\n\n\n\n<p>Workflow:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Author template in repo and run linter\/static validation.<\/li>\n<li>CI validates JSON\/YAML and runs unit tests for modules.<\/li>\n<li>Generate or preview change set in staging and run automated tests.<\/li>\n<li>Approve and execute change set in production during maintenance window or canary flow.<\/li>\n<li>Monitor stack events, application telemetry, and drift reports.<\/li>\n<li>Rollback or run remediation if needed.<\/li>\n<\/ol>\n\n\n\n<p>Data flow and lifecycle<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Input: Template + parameters + capabilities + tags.<\/li>\n<li>Engine: CloudFormation parses, builds dependency graph, invokes provider APIs in order.<\/li>\n<li>Output: Stack resources created\/updated\/deleted; outputs provide cross-stack data.<\/li>\n<li>Lifecycle: CREATE -&gt; UPDATE\/ROLLBACK -&gt; DELETE. Stacks maintain metadata and event logs.<\/li>\n<\/ul>\n\n\n\n<p>Edge cases and failure modes<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Partial failures with resources left orphaned.<\/li>\n<li>Circular dependencies between stacks or resources.<\/li>\n<li>Throttling or API limits during large updates.<\/li>\n<li>Rollback triggered by dependent resource failure causing removal of newly created resources.<\/li>\n<li>Unsupported resources or parameters causing template validation failures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical architecture patterns for CloudFormation<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Monolithic stack\n   &#8211; When to use: Small projects or PoCs with few resources.\n   &#8211; Tradeoffs: Simple but risky for scale and changes.<\/p>\n<\/li>\n<li>\n<p>Micro stacks (per-service stacks)\n   &#8211; When to use: Teams owning separate services; reduces blast radius.\n   &#8211; Tradeoffs: Requires cross-stack references and outputs.<\/p>\n<\/li>\n<li>\n<p>Nested stacks and modules\n   &#8211; When to use: Reuse patterns like networking or authentication.\n   &#8211; Tradeoffs: Debugging nested failure contexts can be harder.<\/p>\n<\/li>\n<li>\n<p>Stack Sets for multi-account\n   &#8211; When to use: Organizations with many accounts needing centralized deployments.\n   &#8211; Tradeoffs: Requires extra governance and permissions.<\/p>\n<\/li>\n<li>\n<p>GitOps via template artifacts\n   &#8211; When to use: Desire for declarative repo-driven deployments.\n   &#8211; Tradeoffs: Needs CI\/CD and policy checks.<\/p>\n<\/li>\n<li>\n<p>CDK-generated templates\n   &#8211; When to use: Programmatic composition or language reuse.\n   &#8211; Tradeoffs: Consider generated template size and debugging complexity.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Failure modes &amp; mitigation (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Failure mode<\/th>\n<th>Symptom<\/th>\n<th>Likely cause<\/th>\n<th>Mitigation<\/th>\n<th>Observability signal<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>F1<\/td>\n<td>Stack update failure<\/td>\n<td>Stack rollback started<\/td>\n<td>Invalid resource property<\/td>\n<td>Validate templates and test change sets<\/td>\n<td>Stack events and error code<\/td>\n<\/tr>\n<tr>\n<td>F2<\/td>\n<td>Drift detected<\/td>\n<td>Configuration differs from template<\/td>\n<td>Manual changes outside IaC<\/td>\n<td>Enforce drift alerts and automated remediation<\/td>\n<td>Drift reports increment<\/td>\n<\/tr>\n<tr>\n<td>F3<\/td>\n<td>Throttled API calls<\/td>\n<td>Slow updates and timeouts<\/td>\n<td>Too many concurrent ops<\/td>\n<td>Throttle updates and use backoff retries<\/td>\n<td>API error rate spikes<\/td>\n<\/tr>\n<tr>\n<td>F4<\/td>\n<td>Orphaned resources<\/td>\n<td>Unexpected cost or conflicts<\/td>\n<td>Partial failure during update<\/td>\n<td>Cleanup scripts and resource tagging<\/td>\n<td>Resource count delta alerts<\/td>\n<\/tr>\n<tr>\n<td>F5<\/td>\n<td>Dependency deadlock<\/td>\n<td>Circular dependency error<\/td>\n<td>Cross-stack circular reference<\/td>\n<td>Refactor stacks and use outputs responsibly<\/td>\n<td>Validation failure logs<\/td>\n<\/tr>\n<tr>\n<td>F6<\/td>\n<td>IAM permission denied<\/td>\n<td>Action fails with access error<\/td>\n<td>Insufficient deployer permissions<\/td>\n<td>Use least-privilege and CI role escalation<\/td>\n<td>Access denied logs<\/td>\n<\/tr>\n<tr>\n<td>F7<\/td>\n<td>Large template limit<\/td>\n<td>Template rejected or truncated<\/td>\n<td>Template exceeds size limits<\/td>\n<td>Use nested stacks or S3 template storage<\/td>\n<td>Template validation failure<\/td>\n<\/tr>\n<tr>\n<td>F8<\/td>\n<td>Unknown resource type<\/td>\n<td>Resource not recognized<\/td>\n<td>Missing Registry provider<\/td>\n<td>Register custom type or update provider<\/td>\n<td>Validation or schema error<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Key Concepts, Keywords &amp; Terminology for CloudFormation<\/h2>\n\n\n\n<p>Below are 40+ terms with brief definitions, why they matter, and a common pitfall.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Template \u2014 Declarative JSON\/YAML document describing resources \u2014 Source of truth \u2014 Pitfall: embedding secrets.<\/li>\n<li>Stack \u2014 An instantiation of a template with parameters \u2014 Represents deployed state \u2014 Pitfall: putting unrelated resources in same stack.<\/li>\n<li>Change Set \u2014 Preview of updates before execution \u2014 Enables safe deployments \u2014 Pitfall: forgetting to apply after review.<\/li>\n<li>Drift Detection \u2014 Compares live state to template \u2014 Detects manual changes \u2014 Pitfall: not scheduling periodic checks.<\/li>\n<li>Nested Stack \u2014 Stack created from another stack to modularize infra \u2014 Reuse patterns \u2014 Pitfall: deep nesting complicates debugging.<\/li>\n<li>StackSet \u2014 Deploys stacks across multiple accounts or regions \u2014 Centralized rollout \u2014 Pitfall: complex permissions.<\/li>\n<li>Outputs \u2014 Exported values from a stack for cross-stack usage \u2014 Data sharing \u2014 Pitfall: circular exports.<\/li>\n<li>Parameters \u2014 Template inputs at deployment time \u2014 Reusable templates \u2014 Pitfall: overuse causing complex branching.<\/li>\n<li>Mappings \u2014 Static key-value mapping within templates \u2014 Simplifies region-specific values \u2014 Pitfall: unwieldy for many variations.<\/li>\n<li>Conditions \u2014 Conditional resource creation logic \u2014 Reduces template duplication \u2014 Pitfall: hiding complexity.<\/li>\n<li>Resources \u2014 The entities created by template (compute, DB, etc) \u2014 Core units \u2014 Pitfall: misnaming resources causing confusion.<\/li>\n<li>Intrinsic Functions \u2014 Template helpers like Ref Fn::GetAtt \u2014 Resolve values \u2014 Pitfall: mis-evaluating function outputs.<\/li>\n<li>Metadata \u2014 Extra information for resources used by tooling \u2014 Tooling hooks \u2014 Pitfall: bloat and irrelevant metadata.<\/li>\n<li>Transform \u2014 Preprocessor for templates (e.g., serverless transforms) \u2014 Simplifies shorthand \u2014 Pitfall: added magic hides real resources.<\/li>\n<li>WaitCondition \u2014 Synchronization construct during creation \u2014 Coordinate external events \u2014 Pitfall: timeouts causing rollbacks.<\/li>\n<li>Custom Resource \u2014 Lambda-backed resource for unsupported types \u2014 Extendable infra \u2014 Pitfall: lifecycle complexity and permissions.<\/li>\n<li>Registry \u2014 Hosts custom resource types \u2014 Extensibility \u2014 Pitfall: relying on unstable third-party types.<\/li>\n<li>Rollback \u2014 Reverting to previous stable state after failure \u2014 Safety mechanism \u2014 Pitfall: losing transient diagnostics.<\/li>\n<li>CAPABILITY_IAM \u2014 Acknowledge IAM resource creation \u2014 Required for privileged changes \u2014 Pitfall: missing capability stop deploys.<\/li>\n<li>Export \u2014 Makes outputs available to other stacks \u2014 Enables composition \u2014 Pitfall: exporting mutable values causing coupling.<\/li>\n<li>ImportValue \u2014 Retrieves exported value from another stack \u2014 Cross-stack reference \u2014 Pitfall: dependency cycles.<\/li>\n<li>Stack Policy \u2014 Prevents certain resources from being replaced \u2014 Protection during updates \u2014 Pitfall: overly restrictive policies block valid changes.<\/li>\n<li>Termination Protection \u2014 Prevents accidental stack deletion \u2014 Safety \u2014 Pitfall: forgetting to disable during automated teardown.<\/li>\n<li>Template Body Size \u2014 Limit for inline templates \u2014 Operational constraint \u2014 Pitfall: storing large templates inline without S3.<\/li>\n<li>Transforms SAM \u2014 Serverless shorthand transform \u2014 Simplifies function definitions \u2014 Pitfall: SAM-specific constructs require transform.<\/li>\n<li>Resource Types \u2014 Named types like AWS::S3::Bucket \u2014 Determines API behavior \u2014 Pitfall: mismatched properties per type.<\/li>\n<li>Stack Events \u2014 Timeline of operations for a stack \u2014 Debugging aid \u2014 Pitfall: failing to surface to alerts.<\/li>\n<li>Stack Tags \u2014 Key-value metadata attached to stacks \u2014 Cost and governance tagging \u2014 Pitfall: inconsistent tag usage.<\/li>\n<li>Change Set Execution \u2014 Applying the change set \u2014 The actual deployment step \u2014 Pitfall: accidental execution without review.<\/li>\n<li>Terminated Resources \u2014 Deleted resources during rollback \u2014 Auditing concern \u2014 Pitfall: data loss if not backed up.<\/li>\n<li>Template Linter \u2014 Static analysis tool for templates \u2014 Reduces errors \u2014 Pitfall: relying solely on linter for correctness.<\/li>\n<li>Drift Status \u2014 Result of drift detection per resource \u2014 Operational risk indicator \u2014 Pitfall: ignoring partial drift.<\/li>\n<li>Resource Import \u2014 Import existing resource into stack \u2014 Adoption tool \u2014 Pitfall: must match resource configuration exactly.<\/li>\n<li>Stack Deletion \u2014 Process to remove resources \u2014 Clean teardown \u2014 Pitfall: shared resources accidentally deleted.<\/li>\n<li>Capabilities Flag \u2014 Acknowledge dangerous ops like IAM \u2014 Deployment gate \u2014 Pitfall: missing on automated runs.<\/li>\n<li>Service Role \u2014 Role CloudFormation assumes to perform actions \u2014 Least privilege path \u2014 Pitfall: over-privileged role.<\/li>\n<li>Stack Policy During Update \u2014 Protect resources from modifications \u2014 Safety \u2014 Pitfall: blocks intended updates.<\/li>\n<li>Event Hook \u2014 Integrations for pre\/post actions \u2014 Automation extension \u2014 Pitfall: complex retry semantics.<\/li>\n<li>Parameter Store Integration \u2014 Pull runtime values into templates \u2014 Dynamic configuration \u2014 Pitfall: secret exposure in outputs.<\/li>\n<li>Modularization \u2014 Splitting infra into reusable modules \u2014 Reuse and maintainability \u2014 Pitfall: overfragmentation increases operational overhead.<\/li>\n<li>Template Versioning \u2014 Tracking template changes via VCS \u2014 Traceability \u2014 Pitfall: not tagging release-compatible templates.<\/li>\n<li>Rollforward \u2014 Applying subsequent changes after rollback \u2014 Recovery pattern \u2014 Pitfall: repeating the same change without fix.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How to Measure CloudFormation (Metrics, SLIs, SLOs) (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Metric\/SLI<\/th>\n<th>What it tells you<\/th>\n<th>How to measure<\/th>\n<th>Starting target<\/th>\n<th>Gotchas<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>M1<\/td>\n<td>Stack success rate<\/td>\n<td>Reliability of deployments<\/td>\n<td>Successful stacks \/ attempted stacks<\/td>\n<td>99% per week<\/td>\n<td>Includes nonproduction runs<\/td>\n<\/tr>\n<tr>\n<td>M2<\/td>\n<td>Change set approval to execution time<\/td>\n<td>Deployment latency in process<\/td>\n<td>Time from change set creation to execution<\/td>\n<td>&lt; 2 hours<\/td>\n<td>CI approvals can skew<\/td>\n<\/tr>\n<tr>\n<td>M3<\/td>\n<td>Drift rate<\/td>\n<td>Percentage of resources drifted<\/td>\n<td>Drifted resources \/ total managed<\/td>\n<td>&lt; 1% monthly<\/td>\n<td>Some drift expected for self-managed resources<\/td>\n<\/tr>\n<tr>\n<td>M4<\/td>\n<td>Mean time to recover stack (MTTR)<\/td>\n<td>Time to restore after failure<\/td>\n<td>Time from failure to successful restore<\/td>\n<td>&lt; 30 min for infra fixes<\/td>\n<td>Automated rollback changes metric<\/td>\n<\/tr>\n<tr>\n<td>M5<\/td>\n<td>Stack rollback rate<\/td>\n<td>Frequency of failed updates<\/td>\n<td>Rollbacks \/ updates<\/td>\n<td>&lt; 0.5%<\/td>\n<td>Partial failures may be acceptable<\/td>\n<\/tr>\n<tr>\n<td>M6<\/td>\n<td>Template validation errors<\/td>\n<td>Early detection of issues<\/td>\n<td>Validation errors per commit<\/td>\n<td>0 in main branch<\/td>\n<td>Linter false positives possible<\/td>\n<\/tr>\n<tr>\n<td>M7<\/td>\n<td>API error rate during deployments<\/td>\n<td>External throttling or permission issues<\/td>\n<td>API 4xx\/5xx during ops<\/td>\n<td>&lt; 1%<\/td>\n<td>Short bursts may be normal<\/td>\n<\/tr>\n<tr>\n<td>M8<\/td>\n<td>Orphaned resource count<\/td>\n<td>Resource leakage or incomplete cleanup<\/td>\n<td>Orphaned resources per month<\/td>\n<td>0 critical resources<\/td>\n<td>Detect via tagging and inventory<\/td>\n<\/tr>\n<tr>\n<td>M9<\/td>\n<td>Deployment duration<\/td>\n<td>Time to complete stack updates<\/td>\n<td>From execution to completion<\/td>\n<td>Varies by stack size<\/td>\n<td>Large stacks take longer<\/td>\n<\/tr>\n<tr>\n<td>M10<\/td>\n<td>Cost delta after deployments<\/td>\n<td>Unexpected cost changes<\/td>\n<td>Cost change vs baseline per deploy<\/td>\n<td>0% unexpected increase<\/td>\n<td>Cost noise from unrelated changes<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Best tools to measure CloudFormation<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Native Cloud APIs and Console<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for CloudFormation: Stack events, drift reports, template validation, change sets.<\/li>\n<li>Best-fit environment: Any environment using provider-native stacks.<\/li>\n<li>Setup outline:<\/li>\n<li>Enable stack logging.<\/li>\n<li>Configure event notifications.<\/li>\n<li>Use drift detection schedules.<\/li>\n<li>Tag stacks for cost and telemetry grouping.<\/li>\n<li>Strengths:<\/li>\n<li>Native integration and no external dependency.<\/li>\n<li>Consistent with provider permissions.<\/li>\n<li>Limitations:<\/li>\n<li>Basic analytics and limited historical query flexibility.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 CI\/CD pipeline metrics (Build system)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for CloudFormation: Change set creation times, validation failures, deployment success rates.<\/li>\n<li>Best-fit environment: GitOps and automated deploy pipelines.<\/li>\n<li>Setup outline:<\/li>\n<li>Integrate validation steps into CI.<\/li>\n<li>Emit metrics to telemetry.<\/li>\n<li>Gate change set execution behind approvals.<\/li>\n<li>Strengths:<\/li>\n<li>Tight feedback loop for developers.<\/li>\n<li>Can enforce policies pre-deploy.<\/li>\n<li>Limitations:<\/li>\n<li>Needs custom metrics or exporters.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Monitoring platform (logs and metrics)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for CloudFormation: API error rates, throttling, resource creation latencies.<\/li>\n<li>Best-fit environment: Teams with centralized observability.<\/li>\n<li>Setup outline:<\/li>\n<li>Collect CloudFormation events.<\/li>\n<li>Correlate with resource metrics.<\/li>\n<li>Build dashboards for stacks.<\/li>\n<li>Strengths:<\/li>\n<li>Rich querying and alerting features.<\/li>\n<li>Correlation with broader system signals.<\/li>\n<li>Limitations:<\/li>\n<li>Requires ingestion and mapping work.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Cost management tool<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for CloudFormation: Cost deltas post deployment and tagging compliance.<\/li>\n<li>Best-fit environment: Teams tracking infra spend.<\/li>\n<li>Setup outline:<\/li>\n<li>Ensure stacks are tagged.<\/li>\n<li>Configure cost alerts per tag.<\/li>\n<li>Track pre\/post deployment cost snapshots.<\/li>\n<li>Strengths:<\/li>\n<li>Detects unexpected spend increases.<\/li>\n<li>Limitations:<\/li>\n<li>Cost attribution lag.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Tool \u2014 Policy-as-code tool<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for CloudFormation: Template compliance against organizational policies.<\/li>\n<li>Best-fit environment: Regulated orgs or large enterprises.<\/li>\n<li>Setup outline:<\/li>\n<li>Define policies for allowed resource types.<\/li>\n<li>Integrate policy checks in CI.<\/li>\n<li>Block non-compliant change sets.<\/li>\n<li>Strengths:<\/li>\n<li>Prevents risky configurations.<\/li>\n<li>Limitations:<\/li>\n<li>Policy drift and false positives.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Recommended dashboards &amp; alerts for CloudFormation<\/h3>\n\n\n\n<p>Executive dashboard<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels: Overall stack success rate, monthly drift rate, cost delta from infra changes, number of stack sets across accounts, policy compliance score.<\/li>\n<li>Why: Gives leadership quick health and risk indicators.<\/li>\n<\/ul>\n\n\n\n<p>On-call dashboard<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels: Active failing stacks, stacks in rollback, recent stack events stream, API error rate during deployments, ongoing change sets with age.<\/li>\n<li>Why: Supports rapid triage for incidents.<\/li>\n<\/ul>\n\n\n\n<p>Debug dashboard<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels: Per-stack timeline of events, resource-level errors, API call latencies, dependent resource metrics, relevant logs and CloudTrail events.<\/li>\n<li>Why: Detailed debugging for remediation.<\/li>\n<\/ul>\n\n\n\n<p>Alerting guidance<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What should page vs ticket:<\/li>\n<li>Page: Production stack rollback, failed create with data loss risk, repeated IAM capability warnings during deploy.<\/li>\n<li>Ticket: Noncritical drift alerts, validation failures in staging.<\/li>\n<li>Burn-rate guidance:<\/li>\n<li>Use error budget to allow small percentage of stack failures per release window; page when burn rate exceeds threshold for critical stacks.<\/li>\n<li>Noise reduction tactics:<\/li>\n<li>Deduplicate by stack name and resource; group similar events into a single notification; suppress transient errors with short backoff.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Implementation Guide (Step-by-step)<\/h2>\n\n\n\n<p>1) Prerequisites\n&#8211; Account with deployment permissions and service role for automation.\n&#8211; Version control for templates.\n&#8211; CI\/CD system integrated with the repository.\n&#8211; Tagging and IAM policies defined.\n&#8211; Observability platform and cost tracking in place.<\/p>\n\n\n\n<p>2) Instrumentation plan\n&#8211; Emit stack events to logging and monitoring.\n&#8211; Tag resources for cost and ownership.\n&#8211; Collect CloudWatch\/metrics for resources provisioned.\n&#8211; Create metrics for deployments and failures.<\/p>\n\n\n\n<p>3) Data collection\n&#8211; Centralize stack events and change set outputs.\n&#8211; Ingest CloudTrail events for resource API calls.\n&#8211; Aggregate deployment metrics in monitoring platform.<\/p>\n\n\n\n<p>4) SLO design\n&#8211; Define SLOs for stack success rates and drift windows.\n&#8211; Allocate error budgets per environment and service.\n&#8211; Tie SLOs to deployment policies.<\/p>\n\n\n\n<p>5) Dashboards\n&#8211; Build executive, on-call, and debug dashboards.\n&#8211; Include cross-linking to runbooks and playbooks.<\/p>\n\n\n\n<p>6) Alerts &amp; routing\n&#8211; Configure paging for critical stack failures.\n&#8211; Route drift and low-priority validation failures to ticket queues.\n&#8211; Implement suppression rules for CI noise.<\/p>\n\n\n\n<p>7) Runbooks &amp; automation\n&#8211; Document common remediation steps and rollback mechanisms.\n&#8211; Automate safe rollbacks and cleanups where possible.<\/p>\n\n\n\n<p>8) Validation (load\/chaos\/game days)\n&#8211; Run deployment load tests for large template updates.\n&#8211; Schedule chaos experiments altering resource states to validate remediation.\n&#8211; Run game days focusing on stack failure recovery.<\/p>\n\n\n\n<p>9) Continuous improvement\n&#8211; Use postmortems to refine templates and policies.\n&#8211; Track recurring failure modes and automate fixes.<\/p>\n\n\n\n<p>Pre-production checklist<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Templates linted and validated.<\/li>\n<li>Parameters and secrets not embedded.<\/li>\n<li>Change sets previewed and approved.<\/li>\n<li>Roles and permissions scoped.<\/li>\n<li>Tagging policy applied.<\/li>\n<\/ul>\n\n\n\n<p>Production readiness checklist<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Rollback policy and termination protection configured.<\/li>\n<li>Observability and alerts enabled.<\/li>\n<li>Backup snapshots for critical data resources.<\/li>\n<li>Cost budget monitoring active.<\/li>\n<li>Runbooks tested and accessible.<\/li>\n<\/ul>\n\n\n\n<p>Incident checklist specific to CloudFormation<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Collect stack events and relevant CloudTrail logs.<\/li>\n<li>Identify the failed resource(s) and error codes.<\/li>\n<li>Check for recent change sets and approvals.<\/li>\n<li>Evaluate rollback feasibility vs forward fix.<\/li>\n<li>Execute runbook steps or escalate to infra owners.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Use Cases of CloudFormation<\/h2>\n\n\n\n<p>Provide 8\u201312 use cases with context, problem, why CloudFormation helps, what to measure, typical tools.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Multi-tier application stack\n&#8211; Context: Web app with load balancer, ASG, and DB.\n&#8211; Problem: Manual deployment inconsistencies across environments.\n&#8211; Why CloudFormation helps: Single template ensures parity.\n&#8211; What to measure: Stack success rate and deployment duration.\n&#8211; Typical tools: CI\/CD, monitoring, database backups.<\/p>\n<\/li>\n<li>\n<p>Network baseline provisioning\n&#8211; Context: VPCs, subnets, route tables, security controls.\n&#8211; Problem: Networking mistakes cause cross-service failures.\n&#8211; Why CloudFormation helps: Enforces standard networking patterns.\n&#8211; What to measure: Network resource drift and ACL changes.\n&#8211; Typical tools: Network monitoring, security scanners.<\/p>\n<\/li>\n<li>\n<p>Multi-account governance via StackSets\n&#8211; Context: Org-wide baseline resources across accounts.\n&#8211; Problem: Manual per-account setup and drift.\n&#8211; Why CloudFormation helps: Centralized StackSets deploy consistent infra.\n&#8211; What to measure: StackSet success rate and policy compliance.\n&#8211; Typical tools: Organization management, IAM auditing.<\/p>\n<\/li>\n<li>\n<p>Serverless application with API and functions\n&#8211; Context: Lambda-backed API with managed DB and permissions.\n&#8211; Problem: Complex IAM and function wiring.\n&#8211; Why CloudFormation helps: SAM or native resources define everything declaratively.\n&#8211; What to measure: Function deployment success and permission errors.\n&#8211; Typical tools: Function observability and API monitoring.<\/p>\n<\/li>\n<li>\n<p>EKS cluster provisioning\n&#8211; Context: Managed k8s control plane and node groups.\n&#8211; Problem: Complex cluster bootstrapping and role setup.\n&#8211; Why CloudFormation helps: Encapsulate cluster creation reproducibly.\n&#8211; What to measure: Node join success and cluster update failures.\n&#8211; Typical tools: Kubernetes monitoring and kubeadm logs.<\/p>\n<\/li>\n<li>\n<p>Blue\/green or canary infra changes\n&#8211; Context: Rolling updates that require infra changes with minimal downtime.\n&#8211; Problem: Risk of downtime on large infra updates.\n&#8211; Why CloudFormation helps: Change sets and staged stacks enable controlled rollouts.\n&#8211; What to measure: Traffic shifting success and error rates under canary.\n&#8211; Typical tools: Traffic management, load testing tools.<\/p>\n<\/li>\n<li>\n<p>Disaster recovery orchestration\n&#8211; Context: Replication zones and failover resources.\n&#8211; Problem: Manual recovery slow and error-prone.\n&#8211; Why CloudFormation helps: Recreate or switch stacks programmatically.\n&#8211; What to measure: Recovery time and data sync status.\n&#8211; Typical tools: Backup tooling and replication monitoring.<\/p>\n<\/li>\n<li>\n<p>Policy enforcement and secure baselines\n&#8211; Context: Enforce encryption, logging, and least privilege.\n&#8211; Problem: Human error leading to non-compliant resources.\n&#8211; Why CloudFormation helps: Templates enforce baselines and avoid omission.\n&#8211; What to measure: Compliance drift and policy violations.\n&#8211; Typical tools: Policy-as-code and security scanners.<\/p>\n<\/li>\n<li>\n<p>CI environment provisioning\n&#8211; Context: On-demand ephemeral environments for testing.\n&#8211; Problem: Inconsistent ephemeral environments waste developer time.\n&#8211; Why CloudFormation helps: Fast, repeatable environment creation.\n&#8211; What to measure: Provision times and teardown success.\n&#8211; Typical tools: CI orchestration and cost control.<\/p>\n<\/li>\n<li>\n<p>Cost-optimized resource creation\n&#8211; Context: Creating right-sized instances and spot usage.\n&#8211; Problem: Oversized resources inflate costs.\n&#8211; Why CloudFormation helps: Templates prescribe cost-saving configurations centrally.\n&#8211; What to measure: Cost delta and resource utilization.\n&#8211; Typical tools: Cost management dashboards and autoscaling.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Scenario Examples (Realistic, End-to-End)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #1 \u2014 Kubernetes cluster provisioning and app wiring<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Provision an EKS cluster with node groups, IAM roles, and networking, and deploy a critical microservice.\n<strong>Goal:<\/strong> Reproducible cluster and app deployment with least privilege roles.\n<strong>Why CloudFormation matters here:<\/strong> Automates cluster creation and role bindings, reduces bootstrapping time.\n<strong>Architecture \/ workflow:<\/strong> CloudFormation creates VPC, EKS cluster, node groups, IAM roles, and outputs kubeconfig reference. CI uses outputs to deploy Helm charts.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Author modular templates for networking, EKS, and node groups.<\/li>\n<li>Use nested stacks to compose cluster and supporting services.<\/li>\n<li>Create change sets and validate in staging.<\/li>\n<li>Deploy cluster with stack set if multi-account.<\/li>\n<li>CI picks up kubeconfig and deploys app manifests.\n<strong>What to measure:<\/strong> Node join success, stack creation duration, pod readiness times.\n<strong>Tools to use and why:<\/strong> Cluster autoscaler, kube-state-metrics, IaC linter.\n<strong>Common pitfalls:<\/strong> Not scoping IAM roles, overlarge templates, missing cluster endpoint access.\n<strong>Validation:<\/strong> Boot single-node cluster then scale to expected production node count.\n<strong>Outcome:<\/strong> Repeatable cluster builds and faster recovery paths.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #2 \u2014 Serverless API with managed DB (Serverless scenario)<\/h3>\n\n\n\n<p><strong>Context:<\/strong> API endpoints implemented via functions with a managed database.\n<strong>Goal:<\/strong> Deploy API, functions, and correct IAM with minimal manual steps.\n<strong>Why CloudFormation matters here:<\/strong> SAM or templates define functions, event sources, and permissions declaratively.\n<strong>Architecture \/ workflow:<\/strong> Template defines functions, API gateway, DB, and table permissions; change sets handle updates.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Author SAM template and parameterize environment names.<\/li>\n<li>Validate locally and run unit tests for handlers.<\/li>\n<li>Deploy to staging via CI and run integration tests.<\/li>\n<li>Promote change set to production during low traffic window.\n<strong>What to measure:<\/strong> Invocation error rate, deployment success, permission denials.\n<strong>Tools to use and why:<\/strong> Function tracing and API gateway metrics to detect regressions.\n<strong>Common pitfalls:<\/strong> Overly permissive IAM roles and missing cold-start mitigation.\n<strong>Validation:<\/strong> End-to-end tests and simulated traffic to validate retries.\n<strong>Outcome:<\/strong> Faster iteration and consistent deployment of serverless services.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #3 \u2014 Incident response: Failed DB migration (Incident scenario)<\/h3>\n\n\n\n<p><strong>Context:<\/strong> A production DB schema change included in a stack update causes migration to fail.\n<strong>Goal:<\/strong> Recover quickly and minimize customer impact.\n<strong>Why CloudFormation matters here:<\/strong> The deployment pipeline and change set provide context for the introduced changes.\n<strong>Architecture \/ workflow:<\/strong> Stack update includes DB resource and migration lambda; failure triggers rollback.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Triage using stack events and change set details.<\/li>\n<li>If rollback occurs, inspect logs for migration error and snapshot DB if needed.<\/li>\n<li>Apply a hotfix change set with corrected migration or roll forward with alternative approach.<\/li>\n<li>Run postmortem to update templates and pre-deploy testing steps.\n<strong>What to measure:<\/strong> MTTR, rollback frequency, data loss risk.\n<strong>Tools to use and why:<\/strong> Backup snapshots, DB migration logging, and deployment tracing.\n<strong>Common pitfalls:<\/strong> Losing transactional context due to automated rollback, not having DB snapshot retention.\n<strong>Validation:<\/strong> Test migrations in production-like staging and run game day.\n<strong>Outcome:<\/strong> Reduced recovery time and improved pre-deploy checks.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #4 \u2014 Cost vs performance trade-off during autoscaling changes (Cost\/performance)<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Changing instance families and autoscaling policies to balance cost and latency.\n<strong>Goal:<\/strong> Reduce spend while keeping latency within SLOs.\n<strong>Why CloudFormation matters here:<\/strong> Templates codify autoscaling policies and instance types enabling controlled A\/B tests.\n<strong>Architecture \/ workflow:<\/strong> Blue-green variant stacks with different instance types; traffic routed gradually.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Create canary stack with cheaper instance types and adjusted scaling.<\/li>\n<li>Deploy subset of traffic and monitor latencies and error rates.<\/li>\n<li>If SLOs met, promote change set to main stack or keep hybrid configuration.\n<strong>What to measure:<\/strong> Request latency, cost per minute, autoscaling triggers.\n<strong>Tools to use and why:<\/strong> Load testing, APM, and cost analytics.\n<strong>Common pitfalls:<\/strong> Under-provisioning leading to latency spikes or over-scaling increasing cost.\n<strong>Validation:<\/strong> Load tests and production canary with real traffic patterns.\n<strong>Outcome:<\/strong> Balanced cost savings without SLA violation.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #5 \u2014 Cross-account secure baseline via StackSets<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Enforcing logging and encryption across org accounts.\n<strong>Goal:<\/strong> Deploy uniform baselines and enforce standards.\n<strong>Why CloudFormation matters here:<\/strong> StackSets allow centralized deployment to many accounts.\n<strong>Architecture \/ workflow:<\/strong> Master account hosts templates; StackSets push to target accounts and regions.\n<strong>Step-by-step implementation:<\/strong><\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Author baseline template for logging and encryption.<\/li>\n<li>Configure StackSet with admin role and target accounts.<\/li>\n<li>Run in dry-run mode to detect issues then execute.\n<strong>What to measure:<\/strong> StackSet propagation time, compliance drift rate.\n<strong>Tools to use and why:<\/strong> Policy-as-code and monitoring for compliance.\n<strong>Common pitfalls:<\/strong> Insufficient cross-account roles causing failures.\n<strong>Validation:<\/strong> Spot checks and automated compliance scans.\n<strong>Outcome:<\/strong> Reduced manual effort and higher security posture.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Common Mistakes, Anti-patterns, and Troubleshooting<\/h2>\n\n\n\n<p>List of mistakes with Symptom -&gt; Root cause -&gt; Fix. Include at least 5 observability pitfalls.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Symptom: Stack update fails with IAM error -&gt; Root cause: Deployer lacks CAPABILITY_IAM -&gt; Fix: Add capability flag to change set execution.<\/li>\n<li>Symptom: Manual changes fix issue but drift later -&gt; Root cause: Engineers changing resources outside IaC -&gt; Fix: Enforce change via templates and restrict console modification.<\/li>\n<li>Symptom: Slow stack creation -&gt; Root cause: Single large stack with many dependencies -&gt; Fix: Break into smaller stacks or parallelize where possible.<\/li>\n<li>Symptom: Orphaned resources after failure -&gt; Root cause: Partial creation and missing cleanup -&gt; Fix: Implement cleanup scripts and tagged resources.<\/li>\n<li>Symptom: Excessive notifications during CI -&gt; Root cause: Unfiltered stack events into pager -&gt; Fix: Filter notifications and route to ticketing for noncritical events.<\/li>\n<li>Symptom: Missing resource property in template -&gt; Root cause: Misunderstanding resource type schema -&gt; Fix: Validate templates against resource schema and use linter.<\/li>\n<li>Symptom: Template size exceeded -&gt; Root cause: Embedding large libraries or assets inline -&gt; Fix: Use S3 for large templates or nested stacks.<\/li>\n<li>Symptom: Circular dependency errors -&gt; Root cause: Cross-stack outputs importing each other -&gt; Fix: Refactor to remove cycles or use parameterization.<\/li>\n<li>Symptom: Security incident from overbroad role -&gt; Root cause: Templates grant wildcard permissions -&gt; Fix: Implement policy-as-code and least privilege.<\/li>\n<li>Symptom: Unclear failure root cause -&gt; Root cause: Missing log aggregation and context -&gt; Fix: Collect stack events and CloudTrail and correlate in observability.<\/li>\n<li>Symptom: Frequent rollbacks -&gt; Root cause: Inadequate preflight tests -&gt; Fix: Add automated staging validations and integration tests.<\/li>\n<li>Symptom: High-cost surprises -&gt; Root cause: Changes introduce expensive resources unnoticed -&gt; Fix: Cost impact checks in CI and tagging.<\/li>\n<li>Symptom: Production outage after nested stack update -&gt; Root cause: Lack of change set review -&gt; Fix: Enforce approvals and preview diffs.<\/li>\n<li>Symptom: Drift alerts ignored -&gt; Root cause: Alert fatigue and no remediation workflow -&gt; Fix: Prioritize drift by risk and automate fixes for low-risk drift.<\/li>\n<li>Symptom: Slow incident response -&gt; Root cause: No runbooks for CloudFormation failures -&gt; Fix: Produce runbooks with clear rollback vs forward guidance.<\/li>\n<li>Symptom: Missing resource telemetry -&gt; Root cause: Not instrumenting provisioned resources -&gt; Fix: Add metrics and logs as part of template provisioning.<\/li>\n<li>Symptom: Observability gaps after deployment -&gt; Root cause: Dashboards not updated with new resource names -&gt; Fix: Parameterize dashboards with stack outputs.<\/li>\n<li>Symptom: Policy-as-code blocking legitimate changes -&gt; Root cause: Overstrict policies without exceptions -&gt; Fix: Review policies and add controlled exceptions.<\/li>\n<li>Symptom: Secrets leaked in outputs -&gt; Root cause: Outputting secret parameters -&gt; Fix: Use secret manager references and avoid outputs for secrets.<\/li>\n<li>Symptom: Stale templates in repo -&gt; Root cause: No lifecycle policy for templates -&gt; Fix: Version templates and prune old modules.<\/li>\n<li>Symptom: Confusing stack naming -&gt; Root cause: Inconsistent naming conventions -&gt; Fix: Adopt standard naming and enforce via CI.<\/li>\n<li>Symptom: Missing alarms for stack failures -&gt; Root cause: Reliance on console for visibility -&gt; Fix: Create alerts for failed stack states.<\/li>\n<li>Symptom: Too many cross-account permissions -&gt; Root cause: Overly permissive StackSet roles -&gt; Fix: Harden cross-account roles with least privilege.<\/li>\n<li>Symptom: Failure to import existing resources -&gt; Root cause: Misaligned resource config -&gt; Fix: Validate resource properties prior to import.<\/li>\n<li>Symptom: Slow recovery from region outage -&gt; Root cause: No cross-region stacks defined -&gt; Fix: Use StackSets and DR templates.<\/li>\n<\/ol>\n\n\n\n<p>Observability pitfalls highlighted above: 10, 16, 17, 22, 5.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Best Practices &amp; Operating Model<\/h2>\n\n\n\n<p>Ownership and on-call<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Infra teams own stack templates and deployment pipelines; service teams own service stacks.<\/li>\n<li>On-call rotations include a roster for infrastructure deployment failures.<\/li>\n<li>Define escalation paths for stack failures affecting production.<\/li>\n<\/ul>\n\n\n\n<p>Runbooks vs playbooks<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Runbook: Step-by-step remediation for a specific failure (e.g., rollback stack X).<\/li>\n<li>Playbook: Higher-level strategy for incident response (e.g., restore from backup).<\/li>\n<li>Keep runbooks short, executable, and linked in dashboards.<\/li>\n<\/ul>\n\n\n\n<p>Safe deployments (canary\/rollback)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use change sets and canary deployments where feasible.<\/li>\n<li>Automate health checks and traffic shifting for canary success criteria.<\/li>\n<li>Define rollback behavior: automatic for critical failures, manual for non-critical changes.<\/li>\n<\/ul>\n\n\n\n<p>Toil reduction and automation<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Encapsulate repeated patterns into modules or private registries.<\/li>\n<li>Automate routine cleanups for expired testing stacks.<\/li>\n<li>Use CI gates to catch policy and lint failures early.<\/li>\n<\/ul>\n\n\n\n<p>Security basics<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use least-privilege service roles for deployments.<\/li>\n<li>Avoid embedding secrets in templates; reference secret stores.<\/li>\n<li>Enforce policy-as-code to block risky resource types or configurations.<\/li>\n<\/ul>\n\n\n\n<p>Weekly\/monthly routines<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Weekly: Review failed stacks and change set backlog.<\/li>\n<li>Monthly: Run drift detection across critical stacks and review cost deltas.<\/li>\n<li>Quarterly: Audit stack policies, IAM roles, and permissions.<\/li>\n<\/ul>\n\n\n\n<p>What to review in postmortems related to CloudFormation<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Template changes and validation steps taken.<\/li>\n<li>CI\/CD gating and why failures passed or blocked.<\/li>\n<li>Drift detection findings and their resolution.<\/li>\n<li>Time to rollback and lessons to reduce recurrence.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Tooling &amp; Integration Map for CloudFormation (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Category<\/th>\n<th>What it does<\/th>\n<th>Key integrations<\/th>\n<th>Notes<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>I1<\/td>\n<td>CI\/CD<\/td>\n<td>Automates validate and deploy change sets<\/td>\n<td>VCS monitoring and approvals<\/td>\n<td>Use deploy roles and run in PR pipelines<\/td>\n<\/tr>\n<tr>\n<td>I2<\/td>\n<td>Monitoring<\/td>\n<td>Collects stack events and metrics<\/td>\n<td>Logs and alerting systems<\/td>\n<td>Correlate with resource metrics<\/td>\n<\/tr>\n<tr>\n<td>I3<\/td>\n<td>Policy-as-code<\/td>\n<td>Validates templates against rules<\/td>\n<td>CI and pre-deploy gates<\/td>\n<td>Prevents risky configurations<\/td>\n<\/tr>\n<tr>\n<td>I4<\/td>\n<td>Cost management<\/td>\n<td>Tracks cost deltas per stack<\/td>\n<td>Tagging and billing APIs<\/td>\n<td>Alert on unexpected increases<\/td>\n<\/tr>\n<tr>\n<td>I5<\/td>\n<td>Security scanning<\/td>\n<td>Scans templates for insecure patterns<\/td>\n<td>CI and scheduled scans<\/td>\n<td>Block or flag violations<\/td>\n<\/tr>\n<tr>\n<td>I6<\/td>\n<td>Secrets management<\/td>\n<td>Stores and references secrets securely<\/td>\n<td>Secret store integration<\/td>\n<td>Avoid outputs containing secrets<\/td>\n<\/tr>\n<tr>\n<td>I7<\/td>\n<td>Template registry<\/td>\n<td>Hosts reusable modules and types<\/td>\n<td>VCS or private registry<\/td>\n<td>Enables reuse and governance<\/td>\n<\/tr>\n<tr>\n<td>I8<\/td>\n<td>Cloud audit logs<\/td>\n<td>Tracks API calls and events<\/td>\n<td>CloudTrail style logs<\/td>\n<td>Crucial for incident forensics<\/td>\n<\/tr>\n<tr>\n<td>I9<\/td>\n<td>Testing frameworks<\/td>\n<td>Unit and integration tests for templates<\/td>\n<td>CI pipelines<\/td>\n<td>Validate resource creation paths<\/td>\n<\/tr>\n<tr>\n<td>I10<\/td>\n<td>Orchestration<\/td>\n<td>Workflow orchestration for complex deploys<\/td>\n<td>Step functions or runners<\/td>\n<td>Handle synchronous tasks and approvals<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently Asked Questions (FAQs)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What is the difference between CloudFormation and Terraform?<\/h3>\n\n\n\n<p>CloudFormation is provider-native declarative IaC, while Terraform is multi-provider and uses a maintained state file; differences include state handling and provider ecosystems.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can CloudFormation manage resources in multiple accounts?<\/h3>\n\n\n\n<p>Yes via StackSets, though it requires appropriate cross-account roles and permissions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do you handle secrets in templates?<\/h3>\n\n\n\n<p>Not store them in templates; reference secret management services or parameter stores.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What is a change set?<\/h3>\n\n\n\n<p>A preview mechanism showing the impact of proposed template changes before execution.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to prevent accidental deletion of critical stacks?<\/h3>\n\n\n\n<p>Enable termination protection and use stack policies to protect resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can I import existing resources into a stack?<\/h3>\n\n\n\n<p>Yes, resource import is supported but requires exact configuration alignment.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How is drift detection useful?<\/h3>\n\n\n\n<p>It finds manual or external changes that differ from the declared template state.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Should I use nested stacks or modular stacks?<\/h3>\n\n\n\n<p>Use nested stacks for reuse; prefer modular stacks for team ownership and smaller blast radii.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do I test CloudFormation templates?<\/h3>\n\n\n\n<p>Use linters, unit tests for modules, integration in staging, and change set previews.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What happens during rollback?<\/h3>\n\n\n\n<p>CloudFormation attempts to revert to the previous stable state, which may delete newly created resources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do I manage IAM permissions for deployments?<\/h3>\n\n\n\n<p>Create a deployment service role with least privilege required and log actions for auditing.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Does CloudFormation support custom resource types?<\/h3>\n\n\n\n<p>Yes via custom resources often implemented as provider-backed Lambdas or registry types.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to reduce deployment noise for on-call?<\/h3>\n\n\n\n<p>Filter non-critical events, aggregate similar notifications, and route low-priority events to tickets.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to manage large templates exceeding limits?<\/h3>\n\n\n\n<p>Use nested stacks or host templates in storage and reference them.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can I automate cost checks during deployment?<\/h3>\n\n\n\n<p>Yes by integrating cost estimation or policy checks into CI pipelines.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Are templates version-controlled?<\/h3>\n\n\n\n<p>They should be; template versioning provides traceability and rollback capability.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What are common security mistakes with CloudFormation?<\/h3>\n\n\n\n<p>Embedding secrets in outputs and overbroad IAM policies are common pitfalls.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How often should I run drift detection?<\/h3>\n\n\n\n<p>Frequency varies by environment; reasonable starting cadence is weekly for production.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p>CloudFormation provides a native, declarative path to provision and manage cloud resources reliably when used with robust CI\/CD, observability, and governance. It reduces manual toil, enforces standardization, and supports recoverable deployments. However, it needs disciplined lifecycle management, policy enforcement, and monitoring to avoid drift, security issues, and cost surprises.<\/p>\n\n\n\n<p>Next 7 days plan (5 bullets)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Day 1: Inventory existing stacks and enable tagging and stack event collection.<\/li>\n<li>Day 2: Add template linting to CI and block merges on validation failures.<\/li>\n<li>Day 3: Implement drift detection schedule for critical stacks.<\/li>\n<li>Day 4: Create on-call runbooks for stack rollback and failure triage.<\/li>\n<li>Day 5: Introduce policy-as-code checks in CI for IAM and expensive resource types.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Appendix \u2014 CloudFormation Keyword Cluster (SEO)<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Primary keywords<\/li>\n<li>cloudformation<\/li>\n<li>cloudformation template<\/li>\n<li>infrastructure as code<\/li>\n<li>IaC cloudformation<\/li>\n<li>\n<p>cloudformation stack<\/p>\n<\/li>\n<li>\n<p>Secondary keywords<\/p>\n<\/li>\n<li>change set cloudformation<\/li>\n<li>cloudformation drift detection<\/li>\n<li>nested stacks<\/li>\n<li>stack sets<\/li>\n<li>\n<p>cloudformation registry<\/p>\n<\/li>\n<li>\n<p>Long-tail questions<\/p>\n<\/li>\n<li>how to create a cloudformation template<\/li>\n<li>cloudformation change set example<\/li>\n<li>cloudformation vs terraform differences<\/li>\n<li>how does cloudformation drift detection work<\/li>\n<li>cloudformation nested stack best practices<\/li>\n<li>how to import resources into cloudformation<\/li>\n<li>cloudformation stack rollback causes<\/li>\n<li>cloudformation iam capabilities explained<\/li>\n<li>how to deploy cloudformation via ci cd<\/li>\n<li>cloudformation template size limit workarounds<\/li>\n<li>how to use parameters in cloudformation<\/li>\n<li>cloudformation outputs cross stack references<\/li>\n<li>cloudformation custom resource lambda example<\/li>\n<li>cloudformation stack sets multi account deployment<\/li>\n<li>cloudformation serverless sam vs cloudformation<\/li>\n<li>cloudformation ecs cluster template example<\/li>\n<li>cloudformation eks cluster template example<\/li>\n<li>cloudformation best practices for security<\/li>\n<li>cloudformation cost estimation before deploy<\/li>\n<li>\n<p>cloudformation change set review checklist<\/p>\n<\/li>\n<li>\n<p>Related terminology<\/p>\n<\/li>\n<li>template validation<\/li>\n<li>stack policy<\/li>\n<li>termination protection<\/li>\n<li>CAPABILITY_IAM<\/li>\n<li>resource import<\/li>\n<li>intrinsic functions<\/li>\n<li>Ref function<\/li>\n<li>FnGetAtt<\/li>\n<li>transforms and SAM<\/li>\n<li>custom resources<\/li>\n<li>service role for cloudformation<\/li>\n<li>stack events<\/li>\n<li>cloudtrail for cloudformation<\/li>\n<li>policy as code<\/li>\n<li>drift reports<\/li>\n<li>stack outputs<\/li>\n<li>importvalue cross stack<\/li>\n<li>nested stack composition<\/li>\n<li>stack dependencies<\/li>\n<li>stack lifecycle<\/li>\n<li>rollback behavior<\/li>\n<li>termination protection<\/li>\n<li>template linter<\/li>\n<li>stack tagging<\/li>\n<li>template registry<\/li>\n<li>change set execution<\/li>\n<li>stack success rate metric<\/li>\n<li>deployment latency<\/li>\n<li>orphaned resources<\/li>\n<li>template modularization<\/li>\n<li>automation runbooks<\/li>\n<li>observability for iaC<\/li>\n<li>deploy role least privilege<\/li>\n<li>secret manager integration<\/li>\n<li>cost management tags<\/li>\n<li>iam policy scoping<\/li>\n<li>stack naming conventions<\/li>\n<li>cross account role delegation<\/li>\n<li>cloudformation providers<\/li>\n<li>stack set governance<\/li>\n<li>stack import process<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>&#8212;<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-1090","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1090","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/comments?post=1090"}],"version-history":[{"count":0,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/posts\/1090\/revisions"}],"wp:attachment":[{"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/media?parent=1090"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/categories?post=1090"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devopsschool.org\/blog\/wp-json\/wp\/v2\/tags?post=1090"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}