A compliance requirement states that a dataset must be encrypted with "keys we control". In AWS terms, what concretely changes when you move that data from an AWS managed KMS key to a customer managed key, and what does that choice cost you?
answer
- same crypto, different policy ownership
- who can edit the key policy?
- AWS managed keys can't cross accounts
- revocation and audit are the real gains
- you now own an availability dependency
basics
~20 sA customer managed key gives you an editable key policy, so you can grant, condition and revoke use independently of the service's own permissions, share with other accounts, and audit every use. The cost is a monthly key charge, per-request charges, and a hard availability dependency on that policy staying correct.
solid answer
~50 sAWS gives you three tiers. AWS owned keys sit outside your account entirely — you cannot see them, policy them or audit them. AWS managed keys appear in your account under an `aws/<service>` alias and their use is visible in CloudTrail, but the key policy is fixed by AWS, so you cannot narrow access, condition it, or share it across accounts. A customer managed key is the one where the compliance ask is actually satisfied: you author its key policy, which becomes a second authorization layer that must independently allow every caller, you can scope grants with condition keys, and you can revoke a whole dataset by editing one policy. It is also the only tier that permits cross-account access. What it costs is a small monthly charge per key plus per-request charges, and — more importantly — an availability dependency: a wrong policy edit or a scheduled deletion makes the data unreadable everywhere at once.
go deeper
Know the three tiers by name — AWS owned, AWS managed, customer managed — and that only the last one has a key policy you write. That single fact answers most of what is asked at this level.
Explain what the editable key policy buys: an independent authorization check, condition keys, cross-account grants, and CloudTrail visibility of every use. Be able to say why an AWS managed key blocks sharing.
Weigh it as a tradeoff. Name the billed cost, the request-rate ceiling, and the availability dependency you take on, and point out that switching keys later means re-encrypting rather than reconfiguring.
Own the key strategy: how many keys and along which boundary, who administers policies versus resources, what change control and alerting protect the critical path, and how you interpret a "keys we control" requirement before it drives an expensive design.
## Three tiers, and what actually differs The cryptography is identical across all three; what differs is ownership of the *policy* and visibility of the *use*. **AWS owned keys** live in an AWS-owned account and are shared across many customers. You cannot view them, cannot see them in your key list, cannot apply any policy to them, and their use does not appear in your CloudTrail. They are free and invisible. For data with no compliance story attached this is genuinely fine — but you can say nothing about the key to an auditor, which is usually what ends the discussion. **AWS managed keys** are created per service in your account, appear under an alias like `aws/s3` or `aws/ebs`, and their use is recorded in your CloudTrail. That is a real step up: you can answer "who decrypted this, and when". But the key policy is authored and maintained by AWS and you cannot edit it. The practical consequences are sharp: you cannot restrict who may use the key beyond what the service's own permissions already say, you cannot add condition keys, and you cannot name a principal from another account — so data under an AWS managed key can never be shared cross-account. **Customer managed keys** are keys you create. You write the key policy, and that policy is an independent authorization layer: every caller must be allowed by it *in addition to* being allowed the service action. This is what "keys we control" means in practice. ## What you gain, concretely - **A second, independently administered gate.** A security team can own key policies while a platform team owns bucket and resource policies, and neither can unilaterally grant read access to the data. That separation of duties is very hard to build any other way. - **Conditional access.** You can constrain use with condition keys — for example requiring that the key be used through a particular service, or that the calling principal belong to your organization — so a stolen role in a partner account cannot use the key for anything but its intended path. - **Cross-account sharing.** Only a customer managed key can name an external principal, which makes it a prerequisite for sharing encrypted objects, snapshots or backups with another account. - **Revocation with one edit.** Removing a statement from the key policy renders that dataset unreadable to the affected principals immediately, without touching hundreds of resource policies. In an incident, that is a real containment lever. - **Complete audit.** Every `Decrypt` and data-key request against the key lands in CloudTrail with the calling principal, which is the evidence an auditor is asking for. ## What it costs Two kinds of cost, and the second is the one candidates forget. The **billed** cost is small: a monthly charge per key plus per-request charges for the KMS API calls on the data path. It is easy to under-estimate at very high request rates, and KMS also enforces a request-rate limit per account and Region, so a hot workload can hit throttling that surfaces as failed reads or writes. The **operational** cost is the serious one: you have taken on an availability dependency. The key policy is now on the critical path for every read of that data. A well-meaning tightening that drops a service-linked principal takes an application down. Scheduling key deletion — which has a mandatory waiting period precisely because it is irreversible — destroys access to everything encrypted under it. Disabling a key does the same, reversibly. You now need change control on key policies, alarms on key state changes, and a clear understanding of which workloads depend on which key. ## The decision, and the part that is irreversible Use the service default for data with no sharing story and no audit requirement, because it is free and has no failure mode you own. Use a customer managed key when any of these is true: another account may need access, an auditor will ask who can decrypt, you want the ability to revoke a dataset independently, or you need conditions on key use. The important asymmetry is that this is much cheaper to decide up front. Changing a bucket's default key does not re-encrypt existing objects, and an encrypted RDS instance or EBS volume cannot simply be re-pointed at a different key. Moving a dataset from an AWS managed key to a customer managed key is a copy-and-re-encrypt project, sized by how much data you have. Interviewers like this point because it converts a governance question into an engineering one. ## The claim to be careful with "Keys we control" sometimes means something stronger than a customer managed key — a requirement that AWS itself cannot use the key material, which points at imported key material or a dedicated hardware layer, with correspondingly heavier operations. Clarify which of the two the requirement means before designing for it, because the answers differ substantially in cost and in what happens when you lose access.
- A team says a customer managed key is unnecessary because AWS managed keys already encrypt with the same strength. What is the counter?The strength is identical — that is not the axis. What differs is control: you cannot edit an AWS managed key's policy, so you cannot narrow access, add conditions, share cross-account, or revoke a dataset independently of its resource policies. If none of those matter for this data, they are right and the free option is correct.
- What is the risk when a single customer managed key protects data for many teams?Blast radius in both directions. One policy edit affects every workload under the key, so tightening for one team can break another, and a compromised principal allowed on the key reaches all of it. Segmenting keys by data classification or by team makes revocation surgical, at the cost of more keys to administer and more monthly charges.
- You inherit a large dataset encrypted with the service's AWS managed key and now need to share it with a partner account. What is the path?There is no in-place fix — that key's policy cannot name an external principal. You create a customer managed key, re-encrypt by copying the data under the new key, then grant the partner in the key policy and in their own identity policy. Budget it as a data-movement project, and switch the default for new writes first so the backlog stops growing.
saying these in an interview costs you the question
- Claims a customer managed key uses stronger encryption
- Thinks changing the default key re-encrypts existing data
- Ignores that key policy edits can take production down
- Assumes AWS managed keys can be shared across accounts
- Treats KMS request charges and rate limits as negligible at any scale