# EC2 EBS Optimization Not Enabled

> Running EC2 instances from the eight opt-in families (c1, c3, g2, i2, m1, m2, m3, and r3) that report ebs_optimized=false get flagged as a $0 compliance finding. ZopNight abstains on Nitro and default-optimized generations, where the false flag is cosmetic, and claims no savings.

Source: https://zop.dev/integrations/aws/recommendations/ec2-ebs-optimization-not-enabled
Updated: 2026-08-19

---

## The opt-in instance families this applies to

- resource.Status: running
- resource.Metadata: ebs_optimized (JSON bool, via metadataBoolRaw). Fires only when the flag is present AND false; an absent flag abstains (item T0073). The prior tag: ebs_optimized=false was a dead contract.
- #1906 (G2): the discoverer now OMITS ebs_optimized when the value is unknown (nil) instead of writing false, so the rule abstains on legacy instances whose EBS-optimized state was never resolved rather than over-firing a false "not enabled" rec on them.
- resource.InstanceType: instance-generation gate. The rule only fires for families that AWS documents as genuinely opt-in for EBS optimization: c1, c3, g2, i2, m1, m2, m3, r3. It abstains for every other family, which falls into one of two buckets: (a) EBS-optimized by default and immutable: m4, c4, r4, d2, x1, p2 and all current-generation Nitro families (t3/t3a/t4g, m5+/c5+/r5+, i3en/i4i, g4/g5, p3/p4, etc.), where ebs_optimized=false is a cosmetic API artifact, not a gap; or (b) EBS optimization unsupported entirely (t1, t2), where there is no attribute to enable. An empty/unparseable instance type abstains fail-safe.

## Why this rule claims no dollars

$0 compliance: CurrentCostUSD/OptimizedCostUSD/SavingsUSD all 0 (no FABRICATED_SAVINGS)

## Enabling the attribute on a stopped instance

1. Confirm the instance is in the opt-in family list (see gate above); non-opt-in families abstain and never reach this remediation
2. Stop the EC2 instance
3. Modify instance attribute to enable EBS optimization
4. Start the instance