FedRAMP cloud architecture, built to pass the boundary review.

FedRAMP is the moat. Most teams underestimate the engineering.

Selling into federal buyers without an authorization is increasingly off the table. Selling with one takes most teams 18 months and a six-figure engineering bill. Not because the controls are exotic. Because the architecture decisions made in month one are still being unwound in month fourteen.

We have shipped FedRAMP-aligned environments for AI SaaS vendors selling into federal buyers, defense subcontractors moving from commercial cloud into GovCloud, and federal systems integrators rebuilding inherited infrastructure under a tighter authorization boundary. The pattern is the same: the security controls are knowable, the deadline is real, and the engineering bottleneck is architectural decisions that should have been made before anyone wrote Terraform.

Stonebridge does the architectural work first, so the assessment phase becomes evidence collection against a system that was built to satisfy the controls, not a remediation sprint against one that was not.

NIST 800-53 controls the infrastructure must satisfy by design.

FedRAMP Moderate inherits roughly 325 controls from NIST 800-53 Rev. 5. High inherits more. Most of those controls touch the cloud environment directly. A correctly-built FedRAMP environment satisfies the technical controls through how the infrastructure operates, not through policy documents that describe what it is supposed to do.

The control families the infrastructure most directly touches:

• AC · Access ControlIdentity federation, role separation, least-privilege IAM, and session management that survives FedRAMP assessment scrutiny.
• AU · Audit & AccountabilityCentralized, tamper-evident logging across every account, region, and service with retention that meets High baselines.
• CM · Configuration ManagementInfrastructure as code with signed, reviewed, and versioned changes. Drift detection on the production boundary.
• IA · Identification & AuthenticationFIPS-validated cryptography, phishing-resistant MFA, and PIV/CAC integration where required.
• SC · System & Communications ProtectionBoundary defense, encrypted transit, KMS-backed encryption at rest, and zero-trust network architecture inside the boundary.
• SI · System & Information IntegrityContinuous vulnerability scanning, patch management, and signed-artifact deployment so production state is provably derived from approved code.

None of these are exotic. All are routinely missed in cloud environments designed without FedRAMP boundaries in mind from day one.

Boundary discipline, not boundary creep.

The architecture pattern that consistently survives 3PAO assessment rests on four principles. The implementation differs across AWS GovCloud, GCP Assured Workloads, and Azure Government, but the architecture is identical.

Principle 1: An explicit, narrow authorization boundary

Most FedRAMP failures begin with a boundary diagram that includes too much. Every service, account, network range, and data store inside the boundary is in scope; every dependency outside must be inherited from another authorized service or excluded entirely. We draw the boundary before writing Terraform, and we hold the line on it.

Principle 2: Identity and network isolation by account, not by tag

Production, staging, logging, and shared services live in separate accounts (AWS), projects (GCP), or subscriptions (Azure) with explicit network peering and zero implicit trust. Identity federates from a central IdP with role-based, time-bounded access. This survives the assessment question that kills most quick-fix architectures: "show me that a developer cannot reach production data."

Principle 3: Logging as the system of record

Every account ships every relevant log to a centralized, write-once, retention-locked logging account. CloudTrail, VPC Flow Logs, EKS audit logs, KMS key usage, IAM Access Analyzer findings: all of it. Logging is not a feature. It is the system of record auditors will use to validate every other control.

Principle 4: Continuous control evidence emission

The pipeline that deploys into the boundary emits evidence on every change: SBOMs, vulnerability scans, signature chains, policy decisions, change tickets. These are stored separately from CI infrastructure with retention locks. When the auditor asks for evidence of a specific control at a specific point in time, the answer is a query, not a project.

Six artifacts your 3PAO will ask for.

A FedRAMP Boundary Build engagement produces a defined set of deliverables, each mapped to controls and ready for assessment package inclusion. Nothing is bespoke that does not need to be.

Five patterns that fail boundary review.

We see the same mistakes repeatedly when teams pursue FedRAMP without architectural help. None are about not knowing what FedRAMP wants. They are about not knowing how to structure the boundary so it works.

1. Boundary scope creep

   Pulling shared developer tooling, observability stacks, and corporate identity into the authorization boundary expands scope by 3-5x and adds months of remediation. Inherit from authorized services where possible. Keep the boundary narrow and defensible.

2. Commercial-region habits inside the boundary

   Using non-FIPS endpoints, non-regulated services, or commercial-region defaults inside GovCloud will fail assessment. The infrastructure-as-code library has to enforce regulated defaults. Engineers cannot be expected to remember.

3. Logging that an engineer can edit

   If audit logs live in an account where engineers have write access, the entire AU control family is compromised. Logging needs its own account, retention locks, and access boundary distinct from production engineering.

4. Manual evidence collection at assessment time

   Producing evidence by hand the week before 3PAO assessment burns weeks and often fails to produce point-in-time evidence the auditor asks for. Evidence emission is a property of the pipeline; the assessment phase is querying it.

5. Treating the SSP as documentation, not architecture

   System Security Plans written after the build always lie. Write the control narratives alongside the Terraform. Every module ships with the controls it implements, and the SSP is generated from that source of truth.

Two ways to engage. Fixed scope, fixed price.

Most clients start with the readiness audit. It is faster, cheaper, and produces a written roadmap that often gets approved as a follow-on build engagement. Clients with a known ATO deadline come straight to the build.

A representative engagement.

One of our FedRAMP engagements involved architecting the authorization boundary for an AI SaaS vendor that needed to sell into federal buyers. The internal team had strong engineering practice but no prior federal experience and a real customer deadline.

Frequently asked, directly answered.