Skip to content

AWS 2026-10-12 Tier 1

Read original ↗

Agentic antimicrobial resistance surveillance with AWS HealthOmics and Amazon Bedrock AgentCore

Summary

An AWS Architecture Blog reference architecture (demonstration, not a clinical system) that turns a public bacterial-genome accession into a plain-language answer about antimicrobial-resistance (AMR) genes without the user writing bioinformatics code or SQL. A researcher submits an NCBI Sequence Read Archive (SRA) accession through a web app; a managed pipeline ingests the reads from the Registry of Open Data on AWS, assembles the genome and screens it for resistance genes on AWS HealthOmics, harmonizes and stores results idempotently as Apache Iceberg tables on Amazon S3 Tables, and exposes a Strands agent on Amazon Bedrock AgentCore that turns questions like "What AMR genes were found in Salmonella?" into Athena queries, grounded with Bedrock Guardrails. The whole stack is one AWS CDK app with no hardcoded identifiers. The post reuses the S3-Tables-plus-agentic-SQL querying pattern from an earlier variant-interpretation solution; what is new here is that the problem starts a step earlier — at raw sequencing reads — and so depends on public-data ingestion with deduplication, assembly-based detection on a managed workflow, and idempotent Iceberg storage.

Key takeaways

  1. Five loosely-coupled, one-directional stages. Ingestion → genomics processing → harmonization/storage → analytical store → conversational agent. Data flows one way; each stage hands off through object storage or a managed table, not a synchronous call. (Source: this article.)
  2. Ingestion deduplicates against a DynamoDB ledger. An EventBridge Scheduler rule (or an on-demand REST call) starts an Step Functions workflow; an ECS/Fargate task fetches and converts the run from the public SRA mirror, and a DynamoDB table records every processed isolate so a scheduled weekly run or a repeated manual submission skips work already done. Fargate is chosen specifically because fetch+convert of a large run runs well beyond a few minutes — a long-running task, not a Lambda. (Source: this article.)
  3. Anonymous S3 read is enough for ingestion. Because the SRA mirror is part of the Registry of Open Data on AWS, the ingest task reads it with an anonymous S3 GET — no credentials, no manual download. (Source: this article.)
  4. Genomics is one managed Nextflow run, not a cluster. AWS HealthOmics runs a single Nextflow workflow of three channel-connected tasks — fastp (read QC/trim) → SKESA (de novo assembly) → AMRFinderPlus (resistance-gene detection) — with nothing to provision or scale. Combining assembly and screening in one run avoids a fragile handoff between two separate runs and matches how community AMR pipelines are structured. (Source: this article.)
  5. HealthOmics tasks run without internet access — three concrete adaptations follow: the AMRFinderPlus reference database is baked into the container image (not downloaded at runtime); container image URIs are passed as workflow parameters (not hardcoded) so the workflow is account/Region independent and HealthOmics can verify image access before a run starts; and outputs are published to the run output path HealthOmics exports to S3. Images are built from pinned tool releases and scanned with ECR image scanning — no floating latest tag. (Source: this article.)
  6. Idempotent Iceberg MERGE is the storage contract. A Lambda normalizes AMRFinderPlus's per-isolate TSV into the community hAMRonization schema (a PHA4GE standard); an AWS Glue job then does a MERGE keyed on (isolate, gene) into two Iceberg tables on S3 Tables — amr_profiles (one row per detected gene) and isolate_metadata (one row per isolate, carrying provenance + license). Reprocessing the same isolate updates rows in place instead of appending duplicates, keeping the tables consistent without a separate deduplication step — the idempotency property that matters for surveillance, where the same accession arrives again on a schedule. (Source: this article.) See concepts/idempotent-operations.
  7. S3 Tables registers schema in the Glue Data Catalog, so Athena reads the same Iceberg tables with no extra setup — a columnar, transactional, low-latency SQL surface over the harmonized corpus. (Source: this article.)
  8. The agent reasons over four narrow Athena-backed tools, each turning a natural-language request into a targeted query: query_amr_profiles (genes for an organism over an optional date range), get_resistance_trends (month-over-month trend), compare_isolates, and lookup_gene_info. A follow-up like "Tell me more about mdsB" fires lookup_gene_info without the user thinking about tables. (Source: this article.) See concepts/text-to-sql.
  9. Grounding is enforced in two places. The system prompt requires the agent to cite the gene ID, the detecting tool, and a confidence value for every claim, and to say plainly when no data supports an answer rather than guess; Bedrock Guardrails add a contextual grounding check plus denied topics that keep responses tied to the returned rows and off medical/patient advice. The reasoning model is Anthropic Claude Opus 4.7 on Bedrock, invoked through a cross-Region inference profile. (Source: this article.)
  10. AgentCore Runtime gives each user session an isolated environment, integrates with IAM, and traces the agent's reasoning and tool calls — the team runs the agent without managing servers or scaling logic. (Source: this article.)
  11. Front door is a standard protected SPA. React single-page app on S3 + CloudFront, protected by AWS WAF and authenticated with Cognito; API Gateway serves REST and streams the chat over WebSocket. (Source: this article.)

Systems

Concepts / patterns

  • concepts/idempotent-operations — the load-bearing storage contract: Glue MERGE keyed on (isolate, gene) makes reprocessing an accession a row-update, not a duplicate-append; dedup without a separate dedup pass.
  • concepts/text-to-sql — agentic natural-language → Athena query over four narrow tool contracts; reuse of the S3-Tables + agent-SQL querying pattern from the prior variant-interpretation solution.
  • concepts/retrieval-augmented-generation — the agent is grounded strictly in rows returned from Iceberg; two-layer grounding (system-prompt citation requirement + Guardrails contextual grounding check) guards against hallucination.
  • Prose-only (single source, taxonomy gate): public-data ingestion with a processed-isolate ledger, assembly-then-screening in one managed run, database-baked-into-container for no-internet tasks, image-URI-as-workflow-parameter. These are implementation choices, recorded here and as tags, not minted as pattern pages.

Caveats

  • Demonstration architecture, not a clinical/production system and not a customer deployment — the stated "proof" is that anyone can cdk deploy it.
  • No operational numbers — no throughput, latency, per-isolate cost, or accuracy figures. Running cost is "depends on how many isolates you process and how often"; HealthOmics runs, Glue jobs, and agent calls are billed per use; the architecture "stays inexpensive when idle."
  • Model availability varies by Region; Claude Opus 4.7 is reached via a cross-Region inference profile.
  • Reuses an earlier AWS post's querying pattern (variant interpretation); this article's novelty is confined to ingestion, assembly-based detection, and idempotent storage.

Source

Last updated · 854 distilled / 2,448 read