AWS Public Sector Blog

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.

Building AI agents for domain-specific classification at scale

Aditya Singh — Fri, 17 Jul 2026 12:56:43 +0000

Organizations across industries face a common challenge: transforming unstructured, domain-specific data into standardized classifications while maintaining accuracy, auditability, and compliance. Whether it’s criminal charges in law enforcement, medical diagnoses in healthcare, or regulatory codes in financial services, manual classification is time-consuming, error-prone, and difficult to scale.

This post shows how public sector and enterprise teams can build an agentic AI-powered classification system on Amazon Web Services (AWS) using the Strands Agents SDK, Amazon Bedrock, and serverless services. You will learn the architecture, the agent workflow, and how to implement this system using the Strands Agents SDK. The approach uses agentic reasoning and web-grounded validation to produce explainable classifications backed by authoritative source citations, reducing manual effort, improving consistency, and creating a complete audit trail for compliance.

Challenges

Establishing effective classification systems for domain-specific data requires substantial effort and expertise. Traditional approaches rely on manual review, static rule engines, or basic machine learning models that lack contextual awareness. This creates significant challenges.

Understanding classification logic means reviewing code or documentation: Each system implements its own approach, leading to inconsistency and redundant effort across teams.
Classification rules couple tightly to application code and are difficult to adapt: This makes updates painful as regulations evolve and limit flexibility when expanding to new standards or jurisdictions.
Auditing and governance are fragmented: Teams don’t centralize reasoning or make it transparent, making it difficult to track who changed what classification logic and when.
It’s time-consuming: Significant development effort is required for each new classification domain or jurisdiction.
As data volumes grow, monolithic classification components become performance bottlenecks.

Solution

To address these challenges, the architecture uses an agentic AI classification system built with the Strands Agents SDK and Amazon Bedrock. The Strands Agents SDK is an open-source framework that enables developers to build AI agents capable of multi-step reasoning and autonomous tool use with just a few lines of code. Amazon Bedrock provides access to foundation models that power the agent’s reasoning. Together, they enable a system where each classification isn’t only a lookup but an autonomous reasoning task: the agent analyzes input, researches authoritative sources, synthesizes a decision, and documents its rationale with citations.

To operate at scale, the agent runs within AWS Lambda, with Amazon Simple Queue Service (Amazon SQS) managing asynchronous batch processing and Amazon DynamoDB persisting every classification with its full reasoning trail. A web search API grounds each classification in authoritative public sources such as statutes, regulations, and official guidelines. Teams that prefer a fully controlled knowledge corpus can replace the web search component with AWS retrieval services such as Amazon Bedrock Knowledge Bases.

The following diagram shows how the system simplifies classification with decentralized, context-aware AI agents. Each component handles a specific responsibility, from ingestion to reasoning to audit persistence.

Figure 1: Domain-specific classification with agentic AI and web-grounded reasoning

A producer uploads a CSV file (or sends a single record) to an Amazon Simple Storage Service (Amazon S3) input bucket.
Amazon EventBridge reacts to the object-created event and triggers a splitter Lambda function that batches records and enqueues them to Amazon SQS.
The processor Lambda function consumes batches from Amazon SQS and invokes the Strands agent for each record. The agent, running on Lambda, calls Amazon Bedrock for foundation model inference.
The agent uses the classification context provided (domain rules, jurisdiction, and temporal parameters) and calls a web search tool to retrieve authoritative sources (statutes, regulations, and official guidelines), then synthesizes a classification with reasoning and citations.
The agent writes the result, including confidence score and source URLs, to DynamoDB; an optional S3 export bucket stores reports for downstream systems.
Amazon CloudWatch captures token metrics and OpenTelemetry traces for full agent observability, including reasoning steps, tool invocations, model latency, and cost tracking.

Use cases

This agentic classification approach applies to multiple industries. Organizations across the public sector and regulated industries can use these autonomous agents to standardize domain-specific data at scale:

Law enforcement agencies can classify free-text criminal charges into standardized offense codes (such as those used in national incident-based reporting) for consistent reporting across jurisdictions, with citations to the underlying statutes.
Healthcare organizations must map clinical diagnoses and procedures to ICD-10 and CPT codes for billing and compliance. The agent can analyze physician notes, procedure descriptions, and patient context to suggest appropriate codes with confidence scores, flagging ambiguous cases for human review.
Financial services firms need to classify transactions into regulatory reporting categories (SAR, CTR) based on transaction patterns, amounts, and contextual factors. The system can autonomously research regulatory guidance and apply jurisdiction-specific rules.
Transportation agencies require classification of incident reports into standardized categories for safety analysis and federal reporting. The agent can process narrative descriptions and classify incidents with references to relevant safety standards.

Agent workflow: From input to decision

The system uses structured prompts and tool definitions to guide the AI agent’s reasoning process. Each classification request follows a sophisticated multi-step workflow:

At the core of every classification lie several critical components:

1. Input context

All available information about the item being classified.

Field	Description
Primary data	The text or description requiring classification.
Domain context	Geographic location, applicable regulations, industry standards, or domain-specific codes.
Temporal context	Date, time, or period relevant to classification rules.
Metadata	Additional attributes that influence classification decisions.

2. Reasoning process

The agent follows a structured approach.

Analyze: Examine input data and identify key classification indicators.
Research: Search for authoritative sources, statutes, or standards.
Synthesize: Combine information from multiple sources to determine the classification.
Validate: Assess confidence based on source quality and completeness.
Document: Generate detailed reasoning with citations.
The agent can also draw on reasoning from prior classifications to guide its research on similar inputs, improving consistency over time and reducing redundant source lookups.

3. Output

Each classification includes the following fields.

Field	Description
Code	The standardized code or category.
Description	Human-readable name of the classification.
Confidence	Numerical value (0.0–1.0) indicating certainty.
Reasoning	Detailed explanation citing specific sources.
Citations	URLs and references to authoritative sources.
Review flag	Flag set when confidence is below threshold (for example, 0.60).

Implementing the agent with the Strands Agents SDK

The agent is concise. With the Strands Agents SDK, the team defines a system prompt that encodes the classification policy, registers a set of tools, and lets the agent loop until it produces a structured result. The following snippets are illustrative reference code.

Defining a tool for authoritative source lookup:

from strands import Agent, tool
from strands.models import BedrockModel

@tool
def web_search_statute(query: str, max_results: int = 3) -> str:
    """Search authoritative sources for classification decisions."""
    results = search_client.search(query=query, max_results=max_results)
    return json.dumps([
        {"title": r["title"], "url": r["url"], "snippet": r["content"][:500]}
        for r in results.get("results", [])
    ])

Creating the agent with a Bedrock-hosted foundation model:

model = BedrockModel(
    model_id="us.anthropic.claude-sonnet-4-6-20250929-v1:0",
    region_name="us-east-1",
    temperature=0.1,
)

agent = Agent(
    model=model,
    tools=[web_search_statute],
    system_prompt=get_classification_prompt(),
)

Invoking the agent on a single record:

request = {
    "charge_text": "DWI 2nd Offense",
    "state": "CA",
    "statute_code": "23152",
    "offense_type": "Misdemeanor",
}

response = agent(json.dumps(request))
classification = json.loads(response.message)

Sample classifications

The following examples show how the agentic classification system handles real-world inputs using synthetic data. Each diagram shows the input, the agent reasoning process, and the structured output.

Law enforcement – criminal charge classification: Law enforcement agencies receive criminal charges in varied formats from different jurisdictions. The agent normalizes these into standardized offense codes regardless of wording or jurisdiction, as shown in the following figure.

Figure 2: Multiple charge descriptions from different states normalize to the same offense code through independent agent invocations

Healthcare – diagnosis code mapping: Healthcare providers need to map clinical notes to ICD-10 codes. The agent parses clinical indicators, searches coding guidelines, and produces a classification with confidence scoring, as shown in the following figure.

Figure 3: Clinical note classification showing input, agent reasoning, and structured ICD-10 output

Financial services – transaction classification: Financial institutions must identify suspicious transaction patterns for regulatory compliance. The agent analyzes patterns, researches FinCEN guidance, and determines regulatory actions, as shown in the following figure.

Figure 4: Transaction pattern classification showing input, agent reasoning, and regulatory output

Next steps

Agentic AI classification shifts domain-specific data processing from brittle rule engines to autonomous, explainable reasoning. The architecture described here delivers:

Transparency: every classification includes detailed reasoning and source citations
Adaptability: the agent autonomously researches evolving statutes and regulations
Scalability: serverless components handle variable workloads efficiently
Governance: a full audit trail captures every decision and the reasoning behind it
Quality: confidence scoring and human-in-the-loop review let teams calibrate accuracy to their risk tolerance

To get started:

Explore the Strands Agents SDK on GitHub to build AI agents.
Review the Amazon Bedrock documentation to learn about accessing foundation models.
Visit the AWS Public Sector page or contact your AWS account team to evaluate this architecture for your organization.

How Rize Credit Union built a serverless data lake on AWS to become its own source of truth

George Estrada — Tue, 14 Jul 2026 20:58:24 +0000

Credit unions exist to serve members, not to run data centers. Every hour our team spends on infrastructure is an hour not spent on the question a member actually cares about: “Is my money safe, is my experience easy, and is my credit union on my side?” Moving to a serverless, managed-service foundation on Amazon Web Services (AWS) means our engineers spend their time on membership modeling, fraud analytics, and AI augmentation instead of capacity planning.

When I joined Rize Credit Union as chief technology and innovation officer, our data looked like most $1.5B credit unions’ data looks: everywhere and nowhere at the same time. Structured records lived inside our Jack Henry Symitar core. Contact-center interactions sat inside Talkdesk. Survey results, vendor extracts, and one-time files lived on shared drives and in individual inboxes. Every report was a negotiation, and every “source of truth” had a footnote. This post is the story of how a small team used AWS managed services to replace that sprawl with a single, serverless, data lake built for the cloud, and why the architecture matters more than any one dashboard it produces.

A Windows-centric shop with no center of gravity

Credit unions are vendor-dependent by design. Symitar alone supports nearly 700 credit unions, and around that core sits a constellation of point solutions for lending, payments, servicing, digital banking, and member experience. At Rize, that meant structured and unstructured data scattered across systems we didn’t own, on cadences we didn’t control, with semantics that didn’t agree. We had no centrally reliable place to ask a question and trust the answer.

The deeper issue was due to organizational physics rather than a technical issue. A two-person data engineering team can’t overcome that kind of entropy by managing more servers. We needed leverage. We needed our people focused on serving members, not patching virtual machines (VMs). And we needed an architecture that a small team could actually reason about, change safely, and extend without rewriting.

A serverless, managed, cloud-based solution

We built the data lake entirely on AWS using a template for a credit union lake, and we followed a deliberate rule: no long-running compute and no self-managed servers. Every component had to be a managed service we could define in code and then leave to function automatically. The backbone includes:

Amazon Simple Storage Service (Amazon S3) as the single storage substrate, organized by medallion layer (raw/, bronze/, silver/, gold/)
AWS Glue for ingestion and transformation jobs
AWS Step Functions and Amazon EventBridge for orchestration and scheduling
Amazon DynamoDB as a change data capture (CDC) state tracker, recording the last log sequence number on every load so a failed job resumes exactly where it stopped
Apache Iceberg tables on Amazon S3 for atomicity, consistency, isolation, durability (ACID) transactions and time travel
AWS Lake Formation for fine-grained, column-level access control
Amazon QuickSight for analytics delivery
Microsoft Entra ID federated into AWS for identity, with AWS Identity and Access Management (IAM) handling service-to-service automation

Everything is managed through Terraform across three repositories—core data lake, networking, and platform—to enhance portability and resiliency. For a learning team, infrastructure as code (IaC) is a best practice as well as a safety net that makes speed possible.

Investing in solving the credit union data model

One architectural detail deserves its own paragraph, because it trips up every vendor we talk to. Traditional banks use a data structure based on products: a checking account is the top-level entity, to which all other account information is connected. Credit unions add a parent layer called the membership. People attach to memberships. Products (such as shares, loans, or cards) attach to memberships. People can also attach directly to products. A single member can hold multiple memberships, each with multiple products, creating a many-to-many web that is substantially more complex than the product-centric model most off-the-shelf analytics tools assume. A meaningful share of our engineering effort went into decoupling and normalizing those relationships so the data is high-fidelity and consumable downstream.

OpenMetadata for governance

The AWS Glue Data Catalog is excellent for technical metadata, but most of our nontechnical staff aren’t going to sign in to the AWS Management Console to find a table. We deployed OpenMetadata on top of the lake as our governance layer and search surface. Business users search for datasets by keyword. Every gold-layer column carries field-level documentation, including the specific values a field can take. A “transaction category” column advertises fee, ATM, transfer, payer to payer (P2P), Automated Clearing House (ACH), and payroll instead of forcing someone to guess. Personally identifiable information (PII) is tagged at the column level, which means if a vendor ever has a breach, we can scope our exposure in minutes instead of weeks. Ownership is assigned to teams, so data quality alerts route to the people who can actually fix them rather than piling up in my inbox.

How AWS helped—beyond the services

I use AWS for everything, and I want to be specific about what “everything” means, because the services are only half of it. The other half is the people. Solutions architects, specialist SAs, and the conversations I have at the annual AWS re:Invent conference and the AWS Summits throughout the year have shaped this architecture as much as any documentation page. When we hit the credit union membership modeling problem, when we debated Iceberg versus Hudi, when we weighed a hub-and-spoke network topology against alternatives—those decisions were sharpened in whiteboard sessions with AWS architects who had seen the patterns before. For a small team trying to punch above its weight, that access is a force multiplier.

Results

The results we generated have increased efficiency and resiliency. They include:

One source of truth – Data from Symitar—Advanced Reporting for Credit Unions (ARCU) and a near real-time Software-Defined Storage (SDS) replica—Talkdesk, vendor extracts, and APIs now land in a single S3 bucket daily, after core end-of-day balancing provides general-ledger integrity.
Zero standing compute – The entire pipeline is serverless. There is no cluster to babysit, no VM to patch, no license to administer.
Resumable, lossless loads – CDC plus the DynamoDB state tracker means a failed job picks up from the exact log sequence number it left on with no duplicates or no gaps.
Storage savings through Iceberg – Our legacy approach stored a full daily snapshot of every table. Iceberg only records what changed, dramatically shrinking the storage footprint while preserving a full history of the records from creation forward.
Built by two engineers – The platform currently running daily analytics for a $1.5B institution is maintained by a two-person data engineering team. That ratio is the outcome that matters most.

What’s next

The architecture was designed for the next phase, not only the current one. The CDC infrastructure and Iceberg tables already support real-time ingestion, but we haven’t had a business case that requires sub-daily data yet. Event-driven integration logs from our frontend applications will be added to the lake next, enabling fraud analytics and proactive member notifications. OpenMetadata’s field-level documentation will ground an AI layer so natural-language queries run against accurate, governed context instead of hallucinated schemas. We’ll consolidate from US-West (N. California) – us-west-1 into US-West (Oregon) – us-west-2 AWS Regions to eliminate cross-Region transfer costs. We’ll split our current single-account environment into dedicated production and development accounts with fully automated continuous integration and continuous delivery (CI/CD).

If you’re a credit union CIO or CTO staring at the same sprawl we started with, my call to action is straightforward: don’t try to overcome entropy by force. Pick a serverless, managed-service foundation, define it in code, and let a small team do the work. And don’t wait a decade to decide. As Andy Jassy puts it, “Speed is not preordained—it’s a choice.” You can’t flip a switch and suddenly have it; you have to architect it into the organization by building a culture of urgency and a willingness to experiment. Speed is something you do, not something you inherit. That’s the move. We’re happy to compare notes.

To learn more, visit Rize Credit Union. To explore a digital transformation for your credit union, connect with the AWS team. This specialized team delivers flexible cloud solutions to help credit unions better serve their members.

Accelerate regulatory package processing with agentic AI on AWS and Databricks

Sanjeev Pulapaka — Tue, 14 Jul 2026 12:49:35 +0000

Federal agencies process millions of conformity packages annually—documentation that verifies products, services, and federal actions meet specific regulatory standards. Whether it’s certifying a vehicle is safe to drive or confirming a project meets environmental standards, these packages play a vital role. They’re the gatekeepers making sure the public stays safe, the environment is protected, and regulations are followed. Yet the manual processes used to review them have barely evolved in decades. With AI enabled conformity package processing the time to approve the package improved significantly.

The result is predictable: mounting backlogs, extended review timelines, inconsistent determinations, and overburdened staff. Submission volumes continue to grow while staffing remains flat. The complexity and variety of conformity requirements across regulatory domains—spanning certificates of conformance for contract supplies, general certificates of conformity for consumer product safety, environmental compliance documentation, import/export declarations, and technical test reports—compound these challenges further.

Amazon Web Services (AWS) offers a fundamentally different approach. By deploying agentic AI—specialized AI agents that work collaboratively to analyze, validate, and route documentation—federal agencies can dramatically accelerate conformity processing while maintaining or improving quality and compliance standards. The goal isn’t to replace human expertise — it’s to make better use of it. Let AI handle the routine validation work and flag what needs attention, so the experts can spend their time where it matters: making judgment calls, interpreting nuance, and tackling the hard problems.

Rethinking regulatory processing from the ground up

Traditional conformity processing is linear and labor-intensive. A package arrives, sits in a queue, gets assigned to a reviewer, and moves through a series of manual checks. Each check requires the reviewer to locate relevant standards, cross-reference databases, verify completeness, and document their determination. The process works—but it doesn’t scale.

Agentic AI reimagines this workflow as a collaborative system of specialized agents, each responsible for a distinct aspect of the review. Built on Amazon Bedrock and Amazon Bedrock AgentCore, and integrated with Databricks hosted on AWS for data processing and analytics, the system operates like a well-coordinated review team rather than a single overloaded examiner.

The architecture uses the managed gateway and routing capabilities of AgentCore to orchestrate the agent workflow, and Databricks provides the data platform backbone—handling large-scale data extraction from legacy systems, running compliance analytics, and exposing these capabilities to the agents using the Model Context Protocol (MCP). This combination delivers the intelligence of agentic AI with the data engineering power needed to process regulatory packages at scale.

Architecture overview

The solution architecture integrates AgentCore with Databricks to create a comprehensive agent-based processing pipeline. As shown in the following diagram, the design follows a gateway pattern where AgentCore handles agent orchestration, authentication, and memory, and Databricks provides the data processing, extraction, and custom tooling layer.

Figure 1: Agentic AI architecture for regulatory package processing

The flow begins when a user submits a regulatory package through the Agent UI, with the request authenticated using Amazon Cognito. The UI invokes the Strands agent running on AgentCore Runtime, which performs the orchestration, reasoning, and validation. To reach external capabilities, the agent calls AgentCore Gateway, a managed MCP endpoint that aggregates multiple backend targets and exposes them to the agent as a unified set of MCP tools.

AgentCore Gateway routes tool invocations to two target categories:

Lambda target – A Lambda target backed by AWS Lambda functions executes business processing rules—the regulatory logic that determines which standards apply, what validation checks are required, and how to route edge cases. Independently, the agent uses AgentCore Memory to maintain short-term conversational context and long-term processing knowledge, enabling agents to learn from past determinations and maintain consistency across reviews.
MCP target – An MCP target pointing at Databricks managed MCP servers (with tool and data access enforced by Unity Catalog) is where the comprehensive solution comes together. Databricks, hosted on AWS, provides the heavy-lifting data capabilities that regulatory package processing demands through its managed MCP servers for AI/BI Genie spaces, Vector Search, Unity Catalog functions, and Genie (natural-language SQL over Databricks SQL warehouses), plus custom MCP servers hosted as Databricks applications for agency-specific tools.

Together these expose data extraction from legacy systems, analytics across historical compliance records, and custom tool integrations that agents can invoke on demand. Databricks Unity Catalog sits alongside this call path as a control-plane governance layer, providing visibility, access policy management, and audit logging across MCP interactions. Amazon Simple Storage Service (Amazon S3) serves as the shared storage layer, holding submitted packages, extracted data, and processing artifacts accessible to both the AgentCore pipeline and Databricks workloads.

Why AgentCore integrated with Databricks

Regulatory package processing is as much a data challenge as it is an AI challenge. Agencies maintain decades of compliance records in legacy systems, structured databases, and document repositories. Making this data accessible to intelligent agents requires a platform that can handle extraction, transformation, and real-time querying at scale.

AgentCore provides the agent runtime: managed infrastructure for deploying, securing, and scaling AI agents with built-in authentication, memory, and tool integration. Databricks provides the data runtime: a unified analytics platform capable of processing massive datasets, connecting to legacy data sources, and serving results back through standard protocols.

The MCP integration between them makes the solution comprehensive. Rather than building point-to-point integrations between each agent and each data source, AgentCore Gateway aggregates the Databricks managed MCP servers and Lambda business rules into a single MCP endpoint. Agents running on AgentCore Runtime can query compliance databases, extract data from legacy objects, invoke custom validation tools, and retrieve historical precedents—all through a single, standards-based protocol. This dramatically simplifies the architecture while maintaining the flexibility to add new data sources and tools without modifying the agent logic.

What the system delivers

At its core, the solution delivers capabilities that transform how agencies handle conformity packages:

Intelligent document classification – Automatically categorizes incoming documents—certificates, test reports, technical drawings, correspondence—and identifies the applicable regulatory framework without human intervention.
Multi-source data validation – Enables agents to cross-reference submitted information against internal compliance databases, historical approval records, industry standards repositories, and regulatory requirement catalogs simultaneously—powered by Databricks’s ability to query across disparate data sources in real time. What might take a human reviewer hours of manual lookup happens in seconds.
Automated compliance checking – Applies business rules through Lambda functions to validate that submissions meet all mandatory requirements—completeness, accuracy, and adherence to specifications—with consistency that human reviewers can’t match across thousands of submissions.
Legacy data extraction through Databricks MCP servers – Enables agents to reach into existing systems of record—databases, file stores, and legacy applications—without requiring those systems to be rebuilt or migrated. This is critical for agencies with decades of institutional data locked in older platforms.
Custom tool integration – Allows agency-specific validation logic, external API calls, and specialized processing to be exposed as tools the agents can invoke autonomously, extending the system’s capabilities without modifying the core architecture.

Putting it into practice: Vehicle import conformity

Consider a federal agency that processes thousands of vehicle import applications annually, verifying that imported vehicles conform to Federal Motor Vehicle Safety Standards (FMVSS). The manual process involves reviewing Vehicle Identification Number (VIN) structures, validating manufacturer certifications against approved lists, cross-referencing crash test data and recall databases, and verifying emissions compliance documentation—all before making a conformity determination.

With the AgentCore and Databricks solution, the workflow becomes significantly more streamlined. When a submission comes in through the Agent UI, it’s authenticated via Amazon Cognito. From there, the Strands agent running on AgentCore Runtime calls AgentCore Gateway, which routes the request to a Lambda function. That function applies business rules to figure out which FMVSS standards are relevant for the vehicle class being submitted.

Through the same AgentCore Gateway endpoint, the agent invokes the Databricks managed MCP servers to extract historical data from legacy compliance databases—prior approvals for this manufacturer, recall history for similar vehicle types, and cross-references against known non-conforming patterns.

The agents synthesize these inputs: VIN structure validation against the manufacturer database, completeness checks against required documentation, and anomaly detection comparing this submission to historical patterns. If everything aligns, the system flags the application for expedited approval. If anomalies surface—a VIN structure inconsistent with the claimed manufacturer, or missing crash test documentation, for example—the system escalates to a human expert with a focused summary of exactly what needs attention and why.

The result is a dramatic reduction in review time for straightforward applications, while giving complex cases the human judgment they require.

Agencies positioned to benefit

The pattern applies broadly across the federal government:

The Environmental Protection Agency can accelerate General Conformity determinations for federal actions affecting air quality, using Databricks to analyze emissions data across State Implementation Plans.
The Consumer Product Safety Commission can process General Certificates of Conformity more efficiently by validating testing laboratory accreditation against historical databases.
The Federal Aviation Administration can enhance aircraft conformity inspections by cross-referencing configuration documentation against type certificate databases spanning decades of certifications.
The Food and Drug Administration can accelerate product registration packages for food, drugs, and medical devices—domains where legacy data in older systems is particularly valuable for pattern detection.
Customs and Border Protection can expedite import declarations by validating certificates against product classifications and trade agreement requirements in real time.
The Department of Defense can strengthen supply chain security by cross-referencing contractor certificates against known counterfeit patterns across the defense industrial base.

Each agency shares the same fundamental challenge: high submission volumes, complex regulatory requirements, constrained resources, and critical data locked in legacy systems. The AgentCore and Databricks architecture addresses these challenges simultaneously.

What agencies can expect

Organizations implementing this architecture for conformity processing can expect significant improvements across multiple dimensions. Initial review times can be reduced up to 60–80%, helping agencies clear backlogs and meet statutory deadlines. Processing errors and rework decrease up to 40–50% as automated validation catches inconsistencies that human reviewers might miss during high-volume periods. Throughput capacity increases by 3–5 times without proportional staffing increases.

Perhaps most importantly, the system delivers consistency—standardized application of regulatory requirements across reviewers, regions, and time periods—along with complete transparency through audit trails that show exactly how each determination was reached. Human experts spend their time where it matters most: complex cases, policy interpretation, high-risk determinations, and the kind of nuanced judgment AI can’t replicate.

Implementation considerations

Government deployments require careful attention to several dimensions. Security and privacy are foundational—implementations must use FedRAMP-authorized cloud services with encryption of sensitive data and full compliance with federal information security requirements. AWS GovCloud (US) provides the isolation and compliance controls necessary for these workloads, and Databricks on AWS supports deployment within these boundaries.

Human oversight remains essential. Critical decisions, precedent-setting cases, and enforcement actions must involve human review and approval—AI serves as a decision support tool, not a replacement for human judgment. Systems must also accommodate frequent regulatory updates and evolving compliance requirements without extensive reprogramming, and all AI-generated assessments must be explainable to regulated entities with clear reasoning supporting determinations.

Data quality is foundational to success. The Databricks layer requires clean, well-structured connections to legacy data sources representing the full range of conformity package types and scenarios. Agencies should plan for an initial data integration phase to map existing systems into the MCP-accessible layer.

Conclusion

The future of regulatory compliance is collaborative intelligence: AI agents running on AgentCore handling high-volume, rules-based processing, integrated with Databricks for comprehensive data access, while human experts focus on the work that truly requires their expertise. To explore how this architecture can transform your agency’s conformity processing, visit the companion reference implementation on GitHub, which provides a starting point for an AgentCore deployment with hooks for Databricks integration.

To learn more about building agentic AI solutions for government, explore Amazon Bedrock and Amazon Bedrock AgentCore, or contact your AWS account team to discuss how agentic AI integrated with your existing data platform can accelerate your regulatory workflows.

AWS GitHub Repo – https://github.com/aws-samples/sample-databricks-mcp

About the authors

Figure 2: Author headshot placeholder

Sanjeev Pulapaka is a Principal AI Architect for US Federal Civilian at Amazon Web Services (AWS). He leads the cross-agency initiative shaping how the federal government moves from AI experimentation to mission-critical agentic AI systems—setting technical direction, building governance frameworks, and producing the thought leadership that drives responsible adoption at national scale.

Nikhil Nayar is a Solutions Architect at Amazon Web Services (AWS). He focuses on helping the US federal government accelerate its journey to the cloud and applied AI solutions. Before joining AWS, Nikhil spent 16 years in the field of enterprise architecture and development, working with enterprise customers and service providers.

How Iowa State University’s Translational AI Center is feeding the future with generative AI and computer vision on AWS

Soumik Sarkar — Mon, 13 Jul 2026 22:58:58 +0000

From on-premises lab prototype to globally scalable pest intelligence

When a farmer in central Iowa spots an unfamiliar insect on their crop, every hour matters. Waiting days for a county extension agent visit or thumbing through reference guides can mean the difference between a targeted spot treatment and a costly full-field chemical application. Iowa State University’s Translational AI Center (TrAC) asked a bold question:

“What if every farmer had an AI entomologist and agronomist in their pocket?”

The Challenge: $120 Billion in Annual Crop Losses

U.S. agriculture loses an estimated $120 billion annually to pests, weeds, and diseases. Farmers face a time-critical identification challenge—misidentifying a pest or weed by even a few days can mean the difference between a targeted treatment and a full-field chemical application. Traditional identification methods rely on manual scouting, county extension visits, or reference guides, none of which scale to the millions of decisions farmers make each growing season.

Meet TrAC: Iowa State’s AI Research Engine

The Translational AI Center (TrAC) at Iowa State University is a pre-competitive research hub that bridges the gap between academic AI breakthroughs and real-world deployment. With over 70 affiliated faculty spanning seven ISU colleges, TrAC breaks down disciplinary silos and organizes research across thematic areas, including food and energy systems, healthcare, autonomy, materials design, and AI ethics.

TrAC operates through three interconnected pillars: AI-driven research, training, and workforce development, making it both a research engine and an educational hub. Through seminars, workshops, AI microcredentials, and an industry-funded seed grant program, TrAC cultivates the next generation of AI practitioners while accelerating the translation of laboratory prototypes into field-ready tools.

As home to AIIRA, one of the National AI Institutes, and with over $35 million in federally funded AI research, TrAC represents one of the nation’s most concentrated efforts to apply artificial intelligence to agricultural challenges at scale.

PestID: Foundation Models for the Field

PestID is TrAC’s flagship agricultural AI application—a smart phone-accessible tool that provides real-time pest and weed identification in 1–2 seconds. But beneath its simple interface lies a sophisticated AI pipeline built on custom-trained foundation models and generative AI.

Vision Transformer Architecture

At the core of PestID are two domain-specific foundation models developed entirely by the TrAC research team:

InsectNet — A Vision Transformer (ViT) model trained via self-supervised learning on 60TB+ of image data using approximately 200,000 GPU node hours across 64 A100 GPUs. InsectNet achieves 98.65% mean per-class accuracy across approximately 3,800 insect species, including 16 USDA-listed invasive species. The model maintains consistent accuracy regardless of insect size, validated across specimens ranging from sub-millimeter to 150mm.
WeedNet — A Global-to-Local AI foundation model achieving 92.6% accuracy across approximately 1,500 weed species, tested on both ground-based and drone-based imagery.

These are not off-the-shelf classifiers. TrAC’s team designed these as true foundation models—producing biologically meaningful embeddings that generalize across species and imaging conditions.

Generative AI for Actionable Guidance

Identification alone isn’t enough. Farmers need to know what to do once a pest is identified. TrAC’s pipeline integrates a Retrieval-Augmented Generation (RAG) module powered by Large Language Models to deliver:

Regionally contextualized Integrated Pest Management (IPM) recommendations sourced from university extension bulletins, field guides, and peer-reviewed research
Multi-language conversational support in 12+ languages, making the tool accessible to diverse farming communities globally
Expert-verified citations ensuring trustworthiness and traceability of every recommendation

The system employs a two-stage architecture: Stage 1 uses vision models for species identification with uncertainty quantification, and Stage 2 deploys a MultiRegionRetriever for location-specific pest management guidance spanning North America, Africa, and India.

Trustworthiness by Design

TrAC embedded guardrails directly into the AI pipeline—including Out-of-Distribution (OOD) detectors, Conformal Set Predictors, and ensemble methods—ensuring the system communicates uncertainty rather than hallucinating answers. When the model encounters an unfamiliar specimen, it says so.

How PestID Works: End-to-End AI Pipeline

The diagram below illustrates the complete PestID workflow—from a farmer’s smartphone photo to a personalized pest management recommendation delivered in 1–2 seconds:

Figure 1: PestID end-to-end pipeline on AWS

Scaling from Lab to Field: The AWS Partnership

TrAC’s models performed brilliantly in the lab. But serving thousands of concurrent farmers during peak growing season from an on-premises university data center presented three critical bottlenecks:

Concurrency — Limited server capacity couldn’t handle simultaneous requests during pest outbreaks
Latency — Delays between the generative AI module and users degraded the experience
Training scale — Retraining foundation models on expanding datasets required computing beyond what the university could provide

AWS partnered with TrAC to architect a phased cloud migration that preserved research agility while enabling production scale:

Phase 1: Auto-Scaling Inference

TrAC deployed InsectNet and WeedNet on Amazon SageMaker endpoints with auto-scaling—chosen because it lets the system dynamically grow from a handful of requests to thousands without manual intervention. Backed by AWS Deep Learning Containers and Amazon S3 for dataset management, this eliminated concurrency constraints. The system now scales on demand, paying only for the inference it consumes.

Phase 2: Cloud-Native Generative AI

The RAG module migrated to Amazon Bedrock, selected for its built-in Bedrock Knowledge Bases and retrieval API—enabling out-of-the-box retrieval-augmented generation without TrAC needing to build and maintain serving infrastructure. This dramatically reduced latency while providing access to state-of-the-art language models for conversational pest management guidance.

Phase 3: Full MLOps Pipeline (Planned)

The team is building an end-to-end machine learning training pipeline using AWS Parallel Computing Service for high-performance job scheduling, Amazon FSx for Lustre for high-throughput storage, and Amazon SageMaker Pipelines for automated model retraining and registry management. Frontend hosting on AWS Amplify enables continuous deployment from GitHub.

Real-World Impact

In pilot deployments across the U.S. Midwest during the 2023–2024 growing seasons, PestID demonstrated measurable impact across approximately 1,000 participating farms:

Metric	Result
Farmers in the pilot	~1,000
Identifications performed	10,000+
Estimated savings	$5M+
Pesticide over-application reduction	30% decrease
Response time per identification	1–2 seconds
Insect species covered	~3,800 species (98.65% accuracy)
Weed species covered	~1,500 species (92.6% accuracy)
Languages supported	12+

U.S. growers—particularly in Iowa and the U.S. Midwest states—are among the early adopters of PestID, using it to respond faster in-season, reduce unnecessary chemical inputs, and protect yields.

“PestID is useful to me for identifying the insects and being prepared for unknown pests as we are moving towards a dynamic environment.”

— Iowa Soybean Association Farmer

The Model for Academic–Cloud Partnership

The TrAC–AWS collaboration demonstrates a replicable model for bringing university AI research to a global scale:

AWS Research Credits — Cloud credits enable researchers to experiment at scale without capital investment, lowering the barrier from prototype to production
Pay-as-you-go infrastructure — Universities avoid over-provisioning hardware that sits idle outside peak research periods
Access to foundation models — Amazon Bedrock gives researchers immediate access to frontier LLMs without building serving infrastructure
Direct engagement with AWS account teams — Comprehensive technical architecture guidance accelerates migration timelines

For TrAC, this partnership means their AI innovations reach farmers faster. For farmers, it means access to PhD-level entomological expertise through a smartphone camera.

What’s Next

TrAC is expanding PestID to serve tens of thousands of concurrent users globally, with planned coverage across Sub-Saharan Africa and South Asia. The team is also exploring drone-based weed detection and expanding the foundation model suite to cover plant diseases.

TrAC is also developing interactive and gamified learning modules for K–16 audiences, covering weeds, insects, plant diseases, and invasive species. These efforts, combined with drone- and rover-based data activities, extend PestID beyond field diagnostics into workforce development and agricultural AI education.

The intersection of generative AI, computer vision, and cloud infrastructure is creating a new paradigm for agricultural decision support—one where academic innovation meets global-scale deployment to advance food security and sustainable agriculture.

Ready to scale your AI research?

Interested in bringing AI-powered agricultural tools to your institution? Contact the AWS Public Sector team to learn how AWS Research Credits can accelerate your path from prototype to production.

Iowa State University’s Translational AI Center is advancing AI-driven solutions across food systems, healthcare, materials design, and beyond. AWS partners with academic researchers worldwide to democratize access to cloud infrastructure and AI tools that accelerate discovery.

How CGI Federal and AWS delivered 50% performance gains and 6-month ATO for GSA’s financial management system

Kylie Horton — Sun, 12 Jul 2026 22:32:12 +0000

The United States General Services Administration (GSA) Pegasys Financial Management program plays a vital role in managing the agency’s financial operations, processing hundreds of billions of dollars in transactions annually for GSA and 40 partner agencies, boards, and commissions. When GSA needed to modernize the infrastructure supporting this mission-critical system, the agency faced a significant challenge. It needed to migrate 30 terabytes of production data, over 100 virtual machines, and 70 external system interfaces to the cloud—all within 6 months while maintaining uninterrupted availability.

Working with CGI Federal and Amazon Web Services (AWS), GSA not only met this ambitious timeline but exceeded expectations, achieving a 30% to 50% improvement in system performance, 20% cost reduction, and achieved Authority to Operate (ATO) in 6 months, which is approximately 2x faster than the benchmark for enterprise application ATOs across Federal Government agencies including GSA.

CGI Federal’s Momentum platform modernizes federal financial management

GSA implemented CGI Federal’s Momentum Enterprise Resource Planning system as the foundation for Pegasys. This U.S. Department of Treasury Financial Management Quality Service Management Office (FM QSMO) approved solution provides federally tailored capabilities that help agencies maintain accountability, comply with regulations and standards, and provide financial transparency to the American people. By integrating and streamlining budgeting, acquisition, and financial processes, Momentum facilitates data integrity, transparency, and auditability while enhancing compliance with federal standards.

GSA’s Cloud Smart strategy and broader federal modernization goals drove the decision to migrate Pegasys to a public cloud environment. The objectives were to achieve cost savings, improve operational efficiency, and position the system for future innovation. However, the scope presented significant technical and operational challenges in terms of migration complexity and timeline constraints.

The timeline was constrained by other critical Pegasys program initiatives. GSA scheduled the migration within a focused 6-month window to accommodate them. The team needed to achieve ATO within this compressed timeframe while maintaining uninterrupted availability for critical financial operations.

Proven migration methodology with AWS migration program

AWS offered compelling advantages for this migration, including cost efficiency, scalability, rapid innovation, and comprehensive security. AWS adheres to over 143 security standards and compliance certifications, including Federal Risk and Authorization Management Program (FedRAMP), and provided the foundation for achieving the compressed ATO timeline.

CGI Federal, an AWS Migration Competency Partner, accessed the AWS Migration Acceleration Program (MAP) to accelerate the timeline and reduce costs. MAP provided:

Proven three-phase methodology – The assess, mobilize, and migrate and modernize framework guided the migration from planning through execution
Cost reduction mechanisms – Financial support meant that CGI Federal to add resources that reduced risk in the project and accelerated the schedule
AWS expertise and tooling – Automated tools and AWS technical guidance streamlined execution
Pre-vetted partnership – GSA gained confidence through CGI Federal’s certified migration capabilities and proven track record

Migration approach

The migration began with a comprehensive assessment. The team evaluated system architecture, configurations, performance metrics, networking infrastructure, data requirements, and licensing needs. This assessment helped GSA understand cost projections for the target cloud architecture and identified optimization opportunities.

The mobilize phase included evaluating migration strategies using the 7 Rs framework, which consists of the common migration strategies of retire, retain, rehost, relocate, repurchase, replatform, and refactor. They then established a secure landing zone on AWS and conducted rigorous testing to validate migration readiness.

Based on this analysis, CGI Federal selected a lift and shift rehosting strategy—moving applications to AWS with minimal changes—to meet the accelerated timeline while maintaining system stability. This approach, which involves migrating applications to the cloud without redesigning their architecture, meant that GSA realized immediate cloud benefits while planning future enhancements and optimizations.

Immediate measurable impact

The migration delivered significant benefits across multiple dimensions:

Dramatic performance improvements – The Pegasys system achieved a range of 30% to 50% improvement in both online response times and batch job performance immediately after migration—without any application tuning. The modern AWS infrastructure provided immediate performance gains that enhanced user experience across all GSA users and the more than 40 partner agencies using the system.
Cost savings – The migration resulted in a 20% reduction in steady state hosting costs, and the accelerated timeline meant GSA realized savings earlier than anticipated. The move to AWS provided immediate access to modernized tools and cloud-based capabilities.
Enhanced reliability and operational agility – AWS Multi-AZ deployment increased system reliability to up to 99.99%—beyond what was available in the on-premises data center. The cloud environment enabled rapid provisioning, reducing wait times for new test environments from 1 week to 2 hours—a 97% reduction that significantly improved operational agility.
Continuous operations maintained – Despite the scale and complexity, the system maintained continuous operations across all 70 system interfaces throughout the migration, providing uninterrupted financial management services for GSA and partner agencies.
Rapid security authorization – The team achieved ATO on an aggressive timeline by leveraging AWS FedRAMP controls and comprehensive documentation. CGI Federal was able to quickly develop the required security plan and meet assessment milestones, demonstrating how cloud-based compliance and security capabilities can dramatically accelerate federal security authorization processes.

Foundation for continuous modernization

The successful migration establishes the foundation for GSA’s next phase of modernization. With Pegasys operating on AWS, the agency can use cloud-based services, including AI-enabled capabilities with Amazon Bedrock, advanced analytics for deeper operational insights, continued optimization through re-architecting, and robust disaster recovery with AWS Backup integration.

By using this two-phase approach—immediate migration benefits followed by ongoing modernization—GSA can continuously enhance system capabilities while maintaining operational stability at reduced cost.

Key takeaways for federal agencies

CGI Federal’s partnership with AWS demonstrates how federal agencies can accelerate cloud adoption while reducing risk:

Structured frameworks accelerate delivery – AWS MAP provides proven three phase framework (Assess, Mobilize, Migrate & Modernize) with tools and investments to reduce risk and compress migration timelines.
Cloud-based security speeds authorization – Using existing AWS compliance controls and comprehensive documentation can significantly reduce ATO timelines. AWS follows more than 143 security standards and compliance certifications, including FedRAMP, which provides a strong foundation for federal security requirements.
Migration competency matters – Partnering with AWS certified migration experts such as CGI Federal provides agencies with pre-vetted capabilities and proven execution. Migration Competency Partners have demonstrated success in helping customers migrate to AWS at scale.
Immediate value justifies investment – Performance improvements and cost savings materialize quickly, validating the business case for cloud migration.
Strategic approach enables continuous improvement – By using a phased migration strategy, agencies can realize immediate benefits while positioning systems for ongoing modernization. The lift and shift rehosting approach provided quick wins, and the cloud foundation enables future optimization.

Federal agencies evaluating cloud migration can apply these lessons to accelerate their own modernization journeys, reduce costs, and improve operational efficiency while maintaining mission-critical service delivery.

To learn more, visit the following resources:

To learn how AWS can help your agency accelerate cloud migration and modernization, contact the AWS Public Sector team.

AWS and Wiz accelerate resilience for academic medical centers

Bryan Rosensteel — Mon, 06 Jul 2026 20:25:18 +0000

Academic medical centers (AMCs) serve to connect the lab bench and the bedside, transforming complex academic research into a global standard of care. In 2026, the mission is more complex than ever: researchers are using generative AI to accelerate drug discovery, and clinicians require instantaneous access to patient data to save lives. This rapid pace of innovation, however, creates a vast and intricate digital footprint that must remain secure against increasingly sophisticated threats.

For the AMC CISO, the challenge is clear: How do you empower researchers to move at the speed of cloud while maintaining rigorous compliance and patient safety? Part of the answer lies in a unified approach. By combining the scalable, secure infrastructure of Amazon Web Services (AWS) with the deep visibility from Wiz’s AI-Application Protection Platform (AI-APP), AMCs can work towards a state of continuous compliance helping to remove security bottlenecks that can slow down innovations to drive clinical breakthroughs.

In this post, we discuss how AWS and Wiz support security and resilience for AMCs to help keep the focus more on patient care while maintaining a robust, secure operating environment.

Securing Epic on AWS

For most AMCs, the Epic EHR is a core element of clinical operations. Transitioning Epic to run as a managed workload on Amazon Elastic Compute Cloud (Amazon EC2) provides the scalability required for modern healthcare, but it also introduces the challenge of securing a monolithic environment without impacting clinical performance.

Managing Epic has been a source of operational pain, often due to the agent fatigue caused by traditional security tools. The combination of AWS and Wiz addresses this directly:

Performance-first security – Wiz’s agentless approach helps AMCs quickly scan their entire Epic-on-EC2 footprint without requiring additional resource overhead from traditional agents. This provides deep visibility into vulnerabilities and misconfigurations without the risk of blue-screening a critical clinical database or degrading the performance of frontline clinician workflows.
Full-stack Epic visibility – By mapping the entire Epic Graph, Wiz helps security teams see how an AWS Identity and Access Management (IAM) role, a network misconfiguration, and a software vulnerability might create a toxic combination that exposes patient records—all within the context of the AWS infrastructure.

Streamlining resilience

In line with the Trump Administration’s March 2026 Cyber Strategy for America, the federal posture has shifted toward Common-Sense Regulation (Pillar 2), which prioritizes operational readiness and offensive deterrence over administrative red tape. For AMCs, this means the goal of compliance is shifting from a checklist to a state of inherent resilience.

Although HIPAA remains the baseline for patient privacy, the final implementation of the Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA), expected to be finalized by CISA later this year, introduces tighter reporting windows for significant incidents. For AMCs, this means reporting substantial incidents within 72 hours and reporting any ransomware payments within 24 hours, regardless of the incident’s size. AWS and Wiz help support this transition by automating the data-gathering processes that typically burden clinical and research teams:

Automated context for HIPAA – AWS provides a secure foundation, and Wiz Data Security Posture Management (DSPM) continuously identifies and maps sensitive research data, personal health information (PHI), and personally identifiable information (PII) across Amazon Simple Storage Service (Amazon S3) buckets and Epic-associated volumes. With this solution, PHI and PII maintain compliance and are actively factored into risk assessments, so teams can prioritize remediation based on actual clinical impact.
Rapid traceback for CIRCIA – To meet 72-hour reporting windows, the Wiz Security Graph assists in tracing risks from exposed resources back to specific IAM roles or code commits in minutes. Wiz helps connect signals across the software lifecycle, from code to runtime, to support the operational continuity insights needed to rapidly understand the area of impact of an incident.

With these automated capabilities, AMCs can move toward the Secure by Design principles emphasized by the new regulatory landscape. Catching risks earlier in the software lifecycle reduces operational friction and when a threat arises, the institution’s focus remains where it belongs: on uninterrupted patient care.

Transparency in the research supply chain

Modern medical research relies on a complex digital supply chain. To maintain the integrity of clinical data, AMCs require a clear accounting of the software and cryptographic models running in their environments. By integrating with Amazon Elastic Container Registry (Amazon ECR), Wiz assists in automating the generation of vital bills of materials:

SBOM (software) – Providing an inventory of open source libraries to help identify vulnerabilities before they impact research.
CBOM (cryptography) – Helping teams identify legacy encryption that might require modernization in line with new federal standards, and take action to protect against Harvest Now, Decrypt Later (HNDL) attacks.
AI-BOM – A critical new field cataloging the models and training sets used in clinical AI, supporting transparency in how AI-driven insights are generated. This is particularly critical because federal research grant requirements from the NIH and NSF increasingly mandate AI-BOMs to ensure the integrity of AI-assisted clinical findings.

This visibility helps researchers innovate with confidence, knowing the building blocks of their applications are being continuously monitored for integrity.

Unified visibility for the research data lake

AMCs often use specialized platforms like Snowflake or Databricks on AWS to manage massive genomic or longitudinal studies. Historically, these platforms could exist as security silos, complicating the institution’s overall risk posture. The collaboration between AWS and Wiz helps extend visibility into these third-party environments. Wiz helps security teams view misconfigurations in a Snowflake warehouse or a Databricks Lakehouse alongside their AWS resources.

This visibility extends to AWS services like AWS HealthLake, which uses the Fast Healthcare Interoperability Resources (FHIR) standard to manage clinical data. Wiz helps secure these data stores with the same rigor as partner solutions. By unifying security for both on-premises health data stores and third-party platforms, Wiz provides a consistent single pane of glass to protect the vast data lakes that fuel institutional discovery.

Enabling Secure by Design innovation

In the AMC environment, shadow IT often emerges when security is perceived as a bottleneck to urgent research. By shifting security left into the development lifecycle, AMCs can integrate security earlier in the process, making it a seamless part of the clinical and academic workflow, and reducing the number of risks that enter production environments.

By using Wiz to scan infrastructure as code (IaC) templates (such as Terraform or AWS CloudFormation) before they are deployed to AWS, IT teams can support the creation of guardrailed sandboxes. With this proactive approach, research environments and the connections back to clinical data are built with institutional security standards from the start.

Wiz AI-APP and agentic defense

As AMCs adopt Amazon Bedrock and Amazon Bedrock AgentCore to build the next generation of clinical tools, they face a new category of AI-driven risks. Wiz AI-APP augments traditional Cloud-Native Application Protection Platform (CNAPP) capabilities and assists organizations in securing AI-integrated environments by helping identify AI-specific misconfigurations, including exposed model endpoints and over-privileged AI agents, before they can be exploited.

Furthermore, as the threat landscape evolves to include agentic threats (autonomous, AI-driven attacks), defense mechanisms must adapt. Wiz Agentic Security introduces AI-driven defenders that can investigate high-priority alerts at cloud speed. This helps security teams match the velocity of automated threats, helping protect sensitive clinical data and institutional intellectual property from autonomous exploitation.

Future-proofing for post-quantum cryptography readiness

In medical research, data longevity is paramount; genomic and longitudinal data remains sensitive for decades. This creates a unique HNDL risk, where data captured over the internet today could be decrypted by future quantum computing capabilities.

AWS is leading the way in quantum-resistant infrastructure, with several service endpoints, including AWS Key Management Service (AWS KMS), AWS Certificate Manager, and Amazon S3, already supporting Module-Lattice Digital Signature Algorithm (ML-DSA) and Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) quantum resistant algorithms. Wiz complements this by helping identify non-quantum-resistant algorithms across the AMC’s footprint. Together, they support the creation of a prioritized migration roadmap, helping safeguard today’s breakthroughs for the next century.

Conclusion

In the modern AMC, security is a vital component of the clinical care team to keep the integrated systems and patient records secure. The combination of AWS and Wiz offers a powerful framework for resilience, so the Epic EHR and the research data lakes that fuel discovery and clinical care are protected by design.

Although no single solution can provide total security, these automated capabilities help AMCs reduce administrative friction and keep their focus where it belongs: on the patients they serve and the innovations that save lives.

Ready to support your AMC’s mission with AWS and Wiz?

Explore Wiz on the AWS Marketplace
Learn more about AWS Healthcare and Life Sciences solutions
Connect with your AWS team to discuss Healthcare Landing Zone Accelerator on AWS

Accelerate IRAP readiness with AWS and Wiz

Bryan Rosensteel — Mon, 06 Jul 2026 20:24:03 +0000

Accelerate IRAP readiness with AWS and Wiz

As organisations modernise to meet the evolving expectations of the Australian Government, delivering secure, cloud-based services has become a commercial and operational necessity. This transformation brings a critical challenge: maintaining a hardened security posture while aligning to the Information Security Registered Assessors Program (IRAP) assessment requirements and priorities.

Under the Protective Security Policy Framework (PSPF), Australian Government systems must be secured at a level commensurate with the classification of the data they handle, ranging from Official to Top Secret. Rather than a static benchmark, these classifications dictate which Information security manual (ISM) controls are applicable based on a risk assessment.

The IRAP provides the independent validation necessary to ensure these chosen controls are effectively implemented. By inheriting a platform already IRAP-assessed for Protected workloads, agencies can use an established security baseline and focus their assessment efforts on their own application layer and data configurations, rather than revalidating the underlying infrastructure.

Amazon Web Services (AWS) and Wiz provide the visibility, architectural guardrails, and automated evidence collection required to streamline this journey. Through these capabilities, AWS and Wiz provide a strategic foundation that accelerates IRAP readiness activities, with reduced manual effort and greater clarity.

IRAP as a catalyst for risk-informed governance

To understand how AWS and Wiz accelerate IRAP readiness, it’s necessary to frame what IRAP requires. A common misconception is that an IRAP assessment is a pass-fail certification. It’s a risk-based assessment against the Australian Government ISM. IRAP covers a broad spectrum, including personnel and physical security, and the primary hurdle for most departments is the sheer volume of technical and operational controls that must be documented and monitored.

As manual assessment methods struggle to keep pace with cloud innovation, automated assurance becomes essential. The AWS and Wiz collaboration specifically accelerates these technical and operational layers, which are often the most complex to manage at scale. This partnership provides the real-time visibility and automated evidence collection needed to maintain a continuous compliance posture across any classification level, ensuring the technical foundation remains aligned with ISM requirements without slowing down delivery.

AWS and the Shared Responsibility Model

For organisations building a service for the Australian Government, the AWS Shared Responsibility Model becomes a starting point and force multiplier for automation. AWS manages the security of the cloud, providing infrastructure that has already been subject to IRAP assessments at the Protected level.

Deploying on AWS, service providers immediately inherit the security controls of the underlying global infrastructure. Through AWS Artifact, organisations can access IRAP summary reports and letters of compliance to provide assessors with evidence for the physical and environmental layers. Providers can shift their focus upward to security in the cloud, including the configurations, identities, and workloads where Wiz provides granular, contextual oversight.

How visibility drives risk decisions

Quantifying cloud risk is the bridge between compliance frameworks and operational confidence. In the Australian Public Sector, risk is strategically defined for all Commonwealth entities in the Resource Management Guide 211 (RMG 211) as the “effect of uncertainty on objectives.” When the objective is the successful delivery of a secure, resilient digital service, the uncertainty often stems from the complex, dynamic nature of the cloud environment. The ISM translates that risk thinking into the cybersecurity domain specifically.

The partnership between AWS and Wiz quantifies this uncertainty. By combining AWS services with Wiz’s ability to identify what they call “toxic combinations” of risk indicators, providers can present a clear risk posture to Australian government Authorising Officers (AOs). This clarity allows faster decision-making regarding whether the remaining uncertainty is acceptable in pursuit of the agency’s mission.

Hardening the modern stack (containers and serverless)

As previously discussed, using infrastructure that has already been subject to an IRAP assessment can provide a valuable starting point for service providers. However, this inheritance alone is not sufficient for a full IRAP assessment. There must also be demonstrated assurance that modern, ephemeral workloads such as Amazon Elastic Kubernetes Service (Amazon EKS) don’t inadvertently bypass established security guardrails.

AWS manages the EKS control plane, using the already IRAP-assessed AWS infrastructure, and the customer remains responsible for their worker nodes and containerised applications. Wiz provides agentless visibility into these runtime configurations, vulnerabilities, and permissions.

Because Wiz automatically detects toxic combinations, such as a container running with a high-severity vulnerability and a path to an AWS Identity and Access Management (IAM) role with elevated permissions, technical teams can remediate risks in minutes. This proactive risk management approach means that issues are resolved before they result in a control failure during a formal IRAP assessment.

Shifting security left (IaC and code repos)

Reducing the cost of market entry and long-term security maintenance by preventing noncompliant architectures from reaching production is a strategic goal for many organisations seeking IRAP assessment.

Organisations use AWS development tools, including AWS CloudFormation, Kiro integrated development environment (IDE), AWS CodeBuild, AWS CodeDeploy, and AWS CodePipeline, along with infrastructure as code (IaC) to build repeatable, secure patterns for the software development lifecycle. Wiz integrates into these continuous integration and continuous delivery (CI/CD) pipelines to enforce ISM-aligned guardrails prior to production deployment.

If a deployment script attempts to provision an Amazon Simple Storage Service (Amazon S3) bucket that is missing encryption or has public access enabled, Wiz flags this in the CI/CD pipeline. This provides proactive evidence for the IRAP assessor that controls are in place to prevent data exposure before it can occur.

Automated evidence for streamlined assessments

An effective strategy for accelerating IRAP readiness is to replace labour-intensive evidence gathering with an audit-ready posture. Automating these processes yields faster time-to-market value.

AWS provides baseline compliance data for the infrastructure layer through services such as AWS Security Hub and AWS CloudTrail. Wiz integrates with these services to deliver unified visibility and enhanced compliance analysis, normalising configuration data across the entire AWS footprint and mapping it directly to the controls defined in the ISM. By automating compliance evidence collection, organisations shorten assessment cycles and reduce the operational overhead of maintaining audit readiness.

During an IRAP assessment, instead of manual screenshots of security groups or virtual private cloud (VPC) configurations, providers can generate reports that demonstrate control effectiveness across the entire fleet simultaneously. This approach has been shown to save hundreds of hours of manual work for compliance assessments, including SOC 2 and FedRAMP, so assessors can focus on high-value risk analysis instead of data validation.

Global trend toward continuous assurance

These three use cases illustrate what is possible today. Globally, governments are already operationalising this approach at scale.

The shift away from point-in-time assessments towards continuous monitoring and mitigation of risk is gaining momentum worldwide. A notable example is the Operation StormBreaker initiative within the US government. Operation StormBreaker demonstrates the effectiveness of the Continuous Authorization to Operate (cATO) methodology to rapidly deliver secure mission services, reducing traditional deployment timeframes from 6–12 months to less than 15 minutes.

To achieve this speed to delivery, Operation StormBreaker relied upon streamlined processes and integrations, including Wiz and AWS integrations with RegScale, Harness, and others. These integrations enhanced automation and compliance reporting, and therefore teams could swiftly identify and prioritise risk remediation and demonstrate a data-centric approach to cATO compliance.

Australian service providers should draw directly on these parallels. The cATO methodology validated by Operation StormBreaker aligns closely with the continuous assurance model that IRAP-aligned organisations are building today. Adopting this mindset demonstrates to government clients that an organisation possesses the systemic maturity to manage risk every day, not only during an audit window.

Conclusion: Facilitating high-confidence risk management

The goal of any IRAP-aligned journey is to provide the foundation for innovation with confidence. By combining the IRAP-assessed infrastructure of AWS with the granular, contextual insights of Wiz, organisations transform security from a barrier to entry into competitive advantage.

Together, AWS and Wiz enable service providers to quantify their security posture, reduce the cost of compliance, and deliver secure, Protected services to the Australian Government. For details about how Wiz centralised security operations and modernised compliance, refer to the Wiz and Operation StormBreaker case study.

Ready to get started? Schedule a demo.

To learn more, visit:

Transforming Acquisition and Development with Operation Stormbreaker – FedGov Today, August 2025
Marine Corps Operation StormBreaker Slashes Software Delivery Timelines by 17x – GovCIO Media, July 2025
DoD Modernization Exchange 2026: Reducing ATO burdens – Federal News Network, April 2026
Breaking the 18-Month Barrier – Owl Cyber Defense, May 2026
Operation StormBreaker – Government Executive, December 2025

What does it cost to answer one question? Measuring per-request cost in agentic workloads

Mike George — Mon, 06 Jul 2026 20:21:51 +0000

The cost dimensions of agentic workloads on Amazon Web Services (AWS) are invisible to many organizations beginning their agentic journey. It’s straightforward to track tokens consumed because this dimension translates directly to your bill. But most organizations can’t determine the cost per request or the cost to answer a single user question. Without understanding the cost to answer a single user question, organizations are blind to cost issues. In this post, I talk about how to gain visibility into your agentic costs, and I identify three things you can do to better control your costs.

Understanding workload costs begins with per-request observability. Tracking only monthly token totals makes it impossible to make the decisions necessary for good cost management. If you’re running agentic workloads on AWS, you need to understand the cost of each user request, the number of cycles each request took, and how input tokens grew throughout those cycles. After you understand per-request observability, then there are three things you can do to better control your AWS agentic costs:

Think about model selection on a per-problem-solved basis not on a per-token basis.
Limit the number of agentic cycles in your workload.
Focus on tool design.

Unexpected ways your agentic costs increase

With a straightforward agentic workload, a user has a question, that question is sent to a model, and the model responds. The user’s question represents the number of tokens in, and the large language model (LLM) response represents the number of tokens out. You can easily calculate the price of that request.

However, the real world rarely follows the simple path. In many agentic workloads, a user has a question that is sent to a model, but the model can’t answer the question, so the model passes control back to the agent with a request to call a specific tool. The agent calls the tool, gets the results back, and returns the entire conversation history back to the model. In some cases, the LLM requests additional tool calls, and as each tool call is completed, the agent passes the entire conversation history back into the LLM until it can produce an answer for the user.

This means that as the number of tool calls increases, the size of the conversation history that is being sent to the LLM also increases. In cases where the agent requires three tool calls to answer a user’s question, your inference costs could be 5–10 times the cost of a single tool call. For example, say a user’s request is 100 tokens, the LLMs request to call a tool adds 50 tokens, and each tool call itself adds another 50 tokens. These three tool calls would add tokens as follows:

The agent sends the user request to the LLM:

100 tokens

The LLM requests tool use number one, which the agent passes back to the LLM:

100 original tokens + 50 tokens to call a tool + 50 tokens from tool result number one = 200 tokens

The LLM requests tool use number two, which the agent passes back to the LLM:

200 existing tokens + 50 tokens to call a tool + 50 tokens from tool result number two = 300 tokens

The LLM requests tool use number three, which the agent passes back to the LLM:

300 existing tokens + 50 tokens to call a tool + 50 tokens from tool result number three = 400 tokens

In this case, the input tokens across all four invocations of the LLM are:

100 + 200 + 300 + 400 = 1,000 input tokens

This is a tenfold increase of input tokens to the user’s original request.

You can’t improve what you don’t measure

As a best practice, you should regularly emit metrics from your agentic workload so you can better visualize the workload’s cost drivers. If you’re using Amazon CloudWatch, then the CloudWatch embedded metric format makes it straightforward to write out telemetry data to log files, which CloudWatch automatically turns into metrics that you can visualize and alarm on.

As an example, each time an agent requests that a tool be called as part of a user’s request, track the input and output tokens, model Id, and tool call number. This way, you can see how many tool calls are being performed and visualize the increase in input tokens as you fulfill a single user request. If you’ve built your agent using the Strands Agents SDK, then you can use its built-in mechanism for retrieving agent metrics.

Think about model selection on a per-problem-solved basis, not on a per-token basis

I built a simple Strands based agent that residents can use to find and qualify for social services, covering food assistance, housing, childcare, utilities, medical care, employment, and senior programs. By measuring the number of tool calls and total tokens required to fulfill each user’s request, I was able to identify several cost savings opportunities.

For example, I ran the workload with expected prompts using the Haiku 4.5 and Opus 4.8 models from Claude by Anthropic in Amazon Bedrock. Through this telemetry, I was able to determine that each user request cost about $0.006 with Haiku 4.5 and $0.14 with Opus 4.8, a cost that was 23 times greater for equivalent results, as illustrated in the following graphic.

Figure 1: Cost Comparison: Haiku 4.5 vs Opus 4.8 API Pricing

This means that if I’m expecting 1,000 requests per day, the workload with Opus 4.8 will cost about $4,200 a month ($0.14 per request x 1,000 requests x 30 days), whereas the same workload with Haiku 4.5 would cost about $180 a month. In my testing, both models produced equivalent results for this workload, meaning the 23x cost difference between the two models is wasted money.

Limit the number of agentic cycles in your workload

Remember that as the number of tool calls increases as part of a user request, the quantity of input tokens increases. This can result in a situation where a small number of users can drive the majority of the workload cost.

In the demo workload I built, I tracked the number of tool calls per request. I tracked p50 (the median) and p90 tool calls per request. In the following graph, you can see that most user requests require three or fewer tool calls. The p50 line stays at or below two tool calls, whereas the p90 line stays at three tool calls, indicating most requests complete within three cycles.

Figure 2: Tool Calls Per Request Over Time: P50 vs P90 Performance Metrics

When I graph the number of input tokens for each tool call, it’s apparent that there are some requests that make more than three tool calls. The following histogram shows the input token count for each tool call within a request. The later tool calls (calls number four and number five) consume significantly more input tokens than earlier ones, illustrating the compounding effect of resending conversation history.

Figure 3: Input Token Usage Across Six Tool Calls in Haiku 4.5

Each progressive tool call adds more input tokens. Because over 90% of requests can be completed in three or fewer tool calls, consider limiting the number of tool calls the agent can make. The tradeoff here is that there might be some complex requests that get incomplete answers. Because each additional tool call resends the entire conversation back to the LLM, tool call number four (for example) costs more than tool calls number one and number two combined. In this case, limiting tool calls is a deliberate decision so a few complex requests don’t negatively impact the monthly agentic budget.

The Strands Agents SDK supports interventions, which you can use to enforce limits programmatically. For example, using interventions, you can stop agent execution after three tools calls and return a partial answer to the user.

Focus on tool design

Tool requests stay in the conversation history and get resent with each subsequent invocation. Because of this, verbose tool responses have a compounding effect on LLM costs. If a tool returns 200 tokens of data when only 50 tokens is needed to answer the question, then the workload is costing an additional 150 tokens. An extra 150 tokens per tool call across three tool calls means 450 wasted tokens per request. At 1,000 requests per day, that’s 13.5 million wasted tokens per month.

In my example, I have a search_programs tool that returns program names, descriptions, eligibility criteria, and contact information. But in practice, only program names and descriptions are ever used. By reducing the tool output to the minimum needed, you reduce the context that accumulates over repeated tool calls.

The other way to optimize tool design is to focus on consolidating tool chains. By enabling tracing in your agentic workload, you can follow tool chains to see if the same tools are called with each user request or if the same tool is called multiple times in the same user request. In cases where several tools are always called in order, consider creating a single tool that returns all the necessary data, instead of multiple tool calls with growing context. The tradeoff here is flexibility, in that the agent gets one tool that returns a larger payload in a single call instead of building up context across multiple tool calls. If you have a well-understood workload with predictable access patterns, it’s worth testing both approaches and comparing the per-request cost.

Conclusion

Agentic workloads cost more than standard inference because each reasoning cycle resends the full conversation history to the LLM. Without per-request observability, you can’t see this happening until the bill arrives. By tracking cost per request, you can make informed decisions about model selection, tool call limits, and tool design before it becomes a problem.

To get started, emit metrics for your agent (consider using the CloudWatch embedded metric format) so you can begin tracking input tokens, output tokens, and tool call count per request. Then run your agent against 20–30 representative prompts and record the per-request token count and number of tool calls for each request. This data will indicate your cost distribution, which will help you determine which of the cost controls in this post will have the greatest impact on your workload.

To learn more, explore the C loudWatch embedded metric format to instrument your existing agents. If you’re building a new agent, consider getting started with the Strands Agents SDK. Finally, use the instrumentation and review Amazon Bedrock pricing to estimate your own per-request costs.

Validating infrastructure as code against FedRAMP 20x: Shift-left compliance

Dr. Tommy Kromer — Mon, 06 Jul 2026 20:14:13 +0000

Catching a compliance violation in production is expensive. Catching it in a pull request is nearly free. In this post, we demonstrate how to build a multi-tool infrastructure as code (IaC) validation pipeline that checks AWS CloudFormation templates and Terraform configurations against Federal Risk and Authorization Management Program (FedRAMP) 20x Key Security Indicators (KSIs) before deployment. Combined with the preventive controls from Preventive controls for FedRAMP 20x: Using SCPs and guardrails to enforce KSIs and the methods to be described in future blog posts, this creates a full-lifecycle compliance architecture.

The case for shift-left compliance

FedRAMP 20x requires that 70% or more of KSIs have automated validation. Most organizations focus that automation on runtime detection, using AWS Config rules and AWS Security Hub checks to find non-compliant resources after deployment. Shift-left compliance adds a layer before deployment: scanning IaC templates in your continuous integration and continuous deployment (CI/CD) pipeline to catch violations before resources are created.

This approach has three benefits for FedRAMP 20x:

Faster feedback. Developers learn about compliance issues in minutes, not days.
Reduced remediation cost. Fixing a Terraform variable is simpler than remediating a deployed resource.
Stronger evidence. Pipeline scan results become machine-readable evidence that your deployment process enforces KSI compliance.

Multi-tool validation strategy

No single tool covers every KSI across every IaC format. We use three complementary tools, each with strengths in different areas:

Tool	Best for	Format	KSI coverage
Open Policy Agent (OPA)/Rego	Custom policy logic, Terraform plan JSON	Terraform	64 policies across all KSI themes
cfn-guard	CloudFormation rule evaluation	CloudFormation	15 rules covering SVC, CNA, and IAM themes
Checkov	Broad static analysis, both formats	Terraform and CloudFormation	59 policies per format

The following figure shows how these tools fit into a full-lifecycle FedRAMP 20x compliance CI/CD pipeline alongside the preventive and detective controls from earlier posts, including:

Pre-deployment: IaC validation
Deployment: Service control policy (SCP) enforcement
Runtime: AWS Config rules
Real time: Threat detection
Throughout: Evidence at each stage feeding into the evidence lake

Figure 1: Full-lifecycle FedRAMP 20x compliance pipeline

End-to-end example: Validating a template against multiple KSIs

Consider a CloudFormation template that creates an Amazon Elastic Compute Cloud (Amazon EC2) instance with an Amazon Elastic Block Store (Amazon EBS) volume and a security group. This single template touches at least three KSIs:

KSI-SVC-VRI: The EBS volume must be encrypted
KSI-CNA-RNT: The security group must restrict inbound traffic
KSI-IAM-ELP: The instance profile must follow least privilege

OPA/Rego policy for encryption (KSI-SVC-VRI)

This policy evaluates a Terraform plan JSON file and flags any EBS volume that lacks encryption. The output is a structured denial message that maps directly to the KSI identifier.

package fedramp20x.svc_vri

import rego.v1

deny contains msg if {
resource := input.resource_changes[_]
resource.type == "aws_ebs_volume"
not resource.change.after.encrypted
msg := sprintf("KSI-SVC-VRI: EBS volume '%s' must be encrypted",
[resource.address])
}

cfn-guard rule for security groups (KSI-CNA-RNT)

This cfn-guard rule evaluates CloudFormation templates and denies any security group with unrestricted inbound access from the internet.

rule deny_unrestricted_ingress when %security_groups !empty {
%security_groups.Properties.SecurityGroupIngress[*] {
CidrIp != "0.0.0.0/0"
CidrIpv6 != "::/0"
}
}

let security_groups = Resources.*[
Type == "AWS::EC2::SecurityGroup"
]

Checkov scan for least privilege (KSI-IAM-ELP)

Checkov includes built-in checks for overly permissive AWS Identity and Access Management (IAM) policies. Running
checkov -d . --check CKV_AWS_63,CKV_AWS_61 validates that IAM policies do not use wildcard actions or resources.

CI/CD integration

You can integrate the three validation tools into your existing CI/CD pipeline using AWS CodePipeline or GitHub Actions. The following sections show how to configure each so that a KSI violation fails the build before deployment.

AWS CodePipeline integration

In AWS CodePipeline, add a validation stage between your source and deploy stages. Use AWS CodeBuild to run the scanning tools.

phases:
  install:
    commands:
      - pip install checkov
      - curl -L -o opa https://openpolicyagent.org/downloads/latest/opa_linux_amd64_static
      - chmod +x opa
      - curl -L -o cfn-guard https://github.com/aws-cloudformation/cloudformation-guard/releases/latest/download/cfn-guard-v3-ubuntu-latest.tar.gz
  build:
    commands:
      - terraform plan -out=tfplan && terraform show -json tfplan > plan.json
      - ./opa eval -d policies/ -i plan.json "data.fedramp20x" --format json > opa-results.json
      - cfn-guard validate -d templates/ -r rules/ --output-format json > guard-results.json
      - checkov -d . --output json > checkov-results.json
  post_build:
    commands:
      - python3 aggregate-results.py --output s3://evidence-bucket/iac-scans/

GitHub Actions integration

For teams using GitHub Actions, add the following step to your workflow. It runs the same three tools and fails the job if any tool detects a
violation.

- name: FedRAMP 20x IaC Validation
  run: |
    opa eval -d policies/ -i plan.json "data.fedramp20x" --fail-defined
    cfn-guard validate -d templates/ -r rules/ --show-summary fail
    checkov -d . --compact --hard-fail-on HIGH

Both integrations fail the pipeline if any KSI violation is detected, preventing non-compliant infrastructure from reaching deployment.

Validating Terraform and CloudFormation side by side

Many organizations use both Terraform and CloudFormation, sometimes within the same environment. Terraform might manage application infrastructure while CloudFormation manages the multi-account AWS environment baseline. Your validation pipeline must cover both.

The multi-tool strategy handles this naturally:

OPA/Rego evaluates Terraform plan JSON, which captures the full resource graph including computed values and provider defaults. This makes OPA particularly effective for validating Terraform configurations.
cfn-guard evaluates CloudFormation templates natively, understanding intrinsic functions like !Ref and !GetAtt. This makes it the right tool for CloudFormation-specific validation.
Checkov supports both formats with a shared rule set, providing consistent baseline coverage regardless of which IaC tool produced
the template.

For organizations standardizing on a single IaC tool, the recommendation is to use all three tools anyway. Each tool detects different classes of issues, and the overlap provides defense in depth at the scanning layer.

AWS Config conformance packs as the runtime complement

IaC scanning catches violations before deployment. AWS Config conformance packs catch drift after deployment. This project includes two conformance packs (Low and Moderate) with 128 rules each, covering 44 to 47 KSIs.

The combination works as follows:

Pre-deploy: OPA/Rego, cfn-guard, and Checkov scan templates in the CI/CD pipeline
Deploy-time: SCPs block non-compliant API calls
Runtime: Config conformance packs detect configuration drift
Threat detection: Amazon GuardDuty and Sigma rules identify active issues

Each layer produces machine-readable evidence that feeds into the evidence lake, contributing to the dual-format authorization package required by FedRAMP 20x.

Mapping scan results to KSI evidence

Every scan result should include the KSI identifier it validates. This mapping enables automated aggregation into your authorization package. Structure your scan output to include:

{
  "ksi_id": "KSI-SVC-VRI",
  "tool": "opa",
  "result": "PASS",
  "resource": "aws_ebs_volume.data",
  "timestamp": "2026-05-15T14:30:00Z",
  "evidence_type": "pre-deploy-scan"
}

This structured output feeds directly into the evidence pipeline covered in future posts, where scan results are transformed into the machine-readable format required for the authorization package.

Building a policy library

The project repository includes a comprehensive policy library across all three tools:

64 OPA/Rego policies covering all 12 KSI themes, with each policy tagged with its KSI identifier and mapped to National Institute
of Standards and Technology (NIST) Special Publication (SP) 800-53 controls
15 cfn-guard rules focused on Service Configuration (SVC), Cloud Native Architecture (CNA), and identity and access management
themes
59 Checkov policies per format (Terraform and CloudFormation) covering encryption, network security, identity, and
logging

When building your own policies, follow these practices:

Tag every policy with its KSI identifier. This enables automated mapping from scan results to KSI evidence.
Include the NIST 800-53 control mapping. Organizations with existing NIST compliance programs can demonstrate dual coverage.
Write clear denial messages. When a scan fails, the message should tell the developer exactly what to fix and why.
Version your policies alongside your infrastructure code.
Policy changes should go through the same review process as infrastructure changes.

Handling scan failures in the pipeline

When a scan detects a KSI violation, the pipeline should fail the build and prevent deployment. However, not all violations are equal. Consider implementing a tiered response:

Critical violations (encryption disabled, public access enabled, no multi-factor authentication (MFA)): Block deployment immediately. These map to KSIs where non-compliance creates direct risk.
High violations (overly permissive identity and access management, missing logging): Block deployment with a clear remediation
path.
Medium violations (non-optimal configurations, missing tags): Warn but allow deployment with a tracking ticket. These might map to KSI recommendations rather than requirements.

This tiered approach prevents pipeline fatigue while maintaining a hard gate on critical KSI requirements. All scan results, including warnings, feed into the evidence lake as pre-deploy validation evidence.

What comes next

With preventive controls blocking non-compliant resources and IaC scanning catching misconfigurations before deployment, the next challenge is assembling all this evidence into a machine-readable authorization package. In next blog, we walk through the evidence pipeline from AWS Config evaluations through Security Hub aggregation to dual-format authorization package output.

Next steps and resources

FedRAMP 20x overview – Program overview and phased delivery timeline
AWS Config conformance packs – Grouping Config rules for compliance frameworks
AWS CodePipeline – Continuous delivery service for automated release pipelines
Open Policy Agent – Policy engine for cloud-native environments
CloudFormation Guard – Policy-as-code evaluation for CloudFormation templates
AWS Security Hub – Centralized security findings aggregation
Blog post 3: Preventive Controls for FedRAMP 20x – SCP enforcement of KSIs

AI-powered customs duties classification, assessment, and collection for international mail shipments to the United States

Christian Hoff — Wed, 01 Jul 2026 20:37:37 +0000

Every year, more than one billion international mail shipments arrive at US ports of entry. Each one requires customs classification, duty assessment, and in many cases, duty collection, a process that today relies heavily on manual inspection and after-arrival data gathering. For US Customs and Border Protection (CBP), this creates a dual challenge: maintaining border security while ensuring efficient processing and accurate revenue collection at unprecedented scale. For postal carriers and their shipping customers, the current process introduces delays, uncertainty, and compliance complexity.

Today, we are announcing that CBP has selected Amazon PreDepart as a trade solutions candidate under the Commercial Solutions Opening Pilot (CSOP) program. As part of this selection, CBP also approved Amazon Customs and Trade (ACT) as a Qualified Party, an entity authorized to collect and remit customs duties on behalf of shippers – for international mail shipments to the United States.

What is Amazon PreDepart?

Amazon PreDepart is an AI-powered service that automates Harmonized Tariff Schedule (HTS) classification, duties assessment, and duties collection for international mail shipments before they depart for the United States. The service enables cross-border postal carriers and their customers to pre-classify products, receive duty assessments, and pre-pay customs duties — all before the shipment leaves its country of origin.

Rather than resolving duties at the border, PreDepart shifts the process upstream. Shippers provide product information (images, descriptions, dimensions, and pricing) and PreDepart returns an HTS classification, calculates the applicable duty, and collects payment, all within the carrier’s existing order flow. When the shipment arrives in the US, CBP receives a verified digital record confirming what’s in the package and that duties have already been paid.

Why this matters

Amazon PreDepart supports CBP’s mission to modernize trade operations, improve security, and increase efficiency at US ports of entry.

For CBP, the service reduces customs processing delays by providing verified shipment data and confirmed duty payment before goods arrive. This eliminates the need to gather basic information at the border. Upon arrival, CBP gains access to digital PreDepart shipment records including product data, and duty payment status, enabling faster identification of high-risk shipments through AI-powered risk analysis. The result: improved revenue collection through verified pre-payment, enhanced security posture, and the ability to focus inspection resources where they matter most.

For postal carriers and shippers, PreDepart reduces uncertainty and creates a more predictable cross-border shipping experience. Duties are assessed and collected before departure, compliance is simplified through automation, and shipments move through US customs with fewer delays. Carriers don’t need to build customs classification expertise in-house — the AI handles the complexity.

How it works: The technology behind PreDepart

Amazon PreDepart was developed combining ACT’s deep trade and customs expertise with AWS generative AI and global cloud infrastructure. The solution brings together AI-powered capabilities across five key dimensions:

Automated HTS Classification. Generative AI analyzes product images and descriptions to assign the correct tariff code from thousands of possible classifications, removing the guesswork and inconsistency of manual classification.

Product Validation. Product information is cross-referenced against product catalogs to ensure accuracy and flag discrepancies before goods are in transit.

Country of Origin Verification. AI-powered image analysis examines product labels to verify declared country of origin, a critical input for accurate duty calculation.

Integrated Duty Calculation and Collection. Once classification and verification are complete, duties are automatically calculated and collected within the carrier’s existing customer order flow — no separate systems, no manual handoffs.

The service delivers an interactive interface designed to integrate seamlessly into existing shipping workflows, enabling classification and collection at scale.

Navigating the path to approval

Bringing Amazon PreDepart to this stage required navigating CBP’s Commercial Solutions Opening Pilot program — a formal government pathway that evaluates commercial technology solutions for trade modernization challenges. The CSOP process is rigorous by design: it ensures that only solutions meeting CBP’s standards for security, accuracy, and operational reliability are approved.

Securing selection required Amazon to demonstrate the ability to serve as a Qualified Party authorized to collect and remit customs duties, technical capability to validate product data and assess duties prior to shipment departure, capacity to provide CBP with pre-verified digital shipment records upon arrival, and AI-powered security and compliance capabilities including shipper verification and risk analysis.

The approval positions ACT as one of the authorized entities to handle duty collection for international mail shipments entering the United States, working directly within CBP’s trade modernization framework.

What our leaders are saying

“We are honored to be selected by US Customs and Border Protection for the Trade Solutions pilot,” said David Cardadeiro, Vice President of Amazon Customs and Trade. “PreDepart is part of our suite of innovative customs brokerage and trade software solutions, and we are proud the technology we provide to global traders through this pilot will help support U.S. customs.”

Get involved

Are you a postal carrier or shipper interested in working with Amazon as your Qualified Party or using Amazon PreDepart for customs duties classification and collection? We’d like to hear from you, connect with our team directly, reach us at predepart-interest@amazon.com

Amazon Customs and Trade (ACT) is Amazon’s trade technology and customs brokerage organization, delivering AI-powered solutions that simplify cross-border commerce for shippers, carriers, and government agencies worldwide.

Amazon Web Services (AWS) provides the most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers — including government agencies, the fastest-growing startups, largest enterprises, and leading nonprofits — use AWS to lower costs, become more agile, and innovate faster.

Accelerating government FinOps with Amazon Quick

Kai-jia Yue — Wed, 01 Jul 2026 16:02:40 +0000

According to Gartner, “Over 50% of organizations will use industry cloud platforms to accelerate their business initiatives by 2029” and “Gartner predicts 50% of cloud compute resources will be devoted to AI workloads by 2029, up from less than 10% today.”

FinOps teams face a persistent challenge: they must translate massive volumes of cloud financial data into timely, actionable decisions, often across multiple accounts, business units, and billing dimensions. Many teams rely on manual spreadsheet analysis, siloed dashboards, and ad hoc reporting requests that slow the feedback loop between spending and optimization.

To alleviate this problem, Peraton has created a solution that integrates the CloudSPARCC dashboard and data with Quick capabilities to centralize data and insights. This solution is currently deployed at multiple large government agencies.

Peraton is a mission capability integrator that delivers enterprise IT around the world. The company is also an Amazon Web Services (AWS) Premier Tier Services Partner with competencies in DevOps, Cloud Migration & Modernization, and Government Consulting. Peraton’s IT infrastructure and technology strategy are designed to support the delivery of mission-critical services and solutions to its customers on a global scale.

In this post, we explore how Peraton created a solution for centralized cloud financial management solution on AWS and how Amazon Quick can accelerate insights for large government entities.

What is CloudSPARCC?

In a previous post, Create a multicloud FinOps dashboard with Amazon QuickSight using AWS services, we introduced CloudSPARCC, a multicloud FinOps solution powered by Amazon QuickSight built by Peraton that delivers a unified visualization into cloud billing data.

The following diagram shows the solution architecture:

Figure 1: Architecture of CloudSPARCC’s data ingestion to visualization

CloudSPARCC uses several key UI design features to enhance the user experience. The multi-sheet navigation feature enabled the team to create a comprehensive dashboard with nine distinct “sheets,” allowing users to navigate between focused views without overwhelming a single page. Each sheet is configurable with filters and provides diverse visuals and chart types that let users tailor data to their specific needs. To complement these capabilities, the team also applied a refreshed user interface with consistent borders and color schemes throughout to streamline navigation and accelerate pattern recognition across the sheets.

Amazon Quick integration

CloudSPARCC provides the visual layer for exploring cloud costs while Amazon Quick adds an AI-powered interface to that data. This enables teams to ask plain-language spending questions, automate recurring cost reports, and generate detailed reports from a single workspace.

Amazon Quick is built on AWS infrastructure that supports government security requirements, with data encrypted in transit and at rest Amazon Quick does not use customer data for training or improving underlying LLMs. For the latest information on compliance certifications and services in scope, see AWS Services in Scope by Compliance Program.

Figure 2: Diagram of a FinOps workflow

The result is a unified FinOps workflow that operates within a single platform. Quick accelerates the speed FinOps teams take to reach deep insights into cost and usage in the cloud environment.

Chat agents

Extracting cost insights from cloud billing data has traditionally required either technical expertise to manipulate and present cost data or reliance on costly third-party solutions to fill the gap. Chat agents, an AI-powered feature within Quick, address both obstacles directly. In Peraton’s case, the team configured the agent to provide direct, conversational access to the organization’s cost datasets. You no longer need to write SQL queries against cost and usage data or manually build dashboard visuals for ad hoc analysis, chat agents allow you to ask questions in plain language and receive precise answers in seconds.

Figure 3: An example of a chat agent conversation

The role of Spaces

The usefulness of any chat agent depends on the data it can access. Spaces play a key role in this process by serving as a centralized repository for teams to store QuickSight dashboards, knowledge bases, topics, and other documentation. When an agent is linked to a Space, it gains access to the knowledge that the Space contains, transforming it into a contextually aware FinOps resource rather than a source of generic answers.

Figure 4: An example of a Quick Space

The Peraton FinOps team configured a Space that contains cost and usage data, supplementary custom cost reports, AWS pricing documentation, their FinOps dashboard, and a web crawler indexed to documentation. The chat agent linked to this Space draws from this context, allowing it to serve as an authoritative expert in relevant cost reporting and Quick help documentation.

In practice, a team member can ask a plain question like “What was our EC2 quarter-over-quarter trends over the last calendar year” and receive an accurate response complete with service breakdowns, account-level details, and live visuals generated directly within the chat window—all without writing custom SQL queries in Amazon Athena or building custom dashboard visuals.

Quick Flows

Quick Flows extend Quick’s capabilities beyond conversational analysis by allowing anyone to build automations that handle repetitive tasks using simple, everyday language prompts. Users can create and define workflows that run on a set schedule, respond to specific events, or run on demand.

Figure 5: An example of the Quick Flows editor showing the AWS Monthly Spend Analysis Email workflow

The Peraton FinOps team configured a workflow to retrieve the previous month’s AWS spending by service and compare it to the preceding month. The workflow creates a formatted summary and emails it to the appropriate stakeholders automatically on a schedule. Beyond email, Quick Flows integrates with a broad set of enterprise tools such as ServiceNow, Jira, and OneDrive, enabling cost intelligence to flow directly into the ticketing systems, approval workflows, and collaboration tools that teams already use.

Quick Research

Analyzing complex questions often requires consolidating data across multiple sources. For FinOps teams, this is especially true for cost optimization analysis, where billing data, current cloud pricing, and cloud best practices must be evaluated together to inform decisions. Quick Research is built to handle exactly this type of problem.

Figure 6: An example output of a Quick Research report

The Peraton FinOps team provided Quick Research with the organization’s cost and usage data, access to live AWS pricing documentation, and cloud best practices. This gave the agent the context needed to perform cost optimization studies such as analyzing Reserved Instance usage across accounts, identifying rightsizing or Savings Plans opportunities, and estimating cost impacts. Work that previously required hours of manual analysis now completes in minutes, with a final report that includes findings, recommendations, projected savings, and implementation timelines.

Conclusion

Amazon Quick’s integrated features create a comprehensive platform for FinOps. By bringing together dashboards, AI agents, automated workflows, and deep research capabilities into a single platform, Quick delivers faster insights, more efficient workflows, and data-driven cloud financial management purpose-built for modern FinOps teams.

To learn more, visit the Amazon Quick documentation and start building your first FinOps Space today.

AWS announces up to $1 billion in cloud credits to accelerate U.S. Intelligence Community modernization

David Appel — Tue, 30 Jun 2026 14:28:02 +0000

Today, Amazon Web Services (AWS) announced the Intelligence Community Accelerated Modernization Framework (ICAMF), a landmark program committing up to $1 billion in available credits to accelerate cloud migration and modernization across the U.S. Intelligence Community. ICAMF provides outcome-based credits through October 2030, giving Intelligence Community agencies a compelling, long-term incentive to accelerate their cloud journey.

The ICAMF removes a significant financial barrier to cloud adoption by offering meaningful credits tied to successful migration and modernization outcomes. By aligning investment with results, the program compresses modernization timelines and enables the Intelligence Community to operate at the speed their missions demand. ICAMF reflects the leading role of AWS as the preferred cloud partner for the Intelligence Community, providing the infrastructure, tools, and economic framework to modernize at scale.

Program overview

The ICAMF establishes a framework within the existing AWS contract with the U.S. Intelligence Community that provides credits for qualified workloads migrating to AWS. The program commits up to $1 billion in available credits and will remain active through October 2030.

Eligible participants include all Intelligence Community agencies operating under the existing AWS contract seeking to migrate and modernize workloads on AWS.

What this means for the Intelligence Community

America’s intelligence agencies operate in an increasingly complex threat environment that demands rapid adaptation, advanced analytics, and seamless information sharing. Although the U.S. Intelligence Community was an early adopter of cloud computing, portions of its vital mission still rely on legacy on-premises infrastructure that limits agility and creates barriers to adopting transformative technologies like generative AI, advanced machine learning, and real-time data fusion.

ICAMF directly addresses these challenges by:

Reducing the cost of modernization: Outcome-based credits based on post-migration value dramatically lower the financial barrier to moving workloads to the cloud.
Accelerating migration timelines: With up to $1 billion in committed credits available through 2030, agencies can plan and execute ambitious modernization roadmaps with confidence.
Enabling mission-critical capabilities: Cloud migration unlocks access to AWS’s full portfolio of services—including generative AI, high-performance computing, advanced analytics, and edge computing—across all classification levels.
Aligning investment with outcomes: Credits are tied to successful migration and modernization, ensuring that AWS’s investment drives real, measurable results.

Supporting the Intelligence Community’s modernization priorities

The ICAMF supports the Intelligence Community’s strategic priorities to modernize IT infrastructure, improve data interoperability, and adopt advanced technologies at pace with evolving threats. The program enables agencies to leverage the most advanced cloud capabilities while achieving meaningful cost efficiencies—delivering improved mission outcomes with the speed and agility that national security demands.

Commitment to National Security customers

AWS is unwaveringly committed to customers in the federal, defense, and national security agencies, and today supports more than 15,000 government agencies around the globe. AWS brings nearly a decade of experience supporting some of the U.S. government’s most sensitive workloads and breaking barriers for our customers. AWS was the first cloud provider to build infrastructure specifically for government (2011), support classified workloads (2014), and achieve accreditation across all U.S. government data classifications (2017).

This commitment continues to grow. In August 2025, the U.S. General Services Administration announced a OneGov Agreement with AWS to provide up to $1 billion in savings for cloud adoption, modernization, and training for federal agencies through 2028. In October 2025, AWS launched a second Secret Cloud Region, AWS Secret-West, further expanding classified computing capabilities. In November 2025, Amazon announced it will invest up to $50 billion to expand AI and supercomputing infrastructure for U.S. government agencies. And in February 2026, AWS announced up to $100 million in federal credits through the Warfighter Capability Accelerator and Genesis Accelerator initiatives to support national security and scientific missions.

The ICAMF builds on this momentum—representing AWS’s largest single investment in Intelligence Community cloud adoption and underscoring our long-term collaboration with the agencies protecting America’s national security.

Getting started

Intelligence Community agencies operating under the existing AWS contract can engage with their AWS account teams to learn more about ICAMF eligibility, program mechanics, and how to qualify workloads for migration credits. Enablement materials, including detailed program guidance and customer-facing collateral, will be available shortly.

Learn more about AWS for the Intelligence Community and how ICAMF can accelerate your cloud modernization journey.

Accelerating autonomous system innovation with Project MAVERICK field testing

Mike Haggerty — Tue, 30 Jun 2026 12:54:32 +0000

Real missions break perfect prototypes. Through Project MAVERICK (Mission Autonomy Versatile Rapid Innovation and Capabilities Kit), Amazon Web Services (AWS) confronts this reality head-on—bringing cloud capabilities directly into the field to test autonomous systems where it matters most.

Autonomous systems that excel in controlled labs often crumble when faced with actual field conditions. The culprit is often engineers building on limited or untested assumptions about operational reality—not because they’re careless but because the environment (and the adversary) is complex. Unfortunately, these gaps typically surface only when it’s too late to fix them.

AWS takes a different approach: test early, test real. Project MAVERICK is a mobile ruggedized platform equipped with AWS Outposts, secure communications, and a flexible integration architecture. By deploying directly to genuine operational environments, MAVERICK works backward from the hardest tactical challenges alongside customers and partners.

“Project MAVERICK is the mobile platform that brings AWS capabilities and partners into the field for rapid innovation,” said Dave Levy, vice president of AWS Global Defense, during his innovation talk at re:Invent 2025.

The modified truck, equipped with an Outpost, secure communications, and flexible integration architecture, allows AWS to rapidly deploy to remote training ranges, customer facilities, or field exercise locations. A recent 2-day field exercise brought together AWS, Anduril, and Gambit for hands-on testing. In this tactical environment, the team validated conversational drone swarm control, AI in disconnected environments, and interoperability across multiple command and control (C2) systems.

The result: single voice commands that coordinate drone swarms through natural language prompts powered by AWS, Anduril, and Gambit technology—tested in realistic field conditions, not only in a lab.

Integration architecture that breaks down C2 silos with real-time data sharing

AWS partnered with Anduril and Gambit to demonstrate these capabilities using accredited services designed for defense and national security missions. Anduril provided Menace-T, a portable ruggedized command-and-control platform running Anduril’s Lattice software, which enables operators to coordinate assets in real time across austere environments. Gambit, a startup developing autonomous systems technology, contributed their ALIEN autonomous coordination system and multi-drone expertise.

AWS integrated these partner capabilities using AWS Wickr for secure communications, AWS IoT Greengrass for edge deployment, and AWS Outposts for edge compute—creating a unified environment where each organization’s technology could be tested and refined together.

The team ingested legacy Automatic Packet Reporting System (APRS) tracking data and routed the normalized stream into both Anduril’s Lattice and the open source Tactical Awareness Kit (TAK), establishing a shared operating picture across heterogeneous C2 systems without ripping and replacing legacy software. The exercise demonstrated how a single data source can support both commercial and open systems without forcing you to replace existing tools.

This integration exemplifies the mission autonomy data flywheel in action. Improved data visibility across disparate C2 systems leads to faster threat identification and better operational decision-making. Each exercise iteration feeds performance data back into platform design, creating a continuous improvement cycle that reduces risk and accelerates mission success.

By providing a common platform for diverse technology providers, AWS eliminates complex vendor integration and accelerates mission capabilities through proactive collaboration.

Simplifying drone swarm operations with conversational control

The exercise also showcased conversational control of autonomous drone swarms using natural language through AWS WickrGov. Working with Gambit, AWS developed an agentic AI interface where operators describe mission objectives in plain language, such as “Execute a search and rescue mission in the northern sector.” The system then translates that intent into fully coordinated multi-drone operations.

“We just tested and proved that on a phone just with Wickr and a custom Wickr bot all running with Amazon Bedrock on an Outpost server, you can task a swarm of drones, or any robot really, to perform a search-and-rescue mission to full success,” said Andrew Kemendo, chief technology officer at Gambit.

Behind the scenes, the WickrGov bot powered by Amazon Bedrock interprets the natural language request, validates mission parameters, and translates the intent into API calls for Gambit’s ALIEN command platform. During the exercise, AWS successfully launched four autonomous platforms through this conversational interface, demonstrating how natural language control can simplify multi-platform coordination.

Validating the “develop in cloud, deploy at edge” pattern for operational advantage

Gambit developed its Amazon Machine Image (AMI) in AWS Regions, fully testing the integration with AWS agentic AI components. AWS then deployed the identical AMI to an Outpost at the field site, where it ran identically in a disconnected, disrupted, intermittent, and limited (DDIL) environment. This established a repeatable pattern for codevelopment in tactical environments.

The consistency between cloud and edge eliminates the integration risk that typically plagues edge deployments. You can develop and test your solutions using familiar AWS services in the cloud, confident that the same workloads will operate reliably at the tactical edge. This pattern also delivers significant cost advantages—developing and testing on Amazon Elastic Compute Cloud (Amazon EC2) in AWS Regions is more cost-effective than using Outpost capacity for iterative development while still providing identical runtime behavior at the tactical edge.

During the exercise, Menace-T hardware and Lattice software backhauled position location data in real time, so operators could coordinate autonomous platforms and review mission data post-exercise. That data informed follow-on mission planning and future capability development.

Bridging legacy radio networks with modern secure messaging

AWS demonstrated a bidirectional bridge between traditional radio networks and AWS WickrGov secure messaging. During the exercise, an operator spoke on a common tactical radio, and local AI models transcribed the audio to text and published it to a WickrGov room. The system then synthesized text responses to voice and broadcast them back over the radio network. This demonstrates how organizations with significant investments in radio infrastructure can integrate with modern collaboration platforms.

Using accredited infrastructure and validated reference architectures

The capabilities demonstrated during this exercise used AWS services designed for the most demanding security requirements. AWS WickrGov and AWS GovCloud (US) support Federal Risk and Authorization Management Program (FedRAMP) High authorization, while other AWS Regions provide infrastructure accredited for classified workloads. You can develop solutions using AWS services and consistent patterns across all unclassified and classified environments, maintaining operational consistency while meeting stringent security requirements.

These field test exercises validated AWS engineering-built reference architectures that you can adopt and adapt for your own missions. Rather than merely demonstrating capabilities, AWS shares the investment in proving solutions work—delivering reference architectures that organizations can deploy, including an AWS WickrGov bot framework for conversational interfaces and an AWS based serverless TAK implementation.

The following architecture diagram shows integration between AWS WickrGov users, IP radios, AWS Cloud services such as AWS WickrGov bots, Amazon Bedrock, and Amazon Simple Queue Service (Amazon SQS), and edge hardware including the Outpost server, Gambit ALIEN software, Anduril Lattice, and drone swarm.

Figure 1: Architecture diagram for the solution described in the post.

Looking forward

The field test exercise demonstrated that conversational control of autonomous drone swarms, edge-based AI processing in DDIL environments, and multi-organization integration using AWS infrastructure are possible and ready for operational validation. More importantly, it validated an approach to collaboration: AWS engineers working together with Anduril and Gambit, in realistic field conditions, solving real problems at mission speed.

Through Project MAVERICK, AWS conducts these events frequently and proactively. MAVERICK will participate in multiple customer exercises and demonstrations throughout 2026, each one an opportunity for collaborative innovation on mission autonomy challenges.

The following graphic shows the DDIL Innovation Lab with Menace-T hardware, edge solutions, cloud compute capabilities, and integration with autonomous systems for field experimentation.

Figure 2: The MAVERICK mobile platform architecture

Organizations working on autonomous systems for defense, national security, or public safety missions can engage AWS engineering resources through AWS Mission Lab—a service you can use to experiment with and deliver innovative mission solutions using AWS infrastructure. Mission Lab provides the resources and support needed to rapidly test and validate new technology integrations, so you can move from concept to operational capability at mission speed.

To learn more about AWS capabilities for autonomous systems and opportunities for field experimentation, contact your AWS account team, the Mission Autonomy Team at missionautonomy@amazon.com, or visit the Cloud Computing for U.S. Defense page. For information about Anduril’s Menace-T and Lattice capabilities, visit Anduril. For more information about Gambit and ALIEN, visit Gambit.

Delivering on the Promise of OneGov: Federal Agencies Modernize with OneGov — and AWS Expands its Program to ISV Partners

Christian Hoff — Tue, 30 Jun 2026 12:45:59 +0000

In August 2025, Amazon Web Services (AWS) secured a OneGov agreement with GSA, to provide up to $1 billion in savings to accelerate cloud adoption, modernization, and training across the federal government. Less than a year later, agencies and partners are leveraging this program to make meaningful progress on cybersecurity and cloud migrations.

Here’s a small sampling of the progress we’ve made together.

Agency Modernization Progress Under OneGov

Centers for Medicare & Medicaid Services (CMS)

Next Generation Desktop (NGD): Through their work with GDIT, CMS is migrating their customer relationship management (CRM) system from legacy on-premises data centers to AWS and upskilling their workforce via AWS Training. The NGD system supports CMS’s beneficiary-facing contact center, which receives over 37M contacts annually from Medicare and Health Insurance Marketplace beneficiaries. This migration supports ongoing modernization efforts for systems that serve Medicare and Health Insurance Marketplace beneficiaries.
Payment Error Rate Measurement (PERM): Through GDIT, CMS is migrating their State Medicaid error rate findings system to AWS to support modernization efforts and future system enhancements. The migration supports continued modernization of systems used in Medicaid program administration.
AWS Outposts for Critical Infrastructure: CMS is utilizing AWS Outposts as part of its hosting environment for critical and sensitive workloads across its data centers. AWS Outposts provides capabilities intended to support organizations seeking to leverage cloud-based infrastructure while meeting stringent security requirements for data residency and isolation. This initiative supports CMS modernization efforts involving infrastructure management and hosting environments.
Enterprise Contact Center: Through GDIT, AWS is modernizing legacy infrastructure to migrate the CMS enterprise IT HelpDesk to Amazon Connect. This effort supports modernization of contact center infrastructure and administration.
Medicare Administrative Contractor (MAC): Through their work with GDIT, CMS is consolidating multiple legacy MAC contact centers to Amazon Connect Customer to modernize and streamline healthcare provider inquiries into Medicare while training their workforce on the use of Amazon Connect Customer. The MAC contact centers receive nearly one million calls annually to request support for Medicare claims submissions and inquiries. This modernization effort is intended to support contact center operations through enhanced communications capabilities and more consistent workflows.

General Services Administration (GSA)

Cloud Ecosystem: GSA IT is modernizing and migrating their technology portfolio with AWS, including mainframe, robotic process automation (eRPA), telecom ordering management, and award management system workloads. The project includes foundational modernization initiatives that will establish critical AI and data capabilities across all migrated workloads. This first tranche kicks off as part of a multi-year transformation program for GSA.

Small Business Administration (SBA)

Multi-Data Center Migration: Through Four Points, AWS is migrating multiple data centers supporting the SBA’s Office of Capital Access, Office of the Chief Financial Officer (OCFO), and Office of the Chief Information Officer (OCIO). The scope includes four data center exits, modernization of critical applications, and establishing a full business disaster continuity and recovery (BDCR) solution for SBA’s key financial systems. Implementation is underway with an expected September 2026 final deployment.

National Oceanic and Atmospheric Administration (NOAA)

National Centers for Environmental Information (NCEI) Data Center Migration: AWS ProServe won the bid to partner with NOAA NCEI—the world’s largest provider of environmental data—to execute one of its most ambitious infrastructure modernizations. The engagement encompasses migrating approximately 1,000 virtual machines and up to 20 petabytes of environmental data from on-premises data centers to an AWS FedRAMP Moderate cloud environment, while maintaining zero downtime across approximately 300 active data streams. Beyond the initial migration, AWS and NCEI are modernizing legacy archival systems to cloud-native S3-based storage solutions and optimizing complex applications for long-term scalability. The result: NCEI harnesses AWS’s global cloud to better serve scientists, researchers, and the public worldwide with faster, more secure access to data, all while meeting federal data center exit mandates.

Bringing ISV Partners into the Framework

AWS is expanding the program to include Independent Software Vendor (ISV), partners giving federal agencies streamlined access to the AWS-native SaaS solutions that power their most critical missions. This strategic expansion accelerates governmentwide IT transformation by pairing the cloud savings AWS already delivers with the application-layer software agencies need most, eliminating fragmented procurement cycles and enabling modernization at unprecedented speed and scale. By bringing in the ISV community, AWS is equipping federal agencies to retire legacy systems faster, adopt advanced AI capabilities, and deliver better services to the American people while maximizing value for the taxpayer.

What’s Next

The momentum behind OneGov reflects a broader shift in how the federal government approaches technology: moving from fragmented, agency-by-agency procurement to a unified strategy that delivers better outcomes at lower cost. AWS is committed to delivering results on its OneGov agreement and supporting the GSA, federal agencies, and ISVs across government to make this transformation a reality.

Learn more about the AWS GSA OneGov agreement and how to engage with AWS representative here.

The examples above reflect AWS-supported projects and modernization activities. Descriptions are provided for informational purposes and do not constitute endorsements, policy statements, or official positions of the referenced agencies.

From Lab to Bedside: Five Years of AI-Powered Health Breakthroughs and What Comes Next

Dr. Dawn Heisey-Grove — Tue, 30 Jun 2026 12:38:20 +0000

Behind every health breakthrough is an investment made long before the results were visible. For five years, Amazon Web Services (AWS) has channeled social impact credits into organizations tackling the world’s toughest health challenges for the most underserved populations—backing bold ideas with enterprise-grade infrastructure.

Since launching the AWS Health Equity Initiative (HEI) in 2021, AWS has supported more than 600 customers with over $90 million of technology to innovate and improve health outcomes for all. Forty-four percent of these customers employed AWS AI services, seeding AI innovation across the global health landscape and proving that cloud-powered AI can improve health and wellness for all.

This blog highlights nine of those organizations deploying AI to save lives today, culminating in AWS’s largest single social impact investment in health: a landmark technology collaboration with the Fleming Initiative to build the world’s first AI-powered platform for combating antimicrobial resistance.

From credits to capabilities: How the model works

AWS social impact credits are more than funding. They make the same world-class cloud infrastructure; AI, machine learning (ML), and agentic services; and data tools that power the world’s largest enterprises available to mission-driven organizations supporting underserved populations. And when that happens, the effects can be transformative.

The model creates a virtuous cycle:

Credits seed innovation. Organizations receive AWS credits and use them to build AI-powered solutions on purpose-built services like Amazon SageMaker, Amazon Bedrock, Amazon Comprehend Medical, Amazon HealthLake, AWS HealthOmics, and AWS HealthImaging.
Validated solutions attract investment. A working prototype running at scale on AWS is the most compelling pitch deck in the world.
Solutions scale on AWS. What starts as a pilot in one clinic or one country can expand to global reach without rebuilding infrastructure.
Impact multiplies. Each validated finding, each trained model, each open dataset creates compounding value for the next organization, the next researcher, the next patient.

Here’s a sample of how AWS-supported organizations leveraged this model to save lives today.

AI to reduce maternal and infant mortality

Babyscripts‘ AI-powered risk identification platform is designed to support earlier detection of the clinical and social conditions that contribute to maternal mortality and morbidity, including maternal mental health conditions, hypertensive disorders and pregnancy, and gestational diabetes. These conditions disproportionately affect women in underserved communities and, when left undetected, can have serious consequences for both mother and baby.

Through remote monitoring, Babyscripts has improved blood pressure (BP) collection among patients with postpartum hypertension and helped eliminate racial disparities observed in office-based collection, with 93% at-home BP ascertainment for White and Black patients. By catching these warning signs early, Babyscripts has driven a critical 13-day reduction in the time to detect preeclampsia, allowing care teams to intervene well before a situation becomes a crisis.

Touch Health developed watotoCare, which uses AI to support newborns in Tanzania during their critical first six weeks of life when they are at highest risk for death. During its first 12 months, watotoCare provided AI-driven early warning and decision support for 5,000 newborns, leading to an 80% decrease in hospital readmission for high-risk babies and a 275% increase in high- and medium-risk babies completing recommended post-natal doctor visits.

AI for behavioral health

Frontera Health is tackling the severe shortage of qualified Board-Certified Behavior Analysts (BCBAs) by developing AI tools that reduce burden on BCBAs and allow them to work more efficiently and spend more time caring for their patients with developmental disorders like autism.

By saving BCBAs 4-5 hours per assessment report, Frontera is increasing the number of patients with autism who can receive interventions, particularly in rural areas. Starting intensive therapy at an early age leads to significantly better outcomes, but only if that therapy is available to these children.

AI to improve care delivery

CHIP (Community Health Integrated Platform) is Khushi Baby’s response to the challenge of fragmented data that leads to fragmented care. Co-developed with community health workers after 250,000 hours in the field, CHIP is a unified, offline-ready digital solution that consolidates the entire work requirement of frontline health workers across all primary health care programs and cadres into a single digital health interface. CHIP reduces over 180 redundant indicators across 12 national health programs.

To date, CHIP has registered ~60 million individuals across 40,000+ villages in India. By late 2025, CHIP is connected to 11 state and central government platform linkages, enabling data to flow across formerly siloed vertical programs.

Digital Umuganda is building Kinyarwanda language AI encompassing speech recognition, and text-to-speech, and machine translation models with the goal of making essential information across healthcare, education, agriculture, and other critical sectors accessible to Rwandan citizens in their native language. Starting from near-zero training data, Digital Umuganda leveraged community-driven crowdsourced data collection through a network of local African partners to build linguistically diverse and contextually relevant datasets across health and other priority areas.

Demonstrating the real-world impact of these models, Digital Umuganda and its partners recently completed a silent trial with community health workers, serving as an initial use case for their broader cross-sector vision.

AI to make sense of complicated health information

NORC’s Trusted Health Information Assistant, THIA, is a topic- and domain-independent AI assistant currently designed for caregivers of older adults. More than 53 million Americans provide unpaid care to an older adult or person with a disability, facing chronic stress, social isolation, and burnout with few accessible supports. Leveraging large language models (specifically, agentic retrieval-augmented generation), THIA supports aging-in-place by helping caregivers navigate complex health information, coordinate care, and access services. THIA reduces the burden on an overwhelmed caregiving workforce while improving outcomes for seniors.

Bayesian Health is leveraging AI to identify early signs of sepsis. Sepsis is the third leading cause of in-hospital death, and early detection can meaningfully reduce mortality. Bayesian Health works with leading health systems such as Cleveland Clinic to increase identification of sepsis by 46% while decreasing false alerts by 10x.

Dr. Synho Do of the Laboratory of Medical Imaging and Computation at Massachusetts General Hospital and Harvard Medical School, combines medical imaging, clinical data, knowledge graphs, and agentic AI workflows on AWS to move AI from isolated demonstrations to practical tools that know when they should and should not answer, while providing safer, more explainable health information. SafeAI is an algorithm that eliminates mistakes, providing fast confirmation of normal and non-urgent outcomes, while saying “I don’t know” rather than making an inaccurate prediction in equivocal cases. For the complicated world of microbiome and disease research, the Microbiome Network Research and Visualization Atlas (MINERVA) applied large-language models and natural language processing to 129,719 publications, yielding 66,444 validated microbe–disease relationships across 2,941 microbes and 3,299 diseases. MINERVA bridges the gap between microbiome research and real-world applications by facilitating the identification of disease risks, comorbidities, and actionable insights.

Announcing: AWS × Fleming Initiative Partnership

Every 11 seconds, someone in the United States contracts a drug-resistant infection. Every 15 minutes, someone dies from one. Globally, antimicrobial resistance (AMR) is projected to cause 39 million deaths between 2025 and 2050, because common infections and injuries that were treatable become harder—and sometimes impossible—to treat. This contributes to an estimated $1 trillion in additional healthcare costs and up to $3.4 trillion in GDP losses by 2030 with disproportionate impact on the world’s poorest nations. Low-income countries stand to lose more than 5% GDP by 2050. The problem is multi-dimensional: farmers feed livestock the same medically important antimicrobials used to treat humans; 30% of commonly used antibiotics are found in our waterways; and wildlife carry resistance genes across continents. The same resistant pathogens appear in farms, hospitals, and rivers, representing a crisis that no single institution, government, or technology can solve alone. This also represents exactly the kind of challenge where AI and agents, applied at scale, across borders, and in service of the most vulnerable populations, can change the trajectory.

Today, AWS announces a collaboration with the Fleming Initiative to combat AMR. This collaboration builds on five years of deliberate AWS investment in organizations using AI, ML, and agentic services to solve the world’s most pressing health challenges.

Combating antimicrobial resistance at global scale

The Fleming Initiative is not a typical research endeavor. Founded by Professor Lord Ara Darzi and operating under the distinguished patronage of HRH Prince William, the Initiative is a partnership between Imperial College London and Imperial College Healthcare NHS Trust. The Initiative will have a strategic network of research that spans across the globe, positioned to foster consolidation, collaboration, and innovation. Together, AWS and the Fleming Initiative are creating capabilities that do not exist anywhere in the global healthcare ecosystem today:

The world’s first global intelligence solution on AMR research and surveillance. This infrastructure will have the capacity to integrate a molecular compound library of more than 100,000 compounds, creating a powerful dataset for AMR research and drug discovery.
Real-time global surveillance connecting 150+ countries. For the first time, standardized AMR data collection and analysis will have the scale to operate globally, enabling resistance patterns to be identified and addressed before they become prevalent.
AI and ML for drug discovery and treatment optimization. With access to Amazon SageMaker and Amazon Bio Discovery, the solution will have the capability to implement models for molecular structure prediction and resistance pattern identification.
Open science for the global research community. De-identified datasets, molecular signatures, and resistance patterns will be freely available to researchers worldwide, including through services such as the Registry of Open Data on AWS, accelerating discovery.

Technology is just one pillar underpinning Fleming Initiative’s work. The Initiative will champion and deliver campaigns for engaging and involving public with AMR and its solutions, as well as co-create interventions that empower behavior change across society. It will also encourage informed policy across the globe by sharing evidence-based tools and learnings. The Initiative is building an innovative ecosystem where clinicians work side by side with microbiologists, AI experts, behavioral scientists, and policymakers, all connecting with the public, so that powerful new ideas can emerge and thrive.

AWS’s collaboration provides the AI and cloud infrastructure that amplifies this multi-pronged approach. The collaboration with the Fleming Initiative represents a new model for how technology companies can partner with global health coalitions and impact true social change at global scale.

Over five years, we’ve seen organizations go from an idea and AWS technology to life-saving AI tools. This collaboration is the next chapter in that story, but it won’t be the last. AWS is committed to continuing investments that put AI and agentic capabilities in the hands of organizations closest to the hardest problems and the populations who need the most support.

If you’re a research organization, nonprofit, health system, or clinic, startup, or public sector organization exploring how AI can accelerate your health mission in support of underserved populations, we want to hear from you.

Learn more about AWS social impact and how AWS supports:

Women’s health
Genomic data democratization with global data sovereignty
Research on rare disease
Health and life sciences innovation with AWS fit-for-purpose health services

5 pillars to stabilize your AI product development strategy

Jim Kim — Mon, 29 Jun 2026 22:23:20 +0000

Generative artificial intelligence (AI) is rewriting the rules of product development faster than most organizations can rewrite their AI strategies. Models gain new capabilities. Tooling from six months ago can feel out-of-date. As organizations experiment to learn what works best, they face a temptation to chase each new capability. The chase leads to team confusion, directionless movement, and wasted time.

To combat this reactive swirl, here are five durable pillars that product and engineering leaders can use to stabilize their strategy. The pillars are grounded in the experience of the Amazon Web Services (AWS) Product Acceleration team’s work with product leaders who are building AI-native products. From this broader view, we can discern the patterns that separate the teams who thrive from those who see little to no gains. Amidst the constant change, each pillar represents a fundamental principle that helps companies cut through the noise and maintain progress toward a high-performing AI product development organization.

Pillar 1: Your people will do more

The designer who can reason about technical constraints. The engineer who understands user psychology. The product manager who can generate production-ready code. We call this the full-stack builder profile. This isn’t a traditional full-stack developer, but a professional who brings multi-disciplinary judgment across product, design, and engineering.

Unsuccessful organizations are already getting stuck in tactical debates such as whether engineering should take over product management or vice versa. At best, these turf wars result in innocuous but disconnected or duplicative efforts, and at worst are eroding trust and culture between teams that need to collaborate.

As they realize the substantial value full-stack builders provide, companies can expect an increasingly competitive market to hire, train, and retain these team members. Rather than specialized expertise, these builders bring sophisticated and multi-perspective judgment, enabling them to prioritize better and make more decisions. As demand shifts to this hiring profile, the workforce will adapt, driving a supply and demand flywheel in this direction. With a nimble team of full-stack builders, instead of locking into functional silos, companies will be able to organize pods that own a customer persona or need and deliver end-to-end.

One additional note: in the past, many companies isolated their innovation work in a separate, standalone team. This approach often created disconnected islands that were too far from the core business to drive real impact. The same risk applies to organizations that centralize AI expertise in a silo today.

What endures: Individuals operate across the full product surface with AI as their force multiplier. This results in teams that are smaller, faster, and more autonomous.

Pillar 2: Product decisions happen more in parallel than in series

Product development has historically been sequential: research, specification, design, engineering, quality assurance (QA), deployment. Each stage produces artifacts that are handed to the next stage, often with significant context loss and delays. With AI, product development will look less and less like a relay race with discrete handoffs, and more and more like a jazz band that collaborates in real-time. The first wave of AI gains came from individual productivity. But as individuals move faster, they surface the real bottleneck: the handoffs, the alignment, the waiting. Efficient, quick, and clear collaboration is where the real returns live.

Instead of making high-stakes decisions with limited information at the start of a project, teams will make continuous, lower-stakes decisions as they observe real outputs in real time. Considerations typically addressed later in the build (e.g., security reviews, performance implications, accessibility requirements, design) can instead be brought upstream, minimizing required rewrites or substantial sacrifices to stay on schedule.

What endures: AI enables smaller, more frequent decision points without sacrificing speed. Cross-functional concerns surface earlier and earlier, when changes are cheap.

Pillar 3: Context is the competitive moat

There has been a persistent misconception that AI should work perfectly without customization. General-purpose models produce general-purpose outputs. The gap between “impressive demo” and “production-ready contribution” is almost entirely a function of context.

Context includes the codebase, the product requirements, the design system, the data model, the security constraints, the QA standards. Context also includes business and organizational context, such as the end-user, who in the company needs to be informed of changes, and what contractual obligations exist. The more AI understands about the specific environment it is operating in, the more it can tailor its outputs, and the less rework humans need to do downstream.

Companies that prioritize making their context legible to AI, through shared documentation, well-organized data repositories, and carefully-governed oversight, will see compounding returns. Every piece of context you give AI reduces the edit distance between its first output and the final product. Over time, this creates a flywheel: better context means less rework, which means faster iteration, which provides better context. Quick, curated access to this context will also help employees find the exact right information more quickly to make faster, better decisions.

What endures: Companies need to build a deliberate data strategy that includes the what (what data?), where (where does it reside?), and how (how do we keep it safe?). AI outputs arrive closer to production-ready on first pass. Rework drops significantly. Institutional knowledge becomes usable and transferable.

Pillar 4: Prioritization becomes more important, not less

When development costs drop, companies can launch more. The dangerous conclusion is that now prioritization matters less. If everything is cheap to build, why not build everything? This mindset has been exacerbated by boards that have mandated AI outputs (e.g., launch one new AI feature every quarter this year) instead of measuring AI-driven outcomes.

The innovation constraint has never been solely about development cost. Every new feature you introduce is a change for users who have developed muscle memory around your current experience. Changes must be introduced thoughtfully so users do not feel like your product is constantly shifting beneath them. The companies that win will not be those that ship the most. They will be those that prioritize well, test thoughtfully, and learn the fastest.

To do this, the conversation must move from “What can we build?” to “What should users experience next?” This second question is much harder, requiring better data, faster feedback loops, and stronger product judgment. At Amazon, we use the Working Backwards process, a methodology that starts from the customer experience and works backward to the solution, to focus on solving real customer challenges instead of simply shipping new features. The principle applies regardless of methodology: starting from the desired customer outcome, rather than available technology, ensures that speed translates into value. Even though the Working Backwards methodology is decades old, it is even more relevant now given how simple it is to ship noise to your customers.

What endures: Prioritization is the discipline that converts speed into real value rather than user confusion. It is arguably the most critical pillar. Without it, the other four amplify chaos rather than progress.

Pillar 5: Trust needs to move at the speed of AI

Trust, safety, and compliance must keep up with the pace of production. Product decisions cannot jeopardize trust for the sake of speed, nor can the commitment to responsible AI grind progress to a halt. Organizations will increasingly rely on services such as Amazon Bedrock Guardrails and AWS Security Agent that operate proactively and on pace with development. It is hard to quantify the value of prevention, but companies that prioritize speed or efficiency over trust discover that the cost of a trust violation far exceeds the cost of investments in responsible AI.

More systems will be built with proportional trust: automated pipelines for changes that carry low risk and high confidence, escalating to human review as risk increases. An agent should be able to deploy a simple on-brand color change without human intervention because the impact is small and the rollback is instant. A new data pipeline that touches PII requires a different level of scrutiny. Companies that build trust at scale will increasingly utilize systems that are intelligent about which changes need what level of scrutiny, rather than applying one-size-fits-all gates that slow everything equally.

What endures: Governance becomes a speed multiplier rather than a bottleneck. Low-risk changes ship instantly through automated pipelines. High-risk changes receive proportional scrutiny without blocking the entire release train.

Conclusion: Setting a durable vision for your organization

Innovation has been driving non-stop change for decades. Recent examples include the internet, then the cloud, and now generative AI. History shows us that when leaders make rapid changes without an overarching direction, their teams lose confidence. The pattern is repeating itself yet again.

As Jeff Bezos observed years ago, understanding what’s not changing is more important than what is changing, because you can build a business strategy around things that are stable in time. An executive can tailor the five durable pillars above to add a consistent gravitational pull toward their multi-year vision.

The teams that move fastest on these pillars bring technical and non-technical leadership to the table together. AWS has resources to support a cohesive approach to business growth, product strategy, and engineering. Translating these pillars into your organization’s specific context is where the real work begins, and where partnership accelerates progress. Connect your leadership team with your AWS account team. That’s where durable strategy turns into compounding progress.

How AWS is helping federal agencies lead in quantum computing and post-quantum security

David Appel — Mon, 29 Jun 2026 21:58:01 +0000

Quantum technology is advancing faster than most government planning cycles anticipate. Fault-tolerant quantum computers, machines capable of solving problems beyond the reach of classical supercomputers, now have a clear engineering path and a delivery timeline measured in months, not decades. The first applications will be in scientific computing workloads with deep relevance to federal agency missions, from energy research to materials science to national security. And as quantum hardware improves, so does the urgency of protecting today’s encrypted data from tomorrow’s quantum-enabled attacks, a migration that every agency will need to execute under hard deadlines.

Last week, the White House reinforced that urgency with two Executive Orders that represent the most significant federal commitment to quantum technologies in a generation. The first, Ushering in the Next Frontier of Quantum Innovation, directs a whole-of-government approach to accelerate deployment and commercialization of quantum computing, sensing, and networking, and it establishes the Quantum Computer for Application Development and Discovery Science (QC-ADDS) Effort to deliver a quantum computer at the scale needed for scientific discovery to a Department of Energy (DOE) facility. The second, Securing the Nation Against Advanced Cryptographic Attacks, mandates that all federal high-value assets and high-impact systems transition to (National Institute of Standards and Technology) NIST-approved post-quantum cryptography (PQC) by the end of 2030 for key establishment and 2031 for digital signatures.

This week, DOE acted on that mandate, launching the Quantum Genesis initiative and the Q Competition to develop and deploy the world’s first scientifically relevant fault-tolerant quantum computing systems by 2028. The initiative will establish a National Quantum Supercomputing User Facility integrated with DOE’s exascale high performance computing (HPC), AI, and networking infrastructure.

At Amazon Web Services (AWS), we’ve been building toward this moment for years, on both sides of the quantum equation. On the computing side, we announced this month our expanded strategic collaboration with QuEra Computing to bring the first fault-tolerant quantum computers to the cloud through Amazon Braket, with scientifically relevant applications starting in 2028. On the security side, AWS security experts have been contributing to post-quantum cryptography research and standards-setting efforts for years, including the NIST standards that now underpin the federal PQC mandate. We have a well-defined migration plan already in execution across our infrastructure in alignment with the 2030 and 2031 deadlines outlined in the Executive Order. We’ve already achieved FIPS 140-3 validation for AWS-LC, the cryptographic library deployed across our infrastructure, which means agencies running workloads on AWS are already operating on a PQC-ready cryptographic foundation without needing to procure or deploy separate solutions.

In this post, I explain a little more about why both quantum computing and post-quantum cryptography matter for federal missions, and what agency leaders should be doing now.

The computing opportunity: From experiments to mission applications

Quantum error correction has advanced rapidly. Research teams have demonstrated the core building blocks of fault-tolerant computation: logical qubits that outperform their physical components, real-time error correction at scale, and coherent operation of thousands of qubits in a single system. Based on these advances, AWS and QuEra are bringing Libra, a megaquop-scale device capable of executing one million quantum operations over hundreds of logical qubits, to Amazon Braket customers by 2028.

This matters for federal missions because the problems it can address are ones where classical supercomputers hit fundamental limits. At the megaquop scale, with 250 logical qubits and up to 100,000 hard fault-tolerant operations, researchers will be able to generate scientifically meaningful data that complements and validates what classical methods produce, reducing uncertainty and strengthening scientific conclusions in domains where classical simulations require approximations that can’t be rigorously verified today.

The specific applications are directly aligned to DOE and national security priorities:

Quantum chemistry and energy science – Simulating the molecular processes behind next-generation solar cells and industrial nitrogen fixation, where classical methods are forced to make approximations they can’t verify. Quantum algorithms provide rigorous validation that no classical approach can deliver.
Materials science – Understanding the behavior of strongly correlated materials relevant to high-temperature superconductivity, where classical computers can’t accurately model the quantum interactions that drive the physics.
High-energy physics – Simulating the real-time dynamics of fundamental forces, a class of problems that is exponentially hard for classical supercomputers and directly relevant to our understanding of the universe at its most basic level.
Nuclear physics – Validating the theoretical models used to predict nuclear behavior, where classical simulations rely on assumptions that currently can’t be independently confirmed.

Each of these represents a specific computational bottleneck where the physics of the problem aligns with the capabilities of the hardware being delivered, and where DOE researchers and their national laboratory teams have been co-designing applications with AWS and QuEra for years. And although DOE science missions represent the earliest applications, the same class of computational advantage extends across the federal government: drug discovery and genomics at National Institutes of Health (NIH), logistics and supply chain optimization at the Department of War, and financial risk modeling at Treasury. As fault-tolerant systems scale, the set of agencies with mission-relevant quantum workloads will grow rapidly.

The Executive Order makes the federal intent explicit: the United States must move quickly beyond quantum research and into deployment of systems capable of scientifically relevant computation. The order directs the Department of War to establish activities and programs to advance readiness for national security applications of quantum computing and calls on the Department of Energy to define technical specifications for transformative scientific applications within 90 days. DOE’s Quantum Genesis initiative and Q Competition define exactly what “scientifically relevant” means: fault-tolerant systems with hundreds of logical qubits, targeting applications in chemistry, materials science, plasma physics, and high-energy physics, delivered by 2028. The system AWS and QuEra are building matches those targets directly, with 250 logical qubits, up to 100,000 hard fault-tolerant operations, and cloud-native integration with classical HPC at scale.

Amazon Braket brings fault-tolerant quantum computing directly to the cloud, integrated with the classical HPC and AI infrastructure agencies already use. This is a critical point: fault-tolerant quantum workloads are inherently hybrid, requiring tight coordination between quantum processors and large-scale classical compute for preprocessing, error decoding, and postprocessing at every step. Braket delivers this as a single environment, inherently connected to AWS elastic HPC resources, GPU-accelerated compute, and workflow orchestration, so agencies can build end-to-end quantum-classical pipelines without standing up separate infrastructure or managing a second security posture.

“This is a very special moment. For the first time, a dream of realizing useful, fault-tolerant quantum computers is in our direct line of sight. Designed to enable quantum computation at an unprecedented scale, these systems should realize truly unique applications. We are proud to significantly expand our collaboration with AWS to bring these unique capabilities to the broader community of scientific users.” — Prof. Mikhail Lukin, Chief Science Officer, QuEra Computing.

The security imperative: Post-quantum cryptography can’t wait

Adversaries can harvest internet traffic today with the intent to decrypt it when quantum computers mature. This makes it urgent to upgrade encryption for data in transit that must remain confidential for 10-plus years. Similarly, long-lived devices such as industrial controllers, vehicles, and satellites that establish their cryptographic roots of trust at manufacture and often can’t be updated post-deployment need quantum-resistant roots of trust starting now. As quantum computing continues to advance, the timeline to a device capable of breaking today’s public-key cryptography is also compressing, and agencies can’t afford to assume that timeline is distant.

The new Executive Order on cryptographic security requires every agency to designate a PQC migration lead within 30 days. It mandates transition of all high-value assets and high-impact systems to NIST-approved PQC algorithms on hard deadlines. It directs the Federal Acquisition Regulatory Council (FAR) Council to amend acquisition regulations to require contractor compliance by 2030. Global regulators beyond the U.S. have set hard deadlines for quantum-resistant confidentiality as early as 2027 and quantum-resistant authentication as early as 2029, making this a worldwide migration, not merely a federal one.

AWS has been leading this migration since before the standards were finalized. AWS has been active in the development and deployment of PQC since 2013. AWS employees contributed to the three new FIPS standards (ML-KEM, ML-DSA, and SLH-DSA) published by NIST in August 2024. Our open source cryptographic library, AWS-LC, already implements these algorithms. Our TLS implementation, s2n-tls and s2n-quic, has supported post-quantum key exchange since 2019.

Our migration plan is structured across four workstreams:

Inventory and standards development – Completing cryptographic inventory, defining how PQC integrates into specific applications and protocols
PQC on public endpoints – Deploying ML-KEM across all AWS service endpoints to protect long-term confidentiality of data in transit
Long-lived roots of trust – Delivering ML-DSA across key services to enable secure code, document, and firmware signing
Session authentication – Migrating to PQC digital signatures for server and client certificate validation

For government customers, this means the cloud infrastructure you run on is already preparing for the post-quantum era, providing a foundation your agency’s migration plan can build on. Our goal is to deliver PQC in alignment with secure-by-default principles: transparent use, imperceptible performance impact, and minimal configuration required. A proactive and well-scoped migration strategy makes these upgrades a strategic decision rather than a deadline-driven fire drill, and organizations running on modern cloud services are better positioned than ever to migrate faster with least operational impact. AWS offers no-cost consultations to help agencies get started on PQC plans for legacy and on-premises workloads.

AWS is ready to support your mission

Quantum computing and quantum security are deeply connected, and agencies that treat them with equal mission priority will be the ones best positioned to lead.

AWS is prepared to meet agencies on both. Amazon Braket gives teams access to quantum hardware today, with managed development environments, leading software frameworks, and direct integration with AWS HPC and AI infrastructure, so they can build skills and co-design applications now rather than starting from zero when fault-tolerant systems arrive. On the security side, our open source cryptographic libraries already implement NIST-standardized PQC algorithms, AWS Key Management Service (AWS KMS) and AWS Private Certificate Authority support the new quantum-resistant signing algorithms, and our security specialists are working with federal customers to map migration plans grounded in how workloads are deployed. We’ve been running this model with national laboratories, defense research organizations, and intelligence community collaborators for years.

Quantum matters to your mission. The question is whether you’re moving at the speed the moment demands.

Let’s build together.

Join us at the AWS DC Summit, Session FED203, on June 30, 2026, at 9:45 AM ET to hear more about AWS and quantum computing for government missions.

Learn more about Amazon Braket, the AWS and QuEra collaboration, and the AWS post-quantum cryptography migration plan.

Providing equitable access to NASA’s Earth science data archive

Chris Stoner — Mon, 29 Jun 2026 14:53:35 +0000

NASA’s Earth Science Data and Information System (ESDIS), at Goddard Space Flight Center, manages a vast archive of over 170 petabytes (PB) of Earth science data. Researchers worldwide use this data globally, with more than 450 terabytes (TB) distributed daily to over 8 million users each year.

We have experienced rapidly increasing data volumes, largely due to new, high-data-volume Earth observation missions such as Surface Water and Ocean Topography (SWOT) and NASA/ISRO Synthetic Aperture Radar (NISAR). To effectively ingest, process, and store this growing archive, ESDIS requires a data-management architecture that is cost-effective, flexible, and scalable. To meet these needs, most components of ESDIS are currently operating within the Amazon Web Services (AWS) commercial cloud, with the goal of migrating all of NASA’s Earth science data to the AWS Cloud by the end of 2026.

The shift of data and services to the cloud wasn’t primarily driven by the sheer volume or cost of storing that data. NASA Earth science data has been openly and freely accessible since ESDIS began operations, in accordance with NASA’s full and open data policy. This policy allows all NASA mission data to be available to anyone, anywhere in the world, without restriction.

However, upholding this open data policy requires addressing the challenges posed by modern data volume and processing needs. We needed to address the problem that Ryan Abernathey of EarthMover termed the “data fortress.” The capability to download and store massive amounts of data (terabyte-scale) and apply high performance compute to that data typically requires resources only available to government agencies, universities, and businesses. Because not all our user community belongs to these entities, we recognized the need to provide this capability to all users.

Our challenges were as follows:

How can we establish an environment that provides equitable access to our data?
How will we fund this environment given the near-exponential growth of our archive?
How do we successfully integrate with the new cloud environment and its diverse user base?

Achieving equitable access

A commercial cloud environment provides equitable access by allowing all our users into the data fortress. A commercial cloud environment containing our archive rather than a government run solution also mitigates risk for NASA. Although we do provide open and free data, we don’t provide unlimited “free science.” We can’t provide unlimited free compute to our users, and we aren’t in a position to manage charging them for it.

A commercial cloud environment reduces those risks while providing the scalable compute resources that we need. A cloud environment also means that users can rent rather than own resources. As a result, individual researchers can afford far more compute power than their budgets would allow if they had to own their compute.

Users can spin up the necessary resources adjacent to the data, perform their analysis directly on the data in the cloud, and then spin them down. This eliminates the need for data downloads and the burden of permanent, costly ownership. To summarize, by migrating the Earth data archive to AWS, we can provide equitable access to Earth science data adjacent to high performance computing resources.

Funding this environment with near-exponential data growth

By migrating to a commercial cloud environment, specifically AWS, we can enhance scientific discovery, streamline operations, and realize significant cost efficiencies across our infrastructure.

Data storage

Our latest missions generate petabytes of data, requiring a highly scalable and flexible storage solution. AWS offers on-demand scalability with minimal overhead, and we’ve implemented several AWS services to achieve substantial cost savings in this area:

Optimized rates – Negotiated bulk storage rates reduce overall purchasing costs.
Intelligent tiering – The Amazon Simple Storage Service (Amazon S3) Intelligent-Tiering storage class automatically moves data between storage classes based on usage patterns. This has realized an estimated 60% reduction in our storage costs.
Data protection – Amazon S3 versioning serves as a lazy-copy solution to mitigate the risk of accidental or malicious data deletion, offering resilience without the need for expensive, comprehensive, full-scale backups.

Compute power

ESDIS and our users can bring processing algorithms and software directly to the data in the cloud. This approach eliminates complexity related to hardware support and procurement, thereby accelerating the pace of scientific discovery. Our compute cost efficiencies are achieved through:

Savings plans – Purchasing compute capacity in advance and in bulk through Compute Savings Plans.
Serverless architecture – Using serverless services (such as AWS Lambda, AWS Fargate, and Amazon API Gateway) means that we only pay for the resources actively in use, avoiding the cost of idle capacity.
On-demand processing – Using Amazon Elastic Compute Cloud (Amazon EC2) Spot Instances for on-demand, asynchronous data processing at significantly lower rates than standard pricing.

Infrastructure and operations

The adoption of a common infrastructure based on cloud-native services has reduced tool redundancy, facilitated data and service sharing, and promoted the use of uniform community standards, policies, and processes. Our general infrastructure cost reductions are a result of:

Economies of scale – The amount of resources AWS needs to acquire gives them the power to make cheaper acquisitions in bulk, which means we acquire services for less cost.
Reduced labor – The use of managed services offloads operational tasks, resulting in reduced labor costs.

Integrating with the diverse user base of AWS

How can we effectively introduce ourselves to this new community and publicize the more than 170 petabytes of freely available, open Earth science data? The Registry of Open Data on AWS is the primary channel for sharing data on AWS, which we now use.

On May 4, 2026, NASA advanced its open science goals by making over 6,000 Earth Science collections visible in the Registry of Open Data on AWS. We organized our collections by mission or project into roughly 300 distinct Open Data Registry entries, which you can access using the NASA Space Act Agreement subcatalog in the Registry.

This addition establishes a vital connection for AWS users, who can now seamlessly discover and analyze NASA data. By enhancing public access, this effort promotes collaboration and accelerates the development of advanced Earth science applications and services within AWS offerings.

At the time of this writing, AWS users can access dataset metadata and essential access information through the Registry of Open Data on AWS. To further enrich the experience, future plans include detailing tutorials and notebooks to guide users on using NASA Earth Science data within AWS.

Figure 1: NASA/AWS group photo commemorating the 300 NASA datasets that put the Registry of Open Data over 1,000 datasets. Pictured from left to right: Chris Stoner/AWS, Doug Newman/NASA, David Appel/AWS, Andrew Mitchell/NASA, Kevin Murphy/NASA, and Jamie Baker/AWS.

What NASA ESDIS has done and what is next

NASA Earthdata currently archives over 170 petabytes of data. We have over 90% of our archive in Amazon S3 with a goal to migrate all of it by the end of 2026. AWS users can find the data through the Registry of Open Data and access it within the US West (Oregon) – us-west-2 Regions through Amazon S3, the AWS Command Line Interface (AWS CLI), AWS SDKs such as AWS SDK for Python (Boto3), or from any location using HTTPS. We will continue to bolster our datasets in the Registry of Open Data on AWS, adding new datasets and augmenting existing ones with elements such as tutorials and notebooks to increase their usability to the AWS user community.

Want to learn more?

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.

MARS-E to ARC-AMPE: Guide for state Medicaid agencies on AWS

Vignesh Srinivasan — Sun, 28 Jun 2026 21:45:51 +0000

On March 4, 2026, the Centers for Medicare & Medicaid Services (CMS) replaced the Minimum Acceptable Risk Safeguards for Exchanges (MARS-E) v2.2 with the Acceptable Risk Controls for Affordable Care Act (ACA), Medicaid, and Partner Entities (ARC-AMPE). ARC-AMPE rebases the compliance program on NIST SP 800-53 Revision 5, expands the control catalog significantly for administering entities (AE) and Direct Enrollment (DE) entities, and merges privacy and security into a single governance model.

The AE deadline passed as of March 4, 2026. The DE deadline is in June 2026. For agencies running Medicaid, Children’s Health Insurance Program (CHIP), or Affordable Care Act Marketplace workloads on Amazon Web Services (AWS), ARC-AMPE is now in scope.

This post is for two audiences. The first is agencies already running MARS-E-compliant workloads on AWS that are looking to map their existing posture onto the new framework. The second is agencies planning a migration from on-premises infrastructure where ARC-AMPE will be in scope from the first day.

What’s different about ARC-AMPE

Three things changed, and they’re the reason existing MARS-E documentation can’t be relabeled:

1. NIST 800-53 Rev 4 became Rev 5

Under MARS-E, the System Security and Privacy Plan (SSPP) tracked controls against NIST SP 800-53 Rev 4. ARC-AMPE moves to Rev 5. Rev 5 reorganized control families, renumbered controls, retired some controls, added others, and pulled privacy out of a separate appendix and into the main catalog. Every existing MARS-E control mapping requires an analysis against the new numbering.

2. Privacy and security now live in the same plan

MARS-E maintained 18 security domains and eight privacy domains as parallel tracks. Many agencies ran them on separate teams, with separate documentation, and on separate assessment cycles. ARC-AMPE collapses everything into 20 unified control families in a single SSPP. Privacy controls sit alongside security controls, and the assessment covers both. For agencies where privacy and security have historically been separate functions, ARC-AMPE requires those teams to coordinate under shared governance.

3. Two new control families with no MARS-E predecessor

Two of the 20 families are net-new and don’t have a MARS-E equivalent to anchor against:

PT (Personally Identifiable Information Processing and Transparency) – Ten new controls
SR (Supply Chain Risk Management) – Six new controls

These controls require technical implementation in your applications and data layer as well as new policies. The following table summarizes the key differences between MARS-E v2.2 and ARC-AMPE v1.0:

Dimension	MARS-E v2.2	ARC-AMPE v1.0	What it means
NIST baseline	Rev 4 (2013)	Rev 5 (2020)	Existing control mappings need to be rebuilt
Control count (AE)	~300	402	Roughly 100 net-new controls in scope
Privacy treatment	Eight separate domains	Integrated into 20 unified families	Privacy and security operate under one plan
New control families	NA	PT, SR	Net-new implementation, no MARS-E carry-over
SSPP format	Word	Excel	Existing documentation workflows need to be rebuilt

How AWS reduces the gap

ARC-AMPE inherits its control catalog from NIST SP 800-53 Rev 5. AWS holds Federal Risk and Authorization Management Program (FedRAMP) authorizations built on the same standard, which means a significant portion of the ARC-AMPE catalog can inherit the controls enabled by AWS.

This is the standard AWS shared responsibility model applied to a control catalog that ARC-AMPE happens to share with FedRAMP. Customers can think about it this way:

AWS-inherited controls – AWS operates under its FedRAMP authorization. Agencies reference AWS compliance evidence in AWS Artifact. Physical and Environmental Protection (PE) and Media Protection (MP) families fall here.
Shared controls – AWS provides infrastructure capability, and the agency configures and operates it. Most of Access Control (AC), Audit and Accountability (AU), Configuration Management (CM), Contingency Planning (CP), and System and Communications Protection (SC) sit in this category.
Customer-owned controls – AWS provides tooling at most; the agency owns the process, documentation, and execution. Awareness and Training (AT), Planning (PL), Personnel Security (PS), Program Management (PM), and the two new PT and SR families fall here.

For agencies running on AWS today, the implementation concentrates on customer-owned and shared categories. Crosswalks between the AWS FedRAMP package and ARC-AMPE indicate the majority of the catalog is satisfied or partially satisfied through inheritance and shared configuration, with the residual work concentrated in privacy governance (PT, PM), supply chain documentation (SR), and a focused set of personally identifiable information (PII)-handling controls.

Where Security Hub CSPM can help

For most compliance frameworks, AWS Security Hub Cloud Security Posture Management (CSPM) is a useful tool. For ARC-AMPE specifically, AWS Security Hub CSPM NIST 800-53 standard enabled runs continuous automated checks against the same control catalog ARC-AMPE is built on.

That alignment means continuous monitoring is built in. ARC-AMPE requires an Information Security and Privacy Continuous Monitoring (ISCM) program. Security Hub CSPM, with the NIST 800-53 Rev 5 standard enabled, closes that requirement for a substantial portion of the catalog by default. Audit evidence is also generated. Security Hub CSPM publishes findings using NIST 800-53 Rev 5 control identifiers. Those are the same identifiers an ARC-AMPE assessor will reference. The following table maps core AWS services to the NIST 800-53 control families they support and their role in continuous monitoring:

AWS service	Primary control families	Role
AWS Security Hub	AC, AU, CM, CP, IA, IR, SC, SI	Continuous control monitoring against NIST 800-53 Rev 5 standard
AWS Config	CM, CA, SC, SI, AU, IA	Configuration recording, drift detection, and NIST 800-53 Rev 5 Conformance Pack
Amazon Macie	PT, SI	Automated PII discovery and classification in S3. Supports PT-2, PT-3, and PT-7(1) data tagging requirements
AWS Key Management Service (AWS KMS)	SC, PT	FIPS 140-3 validated HSMs. Encryption at rest (SC-12, SC-13, SC-28). Envelope encryption for SSN fields (PT-7(1))
AWS CloudTrail	AU	API activity logging (AU-2, AU-3, AU-6, AU-9, AU-12). With S3 lifecycle, satisfies AU-04 retention
Amazon GuardDuty	SI, IR	Threat detection (SI-4), incident handling support (IR-4, IR-5). Malware detection for EBS
AWS Artifact	CA, SA	FedRAMP packages, SOC reports, and other control evidence. Supports SR-2 vendor documentation for AWS layer

If you’re already on AWS

If your agency is running MARS-E-compliant workloads on AWS today, the transition to ARC-AMPE is smaller than the whole list of 402 controls. Most of the infrastructure investment is carried forward. There are three primary places to focus on: rebuilding the SSPP against the new control structure, implementing the PT family controls in the application layer, and formalizing supply chain risk documentation.

What carries forward

The portions of your AWS environment that derive from FedRAMP authorization (PE, MP, the infrastructure layers of AC, AU, CM, SC, SI) carry forward without modification. The shared responsibility model doesn’t change. Specifically:

Multi-account structures and service control policies (SCPs)
AWS Identity and Access Management (AWS IAM) roles, policies, and permission boundaries
AWS Key Management Service (AWS KMS) keys, key policies, and encryption configurations
Amazon Virtual Private Cloud (Amazon VPC) topology, network segmentation, and traffic isolation patterns
AWS CloudTrail, Amazon CloudWatch Logs, and log retention configurations
Existing AWS Security Hub, AWS Config, Amazon GuardDuty, and Amazon Macie deployments

If AWS Security Hub CSPM is enabled with the NIST 800-53 Rev 5 standard, the control evaluations from your existing environment translate directly to ARC-AMPE evidence.

The steps in the following action plans deploy AWS services that incur charges including AWS Security Hub, AWS Config, Amazon Macie, Amazon GuardDuty, AWS KMS, AWS Lambda, Amazon API Gateway, Amazon DynamoDB, and Landing Zone Accelerator on AWS. Use the AWS Pricing Calculator to estimate costs for your environment before proceeding and remove any resources you deploy for evaluation that you don’t intend to keep.

Action plan

Enable AWS Security Hub CSPM with the NIST 800-53 Rev 5 standard across all in-scope accounts. For multi-account environments, enable AWS Security Hub in the management account and use delegated administration. See Setting up AWS Security Hub for enablement steps.
Deploy the AWS Config NIST 800-53 Rev 5 Conformance Pack.
Download the FedRAMP CRM from AWS Artifact.
Map the inherited controls into the ARC-AMPE Volume II Excel SSPP. For each control in the FedRAMP CRM marked AWS-inherited (PE and MP families); copy the control identifier, implementation status, and AWS evidence reference into the corresponding row; and document the inheritance relationship in the implementation description field.
Inventory the non-AWS supplier chain (SaaS, managed services, integrators). The AWS FedRAMP package in AWS Artifact is your supplier documentation for the AWS layer.
Use AWS Service Catalog to restrict your environment to pre-approved services for third-party tools and partners.
For PT, application owners, data engineers, and privacy teams need to work together to implement these new controls: application owners define PII processing requirements, data engineers build the technical controls (tagging, encryption, consent APIs), and privacy teams validate policy compliance.
Deploy Amazon Macie for automated PII discovery.
Configure AWS KMS envelope encryption for SSN fields.
Build consent capture with Amazon API Gateway, Amazon DynamoDB, and AWS Lambda.
Rebuild the SSPP in the ARC-AMPE Volume II Excel template with control owners per family.
Map existing AWS evidence (AWS Security Hub findings, AWS Config evaluations, AWS CloudTrail logs) to the new control structure.
Configure AWS CloudTrail retention for AU-04 (90-day online, 10-year S3 Glacier Deep Archive).

If you’re migrating from on-premises

If your agency is planning a Medicaid or ACA Marketplace migration to AWS, ARC-AMPE changes how to scope the migration. Several decisions that were optional or deferrable under MARS-E are now architectural requirements.

What carries forward

Your existing MARS-E governance work carries forward as input to the new ARC-AMPE SSPP even though control numbering changes. You don’t have to rebuild organizational governance from scratch.

Action plan

For agencies migrating from on-premises, follow this plan to establish an ARC-AMPE-aligned environment:

Deploy the Landing Zone Accelerator on AWS with the following configurations:
1. a. AWS Security Hub with the NIST 800-53 Rev 5 standard
2. b. AWS Config with the Conformance Pack
3. c. AWS CloudTrail with AU-04 retention
4. d. Organization-level data residency SCPs
Define the consent architecture before you start migrating data.
Define PII classification of data before you start migrating data.
Start executing from step 3 of action plan in previous section for customers already on AWS.

The following diagram shows the recommended starting sequence for ARC-AMPE readiness, with separate entry points for agencies already running MARS-E workloads on AWS and those migrating from on-premises and converging on a shared set of steps:

Figure 1: Action plan

The two new control families: PT and SR

PT and SR are the two control families with no MARS-E predecessor.

PT: PII Processing and Transparency

PT addresses how PII is identified, classified, processed, and managed in the system. The high-leverage controls cluster in three areas:

Data tagging and classification (PT-2, PT-3) – PII has to be tagged with its processing authority and permitted use. Amazon Macie provides automated PII discovery in Amazon Simple Storage Service (Amazon S3), and metadata schemas in Amazon DynamoDB or Amazon Relational Database Service (Amazon RDS) can carry processing-authority tags per data element. The pattern that scales is to do classification at the point of ingestion rather than retroactively across an existing data lake.
Consent management (PT-4) – Consent capture, enforcement, and revocation typically come together as a small set of components: a preference store (Amazon DynamoDB), an API for capture and update (API Gateway plus Lambda), and an enforcement mechanism that downstream services consult before processing. Records should include timestamp, scope, purpose, and revocation state.
SSN handling (PT-7(1)) – SSN protection can be implemented through field-level encryption with AWS KMS envelope encryption, with Amazon Macie custom data identifiers detecting unintentional SSN exposure in unstructured data.

The remaining PT controls (privacy notices, individual access, accounting of disclosures, redress) are largely policy and process, but they need to be backed by technical evidence that these implementations produce.

SR: Supply Chain Risk Management

SR addresses vendor and supplier risk across the service chain.

The infrastructure layer (SR-3, SR-6) – AWS FedRAMP authorization documents the supplier risk for the AWS services in scope. Pull the FedRAMP package from AWS Artifact and reference it in the Supply Chain Risk Management Plan. The package includes the SSP, the Security Assessment Report, and the Plan of Action and Milestones, which together satisfy a substantial portion of SR for AWS itself.
Everything else – SaaS tools, managed services, system integrators, and partner entities each need a documented risk assessment with contractual security requirements. An efficient pattern is to maintain a vendor inventory in a single tool with an assessment template and a renewal cadence.

Choosing a region: Commercial or AWS GovCloud (US)

ARC-AMPE doesn’t mandate AWS GovCloud (US). It requires US data residency under SA-9(8) and adherence to the full control catalog, both of which are achievable in AWS US commercial Regions. Many state and local government agencies run regulated workloads in commercial Regions successfully. For agencies with Medicaid workloads requiring FedRAMP Moderate level compliance, US commercial Regions paired with Health Insurance Portability and Accountability Act (HIPAA)-eligible service configurations, FIPS 140 endpoints, AWS KMS encryption, and a signed Business Associate Agreement (BAA) can help to meet compliance. For agencies with workloads needing FedRAMP High compliance, AWS GovCloud (US) can host your workloads. The following table compares AWS US commercial Regions and AWS GovCloud (US) across the factors most relevant to ARC-AMPE compliance:

Factor	AWS US commercial Regions	AWS GovCloud (US)
FedRAMP authorization	Moderate	High
HIPAA-eligible services	Yes (with BAA)	Yes (with BAA)
Suitable for Federal Tax Information (FTI)/IRS Publication 1075	Yes	Yes
Service availability	Full	Subset, expanding
Account onboarding	Standard	Additional vetting required

Where to start

Three actions agencies can take in the immediate future include:

Enable AWS Security Hub with the NIST 800-53 Rev 5 standard – This is a high impact step for closing the ARC-AMPE gap. The findings published against Rev 5 control identifiers translate directly into ARC-AMPE evidence, and the continuous monitoring capability satisfies a meaningful portion of the ISCM requirement on its own.
Pull the FedRAMP package from AWS Artifact – The package serves as the foundation of the Supply Chain Risk Management Plan for the AWS layer and provides the inherited control evidence for the SSPP. Sign into the AWS Artifact console, download the NIST 800-53 Rev 5 Customer Responsibility Matrix, and stage it as the supplier documentation root.
Engage an AWS Security Health Improvement Program (SHIP) assessment – SHIP is a no-cost engagement that evaluates the AWS environment across several security use cases and provides a prioritized remediation roadmap. For agencies preparing for an ARC-AMPE assessment, SHIP is a low-friction way to identify gaps before an assessor does. Reach out to the AWS account team to scope the engagement.

For agencies planning a migration, also reach out to the account team about the Landing Zone Accelerator on AWS. An efficient path to an ARC-AMPE-aligned environment is to deploy the Landing Zone before workloads start moving, then migrate into a baseline that’s already monitored and instrumented.

Conclusion

ARC-AMPE expands the compliance baseline, but the scope is manageable. FedRAMP reciprocity covers most of the catalog at the infrastructure layer, and the residual work concentrates in PT, PM, SR, and a focused set of PII-handling controls.

Agencies already on AWS carry their existing infrastructure investment forward. The residual work is weighted toward documentation and privacy implementation. Agencies migrating from on-premises can land in an ARC-AMPE-aligned environment from the first day through the Landing Zone Accelerator on AWS, gaining inherited controls, automated monitoring, and a compliant foundation as part of the migration.

Compliance is a shared responsibility between AWS and the customer. This post helps agencies understand how AWS services relate to ARC-AMPE requirements and does not constitute legal or compliance advice. Agencies should work with qualified assessors to validate their specific compliance posture. For the list of AWS services in scope of specific compliance programs, see AWS Services in Scope by Compliance Program.