3.2 · Operations

AWS Setup Checklist

More actions

This is the step-by-step checklist to set up our AWS account for the regulated path of the platform. It is written so that someone who has never used AWS before can follow it end to end, and so that the business partner can read it cold and understand both what we are doing and why. Download the PDF version to share with the partner.

Before you start

Three things have to be in hand before opening AWS. If any of these are not yet in place, complete them first. The other todo-list items in the platform cover setting up the business email, phone, and address.

Prerequisite	Why it matters
Business email address	Use the company domain, not a personal Gmail. The AWS account is business infrastructure and should be tied to a role-style address (e.g. aws@yourdomain.com) that survives any individual leaving.
Business credit card	AWS runs a $1 verification charge that is refunded. The business card keeps AWS expenses separate from personal spending and gives the business its own credit history with AWS.
Phone number reachable during signup	AWS will text or call a verification code during account creation.

Step 1. Create the AWS account

Go to aws.amazon.com and click "Create an AWS Account."
Enter the business email and choose a strong password. Save the password in a password manager.
When prompted, choose the Business account type, not Personal. This matters for billing structure and for the Business Associate Agreement later.
Enter business name, address, and phone number.
Enter the business credit card. AWS will run a $1 verification charge and refund it.
Complete phone or text verification.
Choose the Basic Support plan (free) for now. We can upgrade later if we need direct AWS support engineers.

Step 2. Secure the root account immediately

The email and password you just created own the entire AWS account and all its resources. Compromise of that login is the worst-case scenario. Lock it down before doing anything else.

Log into the AWS console with the new root account.
Click the account name in the top right corner and choose Security credentials.
Enable multi-factor authentication on the root user. Use an authenticator app (1Password, Authy, Google Authenticator) or a hardware key.
Confirm that no access keys exist for the root user. If any do, delete them.
Sign out of the root account. From this point on, the root account is only used for tasks that explicitly require it (billing changes, account closure). Day-to-day work happens through a separate admin user.

Step 3. Set up billing alerts before anything can spike

AWS will let a bill grow indefinitely without warning unless you configure alerts. Do this on day one.

In the AWS console, open Billing and Cost Management.
Under Budgets, create a Cost budget.
Set the four monthly thresholds below. Each threshold sends an email when crossed.
Enable Cost Anomaly Detection for unusual spending patterns.
Subscribe the business email and a phone number to these alerts.

Threshold	What it means in practice
$50	Early warning. At our startup phase the entire bill should sit at or below this number, so crossing it is a signal to investigate.
$100	Approaching the upper end of the expected startup phase. Confirm the spend is from real usage, not a misconfiguration.
$250	Outside the expected startup band. Stop and audit before doing anything else.
$500	Hard alert. Treat as a possible runaway loop or unauthorized access until proven otherwise.

Step 4. Sign the AWS Business Associate Agreement

This is the legal document that puts AWS inside our HIPAA chain. Without it, we cannot route Protected Health Information through any AWS service, regardless of how secure the services themselves are.

In the AWS console, open AWS Artifact.
Go to the Agreements tab.
Find the AWS Business Associate Addendum.
Review the agreement (it is templated; we are accepting AWS’s standard terms, not negotiating new ones).
Accept the agreement. The signed BAA is stored inside AWS Artifact and available for download anytime.
Record the signing date on our BAA Status page.

Step 5. Create an admin user (replace the root account for daily work)

In the AWS console, open IAM (Identity and Access Management).
Create a new user with the name "founder-admin" (or similar).
Attach the AdministratorAccess managed policy.
Enable multi-factor authentication on this user too.
Create an access key for programmatic (CLI) access. Save the access key ID and secret key in the password manager.
From this point on, log in through this admin user for daily work. Reserve root for billing and account-level tasks.

Step 6. Pick the AWS region

All HIPAA workloads need to live inside U.S. regions covered by the AWS BAA. We will use us-east-1 (N. Virginia) as the primary region. This is the largest, cheapest, and most feature-complete region. Backups can live in a secondary region (us-east-2 or us-west-2) for disaster recovery.

Step 7. Install the AWS CLI on the development machine

Install the AWS CLI v2 following AWS’s official instructions for the operating system.
Run aws configure and paste in the access key ID, secret key, region (us-east-1), and output format (json).
Test with aws sts get-caller-identity. It should return the admin user’s identity.

What is next once the account is live

Once steps 1 through 7 are complete, the AWS account is ready for actual infrastructure work. We provision the items below in order. Each one has its own configuration steps that we will work through together once the account exists.

Order	Resource	What we configure
1	RDS Aurora Postgres database	Encryption at rest, automated backups, private subnet, parameter group tuned for our workload.
2	S3 buckets for clinic file uploads	Per-clinic bucket policies, server-side encryption, versioning, lifecycle policies for cold files.
3	Bedrock model access	Request access to Anthropic Claude models in the AWS console. Pin to U.S. regions covered by the agreement.
4	Cognito user pool	Authentication, multi-factor configuration, group membership tied to clinic identity.
5	IAM roles for the application	Short-lived credentials scoped to exactly the resources the Next.js app needs to reach.
6	CloudWatch log groups	Retention configured to six years per HIPAA. Scrubbing helper installed on the application side.
7	Application wiring	Next.js application code reads from RDS, writes to S3, calls Bedrock, authenticates through Cognito, and logs through the scrubbing helper.

Download this page as a PDF using the toolbar at the top. The PDF is intended to give the partner a clean, complete view of the AWS setup we are committing to. It explains both the steps and the reasoning behind each step, so the partner does not have to take any of this on faith.