Services/Cloud Architecture

Cloud Architecture

Cloud architecture in a regulated environment is a scoping decision before it is an engineering one. The boundary you draw determines the control count, the evidence you owe, and what an assessor is entitled to inspect. Draw it wide and you inherit controls for systems that never touch regulated data. Draw it badly and you find out during assessment.

We build multi-account landing zones codified in Terraform, with network segmentation, explicit egress deny, KMS key policies that carry no wildcard principals, and IAM trust policies scoped to the exact role that may assume into the data plane. The result is reproducible across environments, reviewable in a pull request, and diffable when an assessor asks what changed. The discipline is the same under every framework. What differs is where the boundary falls and how many controls sit inside it.

By framework

HIPAA Cloud Architecture

Built around the PHI boundary rather than the application boundary, so the scope is decided before the first module is written. Roughly 75 controls in the HIPAA Security Rule set.

HIPAA cloud architecture →

FedRAMP Cloud Architecture

The authorization boundary drawn, agreed and documented before any Terraform is written, with control narratives ready for assessment. 323 controls at Moderate, 410 at High.

FedRAMP cloud architecture →

FedRAMP GovCloud IaC

For teams whose boundary is already decided: the infrastructure as code, a federated deployment path with no long-lived keys in CI, and evidence that emits rather than gets assembled before an audit.

GovCloud infrastructure as code →

Not sure which applies, or where your boundary should fall? That is what the scoping call answers. Written proposal within 48 hours.

Book a 30-minute call