Running your own PKI means: buying HSMs ($30K-$100K), staffing key ceremonies, managing CRL publication, maintaining HA for your Issuing CA, and handling firmware updates on hardware you physically own. Cloud-based PKI eliminates all of this — you create a CA via API call and start issuing certificates in minutes.
But cloud PKI isn’t free (AWS Private CA costs $400/month per CA + $0.75/cert), and it creates vendor lock-in (keys are non-exportable). Here’s when cloud PKI makes sense and when self-hosted is still the right call.
What Cloud PKI Providers Offer
| Provider | Service | FIPS Level | Pricing | Best For |
|---|---|---|---|---|
| AWS Private CA | ACM Private CA | Level 3 (HSM-backed) | $400/mo + $0.75/cert | AWS-centric orgs |
| Google Cloud CAS | Certificate Authority Service | Level 3 | Per-cert + per-operation | GCP-centric orgs |
| Azure | Key Vault + Managed HSM | Level 2-3 | Per-operation | Azure-centric orgs |
| DigiCert ONE | Managed PKI platform | Level 3 | Enterprise pricing | Multi-cloud enterprise |
| Keyfactor | EJBCA SaaS | Level 3 | Enterprise pricing | Compliance-heavy orgs |
How Cloud PKI Works
You define:
├── Hierarchy (Root CA → Intermediate CA)
├── Certificate profiles (key algorithm, validity, SANs)
├── Access policies (who can request certificates)
└── Integration points (cert-manager, IoT Core, applications)
Provider manages:
├── HSM hardware (FIPS 140-2 Level 3)
├── CA availability (multi-AZ, automatic failover)
├── CRL/OCSP publication
├── Physical security
├── Firmware updates
└── Disaster recoveryAWS Private CA (Most Popular)
# Create a Root CA
aws acm-pca create-certificate-authority \
--certificate-authority-type ROOT \
--certificate-authority-configuration \
"KeyAlgorithm=EC_prime256v1,SigningAlgorithm=SHA256WITHECDSA,\
Subject={CommonName='My Org Root CA'}"
# Create Subordinate (Issuing) CA
aws acm-pca create-certificate-authority \
--certificate-authority-type SUBORDINATE \
--certificate-authority-configuration \
"KeyAlgorithm=EC_prime256v1,SigningAlgorithm=SHA256WITHECDSA,\
Subject={CommonName='My Org Issuing CA'}"
# Issue a certificate
aws acm-pca issue-certificate \
--certificate-authority-arn arn:aws:acm-pca:us-east-1:123:certificate-authority/abc \
--csr fileb://server.csr \
--signing-algorithm SHA256WITHECDSA \
--validity Value=365,Type=DAYSIntegration with cert-manager:
apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
name: aws-pca-issuer
spec:
arn: arn:aws:acm-pca:us-east-1:123:certificate-authority/abc
region: us-east-1Cost reality at scale:
| Certificates/Month | Monthly Cost | Annual Cost |
|---|---|---|
| 100 | $475 | $5,700 |
| 1,000 | $1,150 | $13,800 |
| 10,000 | $7,900 | $94,800 |
| 100,000 | $75,400 | $904,800 |
At high volumes, cloud PKI becomes expensive. The break-even vs self-hosted (EJBCA + HSM) is typically around 5,000-10,000 certs/month.
When Cloud PKI Makes Sense
✅ Use cloud PKI when:
- You have no PKI expertise in-house
- You need a CA running in hours (not months)
- Certificate volume is moderate (<5,000/month)
- You’re already on that cloud provider
- Compliance requires HSM-backed keys but you can’t manage HSMs
- You need multi-region availability without building it yourself
❌ Keep self-hosted when:
- High volume (>10,000 certs/month) — cost becomes prohibitive
- You need the Root CA under your physical control
- Air-gapped environments (no cloud connectivity)
- Multi-cloud and don’t want vendor lock-in on trust anchors
- You need protocols cloud CAs don’t support (SCEP, CMP)
The Hybrid Pattern (Recommended)
Self-hosted Root CA (offline, your HSM, your physical control)
↓ signs (annual ceremony)
Cloud Issuing CA (AWS Private CA / Google CAS)
↓ issues (automated, HA, API-driven)
Certificates for your workloadsYou keep the trust anchor portable (self-hosted Root). The operational burden (Issuing CA) is in the cloud. If you ever need to leave the cloud provider, create a new Issuing CA elsewhere — signed by the same Root. No trust store changes needed.
Vendor Lock-In: The Real Risk
The problem: Keys generated in cloud PKI are non-exportable. You cannot extract the CA’s private key and move it to another provider or on-premises HSM.
What this means:
- If you create your Root CA in AWS Private CA, your Root key is permanently in AWS
- Migrating to another provider means: new Root CA → redistribute trust to every device → re-issue every certificate
- This is a multi-month project for large organizations
Mitigation: Keep your Root CA self-hosted. Only put Issuing CAs in the cloud. Issuing CAs are replaceable (sign a new one from your Root). Root CAs are not.
FAQ
Q: Is cloud PKI secure enough for production? A: Yes — cloud PKI providers use FIPS 140-2 Level 3 HSMs (same as on-premises enterprise HSMs). The security is equivalent. The trade-off is control, not security.
Q: Can I use cloud PKI for publicly-trusted certificates? A: No — cloud PKI services issue private certificates only (trusted within your organization). For publicly-trusted certificates (browsers), use public CAs (Let’s Encrypt, DigiCert).
Q: What happens if the cloud provider has an outage? A: Existing certificates continue working (they’re already deployed). New issuance fails until the service recovers. For short-lived certificates (24h), a prolonged outage means services can’t renew. Mitigation: issue certificates with enough validity to survive maintenance windows.
Q: Can I use multiple cloud PKI providers? A: Yes — create Issuing CAs in each provider, all signed by your self-hosted Root. Each provider issues certificates for its own workloads. Unified trust via the shared Root.
Q: How does this relate to QCecuring’s PKI as a Service? A: QCecuring PKI as a Service provides managed CA operations with multi-cloud support, SCEP/EST/CMP protocol support, and integration with our CLM platform for complete lifecycle management — capabilities that basic cloud CA services don’t offer. Learn more →