Skip to content

SYSTEM Cited by 1 source

AWS HealthOmics

What it is

AWS HealthOmics is a managed AWS service for running genomics and other life-sciences workflows at scale without a cluster to provision or scale. It executes containerized bioinformatics pipelines (e.g. Nextflow workflows) as managed runs, handling compute provisioning, scheduling, and output export to Amazon S3 on the user's behalf — aimed at teams that do not run a bioinformatics system of their own. (Source: sources/2026-10-12-aws-agentic-antimicrobial-resistance-surveillance-with-aws-healthomics-and-amazon-bedrock-agentcore)

Workflow execution model

In the AMR-surveillance reference architecture, HealthOmics runs a single Nextflow workflow of three tasks connected by Nextflow channels:

  1. fastp — trims adapters and low-quality bases from the raw reads.
  2. SKESA — de novo assembly of the trimmed reads into contigs.
  3. AMRFinderPlus — screens the contigs for known resistance genes.

Chaining assembly and screening in one run (rather than two separate runs) avoids a fragile cross-run handoff and matches how community AMR pipelines are structured.

Running third-party tools on HealthOmics — the no-internet contract

HealthOmics tasks have no internet access, which forces three adaptations that generalize to any third-party bioinformatics tool run on the service:

  • Bake reference data into the image. The AMRFinderPlus reference database is built into the container image rather than downloaded at runtime.
  • Pass container image URIs as workflow parameters (not hardcoded). This keeps the workflow independent of account and AWS Region and lets HealthOmics verify image access before a run starts.
  • Publish outputs to the run output path that HealthOmics exports to Amazon S3, rather than to arbitrary locations.

Images are built from official tool releases with pinned versions and scanned with Amazon ECR image scanning, so the pipeline never depends on a floating latest tag.

Where it sits in the pipeline

Upstream, an Step Functions workflow and an ECS/Fargate task fetch and convert public reads before handing off to HealthOmics. Downstream, a Lambda normalizes detection output into the hAMRonization schema and an AWS Glue job MERGEs it idempotently into Iceberg tables on S3 Tables, queried through Athena. HealthOmics is the compute-heavy middle: "turning reads into a list of resistance genes."

The AMR post reuses the S3-Tables-plus-agentic-SQL querying pattern from an earlier AWS variant-interpretation solution (Accelerating genomics variant interpretation with AWS HealthOmics and Amazon Bedrock AgentCore). The variant solution starts from an already-called VCF; this AMR solution starts a step earlier, from raw sequencing reads, adding read QC, de novo assembly, and gene detection before results exist to store. Both use HealthOmics as the managed genomics-processing stage.

Caveats

  • Disclosure to date is from a single demonstration reference architecture — no published internal design (scheduler, isolation model, run concurrency), throughput/latency, or per-run cost. Runs are billed per use; the architecture "stays inexpensive when idle."
  • The no-internet task constraint is load-bearing: any tool needing a reference database must ship it inside the image.

Seen in

Last updated · 854 distilled / 2,448 read