In AWS KMS, what is the practical difference between an AWS owned key, an AWS managed key, and a customer managed key?
answer
- ask who controls the policy
- aws/ aliases you cannot edit
- cross-account needs your own key
- only one kind can be deleted or disabled
basics
~20 sThey differ in who controls the key policy. AWS owned keys are invisible and shared across customers. AWS managed keys appear in your account under aws/ aliases but their policy is fixed. Only customer managed keys let you set policy, rotation and deletion.
solid answer
~50 sAWS owned keys belong to the service, live outside your account, and you cannot see, audit, or control them — they are the free default some services use. AWS managed keys are created for you per service, show up under aliases such as `aws/rds` or `aws/ebs`, are visible in CloudTrail, rotate automatically once a year, and cost nothing per month — but you cannot edit their key policy, disable them, or delete them, so they can never be shared cross-account. A customer managed key is one you create: you write the key policy, choose symmetric or asymmetric, control rotation, enable or disable it, schedule deletion, use it in grants, and share it with other accounts. That control is what you pay a monthly per-key charge plus per-request charges for. If you need cross-account access, explicit key-level policy, or cryptographic erasure, only a customer managed key qualifies.
go deeper
Be able to state the three types and the one-line difference: AWS owned is invisible, AWS managed is visible but not editable, customer managed is fully yours. Mention that only the last one can be shared or deleted.
Explain the concrete consequences — no policy editing means no cross-account use, no disable, no scheduled deletion — and know that the price of control is a per-key monthly charge on top of request charges.
Frame it as a decision made once and reversed expensively. Show that you would pick a customer managed key wherever cross-account access, key-level conditions, incident-time disable, or cryptographic erasure is plausibly in the future.
Set the standard for the organisation: which workloads mandate customer managed keys, who administers them, how aliases are named across Regions and accounts, and how the per-key charge is kept from scaling with tenants.
## Three ownership models, one real distinction AWS KMS classifies keys by who controls them. The distinction that matters in an interview is not naming the three, it is knowing what each model takes away. **AWS owned keys** are held and managed by an AWS service across many customers. They do not appear in your account, they have no ARN you can reference, no key policy you can inspect, and no line item on your bill. Several services use one when you enable encryption without naming a key. They are the right default for data whose confidentiality requirement is "encrypted at rest, no further questions" — and unsuitable the moment anyone asks you to prove *which* key protected a record or to make that record unreadable on demand. **AWS managed keys** are created in your account, one per service that needs one, and carry aliases of the form `aws/<service>` — `aws/s3`, `aws/rds`, `aws/ebs`, `aws/secretsmanager`. You can see them in the console, they have real ARNs, and their use shows up in CloudTrail, which is a genuine step up in auditability. The catch is that AWS owns the lifecycle: the key policy is generated and maintained by AWS and you cannot edit it, you cannot disable the key, you cannot schedule it for deletion, and the automatic annual rotation is not configurable. Because the policy cannot be edited, an AWS managed key can never be shared with another account. They carry no monthly key charge; you pay for the API requests made against them. **Customer managed keys** are keys you create yourself with `CreateKey`, and they are the only kind that gives you the full surface: - You author the key policy, and can add grants and condition keys. - You choose the key spec — symmetric encryption, asymmetric (RSA or ECC) for encrypt/decrypt or sign/verify, HMAC, or a key with imported material. - You control automatic rotation, including turning it off, and can rotate on demand. - You can disable the key (instant, reversible) or schedule deletion with a waiting period of 7 to 30 days (irreversible once it elapses). - You can share it with other accounts and use it with multi-Region replicas. - You get a per-key monthly charge plus per-request charges. As of 2025 the monthly charge is roughly one dollar per key, per Region, including each multi-Region replica. ## Choosing between them Reach for a customer managed key when any of these are true: another account must use the key; you need a policy condition scoping who may decrypt what; you must be able to make data unreadable by destroying the key (cryptographic erasure); an auditor requires evidence of key ownership and rotation policy; or you want to disable a key quickly during an incident. None of these are possible with an AWS managed key, and the migration afterwards is expensive because existing ciphertext stays bound to the old key. Reach for an AWS managed key when the requirement is simply "encrypted with an auditable key" and you do not want to own key administration for every service in every Region. The trap is the opposite of over-engineering: teams pick AWS managed keys for convenience, then discover a year later that a partner account must read the data, and every object has to be re-encrypted. ## Aliases and identification All KMS keys are identified by a key ID (a UUID) or a full ARN; the UUID is unmemorable and per-Region, so most code refers to keys through an **alias** — a friendly name such as `alias/payments` that you create and can repoint to a different key later. Aliases are Region-specific, one alias points to at most one key at a time, and `aws/*` aliases are reserved for AWS managed keys. Using an alias rather than a hardcoded key ID is what makes manual key replacement possible without a code deploy, and the `kms:ResourceAliases` condition key lets a policy be written in terms of aliases rather than IDs. ## A note on cost shape The monthly per-key charge is small, but it is per key per Region, so a design that mints a key per tenant or per environment multiplies it directly. Request charges are usually the larger line for high-volume systems — which is exactly why envelope encryption and data-key reuse matter more to the bill than the number of keys does.
- Your data is currently encrypted with an AWS managed key and a partner account now needs to read it. What has to happen?You cannot share an AWS managed key, because its key policy is not editable. You create a customer managed key, allow the partner in its key policy, and re-encrypt or re-write the data under the new key — for an object store that usually means copying every object. The lesson is that the choice is cheap up front and expensive to reverse.
- How do you make a set of records permanently unreadable without deleting them?Encrypt them under a dedicated customer managed key and schedule that key for deletion, with a waiting period between 7 and 30 days. Once it elapses the key material is gone and every data key wrapped under it is unrecoverable. This cryptographic erasure is impossible with AWS owned or AWS managed keys, since you cannot delete them.
- Why refer to a KMS key by alias rather than by key ID in application config?An alias such as `alias/payments` is a stable, readable indirection you can repoint to a different key with `UpdateAlias`, so replacing a key does not require a code or config deployment. Aliases are Region-scoped, which also lets the same config string resolve to the correct local key in each Region.
saying these in an interview costs you the question
- Believes you can edit an AWS managed key's policy
- Thinks AWS managed keys can be shared cross-account
- Claims AWS owned keys appear in your CloudTrail and console
- Says customer managed keys are free to keep
- Assumes any KMS key can be deleted on demand