Day 16: Cross-Account ACM PCA Sharing and Multi-Region DR

Phase 5 · September 10, 2026

Agenda (2–3 hours)

• Read (45 min): ACM PCA User Guide — "Sharing a CA"; "Multi-region deployment"
• Study (60 min): RAM sharing, resource policies, cross-region replication patterns
• Write (45 min): Multi-account architecture for your provisioning service

Why Cross-Account Sharing?

Your organization likely has multiple AWS accounts:

Amazon Leo Secure Comms:
├── Account A: Infrastructure (shared CA)
├── Account B: Provisioning Service (Lambda, DynamoDB)
├── Account C: Device Management (IoT Core, registrations)
└── Account D: Security/Audit (CloudTrail, GuardDuty)

You want the CA in Account A (controlled by the security team) but
the provisioning service in Account B (controlled by your team) to call
IssueCertificate against Account A's CA.

Sharing ACM PCA via AWS RAM

AWS Resource Access Manager (RAM) lets you share ACM PCA CAs:

Account A (CA owner):
└── Create the CA
└── Share via RAM:
    aws ram create-resource-share \
      --name "Leo Provisioning CA Share" \
      --resource-arns "arn:aws:acm-pca:us-east-1:ACCOUNT-A:certificate-authority/..." \
      --principals "arn:aws:iam::ACCOUNT-B:root"

Account B (provisioning service):
└── Accept the RAM invitation
└── Call IssueCertificate with the shared CA ARN

The CA ARN in Account B looks the same as in Account A.
Billing for certificates issued goes to the CA owner (Account A).

Resource-Based Policy Alternative

For fine-grained control, use a CA resource policy instead of RAM:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowProvisioningServiceIssuance",
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::ACCOUNT-B:role/provisioning-service-role"
    },
    "Action": [
      "acm-pca:IssueCertificate",
      "acm-pca:GetCertificate"
    ],
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "acm-pca:TemplateArn":
          "arn:aws:acm-pca:::template/EndEntityCertificate/V1"
      }
    }
  }]
}

The Condition block restricts the provisioning service to only issue certs
with the approved template — it cannot issue CA certs.

Multi-Region Architecture

ACM PCA is a regional service — a CA in us-east-1 cannot issue certs from us-west-2.

For a global provisioning service:

Option A: Single CA (simpler, lower cost)
  ├── All issuance goes to us-east-1 CA
  ├── Pro: simple; one CRL; one audit trail
  └── Con: latency from other regions; single-region failure = global CA outage

Option B: Regional CAs under a common root (better resilience)
  ├── Root CA (offline or ACM PCA)
  │   ├── us-east-1 Issuance CA (serve North America)
  │   ├── eu-west-1 Issuance CA (serve Europe)
  │   └── ap-northeast-1 Issuance CA (serve Asia-Pacific)
  ├── Pro: regional fault isolation; lower latency
  └── Con: more CAs to manage; cross-region trust bundle distribution

Trust Bundle Distribution in Multi-Region

When relying parties validate certs, they check against the trust bundle
(the root CA cert and any intermediate CA certs).

Challenge: if you have 3 issuance CAs, relying parties need to trust all 3.

Solution: they only need to trust the root CA.
  (All issuance CA certs chain up to the root → relying parties validate via chain)

But: the root CA cert must be distributed to all relying parties.
  - Device firmware: root cert burned in at manufacturing time
  - Services: root cert in trust bundle (ACM PCA trust store, or manual)
  - SPIRE: root cert in trust bundle (bundle endpoint)

For satellite terminals: the root CA cert is burned into firmware.
If you need to rotate the root, you need a firmware update. Plan accordingly.

Disaster Recovery Scenario

Scenario: us-east-1 ACM PCA becomes unavailable for 4 hours.

The strongest mitigation: provision certs with long enough validity
that a 4-hour CA outage doesn't matter. For 90-day device certs,
an 4-hour outage is invisible unless a device happens to need provisioning.

Challenge Assignment

Add multi-account architecture to acm-pca-design.md:

### 5.3 Multi-Account Architecture
<RAM sharing vs. resource policy — which approach for your service? Why?>

### 5.4 Multi-Region Design Decision
<Single CA vs. regional CAs — which for your provisioning service?
 What's the cert validity buffer that makes single-CA outage tolerable?>

### 5.5 Trust Bundle Distribution
<How does the root CA cert reach each type of relying party?
 Devices: firmware? Services: ACM trust store? SPIRE: bundle endpoint?>

Resources

• ACM PCA RAM sharing: docs.aws.amazon.com/privateca/latest/userguide/pca-ram.html
• ACM PCA resource policies: docs.aws.amazon.com/privateca/latest/userguide/pca-rbp.html
• AWS RAM documentation: docs.aws.amazon.com/ram/latest/userguide
• Multi-region ACM PCA patterns: docs.aws.amazon.com/privateca/latest/userguide/disaster-recovery.html