Is AWS Lambda HIPAA Compliant? The BAA, the Traps, and 7 Settings (2026)
Last updated: September 7, 2026
AWS Lambda is HIPAA eligible, not HIPAA compliant on its own. AWS covers Lambda under its Business Associate Addendum (BAA). A function becomes part of a compliant system only after you accept that BAA, keep every service in the event chain eligible, secure secrets, keep PHI out of logs, lock the invocation path, and turn on the right audit trail. So the short answer to "is AWS Lambda HIPAA compliant" is: it can be, and serverless has two traps that servers do not. This guide names seven settings, maps each to the HIPAA Security Rule section it satisfies, and shows the two places where careful teams still leak PHI. Every AWS fact was checked against AWS's own documentation on September 7, 2026.
TL;DR: Quick answer
AWS Lambda is on the AWS HIPAA Eligible Services Reference, updated September 3, 2026. So are the usual serverless neighbors: API Gateway, SQS, SNS, EventBridge, Step Functions, DynamoDB, Secrets Manager, CloudWatch Logs, and CloudTrail.
Eligible means the AWS BAA covers the service once you accept it in AWS Artifact. It does not mean your function is compliant. AWS states there is no HIPAA certification for a cloud provider.
Trap one: CloudWatch Logs keeps log data indefinitely by default. One print statement with a patient name becomes a permanent PHI store.
Trap two: a Lambda function URL with auth type NONE lets any unauthenticated user with the URL invoke the function.
CloudTrail records Lambda management events by default. Function invocations are data events you must turn on, and the free Event history only covers 90 days.
What does "HIPAA eligible" mean for AWS Lambda?

HIPAA regulates Covered Entities and their Business Associates, defined at 45 CFR § 160.103. When your function processes electronic protected health information (ePHI), the cloud that runs it is a Business Associate. Under 45 CFR § 164.308(b), you may not hand ePHI to a Business Associate without a signed agreement. AWS meets this with its Business Associate Addendum, which you accept for the account in AWS Artifact. The BAA covers only the services on the HIPAA Eligible Services Reference. Lambda is on that list. AWS also notes that, unless a feature is specifically excluded, the generally available features of a listed service are eligible too. What the contract must contain is in our HIPAA business associate agreement guide.
That is the whole meaning of eligible. AWS built the service so it can process PHI and will stand behind it in the contract. Everything inside your function, and everything your function talks to, is still yours under the shared responsibility model. AWS's own compliance page for Lambda says your compliance responsibility is set by the sensitivity of your data and the laws that apply to you. That is why calling AWS Lambda HIPAA compliant, full stop, is a category error. The platform is eligible. Your configured function is what gets judged. The wider verdict is in is AWS HIPAA compliant. This article zooms in on serverless.
Why serverless is different: the function is never alone

A server holds PHI in one place. A Lambda function passes PHI through a chain. An API Gateway request comes in. The function reads a secret, writes to DynamoDB or RDS, drops a message on SQS, emits a log line, and returns. Every link in that chain is a separate AWS service with its own BAA status and its own settings. One non-eligible service in the chain, or one default left in place, and the whole path fails. That is why an AWS Lambda HIPAA compliant design is really a chain review, not a function review. Here is how the common links stand on the September 3, 2026 list.
Service in the chain | On the Sept 3, 2026 list | What you still set |
|---|---|---|
AWS Lambda | Yes | The seven settings below |
Amazon API Gateway | Yes | Authorizer on every route; no PHI in access logs |
Amazon SQS, SNS, EventBridge | Yes | Encryption on queues and topics; no PHI in subject lines or event names |
AWS Step Functions | Yes | Execution history holds state input; treat it as PHI |
Amazon DynamoDB, Amazon RDS | Yes | Encryption at rest, private networking, scoped users |
AWS Secrets Manager | Yes | Store credentials here, not in environment variables |
Amazon CloudWatch Logs, AWS CloudTrail | Yes | Retention set on purpose; no PHI in log lines |
Amazon CloudFront | Yes, with an exclusion | Delivery through CloudFront Embedded Points of Presence is excluded; read the entry before edge code touches PHI |
Both halves of an AWS Lambda HIPAA compliant review start with this list. The list changes often. Our full read of it, with the footnote rules, is in AWS HIPAA eligible services. The database half of the chain has its own guide: is Amazon RDS HIPAA compliant.
The seven settings that make AWS Lambda HIPAA compliant

Each setting maps to a Security Rule citation. Together they are the AWS Lambda HIPAA compliant checklist. Do all seven and the serverless tier is in shape. Skip one and you have eligible parts that still fail an audit.
Setting | Security Rule section | Lambda control | Default you must change |
|---|---|---|---|
1. Accept the BAA | § 164.308(b) | AWS Artifact, account level | Not accepted until you do it |
2. Eligible services only | § 164.308(b) | Every trigger, target, and log sink on the list | Nothing stops you wiring a non-eligible service |
3. Secrets, not variables | § 164.312(a)(2)(iv), (a)(1) | Secrets Manager; customer managed key on env vars if you keep any | Env vars use the AWS managed key and are readable by anyone with kms:Decrypt |
4. Keep PHI out of logs | § 164.312(b), § 164.312(a)(1) | Structured logging without identifiers; retention set per log group | CloudWatch Logs retention is Never Expire |
5. Lock the invocation path | § 164.312(a)(1), (d) | Function URL auth type AWS_IAM, or API Gateway with an authorizer | Auth type NONE is public |
6. Least privilege and private network | § 164.312(a)(2)(i), (e)(1) | One execution role per function; attach to private subnets to reach RDS | Functions have public internet access by default |
7. A real audit trail | § 164.312(b), § 164.316(b)(2)(i) | CloudTrail trail to S3; Invoke data events enabled | Data events off; Event history stops at 90 days |
1. Accept the BAA before any PHI moves

Sign in to AWS Artifact and accept the Business Associate Addendum for the account. Do this first. It is step one of every AWS Lambda HIPAA compliant deployment. A perfectly built function with no BAA is still a violation of § 164.308(b). Keep the acceptance record with your compliance documents, which § 164.316(b)(2)(i) says you retain for six years.
2. Every service in the chain must be eligible
Walk the path PHI takes: trigger, function, secrets, data store, queue, log sink, and anything that runs at the edge. Each one must be on the AWS list. The table above covers the common links. Two spots deserve a second look. CloudFront is listed with an exclusion for its Embedded Points of Presence, so read that entry before any edge code handles PHI. And a third-party layer or extension is code from someone who has no BAA with you; know what it does with the data it can see.
3. Secrets go in Secrets Manager, and PHI never goes in environment variables

Lambda always encrypts environment variables at rest with an AWS KMS key. The default is an AWS managed key, and you can switch to a customer managed key so only people with access to that key can view them. Two facts matter more than the encryption. First, AWS's own guidance is to store database credentials in AWS Secrets Manager rather than environment variables. Second, anyone with kms:Decrypt on the key can read the variables in the console. So treat environment variables as configuration, never as a place for PHI or long-lived credentials. This is the AWS Lambda HIPAA compliant setting that most teams get half right. They encrypt the variables. Then they paste a connection string with a password into them anyway. Key handling in general is covered in our glossary entry on key management.
4. Trap one: PHI in CloudWatch Logs
Every Lambda function writes to CloudWatch Logs, and CloudWatch Logs stores log data indefinitely by default. The retention column reads Never Expire until you change it. That combination is the most common serverless PHI leak we see. A developer logs the whole event payload to debug a failure. The payload holds a name, a date of birth, and a diagnosis. That log line now lives forever in a log group nobody inventoried in the risk analysis. The fix is procedural and technical. Log hygiene is the AWS Lambda HIPAA compliant control that no console setting can do for you. Log identifiers such as request IDs, never patient fields. Set a retention period on every log group that a PHI function writes to. Keep a separate, longer retention for the audit records that § 164.312(b) needs, because audit logs and application debug logs are different things. CloudWatch Logs encrypts data at rest by default and accepts a customer managed key, which protects the storage but does not undo a leak. Our audit logging glossary entry draws the line between the two kinds of logs.
5. Trap two: a public function URL
A Lambda function URL is a built-in HTTPS endpoint. It has two auth types. AWS_IAM makes Lambda authenticate every request against IAM. NONE means Lambda performs no authentication, and once the resource policy grants public access, any unauthenticated user with the URL can invoke the function. A NONE URL on a function that returns or accepts PHI is an open door with a long random address, which is not access control under § 164.312(a)(1). Use AWS_IAM, or front the function with API Gateway and an authorizer. Add a deny policy so nobody can create a NONE URL by accident; AWS supports a condition key for exactly that. A locked invocation path is the cheapest AWS Lambda HIPAA compliant control on this list.
6. One role per function, and a private network when the data is private
Unique user identification at § 164.312(a)(2)(i) applies to service identities too. Give each function its own execution role with only the actions it needs. Do not share one broad role across a whole application. On networking, AWS is explicit: by default, Lambda functions have access to the public internet. When your function needs a database in a VPC, such as Amazon RDS, attach the function to that VPC's private subnets. Once attached, it can only reach resources in that VPC unless you add a NAT path on purpose. That is the right shape for a function that touches PHI. Lambda's API endpoints only accept HTTPS, with TLS 1.2 required and 1.3 recommended, which covers § 164.312(e)(1) for the control plane. Your function's own outbound calls still need TLS enforced in code.
7. A real audit trail, not the 90-day window
Audit controls at § 164.312(b) are required. CloudTrail records Lambda management events by default: who created a function, changed its configuration, or added a permission. It does not record invocations by default. Those are data events for the Lambda function resource type, and you turn them on separately, at extra cost. The free Event history also only shows 90 days. Create a trail that delivers to an S3 bucket, enable Invoke data events for PHI functions, and keep the bucket for the six years § 164.316(b)(2)(i) expects. Evidence is what separates an AWS Lambda HIPAA compliant claim from a real one. Two details help here. CloudTrail omits the Environment parameter from CreateFunction and UpdateFunctionConfiguration records, so secrets do not land in the trail. And if you use a customer managed key, CloudTrail shows every Decrypt call Lambda makes with it.
What Lambda does not do for you

The BAA and the seven settings cover the serverless tier. Four things stay on your side, however AWS Lambda HIPAA compliant the function looks on paper.
The risk analysis. 45 CFR § 164.308(a)(1)(ii)(A) requires a documented assessment of risks to ePHI. Every log group, queue, and function URL belongs in it. Our HIPAA risk analysis guide lists what OCR looks for.
Test events and sample payloads. The console stores saved test events. If a developer pasted a real patient record in to reproduce a bug, that record is now stored configuration. Use synthetic data.
Temporary files. Anything your code writes to the function's temporary storage during a run is PHI you are responsible for. Clear it before the handler returns, and never assume the next invocation starts clean.
Certification claims. AWS states there is no HIPAA certification for a cloud service provider. A vendor calling its serverless stack "HIPAA certified" is using words the law does not contain.
If you build software on this stack, the full set of downstream duties is in HIPAA compliant hosting for healthcare SaaS. The rules for the whole environment are in our guide to HIPAA compliant cloud hosting.
If your product is not really serverless

Many healthcare teams reach for Lambda to avoid running servers. Then they end up with a web app, a database, and a handful of functions glued around them. If that is you, the honest read is simple. The functions are the small part. The always-on pieces are where the compliance work lives. Our managed HIPAA cloud hosting runs single-tenant environments on these same eligible services, with the database and application tiers hardened and logged the way this article describes. The BAA is signed within 24 hours. Managed plans start from $249 per month with migration included. We sell this, so weigh that as a disclosure. The honest inverse: if your product is serverless end to end and an engineer owns the seven settings above, you do not need us. A managed server host is the wrong shape for you, and we will say so. Either way, the HIPAA compliant hosting plans are public, and you can tell us what you are building for a straight answer.
Frequently asked questions
Is AWS Lambda HIPAA compliant?
AWS Lambda is HIPAA eligible, not HIPAA compliant by itself. AWS covers it under the BAA you accept in AWS Artifact. Your functions become part of a compliant system after seven settings. Keep every service in the chain eligible, secure secrets, keep PHI out of logs, lock the invocation path, scope roles, and enable a full audit trail.
Can Lambda functions process PHI?
Yes, once the AWS BAA is accepted and the function only touches other HIPAA eligible services. Lambda, API Gateway, SQS, SNS, EventBridge, Step Functions, DynamoDB, Secrets Manager, CloudWatch Logs, and CloudTrail all appear on the AWS list dated September 3, 2026.
Are Lambda environment variables HIPAA compliant?
They are encrypted at rest with an AWS KMS key by default, and you can use a customer managed key. They are still readable in the console by anyone with decrypt permission. Keep PHI out of them, and store credentials in AWS Secrets Manager, which is what AWS itself recommends.
Is CloudWatch Logs a HIPAA problem for Lambda?
Only if PHI lands in it. CloudWatch Logs is HIPAA eligible and encrypts data by default, but it retains log data indefinitely until you set a retention period. Log request IDs instead of patient fields, and set retention on every log group a PHI function writes to.
Is AWS Lambda HIPAA certified?
No, and nothing is. AWS states there is no HIPAA certification for a cloud service provider, and HHS certifies no product. AWS shows its controls through SOC, PCI, and FedRAMP audits available in AWS Artifact. Compliance is a state you maintain, not a badge.
Recap: AWS Lambda HIPAA compliant
To recap, is AWS Lambda HIPAA compliant? It is HIPAA eligible on the September 3, 2026 AWS list, along with the services a serverless app usually chains together. It becomes compliant when you do seven things. Accept the BAA in AWS Artifact. Keep every link in the chain eligible. Put secrets in Secrets Manager and PHI nowhere near environment variables. Keep PHI out of CloudWatch Logs and set retention on purpose. Never leave a function URL on auth type NONE. Give each function its own least-privilege role and a private network path to the data. Turn on CloudTrail Invoke data events and keep the trail for six years. Do the seven, keep the evidence, and the serverless tier is ready for the rest of your risk analysis.
This article is general information, not legal advice. AWS facts reflect the AWS HIPAA Eligible Services Reference dated September 3, 2026 and the AWS Lambda, CloudWatch Logs, and CloudTrail documentation as read on September 7, 2026. AWS changes all of these, so confirm current details with AWS before relying on them. Regulatory citations reflect the HIPAA Security Rule at 45 CFR Part 164; the proposed Security Rule update is not final. Base your safeguards on a documented risk analysis and confirm obligations with qualified counsel. We sell HIPAA compliant hosting and compliance reviews. Reviewed September 2026.
Sources
AWS: HIPAA Eligible Services Reference (updated September 3, 2026)
AWS: Data protection in AWS Lambda and Data encryption at rest for AWS Lambda
AWS: Giving Lambda functions access to resources in an Amazon VPC
AWS: Working with log groups and log streams (retention)
45 CFR § 164.308 (administrative safeguards, BAA requirement): ecfr.gov
45 CFR § 164.312 (technical safeguards): ecfr.gov