AWS KMS Key
Does ZopNight manage AWS KMS Key?
KMS customer-managed keys bill a flat monthly fee per key plus per-request charges on cryptographic API calls, and a disabled key bills exactly like an active one. ZopNight inventories keys on the 6-hour cycle, attributes per-key cost from Cost Explorer or CUR 2.0, and recommends cleanup of unused and disabled keys.
Rules that fire on AWS KMS Key
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, cost tracking, and recommendations only. |
An AWS Key Management Service (KMS) customer-managed key encrypts data across AWS services, billed at a flat monthly fee per key plus API request charges. Keys accumulate over time, and disabled or unused keys keep billing their monthly fee.
The monthly fee nobody deletes
Each customer-managed key bills a fixed monthly amount from creation onward, with cryptographic API requests (encrypt, decrypt, generate-data-key) metered separately per call. AWS-managed keys, the ones services create on your behalf, are free, which is why the customer-managed population is the one to inventory. Two properties make key spend sticky: disabling a key does not stop its monthly fee, and deletion is deliberately hard, requiring a scheduled waiting period of 7 to 30 days before the key is destroyed. Keys pending deletion stop billing; disabled keys do not.
Key inventory through ZopNight’s eyes
A dedicated provider discovers every customer-managed key on the 6-hour cycle, with per-key cost attributed from Cost Explorer or CUR 2.0. Cleanup recommendations target two groups: unused keys, whose request activity is absent and which no current resource references, and disabled keys, which someone already judged inactive but which continue to bill monthly until they are scheduled for deletion. The monthly fee per key is small; the finding matters because keys are created programmatically, one per stack, per environment, per service, and populations run into the hundreds.
How key sprawl builds up
Infrastructure-as-code templates default to creating a fresh key per deployment instead of referencing a shared one, so every ephemeral environment leaves a key behind. Key rotation done manually (new key, repoint the alias) strands the old key without a deletion schedule. And imported-material or multi-region key setups get abandoned mid-project, leaving replicas billing in regions nothing uses.
Working the KMS console list
The KMS console lists customer-managed keys with state and alias per region. For candidates, CloudTrail shows whether any cryptographic calls still hit the key, and the key’s grants and aliases reveal remaining dependents. Schedule deletion rather than merely disabling. Disabled is a billing state, not an end state.