3AM deployment: how it works in your AWS account

3AM is a serverless certificate authority and multi-PKI control plane that AxelSpire deploys into a dedicated AWS account inside your AWS Organization. Onboarding produces a small, well-defined set of resources — an AWS KMS encryption key, a scoped cross-account permission grant, and the storage that backs the audit log and infrastructure state. AxelSpire holds no long-lived credentials in the account, every action lands in a tamper-proof audit log inside your account, and you can revoke AxelSpire's access unilaterally in minutes. Calendar time from kick-off to first production deploy is typically one to three weeks.

This page is the deployment deep-dive — the detailed answer to "how does 3AM actually run in our environment?" For the higher-level positioning of why 3AM exists and what makes a PKI control plane different from a CLM platform, start at 3AM overview. For the engineer-level detail behind the deployment described here — OpenTofu module inputs, verification commands, day-2 operations — see 3AM customer onboarding: engineer reference in the Vault.

What 3AM is, in three paragraphs

3AM (AxelSpire Automated Management) is built on AWS KMS. Private key operations are performed inside the KMS HSM boundary — analogous to OpenSSL with an external crypto provider — which means private key material never exists in application memory, in a configuration file, or in a database, and cannot be exported. The CA is serverless: there is no fleet of CA hosts to patch, no quorum to maintain, and no scaling event when issuance volume spikes.

3AM functions both as a standalone CA and as a single integration and policy layer across multiple backend PKIs. The control-plane mode is the integration path for organisations that already operate Microsoft AD CS, EJBCA, HashiCorp Vault PKI, AWS Private CA, or vendor-managed CAs and want a uniform issuance, policy, and observability layer over them rather than a wholesale migration. Issuance and operational data is aggregated across every connected CA for enterprise-level analytics, compliance reporting, and policy enforcement.

3AM ships with compliance logging built in. Every action — including AxelSpire's own operational changes — is written to an S3 Object Lock bucket in the customer account, in compliance mode, with retention configurable from 1 to 100 years (default 7). This is the same primitive financial regulators accept under SEC 17a-4(f) and FINRA 4511(c).

What onboarding produces

The initial deployment creates the following resources, all owned by your AWS account from the moment they are created:

• One AWS KMS customer-managed key (CMK) — the cryptographic root of the deployment. Administrative rights on the key are held by your break-glass and platform-team IAM roles, not AxelSpire. Key material never leaves the KMS HSM boundary.
• One IAM role (ThreeAM-Deployment) — the cross-account permission grant AxelSpire assumes to deploy and operate 3AM. Its trust policy names AxelSpire's CI account ID, optionally an external ID secret you control, and — for the strictest tier — an aws:CurrentTime change window.
• Two S3 buckets — one for the tamper-proof audit log (Object Lock, compliance mode), one for infrastructure state.
• One DynamoDB table — state locking for the deployment.
• A small set of SSM parameters under /3am/* and (optionally) a CloudWatch log group for the onboarding step itself.

That is the entire onboarding footprint. The 3AM application itself — the issuance APIs, policy engine, multi-PKI integrations, observability stack — is layered on top in subsequent stacks operated by AxelSpire. Onboarding is the trust and infrastructure foundation; everything else builds on it.

Where 3AM runs: a dedicated AWS account in your Organization

3AM is deployed into an AWS account that contains nothing else. Account isolation is the operational and security boundary. Keeping 3AM in its own account gives you four properties that matter:

• Transparent billing. AWS bills per account, so 3AM's running cost shows up on its own line. No cost-allocation tags to maintain, no chargeback rules, no risk of 3AM's spend being buried inside a shared workload's bill.
• Bounded blast radius. AxelSpire's deployment role can act in — and see — only this one account. Misconfiguration, compromise, or simple curiosity cannot reach the rest of your estate.
• Clean compliance boundary. CloudTrail, Config, GuardDuty, and Service Control Policies all scope at the account level, so 3AM's audit and compliance posture is self-contained. Auditors review one account, not a slice of a larger one.
• Operational portability. A dedicated account is portable: it can be moved between AWS Organizations, handed back to you in full, or wound down in isolation, without untangling shared resources.

The account is created either by your team (default) or by AxelSpire (managed-onboarding option). Either way, you own the account once onboarding completes. The choice is covered below in Account provisioning.

The vendor access model

Five points define how AxelSpire interacts with the 3AM account at steady state. Each is enforced in code, not policy.

1. AxelSpire holds no long-lived credentials in your AWS account. No IAM users, no static access keys, no stored bearer tokens. AxelSpire's CI assumes the deployment role via STS with a session lifetime measured in minutes. Re-assumption requires the trust policy to still permit it.
2. The audit log lives in your account, not AxelSpire's. S3 Object Lock compliance mode means no principal — including AxelSpire, including your AWS root user, including AWS Support — can modify or delete a receipt before its retention date. This is structurally different from a vendor-side audit export.
3. You can revoke AxelSpire's access in minutes, unilaterally. Three escalating mechanisms exist: rotate the external ID secret (AxelSpire's next apply fails closed), detach the trust policy from the deployment role, or delete the role entirely. None require contact with AxelSpire, a notice period, or a contractual off-boarding window.
4. The deployment role is scoped to one account. It cannot enumerate, read, or write anything in the rest of your AWS estate. The blast radius of any AxelSpire-side compromise is bounded to a single account containing only 3AM.
5. Each AxelSpire change can be gated on your approval, your ITSM system, or your change window. The deployment tier (covered next) determines whether changes auto-apply, wait on a reviewer, fire an SNS notification, open a ServiceNow/Jira ticket, or are blocked outside a declared change window enforced in the trust policy itself.

The combined effect: there is no scenario in this onboarding where AxelSpire ends up with access you cannot revoke, and no scenario where AxelSpire can act in your account without leaving an immutable record in storage you control. Trust is something the architecture lets you verify, not something you accept on a contract.

Deployment tiers: approval gates before each AxelSpire change

The tier is your largest operational decision. It does not change what 3AM is or what the deployment role can do — it changes how much friction sits between an AxelSpire engineer pushing a change and that change applying.

Tier 4 is technically distinctive: the change window is enforced in the cross-account trust policy, not in CI logic. AxelSpire's CI cannot assume the deployment role outside the window even if it tries. This is the strictest available posture without moving to the air-gapped pattern, which removes AxelSpire CI from the access path entirely (covered below in Apply patterns).

If you are unsure, pick tier 1. You can move up later by re-applying the onboarding module with a different value; no re-deployment of 3AM itself is required.

Account provisioning: who creates the account?

Two paths to the empty account 3AM lands in:

The choice does not change what gets created or who has access at steady state. It only changes who creates the empty account it lands in.

Apply patterns: who runs the initial setup?

A separate decision from account provisioning: who actually applies the onboarding module into the account.

• Pattern A — AxelSpire-applied (default). AxelSpire applies the onboarding module via the deployment CI. Fastest. The cross-account trust grant is established as part of the apply.
• Pattern B — customer-applied. Your team applies the open-source 3am-customer-onboarding OpenTofu/Terraform module from your own CI. Same resources as pattern A; the difference is who holds the credentials at apply time.
• Pattern C — air-gapped customer-applied. Highest assurance. AxelSpire CI is not in the access path at any point. The module is delivered as a signed bundle; your team verifies signatures offline, applies, and destroys the local copy of any external ID after handover.

Patterns B and C are the right choice when internal policy requires that you own the apply boundary, or when 3AM is being deployed into an environment where third-party CI access is prohibited categorically. The trade-off is that your platform team takes on the apply-time responsibility, including keeping the module pinned to verified versions.

Calendar time and effort

A typical onboarding into one account and one region. Multi-region adds a few hours per region, mostly on the platform engineer.

Critical-path gating is almost entirely customer-side: procurement, design review, account vending, IAM governance, change-management. AxelSpire-applied (default pattern) is fastest. Customer-applied adds a day. Air-gapped is the slowest because of the offline bundle verification step.

Decisions you sign off in the design review

These are the inputs that drive every other engineering decision. The design-review meeting exists to walk through them once and close them.

If your IP allocation is centrally managed, lock decision 10 in before apply — changing the VPC CIDR after deployment requires a full re-deploy of the 3AM environment and is the only post-apply decision in this list with that property.

By default, AxelSpire deploys 3AM under a hostname on an AxelSpire-owned domain (e.g. <customer_id>.3am.axelspire.io) so the service is reachable on day one without waiting on your DNS team. The cutover to a hostname under your own domain can happen at any time post-deployment without a re-deploy.

Operational risk register

Eleven failure modes have been observed or modelled in 3AM onboardings. The headline is that the vendor access model bounds severity: nothing in the operational onboarding gives AxelSpire durable access you cannot remove.

A8 and A10 are the only entries where post-apply recovery is genuinely disruptive. Both are addressed by getting the network and Organization decisions right at design review, before any engineering happens.

Pre-flight readiness check

Before the design review meeting, the checklist below produces a recommended deployment tier, apply pattern, and account provisioning option from a short set of environment questions, and lists the specific items to resolve before kickoff. Output is computed in your browser; nothing is sent anywhere.

How this compares to typical managed PKI deployment

The 3AM deployment model is unusual relative to most managed PKI and certificate lifecycle management platforms. Keyfactor Command, Venafi TLS Protect Cloud, DigiCert Trust Lifecycle Manager, and AWS Private CA when consumed via a third-party operator typically deploy under one or more of the following patterns:

• Vendor-side hosted control plane. Certificate metadata, issuance history, and operational telemetry live in the vendor's infrastructure. Auditing what the vendor did to your tenant is rate-limited by the vendor's audit export interface and the vendor's retention policy.
• Long-lived API credentials. Integration is typically via API keys or OAuth tokens scoped to a tenant. Rotation requires vendor cooperation; revocation is a tenant-disable action that depends on the vendor's control plane being available and willing.
• Vendor administrative access by default. Vendor support and operations teams hold privileged roles that span tenants. Tenant-side restriction of that access is a contractual control, not a technical one.

3AM's onboarding is the inverse of each. The control plane runs in your AWS account. There are no long-lived credentials. AxelSpire's access is a single scoped role you can detach. The audit log uses S3 Object Lock compliance mode in your account, which means even AxelSpire combined with AWS root cannot retroactively rewrite history. Whether that posture is worth the operational trade-off — you operate AWS, AxelSpire operates 3AM — is the genuine architectural decision a buyer is making, not whether the vendor is "trustworthy" in the abstract.

Frequently asked questions

Does AxelSpire have access to certificate private keys issued by 3AM?

No. Private key operations are performed by AWS KMS using a CMK in your account. AxelSpire's deployment role can invoke the key for issuance operations during the windows the tier permits, but the key material itself never leaves the KMS HSM boundary and cannot be exported. The CMK's administrative policy is held by your break-glass roles, not AxelSpire.

What happens if AxelSpire goes out of business or is compromised?

The 3AM account is in your AWS Organization, the CMK is in your account, the audit log is in your account, and the IAM roles are administered by you. Detaching the trust policy on the deployment role ends AxelSpire's ability to act in the account immediately. The certificate authority itself continues operating against the CMK; what stops is AxelSpire's ability to deploy updates. Continuity-of-service planning for that scenario is part of the design review.

Can we operate 3AM without AxelSpire deploying changes at all (pattern B or C)?

Yes. The onboarding module is open-source. Pattern B has your team apply it from your CI; pattern C is air-gapped. Both produce the same resources as the AxelSpire-applied default. Subsequent 3AM deployments can also be customer-driven, at the cost of taking on the operational burden AxelSpire otherwise carries.

How is the 3AM audit log different from AWS CloudTrail?

CloudTrail records the AWS API calls AxelSpire's role makes. The 3AM audit log records the higher-level intent: which 3AM stack was deployed, which version, with which configuration, who approved it, and the diff against the previous state. Both run in your account. CloudTrail tells you what happened at the API layer; the audit log tells you what was changed in 3AM itself. Object Lock compliance mode applies to the latter.

What does the daily drift report contain?

A diff between the desired 3AM configuration committed to AxelSpire's deployment repository and the live state in your account, plus a list of any out-of-band changes detected. It is published to the SNS topic in your account at 02:00 UTC daily. If the diff is non-empty, the next steady-state apply will reconcile it; tier 1+ blocks the apply on review so you can investigate first.

Is 3AM compatible with our existing PKI estate (Microsoft AD CS, EJBCA, HashiCorp Vault PKI)?

3AM functions both as a standalone CA and as a control plane that fronts other backend CAs. The control-plane mode is the integration path for existing PKI. AxelSpire's PKI consultancy work covers the migration and integration design separately from the deployment described on this page. See 3AM Control Plane for the architecture detail.

What regions is 3AM available in?

US, UK, and EU AWS regions are the standard footprint. Other regions on request. Multi-region deployment with a shared AWS KMS multi-region CMK is supported and selected at design review (decision 11).

Next steps

For the higher-level argument for why 3AM exists and what makes a PKI control plane different from a CLM platform, return to 3AM Control Plane. For the compliance and audit-log detail — frameworks the audit primitive maps to, retention policy, evidence patterns — see 3AM Compliance.

If you are evaluating 3AM and want to walk through the deployment model against your specific security review checklist, the fastest path is Ask Axel — the on-site assistant that has the full 3AM documentation indexed and answers architecture-specific questions directly. For a design-review conversation with the AxelSpire team, contact us.

Related Resources

About AxelSpire and 3AM

AxelSpire is a B2B PKI consultancy and product company founded by Dan Cvrcek, with roughly a decade of PKI architecture across financial services and high-volume internet/operator environments and post-doctoral research at the University of Cambridge. AxelSpire's core product, 3AM (AxelSpire Automated Management), is a serverless certificate authority and multi-PKI control plane built on AWS KMS. AxelSpire operates in the US, UK, and EU, with additional regions on request.

Authored by Dan Cvrcek (AxelSpire). AxelSpire is a vendor-neutral PKI and certificate lifecycle management consultancy.