When you update a CloudFormation stack, every changed property falls into one of three categories. The category is **per-property, per-resource-type** — not per-resource — and is documented in the AWS resource and property types reference under `Update requires:`. ## The three update behaviors | Behavior | What CFN does | Physical ID | Data impact | |----------|---------------|-------------|-------------| | **No Interruption** | Modifies in place | Unchanged | None | | **Some Interruption** | Modifies in place with brief downtime | Unchanged | Service-specific (e.g., EC2 reboot) | | **Replacement** | Creates new resource, updates dependent references, deletes old | **New ID** | **All resource state lost unless externally backed up** | ## The replacement trap The Replacement path is the dangerous one because it's triggered by changes that *look* cosmetic: - `AWS::EC2::Instance` `AvailabilityZone` change → new instance - `AWS::RDS::DBInstance` `Port` change → new DB instance, **all data gone** unless a snapshot was taken first - Renaming a resource's **logical name** in the template → equivalent to delete + create Even adding or removing a property whose presence requires replacement triggers a full replacement, regardless of whether the value would have changed. ## Cascading via `!Ref` / `!GetAtt` When CFN replaces a resource, it walks downstream: any other resource that uses `!Ref` or `!GetAtt` against the replaced resource is also updated. This can cascade further if those updates themselves are replacements. A single innocuous-looking change can ripple through the stack. ## Operational implication Before any update touching a stateful resource (RDS, ElastiCache, EBS volumes), check the property's `Update requires:` field. If it says `Replacement`: 1. Snapshot or back up the resource's data first 2. Plan the application's behavior during the cutover (DNS changes, connection retries) 3. Verify the application uses the *new* property value (e.g., new port) 4. Restore data into the replacement if needed CloudFormation gives you no special warning at update-execute time — the only signal is the property reference docs you should have consulted before submitting. ## Validation tools won't catch this - `validate-template` checks JSON/YAML syntax only — not whether your changes will replace - `cfn-lint` and `rain fmt` catch some property-validity issues, not replacement implications - **Change sets do show replacement intent** (`Replacement: True` in property changes) — see [[CFN Change Sets Preview-Execute]] ## Related - [[CFN Change Sets Preview-Execute]] - [[CFN Failure Rollback Behavior]]