what are the limits for rate of ingestion into AWS healthlake ?

Great question. This is an area that often trips up even experienced implementers when scaling FHIR ingestion pipelines into Amazon HealthLake. You’re right that the documentation provides baseline quota details, but interpreting those in the context of FHIR bundle transactions, especially when streaming data or doing large-scale batch writes, requires some nuance.

Let’s break this down carefully.

1. Write Quota Context (Per Data Store) The 3,000 writes per second per data store limit in HealthLake refers to individual FHIR resource write operations, not to HTTP request calls directly. This means that when you use a FHIR Bundle with a transaction or batch type, each entry in that bundle is treated as a discrete write within that quota.

For example:

If you submit a single transaction bundle containing 100 FHIR resources (such as 100 Observations or Encounters), that call counts as 100 writes against your 3,000 write-per-second limit.

If you send 30 such bundles per second, you’ll reach the service limit (30 bundles × 100 resources = 3,000 writes).

2. Bundle Payload Size and API Constraints Each API call, whether it’s a transaction or batch bundle, is subject to the general payload size limit of 15 MB. This applies to the serialized JSON body of the request.

A few additional nuances to consider:

FHIR validation adds latency and computational cost, so while HealthLake can technically handle 3,000 writes per second, real-world performance depends on the size and complexity of the FHIR resources (number of attributes, nesting depth, and so on).

The bundle type matters:

transaction bundles are processed atomically, meaning all entries succeed or fail together, which makes them slightly more expensive computationally.

batch bundles process entries independently, which can make them more efficient for high-throughput ingestion.

3. Recommended Patterns for Streaming Ingestion If you’re implementing near-real-time ingestion, it’s usually best to use an event-driven pattern rather than direct FHIR endpoint posting. One effective approach is:

Stream HL7v2 or FHIR events through Amazon Kinesis Data Streams or Amazon SQS.

Use AWS Lambda or AWS Glue to batch and transform incoming data into appropriately sized FHIR bundles (keeping each under 15 MB).

Post those bundles to HealthLake at a controlled rate using exponential backoff and retry strategies to stay within quota.

For large-scale ingestion, you might also consider parallelizing across multiple data stores when your architecture allows for logical data segmentation, such as separating by region or data domain.

4. Monitoring and Scaling Guidance You can track throughput and latency using Amazon CloudWatch metrics for HealthLake’s WriteResource API, combined with Lambda or API Gateway logs for your ingestion pipeline. If you consistently approach the upper limit, AWS recommends opening a service quota increase request through the AWS Support Center. These requests are evaluated based on your workload characteristics and account history.

5. Key References:

HealthLake Service Quotas : https://docs.aws.amazon.com/healthlake/latest/devguide/reference-healthlake-endpoints-quotas.html

FHIR Bundles and Batch/Transaction Operations : https://www.hl7.org/fhir/bundle.html

Best Practices for Scaling Data Ingestion on AWS : https://docs.aws.amazon.com/whitepapers/latest/building-scalable-applications-on-aws/building-scalable-applications-on-aws.html

In summary: Think of the 3,000 writes per second limit as your resource operation budget, not just API calls. Keep payloads under 15 MB, batch logically to balance throughput and atomicity, and use CloudWatch to continuously observe ingestion metrics. With a well-tuned pipeline and bundle management, you can achieve very high sustained ingestion rates into HealthLake while maintaining both compliance and performance.