AWS Certificate Manager Private CA

AWS Private CA (formerly ACM Private CA) is a fully managed private certificate authority service that lets security teams build and operate a private PKI hierarchy inside AWS without buying or managing CA hardware. It issues X.509 certificates for internal TLS, mTLS, code signing, IoT device identity, and user authentication. The recommended starting point for most teams is a two-tier hierarchy with a root CA inside AWS Private CA and one or more subordinate CAs per environment, using AWS KMS customer-managed keys for CA key protection, with a hybrid model (on-premises root, AWS subordinate CA) for organizations with strict key sovereignty requirements.

Quick Answer: What Is AWS Private CA and When Should You Use It?

AWS Private CA is the right choice when you need to issue private X.509 certificates for internal workloads, need a CA hierarchy your team does not have to run on physical hardware, and are operating primarily in AWS. It is not a replacement for public TLS certificates (AWS Certificate Manager handles those for free for integrated services). Use AWS Private CA for internal service authentication, mTLS between microservices, IoT device certificates, user VPN certificates, and code signing scenarios where a publicly trusted CA is unnecessary and undesirable. The service costs $400 per CA per month for general-purpose use and $50 per CA per month for short-lived certificates (valid 7 days or fewer), with tiered per-certificate fees on top.

Key Takeaways

• AWS offers two distinct services: AWS Certificate Manager (ACM) for free public TLS certificates used with integrated AWS services, and AWS Private CA for private, internally-trusted X.509 certificates that can be exported with their private key and used anywhere.
• Two CA hierarchy models are available: Private Cloud (root and subordinate CAs both in AWS Private CA, keys protected by AWS KMS) and Hybrid Cloud (root CA on-premises in your own HSM, subordinate CAs in AWS Private CA). The Hybrid model gives you direct custody of the root CA key; the Private Cloud model gives you full cloud automation.
• Two operating modes change cost significantly: General-purpose mode at $400/CA/month supports any certificate validity period. Short-lived certificate mode at $50/CA/month supports only certificates valid 7 days or fewer, making it purpose-built and cost-effective for service mesh, SPIFFE-style workload identity, and high-frequency mTLS environments.
• Key control is a design decision, not a default: AWS Private CA uses AWS KMS to protect CA keys. With default AWS-managed keys, AWS holds operational custody. With customer-managed KMS keys (BYOK), you hold the source key material and can revoke the CA’s ability to sign instantly by deleting the imported key. A full HYOK model requires a Hybrid Cloud architecture with an on-premises root CA.
• CA/B Forum SC-081v3 favors short-lived mode for public-facing certificates: Maximum public TLS validity drops to 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029. Private CA issued through AWS Private CA can already align to any validity period; pairing it with certificate lifecycle automation is essential as renewal frequency increases.

AWS Certificate Manager vs. AWS Private CA: Two Different Services

The confusion between these two services is common and consequential. They serve different purposes, have different pricing models, and are not interchangeable.

AWS Certificate Manager (ACM) provisions and renews public SSL/TLS certificates for use with AWS-integrated services including Amazon CloudFront, Application Load Balancer, Amazon API Gateway, and AWS Elastic Beanstalk. Public certificates through ACM are free for use with these integrated services. ACM handles renewal automatically. The critical limitation: you cannot export an ACM-managed public certificate or its private key. ACM certificates cannot be installed on EC2 instances directly, on-premises servers, or non-AWS systems. They also cannot issue certificates for internal hostnames or private IP addresses that would not pass public domain validation.

AWS Private CA is a managed service for running a private certificate authority. Certificates it issues are privately trusted (your organization’s devices and services must be configured to trust the CA hierarchy). The private key can be exported with the certificate, allowing installation anywhere: EC2 instances, on-premises servers, containers, IoT devices, custom applications. AWS Private CA supports private hostnames, internal IP addresses, and custom subject fields that public CAs cannot issue. It charges a monthly CA operation fee plus per-certificate issuance fees.

Dimension	AWS Certificate Manager (ACM)	AWS Private CA
Certificate trust	Publicly trusted (browser and OS trust stores)	Privately trusted (your CA hierarchy only)
Private key export	Not permitted	Permitted (certificate + key exportable)
Valid for internal hostnames	No	Yes
Cost	Free for ACM-integrated services	$400/CA/month (general-purpose) or $50/CA/month (short-lived)
Auto-renewal	Yes (managed by AWS)	Requires CLM automation or manual renewal
Use cases	Public HTTPS for websites and APIs on AWS services	Internal TLS, mTLS, IoT, code signing, VPN, user auth
CA key custody	AWS-managed (no customer access)	AWS KMS (customer-managed keys supported)

CA Hierarchy Models: Private Cloud vs. Hybrid Cloud

AWS Private CA supports two fundamental CA hierarchy architectures. Choosing between them is the most consequential design decision because it determines who holds custody of the root CA key and how much operational complexity you accept.

Model 1: Private Cloud (Root and Subordinate CAs Both in AWS)

In this model, you create a root CA inside AWS Private CA and one or more subordinate (issuing) CAs beneath it, all inside AWS. The root CA key is protected by AWS KMS. AWS handles high availability, replication, and key protection. You interact with the CA entirely through the AWS console, SDK, and CLI.

This model provides full cloud automation benefits: no hardware to manage, no HSM to provision, automatic high availability across Availability Zones, and API-driven certificate issuance that integrates natively with AWS services. The trade-off is that the root CA key lives in AWS KMS under the shared responsibility model. AWS has operational access to the key material as part of the managed service. For organizations with regulatory requirements mandating that the root CA key be held exclusively by the customer, this model does not satisfy those requirements unless you use customer-managed KMS keys (BYOK).

AWS Private CA supports up to five levels in a CA hierarchy: a root CA with up to four levels of subordinate CAs beneath it. You can create multiple independent hierarchies, each with its own root. For most enterprises, a two-tier hierarchy (root CA plus one issuing CA per environment) is sufficient and easier to audit.

Model 2: Hybrid Cloud (On-Premises Root CA, AWS Subordinate CA)

In this model, the root CA is hosted on-premises, typically in a dedicated HSM under your direct physical and logical control. The subordinate CA is created in AWS Private CA, and you sign the subordinate CA’s certificate signing request (CSR) using your on-premises root CA. The resulting signed subordinate CA certificate is imported back into AWS Private CA, activating the subordinate CA for operational certificate issuance.

This model gives you direct custody of the root CA key. The root CA key never enters AWS. If the AWS Private CA subordinate CA is compromised, an attacker cannot issue new certificates from the root level, and you can revoke the subordinate CA certificate using your on-premises root CA without any dependence on AWS. The trade-offs are real: you must operate and maintain the on-premises root CA infrastructure, conduct documented root CA ceremonies for any root CA key operations, and manage the physical and logical security of the on-premises HSM. For organizations with an existing on-premises PKI they are partially migrating to AWS, the Hybrid Cloud model provides a natural bridge without requiring a full trust model change.

Key Control: Native KMS, BYOK, and HYOK for AWS Private CA

AWS Private CA protects CA private keys using AWS KMS. The choice of KMS key type determines your level of control over the CA key material and your ability to independently revoke access.

Option 1: AWS-Managed KMS Key (Default)

When you create a private CA without specifying a KMS key, AWS Private CA creates and manages a KMS key on your behalf. This key is dedicated to your CA but is managed entirely by AWS. You cannot view the key material, rotate it independently, or delete it without deleting the CA. This is the simplest option and satisfies most operational requirements, but it does not give you the ability to independently revoke the CA’s signing capability outside of deleting the CA through the AWS console or API.

Option 2: Customer-Managed KMS Key (BYOK)

BYOK (Bring Your Own Key) for AWS Private CA means you create a customer-managed key (CMK) in AWS KMS, either generated by AWS KMS or imported from an external key source, and specify that CMK when creating the private CA. AWS Private CA uses your CMK to protect the CA private key.

With a customer-managed CMK, you can disable the key to immediately prevent the CA from performing any signing operations, without deleting the CA. You can view key usage in AWS CloudTrail. You control key rotation for the CMK. If you use imported key material (generating the key externally and importing it into KMS), you retain the source key material and can delete the imported key material from KMS to permanently and immediately revoke the CA’s ability to sign, even without AWS support involvement.

BYOK is the right choice for organizations that need an independent kill switch for the CA key, that have regulatory requirements for customer-generated key material, or that need to demonstrate to auditors that the organization retains provenance over all cryptographic keys protecting its CA infrastructure.

Option 3: HYOK (Hold Your Own Key) via Hybrid Architecture

True HYOK for a root CA, where the CA key never enters AWS under any circumstance, requires the Hybrid Cloud architecture described above: the root CA and its key live in an on-premises HSM that you control, and only subordinate CAs are hosted in AWS Private CA. The subordinate CA inside AWS Private CA still uses a KMS-backed key (which you can make a customer-managed CMK), but the root-level key is entirely outside AWS’s infrastructure.

This provides the strongest key sovereignty at the root CA level. AWS cannot access or exercise the root CA key under any circumstance, including legal compulsion directed at AWS. The trade-off is the added operational complexity of maintaining an on-premises root CA and the latency of the cross-environment signing workflow for subordinate CA operations.

Dimension	AWS-Managed KMS Key	Customer-Managed KMS Key (BYOK)	HYOK (On-Premises Root CA)
CA key location	AWS KMS (AWS-managed)	AWS KMS (customer-managed)	Root key: your on-premises HSM; Subordinate key: AWS KMS
AWS access to root key	Yes (operational)	Yes (operational, customer controls rotation and deletion)	No for root CA key
Independent kill switch	Delete CA only (AWS-mediated)	Disable or delete CMK (immediate, independent)	Revoke subordinate CA cert from on-premises root (immediate)
Key provenance control	AWS generates key material	Customer generates or imports key material	Customer generates and holds root key exclusively
Operational complexity	Low	Medium	High (requires on-premises HSM and ceremony infrastructure)
Best for	Most AWS-native workloads; operational simplicity priority	Regulated sectors; independent key control requirement	Strict sovereignty mandates; classified or air-gapped environments

IAM Model for AWS Private CA: Least Privilege Design

AWS Private CA access control uses IAM identity policies and resource-based policies. Designing least-privilege access requires separating the roles that manage the CA from the roles that issue certificates under it.

CA Administrator role: Needs permissions to create, update, tag, and delete CAs, and to import CA certificates. Key permissions: acm-pca:CreateCertificateAuthority, acm-pca:UpdateCertificateAuthority, acm-pca:DeleteCertificateAuthority, acm-pca:ImportCertificateAuthorityCertificate, acm-pca:TagCertificateAuthority. This role must not be granted acm-pca:IssueCertificate to maintain separation of duties.

Certificate Issuer role: Needs permissions to issue and retrieve certificates and to configure revocation. Key permissions: acm-pca:IssueCertificate, acm-pca:GetCertificate, acm-pca:RevokeCertificate, acm-pca:ListCertificateAuthorities. This role must not be granted CA management permissions.

Cross-account certificate issuance: When a subordinate CA in one AWS account needs to issue certificates for workloads in another AWS account, a resource-based policy on the Private CA must explicitly grant acm-pca:IssueCertificate to the principal in the requesting account. This is the correct pattern for platform teams operating a shared PKI service across multiple AWS accounts in an AWS Organizations structure.

KMS key policy integration: If you use a customer-managed KMS key for CA key protection, the KMS key policy must grant the AWS Private CA service principal permission to use the key for kms:Sign operations. Separating the KMS key administrator (who can manage the key policy) from the KMS key user (the Private CA service) prevents any single principal from both controlling the key and issuing certificates.

General-Purpose Mode vs. Short-Lived Certificate Mode

AWS Private CA introduced a second operating mode specifically for high-frequency, short-validity certificate workloads. Choosing the right mode for each CA in your hierarchy significantly affects both cost and architecture.

General-purpose mode ($400/CA/month) supports certificate issuance with any validity period, from seconds to years. It is appropriate for traditional PKI use cases: TLS server certificates, user authentication certificates, code signing certificates, and device identity certificates with multi-year or multi-month validity periods. It supports all certificate templates and the full range of key algorithms (RSA 2048, RSA 4096, ECDSA P-256, ECDSA P-384).

Short-lived certificate mode ($50/CA/month) restricts certificate validity to 7 days or fewer. This constraint is a feature for environments using SPIFFE/SPIRE-style workload identity, service mesh mTLS (Istio, Linkerd), or certificate-based ephemeral credentials where short validity eliminates the need for revocation checking entirely. At one-eighth the cost of general-purpose mode, short-lived mode is a significant cost optimization for high-frequency, automated certificate issuance environments. Pairing a short-lived mode CA with an ACME or EST enrollment protocol and a CLM platform for certificate automation is the production architecture for modern cloud-native PKI.

What AWS Private CA Can Issue: Certificate Types and Use Cases

AWS Private CA supports the following certificate types through configurable templates that enforce the correct key usage and extended key usage extensions:

• TLS server certificates: Internal web servers, APIs, and microservices requiring HTTPS with private trust. The certificate includes the TLS Server Authentication EKU (OID 1.3.6.1.5.5.7.3.1) and is validated by clients that trust your private CA hierarchy.
• mTLS client certificates: Service-to-service mutual TLS authentication in microservice architectures and service meshes. Both sides present certificates; the TLS Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2) is included. Short-lived certificate mode is optimal for mTLS workload identity certificates renewed on a sub-24-hour cycle.
• IoT device certificates: Manufacturing-time device identity provisioning and field device authentication. AWS Private CA integrates with AWS IoT Core for fleet-scale certificate issuance. IEEE 802.1AR IDevID and LDevID patterns are achievable through the API.
• Code signing certificates: Internal software artifact signing for CI/CD pipelines and firmware distribution. Code signing through AWS Private CA requires the Code Signing EKU (OID 1.3.6.1.5.5.7.3.3) and appropriate key protection for the signing key.
• Email protection (S/MIME): Internal encrypted email through certificates with the Email Protection EKU (OID 1.3.6.1.5.5.7.3.4). For enterprise S/MIME at scale, Encryption Consulting’s CertSecure Manager provides the CLM layer for enrollment and lifecycle management.
• OCSP signing certificates: Required if you configure AWS Private CA’s managed OCSP responder. The OCSP Signing EKU (OID 1.3.6.1.5.5.7.3.9) is included automatically in OCSP signing certificates issued by the service.

OCSP and Certificate Revocation in AWS Private CA

AWS Private CA supports two revocation mechanisms that can be enabled independently per CA.

Managed OCSP is AWS’s hosted Online Certificate Status Protocol responder. When enabled, AWS Private CA automatically issues OCSP signing certificates, publishes the OCSP responder URL in the Authority Information Access (AIA) extension of issued certificates, and responds to OCSP queries about certificate status. Managed OCSP charges $0.06 per certificate per month if OCSP responses were generated for that certificate, plus $0.20 per 100,000 OCSP queries. For high-volume mTLS environments where every connection triggers an OCSP check, these costs accumulate quickly. Short-lived certificate mode avoids OCSP entirely, since certificates expire before revocation becomes relevant.

CRL (Certificate Revocation List) is the alternative revocation mechanism. AWS Private CA can publish CRLs to an Amazon S3 bucket on a configurable schedule. CRL distribution requires the S3 bucket to be accessible to all certificate relying parties, which typically means configuring the bucket for public or scoped access. CRL checking adds latency at connection establishment equal to the time required to download and verify the CRL.

For most enterprise private PKI deployments, managed OCSP is the preferred revocation mechanism because it provides real-time status without requiring clients to download and cache potentially large CRL files. For air-gapped or highly sensitive environments where outbound OCSP queries are undesirable, CRL with a short validity period (daily or hourly publication) is the appropriate alternative.

AWS Private CA Cost Breakdown

Understanding the full cost of AWS Private CA requires accounting for CA operation, certificate issuance, OCSP, and the KMS key operations that protect the CA private key. The original $400/month figure captures only the CA operation cost for general-purpose mode.

Cost component	General-purpose mode	Short-lived certificate mode
CA operation (per CA per month)	$400	$50
Certificates 1 to 1,000 (per cert)	$0.75	$0.058 (flat rate)
Certificates 1,001 to 10,000 (per cert)	$0.35	$0.058 (flat rate)
Certificates 10,001 and above (per cert)	$0.001	$0.058 (flat rate)
OCSP (per cert per month, if queried)	$0.06	N/A (certificates expire before OCSP needed)
OCSP queries (per 100,000)	$0.20	N/A
Free trial	30 days for first CA per account per region (CA operation only; certificate fees still apply)	30 days for first CA per account per region

For a practical example: a two-CA hierarchy (root CA plus one issuing CA) in general-purpose mode issuing 2,000 certificates per month with OCSP enabled costs approximately $800 (CA operation) plus $1,025 in certificate fees (1,000 x $0.75 plus 1,000 x $0.35) plus OCSP costs (2,000 x $0.06 = $120), totaling roughly $1,945 per month before KMS charges. CA sprawl, where each environment gets its own subordinate CA, multiplies the $400/month CA operation fee across all CAs. Consolidating environments under a single subordinate CA where security policy permits reduces cost significantly.

For the current pricing page, see aws.amazon.com/private-ca/pricing/.

Certificate Lifecycle Management Integration

AWS Private CA provides the CA infrastructure, but certificate lifecycle management (CLM) requires additional tooling. As CA/B Forum SC-081v3 reduces maximum public TLS certificate validity to 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029, automated renewal is no longer optional even for private certificates operating alongside public ones.

AWS Private CA integrates natively with several enrollment mechanisms:

• AWS Certificate Manager integration: ACM can use a private CA as its issuing CA for certificates that are automatically deployed to ACM-integrated services. This gives you private trust with ACM’s managed renewal and deployment automation.
• ACME protocol: AWS Private CA Connector for ACME (released 2023) allows ACME-compatible clients (cert-manager, certbot, acme.sh) to request certificates from your private CA using the standard ACME protocol. This is the correct integration path for Kubernetes-native certificate automation and DevOps toolchains.
• Active Directory (AD CS) integration: AWS Private CA Connector for Active Directory integrates with Microsoft AD-joined Windows environments, allowing domain-joined machines and users to receive certificates from AWS Private CA through the familiar AD Certificate Services enrollment mechanisms (autoenrollment, SCEP).
• Direct API and SDK: The AWS Private CA API supports programmatic certificate issuance via the SDK in any language AWS supports, enabling custom enrollment workflows for non-standard systems.

For organizations managing certificates across AWS Private CA and other CA sources (Microsoft AD CS, on-premises PKI, cloud provider CAs), Encryption Consulting’s CertSecure Manager provides CA-agnostic unified certificate discovery, lifecycle automation, and expiry monitoring across all sources. The AWS Private CA volumes should be included in any enterprise CLM inventory.

Multi-Cloud and Hybrid PKI Architecture

Organizations operating AWS Private CA alongside Azure, GCP, or on-premises environments face the same cross-cloud consistency problem as with any cloud-native key management service: AWS Private CA is AWS-specific. Certificates it issues are trusted by systems that trust your private CA hierarchy, but the CA management plane, audit trail, and lifecycle automation are AWS-native and do not extend to other clouds automatically.

Three patterns address this for multi-cloud PKI:

• Single AWS Private CA hierarchy as the enterprise root: All environments (AWS, Azure, GCP, on-premises) trust the same root CA hosted in AWS Private CA. Subordinate CAs issue certificates for each environment. Cross-cloud certificate distribution is handled by deploying the root CA certificate to the trust stores of all systems. This is the simplest model for organizations that are primarily AWS-based and treating other environments as satellite deployments.
• On-premises root CA with cloud subordinate CAs: An on-premises root CA signs subordinate CA certificates for AWS Private CA (for AWS workloads), Azure-based subordinate CAs (for Azure workloads), and any other cloud environments. All subordinate CAs share the same trust root but operate independently within their respective cloud platforms. This is the Hybrid Cloud model extended to multiple clouds. The on-premises root CA is the ultimate trust anchor.
• CLM-unified multi-CA estate: Each cloud uses its native CA service (AWS Private CA for AWS, Azure Active Directory Certificate Services or Azure-integrated CAs for Azure, GCP Certificate Authority Service for GCP), and a cloud-agnostic CLM platform aggregates the certificate inventory, monitors expiry, and enforces rotation policy across all sources. This avoids cross-cloud CA hierarchy complexity at the cost of requiring a CLM platform capable of integrating with multiple CA APIs. Encryption Consulting’s CertSecure Manager integrates with AWS Private CA and other CA sources to provide this unified visibility layer.

ACM Private CA Best Practices

1. Design your CA hierarchy before provisioning: Decide how many CA levels you need (two-tier is recommended for most enterprises: root CA plus issuing CA per environment), how many subordinate CAs to create, and which environments share an issuing CA versus get dedicated CAs. CA sprawl multiplies your monthly CA operation costs and complicates revocation.
2. Document your certificate policy and practices: Define maximum validity periods per certificate type, allowed key algorithms and sizes, permitted extended key usages per certificate template, and the approval workflow for each certificate category. AWS Private CA enforces these through templates and API controls; the policy document is what auditors review.
3. Use customer-managed KMS keys for CA key protection: Default AWS-managed keys work but give you less control. Customer-managed keys provide an independent disable/delete capability and a cleaner audit trail for key operations in CloudTrail.
4. Enable CloudTrail for all Private CA API activity: Every certificate issuance, revocation, CA creation, and CA configuration change generates a CloudTrail event. Route these to a SIEM and configure alerts for certificate issuance from unexpected principals, CA deletion requests, and KMS key disable events for keys protecting CA private keys.
5. Automate certificate renewal before expiry: AWS Private CA does not automatically renew certificates it issues (unlike ACM for public certificates). Use the ACME connector, ACM integration, or a CLM platform to automate renewal. At 47-day certificate validity (effective March 2029 for public certificates), manual renewal is operationally impossible. Build the automation now.
6. Separate CA administrator and certificate issuer IAM roles: No single IAM principal should have both CA management permissions and certificate issuance permissions. Configure separate roles and, for sensitive CAs, require MFA for all CA management operations.
7. Keep the root CA inactive when not in use: If your root CA in AWS Private CA does not need to issue subordinate CA certificates on a regular basis, disable it after the initial hierarchy setup. A disabled root CA cannot be used to issue certificates, reducing the attack surface. Re-enable it only during subordinate CA renewal or hierarchy changes.
8. Plan for multi-region deployment: AWS Private CA is a regional service. If your certificate estate spans multiple AWS regions, create subordinate CAs in each region where certificate issuance latency matters. The root CA can remain in one region; subordinate CAs in other regions each incur their own $400/month (or $50/month) CA operation fee.

Shared Responsibility in AWS Private CA

AWS Private CA operates under the AWS shared responsibility model, with a clear division of what AWS owns and what the customer owns.

AWS-owned responsibilities include the physical security of the data centers hosting the KMS HSMs that protect CA keys, the availability and durability of the AWS Private CA service itself, the FIPS 140-2 Level 3 validation of the HSMs protecting KMS-managed keys, automatic replication of CA configuration and keys across Availability Zones within a region, the security of the managed OCSP responder infrastructure, and patching and maintenance of the underlying service infrastructure.

Customer-owned responsibilities include CA hierarchy design decisions, IAM policy configuration (who can issue certificates, who can manage CAs), the choice of KMS key type (AWS-managed versus customer-managed), certificate template selection and configuration for each CA, revocation configuration (OCSP enablement, CRL S3 bucket access), monitoring and alerting configuration for certificate events, certificate renewal automation, distributing the private CA root certificate to all relying party trust stores, and the Certificate Policy and Certification Practices Statement documentation required for compliance programs.

How Encryption Consulting Can Help

Encryption Consulting is an applied cryptography and cloud security firm with ISO/IEC 27001:2022 and SOC 2 certifications. We help organizations design, implement, and govern AWS Private CA deployments from initial hierarchy design through certificate lifecycle automation and compliance evidence collection.

• PKI as a Service: For organizations that want managed PKI without the operational complexity of running AWS Private CA themselves, Encryption Consulting’s PKI as a Service provides a fully managed private CA with FIPS-validated HSM key protection, root CA ceremony facilitation, CP/CPS documentation, and 24/7 monitoring. We can integrate with AWS workloads while keeping the CA operational burden off your team.
• CertSecure Manager (CLM): AWS Private CA provides CA infrastructure but not lifecycle management for the certificates it issues. Encryption Consulting’s CertSecure Manager provides certificate discovery, expiry monitoring, renewal automation via ACME and EST, and unified certificate inventory across AWS Private CA, Microsoft AD CS, and other CA sources. As CA/B Forum SC-081v3 compresses certificate validity toward 47 days, automated CLM becomes essential.
• PKI Services and Advisory: If you are designing a CA hierarchy for AWS Private CA, evaluating the Private Cloud versus Hybrid Cloud trade-offs, or need a Certificate Policy and CPS document for a compliance audit, Encryption Consulting’s PKI Services covers CA hierarchy design, key ceremony facilitation for hybrid deployments, and CP/CPS development for any PKI compliance framework (NIST, WebTrust, ETSI).
• HSM as a Service: For hybrid deployments requiring an on-premises root CA backed by a dedicated FIPS-validated HSM, Encryption Consulting’s HSM as a Service provides the managed HSM infrastructure for your root CA key without capital expenditure on HSM hardware.
• CBOM Secure: AWS Private CA deployments that have grown organically often contain more CAs, certificates, and key types than security teams can manually track. Encryption Consulting’s CBOM Secure discovers and inventories all cryptographic assets across your AWS environment, including AWS Private CA-issued certificates, KMS keys, and ACM certificates, and generates a Cryptographic Bill of Materials (CBOM) in CycloneDX format for compliance and audit use.
• PQC Readiness: NIST finalized post-quantum cryptography standards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 points toward deprecating RSA and ECC for new uses around 2030. If your AWS Private CA hierarchy uses RSA or ECDSA CA keys today, migration planning should begin now. Encryption Consulting’s PQC Readiness service assesses your AWS Private CA hierarchy against the post-quantum migration timeline and designs the algorithm transition path.

To discuss your AWS Private CA design, CLM automation, or compliance requirements, contact Encryption Consulting.

Conclusion

AWS Private CA removes the hardware procurement, data center footprint, and operational complexity of running a private certificate authority while preserving all the security controls that matter: key algorithm choice, CA hierarchy design, IAM-enforced role separation, KMS-backed key protection with customer control, and a complete CloudTrail audit trail of every certificate operation.

The key decisions that determine whether an AWS Private CA deployment is secure, cost-effective, and auditable are not defaults: the Private Cloud versus Hybrid Cloud hierarchy model, the KMS key type (AWS-managed versus customer-managed BYOK), the operating mode (general-purpose at $400/CA/month versus short-lived at $50/CA/month for sub-7-day certificates), the IAM role separation between CA administrators and certificate issuers, and the CLM automation layer that handles renewal as certificate validity periods shrink toward 47 days.

Organizations migrating from on-premises PKI to AWS Private CA should treat it as a PKI redesign opportunity, not a lift-and-shift. The Hybrid Cloud model preserves root CA key sovereignty while gaining cloud operational benefits for certificate issuance. BYOK with customer-managed KMS keys provides an independent kill switch and key provenance that auditors can verify. Short-lived certificate mode at one-eighth the CA operation cost is the right architecture for any high-frequency mTLS or workload identity use case.

Frequently Asked Questions

What is AWS Private CA and how does it differ from AWS Certificate Manager (ACM)?

AWS Private CA (formerly ACM Private CA) is a managed private certificate authority service for issuing privately trusted X.509 certificates for internal workloads. AWS Certificate Manager (ACM) provisions free public TLS certificates for use with ACM-integrated AWS services. ACM certificates cannot be exported; Private CA certificates can be exported with their private key for use anywhere. ACM certificates are publicly trusted; Private CA certificates are trusted only by systems you configure to trust your CA hierarchy.

What is the difference between Private Cloud and Hybrid Cloud models in AWS Private CA?

In the Private Cloud model, both root and subordinate CAs are inside AWS Private CA, with keys in AWS KMS. In the Hybrid Cloud model, the root CA is on-premises in an HSM you control, and only subordinate CAs are in AWS Private CA. The Hybrid model gives you direct custody of the root CA key; the Private Cloud model provides full cloud automation without on-premises infrastructure requirements.

How much does AWS Private CA cost per month?

AWS Private CA charges $400 per CA per month for general-purpose mode and $50 per CA per month for short-lived certificate mode (certificates valid 7 days or fewer). Certificate issuance is tiered: $0.75 each for the first 1,000, $0.35 each for 1,001 to 10,000, and $0.001 each above 10,000 per region per month for general-purpose CAs. Short-lived certificates are a flat $0.058 each. OCSP adds $0.06 per certificate per month if queried, plus $0.20 per 100,000 queries. AWS offers a 30-day free trial on CA operation for the first Private CA per account per region.

Does AWS Private CA support BYOK (Bring Your Own Key)?

Yes. AWS Private CA uses AWS KMS to protect CA keys. By default it uses AWS-managed KMS keys. You can specify a customer-managed KMS key (with imported key material) when creating the CA. With imported key material, you retain the source key and can delete it from KMS to immediately prevent the CA from signing new certificates. True HYOK (where the CA key never enters AWS at any level) requires a Hybrid Cloud architecture with an on-premises root CA.

What IAM permissions does AWS Private CA require?

CA administrators need acm-pca:CreateCertificateAuthority, acm-pca:UpdateCertificateAuthority, acm-pca:DeleteCertificateAuthority, and acm-pca:ImportCertificateAuthorityCertificate. Certificate issuers need acm-pca:IssueCertificate, acm-pca:GetCertificate, and acm-pca:RevokeCertificate. These roles should be separate: no single principal should hold both CA management and certificate issuance permissions. Cross-account issuance requires a resource-based policy on the Private CA granting IssueCertificate to the requesting account principal.

What certificate types can AWS Private CA issue?

AWS Private CA can issue X.509 certificates for TLS server authentication, TLS client authentication (mTLS), code signing, email protection (S/MIME), OCSP signing, and custom application-specific uses. It supports RSA 2048, RSA 4096, ECDSA P-256, and ECDSA P-384 key algorithms. Certificate templates enforce the permitted key usages and extended key usages for each certificate type, preventing issuance of certificate types not defined in the template.