Workloads stay separated.
Development, production, and security records do not share one blast radius.
Before the product · Entry 001
Build the boundary before the feature.
How I built CareFlow’s HIPAA-ready AWS foundation in the order that made the rest of the SaaS possible.
Most cloud tutorials begin with an application. Mine began with everything the application would have to trust: the agreement, the account boundary, human identity, encryption keys, private routes, and a record of every important action.
That order matters in health technology. AWS supplies eligible services and a Business Associate Addendum. It does not assemble those pieces into a compliant product. CareFlow’s first infrastructure milestone was therefore not “deploy the app.” It was “create the environment where an app could eventually handle sensitive clinical data responsibly.”
Chapter 01
The four promises the foundation had to keep.
Before choosing individual resources, I reduced the problem to four durable promises. They became the test for every later decision.
Access names a person.
Short-lived sessions replace shared administrators and static credentials.
Data domains have their own keys.
Storage, database, and audit encryption remain independently understandable.
History survives the workload.
A compromised application account cannot erase the evidence of its own actions.
AWS can make a service eligible.
I still have to make the system trustworthy.
I still have to make the system trustworthy.
Chapter 02
Three accounts. Three different jobs.
The management account manages the organization and hosts no workloads. Development and production run the product. Security owns the records the product accounts must not be able to destroy.
01 · Development
Learn safely.
Build and verify the system without sharing production’s risk boundary.
WORKLOAD ACCOUNT02 · Production
Serve deliberately.
Keep real workloads isolated from experiments, tooling, and early iteration.
WORKLOAD ACCOUNT03 · Security
Remember independently.
Receive audit records across the account boundary with delivery-only access.
LOG ARCHIVEChapter 03
The order that made the build work.
Each step created a safe dependency for the next. Reversing the order would mean rebuilding controls around resources already carrying risk.
01
Accept the agreement
Put the AWS BAA in place and understand which services it covers before PHI or application code enters the environment.
02
Create the organization boundary
Build the OU and development, production, and security accounts. Keep the management account empty.
03
Remove permanent human credentials
Use IAM Identity Center, named users, MFA, groups, and short-lived sessions.
aws sts get-caller-identity04
Bootstrap Terraform state
Create one encrypted, versioned, TLS-only state bucket per account with native locking and protection from accidental destruction.
05
Separate encryption domains
Use distinct KMS keys for PHI objects, relational data, and audit records. Turn automatic rotation on.
06
Build the network without unnecessary egress
Create public, private-application, and private-data tiers. Add free gateway endpoints first; gate hourly network services until a workload requires them.
07
Export the audit trail
Send validated CloudTrail logs across accounts so the workload can write its history but cannot read or erase it.
Chapter 04
The most important control was something I did not create.
The private-data route table has no default route to the public internet. Isolation is expressed as an absent path, not another permissive rule that has to remain perfect.
Private application tier
Controlled paths
VPC networkLOCAL
AWS storageENDPOINT
Approved egressWHEN NEEDED
Private data tier
No public destination
VPC networkLOCAL
S3 / DynamoDBENDPOINT
0.0.0.0/0ABSENT
PHI isolation as the absence of a route
Chapter 05
A decision ledger, not a victory lap.
A useful build journal records what was chosen, why, and what remains deliberately off. That makes the architecture reproducible—and keeps later tradeoffs honest.
| Decision | What I chose | Why | State |
|---|---|---|---|
| D-01 | Separate security account | Audit history must outlive a workload-account compromise. | Built |
| D-02 | No static IAM keys | Short-lived identity reduces leakage risk and preserves attribution. | Built |
| D-03 | Three KMS domains | Smaller blast radius and clearer audit evidence. | Built |
| D-04 | No data-tier internet route | The strongest accidental-egress path is one that does not exist. | Verified |
| D-05 | Hourly network services off | Pay when a workload needs them, not while the foundation waits. | Gated |
Chapter 06
What this first build taught me.
The transferable value is not the resource list. It is the reasoning that determines when a control belongs in the sequence.
Trust architecture compounds.
When account boundaries, identity, keys, and audit ownership are correct first, every later product feature inherits a safer default.
Security and frugality can agree.
Structural controls, gateway endpoints, and usage-based services can establish the boundary without turning on every hourly meter.
A diagram is not evidence.
Inspect route tables, caller identity, trail health, and archive delivery. Test the claim the architecture makes.
Record why—not only what.
The decision behind a separate security account will remain useful longer than a screenshot of its console page.
Field check
Before the first protected record arrives.
Use this as a reading aid, then prove each item independently in your own environment.
0 of 8 checked · saved nowhere
Visual edition
Build the boundary before the feature.
A narrated visual edition of this journal entry, tracing the foundation from account separation and temporary human access through network isolation and an audit history owned outside the workload.