AWS Certificate Manager and AWS Private Certificate Authority solve related problems, but they sit at different layers of public-key infrastructure. Certificate Manager, usually called ACM, is the certificate lifecycle service most AWS architects encounter when they need TLS certificates on integrated services such as Application Load Balancers, CloudFront distributions, and API Gateway endpoints. AWS Private CA is the managed certificate-authority service used when an organization needs to create and operate its own private trust hierarchy for internal identities, private endpoints, devices, workloads, or mutual TLS. Knowing which layer a design actually needs is part of the data-protection and infrastructure-security reasoning expected in AWS Certified Security – Specialty SCS-C03.
The quickest distinction is trust. A public ACM certificate can be trusted by ordinary browsers and operating systems because it chains to a public root that is already in their trust stores. A certificate issued from a private CA is trusted only by clients that trust that private hierarchy. ACM can also manage private certificates that are issued through AWS Private CA, so the services are not mutually exclusive. The design question is whether you primarily need certificate lifecycle management for AWS endpoints, or a private certificate authority that defines who your organization trusts.
ACM is the AWS-facing certificate lifecycle layer
ACM can request public certificates, request private certificates when it is connected to AWS Private CA, and import externally issued certificates. For many AWS workloads, that makes ACM the simplest place to manage server certificates. An architect can associate an ACM certificate with a supported service instead of manually installing a certificate and private key on every instance.
That integration changes the operating model. AWS services can use the certificate while ACM handles renewal for eligible managed certificates. The application team is no longer building a cron job that watches expiration dates, requests a replacement, copies a private key, and restarts a listener. For internet-facing HTTPS endpoints, this is often the strongest reason to start with ACM rather than with a custom PKI design.
ACM still has service boundaries. Certificates are Regional resources for most integrations, and CloudFront expects its viewer certificate in the US East (N. Virginia) Region. An imported certificate also has a different lifecycle from an ACM-issued certificate because the organization remains responsible for replacing it when needed. The platform therefore reduces certificate operations, but only when the deployment follows the integration and renewal rules of the consuming AWS service.
Private CA creates the trust hierarchy ACM does not replace
A private certificate authority is not merely another storage location for certificates. It is a signing authority that establishes a private chain of trust. AWS Private CA can create root and subordinate CAs, and those CAs can issue certificates for servers, users, workloads, devices, and other identities that participate in an organization’s private PKI.
The root CA is the trust anchor. Subordinate CAs can divide authority by business unit, environment, geography, workload class, or policy. A security team might keep a root CA tightly controlled while allowing separate subordinate CAs for production services and corporate devices. The hierarchy can limit the operational blast radius of one CA and make issuance policy easier to reason about.
Because the hierarchy is private, external clients do not automatically trust it. The organization must distribute the appropriate root or intermediate trust to the systems that validate those certificates. That is exactly what makes private PKI useful for internal trust: the enterprise decides which issuers are trusted rather than relying on the public web PKI.
Public TLS and private PKI start from different trust audiences
For an internet-facing customer portal, the trust audience includes arbitrary browsers and mobile devices that the company does not control. Publicly trusted certificates are therefore the normal choice. ACM can issue a public certificate and attach it to a supported AWS endpoint, giving clients a chain they already know how to validate.
For an internal service mesh, factory device fleet, private API, or administrative application, the trust audience may be only company-managed systems. A private CA can be more appropriate because the organization can issue certificates under its own policies, define certificate templates and validity periods, and distribute trust only to approved clients. The same logic applies to mutual TLS, where both sides authenticate with certificates rather than only the server presenting one.
It is useful to remember that SSL/TLS certificates do not become public or private because of the encryption algorithm. The important difference here is who issued the certificate, which trust anchor validates it, and whether the relying client trusts that chain.
ACM and Private CA often work together
A common architecture uses Private CA as the issuer and ACM as the lifecycle interface for certificates consumed by integrated AWS services. In that model, Private CA defines the private trust hierarchy, while ACM requests and manages certificates from that hierarchy for supported endpoints. This avoids turning the design into an artificial choice between two services that can be complementary.
Another design may issue certificates directly from Private CA when the application has its own enrollment workflow or when the certificate must be delivered to a workload outside the normal ACM integration model. Direct issuance is useful when the requester supplies a certificate signing request and needs the resulting certificate for software, devices, or infrastructure that manages its own private key.
The private-key boundary matters. In a managed AWS integration, the goal may be to avoid exposing the private key to application operators at all. In a direct private-PKI workflow, the workload may generate and protect its own key, submit a CSR, and receive a signed certificate. Those are materially different security designs even though both end with an X.509 certificate.
Exportability changes the key-custody decision
Older ACM advice often treated public ACM certificates as permanently non-exportable. Current AWS behavior is more nuanced. Public certificates requested through ACM can be exportable when export is enabled at creation, while older public certificates created before the service introduced this capability cannot simply be converted into exportable certificates. Private certificates and imported certificates have their own handling rules.
That does not mean export should become the default. A non-exported certificate attached directly to an integrated AWS service keeps the private key away from application hosts and administrators, which can reduce key-exposure risk. Export is valuable when a certificate has to be used on software or infrastructure that ACM cannot directly integrate with, but exporting also transfers responsibility for protecting the private key, rotating the certificate, and removing stale copies.
An exam scenario may therefore turn on where the private key must live. If the endpoint is an AWS-managed listener that supports ACM, keeping the key inside the managed integration is usually simpler. If the same identity must be installed on an external appliance or application that needs direct access to the key, an exportable or independently issued certificate may be necessary.
Mutual TLS makes identity architecture more important than HTTPS alone
Server-side TLS answers one identity question: can the client validate the server it reached? Mutual TLS adds the reverse question: can the server validate the client certificate as an approved identity? That often pushes a design toward private PKI because the organization needs a controlled way to issue and revoke client certificates for workloads, devices, partners, or users.
Private CA can provide the certificate hierarchy behind that trust model, but the rest of the lifecycle still matters. Enrollment must authenticate the requester. Private keys should be generated and stored in a protected location. Trust stores need controlled distribution. Revocation or short certificate lifetimes need to match the risk model. Certificate subjects and extensions should identify the workload in a way the authorization layer can actually use.
PKI belongs with identity and network security rather than being treated as a cosmetic HTTPS setting. A certificate proves only what the issuer and validator are configured to trust; it does not replace IAM authorization, network controls, application policy, or the operational processes required to rotate and revoke trust safely.
Choose the service by trust boundary, issuance model, and consumer
Start with the relying party. If the certificate must be trusted on the public internet and the endpoint is supported by ACM, a public ACM certificate is usually the cleanest design. If the endpoint needs a certificate issued by an external enterprise or commercial CA, importing that certificate into ACM can make sense when the AWS service can consume it.
Next ask whether the organization needs to be its own issuer. Internal service identities, device certificates, private DNS names, workload authentication, and private mTLS are strong indicators that a private CA is required. The next decision is whether ACM should request and manage those private certificates for AWS-integrated endpoints or whether workloads should use a direct private-CA enrollment process.
Finally, decide who owns key custody and renewal. Managed ACM integrations reduce key handling. Exported certificates and directly issued private certificates give more deployment freedom but move more responsibility to the customer. Private CA itself also has lifecycle choices: root versus subordinate roles, hierarchy depth, CA validity, certificate templates, revocation mechanisms, and access to issuance APIs.
A practical architecture can use both without duplicating responsibility
Consider a company with a public web application, internal APIs, and a fleet of managed devices. The public application can use an ACM public certificate on its load balancer. Internal APIs can use certificates issued under a company-controlled Private CA, with ACM managing certificates on supported AWS endpoints. Devices can receive certificates from a dedicated subordinate private CA through a controlled enrollment workflow. Each certificate population has a different trust audience, but the architecture still uses a consistent managed PKI foundation.
That separation also makes incident response clearer. Compromise of one device-issued certificate should not require replacing the public website certificate. Compromise of a subordinate CA is more serious and should have a response path distinct from ordinary leaf-certificate rotation. The hierarchy defines blast radius, so it should reflect operational ownership and risk rather than organizational convenience alone.
For candidates reviewing the broader Amazon AWS security ecosystem, the durable rule is simple: ACM manages certificates for AWS consumption, while Private CA creates private trust. Use public trust for unknown external clients, private trust for controlled communities, and combine the services when AWS-managed certificate lifecycle and enterprise-controlled issuance are both required.