A HIPAA-eligible AWS account is not a compliant one

You did the obvious things. You signed the AWS Business Associate Addendum, you checked that the services you are using are on the HIPAA-eligible list, and someone on the team said the word "compliant" in a meeting. Then a hospital's security questionnaire arrives, or an auditor asks how patient data is protected at rest and in transit, and the honest answer is a shrug. An eligible account is not a compliant one. AWS gives you services you are allowed to use for protected health information; whether you have actually protected it is entirely down to how you built the infrastructure.

This is the build runbook for that infrastructure - the network, storage, encryption, and logging foundation a healthcare workload needs before a single application line runs on top. It is written for a UK or US team standing up PHI workloads on AWS who need the base to be defensible, not just functional. It is deliberately about the foundation, not the application: get this layer right and everything you deploy above it inherits a safe starting point.

The shared responsibility line is where teams trip

AWS is responsible for the security of the cloud - the hardware, the data centres, the hypervisor. You are responsible for security in the cloud - how you configure the VPC, who can reach the data, whether it is encrypted, and whether you can prove what happened. HIPAA lives almost entirely on your side of that line. The BAA is AWS agreeing to be a business associate; it does not configure a single security group for you. Every control below is yours to build and operate, and an auditor will ask you, not AWS, to evidence it.

Layer 1: a private VPC where PHI never sees the internet

Start with the network, because if the network is wrong nothing above it can be made safe. Put every component that touches PHI - application servers, databases, processing - in private subnets with no route to an internet gateway. Public subnets hold only what must face the internet, typically a load balancer, and even that terminates TLS and forwards to private targets.

The part teams miss: reaching AWS services like S3 or KMS does not require the public internet. Use VPC endpoints (gateway endpoints for S3, interface endpoints for KMS and others) so that traffic to those services stays on the AWS private network. Outbound access for patching goes through a NAT gateway, never inbound. Security groups default to deny and open only the specific ports between the specific tiers that need them. The goal is simple to state and exacting to implement: PHI never traverses the public internet, not even on its way to storage.

Layer 2: S3 that is encrypted, private, and versioned

Most PHI ends up in S3 at some point, and most S3 mistakes are the same handful. Block all public access at the account and bucket level - this is non-negotiable and should be enforced, not just set. Turn on default encryption with a customer-managed KMS key (more on keys next). Enable versioning so an accidental or malicious overwrite is recoverable, and enable access logging or use CloudTrail data events so every object read and write is recorded. Bucket policies should require encryption in transit (deny any request not over TLS) and restrict access to the specific roles that need it, reached through the S3 VPC endpoint rather than the open internet.

The same encryption-and-least-privilege discipline that protects PHI in S3 is the foundation under any sensitive workload on AWS - we walk through the IAM, VPC, and KMS controls in more depth in securing AI applications on AWS with IAM, VPC, and KMS, and the principles carry directly to healthcare data.

Layer 3: KMS customer-managed keys, not the default

Encryption is meaningless if you cannot control and audit the keys. Use KMS customer-managed keys (CMKs) rather than AWS-managed defaults for anything touching PHI, because CMKs give you a key policy you control, rotation you configure, and a full CloudTrail record of every key use - who decrypted what, and when. Scope each key's policy so only the specific roles that need to encrypt or decrypt can use it, and keep key administration separate from key usage so no single role both manages and consumes the key. Encrypt everything: S3 objects, EBS volumes, RDS instances, and any snapshots. Unencrypted data at rest is the single finding that turns a routine audit into a problem.

Layer 4: logging and IAM that make it provable

The final layer is the one auditors care about most: can you prove what happened? Enable CloudTrail in every region, log to a dedicated S3 bucket with object lock so the logs are immutable, and protect that bucket as carefully as the PHI itself. Pair it with VPC flow logs and S3 access logging so you have network-level and object-level records. On the identity side, every human and service uses least-privilege IAM roles - no long-lived access keys for PHI access, no shared admin accounts, MFA on anything privileged. The test is concrete: after an incident, you should be able to answer who accessed which record, from where, and when, without guessing. If you cannot, the logging is not done.

Build the base once, then build safely on top

None of this is exotic. It is a private network, encrypted private storage, controlled keys, and immutable logs - assembled deliberately and documented. The reason it matters is that everything you deploy afterwards sits on this base, so a weak foundation quietly undermines every application above it, while a strong one means each new service starts compliant by default. Once the foundation is solid, building the actual healthcare application - including AI on top of the PHI - follows the same controlled pattern we describe for building HIPAA-compliant AI agents on AWS Bedrock. If you want the foundation built and evidenced for you, our AWS consulting team does exactly this for healthcare workloads.

FAQ

Does signing the AWS BAA make my application HIPAA compliant?

No. The Business Associate Addendum means AWS will act as a business associate and you may use HIPAA-eligible services for protected health information. It does not configure any security controls. Compliance depends entirely on how you build and operate the infrastructure - the network isolation, encryption, access control, and logging are your responsibility under the shared responsibility model.

Does PHI need to stay off the public internet on AWS?

Yes, as far as practical. Keep PHI workloads in private subnets and reach AWS services such as S3 and KMS through VPC endpoints, so traffic stays on the AWS private network rather than the public internet. Outbound access for patching goes through a NAT gateway; inbound public access is limited to a TLS-terminating load balancer in a public subnet.

Should I use AWS-managed or customer-managed KMS keys for HIPAA?

Use customer-managed keys (CMKs) for anything touching PHI. CMKs give you a key policy you control, configurable rotation, and a full CloudTrail record of every key use, which is what lets you prove who decrypted what and when. AWS-managed defaults do not give you that level of control or auditability.

What logging do I need for a HIPAA workload on AWS?

CloudTrail enabled in every region, logging to a dedicated bucket with object lock so the records are immutable, plus VPC flow logs and S3 access logging. The standard to meet is being able to reconstruct, after an incident, who accessed which record, from where, and when - without guesswork. If your logs cannot answer that, they are not complete.

The bottom line: HIPAA on AWS is earned in the configuration, not the contract. A private VPC, encrypted and private S3, customer-managed KMS keys, least-privilege IAM, and immutable CloudTrail logs are the foundation that makes a healthcare workload defensible. Build that base once, document it, and everything you put on top starts from a position you can stand behind in front of an auditor.