Native-cloud reference
What is AWS termination protection?
Termination protection is a flag that prevents an AWS resource from being deleted until the flag is explicitly turned off. It is available on EC2 instances, CloudFormation stacks, and (under the name “deletion protection”) on RDS clusters and other services. The protection does not restrict any other operation — it applies only to the delete action.
What does termination protection actually block?
Termination protection blocks the delete API call on the protected resource. It does not restrict reads, writes, configuration changes, or any other operation against that resource.
For an EC2 instance, enabling termination protection means that ec2:TerminateInstances will return an error for that instance. The instance can still be stopped, rebooted, or modified. For a CloudFormation stack, protection prevents the stack from being deleted through the console, CLI, or API. Individual resources within the stack can still be modified by operations that do not involve stack deletion.
How do you enable it?
For EC2 instances, termination protection is available in the console under Instance Settings, or via the CLI:
aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef0 \
--disable-api-termination
For CloudFormation stacks, enable it at creation time or update it afterward:
aws cloudformation update-termination-protection \
--stack-name my-production-stack \
--enable-termination-protection
For RDS clusters, the equivalent is deletion protection, which is a separate flag but serves the same function.
What is it good for?
Termination protection is well-suited to one specific problem: someone with legitimate access making a mistake. An operator who accidentally targets the wrong instance ID, a script that runs against production instead of staging, a console click that hits the wrong row — these are the scenarios it addresses. For this class of error, it works reliably. The extra step required to disable protection before deleting creates a moment of friction that catches a meaningful portion of accidental deletions before they happen.
AWS recommends enabling it on any resource that would be painful to recreate, particularly long-running EC2 instances with state that is not captured elsewhere, and production CloudFormation stacks that manage critical infrastructure.
What does termination protection not cover?
Termination protection does not defend against intentional deletion by someone who holds the right IAM permissions. Disabling the flag requires only the ec2:ModifyInstanceAttribute permission (for EC2) or cloudformation:UpdateTerminationProtection (for stacks) — permissions that are commonly held by anyone with developer or operator access to the account.
An automated script that wants to delete a protected instance can simply disable protection first and then delete. An attacker with account access can do the same. Termination protection also does nothing for the data held by a resource: an EC2 instance’s EBS volumes can be detached and deleted independently of the instance’s termination status.
The boundary it cannot cross is intent. It cannot evaluate whether the person disabling protection is doing so for a legitimate planned operation or for a destructive one. Distinguishing between those two cases — and requiring additional approval or review for high-risk deletions regardless of whether protection was disabled first — is where guardrails at the action layer add coverage that termination protection alone cannot provide. Korvalis monitors for the pattern of disable-then-delete and can require a second approval before the deletion proceeds.
Common questions
Does termination protection stop a determined attacker?
No. Anyone with permission to modify the instance or stack can disable protection and then delete. It stops accidents, not intent. That is its purpose, and it does that job well.
Should I enable termination protection on all production resources?
On anything that would hurt to lose accidentally, yes. EC2 instances, RDS clusters (with deletion protection), and CloudFormation stacks are the most common candidates.
Korvalis enforces guardrails, JIT access, and intent-based detection inside your own cloud account.See plans or join the waitlist.