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

Canonical: https://kaansystems.com/library/hipaa-eligible-aws-services
Topic: Compliance · Published: 2026-09-16 · Updated: 2026-09-16
Summary: AWS publishes a list of HIPAA-eligible services — the ones covered by its Business Associate Addendum — and healthcare teams routinely misread it. Eligibility is a contractual boundary, not a security rating: it says a service can hold PHI under the BAA, not that yours is configured to. Here is what the list actually means, the common categories, and why you treat it as a runtime check.

## Key takeaways

- "HIPAA-eligible" means a service is covered by the AWS Business Associate Addendum (BAA) — it is the only category of service you may use to store, process, or transmit PHI. Running PHI through a non-eligible service steps outside the BAA entirely.
- Eligibility is not compliance. The list tells you a service can legally hold PHI; it says nothing about whether you have signed the BAA, encrypted the data, scoped access, or turned on logging — all of which are still yours to do.
- The list is long (north of 130 services today and growing) and it changes, so the exact count is the wrong thing to memorize; verify current eligibility against the AWS HIPAA-eligible-services page rather than trusting a one-time decision.
- Core building blocks are almost all eligible — EC2, S3, RDS, DynamoDB, Lambda, EKS/ECS, CloudTrail, KMS — while newer, edge, and generative-AI services are the most likely to lag; some services are eligible only in certain configurations.
- Sign the BAA in AWS Artifact before any PHI lands, and treat eligibility as one control inside a fuller posture, not the whole of it.

**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](/library/minimum-viable-hipaa-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.

| Category | Representative eligible services | Notes / caveats |
|---|---|---|
| Compute | EC2, Lambda, ECS, EKS, Fargate, Batch, Elastic Beanstalk | The core compute plane is well covered. Verify newer runtimes and instance-adjacent features; eligibility attaches to the service, not automatically to every preview capability inside it. |
| Storage | S3, EBS, EFS, FSx, Storage Gateway, AWS Backup | Eligible, but encryption and access controls are entirely on you — an eligible bucket left public is still a breach. Confirm any newer storage tier or feature. |
| Database | RDS, Aurora, DynamoDB, ElastiCache, Redshift, DocumentDB, Neptune | Broadly eligible. Some engines or specific features can carry configuration conditions; check the engine and version you actually run, not just the service name. |
| Networking / delivery | VPC, ELB/ALB/NLB, CloudFront, API Gateway, Route 53, Direct Connect, Transit Gateway | Eligible, but TLS enforcement and private routing are your configuration to get right. Eligibility says nothing about how the endpoint is secured. |
| Analytics | Athena, Glue, EMR, Kinesis, MSK, QuickSight, Data Firehose | Many are eligible; the analytics space adds services quickly, so the newest entrants are the likeliest to lag. Verify before piping PHI-derived data through them. |
| ML / AI | SageMaker, Comprehend Medical, Textract, Transcribe, Rekognition | Established ML services are widely eligible. Generative-AI and the newest AI services are the category most likely *not* yet covered — verify current eligibility explicitly before sending any PHI. |
| Security / logging / mgmt | CloudTrail, CloudWatch, KMS, AWS Config, GuardDuty, Secrets Manager, IAM / Identity Center, Systems Manager | This is your controls layer, and it is well covered. These are the services that make the *rest* of your posture defensible — encryption keys, audit logs, access. |

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](/library/minimum-viable-hipaa-aws), 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](/library/soc2-for-startups-complete-guide), 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](/library/choosing-soc2-hitrust-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](/library/securing-phi-observability) — 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.

## Frequently asked questions

**Q: Which AWS services are HIPAA-eligible?**

The HIPAA-eligible services are the ones AWS lists as covered by its Business Associate Addendum (BAA) — on the order of 130-plus today and growing. That includes nearly all the core building blocks (EC2, S3, RDS, Aurora, DynamoDB, Lambda, EKS, ECS, VPC, CloudFront, API Gateway, CloudTrail, CloudWatch, KMS, and many more), with newer, edge, and generative-AI services the most likely not yet covered. The list changes over time, and some services are eligible only in certain configurations, so verify current eligibility against the AWS HIPAA-eligible-services page rather than trusting a static list. If a service is not on it, do not use it for PHI.

**Q: What does HIPAA-eligible mean?**

HIPAA-eligible means AWS has placed the service in scope of the AWS Business Associate Addendum (BAA), the contract that makes AWS a HIPAA business associate for that service. It is a contractual boundary, not a security score. Using an eligible service, with the BAA signed, keeps your PHI inside AWS's business-associate coverage; using a service that is not eligible puts that PHI outside the BAA, which is a compliance gap regardless of whether anything ever leaks.

**Q: Does HIPAA-eligible mean HIPAA-compliant?**

No. Eligibility says a service can legally hold PHI under the BAA; it says nothing about whether your deployment is compliant. You still have to sign the BAA in AWS Artifact, encrypt the data at rest and in transit, scope access to least privilege, and log everything to a tamper-proof archive. A perfectly eligible S3 bucket that is public and unencrypted is a breach waiting to happen. Eligibility is the price of entry, not the finish line.

**Q: Is S3 (or Lambda, or DynamoDB) HIPAA-eligible?**

Yes — S3, Lambda, and DynamoDB are all HIPAA-eligible and among the most commonly used services under the AWS BAA, as are EC2, RDS, Aurora, EKS, ECS, and the core networking and security services. Eligibility still assumes you have signed the BAA and configured the service correctly (encryption, access, logging). For any service you are less sure about — especially newer or AI-oriented ones — check the current AWS HIPAA-eligible-services page instead of assuming, because the list moves and some services qualify only in specific configurations.

**Q: Do I need a BAA with AWS?**

Yes. If you store, process, or transmit PHI on AWS you must accept the AWS Business Associate Addendum (BAA), which is available self-service in AWS Artifact. Without it you have no HIPAA coverage for any service, eligible or not. The BAA extends only to AWS's HIPAA-eligible services, so signing it and then keeping PHI on eligible services only are two halves of the same requirement.

**Q: How many AWS services are HIPAA-eligible?**

On the order of 130-plus today, and the number keeps climbing as AWS adds services to the BAA. Because it changes, the exact count is not worth memorizing — what matters is checking whether each specific service in your PHI data path is currently eligible. Treat the count as directional and the per-service check as the real work; verify current eligibility on the AWS HIPAA-eligible-services page.

Template: "HIPAA-eligibility service map" — branded PDF at https://kaansystems.com/templates/hipaa-eligible-aws-services.pdf

Source: https://kaansystems.com/library/hipaa-eligible-aws-services · Work with Kaan Systems: https://kaansystems.com/contact