apointoo.
Request access
HIPAA

How to Verify AWS HIPAA-Eligible Services Before Deployment

cmsapointoo··8 min read

Short answer: Verify an AWS HIPAA workload by tracing every service, region, identity, key, log, backup, and application control through current AWS documentation and the applicable agreement. AWS’s HIPAA eligible-services reference is a service-scope input, not deployment approval. As of August 15, 2026, use AWS Artifact for agreement evidence, keep proposed or volatile facts dated, and prove the design with synthetic data before production.

AWS service fit and regional boundary

AWS publishes a current HIPAA eligible-services reference. Use it to confirm whether each planned AWS service is in the provider’s eligible scope, then verify the region, feature, account, and configuration. A service can appear on the list while the deployed design still fails because an unlisted service, region, support tool, log, or backup receives data.

Use AWS Artifact to locate and retain current agreements and compliance documents for the organization or account path. Confirm the effective BAA before the first production write. Do not treat an Artifact document, service list, region, or encryption setting as a compliance certification. The application and customer controls remain.

Record the eligibility and region review as of August 15, 2026. Service lists, regional behavior, feature limits, pricing, and API semantics can change. Any cost number in a decision memo should be labelled as an estimate and recalculated before deployment.

Request, data, key, and identity path

client request
    |
    v
regional API -> authenticated service role -> data store
    |                    |                  |
    v                    v                  v
 audit event        key policy          backup path
    |
    v
incident and review queue

optional outbound path:
generic event -> approved queue -> tenant legal gate -> destination

For each arrow, record service name, region, account, data category, identity, key, log, backup, and owner. Browser-provided tenant or region values must not authorize access. Resolve membership and home region server-side. Use least privilege and MFA for workforce and service identities. Keep credentials out of client code and logs.

Path Verification Evidence
Request API authentication, validation, rate and error behavior Test, policy, log sample.
Data Store, query, tenant key, retention, export Schema, negative tests, deletion record.
Key Creation, use, rotation, recovery, revocation Key policy and access test.
Identity Role, permission, MFA, termination IAM review and denied-action test.
Backup Region, encryption, restore, lifecycle Restore exercise and evidence.

For Google Ads, use only generic conversion data after tenant-specific legal approval. Never send patient name, email, phone, hashed identifiers, service or treatment details, or clinical text. A click signal related to an appointment still requires review. Keep the outbound worker off by default and put any approved payload behind a server-side gate.

Use the subprocessor inventory, the shared-responsibility map, and the Lambda boundary guide for related AWS decisions.

Queue, audit, backup, and failure handling

Design failure paths before production. If a worker cannot send an approved event, queue it with an opaque reference and retry safely. If a destination rejects it, do not log the full payload. If a backup restore is needed, restore into an approved region and role boundary. If an identity is revoked, every path must reject it.

  • Use structured audit events with actor, action, tenant, object class, result, timestamp, and request reference, without sensitive content.
  • Review CloudTrail or other audit evidence for administrative actions and retain it under the risk and contract schedule.
  • Use encrypted backups with known retention, restore owner, and deletion verification.
  • Test dead-letter, retry, idempotency, timeout, and permission failures.
  • Document which service handles each failure and who receives the incident.

Eligible-service status does not supply tenant isolation. If DynamoDB is selected, design partition keys and authorization checks around each access pattern; do not imply that it provides database-enforced row-level security. If a relational control is required, prove it with the chosen database and application path.

Cost and proof gate

Estimate AWS cost after the architecture is known. Separate request and execution charges from always-on services, storage, backups, logs, keys, network, support, and compliance work. Label all numbers as planning estimates with region, workload, and retrieval date. A low request estimate does not mean a low production or evidence burden.

Gate Pass condition Stop condition
Eligibility Every service and feature is in the current reference. Unlisted tool receives production data.
Agreement Current BAA is retained through AWS Artifact. Agreement is assumed or unsigned.
Region Data, keys, logs, backups, and support are mapped. Region is inferred from compute alone.
Proof Access, failure, restore, audit, and exit tests pass. Only a diagram or service list exists.

Escalate when a service is borderline, a region is unavailable, a contract requires dedicated isolation, a support path is unclear, or an outbound payload is not approved. Keep production data out of the design until the issue is closed.

Cost and proof gate

  1. Inventory services, features, regions, identities, keys, logs, backups, support, and subprocessors.
  2. Check each against the current AWS eligible-services reference.
  3. Accept and retain the applicable agreement in AWS Artifact.
  4. Test tenant authorization, IAM denial, key use, logging, queue failure, backup restore, and exit.
  5. Recalculate dated cost estimates.
  6. Obtain counsel, security, procurement, and tenant approval before production.

The approval gate passes when service eligibility, contract, region, customer controls, and proof all agree. If one is missing, do not make an eligible-service list the basis for a compliance claim.

Check every service that appears indirectly

An AWS architecture can include services that are not obvious from the main diagram. Build systems, artifact storage, notification services, monitoring, secrets, keys, support tools, analytics, queues, backups, and disaster-recovery copies can all create a data path. Add each to the eligible-services check. If a service is used only for metadata, confirm what metadata it receives and whether the contract and region still fit.

Feature-level eligibility matters too. A service list does not answer whether a preview feature, export, integration, or regional variant is covered. Record the exact API, tier, feature, account, region, and configuration. Reopen the row when an SDK, managed integration, or provider default changes.

Use IAM and key evidence as first-class gates

Review IAM roles, trust policies, resource policies, condition keys, service-to-service paths, and administrative identities. Test a denied action for each important role. A service can be eligible while an overly broad policy lets one tenant access another. Keep browser input out of authorization decisions and resolve tenant membership on the server.

Map key creation, use, rotation, recovery, disablement, and deletion. Test that logs do not reveal credentials or sensitive payloads. Restore backups into an approved region and confirm that key and identity permissions remain narrow. Retain AWS Artifact agreement evidence separately from application test evidence.

Make queues and failures safe

An outbox or queue can improve reliability while creating a copy of the payload. Use opaque references, idempotency keys, retry limits, dead-letter handling, and restricted readers. Inspect failure logs and messages. Do not place patient names, email, phone, hashed identifiers, service or treatment details, or clinical text in a Google Ads event or queue. Generic conversion data requires tenant-specific legal approval and a disabled default.

Revisit costs as estimates

Separate request cost from fixed resources, database capacity, backups, logs, keys, network, support, and engineering time. Label each estimate with region, volume, assumptions, and retrieval date. A free tier or low request price is not a production quote. Recalculate after the synthetic proof identifies real read, write, log, backup, and restore behavior.

Retain the eligibility check, Artifact agreement, architecture map, and test results together. Reopen the checklist when a service, region, feature, or backup path changes.

FAQ

What is the first verification step for AWS HIPAA eligible services?

List exact services, features, regions, and data paths, then compare every one with the current AWS eligible-services reference.

Which source or configuration detail could change the answer?

Eligibility list, region, feature, API behavior, BAA status, IAM policy, backup, key, logging, or support configuration can change the review.

Does an AWS eligible-service list approve a deployment?

No. It is a provider scope reference. Customer architecture, authorization, configuration, risk analysis, and operations still require proof.

What must be approved before a production claim or outbound action?

Approve the service list, BAA, region, IAM, keys, logs, backups, application controls, and exact payload. For Google Ads, require tenant-specific legal approval and keep the event off.

References

Related articles