Terraform Modules That Ship HIPAA and SOC 2 Controls as Default AWS Infrastructure Primitives

For startups building on AWS, the most reliable path to HIPAA and SOC 2 readiness is to encode infrastructure controls in Terraform modules before deployment, then block changes that bypass them. Modules can enforce encryption, logging and access restrictions, but independent audit work and organizational safeguards remain outside Terraform.

Why encoding compliance controls at the module level changes what an audit actually examines

The audit’s clock starts when someone asks for evidence. The deployment’s clock starts before that, when infrastructure begins serving traffic or storing data. Controls added during an audit pass cannot undo the time a non-compliant resource spent in production. Encoding controls in module source moves enforcement ahead of deployment.

compliance.tf describes an evidence chain rooted in the customer’s own AWS account. AWS Config generates evidence from the configuration state each terraform apply leaves behind, which can be mapped to clauses such as SOC 2 CC6.1 and HIPAA §164.312. The audit then examines an enforced configuration. There is an important tooling limit here. AWS Audit Manager entered maintenance mode in April 2026 and is no longer available to new accounts, so new builds cannot assume its automated evidence collection and mapping are available.

What the two frameworks actually require at the infrastructure layer

HIPAA and SOC 2 converge on five infrastructure control categories, making a shared baseline viable. The overlap is useful, but it is bounded. A Terraform kit implements technical controls that auditors verify, and SOC 2 certification requires an independent audit by a licensed CPA firm. Full HIPAA compliance also requires administrative and physical safeguards.

Encryption uses customer-managed KMS keys, one per service, and each key has its own rotation and audit trails. That maps to SOC 2 CC6.1 and CC6.7 and HIPAA §164.312(a)(2)(iv). Network isolation adds private subnets, outbound access only through network address translation, VPC Flow Logs capturing all traffic, and S3 and DynamoDB gateway endpoints. Default security groups have zero rules. These are the network controls that map to SOC 2 CC6.1 and CC6.6.

The audit trail combines CloudTrail, AWS Config, GuardDuty and encrypted S3 with Object Lock, mapping to SOC 2 CC7.2 and CC7.3 and HIPAA §164.312(b). Under CC6.2 and CC6.3, the identity controls include MFA enforcement, permission boundaries, a break-glass emergency role, a read-only auditor role and an account-level password policy. Storage needs its own restrictions as well. Confidential storage uses SSE-KMS with a designated customer-managed key, bucket policies denying non-TLS requests and unencrypted uploads, versioning and access logging. Teams can add WORM Object Lock for retention protection, and the storage controls map to C1.1, CC6.1 and CC6.7.

How Terraform modules can enforce those controls so they cannot be skipped

A private or authenticated module registry can act as a drop-in replacement for ordinary modules. The security settings are in the module source, so developers cannot turn them off through input variables. Initialization downloads that source, while planning exposes the enforced configuration before deployment. The distinction between those stages is important. terraform init brings in the controls, but terraform plan exposes violations before terraform apply.

compliance.tf demonstrates the change with a single source-line replacement, swapping registry.terraform.io/... for soc2.compliance.tf/.... Inputs and outputs stay the same, and the plan shows server-side encryption, public-access blocks and logging without developers having to set them up. The workflow does not need a separate security configuration step. The compliancetf/starter-kit-healthtech-hipaa kit similarly fails planning when a required HIPAA control is unsatisfied, naming the control and offending module. Teams can still make authorized exceptions through compliance.tf query parameters, and every override is logged so that changes that weaken the baseline leave a record.

Checkov and Trivy check plans or state and report findings, while module enforcement keeps a prohibited configuration out of a valid plan. Plan-time scanners can still stop deployment when the pipeline treats findings as failures. Mature programs can use both approaches.

The module inventory and what each named project enforces

The healthtech starter kit is an open-source GitHub project that produces approximately 140 resources in a clean plan with its default configuration. Its network and entry-point coverage includes VPC isolation and flow logs, HTTPS through ALB, API Gateway v2 access logs for PHI routes, WAF and ACM. Compute coverage includes VPC-attached Lambda, private EC2 workers with IMDSv2, and EKS with a private endpoint and encrypted secrets. KMS provides the customer-managed keys used for PHI encryption.

Its data services include RDS PostgreSQL encrypted at creation, Aurora PostgreSQL with Multi-AZ and automated backups, and DynamoDB with KMS and point-in-time recovery. PHI stored in S3 has Object Lock, 7-year retention and cross-region replication, while storage in EFS is encrypted with a customer-managed key. SQS includes a dead-letter queue, ElastiCache Redis includes encryption and Redis AUTH, and OpenSearch is VPC-only with a customer-managed key, HTTPS and audit logs. CloudTrail is explicitly absent from the kit. Teams must add account-level CloudTrail on their own, and the kit also warns that they must rebuild an existing unencrypted RDS instance to add encryption.

Momentum HealthStack is an open-source healthcare project available as the-momentum/healthstack. Its dedicated modules cover OpenVPN access, certificate issuance and rotation, access logging, S3, CloudTrail, HealthLake FHIR services, WAF and flexible networking. Customer-managed encryption keys, access logging and retention policies are configured without manual intervention. Momentum’s published comparison says infrastructure deployment takes 1–2 weeks with HealthStack and 11–16 weeks with a conventional approach.

The official AWS sample AWS Control Tower Controls with Terraform shows how to administer preventive, detective and proactive Control Tower guardrails through Terraform in the AWS-native governance layer. Infrabaseline’s SOC 2-Ready AWS Infrastructure Terraform Kit instead supplies a SOC 2 baseline and auditor-facing mappings. These projects address different deployment scopes. Neither a governance sample nor a readiness kit should be treated as interchangeable with a complete healthcare resource stack.

What these modules do not cover and where teams must still do their own work

compliance.tf defines its scope around resource configuration, framework-to-control mapping and exception management with an audit trail. That includes encryption, logging, access settings and versioning, as well as misconfigurations in modules that cloud security posture tools often flag. Teams are still in charge of IAM policies and identity management. A module may configure an access restriction without settling who should receive access across the organization. Teams must also design the network architecture and segmentation that go beyond the module’s configuration.

Teams also have to handle application security, resources the modules do not cover and runtime monitoring. GuardDuty findings need a response, CloudTrail needs the intended SIEM integration, and incident response procedures must exist outside a resource definition. Organizational policies, training and vendor management cannot be downloaded with a module. HIPAA makes this separation explicit. Technical Safeguards under §164.312 do not replace Administrative Safeguards under §164.308 or Physical Safeguards under §164.310.

These gaps are manageable because they can be named. The starter kit’s explicit CloudTrail omission is more useful than an unqualified compliance claim because it identifies work the adopting team must complete. The same discipline applies to identity, runtime response and resources created outside the kit. Each needs separate ownership and evidence. For infrastructure changes, the next layer is a pipeline that rejects attempts to bypass the approved module path.

Enforcing compliance through the CI/CD pipeline so no unapproved change can reach production

Module defaults protect the resources built through those modules. They do not stop someone from editing module internals or introducing a hand-written resource outside their coverage. The recommended deployment pattern is therefore to run terraform plan on pull requests and terraform apply on merge to main. Policy checks belong before that apply step.

Terraform Sentinel or OPA can reject prohibited configurations before apply, while native SCPs provide account-level restrictions. For example, a policy can block GPU instance types in non-production accounts unless a specific role approves. Checkov and Trivy can scan plans for hand-written configurations and other resources outside module coverage. The scanners fill a different gap here. compliance.tf’s Operational Rules add lifecycle blocks, tagging standards and instance restrictions at download time, letting the platform team configure rules once for every team’s modules.

Deployment access needs hardening as well as policy checks. Infrabaseline’s kit includes a least-privilege OIDC role, PassRole scoping and no credentials in code. That connects pipeline identity to a concrete control an auditor can examine, rather than treating deployment credentials as an unrelated concern. A successful apply then leaves configuration state for AWS Config to collect. Where Audit Manager is available, it can support the evidence mapping, but the maintenance-mode restriction must be accounted for in the build.

Additional controls required when PHI enters GPU and ML pipelines

Protected health information changes the scope of an ML pipeline’s compliance work. Where inference runs, how embeddings are stored, which region is used and whether model inputs are logged all create HIPAA exposure that a standard SOC 2 module set does not fully address. A GPU cluster is not its own compliance boundary. VPC, KMS and CloudTrail modules must be provisioned before PHI-handling inference workloads are deployed into them.

Kubernetes network policies do not satisfy HIPAA §164.312(b) audit requirements by themselves. Systems containing or using ePHI need mechanisms that record and examine activity, with timestamps and user identity serving as best-practice implementation details. For these workloads, teams must confirm kubelet and API server audit logging are enabled. Private endpoints alone are not an audit trail. The starter kit’s EKS defaults provide a private endpoint and secrets encryption, but that does not remove the logging check.

Encryption, segmentation and comprehensive logging also add cost to GPU infrastructure. Teams should budget for them with compute rather than postpone them as post-launch optimization. For startups moving inference from a PaaS environment onto AWS, the base migration work has a defined scope. Terraform module development covering VPC, ECS, RDS, IAM and monitoring typically requires one to two weeks. The compliance module layer is added on top of that base and falls outside the estimate.

How a PaaS-to-AWS migration fits into a compliance-by-default build

Migration is the lowest-cost point to encode these controls because production data has not yet entered the new AWS environment. Adopting Infrabaseline’s kit, compliance.tf or HealthStack at that point allows the first apply to produce a configuration that satisfies the selected infrastructure controls. The RDS encryption constraint makes the consequence concrete, since encryption cannot simply be added to an existing unencrypted instance without rebuilding it.

Account control is a prerequisite for this approach. Shared-tenant PaaS environments cannot run these compliance modules inside the customer’s own AWS account by design. The architecture described here therefore depends on infrastructure running in an account the team controls. That is also the boundary of this guide’s product coverage. These AWS implementations leave the path on another cloud provider unproven, and teams still have to do the organizational work on either cloud.

How do you know a module-based AWS build is audit-ready?

Verify that terraform plan fails when a required control is disabled and that no clean plan can preserve that violation. Then verify the evidence path inside the account. AWS Config must collect the deployed resources’ configuration state, and the evidence must map to the framework clauses under review, including SOC 2 CC6.1 and HIPAA §164.312. Where Audit Manager is available, verify its configuration rather than assuming its presence, while new accounts must account for its unavailability.

Confirm account-level CloudTrail, confirm Kubernetes audit logging where EKS handles PHI, and document IAM and identity management separately from module outputs. Organizational controls need their own evidence too. Verify that administrative and physical safeguards, policies, training and vendor management are documented for the auditor. Those records complete work Terraform cannot perform.

Finally, link the deployed controls to the documentation the auditor will use. Infrabaseline’s SOC 2 Readiness Evidence Map and TSC-to-Terraform mapping with AWS CLI verification commands provide artifacts for that connection. A clean state alone is not enough. In a properly configured account, with collection enabled and controls mapped to the framework, the state left by Terraform becomes part of the audit record.