AWS Public Sector Blog

SaaS design levers for sovereignty on AWS

Mehmet Bakkaloglu — Thu, 06 Aug 2026 17:00:22 +0000

According to an IDC market forecast, global spending on sovereignty is increasing at 27% and is set to reach $409 billion by 2029. For software as a service (SaaS) providers, sovereignty is becoming a prerequisite for selling into public sector and regulated industries such as healthcare and finance.

The challenge for SaaS providers is how to maintain the pooled-resource economics, multi-tenant architecture, operational simplicity, and rapid innovation velocity of a true SaaS model while giving each tenant the sovereignty assurances regulators demand.

The answer lies in design levers, which are architectural settings SaaS builders can adjust independently to deliver individual customer sovereignty requirements without regressing to a fully siloed, single-tenant world. In this post, we explore practical design patterns for SaaS offerings on Amazon Web Services (AWS) and show how sovereignty can be a tunable design dimension rather than an all-or-nothing rebuild.

How sovereignty applies to SaaS

Digital sovereignty lacks a single global definition, but through deep engagement with customers, partners, and regulators, AWS has distilled it into a set of consistent, actionable themes.

Here’s how these themes apply to SaaS:

Data sovereignty – Covers data residency, meaning tenant data must be stored and processed within defined geographic or legal boundaries. This might include metadata. It also covers operator access restriction, which is where SaaS providers must demonstrate verifiable access controls, giving tenants confidence that even the operator can’t access their data.
Operational sovereignty – Covers resiliency and survivability, meaning SaaS control and application planes must be resilient and independently operable per geographic region despite geopolitical disruption, natural disasters, or technical failure. It also covers independence and transparency, where providers might need in-jurisdiction personnel and transparency about the software supply chain.
AI sovereignty – Control over models, inputs, outputs, training data, and inference pipelines. AI-powered SaaS features must respect data boundaries through the full AI lifecycle.

Not all workloads require all these measures. For example, data residency requirements most commonly apply to only customer data, but in some cases might also apply to metadata. Hence design levers that can be adjusted independently.

The six design levers

Based on the SaaS implications of sovereignty, the six key design levers are as follows:

Deployment topology – Where you deploy the control and application planes
Tenant isolation – How you separate the tenants
Encryption key management – Where you store the keys and who manages them
Operator access – Who can access the system and where they are located
Resilience – The ability to recover from infrastructure or service disruptions
AI sovereignty – Control and choice across the AI stack

Figure 1: The six design levers

Deployment topology

The deployment topology is the most visible lever. SaaS providers must separate the control plane—tenant management, billing, onboarding—from the application plane where tenant workloads and data actually reside. The control plane is typically global for centralization and ease of management, but it can be regional or in-country depending on metadata residency requirements. This separation allows the application plane to follow the tenant’s data residency requirements and confirms data processing takes place where data resides.

The application plane ranges across a spectrum:

Single-Region multi-tenant – Deploy in a single sovereign-by-design AWS Region. Most streamlined operations, but limits data residency options to a single jurisdiction.
Multi-Region multi-tenant – Deploy the application plane in each required jurisdiction across multiple Regions. Can be extended to AWS Local Zones to bring compute closer to a specific metro area within a jurisdiction.
Trusted Secure Enclaves – An AWS solution for deploying isolated, security-hardened environments within commercial Regions for sensitive workloads.
Infrastructure exclusive to a customer – For workloads that must stay in a customer-specific facility. AWS Dedicated Local Zones are AWS infrastructure in a customer-chosen location. AWS Outposts brings AWS services on premises. AWS AI Factories provides AWS AI infrastructure in the customer’s data center.
Sovereign cloud – AWS European Sovereign Cloud is an independent cloud designed to help customers meet Europe’s most demanding sovereignty needs, operated separately from global Regions.

Beyond choosing where to deploy, SaaS architects need preventive controls to make sure data doesn’t leak across boundaries. For example, AWS Control Tower data residency controls can enforce Region restrictions and prevent inadvertent cross-boundary data movement.

Tenant isolation

The second lever is how you separate the tenants. Although a shared infrastructure with logical separation typically meets the requirements of most customers, in some customer segments (for example, government or healthcare), full-stack isolation makes it straightforward to establish a hard security boundary and demonstrate compliance. In between these two options, the SaaS providers can also architect isolation at some layers such as shared web tier with siloed storage, known as the bridge model.

AWS enables the full spectrum, from fine-grained AWS Identity and Access Management (IAM) policies and Amazon Virtual Private Cloud (Amazon VPC) boundaries to the account-per-tenant model (demonstrated at scale with 6,000 accounts managed by three people). The key is matching isolation level to the tenant’s regulatory tier, not applying maximum isolation uniformly

Encryption key management

This lever gives customers confidence that their data is inaccessible without their consent. Encryption is a powerful sovereignty lever that’s often overlooked.

There are three main options for data encryption on AWS, each providing incremental control:

AWS managed keys – AWS handles everything. This is the most streamlined option with zero operational overhead. Includes server-side encryption with Amazon Simple Storage Service (Amazon S3) managed keys (SSE-S3) (fully transparent, no config) and server-side encryption with AWS Key Management Service (AWS KMS) keys (SSE-KMS) that are managed by AWS (adds audit logging). Neither the provider nor tenant controls the key.
SaaS provider-managed keys – The SaaS provider creates and controls KMS keys in their own AWS account. Can be shared across tenants or can be one key per tenant. The per-tenant approach enables crypto-shredding (deleting the key makes data unrecoverable). The tenant can’t revoke independently.
Tenant-managed keys – The tenant controls the key and can revoke the provider’s access at any time. Options range from least to most control: tenant KMS key with AWS generated key material and cross-account access, bring your own key (BYOK) where the tenant imports their own key material into AWS KMS, AWS CloudHSM with dedicated single-tenant HSMs, AWS External Key Store (XKS) where the key material doesn’t enter AWS and stays in the tenant’s own key manager, and client-side encryption where the tenant encrypts before data reaches the provider.

Beyond key ownership, there are patterns that address processing-time security. AWS Nitro Enclaves with AWS KMS attestation restrict decryption to a verified enclave so the provider can process tenant data without exposing plaintext in memory. Multi-party or split-key approaches require both provider and tenant to participate in decryption so neither party can access data unilaterally. This is typically seen in regulated financial services or dual-control scenarios.

Operator access

Sovereignty requirements can extend beyond where data is stored to those who can access it. It can also extend to how the software supply chain works. For SaaS providers, operator access can be one of the most scrutinized levers by regulators and customers.

To help customers meet their requirements, SaaS providers should offer operator access models with increasing levels of access restriction:

Shared operations team – A global team manages all tenants regardless of geography, with operators located anywhere. The default for most SaaS, sufficient when tenants have no jurisdictional access constraints.
Geo-restricted operators – Only personnel physically located in-country or in-region can access sovereign environments. Common for European Union (EU) data residency, government workloads, or where data export restrictions apply to viewing data.
Security-cleared personnel – Operators hold government-issued security clearances or equivalent vetting, with access requiring both clearance and location. Used for defense, intelligence, and critical national infrastructure workloads.
Customer-managed operators – The customer provides and manages their own operations staff, and the SaaS provider relinquishes day-to-day operational access entirely. Maximum sovereignty where the customer accepts operational responsibility in exchange for full access control.

For the latter three options, SaaS providers might have to develop a handover process for software updates from global teams to respective operators.

SaaS providers should implement defense-in-depth for operator access, where each layer—AWS service control policies (SCPs), AWS resource control policies (RCPs), and Region-scoped IAM permissions—is evaluated independently, and an operator must satisfy all layers to gain access. A misconfiguration at one layer can’t bypass controls at another. By parameterizing the access model per tenant and storing the access tier as tenant metadata, a single SaaS architecture can serve tenants across the full sovereignty spectrum without requiring separate control plane deployments.

Resilience

SaaS tenants require continuity assurance: that failover and disaster recovery don’t inadvertently violate jurisdictional boundaries. A SaaS provider that replicates to an out-of-jurisdiction Region during a disruption has broken its sovereignty contract. This includes geopolitical scenarios where an entire Region might become unavailable, requiring failover to an alternative Region or service provider within the same jurisdiction.

Building on the deployment topology lever, SaaS providers must confirm both the control plane and application plane can sustain operations within sovereign boundaries:

Multi-Availability Zone within a Region – Both the control plane and application plane should be deployed across multiple Availability Zones (AZs) for high availability. Data doesn’t leave the Region boundary. This is the standard pattern and satisfies most sovereignty requirements with no additional architecture.
Multi-Region within a jurisdiction – Disaster recovery across Regions within the same sovereign boundary, for example eu-central-1 and eu-west-1 for EU sovereignty, in active-passive or active-active configurations. If the control plane is global, it must be designed so a Regional failure doesn’t prevent sovereign tenants from operating. Requires explicit routing logic to prevent failover to non-approved Regions. To learn more, refer to Architecting Multi-Region SaaS Solutions on AWS.
AWS European Sovereign Cloud – An additional in-jurisdiction Region option purpose-built for sovereignty requirements, usable as a primary deployment target or failover destination within Europe.

AI sovereignty

As SaaS products embed AI for features such as chat assistants, workflow automation, and autonomous agents, sovereignty requirements extend to the AI layer. The AWS approach to AI sovereignty identifies key controls that we recommend SaaS providers offer across the sovereignty spectrum:

Model choice and deployment location – Options range from using models through Amazon Bedrock (including open weight models) in the Region where the tenant is deployed, cross-Region inference where jurisdictional boundaries allow, self-hosting open source models on GPU instances within a specific Region, or self-trained models where the tenant controls the training data and artifacts.
Inference and data protection – Where customer data is involved, such as in prompts, fine-tuning, or training, it must be treated with the same sovereignty controls as the rest of the tenant’s data. Nitro backed instances confirm model inputs and outputs remain confidential. Amazon SageMaker AI allows fine-tuning within a single Region.
AI agent governance – As AI agents take autonomous actions on behalf of tenants, they must operate within tenant-scoped permissions. Amazon Bedrock AgentCore Identity and Amazon Bedrock AgentCore Policy provide identity propagation and policy enforcement so agents can only access resources the tenant has authorized.

Putting it together: A tiered sovereignty architecture

Not every tenant needs maximum sovereignty. Smart SaaS design offers tiered sovereignty, meaning customers can self-select the level of control they need. We recommend creating multiple tiers such as standard, enhanced, and premium that are available out-of-the-box, addressing the common sovereignty requirements of customers.

Here’s an example of how these tiers can be structured:

Standard – Aimed at startups and small and medium-sized businesses (SMBs). Single-Region deployment, multi-tenant architecture, AWS managed encryption, and global AI inference. Optimized for cost and ease of adoption.
Enhanced – Aimed at regulated industries. In-Region application plane, multi-tenant with per-tenant KMS keys, siloed storage, shared operations team, and cross-Region AI inference.
Premium – Aimed at government, defense, and critical infrastructure. AWS account per tenant, XKS or CloudHSM encryption, deployed in a Trusted Secure Enclave, AWS Dedicated Local Zones or AWS European Sovereign Cloud, with in-Region AI inference.

Figure 2: Tiered sovereignty based on workload

Additionally, we recommend further configurations that can be add-ons to these tiers. These add-ons can be enabled based on requirements not covered by the tiers. This tiered approach preserves SaaS economics for most tenants while offering premium tiers that command higher price points, turning compliance into a revenue lever.

Conclusion

Sovereignty doesn’t have to mean giving up SaaS. By treating sovereignty as a set of tunable design levers rather than a binary choice between cloud and on-premises, SaaS providers can expand into public sector and regulated industries, and build deeper customer trust while preserving the agility and scale economics that make SaaS compelling in the first place.

AWS provides a broad set of sovereignty building blocks, from Regions to AWS Dedicated Local Zones, from Nitro backed isolation to AWS External Key Store, from AWS Control Tower guardrails to the purpose-built AWS European Sovereign Cloud. The architectural patterns in this post give you a playbook to combine them into a sovereign SaaS offering that doesn’t compromise on innovation.

For additional resources, refer to Digital Sovereignty at AWS and Framework for platform expansion to Europe, Middle East and beyond.

What US federal agencies need to know about OMB memorandum M-26-14: Part 1

Vin Minichino — Thu, 06 Aug 2026 16:28:37 +0000

The US Office of Management and Budget (OMB) has issued Memorandum M-26-14, “Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats,” and, effective immediately, rescinded Memorandum M-21-31. For federal agencies and the teams who defend their networks, this is a meaningful shift. M-26-14 moves away from a single, prescriptive logging catalog toward an adaptive framework that asks agencies to employ a risk-based, prioritized logging approach. If your agency invested to meet M-21-31, that work still matters: M-26-14 is designed to build on it while giving you more flexibility. We covered the original requirements in a 2022 post, What US federal customers need to know about memorandum M-21-31.

In this post, we discuss what changed in federal logging requirements from M-21-31 to M-26-14, and how agencies can prepare ahead of the forthcoming Cybersecurity and Infrastructure Security Agency (CISA) logging reference architecture (LRA).

From M-21-31 to M-26-14: What changed

M-21-31, published in 2021, responded to the SolarWinds incident and Executive Order (EO) 14028. It defined event logging (EL) tiers and an extensive catalog of log data for agencies to capture and retain across their systems, so relevant data would be available after an incident.

M-26-14 keeps that underlying intent—visibility before, during, and after an incident—but changes how agencies get there. Rather than applying one fixed catalog uniformly, agencies now work within an adaptive, risk-based framework and organize logging based on outcomes. The memorandum directs the CISA to publish an LRA that will serve as the core source of implementation guidance, letting agencies build on their M-21-31 progress while accommodating different missions and risk profiles.

Two objectives: CEM and THIRF

M-26-14 asks agencies to prioritize two objectives:

Continuous Event Monitoring (CEM) – The logging and infrastructure that lets you monitor network activity in real time, promptly flag anomalous activity, and respond in a timely manner. A Security Operations Center (SOC) typically ingests and monitors these logs.
Threat Hunting, Investigation, Response, and Forensics (THIRF) – The capability to investigate and perform forensic analysis after a known or suspected compromise. THIRF depends on sufficient hot and cold storage, plus the ability to retrieve and centralize log data from many sources to map how an attack unfolded. This is where proactive threat hunting lives: searching for known indicators of compromise and anomalous activity, and reconstructing attacker behavior, including initial access and lateral movement.

A risk-based approach to logging

The central change is how agencies decide what to log, and how much. M-26-14 expects risk-based decisions—informed by an agency’s threat environment, risk profile, and mission—rather than one checklist applied everywhere. In practice, that means bringing the SOC, threat-hunting teams, and mission owners together to make deliberate choices. A few specifics support this approach:

Scope now explicitly includes Internet of Things (IoT) devices and operational technology (OT) that are part of an agency’s information systems.
Retention is tied to outcomes: logs must be searchable for at least 6 months (to support CEM) and retrievable for at least 12 months (to support THIRF).
Storage can be centralized or decentralized, as long as logs are readily available to the agency’s top-level SOC. Centralizing storage, forwarding logs, federating access, or a hybrid of these are all acceptable.

A maturity model to plan against

M-26-14 introduces a revised maturity model in Appendix C that agencies use to measure and report progress as the percentage of systems operating at each level. It spans five levels, from Ineffective (Level 0) to Optimal (Level 4), across five elements:

Inventory Visibility – How completely an agency’s IT, OT, and IoT assets are captured in a centralized inventory
Collection Coverage – The share of inventoried assets whose required logs are searchable and retrievable
Collection Operations – How well logs generate actionable alerts that are evaluated and tuned over time
Data Retention – How long logs remain searchable and retrievable
Log Management – How logs are stored, encrypted, and protected

One detail shapes strategy: a system’s overall maturity equals its lowest-scoring element, known as the “lowest watermark.” A single weak area sets the score, so it pays to find and close your lowest element first. Where the earlier EL tiers emphasized what you collected, this model measures how effectively you can see, retain, and act on it.

The following figure illustrates an example scoring across the five levels of the maturity model.

Figure 1: Sample self-assessment using the M-26-14 Logging Maturity Model. In this example, the agency scores unevenly across the five elements—illustrating how a single lagging area (here, Collection Operations at L1) constrains overall maturity regardless of strength elsewhere.

Where AWS fits

Because M-26-14 is technology-neutral and outcome-focused, there is no mandated product list. Amazon Web Services (AWS) supports both objectives with familiar building blocks. Services such as AWS CloudTrail, Amazon CloudWatch, and Amazon Virtual Private Cloud (Amazon VPC) Flow Logs help with the real-time visibility that CEM needs, while Amazon Simple Storage Service (Amazon S3) storage tiers and Amazon Security Lake and Unified Data Store support the retrievable, centralized-or-federated storage that THIRF depends on. If your agency is getting started on AWS or revisiting its logging strategy, the Landing Zone Accelerator on AWS (LZA) can help automate the deployment of many of these services and centralize logs in a dedicated log archive account as your environment grows.

Conclusion and next steps

The US OMB has issued Memorandum M-26-14, and, effective immediately, rescinded Memorandum M-21-31.

To prepare for this change, US Federal Agencies can review the following items:

Read M-26-14 and communicate that M-21-31 is rescinded
Begin framing logging as a risk-based decision across the five maturity elements, and identify your lowest-watermark gaps
Bring your SOC, threat-hunting, and mission teams together to weigh centralize-or-federate options
Watch for CISA’s LRA at cisa.gov/Logging

Deploy AI agents in AWS GovCloud (US) using Amazon Bedrock AgentCore

David Schatzman — Wed, 05 Aug 2026 15:22:44 +0000

The Federal Government, the Industrial Base, and SaaS technology providers are taking the next step after experimenting with generative AI in their highly regulated cloud environments and asking the question: How do we put AI agents into production at scale, compliantly, securely, reliably, and without building everything from scratch?

AI agents enable mission owners to advance beyond simple prompt-response interactions. They can now reason, plan, use tools, and take actions across systems, automating complex workflows that previously required human intervention at every step. However, deploying agents in environments with elevated compliance requirements introduces challenges that commercial tooling alone can’t solve: runtime isolation for sensitive workloads, auditable tool access, identity delegation that aligns with existing authorization models, and real-time observability for compliance and oversight. AgentCore lets you deploy AI agents that act autonomously while maintaining the same compliance posture as your most controlled systems.

Amazon Bedrock AgentCore is currently available in AWS GovCloud (US) to address these needs and provides customers operating in regulated industries with a fully managed solution to build, deploy, and operate AI agents at production scale, without needing to manage the underlying infrastructure. This launch is part of Amazon’s broader commitment to invest up to $50 billion in U.S. Federal Supercomputing cloud and AI infrastructure, delivering cutting-edge AI capabilities to customers in our secure and compliant AWS GovCloud (US) environments.

What is Amazon Bedrock AgentCore?

Amazon Bedrock AgentCore provides the production infrastructure layer for agentic AI. Whereas Amazon Bedrock gives you access to foundation models and agent orchestration, AgentCore handles the operational challenges that can emerge when agents move from prototype to mission-critical deployment. These include runtime isolation, secure tool access, identity delegation, observability, and composable architecture.

With AgentCore, mission owners can accelerate agents from prototype to production using their choice of framework and model, while maintaining the security and compliance controls required for government and regulated workloads. AgentCore offers the following key capabilities:

AgentCore Runtime – With AgentCore Runtime, agent execution runs in a secure, isolated environment at the session level, preventing cross-tenant interference and sensitive data processed by one agent from being leaked to another.
Secure tool access using AgentCore Gateway – AgentCore Gateway converts existing APIs and AWS Lambda functions into agent-ready tools through the Model Context Protocol (MCP), giving agents secure access to enterprise data and services.
Identity delegation – AgentCore Identity enables agents to inherit and operate within the identity and permission boundaries of the user or system that invoked them. It natively supports external OAuth 2.0/OpenID Connect (OIDC) identity providers (IdPs). Existing AWS Identity and Access Management (IAM) policies, permission boundaries, and session controls extend naturally to agent actions without requiring user migration or exposing identity infrastructure to the public internet.
Real-time observability – AgentCore Observability provides full visibility into agent reasoning, tool usage, and decision paths. The actions an agent takes are logged and traceable, which is critical for compliance audits, incident response, and building trust in automated decision-making.
Composable architecture – AgentCore Evaluations enables teams to define test scenarios and measure agent performance against expected outcomes, supporting responsible AI practices and ongoing validation requirements.

Agencies don’t need to adopt everything at once. AgentCore services are composable: a team might start with runtime isolation for a sensitive CUI workload, add identity delegation when they’re ready to connect their existing workforce IdP, then layer in observability as they move to production. The flexibility extends to frameworks and models too, so teams can build with what they know today and evolve without rearchitecting.

Unlike bolt-on agent toolkits, AgentCore inherits compliance from the platform. There’s no separate authorization cycle, no additional infrastructure to harden, and no gap between your agent’s security posture and your environment’s.

Why this matters for government agencies

Customers operating in regulated environments face unique architectural considerations when deploying AI systems. Agentic AI, where models autonomously take actions, raises the stakes on these considerations. By addressing these challenges at the infrastructure level, AgentCore helps mission owners move faster from prototype to production, accelerating mission outcomes while maintaining the rigorous security and compliance posture that regulated operations demand. Customers can benefit from the following features:

Accountability requirements – When an agent takes an action on behalf of a customer, there must be a clear audit trail showing what the agent did, why it did it, and under whose authority. The observability and identity delegation features in AgentCore create this chain of accountability by construction.
Least-privilege enforcement – Agents should access only the tools and data their invoking user is authorized to reach. With identity delegation, developers can configure agents to operate within the invoking user’s permission boundaries, preventing privilege escalation.
Multi-tenant safety – In shared infrastructure environments, which are common in civilian organizations and shared services, session-level runtime isolation prevents one tenant’s agent workload from observing or affecting another’s.
Compliance and oversight – Reviewers, inspectors general, security incident responders, and compliance officers need to understand what AI systems are doing. Real-time observability and structured logging provide the evidence base for oversight without requiring manual agent supervision.
Operational readiness – Moving from a proof of concept to a production system that handles thousands of concurrent agent executions requires infrastructure that scales automatically, recovers from failures gracefully, and maintains performance under load. AgentCore provides this without custom engineering.

Example use cases

With AgentCore in AWS GovCloud (US), agencies can deploy production-grade agentic AI for the following scenarios:

Intelligent document processing – Agents that ingest, classify, extract, and route documents across customer workflows, with full audit trails and human-in-the-loop escalation paths.
Citizen service automation – Agents that handle multi-step citizen requests (verifying eligibility, pulling records, calculating benefits, and generating responses), reducing processing time from weeks to minutes.
Multi-step research and analysis – Agents that gather information from multiple sources, synthesize findings, and produce structured analysis products—all operating within the analyst’s access boundaries.
Automated compliance monitoring – Agents that continuously scan configurations, policies, and system states against regulatory requirements, flagging deviations and initiating remediation workflows.
IT operations and incident response – Agents that detect anomalies, diagnose root causes, execute runbook remediation steps, and escalate to human operators when confidence is low.

Getting started

AgentCore is available today in the AWS GovCloud (US-West) Region. You can get started with the following steps:

Enable Amazon Bedrock in your AWS GovCloud (US) account if you haven’t already.
Access AgentCore through the Amazon Bedrock console, the AgentCore CLI, or programmatically using the AWS SDK.
Choose your agent framework — AgentCore supports Strands Agents, LangGraph, Google ADK, and OpenAI Agents SDK.
Define your agent’s tools using the MCP-compatible tool interface—connect to databases, APIs, and enterprise systems your agent needs to access.
Configure identity delegation so agents operate within the invoking user’s permission boundary.
Deploy and monitor using AgentCore observability features to track agent behavior, tune performance, and demonstrate compliance.

For agencies already building agents with Amazon Bedrock Agents, AgentCore provides the production hardening layer—you can adopt it incrementally without rewriting existing agent logic.

Conclusion

The leap from agentic AI experimentation to mission-ready deployment has been one of the biggest barriers to wider AI adoption in regulated environments. AgentCore in AWS GovCloud (US) addresses this issue, providing the security, observability, and operational infrastructure that customers require, without the custom engineering that has historically slowed deployment timelines.

To learn more, refer to the Amazon Bedrock AgentCore Developer Guide. To get started, see Get started with Amazon Bedrock AgentCore, or contact your AWS account team to discuss how agentic AI can accelerate your mission. For more on multi-model access in AWS GovCloud (US), see AI Model Choice is a Mission Advantage.

Distributed generative AI for government

Phillip Spies — Tue, 04 Aug 2026 14:38:20 +0000

Your agency runs on data such as case files, claims, clinical records, procurement, telemetry, and mission logs. A large language model (LLM) that can reason across that data is transformative for citizen services and mission velocity. The instinct is to consolidate: Pull the data into a unified warehouse so the model can see it. This instinct produces the siloed generative AI deployments now appearing across the public sector.

Each solves a single slice because consolidation across the organization is too expensive, too slow, and too risky. A distributed approach, one that brings generative AI to the data rather than the reverse, is achievable today using Amazon Web Services (AWS) solutions such as Amazon Bedrock for orchestration, Amazon Neptune for data lineage, and AWS Identity and Access Management (IAM) for source-point security enforcement.

You invest in generative AI to gain organizational insight and end up with point solutions that can’t see across the organization.

The cost of consolidation

The economic cost of consolidation is a recurring one. Moving data into a centralized warehouse incurs egress fees, duplicated storage, and Extract, Transform, and Load pipeline maintenance for every source. Each new dataset adds to your bill. The data management burden compounds: lineage breaks, consumers query the copy instead of the source, and freshness drifts until the warehouse and operational systems disagree on the same questions.

The access control cost is most acute: Copying data breaks row-level security rules and tag-based restrictions. The pragmatic response is to feed generative AI only the least-sensitive data the consolidation can safely include, which produces the least-valuable insights. Your data already lives where it needs to be. The challenge is to bring the generative AI to it.

In this post, you’ll learn how you can use six architectural patterns to deploy generative AI across your data without the cost and risk of consolidation. Central to these patterns is Tool-Object Level Access Protocol (TOLAP), an open security protocol built on AWS that enforces fine-grained access control at the data source using AWS IAM signing and Amazon Bedrock Agents so unauthorized data never enters the AI’s context window.

From pattern to platform: The Prism prototype

Government agencies need organization-wide AI insight, but their data is scattered across clouds, mission systems, and security boundaries that make consolidation impractical. Prism solves this by sending intelligent agents to where the data already lives, delivering answers without ever moving sensitive records out of their authorized environments.

Prism is a prototype built on AWS that demonstrates how generative AI can operate across data without consolidation. It uses Amazon Bedrock for orchestration, Amazon Neptune for data lineage, and Amazon Bedrock AgentCore Code Interpreter for more secure content generation. TOLAP is the open security protocol at Prism’s core, enforcing access control inside each tool call using AWS identity and signing.

Prism implements all six of the architectural patterns discussed in this article. Its purpose is to make the architecture tangible. Each pattern can be adopted independently. Prism is one shape they take when assembled. The solution features the following:

Distributed-by-design across AWS, Azure, and Google Cloud Platform. Identity on each cloud (AWS IAM roles, managed identity, workload identity federation). A central main account orchestrates; per-tenant worker accounts execute against the data wherever it lives.
Twenty-four source types: 11 database engines, six API protocols, five knowledge base platforms, three object stores, all mediated by three TOLAP secure tool plugins.
TOLAP implemented with signed security contexts, most-restrictive-wins policy merge, and column/row/field enforcement at the tool boundary.
AI-generated compliance checklists rendered alongside conversations in real time with configurable enforcement modes.
LLM-assisted metadata enrichment with cross-source lineage stored in Amazon Neptune and traversed during query planning.
Dynamic content creation (PDF, PowerPoint, DOCX, XLSX) in Amazon Bedrock AgentCore Code Interpreter, a managed, network-isolated sandbox receiving only TOLAP-filtered data.

Prism and TOLAP

The diagram in this section illustrates Prism’s end-to-end query flow across multiple cloud and on-premises environments. The core principle: Bring the intelligence to the data instead of bringing the data to a central lake.

In the diagram, a user describes what they need using natural language. Prism automatically identifies the right data sources, applies TOLAP security and governance, and dispatches processing tasks to wherever the data resides, whether that’s AWS, Google Cloud, Azure, or on premises. Each environment executes locally; data never crosses cloud boundaries. Only filtered, policy-compliant results return to the aggregation layer, which synthesizes them into action-ready summaries, reports, and visualizations.

TOLAP spans the entire pipeline, enforcing access control and audit requirements regardless of where data is processed.

The diagram shows how Prism routes a user’s natural-language request across multiple cloud environments and on-premises systems, returning only authorized, policy-compliant results without moving the underlying data:

Figure 1: Prism multi-cloud intelligence. Data never moves, only the answer does

The architectural reframe: Send intelligent agents to where the data already lives across cloud providers, mission boundaries, and source types, and enforce access policy at the point where the data is read. Reconverge the results centrally. The data never leaves its system of record. The systems that already enforce policies continue to honor them.

Six patterns make this architecture work. Each is independently adoptable. Together, they form a complete stack.

The following diagram illustrates how these six patterns layer together, from persona-level governance at the top through TOLAP enforcement to the distributed execution substrate that spans multiple clouds and data sources:

Figure 2: Organization-level generative AI architecture. This is the six-pattern governance stack

Pattern 1: The gated persona pattern

Open-ended chat is a governance liability. A general-purpose assistant given access to data will go off-script, reach for sources outside scope, generate queries that violate cost assumptions, and produce output that bypasses documentation standards. In a public sector environment, unbounded behavior is incompatible with mission.

The gated persona pattern bounds behavior. Each persona is a configuration: a role, a scope of data sources, allowed query types, expected output formats, and a structured compliance checklist generated by an LLM from the persona’s metadata.

Each checklist item declares an enforcement stage (pre-query, during query, post-query), a validation method, and a required or advisory flag. Enforcement mode is configurable per persona: advisory, blocking, audit, or disabled. The checklist surfaces alongside the conversation so users see what has passed and what’s pending. The persona isn’t a user interface (UI) choice, it’s the governance contract the agent operates under.

Pattern 2: TOLAP

Most generative AI authorization is bolted on at the wrong layer: The API gateway authenticates the request, the application validates the role, and the agent is then trusted to respect those decisions. But by the time the agent pulls results, it has accessed records and fields the user was never authorized to access.

TOLAP moves enforcement inside the tool at the point where data crosses from the source into the agent’s view: The agent calls a tool. The tool resolves the user’s effective policy from a signed security context, rewrites queries to inject row filters and column masks, restricts available endpoints, filters knowledge base results by tag, and returns only authorized data. The agent has nothing to compromise because unauthorized data never enters its context window.

The following diagram traces this authorization flow from the initial user request through policy resolution, credential validation, and more secure tool wrapping to the data source, showing how unauthorized data is excluded before it can reach the agent:

Figure 3: TOLAP authorization flow. This is source-point enforcement

A TOLAP-compliant system has five components:

Security context – A signed, time-bound, tamper-proof container that carries the user’s effective policy from the trusted authority into the tool execution environment
Security profiles – Declarative, reusable policy definitions, scoped per source category
Policy resolution engine – Computes the effective policy for a user by merging all assigned profiles using a most-restrictive-wins strategy
More secure tool wrappers – The tools themselves, each enforcing the resolved policy at execution time: query rewriting, column masking, result filtering, rate limiting, schema redaction
Secure tool factory – Instantiates tools with the correct security context for each request, handling credential resolution and source configuration

By design, this architecture reduces the attack surface by surviving prompt injection, jailbreak attempts, and unintended tool composition because the unauthorized data is never returned. This isn’t a claim that TOLAP eliminates all risk. It’s a claim that the attack surface is architecturally smaller.

Pattern 3: Connection breadth through TOLAP extensibility

Public sector data lives in relational databases, analytics warehouses, Representational State Transfer (REST), GraphQL, Fast Healthcare Interoperability Resources (FHIR), gRPC APIs, vector knowledge bases, and object stores across multiple clouds.

TOLAP makes breadth tractable because the protocol is category-aware but uniformly shaped. Adding a new connection means writing a more secure tool wrapper that interprets the relevant policy fields, not redesigning the authorization layer.

Pattern 4: Data normalization – LLM first, override second

Data rarely arrives normalized. The same entity appears under different identifiers across systems. LLMs are remarkably good at inferring equivalences, such as recognizing that “VA” and “U.S. Department of Veterans Affairs” are the same entity, or that dob and date_of_birth are the same field.

For relationships that aren’t obvious or are compliance-critical, data owners explicitly define overrides stored as graph relationships and applied at query planning time. LLM first means the solution delivers value without an army of data engineers. Override second means owners can pin what matters as the solution matures. It’s the safety net under the model, not the other way around.

Pattern 5: Metadata enrichment for confident discovery

A generative AI solution can’t answer questions about data it can’t find. This pattern gives data owners LLM-assisted tools to enrich metadata (descriptions, classifications, sensitivity flags) at every level. The solution vectorizes enriched metadata for semantic discovery. Metadata is the substrate of trust. Enrich it or guess.

Pattern 6: Dynamic content creation in a managed sandbox

Insights aren’t always tables. Agents generate PDF reports, PowerPoint decks, Word documents, and Excel workbooks by executing Python in Amazon Bedrock AgentCore Code Interpreter, a managed, network-isolated sandbox.

The sandbox receives only TOLAP-filtered data, so the principle holds: Unauthorized data never reaches the content generation layer. The user receives an artifact that reflects only what they’re permitted to see.

What this means for public sector leaders

There are three questions worth bringing to your architects:

1. Where is policy enforced in your generative AI architecture?

If the answer is “at the API gateway” or “in the agent prompt,” the architecture can’t scale to organization-wide data with strict access control. Source-point enforcement is the only model that survives prompt injection across heterogeneous source types.

2. What’s the unit of governance for your generative AI deployments?

If the unit is the model, behavior drifts across users and tasks. If the unit is the persona, which is a role-bound configuration with an enforced compliance checklist, behavior is auditable and adjustable without touching the underlying model.

3. Are you consolidating data to feed generative AI, or distributing generative AI to where the data lives?

Consolidation is the path of least architectural resistance and greatest long-term cost.

These patterns are an open architecture. Prism is one reference implementation. Evaluate which of the six patterns address your environment’s specific failure modes, adopt them independently, and measure whether insight improves without the cost and risk of consolidation.

Conclusion

Distributed generative AI isn’t a future aspiration, it’s an available architecture. The six patterns described in this post mean you can query data in place; enforce policy at the source; normalize entities without a data engineering army; and deliver governed, auditable AI output to any persona in your organization.

Together, they mean you don’t have to choose between organization-wide AI insight and the security, compliance, and cost discipline your mission demands.

To get started, evaluate which of the six patterns address your environment’s specific failure modes. Each pattern is independently adoptable. Start with the one that removes the biggest blocker for your agency. The Prism prototype provides a concrete reference implementation you can examine, adapt, and build on.

For more information about Amazon Bedrock, distributed AI architectures, and AWS solutions for government and public sector, visit the AWS Public Sector Blog.

For a deeper dive into how TOLAP closes the data-object security gap in AI agent architectures, check out the TOLAP: Closing the data-object security gap in AI agent architectures.

Safekeeping your data anywhere: How AWS and Expando help European governments protect data from the edge to the cloud

Niclas Gothberg — Tue, 04 Aug 2026 14:14:39 +0000

Across Europe, governments and public sector organizations face a challenge that is both timeless and increasingly urgent: how do you keep sensitive data secure, accessible, and under your control no matter where your people are operating?

The answer is the same regardless of the mission: civil emergency teams operating without network connectivity, defense organizations managing classified data across security domains, and government agencies navigating strict data sovereignty requirements all need a data strategy that works at every layer, from the far edge or a data center to the cloud.

Amazon Web Services (AWS) is collaborating with Expando, a Swedish defense technology company, to help European public sector organizations build exactly that kind of layered, resilient data infrastructure. Together, AWS and Expando offer a connected approach to data protection that spans rugged edge deployments, disconnected field operations, customer-owned secure locations, and the full power of the AWS Cloud.

The Expando Avalanche platform is a ruggedized, mission-ready edge storage and computing device certified to military durability standards and deployed across European armed forces.

Figure 1: The Expando Avalanche Platform—a MIL-STD 810 certified edge storage and computing solution offering up to 3360 TB of Amazon S3 compatible object storage in a ruggedized enclosure

The challenge: Data that must be protected everywhere

Public sector organizations, particularly those in national security, defense, and critical infrastructure, operate across environments that commercial IT was never designed to handle. Data must be available in the field, where connectivity is unreliable or nonexistent. It must be protected at the highest security levels, even when hardware is physically at risk. And it must remain under the sovereign control of the organization that owns it—not a vendor, logistics chain, or foreign jurisdiction.

At the same time, these organizations need to connect field-collected data back to central systems for analysis, decision-making, and long-term storage. The gap between the tactical edge and the cloud has historically been a weak point: data either stays siloed in the field or must be physically transported in ways that introduce delay, risk, and complexity.

For member states of the EU or NATO, these challenges are compounded by the need to maintain control over data at every stage of its lifecycle, from collection to archival, while supporting interoperability with allied organizations.

The Avalanche platform is engineered for deployment in austere environments, with a ruggedized aluminum chassis, sealed connector panels, and a rack-mountable form factor for integration into mobile or fixed command infrastructure.

Figure 2: Technical overview of the Expando Avalanche enclosure showing the ruggedized chassis, sealed carry handles, I/O connector panels, and 2U rack-mount configuration (482.6 × 88 mm front profile)

A layered approach to data protection

AWS and Expando address this challenge with a three-layer architecture that gives organizations consistent data management, security, and sovereignty across environments.

Layer 1: The rugged edge, Expando Avalanche

The Expando Avalanche platform is a mission-ready edge storage and computing solution built for the most demanding environments. Certified to MIL-STD 810 military durability standards and deployed across European armed forces, Avalanche provides up to 3360 TB of storage in a ruggedized enclosure designed to withstand shock, vibration, extreme temperatures, and dust.

Critically, Avalanche is customer-owned hardware. Organizations retain full sovereignty over their data and their devices. There is no dependency on vendor logistics, mandatory certificate rotations that require hardware to be returned, or requirement for cloud connectivity to keep the system operational. Avalanche can run indefinitely in a fully disconnected state, making it suitable for field deployments, austere environments, and mission-critical operations where network connectivity is unavailable or undesirable.

Avalanche uses Amazon Simple Storage Service (Amazon S3) compatible object storage and AWS Identity and Access Management (IAM) compatible authentication, which means data stored on Avalanche integrates naturally with AWS Cloud services when connectivity is available, without requiring custom integration work.

Layer 2: Secure transport and data upload

When data needs to move from the field to a central data center or to the AWS Cloud, Avalanche supports multiple secure transport options that give organizations flexibility and control.

Organizations can physically move Avalanche units to their own secure facilities, such as a national data center, classified processing site, regional office, or data embassy established for the purpose of data staging and synchronization. A data embassy is a secure, customer-controlled facility where data can be staged, processed, and selectively transferred while remaining under the organization’s sovereign control throughout. This model keeps sensitive data under sovereign jurisdiction at every stage of its lifecycle.

Some organizations have also established their own secure transfer terminals at edge locations, partner sites, or government offices. Avalanche is designed to work seamlessly in these environments because it uses Amazon S3 compatible APIs and IAM compatible authentication, allowing data to be uploaded without custom integration work. For organizations that prefer to use AWS managed secure transfer infrastructure, Avalanche supports data migration through AWS Data Transfer Terminals, providing a governed, auditable pathway for moving large volumes of data into the AWS Cloud without relying on public networks.

The importance of protecting government data, and having a clear plan for how it moves and where it lives, has never been more apparent than in recent years. When Ukraine needed to protect its critical government data following Russia’s invasion in 2022, AWS helped migrate and safeguard more than 15 petabytes of data to keep government services running and citizen records protected. To learn more about that work, refer to Safeguarding Ukraine’s data to preserve its present and build its future. The lesson for European governments is clear: a layered data strategy with sovereign staging points, secure transport options, and cloud resilience is now an operational requirement, not a planning aspiration.

Layer 3: The AWS Cloud and the AWS European Sovereign Cloud

Once data reaches the AWS Cloud, organizations can apply AWS services across analytics, AI, security, compliance, and collaboration to their workloads. AWS operates data centers across Europe, with multiple AWS Regions giving public sector customers worldwide the ability to keep data within the EU while benefiting from the scale, security, and innovation of the world’s most comprehensive cloud.

For organizations that need to process data closer to where it is generated, AWS Local Zones extend AWS infrastructure to specific in-country locations, enabling low-latency compute and storage within national borders. This is particularly relevant for EU member states with strict data residency requirements, where workloads must remain within a specific country rather than a broader regional boundary.

For organizations with the most stringent data residency and operational autonomy requirements, the AWS European Sovereign Cloud provides a dedicated cloud environment designed to operate independently within the EU. It’s built for public sector customers and regulated industries that need a clear data boundary, EU-based operational staff, and governance structures aligned with European sovereignty requirements.

AWS supports more than 143 security standards and compliance certifications globally. European public sector customers can apply security principles, including zero-trust architectures, encryption at rest and in transit, and fine-grained access controls, to their AWS Cloud deployments.

Hypothetical scenario 1: Forest fire response

Let’s imagine a scenario in which a national emergency management agency deploys field teams to a remote forested region during a large-scale wildfire. Teams use Avalanche devices to collect aerial drone imagery, sensor readings, and incident logs in areas with no mobile coverage. When teams rotate back to a regional coordination center, devices are transported to a secure staging facility where data is reviewed and selectively synchronized to the AWS Cloud. Analysts use AWS services to process imagery at scale, model fire spread patterns, and push updated situational maps back to field teams for the next operational period, all without sensitive operational data leaving sovereign control.

Hypothetical scenario 2: Cross-border data sharing between allied agencies

In this hypothetical use case, two EU member states need to share operational data as part of a joint civil protection exercise. Each nation collects data on its own Avalanche devices and transports it to its own national data embassy. At the embassy, each nation reviews its data, applies its own classification policies, and selectively transfers agreed datasets to a shared AWS Cloud environment. Neither nation’s raw data ever leaves its own sovereign infrastructure. The shared cloud environment contains only the data each nation has explicitly approved for sharing, with full audit trails maintained throughout.

These scenarios illustrate the same closed-loop workflow: collect at the edge, transport through sovereign channels, analyze in the cloud, redeploy to the edge. The combination of Expando Avalanche and AWS makes this possible.

Why this matters for EU and NATO member states

With this solution, architects and solution designers can build data pipelines that span the full operational spectrum without compromising on security or sovereignty at different layers. Data collected in the field on an Avalanche device uses the same Amazon S3 compatible APIs and IAM based access controls as data stored in the AWS Cloud, reducing integration complexity and making it simpler to build consistent security policies across your entire data estate.

CIOs and technology leaders can meet data sovereignty requirements without sacrificing operational capability. Your data stays under your control at every layer, on hardware you own in the field, in transit through customer-controlled facilities or secure transfer terminals, and in the cloud under your own AWS account and security policies.

For national security and defense decision-makers, your organizations can operate with confidence in disconnected or contested environments, knowing that data is protected, accessible to authorized users, and ready to be synchronized with central systems when connectivity is restored.

For EU and NATO member states, this architecture supports interoperability and collaboration while maintaining national sovereignty. Data can be shared across allied organizations using AWS Cloud services and secure edge infrastructure, with each nation retaining control over its own data and infrastructure.

Built for Europe, backed by AWS

Expando is a Swedish company with more than 20 years of experience delivering rugged technology to European armed forces and defense organizations. The Avalanche platform is developed and supported in Sweden, with a supply chain and support model designed for the European market. Expando products are deployed in military aircraft, satellites, submarines, combat vehicles, and naval vessels across Europe.

AWS has been investing in European infrastructure and the European public sector for years. With data center Regions across Europe and a growing portfolio of services designed for regulated industries, AWS is committed to helping European governments modernize their IT infrastructure while maintaining the security and sovereignty their missions demand.

European governments shouldn’t have to choose between innovation and control. With AWS and Expando, you don’t have to.

What comes next

The Expando Avalanche roadmap extends the platform’s capabilities further, with Version 2 adding full edge compute support, including containers, edge virtual machines, and machine learning (ML) inference directly on the device. This helps organizations run AI models in the field without any cloud connectivity, processing data locally and synchronizing only the most relevant outputs to the AWS Cloud when connectivity is available.

Getting started

AWS and Expando want to hear from you. If you have specific use cases, capability requirements, or questions about how a layered edge-to-cloud data strategy could work for your organization, reach out to your AWS account team or contact Expando directly at expando.se.

To learn more about the Expando Avalanche platform, visit expando.se.

To learn more about AWS for public sector in Europe, visit aws.amazon.com/government-education.

The Signal-Activated Agent Pattern: A reference architecture for proactive government AI

Phillip Spies — Mon, 03 Aug 2026 19:18:51 +0000

In Part 1 of this series, we introduced the Signal-Activated Agent Pattern, which sends the right dimension of information to the right person based on what matters to them. This critical distinction separates proactive AI from a sophisticated alerting system.

Consider a single data event: a public health surveillance dataset updates with new respiratory illness rates across a region. That same data event is meaningful to multiple people—but in entirely different ways:

A public health researcher needs the statistical trend—rate of change, confidence intervals, geographic clustering. Value dimension: analytical depth.
A policymaker needs the operational implication—which jurisdictions approach intervention thresholds, what resource allocation decisions are imminent. Value dimension: decision-readiness.
A communications director needs the public narrative—how numbers compare to last week’s messaging, what questions media will ask. Value dimension: narrative coherence.
A field coordinator needs the logistics view—which clinics see increased volume, whether to pre-position supplies. Value dimension: ground-level preparedness.

These scenarios use the same data but with four completely different value extractions. The reference implementation achieves this through a consumer context store that maintains each person’s identity, role, and value dimensions in Amazon DynamoDB. When the event arrives, a hot-path filter AWS Lambda function evaluates it against each consumer’s watch conditions independently. Matching events escalate to an agent invoker that calls Amazon Bedrock with the full assembled context, producing a role-shaped response unique to each consumer.

This is why consumer context must exist before the system reacts. Without it, the system can’t distinguish between alerting and serving.

In Part 2 of our two-part series, we discuss the architecture of the Signal-Activated Agent Pattern and its application for proactive government AI. For Part 1, see Signal-activated generative AI: How agencies can reach more people and react faster.

Solution overview

The implemented pattern has two layers. Both share the same consumer context model and event ingestion pipeline:

Notification layer – Delivers role-shaped insights: event → filter → contextual Amazon Bedrock invocation → multi-channel delivery. This is the “tell the official what they need to know” path.
Action layer – Enables agents to take action when authorized: event → filter → contextual evaluation → execute capability (autonomous or human-supervised). This is the “do something about it” path.

Both layers share four foundational components:

Event ingestion (Amazon EventBridge) – Your agency’s data sources—case management systems, sensor networks, financial platforms, citizen portals—emit events to Amazon EventBridge when data changes. EventBridge provides serverless, content-based routing at millions of events per second. Inbound email through Amazon Simple Email Service (Amazon SES) is also supported as an event source, so your agency can wire existing email-based reporting into the activation pipeline.
Deterministic filtering (AWS Lambda hot-path filter) – A hot-path filter Lambda function performs deterministic pre-filtering against each consumer’s watch conditions. This includes threshold checks, status transitions, geographic boundaries, and time-based rules. This layer resolves over 80 percent of incoming events at sub-cent cost. The filter is user-specific: the same event might match one official’s watch conditions while being correctly suppressed for another. Events requiring contextual judgment escalate to Amazon Bedrock. A secondary digest runner Lambda function aggregates non-urgent signals into scheduled briefings.
Contextual AI agent (Amazon Bedrock agent invoker) – When a signal escalates, the agent invoker Lambda function calls Amazon Bedrock as a stateless HTTPS API with the full consumer context assembled from DynamoDB. The agent knows if this is a researcher who needs analytical depth or a policymaker who needs decision options. The same underlying event produces a completely different response for each consumer, shaped by their identity context, operational state, and expressed value dimensions.
Multi-channel delivery (Amazon SES and delivery router) – A delivery router dispatches the personalized response through the consumer’s preferred channel. Amazon SES handles email (both outbound notifications and inbound replies that feed back into the event pipeline). Webhook callback URLs enable delivery to Slack, Microsoft Teams, or custom portals. The channel itself is part of the consumer context.

From insight to execution using the action layer

The notification layer tells officials what they need to know. The action layer enables the agent to do something about it—under controlled conditions with explicit safety boundaries.

Each watch condition can authorize one or more capabilities—typed actions the agent can take when the watch triggers. A capability might be “send a compliance reminder email,” “create a ticket in your agency’s case system,” or “pre-stage supplies at a regional depot.” Capabilities operate in two modes:

Autonomous – The agent acts immediately under pre-authorized conditions. It is bounded by per-capability rate limits (for example, “no more than five emails per consumer per day”), reversibility tiering, and an AWS Systems Manager backed system-wide emergency switch that halts autonomous actions instantly if needed.
Supervised – The agent generates a proposed action and delivers an approve/reject/edit card using Slack, Teams, or a webhook callback URL. The action executes only after explicit human approval. Irreversible actions are supervised-only by system policy—not user choice.

Reversibility tiering classifies each capability into one of four levels: safe (read-only queries), reversible (actions with automated undo), effort-to-reverse (manual cleanup required), and irreversible (can’t be undone). This classification is enforced at the capability registry level. An administrator can’t configure an irreversible action for autonomous execution—the system rejects it, which is a structural constraint to maintain safeguards.

Open-protocol pluggability

Your agency has existing tools: CRMs, ticketing systems, custom RPA, legacy mainframe interfaces. The pattern integrates these through the Model Context Protocol (MCP). Adopters register the MCP-compliant server with the runtime; each tool the server exposes automatically becomes a typed capability in the system—with the same safety pipeline, reversibility classification, rate limits, and emergency switch coverage.

An MCP capability adapter translates between the runtime’s typed capability interface and the MCP server’s tool definitions. This means your agency can configure new action targets without modifying the core pattern. For example, a ServiceNow MCP server, a Salesforce MCP server, or a custom agency-built MCP server for legacy systems can become available capabilities of the action layer with no additional configuration.

Single-table DynamoDB design for consumer context

The consumer context model lives in a single DynamoDB table with three global secondary indexes (GSIs) optimized for the pattern’s access patterns:

GSI-1 (by-source) – Indexes watch conditions by event source. When an event arrives, the hot-path filter queries this index to find consumers watching that source type. This is the critical hot-path query—it must be fast, and it is, providing single-digit-millisecond DynamoDB reads.
GSI-2 (by-role) – Indexes consumers by role for persona fan-out. When a system-seeded watch activates (see the next section), this index identifies each consumer in the relevant role instantly, enabling broadcast of critical signals to all officials who must receive them.
GSI-3 (by-capability) – Indexes action records by consumer and capability. Used for rate-limit enforcement on the action layer: before an autonomous action executes, the system queries this index to verify the per-capability rate limit hasn’t been exceeded.

The same table stores identity context (role, value dimensions, preferences), operational context (current priorities, active decisions), signal buffer items (accumulated events since last touch), watch conditions, and action audit records. With a single-table design, you can avoid cross-table joins, and access patterns are served by indexed queries.

System-seeded persona defaults

Some signals aren’t optional. For example, in the event of a disease outbreak trigger, a Class I product recall, or a critical infrastructure failure, each official in a given role must receive these regardless of personal preferences. The pattern supports system-seeded watches: critical-event conditions configured by administrators that trigger automatically for each consumer assigned to the relevant role. These are invisible to user-authored watch management, non-removable by individual consumers, and indexed using GSI-2 for efficient role-based fan-out.

Two paths into the same runtime

The system supports two entry points into the same AI runtime:

Official-initiated – An official asks a question. The agent invoker responds with full consumer context—informed by their role, current priorities, and long-term context history accumulating in their signal buffer.
System-initiated – A data event triggers the hot-path filter. The agent invoker evaluates through the lens of this consumer’s context and delivers a personalized, role-appropriate insight—or, if the watch authorizes action capabilities, proposes or executes an action.

Both paths use the same context store, Amazon Bedrock invocation pattern, and delivery router. The official experiences a coherent assistant regardless of which path triggered the interaction.

The following diagram shows how both activation paths—whether an official asks a question or a data event triggers the system—flow through the same consumer context store before the agent responds. The diagram also illustrates the dual output: notification layer (role-shaped insights) and action layer (autonomous or supervised execution), with the Systems Manager emergency switch providing immediate halt capability.

Figure 1: Both activation paths—official-initiated and system-initiated—flow through consumer context before the agent responds

Secure runtime model

A common concern with agentic systems is uncontrolled behavior—an AI process running persistently, accumulating state, potentially drifting from its intended scope. The Signal-Activated Agent Pattern addresses this structurally:

There is no persistent AI process – Amazon Bedrock is a stateless HTTPS API. The Lambda function calls it, receives a response, and terminates. There is no large language model (LLM) agent running between events, persistent socket, or accumulated hidden state. Each invocation is independent, bounded, and observable.
Capability binding is structural, not textual – When a watch is authored, it explicitly declares which capabilities the agent might invoke if that watch triggers. This binding is stored in DynamoDB at author-time. At activation-time, the agent invoker enforces this binding before any action executes. Even with a malicious inbound event payload, the agent can’t deviate to call a capability the watch didn’t authorize. This safety property bounds prompt injection: the model can generate whatever text it wants, but the action executor only permits capabilities that were structurally pre-authorized.
Emergency switch is immediate – Parameter Store, a capability of AWS Systems Manager, uses a flag to serve as a global emergency switch. When flipped, autonomous action execution halts within one Lambda function cold-start cycle. There is no graceful shutdown negotiation or queued actions draining. Notifications continue unaffected; only the action layer pauses.

Watch conditions for conversational configuration

The system learns what each consumer needs through natural conversation. For example, a researcher says: “Alert me when any county shows a two-standard-deviation increase in respiratory cases.” A policymaker says: “Let me know when projected hospitalizations in my region approach 80 percent of surge capacity.” A field coordinator says: “Flag me when any clinic in District Four reports supply shortages.”

The system extracts these into structured watch conditions stored in DynamoDB (indexed by GSI-1 for the hot path). Each watch specifies the event source, the filter criteria, the notification template, and optionally the authorized capabilities for the action layer. The solution doesn’t use configuration portals or IT tickets. Officials express what they need in their own words, and the system monitors on their behalf.

Two-package architecture deployment

The reference implementation ships as two packages:

Runtime framework – Core primitives, such as context store, capability registry, delivery router, action executor, hot-path filter logic, and digest runner. This framework is unit-testable without AWS credentials. Your agency can write and validate watch conditions, capability definitions, and persona configurations locally before deploying.
AWS CDK construct library – The AWS Cloud Development Kit (AWS CDK) offers infrastructure as code (IaC). One top-level construct (SignalAgentStack) provisions the recommended topology: EventBridge bus, Lambda functions (hot-path filter, agent invoker, digest runner, action executor), DynamoDB table with three GSIs, Amazon SES configuration, Amazon API Gateway endpoints, and Systems Manager parameters. Lambda code is bundled at publish time—your agency runs a single AWS CDK deploy command.

This separation means your agency can adopt incrementally: start with the notification layer, validate the consumer context model, then enable the action layer when you’re ready for supervised and autonomous capabilities.

Mission impact for your agency

When your agency deploys contextual signal-activation, the impact compounds:

Reach more people – Proactive identification of eligible constituents and at-risk populations. Your agency finds the people who need help rather than waiting for applications.
React faster with the right context – The gap between “data changed” and “a qualified official knows and can act” reduces to minutes, and the information arrives pre-shaped for their decision-making needs.
Each consumer gets their value dimension – The same underlying data surfaces as statistical analysis for researchers, decision briefs for policymakers, logistics summaries for coordinators, and narrative context for communicators.
Act, not just inform – With the action layer, the system moves from “here is what you need to know” to “here is what I can do about it, with your approval”—or, for pre-authorized safe actions, handles routine responses autonomously.
Scale without proportional headcount – The system monitors thousands of data streams simultaneously, personalized for each official. Serverless architecture means costs scale with actual events processed, not provisioned capacity.

Looking forward: The voice-activated intelligence layer

Let’s imagine taking this pattern one step further. Instead of configuring watch conditions through text, picture an official’s first interaction with the service as a voice conversation: “Tell me about your role. What are your current priorities? What keeps you up at night? What would you want to know the moment it happens?”

The official speaks naturally. As they do, the system builds a persona profile in real time: extracting value dimensions, identifying decision patterns, mapping the types of signals relevant to this specific person. That persona becomes the lens through which incoming data is processed.

In response, the voice interface activates: “Good morning. Three developments overnight are relevant to your current priorities. The first relates to the enrollment threshold you mentioned. Would you like me to walk you through the details, send a summary to your team, or explore the cross-cutting impacts on downstream programs?”

The official chooses. Each response triggers a different action—because the system understands not just what happened in the data, but what this person can do with it given their authority and current context. With the action layer in place, a message like “send a summary to my team” actions the user-directed instruction immediately.

Each component for this solution—voice interfaces (Amazon Lex, Amazon Transcribe), persona modeling (DynamoDB, Amazon Bedrock), real-time event processing (EventBridge, Lambda), and voice delivery (Amazon Connect, Amazon Polly)—is offered as managed AWS services. The pattern described in this series is the foundation; the voice-activated intelligence layer is the next step your agency can build on top of it.

The following diagram depicts the continuous refinement loop enabled by voice-activated persona building. Each cycle sharpens the system’s understanding: the official’s spoken priorities become structured watch conditions and capability authorizations, data is filtered through that persona, insights and action choices are delivered, and the system learns from which activations drove real action and which were ignored.

Figure 2: The continuous refinement loop: voice builds the persona, data is processed through it, insights are delivered with choices, and subsequent interactions sharpen the system’s understanding of what this user needs

Traditional vs. signal-activated government AI

The following table compares the features of traditional AI with signal-activated AI.

Traditional AI	Signal-Activated AI
Same report/dashboard for everyone	Personalized value dimension per consumer
User extracts their own meaning from data	System delivers meaning shaped to each role
Context limited to what user remembers to ask	Rich consumer context assembled before activation
Researcher and policymaker see same view	Each gets their specific value extraction
One-size-fits-all notifications	Role-appropriate insights through preferred channel
Informs only; action requires separate system	Notification and action layer with safety controls
Issues discovered at review time	Issues surfaced and acted on at the moment they emerge

Conclusion

The reference implementation is complete: notification layer, action layer (autonomous and supervised modes), open-protocol capability adapter, system-seeded persona defaults, and single-table DynamoDB design with three GSIs. The implementation undergoes AWS validation—deploying against live Amazon Bedrock endpoints, Amazon SES delivery, and production DynamoDB tables.

AWS Public Sector teams will work with interested agencies to scope pilot deployments. Reach out to your AWS account team for engagement details.

Signal-activated generative AI: How agencies can reach more people and react faster

Phillip Spies — Mon, 03 Aug 2026 19:18:19 +0000

Government agencies exist to serve people. Each day, millions of constituents depend on federal, state, and local agencies for benefits, safety, infrastructure, and essential services. The faster your agency can identify a need, reach the right person, and deliver the right information, the better it serves its mission.

But there has historically been a gap between the technology agencies deploy and the humans who consume its output. Data sits in dashboards. Insights live in reports. The value is there—but it requires people to find it, interpret it, and decide what matters to them. Everyone looks at the same spreadsheet, visualization, or report, and each person must extract their own meaning from it.

Technology needs a bridge to the human element that understands not just what the data says, but what each individual person needs from it. A researcher and a policymaker might both look at the same dataset, but need entirely different dimensions of value from it. The researcher needs statistical depth. The policymaker needs decision-readiness. With current solutions, each person must manually extract their dimension from a generic view.

Signal-activated agentic design provides that bridge. Rather than asking each user to consume the same static output and extract their own meaning, a signal-activated system understands what each consumer needs and delivers precisely that value dimension—proactively, in real time, personalized to each person’s role, context, and current priorities.

This two-part series introduces the Signal-Activated Agent Pattern—an architectural approach, backed by a deployable Amazon Web Services (AWS) reference implementation, that helps government AI platforms move from generic, reactive question-answering to proactive, contextually personalized decision support. With this solution, agencies can reach more people, respond faster, and deliver the right value to the right official at each decision point.

The next step for government AI

Most government generative AI deployments today follow a straightforward model: an official asks a question, the AI provides an answer. This is valuable. It accelerates research, simplifies policy interpretation, and reduces the burden on subject matter experts.

But imagine what becomes possible when the AI doesn’t have to wait, and it understands who is asking well enough to shape its response accordingly. It can watch incoming data—benefit applications, sensor readings, case updates, compliance filings—and surface insights to each official in the form that is most useful to them, at the moment those insights become relevant.

This is the shift from reactive AI to contextual signal-activated AI: systems that are continuously aware of what is happening across your agency’s data landscape, understand what each consumer needs from that data, and proactively deliver personalized value before small issues become large ones. The reference implementation built on AWS is deployable today using Amazon EventBridge for event ingestion, AWS Lambda for deterministic filtering, Amazon Bedrock for contextual reasoning, and Amazon DynamoDB for persistent consumer profiles.

Same data, different value: Why personalization is key

The fundamental insight behind signal-activated design is that the same data means different things to different consumers. A single data event—say, updated program enrollment numbers—carries entirely different value depending on who receives it:

A researcher needs the analytical dimension: What is the enrollment trend? How does it compare to projected models? Are there statistically significant deviations in specific demographics or geographies?
A policymaker needs the decision dimension: Are enrollment numbers approaching a threshold that triggers additional funding requirements? What are the implications for next quarter’s budget request? Do I need to act?
A field coordinator needs the operations dimension: Which office locations are seeing increased foot traffic? Do we need to adjust staffing for the next 2 weeks? Are wait times exceeding service standards?
A communications director needs the narrative dimension: How does this compare to what we communicated publicly last month? Do we need updated messaging? What questions will stakeholders ask?

A traditional system presents the same dashboard to all four people and leaves it to each of them to find their value. The signal-activated pattern presented in this series uses a consumer context store in DynamoDB to maintain each person’s identity, role, and value dimensions. When an event arrives, a hot-path filter Lambda function evaluates it against per-user watch conditions. Events that pass escalate to an agent invoker that calls Amazon Bedrock with the full assembled context for that consumer—producing a role-shaped response without users needing to search, filter, or ask.

This is why contextual personalization is at the core of the pattern, not just an additional feature. Without it, proactive AI is just automated broadcasting. With it, proactive AI becomes a genuine service layer that makes each person more effective at their specific job.

The following figure illustrates this contextual fan-out: a single data event enters the pipeline and produces four distinct, role-appropriate insights—each shaped by the consumer’s unique value dimension and delivered through their preferred channel.

Figure 1: A single data event produces four different, role-appropriate insights—each shaped by the consumer’s unique value dimension

Three dimensions of consumer context

For the system to deliver the right value dimension to the right person, it needs deep consumer context. In the reference implementation, this context lives in a single DynamoDB table with three logical layers:

Identity context – Who is this person, and what value dimensions matter to them? A regional director needs different signals than a frontline caseworker; a grants program officer cares about compliance thresholds; a researcher cares about statistical significance. The system stores each consumer’s role, expertise, decision authority, and the specific dimensions of data that are relevant to their work.
Operational context – What are they working on right now? The same signal has different urgency depending on timing. An enrollment spike matters differently to a policymaker who has a budget hearing next week compared to one whose review cycle is months away. The system tracks active decisions, open questions, and current priorities so it knows not just what to deliver but when and how urgently.
Signal context – What has been accumulating? Rather than interrupting with each individual data point, the system synthesizes: “Three things changed in your portfolio overnight that relate to the decision you’re working on.” A digest runner Lambda function aggregates signals on a configurable schedule, producing synthesized briefings that respect attention while confirming that nothing falls through the cracks.

Together, these three layers support a system that is precise rather than noisy—delivering the right value, to the right person, at the right time, in the right format for how they think and decide.

Why now: The infrastructure is ready

Building proactive, contextually personalized AI solutions for government has historically been complex. The foundational infrastructure presented in this post uses managed cloud services, and the reference implementation demonstrates how they combine into a production-ready topology:

Real-time event processing with Amazon EventBridge – Serverless event bus routing millions of events per second with content-based filtering rules.
Foundation models from Amazon Bedrock – Contextual reasoning and personalized generation accessible as a stateless HTTPS API, no model hosting required.
Persistent consumer context using Amazon DynamoDB – Single-table design maintaining per-user profiles, watch conditions, and signal buffers at any scale with single-digit-millisecond reads.
Multi-channel personalized delivery with Amazon SES and Amazon API Gateway – Email (inbound and outbound), webhook callbacks to Slack/Teams, and extensible delivery routing.
Cost-efficient filtering using AWS Lambda – Deterministic per-user watch condition evaluation at sub-cent cost, invoking Amazon Bedrock only for events requiring contextual judgment.
Infrastructure as code deployment with AWS CDK – A single top-level construct provisions the complete stack. One deployment command and one AWS CloudFormation stack configure the services together.

The building blocks are in place and proven composable.

What comes next

In Part 2, we detail the Signal-Activated Agent Pattern architecture: how the notification layer delivers role-shaped insights, how the action layer enables agents to take action under human-supervised or autonomous conditions, and how a single-table DynamoDB design with three indexes supports the hot path at scale. We walk through how EventBridge, Lambda, Amazon Bedrock, and DynamoDB map to each layer, and show how the same data event produces four completely different, role-appropriate insights for four different consumers.

The Signal-Activated Agent Pattern offers AI that doesn’t just answer questions generically, but understands each official as an individual and delivers the specific dimension of value they need—proactively, in real time, at each decision point.

Transforming university lecture content into an enriched course using generative AI on AWS

Benji Durkin — Wed, 29 Jul 2026 13:10:16 +0000

Amazon Web Services (AWS) has collaborated with the University of Technology Sydney (UTS) to make a more engaging content delivery platform as an alternative to long lecture videos. Universities today produce hours of recorded content that students are expected to consume passively, in full, with no adaptation to their individual pace or knowledge level. UTS has performed a trial of this solution in a cloud computing course to evaluate the effectiveness of generative AI in improving student engagement.

This cloud computing course enrolls around 500 students, each with different learning styles, prior knowledge, and time constraints, yet all receive the same 90-minute recording. Research by Gloria Mark at the University of California, Irvine, shows that the average time a person stays focused on a single screen task has declined from approximately 2.5 minutes in 2004 to only 47 seconds in the early 2020s. Learners benefit from content that is bite-sized, adaptive, and intelligently structured, but educators don’t have the time and capacity to produce this manually for every recording. Initial feedback from students indicated that this solution helped them learn more efficiently.

We identified the following core challenges with the current teaching approach:

Engagement in decline – Students increasingly disengage from long-format recordings. Completion rates for full-length lecture videos are low, but lecturers have no scalable way to break content into digestible pieces without significant manual effort.
No visibility into learning gaps – With a monolithic recording, lecturers have no insight into which topics students struggle with, where they stop watching, or what questions they have.
Personalization – Monolithic recordings offer no adaptability to individual learner needs. Providing personalized learning manually is impractical at scale due to teaching resource constraints.

Using AI to make learning more flexible

AWS developed an approach where a content creator uploads a single recording, and the system automatically produces a complete, structured learning module. The recording is intelligently segmented into 15–30 minute topic-focused video chunks, each further divided into short chapters of 30 seconds to 3 minutes for fine-grained navigation. For each chunk, AI generates a summary, key points, context with examples, and multiple-choice knowledge checks. Through a personalized learning path, learners can progress at their own pace, with progress tracking and targeted revision. A course-aware AI chat agent answers learner questions grounded in course materials. Content creators review, edit, and explicitly publish all generated content before learners see it.

Figure 1: Automatically generated lesson with chapters and content

The content review step is important: all AI-generated content is initially stored in a draft state. This human-in-the-loop workflow helps educators verify all AI-generated content before publication to ensure accuracy and quality of learning materials.

One upload is equivalent to one complete course module. A single lecture recording produces a fully enriched learning experience made up of chunked videos with chapter markers, summaries, key points, explanatory content, knowledge checks, and chat context without any additional manual content creation.

How it works

The system is built on two core AWS services for AI processing, Amazon Transcribe for speech-to-text conversion and Amazon Bedrock for generative AI. These are supported by a serverless application layer on AWS.

Amazon Transcribe converts the audio into timestamped, word-level text and temporal metadata that downstream systems reason about programmatically. The Amazon Transcribe audio segmentation feature groups words into sentence-level segments with precise timestamps, and this is what makes intelligent chunking possible. Because every audio segment has a start and end time, we can reason about which text belongs in a chapter and then link back to the exact timestamps.

Claude by Anthropic in Amazon Bedrock handles the semantic reasoning: restructuring raw transcripts into readable paragraphs, identifying topic boundaries, generating chapter divisions, and producing educational content for each segment. The chat assistant uses Amazon Bedrock Knowledge Bases for Retrieval Augmented Generation (RAG). Configuration including model identifiers can be externalized to Parameter Store, a capability of AWS Systems Manager, enabling model upgrades as a configuration change without redeployment.

Together, these services form an end-to-end pipeline: a recording enters as a single video file and emerges as a hierarchical content structure, with the course at the top, followed by the module, chunks, and finally chapters. Each level is enriched with AI-generated learning content, stored in Amazon Relational Database Service (Amazon RDS) for PostgreSQL, and streamed to learners through Amazon CloudFront.

The following diagram is the solution architecture for the preprocessing pipeline and application stack.

Figure 2: Solution architecture diagram

Technical challenges

The concept is straightforward (transcribe, segment, generate), but the implementation reveals several nontrivial technical challenges. This section details the approaches we developed, including methods that failed and why, before arriving at reliable approaches.

Intelligent video chunking with Amazon Bedrock

The most critical component is the video chunking system. It takes a long recording (60–120 minutes) and segments it into self-contained, topic-focused pieces. This is considerably harder than it appears.

In hindsight, our first attempt was naive. We passed the full transcript to Amazon Bedrock and asked it to identify chapter boundaries with timestamps. This doesn’t work reliably and resulted in the following issues:

Mid-sentence breaks – The model placed topic boundaries at arbitrary points, producing chunks that started or ended mid-thought.
Context window saturation – Lectures produce transcripts of more than 15,000 words. The model’s reasoning about topic boundaries degraded across the full document.
Timestamp confusion – Large language models (LLMs) have no built-in understanding of the relationship between text and video timecodes. Including raw timestamps in the prompt introduced noise that degraded accuracy.
Inconsistent output – Results varied significantly between invocations on the same input.

We concluded that a single prompt can’t reliably perform both structural analysis and semantic reasoning simultaneously on long-form content. The problem must be decomposed.

To address this challenge, we broke the complicated process into focused subtasks. We developed a three-stage pipeline that decomposes the problem into discrete, well-defined subtasks, each handled by the most appropriate technique (deterministic processing, lightweight LLM, or sophisticated LLM). The first stage is raw transcript preprocessing. Stage two is broken down into two parts, LLM paragraph generation and term frequency–inverse document frequency (TF-IDF) timestamp recovery. Stage three is also two parts, chapter detection and chunk optimization.

In raw transcript preprocessing, a Lambda function extracts and cleans the audio segments from the Amazon Transcribe JSON output. Each segment contains the spoken text with precise start time and end time fields. Unnecessary metadata is stripped and the duration of each segment is calculated.

The raw transcript segments are passed to Anthropic’s Claude Haiku (a fast, cost-effective model) with instructions to restructure the text into readable paragraphs. This adds punctuation, removes verbal filler, and groups sentences into coherent paragraph units. For long transcripts exceeding 50,000 characters, the system automatically batches the input into manageable chunks, processing each batch independently and assembling the results:

CHUNK_SIZE = 50000

if len(json.dumps(self.transcript)) > CHUNK_SIZE:
    return self._generate_paragraphs_batched(CHUNK_SIZE)

The paragraph restructuring in the first part of stage two loses the original timestamps (the LLM outputs cleaned text, not timestamped segments). We recover timestamps using TF-IDF cosine similarity, a deterministic, statistical technique that matches each generated paragraph back to its corresponding position in the original timestamped transcript.

Both the original transcript segments and the generated paragraphs are transformed into fixed-length windows of 50 words. TF-IDF vectorization and cosine similarity then find the best match:

from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity
import numpy as np

# Transform both sources into 50-word segments for comparison
transcript_segments = self._transform_text_segments(self.transcript, num_words=50)
paragraph_segments = self._transform_text_segments(paragraphs, num_words=50)

# Build TF-IDF matrix across all text segments
vectorizer = TfidfVectorizer().fit_transform(transcript_segments + paragraph_segments)
vectors = vectorizer.toarray()

# For each paragraph, find its best-matching original segment
for i in range(len(paragraph_segments)):
    paragraph_vector = vectors[len(transcript_segments) + i]
    similarities = cosine_similarity(
        vectors[:len(transcript_segments)],
        paragraph_vector.reshape(1, -1)
    )
    best_match = int(np.argmax(similarities))
    paragraphs[i]['start_time'] = int(float(
        self.transcript[best_match]['start_time'])) - 2

TF-IDF weighting ensures distinctive words such as technical terms and proper nouns contribute more to the match than common words. The paragraph is assigned the timestamp of its highest-similarity match. Even after the transcription is restructured, the core vocabulary stays the same, so the matching is reliable. The method uses vector math so it’s also deterministic.

With timestamped paragraphs in hand, Anthropic’s Claude Sonnet (a more capable model) analyzes the full set of paragraphs and groups them into chapters: short, topically coherent sections of 30 seconds to 3 minutes. The model identifies topic transitions and generates meaningful chapter titles.

Finally, the system groups chapters into video chunks, the primary units of content delivery. The model creates chunks of 15–30 minutes by combining consecutive chapters, never splitting a chapter across two chunks.

The result is a hierarchical content structure:

Figure 3: Course hierarchical content structure

After chunk boundaries are determined, the source video is split at the identified timestamps.

Structured content generation with Amazon Bedrock

For each video chunk, the pipeline generates structured educational content: summaries, key points, explanatory material, and multiple-choice assessments. The critical challenge is producing consistent, schema-compliant output from the LLM across thousands of invocations.

Quiz question generation requires the model to output a question, four answer options, a correct answer indicator, and an explanation that must conform to a strict schema. Early approaches using prompt engineering, using prompts such as “Output your answer as JSON,” failed in production. Output formatting varied between invocations and included markdown tables, numbered lists, raw JSON, or hybrid formats. Model version upgrades introduced breaking changes. For example, upgrading from Anthropic’s Claude 3.5 Sonnet to Claude 3.7 Sonnet caused the model to wrap JSON in markdown code fences, breaking the parser entirely.

For this challenge, the solution was to use structured outputs on Amazon Bedrock, a capability that uses constrained decoding to generate schema-compliant JSON responses. Rather than asking the model to output JSON and hoping it complies, the schema is enforced at the token generation level.

Structured outputs uses constrained decoding in which the model can only generate tokens that produce valid JSON that conforms to the provided schema. A separate schema was used for each content type, and this allowed us to generate multiple fields in one prompt. For example, the title of a lesson could be generated at the same time as the description, within one JSON object.

The following screenshot shows the system providing an AI-generated multiple-choice knowledge check using Amazon Bedrock structured outputs.

Figure 4: AI-generated multiple-choice

Course-aware chat-based assistant with RAG

Beyond pre-generated content, learners interact with a chat-based assistant powered by Amazon Bedrock Knowledge Bases with Amazon Simple Storage Service (Amazon S3) as the vector store. Lecturers upload course documents (syllabi, assignment briefs, reference materials) to an S3 bucket, and Amazon Bedrock handles chunking, embedding, and indexing automatically. When new documents are uploaded, a sync operation updates the vector index, keeping the chat assistant’s knowledge current without manual intervention.

A key design feature is source-aware prompting. Each retrieved context is tagged with its source filename, and the system prompt instructs the model to only use content from the specific document the student is asking about. This prevents cross-contamination, for example, answering an Assignment 2 question with content retrieved from Assignment 1.

Conclusion

This post demonstrates that generative AI can transform how long-form educational content is delivered. A single uploaded recording produces a complete, structured learning module with topic-segmented videos, chapter navigation, summaries, explanations, and assessments while maintaining full human oversight over published content.

Key takeaways:

Decompose the problem – Video segmentation can’t be solved with a single LLM prompt. Breaking it into three stages—structural preprocessing, TF-IDF timestamp recovery, and AI-driven topic grouping—produces dramatically better results than any single-pass approach.
Use TF-IDF for timestamp alignment – When an LLM restructures text (losing positional metadata), TF-IDF cosine similarity provides a fast, deterministic method to recover the original timestamps without additional AI calls.
Enforce output schemas at the infrastructure level – Amazon Bedrock structured outputs (constrained decoding) eliminate the need for output parsing, validation, and retry logic, producing reliable structured data regardless of model version.
Match model capability to task complexity – Use fast, cheap models such as Anthropic’s Claude Haiku for text formatting tasks and more capable models such as Anthropic’s Claude Sonnet or Claude Opus for semantic reasoning tasks like topic identification. Not every step needs the most powerful model.
Maintain human oversight by design – Pre-generating all content into a draft state enables educator review without sacrificing automation benefits. The system augments human judgment rather than replacing it.

This implementation targets higher education, but the methodology is domain-agnostic. Organizations producing long-form instructional content, whether that’s corporate training, professional development, compliance education, or conference recordings, can apply the same pipeline to produce structured, bite-sized learning experiences from existing recordings.

To get started transforming your long-form educational content into engaging, bite-sized learning experiences, follow these paths:

Explore the services – Get hands-on with Amazon Transcribe and Amazon Bedrock in your own AWS account. Both offer AWS Free Tier usage to experiment with the core capabilities described in this post.
Connect with us – If you’re an educational institution or training organization looking to implement this approach, contact the AWS Public Sector team to discuss your use case and get architecture guidance tailored to your scale and requirements.

The challenges we identified as part of this collaboration with UTS were addressed using generative AI, with students saying it was especially useful in breaking up long-form content where they previously would lose attention. By using generative AI in an educational environment, it’s possible to improve student retention, personalize content to individual learning requirements, and scale this without requiring many hours of educators’ time.

Empowering underserved youth with AI career support: KLCI’s journey on AWS

Mohammed Reda — Tue, 28 Jul 2026 22:26:40 +0000

Approximately 121 million young Africans between the ages of 15 and 35 are either unemployed or categorized as not in education, employment, or training (NEET). The formal sector provides less than 20% of youth employment on the continent. Each year, over 10 million young people enter the African labor market, but current growth patterns generate only around 3 million formal jobs. For many of these young people, the path from education to employment is unclear not because they lack ambition, but because they lack access to career guidance.

In Nigeria alone, 93% of schools lack dedicated career counselors. Professional coaching costs from $50 to $350 per session, far beyond what most underserved youth can afford. Traditional approaches such as one-on-one mentoring, career seminars, and telephone hotlines haven’t scaled to meet this demand.

The Kayode Alabi Leadership and Career Initiative (KLCI Africa), a nonprofit social enterprise headquartered in Lagos, Nigeria, set out to solve this problem using generative AI and Amazon Web Services (AWS). In this post, we describe how KLCI Africa built Rafiki AI, a WhatsApp-based generative AI career advisor that delivers personalized career guidance to underserved and displaced youth in under 2 minutes.

The challenge

Founded in 2017, KLCI Africa prepares young people in underserved and displaced communities for the workforce. The organization has trained over 10,000 young people across 14 Nigerian states in leadership, skills development, and career readiness. Over the years, KLCI tried one-on-one coaching, group counseling, career seminars, and even phone hotlines. None of these approaches could reach the scale of the problem.

Providing personalized career guidance requires maintaining context across conversations, understanding individual circumstances, and delivering relevant recommendations. Doing this manually for tens of thousands of young people across multiple countries isn’t feasible with a small team and limited resources. A single career counseling session can take 30–60 minutes per person. At that rate, reaching even a fraction of the youth who need support would require thousands of counselors who don’t exist in these communities.

KLCI needed a way to deliver quality career guidance at scale, in a format accessible to youth with limited internet connectivity and no access to laptops or desktop computers. This is where generative AI offered a path forward.

The solution: Rafiki AI

KLCI initially prototyped their career advisor using the OpenAI GPT-4o mini model, calling the API directly from a basic server setup. While this proved the concept worked, the architecture couldn’t scale. There was no automatic scaling to handle concurrent users, no reliable state management across conversations, and no infrastructure to support additional capabilities like voice or document processing.

In February 2025, KLCI was selected for the AWS Education Equity Initiative, receiving $51,000 in cloud credits to build and scale their solution. As part of the initiative, KLCI received technical consultations with AWS solutions architects who helped them address these infrastructure challenges. The team decided to migrate the entire solution to AWS, running the AI model through Amazon Bedrock and building the supporting infrastructure on Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (Amazon RDS), Amazon Simple Storage Service (Amazon S3), and Amazon Route 53.

With the infrastructure in place, KLCI launched Rafiki AI in April 2025 as a WhatsApp-based career chat assistant. Users message a designated WhatsApp number and engage in a structured conversation where the AI guides them through their interests, strengths, limitations, and aspirations using KLCI’s Interest, Strength, Limitation, and Purpose (ISLP) framework. The output is a personalized career pathway plan delivered in under 2 minutes.

Since launch, the team has continued adding functionality. Rafiki now supports over 56 languages, including Yoruba, Igbo, Hausa, Pidgin English, French, and Swahili, meaning it can reach youth across Francophone Africa, East Africa, and refugee communities.

Users can upload their CV for an applicant tracking system (ATS)-standard review and receive tailored interview preparation based on the document’s content. Voice accessibility was added through Amazon Transcribe and Amazon Polly so users with limited literacy can interact by speaking rather than typing.

KLCI also launched Rafiki X, a companion web application that offers extended features including document uploads, payment integration, and email-based career reminders for users with reliable internet access. Conversations across both solutions are retained, meaning users can pause and resume their session within 24 hours. The system is available around the clock.

The results

Since launch, Rafiki AI has achieved significant traction with zero marketing spend, growing entirely through organic word-of-mouth efforts.

The solution has reached over 11,300 users across more than 60 countries, exchanging over 109,000 messages and delivering 49,861 pieces of career advice. It has answered 41,571 career queries, reviewed more than 50 CVs, and unlocked 17,600 free career interactions for underserved youth.

Compared to traditional coaching sessions averaging $350 per session, Rafiki AI has saved users an estimated $280,000 and provided over $767,300 in career guidance value. If users increase their income by just $300 as a result of improved career decisions, the potential collective income gain exceeds $3.1 million.

The impact has also extended offline: KLCI trained 27 school leaders who retrained 70 teachers, reaching 276 students directly. The organization has engaged 54 schools and organizations and trained 2,716 students on how to use Rafiki AI. For youth without smartphones, trained volunteers known as Rafiki AI Champions use their own devices to provide access so no one is excluded due to digital barriers.

Additionally, the AWS credits helped KLCI scale their Skill2Rural courseware platform, growing the educator base by 27.84% to 223 educators who now reach and mentor 128,600 young people in underserved communities.

“It is great to see a solution like Rafiki AI created for underserved and displaced young people get access to AWS cloud support and credits. It is giving growing organizations such as ours a chance to use AI to scale our work and democratize access to career service for young people on the African continent without access to career counselling services and guidance. With the support of AWS to launch Rafiki AI, we have given them something to believe in. This is the intersection of AI and career revolution right in front of us,” said Hammed Kayode Alabi, founder of KLCI Africa.

Conclusion

KLCI Africa’s partnership with AWS is a testament to the transformative power of generative AI in career development and youth empowerment. By building on AWS, KLCI is making personalized career guidance accessible to young people in underserved communities across Africa and beyond.

As the organization continues to innovate and expand, it remains dedicated to breaking barriers to career support and empowering youth to make informed decisions about their future.

With AI-driven solutions and strategic support through the AWS Education Equity Initiative, KLCI Africa is helping shape the future of inclusive, equitable career guidance for all.

Visit Rafiki AI to learn more about their impact.

Transforming Public Sector Procurement with Agentic AI on AWS

Gautam Chhawchharia — Tue, 28 Jul 2026 21:26:39 +0000

Public sector procurement is one of the most complex operational processes in government, but the technology supporting it hasn’t kept pace with its progress. Agencies manage dozens of systems built independently over decades, resulting in data silos, inconsistent portals, and excessive manual effort spent on document creation, compliance verification, and cross-referencing regulations.

Intelligent agents can now autonomously handle regulation-heavy tasks while maintaining human oversight at every decision point. This post explores how an agentic AI architecture on Amazon Web Services (AWS) modernizes the procurement lifecycle from solicitation to proposal evaluation while maintaining compliance with government regulations including United States of America FAR (Federal Acquisition Regulation), United States of America DFARS (Defense Federal Acquisition Regulation), and Canadian procurement frameworks (Public Service Procurement Canada (PSPC) /Shared Services Canada (SSC).

What is an agentic procurement solution?

An agentic procurement solution is a serverless, multi-agent AI platform where intelligent agents can reason, plan, and act autonomously within defined boundaries. Unlike rigid automation, agents seek information, make contextual decisions, and collaborate to complete complex workflows. Key outcomes include:

Automated solicitation generation through multi-stage, human-in-the-loop (HITL) workflows
AI-powered proposal evaluation with comparative and single-mode scoring
Retrieval Augmented Generation (RAG)– Department grounded responses eliminate hallucination through mandatory citation
Regulation-aware compliance considering FAR/DFARS and Canadian PSPC/SSC at every stage
Intelligent data discovery that connects to data wherever it resides on premises, in the cloud, or across external sources

Solution architecture: A four-layer serverless platform

The solution below shows how Amazon components and Agentic frameworks come together to solve a business requirement around Procurement

Figure 1: Agentic Procurement System Architecture Overview

Figure 1 illustrates the end-to-end architecture of the Agentic Procurement System across four purposefully designed layers as explained below:

Layer 1 (End User Facing Front End): Edge & Auth – Amazon CloudFront with AWS Shield for DDoS protection. Amazon Cognito JWT auth (zero anonymous access). Amazon API Gateway as the unified entry point.
Layer 2: Deep Agent Framework – Amazon Bedrock AgentCore manages agent lifecycle and routing through a Supervisor Agent to Stage Manager pattern. The Stage Manager injects role-tuned prompts, performs RAG grounding, and coordinates LLM generation.
Layer 3: Serverless Compute – AWS Lambda functions for chat, workflow coordination, compliance, document management, evaluation, and specialized agents. Scales to zero on idle.
Layer 4: Data & AI – Polyglot persistence within a more secure and private Amazon Virtual Private Cloud (Amazon VPC).

The table below describes the Amazon Service and how it is used within the solution:

Service	Role
Amazon Bedrock	LLM inference + Titan Embed v2 (1024-dim embeddings)
Amazon OpenSearch Serverless	HNSW vector index for semantic search
Amazon DynamoDB	Single-table design for all application state
Amazon Aurora Serverless v2	PostgreSQL for relational contract data
AWS Step Functions	Workflow orchestration
Amazon S3	Frontend hosting, knowledge base docs, exports, uploads

The entire platform spans 60+ API endpoints and operates fully serverless, enabling scaling while optimizing costs.

Multi-agent workflows: Human-in-the-loop by design

The following section describes how a deep / sub agent framework and agentic workflow is used with the RFx builder workflow. This workflow is used to create a comprehensive Request for Proposal type artifact.

RFx Builder: Six agentic workflow stages

The RFx Builder implements a six-stage workflow where the Supervisor Agent creates the RFP record and delegates each stage to the Stage Manager Agent for execution:

Requirements analysis – Analyzes mission needs, generates structured requirements
Market research – Researches relevant vendors, industry benchmarks, and competitive landscape
Technical criteria – Drafts evaluation criteria and technical requirements with industry-standard language
Legal and compliance framework – FAR/DFARS clauses are automatically identified and mapped. For U.S. Department of Housing and Urban Development (HUD) procurements, enforces Section 3 compliance floors, (National Environment Policy Act) NEPA screening gates, Davis-Bacon Act requirements, and appropriations-rider checks
RFP document assembly – Assembles all sections into a cohesive solicitation document with cross-references
Final review and export – Produces the finished document with full traceability and compliance certification

Each stage employs role-based AI personas. (For example, the Compliance Agent cites specific FAR parts; the Market Research Agent references historical contracts.) A procurement officer reviews, edits, and approves the requirements before advancement to next stage. The system is agency-aware: HUD procurements trigger specialized overlays for fair housing, Section 3, and HUD Acquistion Regulation (HUDAR) clause analysis.

The following section describes how a deep / sub agent framework and agentic workflow is used with the Evaluation builder workflow. This workflow is used to create a comprehensive evaluation for a single or multiple proposals received by the Agency.

Evaluation Builder: Five-stage assessment pipeline

The Evaluation Builder provides a structured, five-stage assessment pipeline that guides evaluators from initial criteria definition through final source selection. It combines AI-powered scoring with human oversight, agency-specific customization, and competitive intelligence via Model Context Protocol (MCP) servers to produce documented, defensible procurement decisions.

Evaluation setup and criteria – Define evaluation parameters, scoring methodology, and weighted factors (supports agency-specific preset criteria with adjectival rubrics)
Compliance check – Verify bidder proposals against mandatory requirements with pass/fail matrix. For HUD, auto-flag bidders missing Section 3 plans
Technical evaluation – AI-powered per-bidder scoring with adjectival ratings and rationale per factor, grounded in KB citations
Price and custom criteria – Cost realism analysis, custom scoring factors, and trade-off analysis with comparative and single-mode assessment
Final ranking and SSDD – Composite scoring and automated generation of the source selection decision document with full audit trail

The Scoring Agent supports score override with mandatory rationale capture. When a human evaluator disagrees with the AI’s assessment, the system requires a written rationale that becomes part of the permanent evaluation record. This satisfies requirements for documented, defensible source selection decisions. Competitive intelligence using Model Context Protocol (MCP) servers provides additional context for technology evaluations.

Agentic development on AWS: Framework flexibility

AWS provides flexibility for agentic development. The AWS Strands Agents SDK offers a cloud-based approach with built-in tool use, agent cards for capability discovery, and orchestration patterns. Organizations can equally use LangGraph, CrewAI, or AutoGen on AWS with Amazon Bedrock as the inference backbone. Key patterns include:

Agents as tools – Hierarchical delegation where specialized agents serve as callable tools for orchestrator agents
Workflows – Sequential handoffs preserve enriched context across stage boundaries
Swarms – Collaborative problem-solving through autonomous agent teams
Graph – Directed Acyclic Graph (DAG)-based deterministic control for complex compliance decision trees

RAG architecture: Helping maintain accuracy in regulated environments

A hallucinated regulatory reference could invalidate an acquisition. The RAG architecture implements strict anti-hallucination controls:

Retrieval-before-generation – Mandatory Knowledge Base (KB) retrieval before generation. If no relevant passages exceed the confidence threshold, the agent searches external sources or explicitly acknowledges the gap.
Citation enforcement – Inline regulatory clause citations with post-generation validation against the knowledge base.

Four specialized Amazon Bedrock Knowledge Bases maintain authoritative procurement information:

Knowledge Base	Content
Contract KB	Historical contract data, templates, and recommended practices
Policy KB	FAR, DFARS, HUDAR, Section 3, Davis-Bacon, Canadian PSPC/SSC
Product KB	Catalog information, pricing data, and market intelligence
Process KB	Workflow definitions, SOPs, and decision frameworks

Semantic search uses Titan Embed v2 (1024-dim vectors) on Amazon OpenSearch Serverless with Hierarchical Navigable Small World (HNSW) indexing. Automated ingestion pipelines continuously update the knowledge bases.

Intelligent data discovery: Meeting data where it lives

Seven connector types enable ingestion without requiring a pre-built data lake:

REST APIs – External government platforms and procurement databases
Amazon S3 – Cloud storage document ingestion
MCP – Cloud provider docs and external tools using Amazon Elastic Container Service (Amazon ECS) and AWS Fargate
ODBC – Traditional relational databases, including legacy on-premises systems
Databricks – Analytics platform integration
Snowflake – Data warehouse connectivity
Data lake – Existing data lake architectures

Amazon EventBridge schedules automated ingestion (extract – tag – deduplicate – chunk – sync). Agencies don’t need to consolidate data: Agents find it wherever it lives.

Security: Built for government standards

The solution is architected to meet government security standards through a defense-in-depth approach across network, identity, data, and infrastructure layers. It enforces zero trust networking, least-privilege access, encryption at rest, centralized secrets management, high availability, infrastructure as code, and DDoS protection to ensure a secure, auditable, and resilient operating environment.

Zero trust – No direct internet inbound to compute; Amazon VPC with private subnets and NAT Gateway for controlled outbound
IAM least privilege – Each AWS Lambda instance has a dedicated role with minimum required permissions
Encryption at rest – S3 SSE, Amazon DynamoDB encryption, and Amazon OpenSearch Service across all data stores
AWS Secrets Manager – Manages all credentials centrally; zero hardcoded secrets
Multi-Availability Zone – Active-active configuration across two Availability Zones for high availability
Infrastructure as Code – Full AWS CloudFormation templates (eight nested stacks) enabling repeatable, auditable deployments
DDoS protection – Amazon CloudFront with AWS Shield integration

Observability: Agent transparency at scale

OpenTelemetry (OTEL)-compatible instrumentation with Amazon SageMaker MLflow for experiment tracking:

Full trace capture – Inputs, outputs, tool invocations, and LLM calls using OTEL spans
Experiment tracking – Compare agent versions, model configurations, and prompt strategies through Amazon SageMaker with MLflow
GenAI evaluations – Safety, relevance, and fluency scoring using LLM-as-a-judge patterns
Drift monitoring – Detect when KB content or model behavior shifts from baselines
Reasoning trace – Structured records for audit trail agency resolution, overlay decisions, KB citations

Getting started

Identify high-volume workflows – Focus on repetitive tasks such as solicitation generation or proposal evaluation
Inventory existing data sources – Map data across on-premises, legacy, and cloud systems
Define governance boundaries – Establish agent autonomy limits and HITL approval gates
Start with a pilot – A single workflow stage demonstrates value while managing risk
Scale incrementally – Add agents, KB content, and connectors as confidence grows

Conclusion

By combining Amazon Bedrock foundation models with multi-agent orchestration on AWS, organizations can build intelligent ecosystems that reduce manual effort, improve compliance accuracy, and accelerate cycle times while maintaining the human oversight that mission-critical operations demand.

Data doesn’t need to be centralized in advance. Agents can find it wherever it lives through seven connector types. Compliance is embedded in every interaction through RAG-grounded, citation-required responses. Human judgment remains central; every workflow stage requires explicit approval before advancing. Structured reasoning traces provide full explainability and accountability.

While this post demonstrates the pattern through procurement, the same architecture applies to any regulation-heavy, document-intensive business process, such as healthcare claims, financial compliance, legal review, or supply chain management.

Learn more

Turn stored data into AI-ready insights with Amazon S3

Jeffrey Chen — Tue, 28 Jul 2026 21:24:29 +0000

Amazon Simple Storage Service (Amazon S3) ranks as one of the most widely used services in the Amazon Web Services (AWS) portfolio. Amazon S3 is the backbone of document archives, video catalogs, and data lakes. A question that we hear frequently is “We have all this data in S3 – now what?” AWS answered that question by expanding Amazon S3 with capabilities that help customers discover, structure, and build artificial intelligence (AI) ready pipelines.

In this post, we walk through three extended capabilities of Amazon S3: Amazon S3 Metadata, Amazon S3 Vectors, and Amazon S3 Tables and explore how each maps to real challenges government agencies face today.

Amazon S3 Metadata: Know what you have

What it is: Amazon S3 Metadata automatically generates and maintains queryable metadata for objects across your S3 buckets – including system-defined metadata, user-defined metadata, object tags, and annotations.

Why it matters: Keeping track of stored data becomes difficult at scale. S3 Metadata lets teams quickly search and filter by object attributes to find the data they need without the need to build custom inventory tooling.

Use Case: A state government needs to consolidate files from multiple departments into Amazon S3. Each department used different naming conventions, and many files were never tagged with retention categories. When the legislature requests a records retention audit, the IT team must manually sift through buckets or write custom scripts to identify non-compliant objects. With S3 Metadata, the team can easily tag and query their data by creation date, storage class, and department tag to produce a complete list of non-compliant objects.

Best practice: Choose the right metadata type for your need. System-defined metadata is generated automatically and useful for filtering by storage class or creation date. User-defined metadata is set at upload time for application-specific attributes. Object tags can be added or modified at any time making them ideal for retroactive classification and lifecycle policies. Annotations let you attach richer, structured metadata context. Once tagged, query with Amazon Athena to generate audit-ready reports. To get started, see Amazon S3 Metadata now supports metadata for all your S3 objects.

Amazon S3 Vectors: AI-ready search for the data you already have

What it is: Amazon S3 Vectors extends Amazon S3 with native vector storage and querying, purpose-built for semantic search and AI workloads. S3 Vectors handles billions of vectors at sub-second latency while cutting costs by up to 90% compared to standalone vector databases.

Why it matters: AI workloads with Retrieval-Augmented Generation (RAG) rely on vector databases to store embeddings (compact numerical representations) of your content. Traditional vector databases are costly and require maintenance whereas S3 Vectors provides a cost-effective and serverless way to power your RAG chatbot.

Use Case: A state unemployment agency handles thousands of calls per day, with questions spanning hundreds of pages of policy and eligibility guidance stored in Amazon S3. Caseworkers often need answers that cut across multiple documents. With S3 Vectors, the agency stores embeddings of its policy documents directly in S3. Paired with a large language model, those embeddings power a generative AI assistant that retrieves accurate answers in seconds rather than requiring caseworkers to search through dozens of PDFs manually.

Best practice: Pair S3 Vectors with Amazon Bedrock Knowledge Bases to create a RAG chatbot, which splits documents into passages, generates embeddings, and retrieves content for AI responses. To get started, see Building RAG applications with Bedrock Knowledge Bases and S3 Vectors.

Amazon S3 Tables: Structure your data without managing infrastructure

What it is: Amazon S3 Tables delivers managed Apache Iceberg tables that automate the operational burden of managing data lakes and lakehouses.

Why it matters: Agencies that build data lakes often find that upkeep becomes tedious and time-consuming as data grows. S3 Tables handles the operational burden automatically by continuously compacting small files into query-optimized objects, expiring old snapshots, and removing unreferenced files. Built-in Intelligent-Tiering further reduces storage costs by up to 80% by shifting data across access tiers as query patterns change, so teams can focus on delivering real business value rather than managing infrastructure.

Use Case: A metropolitan 911 center processes over a million emergency calls per year. Every call generates a record with the call type, location, priority level, unit dispatched, and response time. The public safety analytics team uses this data to find coverage gaps, position units more effectively, and track whether response times meet their targets. As years of call data accumulate, the team spends more time keeping the data queryable than analyzing it: merging thousands of small daily files so searches stay fast, cleaning up outdated copies, and fixing reports that slow down under growing data volumes. With S3 Tables, dispatch records flow into fully managed tables that handle all this housekeeping automatically. The team focuses entirely on the analysis that matters: closing coverage gaps and keeping response times on target.

Best practice: Integrate S3 Tables with Amazon Athena for on-demand SQL queries and Amazon QuickSight for self-service dashboards. This gives decision-makers direct access to current data without waiting on a data engineering team to prepare reports. To get started, see How to consume tabular data from Amazon S3 Tables for insights and business reporting.

Conclusion

Amazon S3 Metadata, Amazon S3 Vectors, and Amazon S3 Tables extend the service agencies already rely on into a platform that turns stored data into actionable insight. The result is less time spent on operational upkeep, faster access to the answers that drive decisions, and lower storage costs as data grows.

Ready to start? Pick the capability that matches your biggest challenge:

Amazon S3 Metadata eliminates manual inventory work by making every object discoverable through structured queries.
Amazon S3 Vectors removes the need to provision a separate database for AI-powered semantic search.
Amazon S3 Tables automates the maintenance that slows down analytics teams as data volumes scale, while reducing storage costs by up to 80%.

You can use all three today through the AWS Management Console, AWS CLI, and AWS SDKs. To learn more about how AWS supports state and local government agencies, visit AWS for State and Local Government.

Implementing per-user token guardrails for Amazon Bedrock in government agencies

Phillip Spies — Tue, 28 Jul 2026 21:08:19 +0000

A single developer experimenting with large context windows can consume thousands of dollars in Amazon Bedrock tokens within hours. For federal and state agencies accelerating generative AI adoption, per-user guardrails aren’t optional. They’re essential to maintain governance while enabling innovation at scale.

OMB M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust, directs agencies to accelerate AI adoption while maintaining appropriate governance and public trust. Innovation is the primary mandate, but agencies must pursue it responsibly.

Meanwhile, OMB M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, demands that agencies verify every actor and every access attempt. Together, these mandates create a combined expectation: Agencies should maintain visibility and control over how AI resources are consumed not just at the organizational level, but per individual user so adoption can accelerate without uncontrolled risk.

Without per-user guardrails, agencies face two compounding risks: unpredictable cloud spend from unconstrained token consumption, and governance gaps that fail audit requirements. A single automated pipeline with a runaway loop can exhaust thousands of dollars in tokens within hours.

This post presents two complementary patterns for implementing per-user token guardrails on Amazon Bedrock from Amazon Web Services (AWS):

Pattern 1: Claude Code (CLI/developer access) – Using Amazon CloudWatch logging, AWS Lambda, and Amazon DynamoDB to monitor and enforce limits on developer tool usage
Pattern 2: Application-level access – Using a centralized large language model (LLM) invocation class to track and enforce limits within custom applications

Both patterns share a common data model: a default token limit per model applied to all users, with per-user overrides for individuals requiring higher allocations. When a user reaches their daily limit, the system pauses access until the next calendar day.

Architecture overview

Both patterns converge on the same core design principles:

Default limits per model – Every model has a baseline daily token allocation that applies to all users
Per-user overrides – Specific users who require additional capacity receive a higher threshold
Daily enforcement – After a user exhausts their allocation, the system blocks access until the next day
Alerting – Notifications at 80% and 100% thresholds warn users and administrators
Auditability – Every invocation is logged with user identity, model, and token counts

Default and override limit strategy

The default limit per model establishes a baseline allocation that applies across the organization. This approach gives every user immediate access to AI capabilities on the first day without requiring individual provisioning. Agencies should set these defaults conservatively enough for typical daily workflows but low enough to prevent runaway consumption.

Per-user overrides accommodate the reality that different roles have different needs. A data scientist building training pipelines consumes far more tokens than an analyst running occasional summaries. The override mechanism means administrators can grant higher allocations to specific users or service accounts without raising the ceiling for everyone.

When determining initial limits, consider the following factors:

Model pricing tiers – Claude Sonnet tokens cost more than Claude Haiku; set lower token limits for expensive models
Role-based heuristics – Developers using Claude Code typically consume 50,000–200,000 tokens per day; application end users typically consume 5,000–20,000
Budget reverse-engineering – Divide your monthly AI budget by working days and active users to establish a sustainable per-user ceiling

Shared Amazon DynamoDB table design

The following table schema supports both patterns. The UserLimits table stores per-user override allocations, the DefaultLimits table stores organization-wide baselines per model, and the UsageLog table tracks daily consumption:

Table	Partition key	Sort key	Attributes
UserLimits	USER#<userId>	MODEL#<modelId>	dailyTokenLimit, isBlocked, lastReset
DefaultLimits	DEFAULT	MODEL#<modelId>	dailyTokenLimit
UsageLog	USER#<userId>	DATE#<date>#MODEL#<modelId>	inputTokens, outputTokens, totalTokens

Pattern 1: Claude Code guardrails

When developers use Claude Code (Anthropic’s CLI-based coding assistant, accessed through Amazon Bedrock), Amazon CloudWatch captures invocation logs. This pattern uses an Amazon CloudWatch subscription filter to trigger an AWS Lambda function that tracks usage and enforces limits in nearly real time.

How it works

Prerequisites

You must enable Amazon Bedrock model invocation logging (it’s disabled by default). After it’s enabled, each log entry automatically includes the identity.arn field (the IAM principal that made the request) alongside input.inputTokenCount and output.outputTokenCount. No custom instrumentation is required to attribute token usage to individual users.

Amazon Bedrock model invocation logging sends events to Amazon CloudWatch Logs
An Amazon CloudWatch subscription filter triggers a Lambda function on each invocation event
The Lambda function parses the log event to extract the user identity (IAM principal), model ID, and token counts (input + output)
Lambda queries Amazon DynamoDB for the user’s current daily usage and their limit (user-specific override or model default)
If the cumulative usage exceeds the limit, the function triggers enforcement
A scheduled daily Lambda function (or DynamoDB TTL) resets usage counters at midnight UTC

Because model invocation logs are delivered to Amazon CloudWatch asynchronously (typically within seconds), this pattern provides close to real-time enforcement. A user might complete one or two additional invocations between exceeding their limit and the deny policy taking effect. For applications requiring strictly synchronous enforcement, see Pattern 2, which checks limits inline before each Amazon Bedrock call.

Enforcement option A: IAM deny policy (hard block)

The Lambda function attaches an explicit deny policy to the user’s IAM role or user, preventing any further Amazon Bedrock InvokeModel calls. This is the strongest enforcement mechanism: The user receives an AccessDenied error on their next attempt.

Node.js Lambda handler (Option A)

const { DynamoDBClient, GetItemCommand, UpdateItemCommand } = require('@aws-sdk/client-dynamodb');
const { IAMClient, PutUserPolicyCommand, DeleteUserPolicyCommand } = require('@aws-sdk/client-iam');
const { SNSClient, PublishCommand } = require('@aws-sdk/client-sns');

const ddb = new DynamoDBClient({});
const iam = new IAMClient({});
const sns = new SNSClient({});

exports.handler = async (event) => {
  const logData = parseCloudWatchEvent(event);
  const { userId, modelId, inputTokens, outputTokens } = logData;
  const totalTokens = inputTokens + outputTokens;
  const today = new Date().toISOString().split('T')[0];

  // Get user limit (override or default)
  const limit = await getUserLimit(userId, modelId);

  // Increment daily usage
  const newTotal = await incrementUsage(userId, modelId, today, totalTokens);

  // Check thresholds
  if (newTotal >= limit) {
    await blockUser(userId);
    await notify(userId, modelId, 'BLOCKED', newTotal, limit);
  } else if (newTotal >= limit * 0.8) {
    await notify(userId, modelId, 'WARNING_80PCT', newTotal, limit);
  }
};

async function getUserLimit(userId, modelId) {
  // Check for user-specific override first
  const override = await ddb.send(new GetItemCommand({
    TableName: 'UserLimits',
    Key: { PK: { S: `USER#${userId}` }, SK: { S: `MODEL#${modelId}` } }
  }));
  if (override.Item?.dailyTokenLimit) return Number(override.Item.dailyTokenLimit.N);

  // Fall back to default limit for this model
  const defaults = await ddb.send(new GetItemCommand({
    TableName: 'UserLimits',
    Key: { PK: { S: 'DEFAULT' }, SK: { S: `MODEL#${modelId}` } }
  }));
  return Number(defaults.Item?.dailyTokenLimit?.N || 100000);
}

async function blockUser(userId) {
  const denyPolicy = JSON.stringify({
    Version: '2012-10-17',
    Statement: [{ Effect: 'Deny', Action: 'bedrock:InvokeModel*', Resource: '*' }]
  });
  await iam.send(new PutUserPolicyCommand({
    UserName: userId,
    PolicyName: 'BedrockTokenLimitDeny',
    PolicyDocument: denyPolicy
  }));
}

.NET Lambda handler (Option A)

public class TokenGuardrailFunction
{
    private readonly IAmazonDynamoDB _dynamoDb;
    private readonly IAmazonIdentityManagementService _iam;
    private readonly IAmazonSimpleNotificationService _sns;

    public async Task FunctionHandler(CloudWatchLogsEvent input, ILambdaContext ctx)
    {
        var logData = ParseCloudWatchEvent(input);
        var (userId, modelId, inputTokens, outputTokens) = logData;
        var totalTokens = inputTokens + outputTokens;
        var today = DateTime.UtcNow.ToString("yyyy-MM-dd");

        var limit = await GetUserLimit(userId, modelId);
        var newTotal = await IncrementUsage(userId, modelId, today, totalTokens);

        if (newTotal >= limit)
        {
            await BlockUser(userId);
            await Notify(userId, modelId, "BLOCKED", newTotal, limit);
        }
        else if (newTotal >= limit * 0.8)
            await Notify(userId, modelId, "WARNING_80PCT", newTotal, limit);
    }

    private async Task<long> GetUserLimit(string userId, string modelId)
    {
        var overrideReq = new GetItemRequest {
            TableName = "UserLimits",
            Key = new Dictionary<string, AttributeValue> {
                ["PK"] = new AttributeValue { S = $"USER#{userId}" },
                ["SK"] = new AttributeValue { S = $"MODEL#{modelId}" }
            }
        };
        var result = await _dynamoDb.GetItemAsync(overrideReq);
        if (result.Item.ContainsKey("dailyTokenLimit"))
            return long.Parse(result.Item["dailyTokenLimit"].N);

        // Fall back to default
        overrideReq.Key["PK"] = new AttributeValue { S = "DEFAULT" };
        var defaults = await _dynamoDb.GetItemAsync(overrideReq);
        return long.Parse(defaults.Item["dailyTokenLimit"].N);
    }

    private async Task BlockUser(string userId)
    {
        var denyPolicy = @"{ ""Version"":""2012-10-17"",
            ""Statement"":[{""Effect"":""Deny"",""Action"":""bedrock:InvokeModel*"",""Resource"":""*""}] }";
        await _iam.PutUserPolicyAsync(new PutUserPolicyRequest {
            UserName = userId,
            PolicyName = "BedrockTokenLimitDeny",
            PolicyDocument = denyPolicy
        });
    }
}

Enforcement option B: Gateway check (soft block)

For agencies preferring a less disruptive approach, the Lambda function sets a “blocked” flag in Amazon DynamoDB. A custom Amazon API Gateway authorizer or proxy layer checks this flag before forwarding requests to Amazon Bedrock. This provides a friendlier user experience with custom error messages and is more readily reversible.

Node.js gateway authorizer

const { DynamoDBClient, GetItemCommand } = require('@aws-sdk/client-dynamodb');
const ddb = new DynamoDBClient({});

exports.handler = async (event) => {
  const userId = event.requestContext.authorizer.claims.sub;
  const modelId = event.pathParameters.modelId;

  const result = await ddb.send(new GetItemCommand({
    TableName: 'UserLimits',
    Key: { PK: { S: `USER#${userId}` }, SK: { S: `MODEL#${modelId}` } }
  }));

  if (result.Item?.isBlocked?.BOOL) {
    return {
      statusCode: 429,
      body: JSON.stringify({
        error: 'TokenLimitExceeded',
        message: 'Daily token limit reached. Access resumes tomorrow.',
        resetTime: getNextMidnightUTC()
      })
    };
  }
  return { statusCode: 200, body: 'authorized' };
};

Daily reset function

A scheduled Lambda function (triggered using Amazon EventBridge at 00:00 UTC daily) resets blocked users:

exports.resetHandler = async () => {
  const blocked = await scanBlockedUsers();
  for (const user of blocked) {
    await iam.send(new DeleteUserPolicyCommand({
      UserName: user.userId, PolicyName: 'BedrockTokenLimitDeny'
    }));
    await resetUsageCounters(user.userId);
  }
  console.log(`Reset ${blocked.length} users`);
};

Comparing enforcement options

Both enforcement approaches are valid. The right choice depends on your agency’s operational requirements, risk tolerance, and user experience priorities.

Criteria	Option A: IAM deny policy	Option B: Gateway check
Enforcement strength	Hard block. AWS-level denial, can’t be bypassed by application code	Soft block. Enforced at the proxy layer; direct SDK calls bypass it
User experience	Generic AccessDenied error; requires user to understand IAM	Custom error message with reset time and remaining context
Reversibility	Requires IAM policy deletion. Slightly slower to unblock	Flip a DynamoDB flag. Instant unblock by admin
Latency impact	None. Enforcement is async after invocation	Adds approximately 10–50ms per request for the DynamoDB lookup
IAM permissions required	Lambda needs iam:PutUserPolicy and iam:DeleteUserPolicy	Lambda only needs dynamodb:UpdateItem
Coverage scope	Blocks all Amazon Bedrock access (CLI, SDK, console)	Only blocks requests routed through the gateway
Race condition risk	User might complete one to two additional calls before deny propagates	Minimal. Check happens synchronously before each call
Best suited for	High-security environments; compliance-driven agencies; Claude Code CLI users	User-facing applications; environments needing graceful degradation

For Claude Code (CLI) usage, option A provides more rigorous enforcement because developers have direct SDK access that could bypass a gateway. For application-level access (Pattern 2), a gateway check or in-application enforcement is typically sufficient and delivers a better end-user experience. Many agencies implement both: Option A as a backstop for developer tools and option B for user-facing applications.

Pattern 2: Application-level guardrails

For custom applications built on Amazon Bedrock (chatbots, document processors, code assistants), you implement enforcement within the application’s LLM service layer. A centralized invocation class wraps all Amazon Bedrock calls, performing pre-invocation limit checks and post-invocation usage recording.

How it works

The following steps describe the request lifecycle from user authentication through quota enforcement:

Application users authenticate using Amazon Cognito or your agency identity provider (IdP)
All Amazon Bedrock calls route through a centralized service class (never direct SDK calls from controllers)
Before each invocation, the service checks the user’s daily usage against their limit
If under the limit, the service invokes Amazon Bedrock and captures token counts from the response metadata
After invocation, the service records the interaction (user, model, tokens, timestamp) in the database
If over the limit, the service returns a structured quota-exceeded response to the frontend

Node.js — BedrockGuardrailService class

const { BedrockRuntimeClient, InvokeModelCommand } = require('@aws-sdk/client-bedrock-runtime');
const { DynamoDBClient, GetItemCommand, UpdateItemCommand } = require('@aws-sdk/client-dynamodb');
const { SNSClient, PublishCommand } = require('@aws-sdk/client-sns');

class BedrockGuardrailService {
  constructor() {
    this.bedrock = new BedrockRuntimeClient({});
    this.ddb = new DynamoDBClient({});
    this.sns = new SNSClient({});
  }

  async invoke(userId, modelId, payload) {
    const today = new Date().toISOString().split('T')[0];

    // Pre-invocation: check current usage against limit
    const { currentUsage, limit } = await this.getUsageAndLimit(userId, modelId, today);
    if (currentUsage >= limit) {
      return {
        success: false, error: 'TOKEN_LIMIT_EXCEEDED',
        message: 'Daily token limit reached. Access will resume tomorrow.',
        currentUsage, limit
      };
    }

    // Invoke Amazon Bedrock
    const response = await this.bedrock.send(new InvokeModelCommand({
      modelId, body: JSON.stringify(payload), contentType: 'application/json'
    }));
    const result = JSON.parse(new TextDecoder().decode(response.body));

    // Post-invocation: record usage
    const tokensUsed = result.usage.input_tokens + result.usage.output_tokens;
    const newTotal = await this.recordUsage(userId, modelId, today, tokensUsed);

    // Check alert thresholds
    if (newTotal >= limit * 0.8 && currentUsage < limit * 0.8) {
      await this.sendAlert(userId, modelId, newTotal, limit, 'WARNING_80PCT');
    }

    return { success: true, result, tokensUsed, remainingTokens: limit - newTotal };
  }

  async getUsageAndLimit(userId, modelId, date) {
    const [usage, userLimit, defaultLimit] = await Promise.all([
      this.ddb.send(new GetItemCommand({
        TableName: 'UsageLog',
        Key: { PK: { S: `USER#${userId}` }, SK: { S: `DATE#${date}#MODEL#${modelId}` } }
      })),
      this.ddb.send(new GetItemCommand({
        TableName: 'UserLimits',
        Key: { PK: { S: `USER#${userId}` }, SK: { S: `MODEL#${modelId}` } }
      })),
      this.ddb.send(new GetItemCommand({
        TableName: 'UserLimits',
        Key: { PK: { S: 'DEFAULT' }, SK: { S: `MODEL#${modelId}` } }
      }))
    ]);
    return {
      currentUsage: Number(usage.Item?.totalTokens?.N || 0),
      limit: Number(userLimit.Item?.dailyTokenLimit?.N || defaultLimit.Item?.dailyTokenLimit?.N || 100000)
    };
  }

  async recordUsage(userId, modelId, date, tokens) {
    const result = await this.ddb.send(new UpdateItemCommand({
      TableName: 'UsageLog',
      Key: { PK: { S: `USER#${userId}` }, SK: { S: `DATE#${date}#MODEL#${modelId}` } },
      UpdateExpression: 'ADD totalTokens :t',
      ExpressionAttributeValues: { ':t': { N: String(tokens) } },
      ReturnValues: 'ALL_NEW'
    }));
    return Number(result.Attributes.totalTokens.N);
  }
}

module.exports = { BedrockGuardrailService };

.NET — BedrockGuardrailClient class

public class BedrockGuardrailClient
{
    private readonly IAmazonBedrockRuntime _bedrock;
    private readonly IAmazonDynamoDB _dynamoDb;
    private readonly IAmazonSimpleNotificationService _sns;
    private readonly ILogger<BedrockGuardrailClient> _logger;

    public BedrockGuardrailClient(
        IAmazonBedrockRuntime bedrock,
        IAmazonDynamoDB dynamoDb,
        IAmazonSimpleNotificationService sns,
        ILogger<BedrockGuardrailClient> logger)
    {
        _bedrock = bedrock; _dynamoDb = dynamoDb;
        _sns = sns; _logger = logger;
    }

    public async Task<InvokeResult> InvokeWithGuardrails(
        string userId, string modelId, string payload)
    {
        var today = DateTime.UtcNow.ToString("yyyy-MM-dd");
        var (currentUsage, limit) = await GetUsageAndLimit(userId, modelId, today);

        if (currentUsage >= limit)
            return InvokeResult.LimitExceeded(currentUsage, limit);

        var response = await _bedrock.InvokeModelAsync(new InvokeModelRequest
        {
            ModelId = modelId,
            Body = new MemoryStream(Encoding.UTF8.GetBytes(payload)),
            ContentType = "application/json"
        });

        var result = JsonSerializer.Deserialize<BedrockResponse>(response.Body);
        var tokensUsed = result.Usage.InputTokens + result.Usage.OutputTokens;
        var newTotal = await RecordUsage(userId, modelId, today, tokensUsed);

        if (newTotal >= limit * 0.8 && currentUsage < limit * 0.8)
            await SendAlert(userId, modelId, newTotal, limit);

        return InvokeResult.Success(result, tokensUsed, limit - newTotal);
    }
}

.NET dependency injection registration

// Program.cs or Startup.cs
builder.Services.AddSingleton<IAmazonBedrockRuntime>(new AmazonBedrockRuntimeClient());
builder.Services.AddSingleton<IAmazonDynamoDB>(new AmazonDynamoDBClient());
builder.Services.AddSingleton<IAmazonSimpleNotificationService>(
    new AmazonSimpleNotificationServiceClient());
builder.Services.AddSingleton<BedrockGuardrailClient>();

Usage alerts and notifications

Both patterns include a notification layer that alerts users and administrators when usage thresholds are approached or exceeded. Amazon Simple Notification Service (Amazon SNS) delivers alerts to email, SMS, or agency messaging platforms.

Alert thresholds

The system supports configurable alert levels that trigger notifications at key consumption milestones:

80% threshold – Warning notification sent to the user: “You have consumed 80% of your daily token allocation for [model]. Consider conserving usage for critical tasks.”
100% threshold – Block notification sent to the user and their administrator: “Daily token limit reached. Access to [model] is paused until [reset time].”
Custom thresholds – Agencies can define additional intermediate alerts (for example, 50% for high-visibility projects)

Node.js alert function

async function sendAlert(userId, modelId, currentUsage, limit, alertType) {
  const percentage = Math.round((currentUsage / limit) * 100);
  const message = alertType === 'BLOCKED'
    ? `User ${userId} has reached their daily limit for ${modelId}. Access paused.`
    : `User ${userId} has consumed ${percentage}% of their daily limit for ${modelId}.`;

  await sns.send(new PublishCommand({
    TopicArn: process.env.ALERT_TOPIC_ARN,
    Subject: `Bedrock Token Alert: ${alertType}`,
    Message: JSON.stringify({ userId, modelId, currentUsage, limit, percentage, alertType }),
    MessageAttributes: {
      alertType: { DataType: 'String', StringValue: alertType },
      userId: { DataType: 'String', StringValue: userId }
    }
  }));
}

Admin visibility and dashboard

Governance requires not just enforcement but transparency. Administrators need a real-time view of token consumption across their agency by user, model, and time period.

Key dashboard views

A governance dashboard should provide the following views to support cost management and usage oversight:

Agency-wide daily consumption – Total tokens consumed across all models, trended over time
Per-user leaderboard – Top consumers ranked by daily, weekly, and monthly usage
Model breakdown – Usage distribution across Claude Sonnet, Claude Haiku, and other models
Limit utilization – How close each user is to their daily cap (highlighting those at 80% or above)
Cost projection – Estimated monthly cost based on current consumption patterns

Amazon DynamoDB query patterns

The UsageLog table supports efficient queries for dashboard data:

// Query all usage for a specific date (using a GSI on date)
const params = {
  TableName: 'UsageLog',
  IndexName: 'DateIndex',
  KeyConditionExpression: '#d = :date',
  ExpressionAttributeNames: { '#d': 'usageDate' },
  ExpressionAttributeValues: { ':date': { S: '2026-06-19' } } // Example date
};

// Query a specific user's usage history
const userHistory = {
  TableName: 'UsageLog',
  KeyConditionExpression: 'PK = :pk AND begins_with(SK, :prefix)',
  ExpressionAttributeValues: {
    ':pk': { S: 'USER#jsmith' },
    ':prefix': { S: 'DATE#2026-06' }  // All of June 2026
  }
};

For production dashboards, consider streaming Amazon DynamoDB data to Amazon QuickSight using Amazon DynamoDB Streams and Amazon Data Firehose, or using Amazon Athena to query exported data in Amazon Simple Storage Service (Amazon S3).

Security considerations

When implementing token guardrails, agencies should address the following security dimensions to maintain alignment with their authorization to operate and Federal Risk and Authorization Management Program (FedRAMP) requirements:

Least privilege – The Lambda enforcement function requires IAM permissions to attach deny policies and write to Amazon DynamoDB, but shouldn’t have broader administrative access. Scope its execution role tightly to the specific resources it manages.
Tamper resistance – Users shouldn’t be able to modify their own limit records in Amazon DynamoDB. Use IAM resource-based policies to restrict write access to the limits table exclusively to the enforcement Lambda function and authorized administrators.
Audit trail – Enable Amazon DynamoDB Streams on the UserLimits table to capture all modifications to limit values. Stream these changes to Amazon CloudWatch Logs or AWS CloudTrail Lake for compliance auditing.
Encryption – Enable encryption at rest on all Amazon DynamoDB tables using AWS Key Management Service (AWS KMS) customer-managed keys, and enforce TLS 1.2+ for all API communications.
Multi-account strategy – In organizations using AWS Organizations with multiple accounts, deploy the enforcement infrastructure in a centralized security account and use cross-account IAM roles to apply deny policies in workload accounts.

Conclusion

Implementing per-user token guardrails for Amazon Bedrock addresses both the governance mandates from OMB and the practical need for predictable AI spend. The two patterns presented here cover the full spectrum of agency AI usage:

Pattern 1 (Claude Code) – Monitors developer CLI usage using Amazon CloudWatch and enforces limits through IAM deny policies or gateway checks
Pattern 2 (Application-level) – Embeds enforcement directly in the application’s LLM service layer, providing immediate feedback to end users

Both approaches share a common Amazon DynamoDB data model with default limits per model and per-user overrides, making administration straightforward. Combined with proactive alerting and administrative dashboards, agencies gain complete visibility and control over their generative AI consumption.

By implementing these guardrails, agencies demonstrate compliance with OMB AI governance requirements while making certain that AI adoption remains sustainable and fiscally responsible. The patterns are modular: Start with one, add the other as your AI footprint grows.

The 1000 Genomes Project, reanalyzed: A new analytical baseline for human genomics

Eric Allen — Mon, 27 Jul 2026 21:45:13 +0000

The Illumina bioinformatics team reanalyzed the 1000 Genomes Project to establish a new analytical baseline for common human genetic variation. Thousands of studies benchmark against the original 1000 Genomes Project call set. Population frequency estimates used in genome-wide association studies (GWAS) and variant interpretation databases derive from it. It is, in many ways, the cohort the global genomics community trusts most.

The original baseline predates recent advances in structural variant detection, repeat expansion analysis, pangenome references, and pharmacogenomic characterization. The analytical frontier advanced dramatically, but the original 1000 Genomes Project call sets weren’t updated alongside it. The gap between what modern pipelines can detect and what the original 1000 Genomes Project calls contain has become a limiting factor for labs validating new methods.

This reanalysis removes that ceiling. We used Illumina DRAGEN (Dynamic Read Analysis for GENomics) on Amazon Elastic Compute Cloud (Amazon EC2) F2 instances to reanalyze the entire 1000 Genomes Project high-coverage cohort (3,202 whole genomes including 602 trios) across five major DRAGEN versions (3.5, 3.7, 4.0, 4.2, and 4.4), producing consistent calls across every major variant class from a single pipeline run. DRAGEN 4.4 anchors analysis against a pangenome reference, demonstrating pangenome-based variant calling at population scale on a globally representative cohort.

You can access the results on the Registry of Open Data on AWS at no cost. No Amazon Web Services (AWS) account is required, and there are no egress fees.

In this post, you can learn what distinguishes this reanalyzed dataset from prior 1000 Genomes Project call sets, how to access the data, and how to explore it using both bioinformatics tools and a natural-language query interface built on Amazon Bedrock.

Key differentiators of this reanalysis

This is not a newer pipeline applied to the same data. Rather, we reprocessed the data using a wider set of current methods, distinguishing it from any prior 1000 Genomes Project call set.

DRAGEN v4.4.7 calls single nucleotide variants (SNVs), indels, copy number variants (CNVs), structural variants (SVs), short tandem repeats (STRs), and human leukocyte antigen (HLA) types from a single integrated pipeline. Targeted callers additionally characterize pharmacogenomically complex genes, such as CYP2D6, CYP2B6, GBA, SMN, HBA, LPA, RH, and CYP21A2, in the same run. A single integrated pipeline eliminates the need for tool-stitching or reconciliation across independent callers: one pipeline, one reference framework, one quality model.

DRAGEN 4.4 incorporates a second-generation multigenome mapper with an expanded pangenome reference containing samples from diverse ancestries. Combined with machine learning (ML)-based variant recalibration, this reduces reference bias for non-European populations (a known limitation of linear reference alignment). It also supports more accurate structural variant detection in regions of high population-specific diversity. Applied to the 1000 Genomes Project 3,202 genome cohort (26 populations across 5 superpopulations), this represents a landmark demonstration of pangenome-based calling on a diverse, well-characterized cohort.

The Registry of Open Data on AWS hosts DRAGEN call sets from versions 3.5, 3.7, 4.0, 4.2, and 4.4. All are applied to the same 3,202 genomes. You can track algorithmic improvements across DRAGEN generations on identical inputs, validate methods against multiple analytical baselines simultaneously, and quantify the impact of specific advances (such as the pangenome introduction in 4.4) on variant sensitivity and specificity.

Performance

The combination of DRAGEN v4.4 with EC2 F2 instances delivers a fundamental shift in what is economically feasible at population scale. According to benchmarks published in the AWS HPC Blog, DRAGEN v4.4 on EC2 F2 instances (f2.6xlarge) achieves significant improvements.

Full WGS analysis, including mapping, variant calling, CNV, SV, STR, HLA, and targeted callers was two times faster than previous-generation F1 instances at 30% of the Amazon EC2 compute cost. Basic WGS analysis, including mapping and small variant calling only, was 1.5 times faster at 40% of cost.

These economics matter beyond this project. At 30% of previous cloud compute cost, population-scale reanalysis moves from being accessible only to large consortia to being fundable by academic groups and smaller research programs.

Joint genotyping: Cohort-level analysis with DRAGEN IGG

Beyond per-sample variant calling, we performed variant aggregation and filtering using the DRAGEN Iterative Genomic Variant Call Format (gVCF) Genotyper (IGG) v4.4.7. IGG genotypes large collections of germline gVCFs from unrelated samples, producing a single normalized multisample VCF containing all variants and genotypes observed across the cohort.

The iterative workflow supports efficient cohort updates without reprocessing all input data, making it well-suited for evolving reference resources. The resulting joint-called VCF provides a standardized, analysis-ready resource compatible with downstream workflows including GWAS, population stratification, and variant annotation.

You can directly compare allele frequencies across the five 1000 Genomes Project superpopulations or integrate the data with other cohorts without additional harmonization. For the 602 trio families in the cohort, additional pedigree analyses enabled joint small variant genotyping along with variant detection for both CNVs and structural variants.

Accessing the data

The complete reanalysis is publicly available on Amazon Simple Storage Service (Amazon S3) through the Registry of Open Data dataset at 1000 Genomes Phase 3 Reanalysis with DRAGEN 3.5, 3.7, 4.0, 4.2, and 4.4. The dataset includes high-quality variant calls for all variant classes (VCF format), aligned CRAM files, quality metrics and annotations for downstream analysis, and cohort-level joint-called VCFs from DRAGEN IGG.

To access the reanalysis without an AWS account, use the command line interface (CLI):

aws s3 ls s3://1000genomes-dragen-v4-4-7/ --no-sign-request

If you have an AWS account, you can access the reanalysis by signing in on the Amazon S3 console.

No egress fees apply for public access. Complete dataset documentation, usage examples, and technical specifications are available on the 1000 Genomes Phase 3 Reanalysis with DRAGEN page on the Registry of Open Data.

Exploratory analysis: From variant calls to population insights

Researchers can use Illumina Connected Analytics (ICA) Bench and Jupyter notebooks to explore how the reprocessed cohort supports sophisticated downstream analysis. The following examples demonstrate population-level analyses, with visualizations shown in the following graphs.

The first graph, a scatterplot, shows principal component analysis (PCA) of the 1000 Genomes Project population dataset PCA clustering with GIAB samples excluded. This analysis confirms expected population clustering across the 1000 Genomes Project superpopulations.

Figure 1: PCA clustering of 1000 Genomes dataset

The following bar graph shows that loss-of-function (LOF) and missense mutations appear more often at lower allele frequencies, whereas splice region and synonymous mutations appear more at higher allele frequencies. This pattern is consistent with purifying selection acting on deleterious variants.

Figure 2: Variant consequence by allele frequency

These Jupyter notebooks provide reproducible starting points for researchers conducting their own population-scale analyses. The notebook files are packaged as an ICA bundle named “1kg_jupyter_notebooks v1.0,” available to any ICA user with a subscription in the US ICA region. There is no additional cost beyond an ICA Basic subscription.

ICA bundles can’t be shared using a direct external link. To find it, on the Bundles console, choose Bundles in the left navigation pane and the Entitled Bundles tab, then link it to your project. Refer to the ICA Bundles documentation for detailed instructions on ICA Bundle access and usage.

Natural language querying

For researchers who need answers from this data without pipeline infrastructure, we developed an open source conversational agent using the Strands Agents SDK with Amazon Bedrock for model inference.

The workflow ingests per-sample VCFs and Illumina Connected Annotations into Amazon S3 Tables in Apache Iceberg format. Amazon Athena provides SQL access across the entire cohort. The conversational agent translates natural-language questions into SQL, executes queries, and returns results such as the following:

“Which samples carry a heterozygous variant in BRCA2?” returns sample IDs, genotypes, and population labels.
“Show me pathogenic variants on chromosome 17 with gnomAD frequency below 1%” returns matching variants with ClinVar annotations.
“What are the top 10 highest REVEL score variants in cancer-related genes? Only show the 5 most useful columns” returns the resulting SQL query and the query results in a tabular format, as shown in the following screenshot.

Figure 3: The conversational agent returns the top 10 highest REVEL score variants in cancer-related genes, demonstrating natural-language SQL query generation

This interface reduces friction for researchers who need population frequency data to inform research design but lack command line expertise. The open source code is available at sample-bedrock-variant-query-agent on GitHub.

The following diagram is the solution architecture. Key components shown in the diagram include the VCF data loader and annotations parser, data loading of the parsed data into Amazon S3 Tables, usage of AWS Glue and Amazon Athena to enable querying, and Amazon Bedrock for the AI chat capabilities.

Figure 4: Architecture of the Amazon Bedrock variant query agent

Conclusion

This reanalysis is not the endpoint; it’s infrastructure that supports ongoing work across multiple research domains:

For bioinformaticians and method developers – Five pipeline versions were applied to the same 3,202 genomes, in one bucket. You can track algorithmic evolution, validate methods against multiple baselines, and benchmark against pangenome-anchored calls on the cohort that the field already uses as ground truth.
For population geneticists – Pangenome-anchored calls reduce reference bias in non-European populations. Full variant-class coverage supports structural variant and STR analyses that earlier call sets can’t provide.
For translational researchers – The updated results are an analytically current reference for population frequency estimation, variant interpretation, and method validation, accessible in standard formats with no barriers.
For the field – This reanalysis lifts the ceiling. The baseline now reflects current methods. The infrastructure is openly accessible.

Explore the dataset today in the Registry of Open Data on AWS and try the ICA Bench example population analysis scripts and the conversational Amazon Bedrock agent example in the sample-bedrock-variant-query-agent GitHub repository.

For full technical details on DRAGEN v4.4.7 pipelines, parameters, and benchmarking results, refer to the DRAGEN v4.4 User Guide. Whether you’re conducting population genetics research or validating a new analysis method, this dataset and the surrounding tooling provide a strong foundation to accelerate your work.

For more info about DRAGEN on AWS, visit DRAGEN Complete Suite in AWS Marketplace, view the DRAGEN v4.4 blog, or visit Illumina’s Informatics products home page.

The information in this post is for research use only and not to be used in diagnostic procedures.

The authors would like to thank Trevor Cousins (Illumina) who helped with the exploratory analysis in Illumina Connected Analytics.

Accelerating geospatial work with Kiro: One AI interface for the geo stack

Chris Stoner — Mon, 27 Jul 2026 00:51:08 +0000

Geospatial practitioners face a double integration tax. A single question such as, “How has vegetation changed around this watershed over the last 2 years, and where should we focus field work?”, can require coordinating half a dozen tools, each with its own API, data format, coordinate reference system (CRS) conventions, and rate limits, before a single analytical result emerges.

Worse, the fragmentation is two-sided. In most domains, the integration problem is mostly about data access. In geospatial work, processing and compute are as fragmented as the data. The catalog that lists the imagery doesn’t reproject it, the library that reprojects it doesn’t run band math, and neither of them scale a job across a cluster when the area of interest grows. Researchers either juggle a dozen desktop tools and browser tabs or write integration scripts that require maintenance when APIs or projection assumptions change.

This post introduces the Geospatial Power Pack, a Kiro power package that turns Kiro into a unified, AI-assisted geospatial workspace. Kiro is an agentic development environment created by Amazon Web Services (AWS). It helps developers and teams turn prompts into executable specs, validate code correctness to find bugs that unit tests miss, and build across large codebases with parallel agents that learn from every session. Users ask questions in natural language, and Kiro pulls data directly from authoritative sources, such as Registry of Open Data on AWS, and reads it in place rather than downloading, running real geospatial operations in the same environment the user writes code.

Now, you can use datasets from National Aeronautics and Space Administration (NASA), such as Surface Water and Ocean Topography (SWOT), and from United States Geological Survey (USGS), such as USGS Landsat, from the Registry of Open Data using Kiro with the Geospatial Powerpack.

Fragmentation slows the work on both sides

Consider an analyst assessing post-wildfire vegetation recovery. Today they might need to:

Find pre- and post-fire Sentinel-2 scenes across SpatioTemporal Asset Catalogs (STAC).
Pull the fire perimeters and infrastructure as vector features, reproject to a common CRS.
Read relevant bands from Cloud-Optimized GeoTIFF (COGs), compute burn-severity index (NBR), and difference the dates.
Summarize severity by management unit (zonal statistics).
Run a foundation model (FM) change-detection pass and scale out when the AOI spans a region.

That’s five categories of work spanning multiple tools, coordinate systems, file formats, and scaling regimes—for a single analysis. Multiply it across every site and project, and the cognitive overhead adds up fast.

Solution overview: The Geospatial Power Pack

The pack combines Kiro powers with modular Model Context Protocol (MCP) servers. A central power, kiro-geospatial, acts as the hub, providing an onboarding dashboard, a searchable resource catalog, a credential manager, domain skills, and guided workflows. Nineteen standalone MCP servers exposing 46 tools handle the actual work, each independently installable and configurable, plus a peer power for distributed compute on AWS.

The design is guided by a few key decisions:

Dual fragmentation, equal weight – Data access (discover and read) and processing and compute (transform and analyze) are treated as co-equal problems. By design, the pack ships at least as many processing and compute servers as data servers, with a third pillar dedicated to geospatial artificial intelligence (GeoAI).
Modular by design – Install only the servers you need using uvx. A team doing imagery analytics doesn’t have to install the point-cloud or biodiversity servers. Each server is a standalone Python package, and installing one pulls in only the shared base.
Single credential surface – Configure keys one time in mcp.json, each flagged as required, optional, or license-needed. Secret values never appear in any status report, error, or log.
Orchestrated discovery, processing, and analysis – Ask one question and the hub’s orchestration router fans it across multiple sources and tools in parallel, always in pillar order, with graceful degradation when a source fails.
Open data first – The default discovery and GeoAI paths read open, credential-free datasets from the Registry of Open Data on AWS, such as Sentinel-2 Cloud Optimized GeoTIFFs using the Earth Search STAC API, LGND Clay v1.5 embeddings over anonymous Amazon Simple Storage Service (Amazon S3), so a new user gets a working pipeline with nothing to license or configure.

Coverage at a glance

The pack organizes capabilities into three pillars plus credentialed and peer servers.

Pillar	Servers	What it covers
Data connectors	geo-stac, geo-vector, geo-geocode-route, geo-terrain, geo-weather-climate, geo-biodiversity, geo-ogc	Imagery and catalog search (STAC, federated multi-catalog), OpenStreetMap or Overture vector features, geocoding and routing, terrain and elevation, weather and climate, species occurrences, generic OGC API – Features
Processing and compute	geo-ops, geo-formats, geo-query, geo-raster, geo-pointcloud, geo-index, geo-3d	Coordinate reference system (CRS) transforms, geometry ops and overlays, COG or GeoParquet conversion, in-process spatial SQL (DuckDB) and Amazon Athena, windowed COG reads and band math, zonal statistics, point clouds (COPC), H3 or S2 indexing, 3D Tiles, and glTF
GeoAI	geo-foundation-models, geo-embedding-search	FM embeddings, segmentation, and change detection. On-tile embedding and segmentation use deterministic local stand-in backends for Clay, Prithvi-EO-2.0, SatCLIP, or SAMGeo (pluggable for real weights), whereas real published Clay v1.5 vectors are retrieved using lookup_embeddings; embedding store and similarity search (Amazon OpenSearch Service, LanceDB)
Credentialed	geo-warehouse, geo-commercial-imagery	Warehouse-scale spatial SQL (Amazon Redshift); commercial imagery search and ordering (Maxar using Sentinel Hub, Planet)
Peer power	aws-geo-compute	Engine selection and job submit or status across AWS Batch, Amazon Elastic Container Store (Amazon ECS) with AWS Fargate, Amazon EMR with Apache Sedona, and Amazon SageMaker AI

In total, that’s 21 packages—the hub, the geo-common shared base, and 19 MCP servers exposing 46 tools across open, free-tier, and proprietary sources.

How it works

The interface is built to answer a single question by coordinating multiple sources and operations. A researcher might ask Kiro:

Find the two least-cloudy Sentinel-2 scenes over this area of interest from before and after the fire, compute the burn-severity difference, and summarize it by the parcels in this GeoJSON.

Kiro discovers the scenes across STAC catalogs, reads only the bands it needs directly from Amazon S3, computes the index, and rolls the result up by zone, with no scripting, no tab switching, and no manual reprojection.

Orchestration with graceful degradation

A single natural-language request flows strictly in pillar order: every discover step precedes every process step, which precedes every analyze step. Discovery sources are queried concurrently; if one source fails, the router records that in the provenance, labels the result partial, and keeps going rather than failing the whole request.

Federated STAC search is a good example. stac_search_multi queries multiple catalogs at once—Earth Search, CMR-STAC, Copernicus, and USGS—and round-robin merges the results so every responding catalog is represented rather than the first one filling the quota. It also collapses the same physical scene served by multiple catalogs under different ID schemes, with per-endpoint provenance for every result.

Guided multistep workflows

The pack includes steering workflows: executable, step-by-step guides that activate based on your workspace file patterns. They cover end-to-end pipelines such as COG conversion, STAC discover-and-analyze, zonal statistics, geocode-and-route, and embedding-based change detection. These aren’t documentation pages—they’re guides Kiro follows step by step, calling the right tools in the right order.

Domain skills with encoded best practices

Skills provide contextual guidance that activates based on what you’re working on—cloud-optimized format conventions (COG, GeoParquet, Zarr, or COPC), coordinate-reference handling, and the discovery, processing, and analysis pattern. When you’re converting rasters or wrangling projections, Kiro already knows the conventions.

Walkthrough: Sentinel-2 and Clay embeddings from the Registry of Open Data on AWS

Here’s a concrete, credential-free walkthrough built entirely on two Registry of Open Data on AWS datasets—Sentinel-2 Cloud-Optimized GeoTIFFs and the LGND Clay v1.5 Sentinel-2 embeddings. Imagine you want to characterize vegetation around an area of interest (AOI) and find other places that look like it.

Discover (Sentinel-2, open) – Ask, Find the least-cloudy Sentinel-2 L2A scene over this AOI from June 2024. Kiro queries the open Earth Search STAC API (maintained by Element 84) for the sentinel-2-l2a collection and returns matching items with their COG asset hrefs and eo:cloud_cover. This requires no account or key.
Read in place (COGs on Amazon S3, open) – Ask, Read the red and NIR bands for my AOI and compute NDVI. Kiro reads only the byte ranges it needs for the AOI window directly from the sentinel-cogs bucket, which is in the US West (Oregon) – us-west-2 AWS Region, using geo-raster, then runs the (normalized difference vegetation index) NDVI band math. No scene is downloaded whole; the read is scoped to the pixels in the window.
Retrieve embeddings (LGND Clay v1.5, open) – Ask, Pull the published Clay v1.5 embeddings for this same AOI. Kiro calls geo-foundation-models lookup_embeddings, which fetches real 1024-dimensional Clay v1.5 vectors for the AOI from the LGND dataset on Source Cooperative’s anonymous Amazon S3 mirror (us-west-2.opendata.source.coop, CC-BY 4.0). The dataset publishes an aggregated product (one representative embedding per MajorTOM grid cell per month) and a per-scene product, currently for June 2024 and June 2025. The bounding box (bbox) area and result count are bounded so a single call returns a small, consumable set.
Search by similarity (open vector store) – Ask, Index these embeddings and find the most similar cells in my collection. Kiro loads the retrieved vectors into geo-embedding-search (LanceDB locally or Amazon OpenSearch Service) and runs a nearest-neighbor query, surfacing other locations whose Clay embeddings are closest to the AOI—semantic “find more like this” over open data.

Each of these steps runs against open, credential-free data. There are two practical notes the pack encodes directly. The Clay embedding files are large single-row-group GeoParquet, so the embedding retrieval is best run in US West (Oregon) – us-west-2 or as a batch ingest into the vector store—remote interactive calls are best-effort. And because the on-tile embed_tile path ships a deterministic local stand-in (not real model weights), use lookup_embeddings when you need real Clay v1.5 vectors; each embedding result carries a backend field that records which produced it, so the two are never silently mixed.

This is the pattern the Registry of Open Data on AWS is built for: discovery, cloud-optimized reads, and now FM embeddings, all over sponsored open datasets, with the AWS “bring compute to the data” path (aws-geo-compute) ready when an AOI grows past what fits in-process.

Data credits

This walkthrough uses the Sentinel-2 Cloud-Optimized GeoTIFFs on the Registry of Open Data on AWS (and contains modified Copernicus Sentinel data) and the LGND Clay v1.5 Sentinel-2 embeddings (Source Cooperative, CC-BY 4.0). OpenStreetMap-derived features are © OpenStreetMap contributors (ODbL).

What makes this different

Desktop geographic information system (GIS) tools are powerful but keep you in a point-and-click loop that’s hard to reproduce or automate, and they don’t reach cleanly into cloud-optimized catalogs and object storage.

Library stacks like GDAL, rasterio, shapely, and pyproj give you programmatic control but require writing and maintaining integration code for every catalog, projection, and format—exactly the part that breaks. The pack handles the API calls, byte-range reads, error handling, and rate limiting so you can focus on the analysis rather than the infrastructure.

Generic AI assistants can discuss geospatial concepts, but they can’t run a live STAC query, reproject a geometry, or compute a real zonal statistic. The Geospatial Power Pack makes authenticated, structured calls and runs actual geospatial operations that return machine-readable results, providing real data rather than summaries from a training corpus.

Architecture for geospatial engineers

Each MCP server is a standalone Python package built on a shared geo-common base that provides one async HTTP client (built on httpx) with retry and exponential backoff, a common error taxonomy, rate-limit handling, and the BaseGeoServer contract every server inherits. Behavior is consistent across every domain because it’s implemented one time.

Servers run using uvx—no Docker or infrastructure to manage. A machine-readable bundle manifest declares every server, skill, and steering workflow, so it’s straightforward to check status and configure a setup. Property-based testing with Hypothesis backs the logic-bearing components, giving confidence the tools behave correctly on unexpected inputs.

Two principles run through the architecture. It’s cloud-optimized by default, meaning that the pack reads COG byte ranges, GeoParquet, Zarr, and COPC directly rather than downloading whole files. And it follows the principle of bringing the compute to the data—read only the byte ranges you need from Amazon S3, and delegate heavy or distributed jobs to aws-geo-compute, which maps a task type to the right execution target across AWS Batch, AWS Fargate, Amazon EMR with Apache Sedona, and Amazon SageMaker AI.

The result spans roles. Analysts retire wrapper scripts and let Kiro handle the integration layer. GIS engineers cross-reference data sources and run processing in one conversation instead of stitching together half a dozen tools. Teams work from the same declarative tooling, which cuts down the reproducibility problem that comes with mismatched local GIS installs.

Getting started

Install the shared base and the hub, add the servers you want, register them in mcp.json, and start asking questions. The onboarding dashboard shows what’s available, what needs credentials, and what’s ready to use.

The following is a minimal mcp.json for a working discovery, processing, and analysis pipeline:

{
  "mcpServers": {
    "geo-stac":   { "command": "/abs/path/.venv/bin/geo-stac" },
    "geo-vector": { "command": "/abs/path/.venv/bin/geo-vector" },
    "geo-ops":    { "command": "/abs/path/.venv/bin/geo-ops" },
    "geo-foundation-models": { "command": "/abs/path/.venv/bin/geo-foundation-models" }
  }
}

With those servers configured, you can already search imagery across multiple STAC catalogs, pull OpenStreetMap vector features, reproject and run geometry operations, and compute FM embeddings from a single chat interface. Add credentialed servers like geo-warehouse or geo-commercial-imagery by supplying their keys using env.

Conclusion

Geospatial work has had a dual fragmentation problem. The data is scattered across catalogs and APIs, and the processing is scattered across libraries and compute backends that don’t talk to each other. For public sector organizations—whether they’re monitoring wildfire recovery, tracking watershed health, or planning infrastructure investments— this fragmentation slows progress.

The Geospatial Power Pack collapses that integration tax into one interface, one credential surface, and one conversation, where you can move from discovery to processing to analysis in minutes. The authoritative catalogs and APIs remain the source of truth; Kiro becomes the single point of access that coordinates them. And because its default discovery and GeoAI paths read directly from the Registry of Open Data on AWS, anyone can run this walkthrough with no account, no key, and no egress cost.

As open geospatial datasets grow and FMs improve, the same architecture scales with them—new data sources become new MCP servers, and new models slot into the GeoAI pillar without rearchitecting the workflow. The goal is straightforward: spend less time wrangling tools and more time answering the questions that matter.

Want to learn more?

To get started, find the full power package with all the MCP servers, skills, steering workflows, and example configurations in the Geospatial Kiro power pack repository.

Learn more about open data on AWS. To learn about using open data on AWS datasets, visit the open data topic in the AWS Public Sector Blog.

1,143 datasets and counting: The Registry of Open Data on AWS hits a milestone

Kyle Cook — Mon, 27 Jul 2026 00:45:56 +0000

The Amazon Web Services (AWS) Open Data Sponsorship Program makes high-value, cloud-optimized datasets freely available for analysis, helping researchers and developers worldwide access critical data without cost barriers.

The Registry of Open Data on AWS has surpassed a major milestone: over 1,100 datasets are now freely available to anyone. In the last 2 years, the Registry has more than doubled in size, growing from 556 to over 1,100 datasets—a 105% increase.

Anyone can use these datasets to analyze data on AWS, develop new cloud-based techniques and tools, or build communities that benefit from shared data access. Through this program, customers have made over 400 petabytes of high-value, cloud-optimized data publicly available.

All datasets are listed in the Registry of Open Data on AWS. This quarter, 261 new or updated datasets were released.

What are people doing with the Registry of Open Data on AWS?

Organizations are using the Registry of Open Data on AWS in many different ways, including:

How AWS Open Data democratizes genomic data for the world. Every human deserves access to innovations that could save their life. Yet for decades, groundbreaking genomic research remained locked behind institutional walls, accessible only to well-funded laboratories. AWS addresses these challenges through open data and strategic programs that put powerful technology within reach of organizations supporting underserved populations.
Transforming rare cancer research with Amazon Quick by integrating biomedical databases for breakthrough discoveries. Hosting the datasets on the AWS Registry of Open Data makes it widely accessible while removing the heavy computational barriers typically required to handle large biological datasets.
Some of the most important datasets in human genomics are now available for researchers everywhere to use to make impactful health discoveries, without being limited by costly transfer fees. Researchers at the UC Santa Cruz Genomics Institute Computational Genomics Lab and the Broad Institute have deployed a mirror of the National Human Genome Research Institute (NHGRI) AnVIL Data Explorer’s open-access genomic datasets in the AWS Registry of Open Data.
When Sid was diagnosed with osteosarcoma in November 2022, he pursued maximum diagnostic testing to explore all treatment options. After standard care, he pioneered parallel therapies and scaled this innovative approach for others. His comprehensive dataset hosted on AWS Open Data includes clinical records, molecular data, RNA and DNA sequencing, spatial transcriptomics, residual disease testing (MRD) testing, flow cytometry, imaging, and lab results. This freely shared resource accelerates global cancer research and drives progress toward better patient outcomes.

NASA launches 231 new datasets in the Registry of Open Data

National Aeronautics and Space Administration (NASA) made the decision to include these datasets—spanning decades of Earth observation, climate research, and satellite missions—in the Registry of Open Data on AWS, and it underscores its commitment to transparency, scientific collaboration, and democratizing access to critical environmental and space-related information.

By sharing projects from the 1990s AN and GR series to modern initiatives like NISAR, PACE, and SWOT, NASA ensures that researchers, policymakers, and the public can access high-quality data to advance climate science, disaster response, and resource management. This initiative fosters global partnerships and empowers communities to address challenges such as climate change and biodiversity loss through evidence-based solutions. They now have over 300 datasets within the Registry of Open Data.

NASA joins 30 other new or updated datasets on the Registry of Open Data on AWS in the following categories:

Climate and weather

EMBER Modeling Files from U.S. Environmental Protection Agency
IOOS MARACOOS Regional Ocean Modeling System (ROMS) “Doppio” Data Assimilative Reanalysis from National Oceanic Atmosphere Administration (NOAA)
ECMWF AIFS ENS – dynamical.org Icechunk Zarr from dynamical.org
East Coast Community Ocean Forecast System (ECCOFS) from NOAA
Global aboveground biomass (AGB), 100m from CTrees
Met Office Blended Probabilistic Forecast – Global gridded percentiles from Met Office
Met Office Blended Probabilistic Forecast – Global gridded probabilities from Met Office
Met Office Blended Probabilistic Forecast – Global spot percentiles from Met Office
Met Office Blended Probabilistic Forecast – Global spot probabilities from Met Office
Met Office Blended Probabilistic Forecast – UK Spot Percentiles from Met Office
Met Office Blended Probabilistic Forecast – UK Spot Probabilities from Met Office
Met Office Blended Probabilistic Forecast – UK gridded percentiles from Met Office
Met Office Blended Probabilistic Forecast – UK gridded probabilities from Met Office
DWD ICON-EU – dynamical.org Icechunk Zarr from dynamical.org
NOAA North American Multi-Model Ensemble (NMME) from NOAA
Met Office UK Marine Observations from Met Office
NOAA JISAO’s Seasonal Coastal Ocean Prediction of the Ecosystem (J-SCOPE) from NOAA
NOAA HRRR – dynamical.org Icechunk Zarr from dynamical.org

Geospatial

Life sciences

How can you make your data available?

The AWS Open Data Sponsorship Program covers storage costs for publicly available, high-value, cloud-optimized datasets. We work with data providers who seek to:

Democratize access to data by making it available for analysis on AWS
Develop new cloud-based techniques, formats, and tools that lower the cost of working with data
Encourage the development of communities that benefit from access to shared datasets

Learn how to propose your dataset to the AWS Open Data Sponsorship Program.

Learn more about open data on AWS.

How UTHealth Houston built HIPAA-compliant generative AI at scale: iDFax’s 2-year journey with Amazon Bedrock

Xiaoqian Jiang, PhD — Sat, 25 Jul 2026 16:48:18 +0000

Every day, clinical staff at UTHealth Houston spent up to 2.5 minutes on a single medical fax, reviewing, categorizing, routing, and manually entering data into their electronic health record (EHR) system. Multiply that by hundreds of thousands of faxes a year, and the toll on staff time and patient care becomes impossible to ignore. In June 2023, UTHealth Houston set out to change that.

This post is a follow-up to our March 2025 blog post, UTHealth Houston’s iDFax transforms medical fax management with Amazon Bedrock, which introduced the iDFax pilot and its early results. Here, we document the full 2-year journey from that initial deployment to enterprise-scale production—and the lessons learned along the way.

What began as a pilot program has evolved into a compelling example of how generative AI can transform medical document processing at enterprise scale while maintaining strict Health Insurance Portability and Accountability Act (HIPAA) compliance.

UTHealth Houston is a leading academic medical center comprising seven schools and two hospitals. It’s home to two organizations at the forefront of digital healthcare innovation. The McWilliams School of Biomedical Informatics is one of the largest biomedical and health informatics programs globally, with an entire department focused on AI and data science. The Center for Digital Healthcare Innovation drives the development and implementation of clinical technologies to enhance patient care, education, and research across the institution.

The transformative journey from pilot to production

In June 2023, UTHealth Houston launched iDFax, a solution powered by Amazon Bedrock, a fully managed service for building and scaling generative AI applications with foundation models (FMs), designed to transform medical fax management. What started as a pilot processing 2,800 faxes monthly has scaled to an enterprise deployment handling over 100,000 faxes monthly by February 2026, representing an approximately 3,500% increase in processing volume over 32 months.

The numbers tell a compelling story of successful AI adoption at scale:

More than 1.2 million faxes processed annually at full deployment across UT Physicians clinics
Over 1,200 registered users, including doctors and clinic staff, across more than 100 clinics
More than $2 million in annual cost savings through processing time reductions and workflow automation
More than 95% optical character recognition (OCR) accuracy maintained consistently throughout the scaling process
50–70% reduction in processing times, from 82–150 seconds per fax to only 28–68 seconds

Manual processing at scale

Before iDFax, UTHealth Houston’s legacy fax-based communication workflow consumed 82–150 seconds of staff time per fax. Healthcare staff manually reviewed, categorized, routed, and entered data into the Epic EHR system, creating costly bottlenecks that delayed patient care. With hundreds of thousands of medical faxes flowing through the system annually, this manual approach was unsustainable.

UTHealth faced a clear challenge. They needed to build an intelligent, HIPAA-compliant automation system that could dramatically reduce processing time and costs while scaling to handle over one million faxes annually across a complex academic medical center environment.

Why Amazon Bedrock and AWS?

UTHealth Houston chose Amazon Web Services (AWS) because Amazon Bedrock provided highly accurate, cost-effective document classification without requiring custom machine learning (ML) infrastructure. Several key factors drove the decision:

HIPAA-compliant AI at scale – Amazon Bedrock offers HIPAA-eligible services with built-in security guardrails. This meant the team could build a compliant AI solution from day one. The secure landing zone environment provides comprehensive security guardrails and centralized observability to help meet strict healthcare compliance requirements.
EHR integration – AWS services enabled direct integration with UTHealth Houston’s Epic EHR system through AWS Direct Connect, allowing automatic extraction of physician and patient data for identity retrieval and record assignment, eliminating manual data entry that previously consumed 2–3 minutes per fax.
Elastic scalability – The comprehensive AWS managed services offerings, including Amazon Simple Storage Service (Amazon S3), Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Queue Service (Amazon SQS), and Amazon DynamoDB, provided the elastic scalability needed to grow from 2,800 faxes monthly to over 100,000 faxes monthly without performance degradation.
Rapid deployment – The managed services approach reduced operational overhead while enabling rapid deployment, which meant the team could move from pilot to production scale in under 2 years.

High-level architecture

The iDFax architecture uses a sophisticated eight-step processing pipeline that orchestrates multiple AWS services:

1. Ingestion – iDFax uploads inbound electronic fax data to AWS at near real-time speed over AWS Direct Connect links to an Amazon Simple Storage Service (Amazon S3) bucket in a secure AWS account.
2. Queueing – Amazon Simple Queue Service (Amazon SQS) queues the data for reliable, ordered processing.
3. Processing – The team packages iDFax applications as Docker containers running on Amazon Elastic Compute Cloud (Amazon EC2) instances, which process faxes from the queue.
4. Metadata management – The system stores and tracks processing metadata in Amazon DynamoDB tables.
5. EHR integration – Automatic extraction of physician and patient data enables direct Epic integration.
6. AI classification – Amazon Bedrock FMs handle classification tasks and generative AI–driven analysis for intelligent document processing (IDP).
7. Referral automation – The system uses automated order transcription to improve accuracy and accelerate the referral process in Epic.
8. Storage and routing – iDFax routes results to integrated systems like Epic or stores them in the AWS environment for data retention and retrieval.

The following diagram shows the solution architecture.

Figure 1: iDFax solution architecture

iDFax key features and benefits

iDFax reduces fax processing times by 50–70%, from the legacy system’s 82–150 seconds per fax to only 28–68 seconds. At current processing volumes exceeding 100,000 faxes monthly, this time savings means that clinical staff can redirect approximately 19,000 staff hours annually from administrative tasks to direct patient care. This is the equivalent of roughly 57,000 patient appointments at 20 minutes each.

The system maintains over 95% OCR accuracy through advanced image correction and handwriting recognition capabilities, exceeding industry benchmarks for AI-assisted document processing.

The solution automates key processes such as document categorization, splitting, and de-duplication, improving document organization quality while reducing processing errors.

iDFax connects fax content to patient records through automatic extraction of physician and patient data for identity retrieval and record assignment with Epic. This integration eliminates the manual data entry that previously consumed 2–3 minutes per fax.

A dynamic monitoring dashboard provides users with actionable insights into system usage, document types processed, and overall operational efficiency.

The team built iDFax using HIPAA-eligible AWS services throughout its entire architecture, maintaining the highest standards of protected health information (PHI) security.

The following bar graph the dramatic increase over time in processing metrics for faxed data.

Figure 2: Faxed data processing metrics

Phased deployment strategy

The success of iDFax demonstrates the value of a methodical, phased deployment approach.

Phase 1: Pilot implementation (June–December 2023)

Initial deployment to selected sites within UTHealth Houston
Processed over 220,000 faxes during the pilot phase
Monthly volumes grew from 2,800 to 7,800 faxes
Validated system capabilities and established performance baselines

Phase 2: Systematic expansion (January–December 2024)

Primary scaling period with monthly volumes growing from 9,100–23,400 faxes
Systematic rollout to additional UT Physicians clinics and departments
Processed 253,920 faxes total during 2024
Established a scalable operational foundation, including cloud deployment to support enterprise growth and reliability

Phase 3: Production deployment (January–December 2025)

Full-scale deployment across UT Physicians clinics
Monthly processing volumes reaching more than 100,000 faxes
Serving over 1,200 active users across more than 100 clinic locations
On track to process more than one million faxes annually

Phase 4: Optimization and enhancement (January 2026–present)

Transition from deployment to continuous improvement and workflow optimization
Implementation of the Transcribe Order feature, enabling faster referral processing with significantly reduced manual entry
Driving efficiency through continuous optimization and automation

Financial impact and ROI

The financial returns have exceeded initial projections, with the system delivering more than $2 million in annual cost savings.

The 68-second average time savings per fax across one million annual faxes represents approximately $908,000 annually in labor cost savings alone, calculated at healthcare administrative labor costs of $48.05 per hour.

Conservative return on investment (ROI) analysis indicates net annual returns of more than 220%—calculated by comparing total annual cost savings against implementation and operational costs—with payback periods of approximately 3–4 months.

The financial impact spans multiple categories including labor efficiency, operational overhead elimination, error reduction, and compliance risk mitigation, creating a strong financial case for strategic healthcare AI investment.

Clinical impact and workflow transformation

Beyond the metrics, iDFax has fundamentally transformed clinical workflows at UTHealth Houston. Healthcare providers report increased confidence in document processing accuracy and reduced administrative burden, allowing better focus on patient care.

The system’s near real-time processing capability delivers critical clinical information to providers quickly, supporting timely clinical decision-making and reducing delays in patient care. The automated document categorization and routing capabilities have improved document organization quality while reducing processing errors.

At current processing volumes, the time savings allow clinical staff to redirect substantial hours from administrative tasks to direct patient care—a transformation that directly impacts the quality of healthcare delivery across UTHealth Houston’s extensive network.

Technical leadership and innovation

The implementation reflects sophisticated technical leadership and collaborative execution. Led by the McWilliams School of Biomedical Informatics and the Center for Digital Healthcare Innovation, with technical leadership and major development contributions from Dr. Omer Anjum, the project brought together clinical informatics expertise, digital healthcare innovation capabilities, and AWS technical support. Krystal Goff, serving as project manager, drove cross-functional alignment across infrastructure, cloud, development, customer, and leadership teams to support successful execution.

The system operates within UTHealth Houston’s AI governance framework, led by Dr. Xiaoqian Jiang as associate vice president for medical AI and chair of the Department of Health Data Science and Artificial Intelligence. This leadership structure helps align iDFax’s evolution with institutional strategic priorities and emerging AI capabilities.

Lessons learned and best practices

The 2-year journey from pilot to production has yielded valuable insights for healthcare organizations considering similar AI implementations:

1. Start with clinical leadership – Projects succeed when clinicians who understand workflow challenges lead them and champion adoption.
2. Design for compliance from day one – Building HIPAA-compliant architecture from project inception prevents costly retrofitting.
3. Prioritize EHR integration – Direct integration with existing systems is critical for user adoption and workflow efficiency.
4. Deploy in phases – Phased implementation enables risk mitigation while demonstrating value incrementally.
5. Measure rigorously – Clear performance metrics and baseline measurements facilitate organizational buy-in and demonstrate ROI.
6. Invest in change management – Comprehensive training programs and ongoing support infrastructure are essential for sustained user adoption.
7. Listen early and often – Continuous user feedback helps solutions align with real workflows, builds trust, and drives stronger adoption.

Looking forward

The success of iDFax provides a foundation for UTHealth Houston’s broader digital transformation strategy. The system’s proven capabilities in document processing and workflow automation create a platform for expanding AI initiatives across the organization, including the recently launched Transcribe Order feature, which enables faster referral processing with significantly reduced manual entry.

The robust, scalable architecture also positions iDFax to address similar document management challenges in other highly regulated industries. Sectors such as insurance, legal, and mortgage frequently contend with high volumes of sensitive fax communications and stringent compliance requirements. iDFax’s success in healthcare demonstrates its potential to streamline operations, strengthen security, and reduce costs for organizations across these fields.

Conclusion

UTHealth Houston’s iDFax implementation demonstrates that healthcare organizations can achieve transformative AI adoption at enterprise scale while maintaining strict HIPAA compliance and delivering strong financial returns. The journey from 2,800 faxes monthly in a pilot program to processing over 1 million faxes annually represents more than technological success—it’s a blueprint for healthcare AI transformation.

By using Amazon Bedrock foundation models and AWS comprehensive cloud services, UTHealth Houston built a solution that improves productivity, reduces costs, and improves care delivery. Processing over 1 million faxes annually while generating more than $2 million in cost savings and maintaining more than 95% accuracy provides a replicable model for healthcare organizations seeking AI-powered document management solutions.

The 2-year production journey demonstrates that with proper planning, technical architecture, clinical leadership, and organizational support, healthcare AI can deliver both immediate operational improvements and long-term strategic value. As healthcare continues its digital transformation, iDFax stands as a benchmark implementation for HIPAA-compliant generative AI at scale.

To learn how AWS can help your organization modernize document workflows with generative AI, contact your AWS representative or visit Amazon Bedrock product page to explore HIPAA-eligible AI solutions for regulated industries.

How eduroam empowers its community through real-time analytics with Amazon Quick Sight

Jan Day — Wed, 22 Jul 2026 13:00:08 +0000

How does eduroam, a global federated network—one that authenticated over 9.2 billion sessions in 2025 across more than 100 countries—stay healthy, responsive, and sustainable? It relies on its community and the frequent, data-rich, and collaborative communication among its participating institutions.

For the more than 2,800 administrators across approximately 1,200 participating institutions in the US, that means access to near daily provided to them through Amazon Quick Sight on Amazon Web Services (AWS) by the eduroam team at Internet2. However, this wasn’t always the case. This post walks through how the eduroam team modernized their data reporting pipeline, the architecture behind it, and the impact it’s had on institutional engagement.

The challenge of static reports in a dynamic world

eduroam (education roaming) is the secure, worldwide roaming access service developed for the international research and education community. eduroam lets students, researchers, and staff from participating institutions automatically connect to secure Wi-Fi at any participating institution worldwide—no guest accounts, captive portals, or insecure password-based networks.

Internet2, the organization overseeing the US eduroam network, captures daily data from about six million authentications per day. Since 2022, Internet2 has been sending to each participating institution a monthly summary PDF with information about eduroam usage at their institution, including number of successful authenticated sessions per day, unsuccessful attempts, and local and worldwide eduroam sites visited. In addition, each institution received 6-month and annual summaries of usage.

These static PDFs left much to be desired. They didn’t let institutions explore their own usage. Limitations in the visualization tools sometimes produced unreadable graphics. The data covered only a single usage period, with no historical context. Administrators couldn’t compare year-over-year usage, which meant they couldn’t plan to support events that might require increased investment in technology or communication to their user community (such as hosting an international conference or event drawing participants from multiple institutions). Internet2 sent these reports out monthly, not providing timely insight. These summary reports weren’t detailed enough to let administrators identify problems with their infrastructure and troubleshoot in real time.

eduroam is decentralized by design. The service runs better when local administrators actively improve their infrastructure, but with static reports, administrators lacked the visibility to do so effectively.

Democratizing access to shared data

Internet2 sits at the center of millions of eduroam transactions, and they capture data that is of shared interest to the eduroam community. Both Internet2 and eduroam participating organizations benefit from understanding the data. A broader infrastructure modernization prompted the team to ask: “If we’re scaling eduroam for millions more users, shouldn’t we also rethink how eduroam communicates value to its community?”

Sara Jeanes, director of eduroam and certificate services at Internet2, wanted to facilitate community participation and engagement with the eduroam data, not gatekeep information. Sara knew the community needed real-time, self-service access to their own data. Community members needed the ability to explore their own data dynamically and explore their own usage during different time windows (for example, compare our flagship alumni event last year to the same event this year or plan for spikes during a rivalry football game). She also knew that they wanted context for how they’re performing relative to their peers while preserving privacy—the ability to see their own data without exposing others’ data.

A federated analytics platform on Amazon Web Services

Internet2 evaluated several analytics platforms for one that met their needs for security, capabilities, licensing, and scale. During their evaluations, they realized that row-level security was a critical capability. It would let each of the 2,800 eduroam administrators sign in to the solution and see only their institution’s data, which is critical for a trust-based federation.

Internet2 selected Amazon Quick Sight as its business intelligence (BI) layer. This was a natural choice because Internet2 was already running eduroam infrastructure on AWS, which meant the team could streamline data ingestion, storage, and visualization within a single cloud environment.

The architecture works as follows. Each night, AWS Glue ingests two data sources: institution metadata from Federation Manager (including hotspot locations) and national eduroam login logs captured at second-level granularity. An AWS Glue extract, transform, and load (ETL) job aggregates those raw logs into daily totals, while an AWS Glue crawler infers schema and registers the datasets in the AWS Glue Data Catalog. The processed data lands in Amazon Redshift Serverless, which serves as the central data store holding both aggregated traffic and row-level security (RLS) rules. Amazon Quick Sight then reads from Amazon Redshift Serverless in direct query mode, so dashboards consistently reflect the latest data without requiring a separate extract.

On the identity side, Internet2’s IAM system provisions eduroam administrators into AWS IAM Identity Center, which acts as the identity provider for single sign-on. Quick Sight authenticates users through IAM Identity Center and cross-references their identity with authorized institution mappings from Federation Manager using a built-in RLS rules dataset. The result is that each institution sees only its own window into the eduroam federation.

The system consists of the following components:

eduroam source systems – Federation Manager provides institution metadata and service locations, national eduroam login logs record authentication events as users roam across participating institutions, and Internet2 IAM supplies the administrator identities who manage the federation
Ingestion and ETL with AWS Glue – Ingests source data nightly, the AWS Glue crawler infers schema into the AWS Glue Data Catalog, and AWS Glue ETL jobs aggregate records on a secondary daily schedule.
Data store – Amazon Redshift Serverless stores the aggregated traffic data alongside metadata and row-level security rules that map users to institutions.
Analytics and BI – Amazon Quick Sight reads from Amazon Redshift Serverless in direct query mode with native row-level security enforced per institution.
Per-institution dashboards – Each institution sees only its own window into the eduroam federation through dedicated dashboard views.
Identity and access – Internet2 IAM provisions administrators into IAM Identity Center, and Amazon Quick Sight authenticates users through single sign-on.
Monitoring and audit – Amazon CloudWatch captures metrics and logs, and AWS CloudTrail provides API-level audit trails across the pipeline.

The following diagram shows the solution architecture.

Figure 1: Internet2 eduroam analytics on AWS

Thomas Pratt, Internet2’s enterprise solutions architect, keeps the data in perspective. “We’re talking about a 400-million-row log table aggregated to a daily level,” he says. Although the number sounds large, Pratt notes the architecture handles it comfortably. What matters isn’t the volume but making it accessible to 2,800 administrators simultaneously.

The eduroam US analytics dashboards launched a pilot in November 2025 to eduroam Support Organizations (eSOs), then released to the entire US eduroam community in January 2026.

Active stewards

The eduroam analytics dashboards fuel institutional independence—administrators can make decisions without having to ask Internet2. Administrators can now dig into 4 years of data. They can compare events, track seasonal patterns, and identify issues their user community is experiencing in real time.

Mary Bull, eduroam’s technical service manager, noted that one K12 administrator discovered a counterintuitive pattern: summer usage was increasing. Digging into the data, they realized college students returning home were connecting to their local school district and library Wi-Fi, an insight they might never have seen in the static PDF reports.

Access to dynamic data has given greater insight to administrators at multiple scales. Before the availability of eduroam Quick Sight dashboards, team members counted log lines and used Microsoft Excel for statistical analysis. It was difficult to replicate the analysis, even for key troubleshooting metrics like the national average of the eduroam access request reject rate. Now Internet2 can compare the overall rate to identify institutions that need support. In the future, eduroam sites will be able to see how they stack up and can identify where they need help. This will help institutions be proactive and address sitewide errors without waiting for users to report problems. The Quick Sight platform provides a flexible portal where new analytic visuals can be added as Internet2 develops and releases them.

Institutions aren’t on their own. Internet2 uses the data to identify institutions that are struggling to complete the infrastructure configuration necessary to connect to the eduroam network. This information lets Sara and her team develop interventions tailored to the needs of specific institutions rather than sending out one-size-fits-all communications.

Community-driven philosophy

“We want to facilitate administrators to operate on their own and for us to not be the choke point.” Sara shared.

The new dashboards complement the 2026 State of the Network report. “This report is about building shared expectations across the eduroam community,” Sara explained. “This report is encouraging our community to discuss and incorporate data as it collectively establishes community best practices and norms. Now the community can define, ‘what good looks like’.”

What’s next

Amazon Quick Sight enables a platform that delivers flexible, secure data access and opens the door to future new visuals that let eduroam administrators troubleshoot and demonstrate the value of the service to their stakeholders.

The Quick Sight dashboards are only the beginning. K12 school districts, museums, and libraries across 11 states have added nearly 3,000 new deployments since 2019. With eduroam expanding rapidly beyond higher education, the Internet2 team is focused on making the analytics platform grow alongside the community it serves.

That means two things. First, meeting new community members where they are: the team is developing onboarding materials tailored to organizations that might be encountering eduroam analytics for the first time. Second, deepening the value for existing institutions by incorporating community feedback into the platform’s roadmap. Upcoming enhancements include combining eduroam data with National Center for Education Statistics (NCES) data to add demographic and institutional context, aggregated community views that let administrators benchmark against peers, and predictive insights that surface trends before they become problems. Imagine asking, “How does our eduroam usage compare to the rest of the Big Ten athletic conference?”

A stronger network through shared insight

eduroam was born from a shared need—researchers and students were increasingly mobile, and the community recognized that no single institution could solve connectivity alone. A federated approach, built on mutual trust, was the answer. Two decades later, that same collaborative DNA is driving a new chapter, one where shared data, not only shared infrastructure, strengthens the network. As Internet2 rolls out its first State of the Network report this summer, the US eduroam community is proving that when 1,200 institutions can see, understand, and act on the same data, the result is a healthier network and a model for how federated communities everywhere can scale trust through transparency.

Not yet using eduroam? Learn how to join the federation and give your community secure connectivity. Learn more about how Amazon Quick Sight enables secure, embedded analytics at scale, including row-level security for multi-tenant environments.

The NBDC sandbox: How the Masonic Institute for the Developing Brain built a secure cloud environment to accelerate brain development research with AWS

Jianjun Xu, Ph.D. — Wed, 22 Jul 2026 01:37:44 +0000

The Adolescent Brain Cognitive Development (ABCD) and HEALthy Brain and Child Development (HBCD) studies, the largest longitudinal brain development studies in U.S. history, are producing transformative insights, but the data driving those discoveries require greater security and have grown so large that many research teams struggle to access and analyze them.

Researchers working with large-scale brain development data have long followed a familiar workflow of downloading the data, storing it locally, and analyzing it through institutional systems. But new National Institutes of Health (NIH) security requirements and rapidly expanding volumes have made that process unsustainable for many teams. “The data has become almost impossible to handle if you’re not an informaticist or don’t have one on speed dial,” said Dr. Damien Fair, co-director of the Masonic Institute for the Developing Brain (MIDB) at the University of Minnesota (UMN).

Dr. Fair, MIDB, and Lasso Informatics designed and developed the NIH Brain Development Cohorts (NBDC) Sandbox as a secure environment for accessing and analyzing sensitive data. With support from Amazon Web Services (AWS) and AWS Partner ScaleCapacity, the NBDC Sandbox was implemented on the AWS Cloud in a secure, scalable fashion, empowering users to access ABCD and HBCD data in place, with no downloads required.

Why the data demands new workflows

For the past decade, the ABCD Study has tracked about 12,000 participants from age nine or 10 through young adulthood. The newer HBCD Study extends that model, starting in the second trimester of pregnancy and following subjects up to the point where the ABCD Study begins. Both studies investigate how experiences, histories, biology, and exposures influence brain development.

Researchers working with data from these studies face two tough challenges. The first is the data’s size and scope. These high-dimensional datasets contain billions of elements across a wide range of data types, including MRI, EEG, behavioral, biosensor, bio samples, and genetic data. Their volume and complexity far exceed what most institutions can download and store locally.

The second is stringent security standards. New NIH mandates, introduced in January 2025, significantly expand compliance requirements to strengthen privacy and data protection. Strict policies substantially limit access, and required data-use certifications constrain collaboration by prohibiting data sharing outside secure systems. “That is an issue because most universities and laboratories don’t have those types of environments,” said Dr. Fair.

While the MIDB team had constructed an on-premises environment for the NBDC, these NIH mandates challenged the team to think beyond this environment and consider new approaches that allow for more flexible expansion to meet new community needs. They needed a cloud-based, compliant companion that was built for how researchers work, with familiar tools, scalable resources, and predictable costs. To construct it quickly and effectively, they needed support.

Shaping a solution with AWS

MIDB had recently built a HIPAA-secure AWS environment for a Department of Defense (DoD) telehealth project at UMN, so working with AWS again was the natural next step.

AWS helped Dr. Fair and Lasso plan the execution and identify ScaleCapacity as the right collaborator to implement a hybrid framework within the UMN environment.

Creating a compliant research environment in under a year required the full cross-functional team. “It was an all-hands-on-deck effort to put this environment in play,” Dr. Fair explained.

How the NBDC Sandbox works

Researchers access the Sandbox via the centralized, user-friendly NBDC Data Hub and use familiar tools such as Jupyter notebooks, RStudio, Python, and Linux. Because Amazon Simple Storage Service (Amazon S3) stores and mounts the data directly in the file system, research teams bypass the download step entirely.

The environment uses AWS ParallelCluster with Slurm for high-performance computing (HPC), supporting both batch and interactive workloads. The cluster elastically scales compute resources, including GPUs, based on demand. Separate Slurm queues offer different tiers of resources, so researchers can select the right level of compute for their workload, from lightweight data exploration to intensive neuroimaging analysis. Fair-share scheduling distributes these resources equitably, and when the system reaches capacity, additional jobs are queued rather than incurring unexpected costs or halting work mid-process.

The environment also includes pre-installed neuroimaging tools—FreeSurfer, FSL, AFNI, and Connectome Workbench—so researchers can run MRI and diffusion tensor imaging (DTI) analysis, cortical surface reconstruction, brain segmentation, and other processing tasks without configuring software.

The Sandbox’s architecture mirrors that of most university supercomputing centers, so researchers skip the learning curve. It also keeps costs fixed and predictable. For academic teams operating within tight grant budgets, this feature is crucial. “They don’t want to see quadruple the cost they budgeted, or to see their work stop because resources have run out,” said Dr. Fair. “So, having that kind of functionality is really important.”

Open OnDemand serves as the intuitive user-facing layer on top of AWS ParallelCluster. Through a browser-based interface, researchers can launch and monitor jobs, manage files, and run tools like Jupyter and RStudio, all without deep HPC knowledge or local setup. A hybrid model combines local and cloud-based resources to keep costs down. In total, this technical design offers cost-predictability and a frictionless user experience.

Expanding access across the research community

The NBDC Sandbox is changing how researchers work with large-scale data on brain development. “It reduces barriers to science,” explained Dr. Fair. “The real-world impact is, hopefully, accelerating new discoveries.” Across the research community, the benefits will be concrete:

Institutions no longer need to build and maintain compliant on-premises environments to access the data.
Cross-institutional teams will be able to share data within a secure environment, supporting collaboration that was previously difficult.
Researchers can work in familiar environments without needing to set up new systems or learn new workflows.
Institutions without dedicated informatics teams can access and use high-dimensional datasets.
Researchers can spend less time on the technical aspects of data access and more time on the science.

Early results reveal growing demand

The NBDC Sandbox went live in November 2025, and the initial response has been positive: “People are just happy that they have it,” said Dr. Fair.

Researchers are using the environment for training sessions, hackathons, and workshops, including at the annual HBCD meeting. It also supports programs such as the Scientific Training in Addiction Research Techniques (START) program, which helps scholars at institutions with limited computing resources work with these datasets.

Usage trends underscore the expanding need for cloud-based compute environments. “Demand is only increasing as more people learn about it,” said Dr. Fair. “It’s definitely growing quite a bit.” The team expects it to increase further as file-based data just became available at the end of April 2026.

Building a blueprint for the research community

Dr. Fair and the Lasso team envision a future in which researchers access brain development data exclusively through cloud-based environments.

To advance that vision, they constructed a repeatable, cloud-first model for accessing sensitive data. MIDB’s environment serves as a blueprint for institutions to reference when developing their own implementations, which can now be deployed from Lasso as a Secure Analytics Framework Environment (SAFE) or Lasso SAFE.

Dr. Fair, MIDB, and the Lasso team are still refining the NBDC Sandbox. They plan to explore evolving tools and technologies that expand support for institutional teamwork through collaborative spaces and derived data sharing (or community collections). They are also the model in which institutions can secure their own SAFE environment that meets institutional needs and NIST compliance requirements, while continuing to optimize the user experience.

Bringing the compute to the data

Expanding data volumes and tightening NIH security mandates are accelerating a shift toward cloud-based research computing. The NBDC Sandbox demonstrates that with familiar tools, predictable costs, and accessible systems, the benefits of making that shift extend well beyond compliance.

MIDB’s implementation of SAFE (NBDC Sandbox) provides institutions with a replicable roadmap for executing an increasingly urgent transformation. “This movement is coming,” Dr. Fair said. “The question is, are you prepared for it?”

When your team is ready to bring the compute to the data, AWS can assist. Learn how AWS helps research institutions securely access, analyze, and collaborate on large-scale datasets in the cloud.

Read related stories on the AWS Public Sector Blog:

TOLAP: Closing the data-object security gap in AI agent architectures

Phillip Spies — Tue, 21 Jul 2026 15:12:37 +0000

If your organization deploys AI agents across organization or government environments, you’re likely discovering that security models can’t keep pace. Agents access data through tools such as plugins, function calls, and Model Context Protocol (MCP) servers, and those tools connect directly to source systems. The agent constructs its own queries, decides which endpoints to call, and determines what data to retrieve. Every interaction is an autonomous data-access decision.

Every major agent framework has a security model for this. Amazon Web Services (AWS), Microsoft, and Google each ship agent solutions with authentication and credential management built in. Amazon Bedrock Agents, for example, enforces AWS Identity and Access Management (IAM)-based authorization on which AWS Lambda functions, Amazon Simple Storage Service (Amazon S3) buckets, and Amazon Bedrock Knowledge Bases an agent might invoke. Each model authorizes whether the agent can invoke a tool. None enforce policy on what the tool returns. The gap between those two questions is where data leaks into the model’s context window.

The frameworks acknowledge this gap and tell you to fill it yourself. Tool-Object Level Access Protocol (TOLAP) closes that gap: It means organizations can deploy AI agents against sensitive data sources with confidence that access policies follow the data, not the agent.

Why traditional access models fall short

The instinct is to reach for existing access control models. No one designed them for the agent loop, and each has limitations in this context.

Role-based access control can’t say which columns are visible or which rows should be filtered. Attribute-based access control evaluates policy at a centralized engine, but agents that construct direct queries bypass it entirely. Database row-level security applies only to databases. APIs, knowledge bases, and object storage are out of scope. Content guardrails filter what the model says, not what the model sees; by the time they intervene, unauthorized data is already in the context window, available for summarization, reasoning, and exfiltration through prompt injection.

The question is no longer whether agent tools need data-object security. The question is what the standard for it should be.

Introducing TOLAP

TOLAP is an open protocol that moves access control to the only layer that can’t be bypassed in an agent system: the tool itself. The tool is the boundary between the agent and the data source. If the tool enforces policy at that boundary, every other layer above it becomes optional defense rather than load-bearing security.

Three principles

The properties described hold when a system conforms to the TOLAP specification:

Source-point enforcement – The system enforces security where data originates, not in a layer above it. The tool wraps the data source and applies policy before any data crosses the boundary. Because the tool is the only configured path to the data source, there is no route that bypasses enforcement. The tool is the security boundary.
Object granularity – Policies operate on individual data objects, not on tables, resources, or services. Columns, rows, fields, tags, endpoints, HTTP methods, similarity thresholds, file prefixes, and result limits are all first-class targets. A single TOLAP policy can simultaneously declare that a user can query the patients table, can’t see the ssn column, can see rows filtered to their assigned regions, and receives the email field as a SHA-256 hash.
Agent transparency – The calling agent requires zero security awareness code. Restricted data doesn’t exist from the agent’s perspective. Prompt injection attacks aimed at extracting unauthorized data have nothing to extract because the data wasn’t in the response. The defense is architectural, not behavioral.

Five components

A TOLAP-conformant system has five components, run in this order on every tool call:

Security Profiles are declarative, reusable policy definitions. An administrator authors a profile specifying allowed objects, hidden fields, masked columns, row filters, tag restrictions, endpoint access, and operational limits. Administrators assign profiles to users, groups, roles, or service accounts with mandatory audit fields—who granted access, when, and why—and optional time-bound expiry.
The Policy Resolution Engine computes the effective policy for a user and data source by merging all applicable profiles. The merge strategy is most-restrictive-wins:
- Intersect allowed sets
- Union hidden sets
- Conjunctively combine row filters
- Take the minimum value for numeric maxima
- Require unanimous agreement for Boolean permissions
The Security Context packages the effective policy into a hash-based message authentication code (HMAC)-signed, time-bound, self-contained envelope. The system signs it to prevent tampering, time-stamps it to prevent replay, and makes it self-contained to eliminate database lookups at enforcement time. It transports cleanly across process, network, and cloud-account boundaries.
Secure Tool Wrappers enforce the policy at the data boundary: rewriting queries, masking fields, filtering results by classification, and enforcing volume limits.
The Secure Tool Factory instantiates wrappers with the correct security context and credentials for each request. Agents receive tools from the factory and don’t construct data access directly.

The following diagram illustrates how the five TOLAP components execute in sequence on every tool call, from policy resolution through enforcement at the data boundary.

Figure 1. TOLAP security architecture: Security profiles flow through the Policy Resolution Engine to produce a tamper-proof security context, which the Secure Tool Factory uses to instantiate wrappers that enforce policy on every tool call. The AI agent receives only filtered data and doesn’t see unauthorized information.

A peek at what a policy looks like

A short example makes the protocol concrete. This policy grants a healthcare analyst persona access to a clinical database:

{
  "name": "healthcare-analyst",
  "permissions": { "canQuery": true, "canExport": false, "readOnly": true },
  "objectRules": {
    "allowedObjects": ["patients", "encounters", "diagnoses"],
    "hiddenObjects": ["billing_internal", "audit_log"],
    "fieldRules": {
      "hiddenFields": ["patients.ssn", "patients.date_of_birth"],
      "maskedFields": [
        { "field": "patients.email", "maskType": "hash",
          "parameters": { "algorithm": "sha256" } },
        { "field": "patients.full_name", "maskType": "partial",
          "parameters": { "showFirst": 1, "maskChar": "*" } }
      ]
    },
    "rowFilters": [
      { "field": "region", "operator": "in", "values": ["us-east", "us-west"] },
      { "field": "status", "operator": "notEquals", "value": "deleted" }
    ]
  },
  "limits": { "maxResults": 5000, "maxQueryTimeSeconds": 30 }
}

Under this policy, the agent doesn’t see ssn or date_of_birth (absent from the schema), receives email as a SHA-256 hash and full_name as “J*********”, sees only us-east and us-west rows excluding deleted records, and is capped at 5,000 results with a 30-second timeout. None of this is visible to the agent.

Cross-source coverage with one schema

The same protocol covers databases (Amazon Athena, Amazon Redshift, PostgreSQL, MySQL, BigQuery, Synapse, and others), APIs (REST, GraphQL, SOAP, FHIR, HL7, gRPC), knowledge bases (Amazon Bedrock Knowledge Bases, Amazon OpenSearch Service, Azure AI Search, Elasticsearch), and object storage (Amazon S3, Azure Blob Storage, Google Cloud Storage). Each source category interprets the relevant fields of one shared policy schema. One schema, all source types. Adding a new connector means writing a more secure tool wrapper, not redesigning the authorization layer.

Why this matters for the public sector

Public sector organizations face unique pressures when deploying AI agents. Government agencies handle citizen data subject to strict regulatory frameworks. Healthcare systems manage protected health information across federated environments. Defense and intelligence communities require compartmentalized access that adapts to mission context. TOLAP helps these organizations maintain compliance and preserve public trust by deploying AI agents at scale with consistent, enforceable access controls.

An open standard, available today

The specification

TOLAP defines a protocol-agnostic specification anchored in a versioned JSON Schema covering policy definition, policy assignment, and the merged effective policy.

The SDK

A reference SDK ships in .NET, Python, and TypeScript, each as three packages. The core package contains models, the merge algorithm, HMAC signing, and the enforcement engine with zero external dependencies. The store package defines a pluggable policy-storage interface with an in-memory implementation. (DynamoDB, PostgreSQL, or Redis can sit behind it without changing the rest of the system.) The MCP package wraps any MCP server with TOLAP enforcement: drop-in, no changes inside the tool implementation.

Security properties

By design, a TOLAP implementation provides:

Non-bypassable enforcement – When correctly configured, the tool is the only path to the data source
Tamper resistance – Effective policies are HMAC-signed; modification invalidates the signature
Replay resistance – Signed contexts are time-bound and expire
Cross-boundary integrity – Signed contexts transport cleanly across process, network, and cloud-account boundaries without losing their protections
Thorough audit – Every assignment carries mandatory audit metadata: who granted it, when, and why

TOLAP versus traditional approaches

The following table summarizes how TOLAP compares to traditional access control approaches across key dimensions relevant to AI agent deployments:

	RBAC	ABAC	Database RLS	TOLAP
Enforcement point	Application layer	Policy engine/gateway	Database engine	Inside the tool
Granularity	Role/resource	Attribute/policy	Row	Column, row, field, tag, endpoint
Cross-source	Per-system	Centralized but bypassable	Database only	All source types unified
Agent-safe	Requires compliance	Requires routing through	N/A	Transparent: agent unaware
Masking	Not built-in	Policy-dependent	Not built-in	Built-in per-field masking
Multi-tenant	Application logic	Policy logic	Database logic	Embedded in every tool
Audit trail	Varies	Varies	Varies	Mandatory per-assignment

The bottom line

AI agents are accessing enterprise data at scale through tools. The security model that protects that data must operate inside the tool itself, not at the gateway, application, or in the prompt. TOLAP is declarative, auditable, transparent to the agent, and non-bypassable by design. The specification, the schema, and the reference SDK are open and available today.

Two questions for your team:

Where in your agent architecture does data-object policy enforcement live today? If the answer is “at the gateway,” “in the application,” or “in the agent’s prompt,” the architecture has the gap this protocol closes.
Would your enforcement survive prompt injection if the tool received unfiltered data? If the answer requires the agent to behave correctly, the answer is no.

Next steps

To explore the TOLAP specification, JSON Schema, and reference SDKs, visit the TOLAP open standard repository. For questions, contributions, or implementation guidance, see the project documentation.

How South Carolina’s Talking Book Services uses Amazon Connect to bring readers closer to the stories they love

Deepa Nair — Sun, 19 Jul 2026 15:08:38 +0000

South Carolina State Library’s Talking Book Services has been putting books into the hands—and ears—of people with print disabilities since 1931. Now, with the help of Amazon Connect, the small team of reader advisors serving 4,200 patrons across the state is making those deeply personal connections easier than ever.

In 1931, Congress established the National Library Service to serve veterans in every US state and territory who had visual disabilities resulting from their military service. Nearly a century later, the South Carolina State Library’s Talking Book Services program provides reading materials in digital audio and braille formats to patrons statewide. This library program is available to any South Carolina resident with a visual impairment, physical disability, or reading difference, such as dyslexia, that makes it difficult to use traditional print materials.

Unlike most modern library services, Talking Book Services assists its patrons primarily by phone. Five reader advisors each field up to 30 calls per day, personally setting up accounts and queues of reading material, assigning specialized equipment, and troubleshooting app or equipment difficulties. A call might be a quick request for the latest mystery or a book request along with a bit of conversation with a patron who just wants someone to talk to.

“We try not to limit that interaction when we don’t have to,” says Jennifer Wilson, director of Talking Book Services at the South Carolina State Library. “We don’t want to rush people. We value that ability to connect with them.”

When the phone is essential to the mission, the system behind it matters. And for years, the team knew theirs wasn’t keeping pace.

Why Amazon Connect

Their previous setup offered no menu options, no call routing, and no advanced features like voicemail transcription. The team explored several alternatives, but each came with a mass of required features that created unnecessary complexity for patrons who need simplicity above all.

It was Paul Harmon, IT director at the South Carolina State Library, who suggested the team consider Amazon Connect. The appeal was immediate: a cloud-based contact center that the team could set up quickly and tailor precisely to their needs.

The simplicity of getting started was a deciding factor. The intuitive drag-and-drop contact flow of Amazon Connect means a team doesn’t need deep technical expertise to build their phone workflows. Single sign-on integration made the transition seamless for reader advisors. They sign in to Amazon Connect the same way they access their other work tools, with no separate credentials to manage. For a small team of five advisors focused on patron support rather than IT, this ease of use is essential.

Designing for accessibility

Working with implementation partner SMX, the Talking Book Services team designed a phone experience around one guiding principle: accessibility first.

That meant minimizing menu steps and ensuring voice commands could navigate the entire system. It also meant paying close attention to something many organizations never think about: the sound of the voice answering the phone.

“We chose a male voice because lower pitches tend to be easier to hear,” Wilson explains. “We were able to slow it down just a little bit. We were able to specifically say what we wanted our greeting to be, keep it simple, keep those options clear.”

The flexibility of Amazon Connect made this level of customization straightforward. Rather than adapting to fit a rigid phone platform, the team was able to build the exact experience their patrons needed—from the voice and pacing of the interactive voice response (IVR) prompts to the structure of the menu options.

More than a library—a lifeline

For many patrons, Talking Book Services isn’t only a convenience. It’s a connection to the world. This became more apparent than ever during the COVID-19 pandemic. Wilson explains, “During lockdown, when all of the reader advisors were working from home, they set up a process to call every one of our four-thousand-plus patrons to check in on them and assure them we were still here and able to help them. Some of our patrons were very isolated, and our call was one of their only outside contacts. Everyone on the Talking Book Services team felt really good about being able to offer that contact and continuity of service at a time when so much of normal life completely stopped. Our patrons told us over and over how much they appreciated that effort.”

It’s not an isolated story. Wilson and her team of five reader advisors regularly receive calls and notes from family members describing the program as life-changing. They’ve formed relationships that span decades.

Wilson doesn’t hesitate when asked about the value of what her team provides. “Being a part of the South Carolina State Library makes it possible to provide completely free service to qualifying residents all across South Carolina,” Wilson says. “We love helping our fellow South Carolinians access a rich and rewarding reading life when they might have thought that opportunity was gone forever.”

Voicemail transcription changes the game

Though the system has been live for only a few weeks, the impact on daily operations is already clear. The feature that has won the most enthusiastic praise from the reader advisors is voicemail transcription, the ability to simultaneously listen to and read a patron’s voicemail message.

“That is their favorite thing ever,” Wilson says. “Having the ability to read a message at the same time we are listening to it helps us provide more accurate and timely service—that’s a win-win.”

The team is also exploring Bluetooth headsets to match their workflow. Unlike a traditional call center, reader advisors aren’t desk-bound. They’re up and down throughout the day, pulling patron records, visiting the mailroom, and making copies. The flexibility to take a call while walking back from the copier adds another layer of mobility to their day.

Scaling to reach every eligible child in South Carolina

Wilson sees the current implementation as only the beginning. She’s already thinking about potential integrations with their system that could streamline the enrollment process or help reader advisors set up genre preferences more efficiently during onboarding calls.

But the most ambitious goal on the horizon is growth, specifically, reaching school-age children across the state. With recent eligibility expansions to include people with learning disabilities like dyslexia and ADHD, Talking Book Services is actively working to connect with students who have qualifying conditions and could benefit enormously from accessible audiobooks. Many of these families have never heard of the program.

This is where the scalability of Amazon Connect becomes critical. As outreach to school districts succeeds and referrals increase, the team needs a phone system that can absorb growing call volume without requiring new hardware, additional phone lines, or extra licenses. The Amazon Connect pay-as-you-go model means costs scale proportionally with demand. The team pays only for the minutes they use, whether they’re serving 4,200 patrons or 42,000.

Beyond scalability, Amazon Connect automation capabilities open new possibilities for supporting this growth. Automated enrollment confirmations, self-service menu options for common requests like checking the status of a mailed cartridge, and intelligent call routing could all help a small team of five advisors manage a much larger patron base without sacrificing the personal relationships that define the service.

“We have the opportunity to enroll and serve patrons their entire life,” Wilson says. “From the grandparent who has lost their vision to their grandchild with dyslexia.”

The goal is to make sure all generations of eligible readers can find their way to that first phone call, and that when they do, someone is ready to answer.

To learn more about Talking Book Services at the South Carolina State Library or to apply for service, visit South Carolina Talking Book Services. To learn how Amazon Connect helps organizations of all sizes build accessible, scalable contact experiences, visit the Amazon Connect product page.