ACM, STS & CloudHSM
Three security services that round out the AWS security toolkit: ACM for managed TLS certificates, STS for temporary credential vending, and CloudHSM for dedicated, single-tenant hardware security modules.
Want a visual for this topic?
Generate a diagram tailored to ACM, STS & CloudHSM — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain how ACM removes manual TLS certificate renewal for supported AWS services
- •Trace what an STS AssumeRole call actually returns and why it's temporary
- •Explain what CloudHSM offers that KMS doesn't, and why that matters for certain compliance requirements
- •Choose correctly between KMS and CloudHSM for a given key-management requirement
What is it?
AWS Certificate Manager (ACM) provisions, manages, and automatically renews TLS/SSL certificates for use with integrated AWS services like CloudFront, ALB, and API Gateway, eliminating manual certificate lifecycle management. AWS Security Token Service (STS) issues short-lived, temporary security credentials that let an IAM principal assume a role (or federate an external identity) with a specific, time-limited set of permissions, rather than relying on long-lived access keys. AWS CloudHSM provides dedicated, single-tenant hardware security modules (physical, FIPS-validated cryptographic hardware) for organizations with cryptographic key requirements that KMS's shared, managed model can't satisfy.
Why it exists
Manually tracking and renewing TLS certificates across many services before they expire is tedious and a common source of real outages when someone forgets — ACM exists to make certificate lifecycle management fully automatic for integrated services. Long-lived IAM access keys are a persistent security liability if leaked, since they remain valid indefinitely until manually rotated or revoked — STS exists to make temporary, automatically-expiring credentials the default way principals gain access, dramatically shrinking the blast radius of a leaked credential. Some organizations have compliance or contractual requirements mandating dedicated (not shared/multi-tenant) hardware for cryptographic key storage and operations, which KMS's underlying shared HSM fleet doesn't satisfy — CloudHSM exists to offer single-tenant hardware specifically for those cases.
Problem it solves
ACM solves certificate expiry outages and the operational overhead of manual renewal for supported services. STS solves the long-lived-credential risk problem, letting applications and users assume time-limited roles instead of embedding permanent access keys. CloudHSM solves compliance and control requirements around dedicated (not shared) cryptographic hardware, and also supports cryptographic operations and algorithms beyond what KMS natively exposes, useful for specific legacy or regulatory requirements.
Intuition
ACM is like a subscription service that automatically renews your car's registration before it expires, instead of you needing to remember and manually file paperwork every year — and if you forget with a manual process, the consequence (an expired cert breaking HTTPS) is a real outage. STS temporary credentials are like a visitor badge that automatically stops working at 6pm, versus handing someone a permanent building key that works forever until someone remembers to physically take it back. CloudHSM is like renting your own private, locked vault with your own key, instead of using a shared bank safety-deposit facility (KMS) where the bank (AWS) still operates the underlying vault infrastructure, even though your specific box inside it is private to you.
Analogy
Think of KMS as a well-run apartment building's shared, managed mail room — secure, convenient, professionally operated, but the building manages the underlying room infrastructure. CloudHSM is choosing to install your own personal safe inside your own private space instead, where you alone control the physical hardware, at the cost of having to manage more of the operational details yourself.
Technical explanation
ACM certificates issued for use with integrated services (CloudFront, ALB/NLB via ACM integration, API Gateway) are automatically renewed by AWS as long as domain validation (DNS-based, typically via a CNAME record) remains correctly configured — no action is needed from the certificate owner for renewal itself. STS's AssumeRole (and related calls like AssumeRoleWithWebIdentity for federation, or AssumeRoleWithSAML) returns temporary credentials scoped to the assumed role's permission policy, with an expiration enforced server-side by AWS regardless of whether the credentials are explicitly revoked — this is the mechanism underlying EC2 instance profiles, Lambda execution roles, and cross-account access, all of which work via STS under the hood even when a user never calls it directly. CloudHSM clusters are FIPS 140-2 Level 3 validated, single-tenant hardware, giving direct administrative control over the HSM (including the ability to use PKCS#11, Java JCE, or Microsoft CNG/KSP standard cryptographic interfaces directly against the HSM), a level of low-level control and standards-compliance KMS's managed API doesn't expose, and CloudHSM specifically supports use cases requiring these exact standard interfaces or dedicated-hardware compliance attestations.
Architecture
A public-facing web application uses ACM-issued certificates on its ALB and CloudFront distribution, both auto-renewing indefinitely with zero manual certificate management. Its Lambda functions use execution roles, meaning every invocation implicitly calls STS behind the scenes to obtain temporary credentials scoped to exactly that function's permissions, with no long-lived access keys stored anywhere in the function's configuration. Separately, a payments company processing card data uses CloudHSM specifically because their compliance framework requires dedicated, single-tenant hardware for cryptographic key operations, a requirement KMS's shared model cannot satisfy regardless of KMS's own strong security properties.
Workflow
- Request and validate an ACM certificate (typically via DNS validation) for any domain served through CloudFront, ALB, or API Gateway. 2) Default to IAM roles (which use STS under the hood) for any workload needing AWS permissions, instead of creating and distributing long-lived IAM user access keys. 3) Evaluate CloudHSM only when a specific compliance, contractual, or standards-interface (PKCS#11/JCE/CNG) requirement exists that KMS cannot satisfy — otherwise KMS remains the simpler, fully managed default for the vast majority of encryption key needs.
Example
A healthcare SaaS company uses ACM certificates across all customer-facing endpoints (zero renewal incidents since adoption), uses STS-based role assumption exclusively for both human and application access (no long-lived access keys exist anywhere in their account, verified via IAM Access Analyzer), and uses CloudHSM specifically for one legacy on-premises-originated encryption workflow that requires direct PKCS#11 interface access their compliance auditor mandated stay on dedicated hardware.
Real-world usage
ACM is the default, near-universal choice for TLS certificates on any AWS-hosted public endpoint using CloudFront, ALB, or API Gateway. STS-based temporary credentials (via IAM roles) are AWS's own explicitly recommended default over long-lived access keys for essentially all use cases, including EC2 instance profiles, Lambda execution roles, and cross-account access. CloudHSM sees far more limited but real adoption, concentrated in financial services, healthcare, and government workloads with specific dedicated-hardware compliance mandates.
Trade-offs
ACM trades a small amount of certificate portability for eliminating renewal risk entirely — an easy call for nearly every AWS-hosted endpoint. STS-based temporary credentials trade a small amount of application-side complexity (handling credential refresh) for a dramatically reduced security blast radius versus long-lived keys — a tradeoff AWS itself recommends taking essentially universally. CloudHSM trades significant additional cost and operational responsibility for dedicated, single-tenant hardware control — only worth it when a genuine compliance or standards-interface requirement exists; otherwise KMS's fully managed, shared-tenant model is simpler and cheaper for the same core encryption needs.
Visual explanation
Picture an ALB with an ACM-issued certificate automatically renewing every few months with zero manual action, as long as the required DNS validation record remains in place. Picture an application calling STS's AssumeRole API, receiving back a temporary access key ID, secret key, and session token valid for a configured duration (from 15 minutes up to a maximum depending on the role's settings), after which those credentials simply stop working without any explicit revocation needed. Picture CloudHSM as a dedicated cluster of physical hardware security modules provisioned specifically for one AWS account, entirely separate from the multi-tenant HSM fleet underlying KMS.
Advantages
- —
ACM eliminates certificate expiry outages entirely for integrated services, with zero ongoing manual renewal effort
- —
STS-based temporary credentials dramatically shrink the blast radius of a leaked credential, since they expire automatically without requiring active revocation
- —
CloudHSM gives direct administrative control over dedicated hardware and standard cryptographic interfaces KMS doesn't expose
- —
All three integrate natively with the rest of AWS's IAM and service ecosystem, without custom tooling
Disadvantages
- —
ACM certificates used with integrated services can't be exported for use outside AWS in most cases, limiting portability
- —
STS's short-lived credentials require applications to handle credential refresh correctly, adding a small amount of implementation complexity versus a static key
- —
CloudHSM requires you to manage the HSM cluster's administration and key backup yourself, a meaningfully larger operational burden than KMS's fully managed model
- —
CloudHSM is significantly more expensive than KMS, appropriate only when its specific dedicated-hardware requirement genuinely applies
Common mistakes
- —
Letting an ACM DNS validation record lapse or get removed, silently breaking automatic renewal despite ACM otherwise being 'automatic'
- —
Continuing to use long-lived IAM user access keys for workloads that could use an IAM role (and STS) instead, unnecessarily keeping a persistent leaked-credential risk alive
- —
Choosing CloudHSM by default for 'extra security' without a genuine compliance or interface requirement, paying significantly more and taking on more operational burden than KMS would have required for the same underlying protection
- —
Assuming CloudHSM keys can be used interchangeably with KMS-integrated services without additional integration work — CloudHSM's dedicated hardware model requires more direct application-level integration than KMS's API-based model
In the AWS Console
- 1
AWS Console → Certificate Manager → Request a certificate
Enter the domain name(s), choose DNS validation (recommended over email validation), and add the generated CNAME record to your DNS.
Once DNS validation is in place and remains in place, ACM handles all future renewals automatically with no further action needed.
- 2
IAM → Roles → Create role → Trusted entity type
Create a role with a defined trust policy (which principals can assume it) and permission policy (what the assumed role can do) — this role is what STS issues temporary credentials against.
This is the standard pattern underlying EC2 instance profiles, Lambda execution roles, and cross-account access — all use STS AssumeRole behind the scenes.
- 3
AWS Console → CloudHSM → Create cluster
Provision a CloudHSM cluster across multiple AZs for high availability, then initialize and activate it before creating HSM users and keys.
Unlike KMS, you are responsible for cluster administration, including key backup strategy — losing quorum access to a CloudHSM cluster without a proper backup can mean unrecoverable key loss.
🎤 Interview questions
How does ACM avoid the classic 'certificate expired and broke production HTTPS' incident? (Listen for: automatic renewal for certificates on integrated services like CloudFront/ALB, as long as DNS validation remains correctly configured — no manual renewal action needed.)
Why does AWS recommend IAM roles (and STS-issued temporary credentials) over long-lived IAM user access keys? (Listen for: temporary credentials expire automatically without requiring active revocation, dramatically shrinking the blast radius if credentials are ever leaked.)
What does CloudHSM offer that KMS fundamentally cannot, regardless of KMS's own security properties? (Listen for: dedicated, single-tenant physical hardware — KMS's underlying HSM fleet is shared/multi-tenant, which some compliance frameworks explicitly disallow.)
What's the operational cost of choosing CloudHSM over KMS? (Listen for: you become responsible for cluster administration and key backup yourself; losing quorum access without a proper backup can mean unrecoverable key loss, unlike KMS's fully managed model.)
What actually happens when an EC2 instance with an attached instance profile calls an AWS API? (Listen for: behind the scenes, the instance profile mechanism uses STS to obtain temporary credentials scoped to the role's permissions, refreshed automatically before expiry — no long-lived keys are stored on the instance.)
📂 Subtopics
What Actually Happens During an STS AssumeRole Call
The concrete request/response mechanics behind temporary credential vending, and where it happens invisibly.
~8 min
KMS vs CloudHSM: Choosing Correctly
A direct decision framework for the most commonly confused pair in the AWS security-services toolkit.
~8 min