Which AWS Services Are HIPAA-Eligible? The List and What It Actually Means

Which AWS services are HIPAA-eligible? The ones AWS lists as HIPAA-eligible — on the order of 130-plus today and still growing — are the only services covered by the AWS Business Associate Addendum (BAA), which makes them the only services you may use to store, process, or transmit protected health information (PHI). Everything else — a service too new to be added, an edge feature, a region-limited preview — sits outside the BAA, and routing PHI through it is a compliance gap whether or not a single record ever leaks. The list moves, so the count is the wrong thing to memorize; verify each service you touch against the AWS HIPAA-eligible-services page as a runtime check, not a one-time decision.

That is the whole answer, and it is also where most healthcare teams go wrong. They pull the list once, tick the boxes, and treat “eligible” as if it meant “compliant.” It does not. Eligibility is a contractual boundary drawn by AWS; compliance is the work you do inside it. This article is about the difference — what the list actually means, which categories it covers, and how to keep from misreading it. It pairs with our minimum-viable HIPAA posture on AWS, where using only eligible services is control number two of twelve.

What does “HIPAA-eligible” actually mean?

It means AWS has placed the service in scope of the BAA — nothing more, nothing less. The BAA is the contract that makes AWS your HIPAA business associate: it commits AWS to handling PHI according to the Security Rule’s requirements on the parts of the stack AWS controls. When AWS declares a service “HIPAA-eligible,” it is saying “we will stand behind this service under the BAA.” When a service is absent from the list, AWS is making no such commitment, and any PHI you put there is uncovered.

So “eligible” is a legal-coverage status, not a security rating. It does not mean the service is more secure than a non-eligible one. It does not mean the service ships in a compliant configuration. It means one specific thing: this service is inside the contract. Get that framing right and the rest of the list stops being confusing.

Two consequences follow immediately. First, you must actually sign the BAA — it is self-service in AWS Artifact, and until you accept it, none of your services are covered, eligible or otherwise. Second, the BAA extends only to the eligible services, so the coverage you just signed for evaporates the moment PHI flows into a service that is not on the list.

Which AWS services are HIPAA-eligible?

Nearly all the core building blocks are, and the long tail of newer and specialized services is where the gaps live. The table below groups the common categories, names representative services AWS has listed as eligible, and flags the caveat that matters for each. Treat the service names as illustrative and approximate — the authoritative, current list is the AWS HIPAA-eligible-services page, and it changes often enough that you should check rather than trust this snapshot.

The pattern is consistent: if it is a foundational, widely deployed service, assume it is eligible and confirm. If it is new, niche, generative-AI-flavored, or a preview, assume it is not eligible until you have verified it is. That default — suspicious of the shiny thing, trusting of the boring building block — is the right instinct for regulated infrastructure generally.

Does HIPAA-eligible mean HIPAA-compliant?

No, and this is the single most expensive misreading of the list. Eligibility gets a service into the room. Compliance is everything you do once it is there.

An eligible service handles PHI compliantly only if you have also: signed the BAA, encrypted the data at rest (KMS) and in transit (TLS 1.2 or higher), scoped access to least privilege, and shipped audit logs somewhere tamper-proof. Skip any of those and you have a non-compliant deployment sitting on a perfectly eligible service. The canonical example is an S3 bucket: S3 is eligible, has been for years, and is on nearly every healthcare team’s stack — and a misconfigured, public, unencrypted S3 bucket is one of the most common ways PHI gets exposed. The service being on the list did nothing to prevent that.

This is why we frame eligibility as the second control in the minimum-viable HIPAA posture, not the whole of it. The other eleven controls — account separation, MFA, encryption, tamper-proof logging, backups — are what turn an eligible service into a compliant one. Most of that same control set also carries straight into a SOC 2 readiness effort, because the encryption, access, and log-integrity requirements overlap almost entirely; if you are still deciding which framework you even owe your buyers, start with choosing between SOC 2, HITRUST, and HIPAA before you optimize the service list.

The verdict: eligibility is necessary and nowhere near sufficient. It is the price of entry.

Why is eligibility a runtime check, not a one-time decision?

Because the list grows, and your architecture drifts, and the two move independently. AWS adds services to the BAA over time — a service that was not eligible when you evaluated it last year may be eligible now, and, more dangerously, a shiny new service your team just adopted may not be eligible yet even though everything around it is. A one-time “here are our approved services” spreadsheet is stale the day after you write it.

Two failure modes come from treating eligibility as static. The first is an engineer reaching for the newest managed service to solve a problem — a new AI summarization API, a new streaming primitive — without anyone checking whether it is covered, and PHI quietly flowing into it. The second is subtler: PHI ending up somewhere nobody architected for it. Observability is the classic route. Logs, traces, and metrics capture PHI by accident all the time — a patient ID in a URL, a full request body in a stack trace — and if that telemetry lands in a tool or service that is not eligible (or outside the BAA entirely, like a third-party SaaS observability vendor without its own BAA), you have a breach that started as a debug log.

The fix is to make eligibility a control you run, not a decision you made. Practically: keep a living map of every service in your PHI data path, re-check it on a cadence and whenever the architecture changes, and put a gate — a review step, an SCP, a tagging policy — in front of new service adoption in accounts that touch PHI. The AWS HIPAA-eligible-services page is the source of truth; your map is how you know which entries on it you actually depend on.

What does “eligible only in certain configurations” mean?

It means the service qualifies for the BAA, but only when you use it a specific way — and if you use it another way, you are outside coverage even though the service name is on the list. Eligibility occasionally carries conditions: a particular feature must be enabled or avoided, a specific mode must be used, or certain data must not be sent to a certain surface. AWS documents these conditions alongside the eligible-services list.

The trap is reading the service name, seeing it on the list, and stopping there. “RDS is eligible” is true; “therefore anything I do with RDS is covered” does not follow if a specific feature carries a condition. When a service in your PHI path has configuration caveats, the caveat is part of your control, not a footnote — write it into your service map next to the service, and make sure the way you actually run it matches the way that makes it eligible. When in doubt, read AWS’s own conditions for that service rather than inferring from the name.

So what is the good-enough bar?

A regulated SMB has “gotten eligibility right” when three things are true, and no sooner:

1. The BAA is signed in AWS Artifact, before any PHI landed.
2. Every service in your PHI data path is on the current eligible list — including the ones PHI reaches by accident (logging, analytics, telemetry), and used in a configuration that keeps it eligible.
3. Eligibility is a check you re-run, not a decision in an old doc — with a gate in front of new-service adoption in PHI-touching accounts.

Clear that bar and eligibility is handled. It is a low bar by design, because eligibility is only one control; the encryption, access, and logging that make an eligible service compliant are the larger job, covered in the minimum-viable posture. The wrong outcome is the common one: a team that pulled the list once, felt done, and never noticed the day PHI started flowing into a service that was never on it.

Do not over-engineer this. You do not need a bespoke compliance database to track eligibility for a ten-service stack — a maintained page in your runbook and a review gate will do. You do need to stop treating “it’s on the list” as the end of the conversation.

The Template

The service map below is the artifact that keeps eligibility honest. List every AWS service that touches PHI — including the ones PHI reaches indirectly through logs, traces, backups, and analytics — and score each row. Anywhere a row is not clean, decide one of three things: fix it this sprint, accept and document the gap, or escalate it as a compliance risk. Keep it in your runbook and re-run it on a cadence and on every architecture change.

Prerequisite (do this first)

• AWS Business Associate Addendum (BAA) accepted in AWS Artifact
• A named owner for this map and a review cadence (quarterly, minimum)

Per-service checklist — one row per service in the PHI data path

• Service name and what PHI it touches (stored / processed / transmitted / incidental)
• Confirmed on the current AWS HIPAA-eligible-services page (date checked: ______)
• No configuration caveat — or, if there is one, we run it in the eligible configuration
• Encrypted at rest (KMS) where it holds PHI
• Enforces TLS 1.2+ in transit where it transmits PHI
• Access scoped to least privilege
• Activity logged to the tamper-proof archive

Don’t-forget-these rows (PHI reaches them by accident)

• Logging / monitoring destinations (CloudWatch, and any third-party observability tool — does it have its own BAA?)
• Tracing and APM spans
• Analytics / data-warehouse pipelines fed from PHI stores
• Backup and DR targets, including cross-region copies
• Any queue, cache, or search index in the request path

Governance

• A gate exists (review step, SCP, or tagging policy) before new services are adopted in PHI-touching accounts
• The map was re-checked against the AWS list on the last review date
• Every non-clean row has a decision recorded: fix / accept-and-document / escalate

Run it once to find where PHI actually flows, then re-run it whenever the architecture moves. Eligibility is not a fact you learn once; it is a boundary you patrol.