AWS Public Sector Blog

A community credit union’s path from VMware outages to cloud resilience

Jason Beard — Wed, 16 Sep 2026 16:11:06 +0000

For 70 years, Carter Credit Union has served communities across northwest Louisiana and beyond. What started in 1954 as a small financial cooperative for International Paper company employees in Springhill, Louisiana, has grown into a $770 million institution serving more than 45,000 members across 13 locations. For many of those members, particularly in rural and underserved areas, Carter represents their primary access point to mainstream financial services, financial education, and the economic stability that comes with belonging to a trusted institution.

But behind that growth was an aging technology infrastructure that put member services at risk. In 2022, Carter’s IT team began migrating the credit union’s on-premises VMware environment to Amazon Web Services (AWS), a move that would reduce costs, strengthen security, and facilitate uninterrupted access for the communities that depend on Carter. What makes the story remarkable is that a three-person team executed the entire migration while maintaining continuous service to members.

The breaking point

Carter’s legacy environment relied on a VMware virtualization stack hosted on physical servers in a single data center, all dependent on one fiber circuit for connectivity. Jason Berard, Carter’s chief information technology officer, saw how vulnerable this architecture was when a construction crew severed the primary fiber line. The backup circuit, which was routed through the same conduit, failed simultaneously. The organization remained completely offline for 24 hours. In a separate incident, a hardware failure caused a multiday outage, leaving critical systems unavailable for 3 consecutive days.

“We had a single point of failure in almost every layer of our infrastructure,” Berard said. The credit union had moved some VMware workloads to a colocation facility in Dallas, Texas, but the arrangement still required Carter’s small team to manage physical hardware, maintain VMware licensing, handle firmware updates, and budget for server replacement cycles every 3–5 years. The total cost of ownership continued to climb while the risk of member-facing outages remained unacceptably high.

Choosing AWS

Berard evaluated AWS, Google Cloud, and Microsoft Azure. The determining factor came not from a sales pitch but from a peer recommendation: The president of a credit union service organization (CUSO) shared their positive experience migrating to AWS, and colleagues across the credit union industry confirmed similar results. In a sector built on trust and cooperative values, those endorsements from fellow practitioners carried more weight than any vendor presentation. AWS also offered purpose-built solutions for credit unions, including infrastructure designed to meet the compliance and security requirements that financial institutions navigate daily.

A phased migration from VMware to AWS with a small team

Carter’s entire migration from its VMware environment to AWS was executed by a team of three, with Berard providing strategic oversight and two infrastructure specialists handling the day-to-day technical work. Rather than attempting a full lift and shift over a single weekend, the team chose a phased strategy that meant they built confidence and validated performance at each step before moving to the next set of workloads.

Carter began with a set of servers already approaching required operating system (OS) upgrades. Rather than investing in OS updates on aging hardware and renewing VMware licensing, the team rebuilt those workloads in AWS. As the migration matured, they incorporated AWS Transform MGN to streamline the transition of remaining systems.

One team member, Randy, had spent his career managing traditional on‑premises data centers. To support the shift in skill requirements, the team completed AWS training focused on cloud server management, auto scaling, and cost optimization. That investment proved effective: Carter successfully executed the migration without hiring external consultants and without disruption to member services throughout the transition.

Expanding access through Interactive Teller Machines

Carter has been rethinking how it delivers financial services to members who might not live near a traditional branch. The credit union has deployed an Interactive Teller Machine (ITM) service called CarterLIVE! as its primary service model across most locations, with only one traditional teller-line branch remaining.

These machines connect members to live tellers through two-way video while providing standard ATM functionality, effectively bringing face-to-face financial guidance to communities that might otherwise lack convenient access. As a next step, Carter is migrating its ITM infrastructure to a hybrid cloud model, splitting components between the credit union’s AWS environment and the ITM vendor’s cloud platform. With this collaborative approach, Carter aims to deliver the same redundancy and uptime the rest of its environment now enjoys while further strengthening its ability to serve members in rural and underserved areas.

Measurable results for members and the bottom line

Over a 3-year analysis period, Carter documented meaningful cost savings compared to the hardware replacement cycles, VMware licensing renewals, and maintenance contracts they would have faced on premises. Carter is projected to save more than $70,000 by migrating to AWS rather than refreshing its existing on‑premises server environment. These savings come from avoided hardware replacement costs, eliminated VMware licensing renewals, reduced data center overhead, and the efficiencies gained through the AWS consumption-based model.

The savings translate directly into resources Carter can reinvest in member services, financial education programs, and community development initiatives rather than spending them on hardware that depreciates the moment it arrives. In AWS, the credit union pays for the compute and storage it actually uses, scaling resources with member demand rather than overprovisioning for peak capacity.

The migration has also delivered a measurable improvement in security posture. Carter now benefits from AWS infrastructure designed to meet the security and compliance standards required by financial regulators, including encryption at rest and in transit, identity and access management controls, and continuous monitoring capabilities that would have been prohibitively expensive to implement on premises.

Most importantly for members, Carter hasn’t experienced the kind of extended outages that previously disrupted services. Members can access their accounts, process transactions, apply for loans, and connect with live tellers through CarterLIVE! video banking without interruption whether they bank in Shreveport, Springhill, or anywhere else in the country.

What other credit unions can learn

Carter Credit Union’s migration demonstrates that moving from an on-premises VMware environment to the cloud doesn’t require a large IT department or a massive budget. A small, focused team with the right training and a phased plan can modernize critical financial infrastructure while maintaining service for the members and communities who depend on them.

Here are some lessons to keep in mind if you’re considering a similar migration:

Start with what needs upgrading anyway. Servers due for OS or hardware refreshes are natural first candidates for cloud migration.
Invest in training before you migrate. Cloud fluency changed how Carter’s team approached every subsequent infrastructure decision.
Lean on peers in the credit union community. Industry networks and CUSOs can provide honest firsthand feedback no vendor whitepaper can replicate.
Phase the work and protect member service above all else. A gradual approach reduces risk and means members don’t bear the consequences of a transition they didn’t ask for.

To learn more about how AWS supports credit unions, visit the Digital Transformation for Credit Unions page or explore cloud migration resources to plan your own journey.

Carter Credit Union is headquartered in Shreveport, Louisiana, and has served its communities since 1954. Learn more at cartercu.org.

Develop an AI voice command center with Amazon Quick and Kiro

Courtney Maatta — Mon, 14 Sep 2026 20:08:13 +0000

Amazon Web Services (AWS) public sector teams devote a significant portion of each day to administrative work such as compiling cost reports, monitoring security posture, triaging email and chat, and maintaining an accurate calendar. Individually, these tasks are minor. Collectively, they consume time and attention that could be better directed toward mission outcomes and the constituents these organizations serve.

With the solution example in this post, you can build a voice-activated command center that runs on your local machine, listens when you talk to it, and answers back using a clean, high-tech dashboard. You can learn how to build a command center (you can give it a fun name such as Jarvis or Alfred) that briefs you on finances, security, your calendar, and your inbox. With an AI-powered integrated development environment (IDE) and a desktop productivity assistant, it doesn’t leave your laptop.

This post covers the two prerequisites needed (a desktop assistant and an AI IDE), how they connect through a straightforward file bridge, why this pattern is a good fit for public sector constraints, and what to keep in mind when it comes to cost.

This is a build-it-yourself, local solution for personal and team productivity. You’ll be using local desktop services including Amazon Quick for desktop and Kiro.

What you’ll build

The result is a desktop application that gives you:

A sci-fi-style animated dashboard – A heads-up display with a live dial, transcript, and status readouts that react as you speak
Voice in and out – Talk to it and it speaks back to you in a short briefing
C-suite advisors you can call by name, for example:
- Chief financial officer (CFO) – A spending or cost briefing
- Chief security officer (CSO) – A security posture review
- UX designer – Spins up a new design project using the open source Open Design toolset
- Daily summary – What happened across your work day, plus quick calendar and email checks
- AI developer – Drives your local AI IDE to build and refine things for you

Everything runs on your Mac or desktop operating system (OS). There’s no server to set up and data doesn’t leave your machine unless you explicitly wire an integration to do so. For example, you can say “Call my CFO” or “chief financial officer” as the key command to call the agent. The following image is an example of the end result, which is a local voice command center:

Figure 1: The local command center dashboard running on your desktop

Please note that names in this post are for fun demonstration purposes only. Any names shown, such as Jarvis or Alfred, are used solely as illustrative, user-chosen display names for a personal, local tool. Product names, logos, and brands are the property of their respective owners, and their use here is nominative and for demonstration purposes only. Choose your own name for your assistant and confirm you have the right to use any name or mark you adopt.

How it works: The file bridge

You build the bridge by prompting Amazon Quick for desktop. The command center itself is intentionally lightweight and offline. It doesn’t call a third-party API directly. Instead, it exchanges small JSON files with a desktop assistant through a shared folder called the bridge. Your AI desktop assistant does the work of connecting to email, chat, and reporting sources and writes the answers back for the command center to read aloud.

The following diagram shows the end-to-end flow, from your voice command to the spoken briefing:

Figure 2: AI desktop to voice command center workflow. Major components are Amazon Quick and Kiro. Kiro CLI is depicted

The key idea: The desktop assistant creates and fills the responses/ and outputs/ folders; the command center only reads results for Amazon Quick. That clean separation is what keeps the local app lightweight and private.

Prerequisite 1: A desktop assistant to feed the bridge

Amazon Quick for desktop is a productivity assistant available for macOS and Windows that can connect to the services you already use and act on a schedule. This is the engine behind the bridge. The steps in the following section walk you through setup, agent creation, and wiring the bridge.

Before you create agents: Three quick setup tasks

When you install Amazon Quick for desktop, do these three things first so the assistant has good local data to work with and a place to write:

Enable your integrations – Turn on the Google Calendar, email, Microsoft Teams, and Slack connections so Amazon Quick has accurate local data to supply the voice app.
Create the bridge folder – Make a local folder named CoS-Bridge in your Documents folder (~/Documents/CoS-Bridge). This is where the assistant and the command center exchange files.
Grant Amazon Quick access to the folder – In Amazon Quick, open the left sidebar, select My Computer inside Quick, and give Amazon Quick access to your CoS-Bridge folder so it can read requests and write results there.

Give Amazon Quick these agent prompts

With integrations enabled and the folder in place, create scheduled agents in Amazon Quick using plain-language prompts such as these. (Adapt the specifics to your own sources.)

1. Daily Report agent

Set up a Daily Report agent that runs at 3AM and sends me an email. It should provide me with key activities from my email over the last week, upcoming events, and calendar key activities for the week.

2. CFO Report agent

Set up a CFO Report that pulls my Amazon Web Services (AWS) cost and billing report data from my email, my Salesforce dashboards, and any reports that are cost- and budget-related.

3. CSO Report agent

Set up a CSO Report that pulls in <enter your security-related email or source>. (The AWS Security Agent is also a Kiro power that can scan a repository for you and summarize vulnerabilities, which is a useful complement to the CSO briefing.)

To wire these into the voice app, you also create a daily Bridge-watcher agent. You can explore the full Amazon Quick bridge setup in GitHub, which includes instructions you can copy and paste as a prompt into the Amazon Quick desktop assistant, including the exact JSON shape it should write.

Prerequisite 2: An AI IDE to build and shape the app

Kiro is an AI-powered IDE, and the Kiro command-line interface (CLI) is its command-line counterpart. Together they mean you can clone the starter project, run it locally, and then refine it in natural language until it looks and behaves the way you want.

Download Kiro. (You can explore the Kiro Documentation too.)
Install the Kiro CLI. The command center’s AI Developer feature drives it to build things for you, scoped to a project folder. Open Design is a third-party, optional solution that works with Kiro to design and prototype products and is open source. This repository is included for use if you choose to call the UX Designer.
Clone the starter repository and run it:

git clone --recurse-submodules <your-repo-url>
cd chief-of-staff-voice-command-center

npm install

npm start

Because the whole thing is a local application, not a cloud deployment, and you own it. Open it in Kiro and ask for changes in plain English. You can rename the assistant, restyle the dashboard, add or remove an advisor, or change what a briefing says. The AI IDE is what turns a starter project into your command center. It runs on macOS and desktop operating systems (Windows and Linux), with a rich voice experience on macOS.

Why a desktop assistant is the right pattern

The reason this approach is valuable for public sector teams is that the desktop assistant can draw on many local connections you already have—for instance, Microsoft Teams, Slack, and email—and turn them into briefings the command center reads aloud. A few examples:

Cost reporting – The assistant reads your finance or cost report emails and produces a CFO-style spending briefing.
Security reporting – It summarizes security posture and findings into a CSO briefing.
Daily operations – It scans your inbox, chat, and calendar and gives you a single morning summary.

Because that work happens through the assistant and lands in the bridge folder, the command center stays small, local, and straightforward to reason about while still benefiting from rich, connected data sources.

Cost and token use disclaimer

This solution is inexpensive to run, but it does have costs, and those costs depend on how you use it. Keep the following in mind:

AI IDE (tokens) – Explore the Kiro pricing page.
Desktop assistant (monthly) – Explore the Amazon Quick pricing page.
Open Design – This is a no-cost open source third-party solution.

Get started

To build your own AI chief of staff, you can take the following next steps:

Download Amazon Quick for desktop and complete first sign-in.
Download Kiro and install the Kiro CLI.
Clone the starter repository, run npm start, and open it in Kiro to make it your own.
Create the voice-bridge-watcher agent in Amazon Quick using the setup instructions included with the project, and point it at the reporting sources you care about starting with a cost or finance report for the CFO.

Give it a name you enjoy saying, then ask it for your first briefing.

Conclusion

Administrative overhead doesn’t have to compete with mission delivery. With a local command center powered by Amazon Quick for desktop and Kiro, your team can turn routine tasks such as cost reporting, security monitoring, and inbox triage into voice-activated briefings that stay on your device.

No cloud deployment, no data leaving your machine, and no complex infrastructure to maintain. Clone the repository, set up the bridge, and give your AI chief of staff its first assignment.

From Amazon RDS Custom for Oracle to what’s next: A technical guide to Oracle migration paths on AWS

FNU Zubair — Mon, 14 Sep 2026 16:01:44 +0000

This post provides a decision framework and technical guidance to help database administrators and architects navigate the transition facing Amazon Web Services (AWS) customers who run workloads on Amazon Relational Database Service (Amazon RDS) Custom for Oracle. Following the AWS announcement that it will discontinue RDS Custom for Oracle on March 31, 2027, organizations need a clear, practical roadmap to evaluate and execute migration to the best-suited alternative—Amazon RDS for Oracle, Oracle on Amazon Elastic Compute Cloud (Amazon EC2) or Oracle Database@AWS (ODB@AWS)—based on operational, technical, and business requirements.

To get the most out of this guide, readers should be familiar with the following:

Oracle Database administration fundamentals
AWS core services, including Amazon RDS, Amazon EC2, Amazon Virtual Private Cloud (Amazon VPC), AWS Identity and Access Management (IAM), and AWS Systems Manager
Oracle database deployment models on AWS: RDS for Oracle, RDS Custom for Oracle, Amazon EC2 hosted Oracle, and multi-cloud option ODB@AWS
Basic concepts of Oracle licensing, support timelines, and certified platform requirements

Understanding the change

AWS has announced that RDS Custom for Oracle will reach end of support on March 31, 2027. After this date, customers will no longer be able to access the RDS Custom for Oracle console or resources.

Organizations running workloads on RDS Custom for Oracle should assess their environment now. The key questions to answer are:

What operating system (OS)-level customizations or dependencies exist on the RDS Custom host?
What Oracle version, features, parameters, hidden parameters, or patch levels are in use that aren’t available in standard RDS for Oracle?
What third-party agents or integrations interact with the Oracle OS or file system layer?
What are the high availability and disaster recovery (HA/DR) requirements and current Oracle Data Guard configurations?
What are the licensing arrangements: Bring Your Own License (BYOL), Oracle Unlimited License Agreement (ULA), or License Included (LI)?

These answers determine the right migration path. Complex, multi-workload environments should start a phased approach now.

Amazon RDS for Oracle enhancements

RDS for Oracle has gained capabilities that address why customers previously chose RDS Custom for Oracle. The biggest update: maximum storage increased from 64 TiB to 256 TiB, removing the main reason why many customers used RDS Custom for Oracle to hold large databases.

Recent capability improvements

The following improvements make RDS for Oracle a stronger option for workloads that previously required the RDS Custom variant:

Maximum database storage increased from 64 TiB to up to 256 TiB through additional storage volumes (up to three additional volumes per instance).
Cross-Region read replicas with additional storage volumes for disaster recovery at scale.
AWS Organizations upgrade rollout policy for controlled, staggered automatic minor version upgrades across database fleets.
Oracle Database version support expanded to 26ai. The databases that are currently supported are 19c, 21c, and 26ai Enterprise Edition.

Feature comparison: Amazon RDS for Oracle and Amazon RDS Custom for Oracle

The following table highlights some key capability differences between RDS for Oracle and RDS Custom for Oracle to help teams identify functional gaps and options before migration.

Capability	Amazon RDS for Oracle	Amazon RDS Custom for Oracle	Alternative for some Amazon RDS Custom functionalities in Amazon RDS for Oracle
OS-level access (SSH/RDP)	✗	✓ (SSH + sudo)
Scheduling cron jobs	✗	✓	Internal database jobs: DBMS_SCHEDULER External schedule jobs: AWS Lambda and Amazon EventBridge Complex workflows: AWS Step Functions
Maximum database size	256 TiB (multi-volume)	64 TiB
Automated quarterly patching	✓	Shared responsibility	AWS managed
Automatic backups	✓	Shared responsibility	AWS managed
Custom Oracle parameter groups	✓	✓
Multi-AZ automated failover	✓	✓ (shared responsibility)
Custom Oracle home patching	✗	✓
Third-party agent installation on host	✗	✓
Monitor DB using Oracle Enterprise Manager (OEM)	✗	✓	No OEM agent on RDS for Oracle. Options with limited functionalities including Agentless OEM using Amazon EC2 Proxy, OEM DB Express, or Amazon CloudWatch
License Included (LI) option	✓	✗
Bring Your Own License (BYOL)	✓	✓

Migration roadmap options

Organizations migrating from RDS Custom for Oracle have three destination options. The best option depends on the workload, OS and business requirements, and target operational model.

The following table compares the three platforms against RDS Custom for Oracle as the current state.

Capability	Amazon RDS for Oracle	Oracle on Amazon EC2	ODB@AWS	Amazon RDS Custom for Oracle (Current)
OS-level access	✗	✓	✓	✓
Max database size	256 TiB	Unlimited*	Exadata scale	64 TiB
Management overhead	Low (AWS managed)	High (self-managed)	Medium (Oracle managed)	Medium
Patching control	AWS managed	Customer controlled	Oracle managed	Customer controlled
Licensing (BYOL)	✓	✓	✓	✓
License Included (LI)	✓	✗	✗	✗
Multi-AZ failover (automated)	✓	Manual	✓	✓ (Shared)
Oracle Real Application Clusters (RAC) support	✗	✗	✓	✗
Exadata hardware	✗	✗	✓	✗
Full SYSDBA access	✗	✓	✓	✓
AWS managed automated backups	✓	✗	✗	✓
Cost model	Per instance-hour	Per instance-hour	Subscription	Per instance-hour

Path 1: Migrate to Amazon RDS for Oracle

RDS for Oracle is the recommended path for managed workloads without OS-level or advanced Oracle infrastructure dependencies. If you chose RDS Custom for Oracle mainly for storage capacity (the old 64 TiB limit), that constraint is gone: RDS for Oracle now supports up to 256 TiB.

RDS for Oracle delivers a comprehensive set of AWS managed capabilities: automated Multi-AZ failover, AWS Backup integration, Amazon CloudWatch metrics, IAM based authentication, automated patching, and version upgrades. This path trades operational flexibility for lower management overhead and higher reliability through AWS automation.

Path 2: Migrate to Oracle on Amazon EC2

Oracle on Amazon EC2 is a strong fit for workloads with OS-level dependencies that can’t be abstracted away: custom batch schedulers, third-party agents, direct file system access, SYSDBA/SYSASM operations beyond the Amazon RDS API surface, or Oracle patches not yet certified on Amazon RDS. Amazon EC2 gives the customer a fully self-managed Oracle environment with control over each layer of the stack.

The trade-off is operational complexity: OS patching, Oracle home maintenance, Oracle Recovery Manager (RMAN) backup management, Oracle Data Guard configuration, and instance lifecycle management become customer responsibilities. Teams on this path should invest in Systems Manager for automation, AWS Backup for Oracle RMAN integration, and CloudWatch custom metrics for observability.

Path 3: Oracle Database@AWS

ODB@AWS is jointly operated by Oracle and AWS, delivering Exadata hardware co-located in AWS data centers with direct, low-latency connectivity to AWS services. It targets organizations that need Exadata-class performance, Oracle RAC, full Oracle infrastructure feature access (Advanced Queuing, Oracle Streams, Oracle Text, Spatial), and continuity of existing Oracle Support agreements and ULAs.

This path suits large-scale Oracle E-Business Suite, PeopleSoft, and Oracle Applications customers who want to consolidate on AWS while keeping RAC and the full Oracle software stack and support model. It offers unified billing through AWS Marketplace, flexible and Oracle Subscription licensing, and network integration with AWS services through the ODB network.

Use cases and migration approaches

The following three use cases represent the most common RDS Custom for Oracle deployment patterns. Each maps to a recommended migration path based on the workload’s technical requirements.

Use case 1: Oracle E-Business Suite to ODB@AWS

In this scenario, a customer runs Oracle E-Business Suite (EBS) 12.2 with Advanced Queuing, Oracle Text, custom PL/SQL jobs, and Oracle Workflow on Exadata, using RAC, Smart Scan, Smart Flash Cache, and dedicated infrastructure to meet performance and security requirements. An active Oracle ULA covers the deployment. A second phase upgrades the database to Oracle 26ai, certified with EBS 12.2 on ODB@AWS.

ODB@AWS is a good fit for the following reasons:

Oracle EBS 12.2 is certified on ODB@AWS ExaDB-D with Oracle Database 19c—the application tier on Amazon EC2—with full support for Oracle-specific features, including DBMS_SCHEDULER, Advanced Queuing, Oracle Text, and Oracle Spatial.
Exadata infrastructure co-located in AWS data centers delivers Smart Scan, Smart Flash Cache, and low-latency connectivity to AWS services. This meets transaction-heavy Oracle EBS financial module performance requirements without cross-data center latency.
Preserves existing licensing and support agreements; SYSDBA access enables EBS patching on Oracle’s certification schedule, not the AWS managed patch timeline.

The migration approach consists of the following key phases:

Assessment – Capture Automatic Workload Repository (AWR) baselines across Oracle EBS peak windows to right-size the ODB@AWS Exadata VM cluster. Run Oracle EBS Technology Codelevel Checker (ETCC) on the source to find and resolve mandatory patches before migration. Document custom database parameters, Oracle Home patches, and OS agents. Design ODB network CIDR ranges upfront. Initiate Oracle account and Oracle Cloud Infrastructure (OCI) tenancy setup.
Non-production migration – Provision and peer ODB@AWS to the existing Amazon VPC. Run Oracle EBS pre-clone scripts on source DB and application tiers, then RMAN-duplicate to the ODB@AWS target. Execute post-clone steps, rerun AutoConfig on the Amazon EC2 application tier, start concurrent managers, and re-validate ETCC compliance. Benchmark top concurrent programs and complete full UAT testing before the production migration phase.
Production migration – Use Oracle Data Guard to continuously synchronize the database from the source RDS Custom (primary) to ODB@AWS (standby). When the apply lag is stable, switch over from primary to standby on ODB@AWS. This yields near-zero downtime (minutes). Rerun AutoConfig on Amazon EC2 application tier nodes, restart Oracle EBS services, and confirm end-to-end validation.

For organizations needing parallel-run validation or phased cutover, Oracle GoldenGate provides bidirectional replication between source and target.

Use case 2: PeopleSoft HCM/Financials to Oracle on Amazon EC2

In this scenario, a customer runs PeopleSoft Human Capital Management and Financials on RDS Custom for Oracle. PeopleSoft HCM requires OS-level cron scheduling, third-party job schedulers, and specific Oracle patch sets for PeopleSoft’s certified platform matrix that RDS for Oracle does not yet support. For PeopleSoft environments that don’t need Oracle RAC or Exadata performance features, Oracle on Amazon EC2 is a good option—it’s flexible and lower cost than ODB@AWS. The database, application, and Process Scheduler tiers all run on Amazon EC2, preserving full OS access, RMAN control, and PeopleTools operational continuity.

Oracle on Amazon EC2 is a good fit for the following reasons:

PeopleSoft’s Process Scheduler and SQR reporting engine require OS-level integration, file system access, and the ability to spawn processes.
Batch processing uses shell scripts that must run on the OS alongside the Oracle database.
Oracle on Amazon EC2 gives full control over Oracle Home, patch level, and database parameters. PeopleSoft’s certified platforms matrix requires specific Oracle Database patches. Third-party tools and agents install directly alongside the Oracle database on the EC2 instance.

The migration approach consists of the following key phases:

Assessment – Capture AWR baselines to right-size the target EC2 instance and Amazon Elastic Block Store (Amazon EBS) storage. Confirm Oracle PeopleSoft PeopleTools compatibility with Oracle Database 19c. Document custom database parameters, Oracle Home patches, OS agents, and Process Scheduler configuration files from the RDS Custom host. Validate Integration Broker node configuration, external system endpoints, and RMAN backup/recovery procedures to Amazon Simple Storage Service (Amazon S3) on the source environment.
Non-production validation – Provision a target EC2 DB instance running Oracle 19c, matched to the source Oracle Home and patch level. Perform RMAN backup-based duplication from RDS Custom to Amazon EC2 using Amazon S3. Run post-clone steps on all application tier nodes to point to the new EC2 DB instance, reconfigure Process Scheduler domains, and re-register Integration Broker nodes. Complete end-to-end UAT testing and benchmark against the AWR baseline.
Production migration – Establish Oracle Data Guard between RDS Custom (primary) and Amazon EC2 (standby) for continuous redo log synchronization ahead of cutover. When the primary and standby are synchronized, an Oracle Data Guard switchover promotes Amazon EC2 to primary in near-zero downtime (minutes). Update all PeopleSoft application tier nodes with new DB instance connection strings, restart services, and confirm end-to-end validation before the maintenance window closes.

Use case 3: Oracle DB with Oracle APEX to Amazon RDS for Oracle

In this scenario, a customer running Oracle APEX on Oracle Database 19c on RDS Custom re-platforms to RDS for Oracle. For APEX workloads with no dependency on OS-level access, SYSDBA, RAC, or custom Oracle Home patches, RDS for Oracle is the ideal migration target—it supports APEX through managed Option Groups, removes operational overhead, and is an AWS managed Oracle service with an active support roadmap. This migration moves the customer to a fully managed service with few application changes.

RDS for Oracle is a good fit for the following reasons:

AWS managed automated backups, patching, Multi-AZ HA, and Amazon RDS Performance Insights avoid DBA intervention for routine lifecycle tasks.
Oracle APEX is supported through AWS Option Groups (APEX and APEX-DEV). It is deployable as a runtime or full development environment with the listener hosted on a separate EC2 instance.
Custom initialization parameters are managed through RDS parameter groups—the team reviews hidden parameters during assessment and any gaps flagged before migration.

The migration approach consists of the following key phases:

Assessment – Document the source RDS Custom APEX environment: APEX version, workspace list, application export inventory, ORDS version and configuration, custom database parameters, OS-level backup scripts, and any custom APEX_version account configurations. Take APEX application exports for all workspaces and applications using the APEX Export utility as a pre-migration safety net. Design and validate AWS Backup.
Non-production migration – Provision a new RDS for Oracle 19c instance with APEX and APEX-DEV Option Groups: AWS installs APEX automatically, removing the manual SYSDBA-driven process used on RDS Custom. Migrate APEX application schemas and workspace data using Oracle Data Pump export/import, reconfigure ORDS on the EC2 instance to point to the new RDS endpoint, and run rdsadmin.rdsadmin_run_apex_rest_config to configure RESTful services. Validate all APEX applications end-to-end and confirm AWS Backup, AWS Lambda, and Amazon EventBridge schedules with a successful backup and test restore.
Production migration – During the maintenance window, set APEX applications to unavailable, take a final Oracle Data Pump export from RDS Custom, import it into the production RDS for Oracle instance, and reconfigure ORDS to the new endpoint. Enable Multi-AZ for automated HA, set APEX applications back to available, and confirm end-to-end validation across all workspaces before the window closes.

Migration approach and tools

The primary decision in choosing your migration approach is between physical and logical migration. Each has distinct trade-offs in downtime, complexity, and suitability by target platform:

Oracle Data Guard – Maintains a synchronized physical standby on the target Amazon EC2 or ODB@AWS platform during migration. When ready, a planned switchover completes in minutes with near-zero data loss and no extended downtime.
Oracle GoldenGate – Continuously captures and applies redo log changes between source and target, letting both systems run at the same time for heterogeneous migrations, cross-version upgrades, or extended parallel validation.
Oracle Data Pump (expdp/impdp) – Exports full or partial schemas to a dump file set—stored on Amazon S3 or transferred directly to the target. This option is suitable for smaller databases or non-production environments where a maintenance window is acceptable.
AWS DMS – AWS Database Migration Service (AWS DMS) supports Oracle as both source and target. Its change data capture (CDC) engine replicates changes continuously with low latency. It’s suitable for migrations to RDS for Oracle that need schema transformation or an extended replication window.

The following table compares physical and logical migration options.

Dimension	Physical migration	Logical migration
Methods	RMAN, Oracle Data Guard	Oracle Data Pump, AWS DMS, Oracle GoldenGate
Data fidelity	Block-level exact copy	Object-level (schema + rows)
Downtime	RMAN: Depends on the DB size Oracle Data Guard Switchover: Minutes	Oracle Data Pump: Hours to days AWS DMS: Varies Oracle GoldenGate: Minutes (CDC)
Schema changes allowed	✗	✓
Cross-version migration	Limited	✓
Cross-platform migration	With XTTS	✓
Best for	Same-version, Amazon EC2 and ODB@AWS targets	RDS for Oracle target, schema evolution scenarios
Validation complexity	Lower (bit-exact)	Higher (row counts, checksums, application testing)

Conclusion

The March 31, 2027, end of support for RDS Custom for Oracle gives Oracle database teams on AWS a defined window to right-size their deployment model—reducing operational overhead, optimizing costs, and improving availability with modern AWS tooling.

The guiding principle is workload-driven platform selection: workloads without OS-level dependencies belong on RDS for Oracle, which now supports up to 256 TiB with extensive AWS automation integration; workloads with genuine OS requirements belong on Amazon EC2; and Oracle Applications or Exadata-dependent workloads belong on ODB@AWS.

To begin planning your migration, review the A mazon RDS for Oracle User Guide, explore the Oracle Database@AWS User Guide, and connect with your AWS account team to discuss your specific requirements.

How Common Crawl and AWS Open Data built the foundation for the AI revolution

Rich Skrenta — Fri, 11 Sep 2026 18:37:33 +0000

When Gil Elbaz founded Common Crawl in 2007, his goal was to make web-scale crawl data available to researchers and organizations that lacked the resources to operate their own crawling infrastructure. Nearly two decades later, that mission has had impacts far beyond what anyone anticipated.

The Amazon Web Services (AWS) Open Data Sponsorship Program has hosted the Common Crawl open repository of web data at no cost since January 2012. It has become one of the most important sources of training data for the large language models (LLMs) reshaping industries.

A 2024 Mozilla Foundation study found that 64 percent of 47 major LLMs published between 2019–2023 used filtered versions of Common Crawl data for training. The dataset has been cited in over 13,000 research papers.

This is the story of a 14-year collaboration between a small nonprofit and AWS, and how open data infrastructure became the foundation of the AI era.

From 5 billion to 300 billion pages at petabyte scale

Common Crawl began collecting data in 2008 using a custom Hadoop-based crawler with a PageRank implementation. In January 2012, the organization joined the AWS Public Data Sets program—now the AWS Open Data Sponsorship Program—making its corpus of 5 billion web pages available at no cost on Amazon Simple Storage Service (Amazon S3). This meant Common Crawl could focus its limited nonprofit resources on crawling and data quality.

As Common Crawl noted at the time, “Demonstrating their commitment to an open web, AWS hosts public data sets at no charge for the community. Placing our data in the public data sets program not only benefits the larger community, but it also saves us money.”

In 2013, Common Crawl replaced its custom crawler with CCBot, a system based on the Apache Software Foundation’s Nutch web crawler, and adopted the Web ARChive (WARC) format (ISO 28500) as its standard distribution format. In March 2022, Common Crawl celebrated the 10-year anniversary of being a part of AWS Open Data Sponsorship Program and introduced Amazon CloudFront as a new distribution channel alongside Amazon S3, giving users faster access to the data.

Today, the Common Crawl archive contains more than 300 billion web pages, with monthly crawls capturing between 2.3–2.7 billion pages as of this writing.

The LLM inflection point

The release of the OpenAI GPT-3 model in 2020 drew global attention to the role Common Crawl plays in AI development. The GPT-3 paper reported that approximately 82 percent of its raw pre-training tokens were derived from filtered Common Crawl data, the beginning of an industry-wide pattern.

Common Crawl data has been used to train frontier models including GPT-3 (OpenAI, 2020), the BigScience Large Open-science Open-access Multilingual Language Model (BLOOM, 2022), the Meta Llama series, Google Gemini, and Falcon LLM (Technology Innovation Institute, 2023). More recently, Hugging Face FineWeb datasets, NVIDIA Nemotron-CC (6.3 trillion tokens), and Google MADLAD-400 (419 languages) have applied increasingly sophisticated filtering to Common Crawl snapshots.

Scaling infrastructure to meet AI demand

The explosion of AI training workloads placed extraordinary demands on the underlying infrastructure of Common Crawl. By late 2023, downloads had doubled every 6 months for several years, and aggressive downloaders began causing performance disruptions. AWS worked directly with Common Crawl to deploy rate limiting in November 2023, restoring reliable access for the broader community.

Today, the infrastructure spans Amazon S3 as the canonical distribution point, Amazon CloudFront for faster global access, Amazon Athena for querying the index without downloading raw data, and Amazon EMR, AWS Lambda, and Amazon SageMaker for large-scale processing and model fine-tuning. In April 2026, Common Crawl began experimentally distributing data through Hugging Face, although Amazon S3 remains the primary source.

This infrastructure means that a graduate student at a university in Nairobi, a two-person startup in São Paulo, and a research lab in Bangalore can access the same foundational data powering frontier AI systems at no cost.

What this means for AWS customers

The value Common Crawl delivers to the AWS environment extends well beyond the dataset itself.

For builders

If you’re training or fine-tuning language models, you can access pre-training data at scale without building crawling infrastructure, using the derived datasets such as Colossal Clean Crawled Corpus (C4), FineWeb, RefinedWeb, OSCAR, and Nemotron-CC. The Registry of Open Data on AWS lists Common Crawl with tutorials and usage examples that can help you query and process the data without downloading petabyte-scale archives.

For researchers

Over 13,000 published papers have used Common Crawl data across computational linguistics, information retrieval, machine translation, web science, digital preservation, cybersecurity, longitudinal web analytics, phishing detection, health misinformation retrieval, and studies of geolinguistic representation in text data and social science.

You can build on this foundation the same way Stanford’s 2014 Global Vectors for Word Representation (GloVe) word embedding model and Facebook AI Research’s fastText did: both trained word vectors on Common Crawl data covering up to 157 languages.

For organizations

If you’re building search, recommendation, translation, or knowledge extraction systems, you can prototype and validate approaches using Common Crawl before building your own data pipelines.

The Web Graphs give you structural web intelligence, 279.4 million host-level nodes and 13.4 billion edges, plus 122.3 million domain-level nodes and 6.1 billion edges as of the January 2026 release, which are unavailable from other open sources.

For the multilingual AI community

If you’re working to address the overrepresentation of English in AI training data, the Common Crawl Web Languages Project, which was launched December 2024, and the CommonLID (Language Identification) benchmark, released early 2026 and covering 109 languages with MLCommons, EleutherAI, and Johns Hopkins University, provide critical resources.

The CommonLID benchmark was created through community annotation, with native speakers annotating over 350,000 lines of web text. Additionally, the High-Performance Language Technologies (HPLT) project uses Common Crawl data to build a 30-trillion-token multilingual dataset spanning 198 languages, further expanding multilingual AI capabilities beyond English.

Looking ahead

As AI models become more capable and more multilingual, demand for high-quality open training data continues to grow. The AWS Open Data Sponsorship Program helps this foundational resource remain available to everyone, from individual researchers to the world’s largest AI laboratories.

As Rich Skrenta, executive director of the Common Crawl Foundation, puts it: “Common Crawl would not exist without Amazon’s support for open data. We are grateful for our partnership and look forward to serving the AI ecosystem together.” Open data isn’t a side project. It’s infrastructure. And infrastructure, when done right, compounds.

Accessing Common Crawl on AWS

You can access Common Crawl data from the us-east-1 AWS Region at no cost in three formats: WARC (raw crawl data), WAT (metadata and link graphs), and WET (extracted plaintext). Monthly releases include index files in columnar format for querying with Amazon Athena.

For detailed format documentation and access instructions, visit the Common Crawl page on the Registry of Open Data on AWS, or visit the Common Crawl getting started page for different access methods.

Building supply chain multi-agent workloads in AWS GovCloud (US)

Francisco Zabala — Thu, 10 Sep 2026 18:25:58 +0000

If you support a public sector supply chain, a shortage is a mission problem before it’s a cost problem. Your inventory position sits in a system of record. The signals that predict a shortfall don’t: a supplier advisory here, a port closure there, lead time that keeps slipping. Analysts reconcile all of it by hand, one item at a time. They usually find out too late.

Agents can carry out that reconciliation and hand back a ranked short list with the reasoning attached, and they never place an order without your approval.

This post shows how to build that on Amazon Web Services (AWS) using Amazon Bedrock, deployed in AWS GovCloud (US). You’ll deploy a working multi-agent workload, see how a supervisor coordinates specialized agents through the Converse API in Amazon Bedrock, and learn which AWS GovCloud (US) details break patterns copied from commercial Regions.

What you build

By following the steps in this post, you’ll build a read-only console that ranks items by readiness risk, backed by three agents on Amazon Bedrock.

This complements a system of record rather than replacing it. Enterprise resource planning (ERP) and inventory suites already compute reorder points well. What they don’t do is pull in outside signals and tell you which items deserve attention first. That is the gap the agents fill.

The workflow carries inventory and disruption data through ingestion, processing, and analysis, and stops for an analyst before anything is ordered. The following steps describe each stage in turn.

Inventory data and external disruption signals land in an Amazon Simple Storage Service (Amazon S3) raw zone.
Amazon Simple Queue Service (Amazon SQS) decouples sources from processing. Extract, transform, and load (ETL) jobs on AWS Lambda or AWS Batch normalize records into a curated dataset.
Amazon Athena exposes that dataset as the read-only query surface for the agents.
A supervisor orchestrates the workflow. It calls Amazon Bedrock through an AWS GovCloud (US) inference profile, bounded by Amazon Bedrock Guardrails.
Three specialized agents run under it. The ETL agent fetches and validates the demand series. The analytics agent forecasts demand and scores risk. The visualization agent builds the ranked queue, drafts a brief, and proposes an action. Amazon DynamoDB holds agent state.
An Application Load Balancer fronts the console on AWS Fargate. Amazon CloudFront is not available in AWS GovCloud (US), so the load balancer is the delivery layer.
Amazon Cognito authenticates the user before the console is reachable. Authentication is enforced at the application layer, so an unauthenticated request never reaches the console.

When an action is warranted, the workflow pauses for an analyst to approve or reject it. No agent acts on its own.

This architecture is shown in the following diagram.

Figure 1: Multi-agent supply chain risk workflow in AWS GovCloud (US)

An analyst works from the ranked queue rather than from raw inventory records. The following screenshot shows that queue, with the highest-risk items at the top.

Figure 2: The console ranks items by readiness risk and links each row to its location

Prerequisites

To implement the solution, you need to have the following prerequisites:

An AWS GovCloud (US) account with permissions for the services described in the architecture
The AWS Cloud Development Kit (AWS CDK) v2 and the AWS Command Line Interface (AWS CLI), both configured for us-gov-west-1
A container runtime (Docker or Finch), Python 3.11 or later, and Node.js 20 or later
Access to an Amazon Bedrock foundation model (FM), with its inference profile available to your account

Amazon Bedrock charges per token. The deployed console runs a load balancer, one AWS Fargate task, and Amazon Cognito. Remove the resources when you finish (see Cleanup).

Deploy it

Run the analytics locally first. You don’t need an AWS account for this. The example backtests a moving-average forecast against a seasonal-naive baseline and derives a decision per item:

== SKU-1001 ==
  backtest MAPE:      model(MA3)= 8.94%  baseline(seasonal)=14.46%  -> winner: model
  readiness risk:     HIGH
  recommended action: Reorder 500 and qualify an alternate supplier

Then deploy the console and agents:

git clone https://github.com/aws-samples/multi-agent-supply-chain-risk-for-govcloud && cd multi-agent-supply-chain-risk-for-govcloud
python -m venv .venv && .venv/bin/pip install -e ".[dev,bedrock]"
.venv/bin/python examples/worked_forecast.py     # local run

cd infra/cdk && npm ci
npx cdk deploy -c qualifier=<your-bootstrap-qualifier>

Create a user in the Amazon Cognito user pool the stack provisions, then sign in. The following screenshot shows the sign-in page.

Figure 3: Users authenticate through Amazon Cognito before reaching the console

How the agents work

Each agent owns a small tool set. Every tool carries an autonomy classification, so the approval boundary lives in code rather than in prompt text:

class ToolAccess(str, Enum):
    AUTONOMOUS = "autonomous"          # read/compute, no side effects
    HUMAN_APPROVAL = "human_approval"  # consequential; requires sign-off

VISUALIZATION_AGENT = Agent(
    name="visualization_agent",
    tools=(
        Tool("build_view", "Assemble map markers and queue rows.", ToolAccess.AUTONOMOUS),
        Tool("draft_brief", "Draft a grounded, plain-language brief.", ToolAccess.AUTONOMOUS),
        Tool("place_reorder", "Place an order. REQUIRES human approval.",
             ToolAccess.HUMAN_APPROVAL),
    ),
)

The supervisor hands each agent’s tools to a foundation model through the Converse API. The model chooses which tool to call and in what order, reacting to each result. Nothing here follows a fixed script.

One AWS GovCloud (US) difference will stop you immediately. Converse requires an inference profile ID. Amazon Bedrock rejects the on-demand model ID.

DEFAULT_REGION = "us-gov-west-1"
DEFAULT_MODEL_ID = "us-gov.anthropic.claude-sonnet-4-5-20250929-v1:0"

response = client.converse(
    modelId=DEFAULT_MODEL_ID,
    system=[{"text": SYSTEM_PROMPT}],
    messages=messages,
    toolConfig=build_tool_config(),
)

When the model proposes a consequential action, the loop stops and returns it for approval instead of executing it:

for tool_use in tool_uses:
    if requires_human_approval(tool_use["name"]):
        return AdapterResult(
            stopped_for_approval=True,
            pending_action={"tool": tool_use["name"], "input": tool_use.get("input", {})},
        )
    tool_results.append(execute_tool(tool_use))

The ranking itself is a weighted blend of three inputs: stockout pressure from the forecast and reorder point, the external disruption signal, and mission criticality, which the sample data carries as a flag on each item in the system of record. Every item shows its score, its primary driver, and a plain-language rationale, as shown in the following screenshot. A reviewer can tell why an item sits where it does.

Figure 4: Selecting a location shows its risk score, inventory position, and primary driver

Customize it for your needs

Treat the deployed stack as a starting point. Five changes cover most adaptations, and each one is restricted to a single layer:

Point it at your data – Swap the sample connectors for your inventory source and whichever disruption feeds you trust. The agents read a curated dataset through Amazon Athena, so all they need is a table rather than a schema rewrite.
Tune the risk model – The weighting exists in a single function. Adjust it or replace the forecast with statsmodels, Prophet, or an Amazon SageMaker AI endpoint. Whatever you choose should exceed a documented baseline for mean absolute percentage error (MAPE) before you rely on it.
Scope permissions tightly – The repository ships one AWS Identity and Access Management (IAM) role per layer, each validated with IAM Access Analyzer. Two details require attention. The Converse API authorizes against bedrock:InvokeModel because there is no bedrock:Converse action. And an AWS GovCloud (US) system-defined inference profile can route to either us-gov-west-1 or us-gov-east-1, so the policy has to list the model Amazon Resource Name (ARN) in both Regions. Omit one and the service denies the call. Agent data access stays read-only over the curated prefix.
Harden the transport – The reference console serves over HTTP on an internal load balancer for demonstration. Before real users touch it, terminate TLS at the load balancer with a certificate from AWS Certificate Manager, redirect port 80 to 443, mark session cookies Secure, and add Strict-Transport-Security.
Add an agent – Define it with its tools and register it with the supervisor. A notification agent is a natural next step. Another option is a context-retrieval agent over Amazon Bedrock Knowledge Bases. The supervisor enforces the approval boundary centrally, so anything you add inherits it.

The structure travels. Ranking grant applications, triaging compliance findings, prioritizing maintenance: the pattern fits many workflows where an agent gathers cross-source data and recommends an action for a person to authorize.

Cleanup

Destroy the stack to stop charges, then remove the image repository if you no longer need it:

cd infra/cdk && npx cdk destroy -c qualifier=<your-bootstrap-qualifier>
aws ecr delete-repository --repository-name supply-chain-console \
  --force --region us-gov-west-1

Confirm in the AWS Management Console that the AWS CloudFormation stack and the Amazon Elastic Container Registry (Amazon ECR) repository are gone.

Conclusion

You can deploy agentic AI workloads in AWS GovCloud (US) today, provided you account for its specifics: invoke Amazon Bedrock through an inference profile, scope model and data permissions to what each agent needs, deliver the application behind a load balancer, and keep a person in the loop for consequential actions. Start with the local run, deploy the stack, then point it at your own data.

Additional resources

Sample code for this post
Services in AWS GovCloud (US) Regions
AWS GovCloud (US) User Guide
Converse API reference in Amazon Bedrock
Amazon Bedrock Guardrails

Please note that this post is intended for informational purposes. The approach described might not be suitable for every organization or compliance program. Evaluate it against your organization’s compliance needs and any applicable regulatory obligations.

How Forseti and AWS connect domestic violence survivors to services in real time

Dr. Dawn Heisey-Grove — Wed, 09 Sep 2026 16:04:34 +0000

In the time it takes to read this sentence, a domestic violence survivor might have decided to seek help, and the window for connecting them to safety is already closing. Research shows 88% of help-seeking occurs in the moments between the acute crisis and the return to an abusive cycle. Services exist, but getting survivors connected to them is challenging. But now, technology exists that can make that connection fast enough to matter.

Across the United States, more than 64 million adults have experienced intimate partner violence in their lifetimes, but 82% of abused women never contact an agency or counselor and 74% never seek medical care for their abuse. Of those who do come forward, the majority never connect with the services that could change their trajectory. When a law enforcement officer responds to a domestic violence call, the first few minutes represent a singular opportunity: the survivor is present, the danger clear, and the system paying attention. What happens next depends entirely on whether the response infrastructure can match that moment.

Forseti, a public safety technology company, built the Honest Assessment Response Tool (HART) to meet survivors in that moment. Running on Amazon Web Services (AWS), HART digitizes on-scene domestic violence risk screening, connects survivors to services in real time, and gives state agencies population-level visibility into intimate partner violence patterns.

Why timing matters: The research case for real-time connection

The evidence on timing is unambiguous. Foundational research on the violence cycle identifies a narrow “Open Window Phase” between the acute battering incident and the subsequent calm period. During this window, a survivor realizes they can’t stop the violence, is most likely to reach out for help, and is most receptive to intervention.

When that window closes, the drop-off is severe because survivors frequently experience post-traumatic stress that inhibits long-term planning, combined with manipulation and coercion from the abuser that compromises their ability to follow up independently. Even among highly motivated survivors who call the National Domestic Violence Hotline and express clear intention to act, only 24.6% who intended to go to a shelter actually did within 2 weeks. Only 31.9% contacted law enforcement as planned.

An immediate, active connection improves action fivefold: 72.7% of survivors who received an immediate referral connected with behavioral health resources, compared to only 15.7% for those who received a passive referral. This is the gap Forseti closes. Rather than handing a survivor a phone number and hoping they call, HART creates a real-time digital connection between the officer on scene, the completed risk assessment, and the local service provider, while the survivor is still present and receptive.

The challenge: Paper processes in a time-critical system

A 2025 audit examined a sample of domestic violence incident reports from the Dallas Police Department and found that among intimate partner cases, 28% were missing a completed Lethality Assessment Program (LAP) form. Paper forms moved slowly through interdepartmental mail. Even when officers completed the LAP at the scene, 35% of sampled forms never reached the database caseworkers use to track high-risk victims. The share of high-risk victims who spoke with a shelter or counselor at the scene had fallen from over 40% when the program launched in 2012 to approximately 20% during the audit period.

Dallas is not an outlier. Research shows that standard care for domestic violence includes identification, but rarely includes providing support, facilitating access to support, or following up. When it does, it typically consists of printed educational material or a phone number to a community-based advocacy agency, materials that previous research suggests survivors feel a need to hide from the abuser.

The solution: Digital connection changes outcomes

HART replaces the paper workflow entirely. Officers complete the same Domestic Violence Supplemental Form and Lethality Assessment on a device at the scene. The record is structured, validated, and shareable the moment it’s submitted. Behind HART sits County Connect, Forseti’s referral infrastructure that routes each completed assessment in real time to the district attorney, local domestic violence service providers, and other agencies with a need to know.

No paper to scan. No courier to wait for. No caseworker retyping data from a handwritten form. When officers identify a survivor as being in high danger, the local domestic violence service provider receives a referral while the officer is still on scene.

This approach mirrors the evidence-based model validated by the Lethality Assessment Program-Maryland Model, which combines standardized screening with immediate service connection. And these digital connections work, as observed with a digital warm handoff tool, the Domestic Violence Report and Referral (DVRR) system. (A warm handoff is when care is transferred between caregivers with the patient present.) Among 1,366 DV-related emergency department visits between 2014 and 2018, DVRR-associated visits increased patients’ odds of reaching advocacy services for the populations most underserved by legacy systems:

2.6 times for Latinx female survivors
4.66 times for Black survivors
12.8 times for male survivors

HART builds on this model by adding digital infrastructure that eliminates the manual steps where connections are lost.

Addressing the geographic lottery: Rural communities need real-time infrastructure most

Women in small rural areas experience domestic violence at rates of 22.5% compared to 15.5% for urban women. Women in small rural areas also report more severe events: more than 60% report four or more events of physical violence compared to 40% of urban women. Yet services in rural areas have long been limited due to geographic isolation, lack of transportation, and limited access to legal services, housing, and health services.

HART’s multistate architecture addresses this directly. Forseti’s single cloud platform provides standardized data collection across 14 states, providing an officer in a rural North Carolina county with the same assessment tools, the same real-time referral pathways, and the same data quality as a detective in a metropolitan police department. The platform eliminates the geographic lottery of response quality that currently defines domestic violence intervention in America.

Built on AWS for security and scale

HART and County Connect run on AWS GovCloud (US). The platform is fully compliant with the FBI’s Criminal Justice Information Services (CJIS) Security Policy, with a formal assessment and authorization on record, and holds SOC 2 Type II compliance. This is the security posture that law enforcement, state agencies, and domestic violence service providers require before survivor and case data touches a cloud platform.

The platform is powered by Amazon OpenSearch Service and Amazon CloudWatch. OpenSearch Service powers search and analytics across incident records so prosecutors and state researchers can query structured domestic violence data instead of paging through PDFs. CloudWatch provides around-the-clock monitoring for a system that must be available the moment an officer is standing in a survivor’s home.

As Forseti has grown from a single-agency pilot to a multistate platform, AWS infrastructure has enabled a small team to support more than 160 agencies without rebuilding architecture for each new state deployment.

Impact by the numbers

HART is now in use across more than 160 law enforcement and domestic violence service provider agencies in 14 states, with more than 10,000 survivors assessed to date. Forseti is also collaborating with leading domestic violence researchers and institutions across the country to analyze assessment data and improve how agencies nationwide respond to domestic violence calls for service.

“All agencies need to be on the same team to assist survivors, and that’s exactly what we are doing here at Forseti,” says Warren Lautz, chief operating officer, Forseti. “It is unacceptable to let archaic processes hinder communities’ ability to save lives.”

Looking ahead

For criminal justice and social service agencies working to close the gap between a 911 call and a connected support system, Forseti and HART demonstrate what becomes possible when on-scene data collection and statewide infrastructure run on the same secure cloud platform. The research is clear: real-time connection during the critical window of opportunity increases the share of survivors who reach advocacy services, and agencies implementing the Lethality Assessment Program have seen a significant reduction in intimate partner homicide. As new states and metropolitan agencies come online, the model offers a path from fragmented paper processes to coordinated, real-time response at scale.

Learn more about AWS social impact.

AI-powered customs classification, duty calculation, and pre-departure collection now available to postal operators across 192 nations

Mike Lentine — Tue, 08 Sep 2026 15:18:35 +0000

For international e-commerce customers whose packages are shipped through one of 192 postal networks, the cost of a purchase often isn’t final at checkout. Duties and taxes are calculated after departure, assessed at the border, and charged upon delivery. This creates unexpected costs, refused deliveries, and eroded trust. Postal operators want to solve this, but offering full landed cost transparency requires customs classification expertise across thousands of tariff codes and dozens of destination countries – expertise that most Posts aren’t equipped to build in-house. Today, that changes for all 192 UPU member nations.

Amazon PreDepart has successfully met the technical requirements of the Universal Postal Union (UPU) TechCert Programme for information technology integration and interoperability with UPU technology. This certification makes Amazon PreDepart available as a solution for providing Delivered Duty Paid (DDP) customer pricing to postal operators across the UPU’s 192-member nation network, accessible through the platforms they already use. This milestone builds on over six years of developing AI-powered customs classification and duty collection capabilities and follows US Customs and Border Protection’s selection of Amazon PreDepart under the Commercial Solutions Opening Pilot earlier this year.

What is the UPU Delivered Duty Paid Solution?

The UPU DDP solution enables postal operators to collect duties and taxes at origin (before shipment departure) improving customs clearance efficiency and providing full landed cost transparency to customers. For consumers purchasing goods online, DDP means that all relevant costs (shipping, duties, and taxes) are known at the time of purchase, reducing risk of unexpected charges at delivery and reducing risk of delays at the border by transmitting the product and shipment details pre-departure through Amazon PreDepart Service.

The solution is available through the UPU’s Customs Declaration System (CDS) and APIs, and supports integration with certified third-party providers. Amazon PreDepart is now one of seven certified providers, validated by the UPU TechCert Program to operate seamlessly within the UPU’s global postal technology ecosystem.

What this means for operators

Amazon PreDepart’s UPU TechCert certification gives postal operators and express shippers a turnkey path to offering DDP services without building the underlying complexity themselves.

For postal operators and express shippers, the certification means immediate access to AI-powered customs classification and duty collection capabilities through the UPU infrastructure they already use. CDS users can activate Amazon PreDepart as their DDP service enabler through a configuration parameter. Non-CDS Posts connect via the UPU PTC API Gateway. Express shipper platforms integrate directly through PreDepart APIs. All paths deliver automated HTS/HS classification, duty calculation, and pre-departure customs filing drafting at scale, no new systems or customs expertise required.

For customers, it means full cost transparency at the point of sale so long as complete product information is provided. Amazon PreDepart calculates and collects duties and taxes before shipment, so customers know their total landed cost for such products upfront. No surprises at delivery, no refused packages, no uncertainty about what they owe on those products.

How it works: the technology behind PreDepart

Amazon PreDepart combines Amazon Customs and Trade’s (ACT) deep trade and customs expertise with AWS generative AI and global cloud infrastructure. The solution delivers AI-powered capabilities across four key dimensions:

Automated HTS/HS classification. Generative AI analyzes product descriptions, materials, and specifications to recommend the correct tariff classification code from thousands of possible classifications within seconds, removing the guesswork and inconsistency of manual classification.
Complete duty breakdown. The solution compiles all relevant tariff classification codes and import duties into a single, unified view. Postal operators and their customers can quickly identify applicable tariff classification codes and understand import costs, enabling faster decision-making and greater confidence in customs compliance.
PreDepart Elements. Ready-to-use web tools integrate directly into a postal operator’s website or shipping platform. The PreDepart Application Line Item Element embeds into the item identification step for interactive customs data collection, while the PreDepart Application Element offers a simpler single-component solution for managing multiple items. Both can appear as drawers, modals, or within existing workflows to match a platform’s design.
Integrated duty calculation and collection. Once classification is complete, the system automatically calculates and collects duties within the carrier’s existing shipping flow — no separate systems, no manual handoffs. Amazon PreDepart then drafts customs filings before goods depart, supporting rapid clearance upon arrival.

Navigating UPU certification

Achieving UPU TechCert certification required Amazon to demonstrate interoperability across the UPU’s global postal technology ecosystem. The certification scope covers three key areas of integration:

DDP functionalities: CDS software integration. Amazon PreDepart integrates fully with the UPU CDS, enabling postal operators to activate DDP services through a simple configuration parameter — no custom development required.
POST*Net integration. The system transmits shipment data securely through the UPU’s global postal network, sending only the information required for customs filing: item identification, declared value, country of origin, and transport information.
Customs broker services for US-bound shipments. ACT is a licensed US customs broker able to file customs declarations with US Customs and Border Protection and handle the financial settlement of applicable duties and taxes on US imports.

The certification supports multi-provider configurations (from CDS 2025 SP1 onwards), so operators can add Amazon PreDepart to their existing setup or run it as their sole provider, selecting the best fit for their routes and volumes.

What our leaders are saying

“Amazon PreDepart’s UPU TechCert certification represents our commitment to making international trade simpler and more transparent for postal operators and their customers worldwide,” said David Cardadeiro, vice president of Amazon Customs and Trade. “By integrating directly with the UPU’s global postal infrastructure, we can now bring our AI-powered customs solution to Posts across 192 nations through the platforms they already use.”

Get involved

In this post, we announced Amazon PreDepart’s UPU TechCert certification and how it enables postal operators across 192 nations to offer Delivered Duty Paid services through the platforms they already use, no customs expertise or custom integrations required.

Any operator in the UPU’s 192-member nation network can activate Amazon PreDepart as their certified DDP service enabler today. There’s no customs integration to build and no in-house expertise to develop. Activate, configure, and start collecting duties before departure.

Are you a postal operator or express shipper interested in activating Amazon PreDepart as your certified DDP service enabler? We’d like to hear from you! Connect with our team directly 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.

How MTC’s 511 program uses Amazon Connect to serve 1.6 million callers

Ofelia Walsh — Wed, 02 Sep 2026 17:47:44 +0000

For the 7 million residents of the San Francisco Bay Area, getting to work, school, or home safely and on time depends on reliable, real-time travel information. Whether it’s checking when the next bus, train, or ferry departs; finding out about a freeway closure; or getting a broken-down car towed off the Bay Bridge, the region’s 511 traveler information service is a critical public resource. Its phone service runs on Amazon Web Services (AWS) using Amazon Connect Customer and Amazon Lex.

The Metropolitan Transportation Commission (MTC), the transportation planning, financing, and coordinating agency for the nine-county Bay Area, operates the 511 phone service as a fully automated interactive voice response (IVR) system that handles approximately 1.6 million calls per year with zero wait times and no live agents.

A 20-year-old service needed a new platform

MTC has operated the 511 traveler information line for more than 20 years, providing callers with real-time transit departures, traffic conditions, driving directions, emergency alerts, and transfers to regional transit agencies and paratransit operators. The system has always been fully automated with no live agents and no hold queues while serving an unlimited number of concurrent callers around the clock.

MTC selected Amazon Connect Customer for its breadth of features and its ability to integrate with the agency’s existing data infrastructure, which is hosted on AWS. MTC completed the migration and launched the new Amazon Connect Customer 511 phone service on September 28, 2023.

Conversational AI replaces traditional IVR menus

Unlike traditional IVR systems that force callers through rigid touchtone menus, MTC’s 511 service uses Amazon Lex—the same conversational AI technology that powers Amazon Alexa—to understand natural speech and guide callers to the information they need.

When a caller dials 511, Amazon Lex processes their spoken request, identifies their intent, and routes them through the appropriate call flow within Amazon Connect. A caller can say “transit departure times,” name a transit agency such as BART or VTA, and provide a stop name. Amazon Lex handles the exchange, collecting each piece of information and returning a real-time answer. MTC’s 511 service supports both English and Spanish. Callers who prefer touchtone input can use that as well.

Because Amazon Lex handles all caller interactions, MTC operates the 511 phone service without a single live agent. Each call is answered instantly. The system handles an unlimited number of concurrent callers, which is a critical capability for a service covering nine counties and over 7 million residents.

Real-time data powers every call

Behind each 511 call is a data pipeline built on AWS. MTC’s data and development team collects transit and traffic information from dozens of regional operators and stores it in databases hosted within AWS. A custom API layer exposes this data to both the 511 IVR system and the 511.org website, providing a consistent experience across channels.

The data falls into two categories:

Static data – Transit schedules that update whenever agencies publish changes, typically monthly or quarterly.
Real-time data – Live predictions refreshed as frequently as every 10 seconds, depending on the transit operator.

When Amazon Lex captures a caller’s request, the Amazon Connect Customer contact flow invokes the API, retrieves the real-time prediction, and delivers the answer back to the caller through text-to-speech. This exchange takes seconds.

Serving travelers across nine counties

Callers interact with Amazon Lex call flows that provide information across several categories:

Transit departure times – Callers name a transit agency, provide a stop, and receive the next scheduled departure. Amazon Lex manages the multi-turn conversation, prompting for any missing details. This is the most requested feature, accounting for 75% of all calls.
Traffic conditions and driving times – Callers provide a city, landmark, or start and end city and receive real-time route guidance, estimated travel times, and traffic conditions.
Transit agency transfers – Callers can request a live transfer to BART, AC Transit, Caltrain, SamTrans, SFMTA, or VTA for issues such as lost items, to speak with a live operator, or specific inquiries, making up 10% of call volume.
Freeway Assist – Motorists whose vehicles break down on Bay Area freeways can call 511 to receive a no-cost tow, helping clear congestion quickly.
Paratransit – Dedicated menu options for riders who need accessible transit services, including transfers to live operators.
Partner programs – Information on FasTrak, Clipper, All-Nighter, Vanpool, and other regional transportation initiatives.

Amazon Connect Customer orchestrates the flow, there’s no dependency on human staffing. The system scales automatically to meet demand.

Improved visibility and reliable operations

Since migrating to Amazon Connect Customer, MTC’s team has gained operational capabilities unavailable in the previous system.

The ability to look up individual contact IDs in Amazon Connect Customer has been particularly valuable. “I can look up a contact ID and see exactly what the issue is with that call,” said a member of MTC’s 511 team. “It’s helpful and allows us to address user concerns and feedback quickly.”

To maintain continuous service availability, MTC’s consultant performs daily monitoring across both the Amazon Connect Customer production and staging environments. Whenever a subsystem experiences downtime, the team receives immediate Slack alerts, meaning a rapid response is mounted before callers are affected. This proactive monitoring, combined with separate environments, follows AWS operational best practices by catching issues early and keeping changes validated before they reach production.

Since going live on Amazon Connect Customer, the agency hasn’t experienced an unplanned outage. The team provides monthly call volume statistics and request breakdowns to leadership, giving decision-makers visibility into how the traveling public uses the service.

Navigating real-world challenges

The primary technical challenge MTC has encountered is background noise during calls. Because the majority of 511 callers are requesting transit departure times, many are calling from bus stops, train platforms, and other noisy environments. This can affect the accuracy of the Amazon Lex speech recognition function.

Beyond that, the transition has been seamless. “No other challenges,” said MTC’s 511 team lead. “Everything’s been pretty great and smooth.”

A model for agentless public sector automation

MTC’s 511 phone service demonstrates how public agencies can combine Amazon Connect Customer and Amazon Lex to deliver critical information services at scale without staffing a traditional call center or employing a single live agent.

By pairing conversational AI with real-time data APIs hosted on AWS, MTC serves 1.6 million callers per year across nine counties, covering modes of transportation from buses, trains, and ferries to freeway towing.

The result is a service that keeps the Bay Area moving, one 511 call at a time.

For additional public sector stories, you can explore the AWS Public Sector Blog.

The Metropolitan Transportation Commission (MTC) is the transportation planning, financing, and coordinating agency for the nine-county San Francisco Bay Area, serving over 7 million residents across San Francisco, Alameda, Contra Costa, Marin, Napa, San Mateo, Santa Clara, Solano, and Sonoma counties.

AWS expands its Defending Digital Campaigns offering for the 2026 election cycle

Leo Zhadanovsky — Tue, 01 Sep 2026 21:53:19 +0000

For the 2026 U.S. midterm election cycle, Amazon Web Services (AWS) is continuing to work with Defending Digital Campaigns (DDC) to provide more than 20 cybersecurity-related services at low or no cost to active and registered national party committees and federal candidate campaigns for the U.S. House and Senate.

This post describes the program for the 2026 cycle, the services it covers, and how eligible campaigns and committees can enroll. Since AWS first joined DDC in 2020 and expanded the offering in 2022 and again in 2024, eligible campaigns and committees of any size and on either side of the aisle have used these services to protect the data, identities, and applications they rely on through Election Day.

DDC is a nonprofit, nonpartisan, non-aligned organization that helps eligible federal political campaigns and committees access cybersecurity products, services, and information regardless of party affiliation. The Federal Election Commission has granted DDC special permission to operate this model so that all eligible campaigns and committees can receive consistent support within the bounds of campaign finance law.

Updates and highlights

The 2026 program refreshes the AWS service catalog available to eligible campaigns and committees through DDC. Here are three services to highlight this cycle:

AWS Security Agent – New for 2026 – Announced at AWS re:Invent 2025, AWS Security Agent is an agentic AI assistant that helps customers proactively secure their applications throughout the development lifecycle. It supports workflows that map directly to common campaign needs: on-demand penetration testing that produces validated vulnerabilities and reproducible exploit paths, design security reviews that analyze architecture and technical designs for security risks, and automated code security reviews on pull requests with inline remediation guidance. Eligible campaigns and committees enrolled in DDC can now use AWS Security Agent at no cost during the program window.
AWS Shield Advanced – Provides managed distributed denial-of-service (DDoS) protection for campaign websites, donor portals, and any other internet-facing application during the high-traffic windows that surround a national election. The DDC offering provides up to a 60-day program window with no long-term commitment.
AWS Wickr – Provides end-to-end encrypted messaging, voice and video calling, file sharing, and screen sharing for campaign teams. AWS Wickr holds a Defense Information Systems Agency (DISA) Provisional Authorization at Impact Level 5 in AWS GovCloud under the U.S. Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG), and Federal Risk and Authorization Management Program (FedRAMP) High authorization in AWS GovCloud (US). It’s in active use across the DoD, including a U.S. Air Force deployment of Wickr RAM through Air Force Cloud One and Air Force Special Operations Command (AFSOC), and a U.S. Army rollout that, as of January 2026, was approaching 100,000 registered users. Eligible organizations should work with their AWS account team to enroll in AWS Wickr.

In addition to these three, the program covers a broader set of identity, network, data, and operational security services. The full complement of services is listed later in this post.

Why this matters for the 2026 cycle

Election campaigns and committees continue to be high-value targets for nation-state actors, financially motivated criminal groups, and opportunistic intruders. The Federal Bureau of Investigation (FBI) Internet Crime Complaint Center (IC3) 2024 Internet Crime Report recorded 859,532 complaints with $16.6 billion in reported losses, a 33% increase from 2023.

Phishing and spoofing was the most-reported crime type by volume, with 193,407 complaints, and government impersonation accounted for $405 million in losses. Adding to that picture, the FBI warned in May 2025 that malicious actors are using AI-generated voice messages and text messages to impersonate senior U.S. officials and target their contacts—a tactic that translates directly to the campaign-staff threat model.

Campaigns operate on compressed timelines with lean staff, and they often lack the security headcount or budget that an enterprise has on hand year-round. Through this collaboration with DDC, campaigns of any size can access the same kinds of foundational security services larger organizations already rely on.

Campaigns operate with small staffs and tight timelines. Access to enterprise-grade security tools is something they need, not something they can usually afford. The continued collaboration between AWS and DDC puts essential security in the hands of every eligible campaign—at no cost. — Michael Kaiser, President and CEO, Defending Digital Campaigns

Services included in the 2026 offering

Eligible campaigns and committees can use these services through the program window. Each link goes to the service’s product page on aws.amazon.com.

Amazon CloudWatch – Centralize logs from systems, applications, and AWS services
Amazon Cognito – User sign-up, sign-in, and access control
Amazon Detective – Security data analysis and visualization for root cause analysis
Amazon GuardDuty – Intelligent threat detection
Amazon Inspector – Automated vulnerability management
Amazon Macie – Discovery and protection of sensitive data
AWS Audit Manager – Continuous auditing for risk and compliance
AWS Certificate Manager – Public and private SSL/TLS certificate management
AWS CloudTrail – User and API activity tracking
AWS Config – Assess, audit, and evaluate AWS resources
AWS Control Tower – Set up and govern a secure, multi-account AWS environment
AWS Firewall Manager – Centrally configure and manage firewall rules
AWS IAM Identity Center – Central management of access to multiple AWS accounts and applications
AWS Key Management Service (AWS KMS) – Create and manage cryptographic keys
AWS Network Firewall – Network security for your Amazon Virtual Private Cloud (Amazon VPC)
AWS Resource Access Manager – Securely share AWS resources
AWS Secrets Manager – Manage, retrieve, and rotate database credentials, API keys, and other secrets
AWS Security Agent – New for 2026 – Agentic AI assistant for on-demand penetration testing, design security reviews, and code security reviews
AWS Security Hub – Automated security checks and centralized security alerts
AWS Shield Advanced – Managed DDoS protection
AWS WAF – Protection for web applications from common web exploits
AWS Wickr – End-to-end encrypted messaging, voice and video calls, file sharing, and screen sharing

Who is eligible and how to enroll

Eligibility is determined by DDC, in line with Federal Election Commission guidance and DDC’s own program rules. The program is available to active and registered:

National party committees of major political parties
Federal candidate campaigns for the U.S. House and Senate
Other federal-level committees that meet DDC’s program criteria

Eligible campaigns and committees can visit AWS Security Services for Federal Political Campaigns to enroll. To learn more about DDC, contact DDC directly to confirm eligibility and request access. Existing AWS customers can also reach out to their account team or the AWS Public Sector team to discuss next steps after DDC has confirmed eligibility.

Conclusion

Election campaigns of every size deserve access to current, well-maintained security services. The 2026 refresh of the AWS offering through DDC—including AWS Security Agent—is intended to help campaigns and committees focus on running their operations and reaching voters with one fewer thing to worry about.

Democracy works when candidates and campaigns can focus on engaging voters, not worrying about protecting themselves from cyber threats. Our continued collaboration with DDC reflects the civic responsibility of AWS, making essential security accessible to every eligible campaign, regardless of party affiliation and budget. — Kim Majerus, Vice President of Global Education and Local Government, AWS

To learn more about DDC, visit defendcampaigns.org. To learn more about how AWS supports election cybersecurity, refer to prior posts on the AWS Public Sector Blog covering the 2022 and 2024 updates.

Human-in-the-loop claims processing with Amazon Bedrock AgentCore

Brigette Bucke — Tue, 01 Sep 2026 19:25:05 +0000

Each state eligibility office we talk to asks the same question: How do we move faster without increasing errors? The agentic AI pitch sounds compelling. The agent handles everything, humans step back, costs drop. But for environments where a bad decision means a family loses benefits or a state faces federal penalties, that pitch skips a few chapters.

States face financial sanctions when Supplemental Nutrition Assistance Program (SNAP) determination error rates exceed 6%. A single misclassified household can trigger corrective action cascading across a program. These stakes are budgetary and concrete, not abstract.

Here’s the argument the autonomous agent pitch avoids: Most production deployments don’t start fully autonomous, and many won’t. We recommend that the architecture supports the reality by design. Amazon Bedrock AgentCore developed by Amazon Web Services (AWS) does.

In this post, we explore a human-in-the-loop (HITL) framework in the form of architectural patterns teams can use to introduce agentic AI incrementally into eligibility workflows that are adapted to their programs, policies, and risk tolerances.

The autonomy progression model

Teams deploying agentic AI for claims processing tend to fall on a spectrum. At one end, the agent drafts and a human approves everything. At the other, the agent decides autonomously on scoped case types with proven accuracy. The middle ground is supervised autonomy, and that’s where most production systems live for a long time. Trust is earned through measured accuracy, not declared by architecture.

In this middle framework, Assist mode is where the agent drafts determinations and surfaces evidence. A caseworker reviews and approves each one. This is where you build trust, measure accuracy, and establish your baseline error rate.

In Supervised autonomy, the agent handles routine cases independently. Edge cases, denials, and anything below a given confidence threshold still route to humans.

Cedar policies define the boundary between Assist and Supervised autonomy modes declaratively. Cedar is an open source policy language developed by AWS where you can write human-readable rules specifying what an agent is permitted or forbidden to do. Instead of burying authorization logic in application code, you express it as policy: If conditions A, B, and C are true, permit this action. If condition D is true, forbid it. The rules are auditable, able to be versioned, and separate from the agent itself.

In Full autonomy (selective), only case types where the agent has demonstrated sustained accuracy at or below the acceptable error rate qualify. You can expand the scope based on evidence, not ambition.

	Assist	Supervised	Autonomous
Agent role	Drafts determinations, surfaces evidence	Approves routine cases autonomously	Full decision authority on scoped types
Human role	Reviews and approves each decision	Reviews edge cases and denials	Monitors metrics, handles escalations
Use when	Building trust, establishing baseline	Accuracy proven on routine cases	Sustained accuracy below error threshold

How Amazon Bedrock AgentCore supports the spectrum

A claims processing agent needs multiple capabilities working together. Here’s what matters, grouped by the question each capability answers:

Know: What policy applies?

Amazon Bedrock Knowledge Bases ingests federal regulations, state manuals, and county procedures. The agent retrieves actual policy language rather than approximating it. Amazon Bedrock AgentCore Memory persists context across sessions so the agent doesn’t start from zero on a reopened case. The case history, redetermination timelines, and pending verifications are all carried forward.

Decide: What action is authorized?

Authorization boundaries must be explicit, not implied. Cedar policies make them declarative. Amazon Bedrock AgentCore Runtime reasons about the determination in an isolated environment. Cedar policies define what the agent can and can’t do. For example: Calculate eligibility, yes. Override a human denial, no. Modify policy rules, no. Access cases outside its caseload, no. Cedar also scopes authority per program. This can apply to decisions such as authorizing the agent for making SNAP determinations, but making it recommend-only for Medicaid.

Connect: How does it reach external systems?

Amazon Bedrock AgentCore Gateway routes tool calls through a single managed entry point, such as case management systems, document services, state wage databases, and federal verification hubs. Amazon Bedrock Guardrails helps prevent personally identifiable information (PII) leakage, block prompt injection, and enforce topic boundaries.

Trust: How do humans stay in control?

Oversight is the mechanism that makes autonomy possible. Amazon Bedrock AgentCore Observability tracks each determination through the full reasoning chain. Evaluation scores decisions against ground truth and can detect drift within days. AWS Step Functions embeds agentic reasoning inside workflows with human approval gates. AWS Lambda interceptors evaluate each action in real time and escalate dynamically.

Group	Question	Components
Know	What policy applies?	Amazon Bedrock Knowledge Bases, Amazon Bedrock AgentCore Memory
Decide	What action is authorized?	Amazon Bedrock AgentCore Runtime, Cedar policies
Connect	How does it reach external systems?	Amazon Bedrock AgentCore Gateway, Amazon Bedrock Guardrails
Trust	How do humans stay in control?	Amazon Bedrock AgentCore Observability, evaluation, AWS Step Functions, AWS Lambda

Three human-in-the-loop mechanisms

This framework provides three patterns for keeping humans in the loop at the right points in a claims workflow.

1. Cedar policies as approval gates

The same policy that grants autonomous authority on routine cases can require human sign-off on exceptions. The agent does the cognitive work by gathering evidence, calculating eligibility, and drafting a determination, but the final action waits for confirmation when the policy demands it. Cedar’s forbid-beats-permit semantics make this a direct expression of policy rather than a workaround.

The following Cedar policy example shows how you could scope autonomous approval for routine SNAP renewals while requiring human review when income changes are detected:

// Permit autonomous processing for routine SNAP renewals
// where no income change is detected and confidence is high
permit (
  principal == EligibilityAgent::"snap-claims-agent",
  action == Action::"approve_determination",
  resource is Case
)
when {
  resource.program == "SNAP" &&
  resource.case_type == "renewal" &&
  resource.income_change_detected == false &&
  context.confidence_score >= 0.92
};
 
// Forbid autonomous approval when income has changed.
// This forces the case to a human reviewer.
forbid (
  principal == EligibilityAgent::"snap-claims-agent",
  action == Action::"approve_determination",
  resource is Case
)
when {
  resource.income_change_detected == true
};

In this example, the permit policy allows the agent to approve routine SNAP renewals only when no income change is detected and the model confidence score meets the 92% threshold. The forbid policy overrides any permit when income has changed, routing the case to a human caseworker. Because Cedar uses forbid-beats-permit semantics, a single forbid policy is sufficient to block autonomous action regardless of other permits in the policy set.

2. AWS Step Functions for workflow-level control

In this pattern, the agent handles high-volume cognitive tasks such as evidence gathering, eligibility calculation, and document assembly. The workflow pauses at a defined checkpoint. A human reviews the determination. Execution continues only after approval. You get AI throughput on low-risk work and human judgment where it matters.

3. AWS Lambda interceptors for dynamic escalation (design pattern)

Unlike Cedar policies and AWS Step Functions, which are product features you configure, AWS Lambda interceptors are an architectural design pattern you implement yourself. You write AWS Lambda functions that sit in the agent’s action path and evaluate each action in real time.

This provides fine-grained, dynamic escalation logic without hard-coding each edge case. For example, if the agent is about to deny benefits to a household with children under 5, escalate to a supervisor. These rules incorporate context the agent itself surfaces, giving teams dynamic escalation logic that adapts as policy evolves.

Why this matters now

Caseloads outpace hiring year over year. Caseworker turnover exceeds 30% in some states according to workforce surveys and federal research. Policy complexity increases each legislative session. Missed redetermination deadlines mean families lose coverage, agencies face audit findings, and program integrity erodes.

The framework discussed in this post gives caseworkers an agent that handles the research, retrieval, calculation, and documentation so human judgment goes toward the cases that actually need it.

An agent designed to process the majority of routine redeterminations autonomously while routing exceptions, denials, and low-confidence cases to caseworkers is a force multiplier. It helps keep error rates within federal tolerance while clearing the backlog that causes missed deadlines. Families can get answers faster, caseworkers can spend time on cases that need human judgment, and agencies can maintain the public trust that makes these programs work.

Get started

Ready to explore how HITL patterns can apply to your agency’s eligibility workflows? Start with these three components:

Amazon Bedrock AgentCore – Build, deploy, and manage AI agents with runtime isolation and observability.
Cedar policy language – Declarative authorization for fine-grained agent permissions. Use Cedar to define what your agent can and can’t do per program and case type.
AWS Step Functions – Embed agentic reasoning inside HITL workflows. Design checkpoints where human review is required before the agent proceeds.

You can contact your AWS account team to discuss a pilot, or visit the Amazon Bedrock AgentCore Documentation to start building.

AWS and OST Eastern Switzerland University of Applied Sciences: An Innovation Factory for Swiss Industry

Christoph Schnidrig — Tue, 01 Sep 2026 16:42:17 +0000

How cloud technology and artificial intelligence reach the production line directly – and why a university of applied sciences is the ideal place for it.

In most factories, production machines, measurement stations, and robots from various vendors stand side by side. Often, however they don’t communicate with each other. Anyone looking to leverage artificial intelligence to create value from this data – whether to reduce scrap rates or predict downtime – first needs a unified data foundation. This is exactly the problem that Amazon Web Services (AWS) and Eastern Switzerland University of Applied Sciences (OST) are now tackling together as part of a new collaboration under the AWS Cloud Innovation Lab program.

A data platform for the smart factory

The IWK – Institute for Materials Science and Plastics Processing at OST has been developing innovative solutions for over 20 years in collaboration with a network of Swiss industrial companies and international research partners, with complementary core competencies in advanced materials, production technologies, and component design. Around 60 staff members work with a state-of-the-art machine park that is available to companies looking to test new materials, processes, technologies before investing in their own production capabilities.

At its Rapperswil-Jona campus, OST is expanding this collaboration with industry into an Innovation Factory. Unlike a traditional research lab, this interdisciplinary center directly connects real-world manufacturing technologies – injection molding, additive manufacturing, metal machining, 3D printing – with robotics, AI, and data analytics. Companies can bring their own challenges and develop solutions jointly with the research team. Few facilities in Switzerland offer this breadth.

IWK Techpark in Rapperswil-Jona: State-of-the-art manufacturing technology for research and industry.

“Before our data converged on local laptops and servers – difficult to share, and no foundation to rapidly leverage new technologies like AI. On top of that, it’s nearly impossible to take a good prototype into production at an industry partner’s site,” says Prof. Dr. Frank Ehrig, Director of IWK

As manufacturing specialists, the IWK team and their partners don’t want to spend their time building IT infrastructure from scratch. With AWS as the cloud provider, this infrastructure is production-ready and scalable from day one – serving as the foundation for the Innovation Factory and for every industry project that emerges from it.

The first showcase project

What this looks like in practice is demonstrated by the first showcase project in the Innovation Factory – representative of many other manufacturing processes to come. As the initial use case, we’re connecting a complete injection molding production cell to the cloud: the injection molding machine itself (KraussMaffei), mold temperature control and in-mold sensing (Kistler), laser marking for individual part identification (Matriq), a precision scale (Kern), and a camera for visual quality inspection (Keyence). Six data sources, multiple different protocols and data formats – and ultimately one unified data platform.

Based on AWS IoT Greengrass – software that runs on an edge device directly at the plant and seamlessly connects it with the AWS Cloud – and AWS IoT SiteWise for structuring and visualizing industrial data, three concrete applications are built on top:

Real-time quality dashboards with Amazon Managed Grafana give machine operators and production managers continuous visibility into current production status.
AI-powered quality inspection directly at the machine detects deviations immediately and derives recommendations for ongoing production – without a round-trip to the cloud. Less time critical, more complex analyses are handled by Amazon Bedrock in the cloud, which automatically delivers root cause analysis.
A digital product passport gives each manufactured part its complete production history via QR code: process data, quality inspection results, and material traceability.

The production cell (mold temperature control, in-mold sensors, laser marking, injection molding machine, scale, camera) transmits its data to AWS via various protocols. The cloud stores and synchronized the data, AI/ML models analyze it, and the results are displayed as dashboards in the browsers of machine operators and production managers.

Especially valuable for IWK: AWS cloud experts and the IWK team develop the infrastructure and application code jointly- using AI-assisted software development with Kiro, which drastically shortens development cycles. In the process, the IWK team itself undergoes a steep learning curve and can apply this knowledge to any number of additional production processes in the future – well beyond this first project.

“Kiro connected straight to the running hardware and debugged it systematically. What would otherwise have been weeks of manual troubleshooting was done in a single session.”, says Ramon Iten, OT Engineer, IWK

Why this collaboration advances Swiss industry

This collaboration is more than a single project. It’s part of our commitment to making cloud and AI technology directly available where Swiss industrial companies research, test, and train. Rather than offering technology only from a distance, we’re investing in an institution that has been bridging research and practice for years.

Not only companies benefit, but also the next generation of engineers: OST students work directly on this project, and in future bachelor’s and master’s theses they’ll use the same cloud and AI technologies deployed in industry – hands-on education that starts on the shop floor.

“Swiss industry is renowned for its innovation – and for its exacting standards of quality and precision. In IWK, we’ve found a partner that has been living exactly this interplay between research and industrial practice for over 20 years. Together, we’re bringing AWS technology directly into applied research, right to the machine, where companies can experience it firsthand. What emerges is not a pilot project destined for the shelf, but a model that Swiss companies can adopt themselves,” says Felix Schoenherr, Country Manager, AWS Switzerland.

Get involved

OST’s Innovation Factory is open to companies – regardless of how far along you are in your own digitalization journey:

Services – short-term support, available at any time: consulting, material and failure analysis, or access to IWK’s state-of-the-art machine and equipment park.
Industry R&D Projects – bring your own challenge, whether it involves new materials, products, or technologies. Initial trials can be conducted directly at IWK, with confidentiality guaranteed.
Publicly Funded R&D Projects – for initiatives with greater innovation potential and risk: from Innosuisse innovation vouchers (feasibility analysis, CHF 15,000, 2–3 months) to multi-year Innosuisse or EU projects.

For more information or to discuss a specific project, visit the OST Innovation Factory website. If you’d like to learn more about the AWS technologies behind this project or discuss your own initiative with us, contact your AWS team.

How to secure communications beyond encryption with AWS Wickr

Chris O’Rourke — Tue, 01 Sep 2026 14:57:07 +0000

In response to a rise in cyber espionage activity conducted by nation-state affiliated threat actors, the Cybersecurity and Infrastructure Security Agency (CISA) has recommended using encrypted messaging applications to protect sensitive communications.

CISA’s Mobile Communications Best Practice Guidance advises government, military, and political personnel to “adopt a free messaging application for secure communications that guarantees end-to-end encryption.”

Encryption alone is not enough

As adoption of these applications increases, it’s important not to lose sight of recordkeeping and compliance obligations. Public-key cryptography pioneer Whitfield Diffie alluded to the recent US government group chat leak during the Cryptographer’s Panel at RSA Conference 2025. The use of an encrypted consumer messaging application to communicate classified information, he noted, broke archiving laws. Because many of these tools use 256-bit Advanced Encryption Standard (AES) encryption, which is “good enough” to protect sensitive information, he predicted an increase in the use of consumer applications in unapproved ways.

Consumer messaging applications are convenient, but they aren’t designed for national security or regulated environments. They don’t go beyond encryption to deliver the data retention and policy enforcement controls that are needed to secure mission-critical communications while meeting compliance requirements.

How AWS can help

AWS Wickr is a messaging and collaboration service that protects messaging, calling, file sharing, screen sharing, and location sharing with 256-bit end-to-end encryption (E2EE). Wickr combines advanced security for sensitive communications, administrative controls for user and policy management, and data retention for auditing and regulatory needs.

With Wickr, communications are encrypted locally on devices and remain undecipherable in transit. Every call, message, and file is encrypted with a unique secret key, and no one but intended recipients can decrypt them. It’s straightforward for personnel and teams to use and to access and download on iOS, Android, macOS, Windows, and Linux devices.

“For many federal agencies and organizations, having the ability to securely communicate and share information—whether in an office or out in the field, with the ability to translate languages in real-time—is key to mission success. AWS Wickr helps our customers collaborate securely with end-to-end encryption across multiple use cases, while also driving AI innovation and providing the administrative controls needed to support sensitive and regulated workloads.”

–Dave Levy, vice president, worldwide public sector at AWS

Wickr is Department of Defense (DoD) Cloud Computing Security Requirements Guide Impact Level 5 (CC SRG IL5) and Federal Risk and Authorization Management Program (FedRAMP) High authorized in the AWS GovCloud (US-West) Region. It also meets compliance programs and standards such as Health Insurance Portability and Accountability Act (HIPAA) eligibility, International Organization for Standardization (ISO) 27001, and System and Organization Controls (SOC) 1, 2, and 3.

Meeting CISA recommendations

A November 2025 update to CISA’s recommendations includes additional guidance aimed at combating the use of commercial spyware to target users of messaging applications. Wickr features and capabilities align with the following CISA mobile communications best practices, and can help you enhance the protection of sensitive data against threats:

E2EE on by default for all communications and metadata
Text interoperability across operating systems
No reliance on SMS-based authentication
Integration with single sign-on for phishing-resistant authentication
Burn-on-read and expiration timers for added security and privacy
Continuous security updates and vulnerability management

Centralized management

Wickr offers a centralized management console you can use to monitor network security in real time, enforce role-based access controls and security policies, manage message retention periods in accordance with your requirements, and generate detailed compliance and audit reports.

Fine-grained administrative controls allow administrators to add and remove users, and you can organize them into security groups with restricted access to features and content at their level. You can apply policies to each group that are custom-tailored to meet desired outcomes. Files can be uploaded and organized in folders, and a view-only mode can be configured for specific security groups to prevent downloading.

External collaboration

Unlike consumer messaging apps that allow the registration of anyone with a phone number or username—and don’t enforce limits on who can be invited to a conversation—Wickr federation and guest access features promote secure collaboration with outside parties. Wickr network administrators can enable or disable guest access and restrict communication with external networks by using allow lists that limit communication to approved network IDs. Groups of users can be assigned to specific federation rules, and there is a differentiated UX treatment for conversations that include out-of-network users.

Data retention

Administrators can configure and apply data retention to both internal and external communications in a Wickr network. This includes conversations with guest users, external teams, and other partner networks, so you can retain messages and files sent to and from the organization. Data retention is implemented as an always-on recipient that is added to conversations, similar to the blind carbon copy (BCC) feature in email. AWS Wickr offers two data retention deployment options: Serverless and Bot-based. Serverless data retention is managed by AWS and uses your AWS Key Management Service (KMS) key to store the data in Amazon S3. Bot-based data retention requires a Docker host, which can be on-premises, on an Amazon EC2 instance, or at a location of your choice. See AWS Wickr Documentation to choose the method that best fits your organization’s infrastructure and compliance requirements. AWS can’t decrypt conversations, giving you complete control over your data.

Digital sovereignty

When you use Wickr in an AWS Region of your choice, all the infrastructure required to operate it and all the conversations in your network are hosted within that Region. Wickr is among the services that will be featured in the AWS European Sovereign Cloud.

Wickr is currently available in the following AWS Regions:

US East (N. Virginia)
Asia Pacific (Malaysia, Singapore, Sydney, and Tokyo)
Canada (Central)
Europe (Frankfurt, London, and Zurich)
AWS GovCloud (US-West)

Wickr and generative AI

Wickr agents can help you extend the E2EE capabilities of Wickr to other applications and automate workflows. They function as standard users and facilitate integrations with external services, communication tools such as Slack, Discord, or Matrix-compatible endpoints, and specialized solutions such as the Android Team Awareness Kit (ATAK) through a dedicated plugin.

Using Wickr bots, your technical teams can build and deploy agent integrations within your Wickr network to bring AWS generative AI services to edge devices in a straightforward chat interface, opening up a variety of use cases:

Get answers with a Wickr LLM agent – Build a Wickr LLM agent integration with Amazon Bedrock using sample code. The bot can be configured not to store your questions or the answers it provides.
Recognize images – Build an agent for identifying objects, scenes, actions, and more in images uploaded through the chat interface using Amazon Rekognition. Capabilities such as object detection and facial recognition can be used to process photos or videos captured in the field and provide alerts or metadata to users.
Transcribe speech – Integrate an agent with Amazon Transcribe to automatically transcribe voice messages sent through Wickr and respond through text.
Translate messages – Build a multilingual agent that translates messages between languages using Amazon Translate in support of global collaboration.
Analyze audio – Use agents with services such as Amazon Polly or Amazon Transcribe to analyze audio from bodycams, drones, and other sources, and automatically generate transcripts, identify speakers, and detect sounds of interest.

Teams operating in high-stakes environments can ingest signal and sensor data through an API agent and integrate real-time alerts. This allows mission-critical messages to be rapidly disseminated to both federated and nonfederated Wickr users, reducing tactical latency and enhancing decision-making capabilities.

Protect your most sensitive conversations

Encryption is a critical component of a defense-in-depth security strategy, but it’s not a standalone solution for secure and compliant communications. AWS Wickr can advance your organization’s efforts to protect sensitive message content—including text, files, audio, and video—by combining E2EE with the broader protections needed to help meet requirements as cyber threats and regulations change. With enterprise-grade security features, granular administrative controls, and flexible integration capabilities, Wickr supports you as you follow the guidance set out by CISA, use generative AI to accelerate collaboration, and move beyond encryption to close the security and compliance gaps presented by consumer messaging applications.

Want to learn more about how AWS helps public sector organizations deploy AI-driven solutions? Connect with the AWS Public Sector Team today.

Army R&D team uses agentic engineering to build secure, compliant code

Michael Baker — Mon, 31 Aug 2026 20:36:31 +0000

Modern warfare demands software that moves at the speed of the mission. For U.S. defense research and development (R&D) organizations, this means building, testing, and fielding software faster than ever while meeting some of the most complex security and compliance requirements in the federal government. Traditional infrastructure approaches designed for waterfall development cycles can’t keep pace with the iterative, continuous nature of modern software delivery.

A defense-focused R&D secure coding solution was purpose-built for the U.S. Army to solve exactly this problem. The foundation is a more secure, cloud-based Amazon Web Services (AWS) landing zone that enables agile software development at scale without sacrificing compliance, security, or mission focus. In this post, we explain how developers reduced critical software delivery process times by up to 75% using AWS GovCloud (US) and AI-powered agentic engineering using this solution, how it empowers teams by accelerating authorization cycles across distributed teams, and how it is architected to meet Impact Level 5 (IL5) compliance requirements. Significant benefits of agentic engineering are shown in the graphic below: faster software delivery, shorter timelines from authorization to operate to MVP in production, and significantly less time needed to scan for security compliance.

Figure 1 Key outcomes include faster software delivery, faster start from authorization to Minimum Viable Product, and faster security compliance reviews using agentic software engineering.

Modernizing defense R&D without compromising security

Defense R&D organizations face challenges that commercial cloud solutions alone can’t address. Programs must meet IL5 compliance standards requiring rigorous controls across every layer of the stack. Developers, program managers, and defense industry partners don’t all work from the same network. They’re spread across different locations and classification environments.

Cyber, safety, and operational requirements have historically led teams into waterfall approaches to define system requirements in detail before building. This approach lacks the agility to respond to changing environments, missions, and technologies. That means they can’t realize the full benefits of Development-Security-Operations (DevSecOps) practices. Legacy infrastructure limits collaboration across cross-functional teams and partner companies, slowing time to capability.

Defense developers are taking a new approach to software acquisition that embraces agile principles and DevSecOps best practices. That requires a modern infrastructure foundation to support iterative, continuous software development.

Secure development solution to build compliant software

The Army development team created a secure development solution built on AWS GovCloud (US) Landing Zone that enforces Zero Trust and enables scalable collaborative coding, as shown in the diagram below.

This DevSecOps solution with Zero Trust enables more secure, scalable software collaboration. At the center of everything is the Zero Trust Access Gateway. This is the single point of policy enforcement. Every user, every device, and every session is continuously verified. There’s no implicit trust based on network location.

The entire solution operates within a defined Authority To Operate (ATO) Boundary authorized for IL5 data and workloads. By having a solution-level ATO, individual programs don’t need to go through the full 12-month authorization process independently. They inherit the solution’s security posture. New partners and tenants can start developing and testing software immediately without lengthy onboarding delays.

On the left side, partner access means partner companies can connect. They come through the Zero Trust gateway, get verified, and then access only the specific project resources they’re authorized for.

Integrated testing connects the solution to external systems: hardware-in-the-loop sets, simulation environments, and test ranges. Code developed in this solution can be pushed directly to test infrastructure without manual transfer steps.

On the right, developer access is how government engineers connect. They use the same Zero Trust verification, same policy enforcement, and same experience, regardless of where they’re physically located. In this environment, collaboration is easier and software can be built faster to meet compliance.

Secure data exchange means users can move artifacts, source code, compiled binaries, test data, and media between environments and partners more securely. This is often the biggest bottleneck in collaborative projects, and this solution automates it. This links secure development with operations pipelines.

Built on Landing Zone architecture on AWS

Specific AWS GovCloud (US) infrastructure underpins the software coding landing zone, nesting layers of security to accelerate IL5 compliance and meet Zero Trust mandates.

AWS GovCloud (US)

This is a physically isolated set of AWS Regions designed specifically for sensitive government workloads. AWS GovCloud (US) Regions are logically and physically administered exclusively by AWS personnel that are U.S. citizens. AWS GovCloud (US) meets Federal Risk and Authorization Management Program (FedRAMP) High and DoD IL5 requirements while providing AWS Services available in commercial Regions with additional compliance controls that the U.S. government requires. These workloads run in AWS GovCloud (US) to meet classification and data sovereignty requirements.

Landing Zone Accelerator on AWS

This provides the foundational multi-account architecture that organizes the cloud environment. The Landing Zone Accelerator serves as the blueprint for how accounts, networks, security controls, and governance policies are structured.

This open-source solution deploys the architecture automatically following AWS and DoW best practices while setting up organizational units, configuring centralized logging, enabling security services, and establishing network connectivity in a standardized, repeatable way. For software coding, the landing zone provides the scaffolding: separate accounts for each tenant, shared services accounts for common tools, a security account for centralized monitoring, and network accounts for connectivity.

IL5 compliance is achieved through built-in security controls and governance guardrails. Rather than configuring hundreds of security controls manually, the landing zone deploys them automatically. Service Control Policies prevent unauthorized actions, AWS Config rules continuously evaluate compliance, Amazon GuardDuty monitors for threats, and AWS CloudTrail logs every API call. If a tenant attempts a noncompliant action such as opening a port to the internet, guardrails prevent it automatically.

Zero Trust architecture integration

This integration replaces the traditional perimeter defense model where users inside the network are trusted. Zero Trust verifies every access request against the user’s identity, device posture, location, and behavior — every time, with no trusted network assumed. The Zero Trust capability provides cloud-based security to enforce these policies. Users connect to the solution where their identity is verified, device health is inspected, and access is granted only to the specific applications they’re authorized for.

Network-agnostic access

This is a direct result of Zero Trust. Developers no longer need a government-issued laptop on a government network with a hardware VPN token. They authenticate through the Zero Trust gateway, prove their identity and device policy compliance, and gain access. This is transformative for defense partners who previously required dedicated circuits to collaborate, which took time to provision and access.

AWS services powering the secure development solution

Landing Zone Accelerator on AWS • AWS Organizations • AWS Config • AWS CloudTrail • AWS Transit Gateway • Amazon Elastic Kubernetes Service • AWS CloudFormation

Adding agentic workflows to accelerate mission impact and innovation

The secure coding solution’s landing zone is actively supporting DoW R&D programs today. Distributed teams collaborate securely and deliver software faster than legacy environments allowed. Programs that previously faced 12-month authorization and contracting cycles to spin up new cloud environments now deploy minimum viable products (MVPs) in as little as 3 months, which is a 75% reduction in time to capability. That speed matters. Partners can rapidly integrate frontline insights and deliver relevant software solutions to the field as mission requirements evolve.

The solution also provides a cloud-based digital engineering workspace that integrates cyber, safety, and airworthiness verification into the iterative agile process rather than treating them as end-of-cycle gates. For DoW programs, this is a critical distinction. Safety and airworthiness certification can’t be an afterthought. Building verification in from the start means teams avoid a compliance bottleneck right before fielding.

Most recently, the solution integrated multiple AI models on AWS GovCloud (US) to address two of the most time-intensive processes in defense software delivery. For Security Technical Implementation Guides (STIG) compliance automation, an AI agent autonomously processes code against all 286 STIG rules and produces a structured compliance report for human review. A process that previously took 3 weeks now completes in 2–3 hours, which isn’t an incremental improvement but a fundamentally different category of speed.

For agentic engineering workflows, a chat-based agent integrated with coding capabilities gives engineers the ability to query, synthesize, and report on program data using natural language. Tasks that previously required hours can now be completed in under 5 minutes. Future applications under exploration include ticket triage automation and AI-assisted code review.

Secure Development Solution demonstrated metrics that make a difference to accelerate secure coding for defense systems, as shown in the graphic below.

Figure 3 AI-assisted agentic engineering supports human decision making with data preparation for compliance automation and chat queries for DevSecOps

This AI-assisted collaboration delivers measurable mission impact with a 75% reduction in time to capability. That number isn’t theoretical. The team compressed what was traditionally a 12-month authorization and environment provisioning cycle into 3 months to deploy a MVP. Programs that previously spent their entire first year standing up coding environments now make and deploy code within their first 90 days.

A concrete example illustrates the impact: A specific R&D program involving distributed defense industrial partner teams needed to collaboratively build control software in a secure environment. Before the secure coding platform, getting those teams connected, authorized, and collaborating took the better part of a year. The Army team onboarded them into a shared workspace with appropriate access controls in weeks. Those teams now iterate on code together in real time with automated testing against hardware-in-the-loop systems.

The solution provides a cloud-based digital engineering workspace that goes beyond source code management to integrate modeling tools, simulation environments, and collaboration platforms—all within the IL5 boundary.

Critically, this agentic coding solution integrates cyber, safety, and other tests into the agile process with humans at the center. These aren’t afterthoughts or phase gates at the end: Automated checks run with every build. When a developer pushes code, the pipeline automatically evaluates it against cybersecurity requirements, safety constraints, and operational tests. Issues are caught and fixed in hours, not months. Government engineers can focus their time on human decision-making after the AI engineering workflows organize their data. Lessons learned can be continually added into the agentic engineering reviews, speeding the cycle while improving software quality and security compliance.

A replicable model for secure coding

The secure coding solution is more than a single program’s infrastructure. It’s a replicable model for how software-focused organizations can modernize software delivery while maintaining the security, compliance, and mission focus needed. The landing zone is designed to scale. Additional tenants and programs can onboard using the same standardized, repeatable architecture, reducing the time and cost of standing up compliant cloud infrastructure from months to weeks.

This more secure coding solution is architected to rapidly evolve while supporting the agentic engineering approach. New missions can expand to include modeling and simulation and technical documentation creation. New AI models can be integrated alongside emerging AWS GovCloud (US) capabilities such as Amazon Kiro for AI-assisted coding, Amazon Quick for analysis, research, and report generation, and Amazon Bedrock AgentCore to deploy, monitor, and evaluate agent-based workflows. Collaborative engineers will be able to develop in the unclassified solution and push code to classified production environments.

The principles that make this environment replicable are straightforward. The architecture is network-agnostic and secure-by-design, with zero trust enforcement that works across any network or classification environment. Every capability is tied to a real program outcome, not technology for its own sake. And the solution is proven through real-world R&D programs, with support for acquisition development programs and generative AI use cases that demonstrate measurable impact at scale.

AI-powered agentic engineering supports human decisions

This case study shows how AI-powered agentic engineering supports humans in making effective, timely decisions to deliver needed defense capabilities. Other R&D organizations interested in modernizing their software development capabilities can explore how the secure coding environment on AWS enables more secure, agile DevSecOps at scale. Whether you’re looking to accelerate delivery timelines, streamline compliance automation, or adopt cloud-based development practices, the AWS team is ready to support your cloud journey. The latest security configurations and best practices are provided for the Landing Zone Accelerator – Universal Configuration. To learn more, visit AWS GovCloud (US) or reach out to the team at AWS.

AI Model choice brings Mission Advantage to AWS GovCloud (US) customers

Heather Crawford — Sun, 30 Aug 2026 14:10:12 +0000

Introduction

From citizen services to national security, government agencies and their supporting industrial base rely on AI to deliver faster decisions, better mission and business outcomes, and protect national interests. But as AI becomes deeply mission-embedded, a strategic question emerges: are you choosing the best model for each mission, or defaulting to the one you typically use? Customers should never be locked into a single model, and democratizing access to the world’s best frontier AI models gives customers the freedom to innovate on their own terms. That means choosing the right model for the right task, adopting breakthroughs as they emerge, and maintaining continuity when conditions change. For government missions, that principle is even more critical. Model choice is how agencies stay in control of their own innovation, advance U.S. global AI leadership, and deliver on America’s AI Action Plan.

As part of AWS’s up to $50 billion commitment to deploy integrated AI and HPC cloud infrastructure for the U.S Government, we’re driving American AI innovation by expanding AI model choice in our AWS Government Regions. We’re excited to share that AWS GovCloud (US) has expanded model families offered through Amazon Bedrock, giving government customers, their supporting industrial base, and technology partners the AI model choice their missions demand. Model choice is here today. Amazon Nova, Anthropic Claude, Meta Llama, NVIDIA Nemotron, OpenAI, and xAI Grok are currently available in Amazon Bedrock. Additional frontier models are also available in the same compliant and isolated cloud environment. This breadth of model choice gives government customers, the supporting industrial base, and technology partners the freedom to run inference, build agentic AI systems, and innovate on their own terms — choosing the best model for every task without compromise.

Why AI model choice is an operational imperative

AI model choice matters for every organization. For government missions, it’s an operational imperative. Here’s why:

Task-specific optimization – Different AI models excel at different tasks. A model optimized for code generation might underperform at document summarization. Having access to multiple models lets agencies match the right model to each mission requirement.
Agentic AI acceleration – Multi-model architectures underpin AI agents that work autonomously. Lightweight models handle routing while frontier models tackle complex reasoning, multiplying the value of every AI investment.
Cost optimization – Leaders can right-size AI spend, using cost-efficient models for routine tasks and reserving premium models for complex analysis.
Model evaluation – Developers can benchmark models against each other using their own data and requirements to pick the best performer rather than just picking the one they usually rely on.
Roadmap independence – AI models evolve on different timelines, with different strengths. Relying on a catalog of models ensures your mission isn’t tied to any single model’s development cycle.
Operational continuity – When a model version is deprecated, updated, or temporarily unavailable, having alternatives already integrated into your architecture means the mission continues without interruption.
Futureproofing – The field of AI is evolving more rapidly than any other technology inflection point in history. Multi-model architectures, enabled by model choice, position agencies to adopt new breakthroughs without re-architecting existing systems.

The mission impact is clear. Multiple model families mean faster deployment, less vendor risk, and operational readiness that holds as AI evolves. Agencies deliver outcomes faster and innovate at the pace the mission demands. Consider a mission system that uses a lightweight model to classify incoming sensor data, a reasoning model to generate threat assessments, and a code model to automate patching. All three run through a single Amazon Bedrock API, inside the same compliance boundary, with no additional procurement or vendor onboarding.

What AI models are now available in AWS GovCloud (US)

Through Amazon Bedrock in AWS GovCloud (US), customers have access to multiple AI model families including:

Amazon Nova – Amazon’s frontier models, purpose-built for enterprise-grade performance with best-in-class price-performance across text, image, and multimodal embeddings tasks. Agencies can use Nova to process intelligence imagery, automate document triage and embeddings, and integrate AI across high-volume workflows at a fraction of the cost.
Anthropic Claude – Known for nuanced reasoning, long-context understanding, and safety-focused design. Claude excels at complex analysis, document processing, and tasks requiring careful judgment. Government teams can use Claude for policy analysis, legislative review, and adjudication where precision protects the mission.
NVIDIA Nemotron – High-performance models optimized for enterprise AI applications, offering strong reasoning and instruction-following capabilities for government workloads. Agencies can deploy Nemotron for mission automation, agentic workflows, and tasks demanding precise instruction adherence at scale.
OpenAI GPT and OSS – Industry-leading models including GPT-series and open-weight models, bringing advanced reasoning, code generation, and multimodal capabilities. Teams can use these models for secure code generation, complex data analysis, and building AI agents that chain multiple reasoning steps.
xAI Grok – Built for reasoning over long, complex inputs with configurable depth and strong tool-calling capabilities. Grok excels at document understanding, agentic workflows, and tasks where hallucination tolerance is low. Government analysts can use Grok for contract review, case law analysis, and financial document question-answering where accuracy is non-negotiable.
Additional frontier models – A growing catalog providing agencies with access to the latest innovations in AI model capabilities. As new models launch, agencies can adopt them through the same API without re-architecture.

All models are accessible through the unified Amazon Bedrock API and the native SDKs by changing a single endpoint URL. These access profiles make model access and migration frictionless. Click her e to see all the models available in AWS GovCloud (US) and their compliance status.

Built for regulated AI workloads

For AI to deliver mission outcomes, it must run where the mission lives. For customers dependent on Controlled Unclassified Information (CUI) and regulated data, that means AWS GovCloud (US) – the same isolated, compliant infrastructure trusted for the nation’s most sensitive workloads. Your application inherits AWS GovCloud (US) GenAI/ML service and model compliance, so you don’t start your compliance package from scratch:

Data residency – All data remains on U.S. soil.
Isolated infrastructure – Models run within the same physically and logically isolated infrastructure trusted for sensitive controlled unclassified (CUI) workloads since 2011.
Operational excellence – AWS GovCloud (US) regions are operated by U.S. Citizens working on U.S. soil.
No data sharing – Customer data is never used to train or improve models.
Hardware-rooted trust – Bedrock model inference engine is built on the Nitro System with NitroTPM cryptographic attestation, providing hardware-level isolation and platform integrity verification for inference infrastructure.
Zero Operator Access (ZOA) – No operator, including AWS or model providers, can access prompts, completions, or model weights during inference.
Encryption – FIPS 140-3 validated, encrypted in transit and at rest, with customer-managed keys via AWS KMS.
Compliance posture – Compliance inherited, not rebuilt: meets FedRAMP Class D, DoD CC SRG IL4/5 and ITAR requirements
Responsible AI controls – Amazon Bedrock Guardrails Runtime API enforces content filtering, PII redaction, and topic restrictions.

Getting started with AI in AWS GovCloud (US)

Customers already operating in AWS GovCloud (US) can enable Amazon Bedrock and begin accessing AI models today. Here’s how to get started:

Enable Amazon Bedrock in your AWS GovCloud (US) account through the AWS Management Console.
Access available models – For details on how to access different models in AWS GovCloud (US), including which models are currently authorized for specific compliance levels, refer to the Amazon Bedrock model access documentation.
Benchmark and compare AI models against your requirements using built-in Amazon Bedrock evaluation tools.
Start building using Amazon Bedrock Agents, Amazon Bedrock Knowledge Bases, Amazon Bedrock Guardrails, and AgentCore to deploy production-ready AI applications.

Build mission-ready AI with the models you choose

For fifteen years, AWS GovCloud (US) has stood for a simple principle: customers should never have to choose between compliance and innovation. Our investments in AI infrastructure and GenAI service and model expansion carry that principle forward — delivering the next wave of innovation at speed and scale without sacrificing the compliance and security government missions require. The models are here, the infrastructure is ready, and the mission doesn’t have to wait.

To speak with an AWS specialist about your AI strategy, contact your AWS account team or the AWS Public Sector team.

What HCLS security teams can do this quarter to close the execution gap

Adam Birnbaum — Thu, 27 Aug 2026 22:50:01 +0000

Most security teams know what’s needed to defend their organization. Regulatory guidance is available, threat intelligence sharing has increased, and risks are well-documented. So why are healthcare and life sciences (HCLS) groups, from commercial payors to public health systems, still facing recurring incidents or falling behind in protecting sensitive information? The answer is the execution gap: the space between knowing what to do and the ability to get it done.

When working with health systems, I have seen security teams who could name most gaps in their physical or Amazon Web Services (AWS) environment. Awareness or execution were not their primary problems. Evidence unavailability or governance immaturity drove many of their issues. Unfortunately, this is the norm and not the anomaly. Controls were operational but lacked evidence or consistent follow through, including disaster recovery tests with no captured results, logging with no active monitoring, or governance meetings with no documented action items. Other teams had the reverse problem. They were so consumed by manual evidence collection that control execution slipped.

Both teams want to succeed, but the ever-changing regulatory environment and emerging security risks make it difficult to close the execution gap. To help you, instead of being a to do checklist, this post explores the widening knowing-doing gap and offers suggestions on what you can start changing now using existing resources.

The compounding risk spiral

Three forces are simultaneously pulling in the same direction: economic pressure, regulatory requirements, and AI-enabled threats. While manageable alone, together they compound in ways most security programs aren’t designed to absorb.

Economic pressure is real and accelerating. Reimbursement cuts, acute for nonprofit health systems, community hospitals, and academic medical centers already operating on thin margins, are usually felt by security in the form of reduced headcount or funding. This usually impacts monitoring, patching, and evidence collection. Someone absorbs the work into their existing workload or it’s deprioritized, risking overall defense and compliance.

The regulatory landscape is moving faster than teams can absorb. It’s not only the Health Insurance Portability and Accountability Act (HIPAA) anymore. State privacy laws are expanding, carrying shorter compliance windows, potentially conflicting requirements for multistate groups, and costly noncompliance. AI governance laws are emerging rapidly with aggressive enforcement timelines.

Most teams struggle to keep pace with one regulatory change; three at once introduces unintended risk, cost, and adoption pressures. The problem isn’t understanding the requirements but whether your governance program, resources, and executive support can keep pace with the rate of change.

AI-enabled threat activity targets healthcare specifically. The timing between vulnerability identification and exploitation is shrinking. According to Cogent Security, the window has reduced to 12 hours from 125 days. Healthcare groups, especially in the public sector, are targeted because resource constraints are well known, resulting in security teams having difficulty remediating fast enough to ward off unauthorized actions and continuing to widen the execution gap.

The 2026 Verizon Data Breach Investigations Report confirms the acceleration. This year’s report indicated that vulnerability exploitation surged 55% year-over-year to become the leading initial access vector for the first time in the report’s 19-year history. Meanwhile, Comparitech reports that 120 ransomware attacks targeted hospitals and clinics in Q1 2026 alone.

These aren’t separate problems to solve independently, which is why they compound. Strained teams fall behind on security posture work, leading to control weakness accumulation. This often translates to increased incident probability, with the organization spending more on reactive triage without catching up. The funding needed for security maturity is now spent on incident management.

The common thread between the three is capacity and needing to do more with what you have without it becoming burdensome.

Your problem isn’t only your problem

A security gap is an ecosystem problem, but many treat it as internal. Think about who might be connected to your systems or environment: payers, providers, electronic health record (EHR) vendors, state health information exchanges, pharmacies, and members. Third-party interconnection means that when one organization has an unaddressed gap, everyone connected to it inherits a portion of that risk. Controls are strongest when the connections between domains are secure and there is continuous collaboration to keep them protected.

The execution gap isn’t about one health system failing to maintain their controls, but how you and your providers are intertwined and must collaborate to address the shared risk.

The access you haven’t detected

When was the last time you had full confidence that nothing unauthorized was happening in your environment? The answer often heard is “we have not had an incident yet.” Without continuous monitoring, that often means “we have not detected one yet.”

Dwell time is the window between unauthorized access and its discovery. For teams that can’t staff or afford around-the-clock security operations monitoring, that window stretches and damage accumulates.

Your cloud detection services can help close this gap and provide visibility where it’s lacking without adding headcount or constraining teams. For example, Amazon GuardDuty runs continually across accounts and workloads, surfacing findings on unauthorized access, credential misuse, and data exfiltration that would otherwise sit undetected. When GuardDuty identifies a finding, Amazon Detective correlates activity across your logs, network flows, and API calls for event reconstruction, significantly reducing investigation time and expediting root cause determination and remediation. This requires no manual effort from team members or reassignment. Instead, team expertise focuses on response and control improvements rather than manual log review or incident retracing.

Why checkbox compliance must remain in the past

Historically, many organizations’ security compliance efforts were focused on what’s necessary to pass the latest audit or customer assessment. They were checking off an annual compliance requirement instead of taking security seriously, creating false confidence and significantly increasing risk. Passing an audit means your controls met the criteria at the time of the assessment. It doesn’t mean those controls are operating as designed between audits or that data privacy protections are consistently adequate.

The pattern across resource-constrained HCLS organizations is consistent: compliance-as-event (what’s needed to pass) rather than compliance-as-operating-posture (continuous and evolving). Due to resource constraints and unfunded regulatory mandates, teams scramble to pass regulations and then revert to baseline or delay remediations until the next cycle. They’re usually surprised when next year’s assessment criteria don’t match the prior year or their remediation no longer fully meets this year’s requirement, leading to a new exception. Even without the new HIPAA Security Rule changes, enforcement actions now consider how risks from the addressable requirements were handled. That would be an expensive surprise to someone who believed that they were compliant because the rules weren’t mandatory. Whether an organization is a small practitioner or a large nonprofit community hospital, when resources are stretched, remediation timelines and framework or regulatory change maintenance are challenged as well.

This is where you determine whether your operating processes are making your team’s work invisible or unsustainable. The shift from annual evidence collection to continuous documentation is where automation matters most. Passing the current regulations isn’t enough. You need to put systems in place that will ease the overall burden. This will also organically help with posture strengthening and shifting your organization from reactive to proactive.

The privacy dimension you’re probably underestimating

When the industry talks about the execution gap, the default framing is security. But the downstream consequence of a healthcare incident is rarely a security issue alone. It’s a privacy violation, with data exposed, patients affected, and trust eroded.

Many HCLS organizations merge privacy and security rather than treating privacy as a parallel discipline with its own governance, impact analysis, and by-design standards. The regulatory scrutiny is increasingly coming from the privacy side: state privacy, AI data-use rules, and patient rights provisions many security professionals aren’t traditionally skilled to handle.

A practical starting point is to gain visibility into what sensitive data, such as protected health information (PHI), you have and where it lives. Services such as Amazon Macie help you discover health-related data located in unmonitored locations across Amazon Simple Storage Service (Amazon S3) storage. That visibility is the first step toward governing what you can’t currently see, and it shifts data privacy from aspiration to operational capability.

When deciding if your privacy program is sufficient, examine whether you have true data governance or have security controls that merely happen to protect data. Also look at whether the time spent on maintenance has been sufficient.

The path forward starts this quarter

The postponement to the HIPAA Security Rule changes gave you time, but a delayed deadline doesn’t delay your risk. If enacted, all addressable requirements become required. If your team can’t handle your current compliance workload, what happens when the HIPAA or new federal or state regulations arrive? Because of the deferral, you can close gaps at a controlled pace before they become the next obligation you’re juggling. The following path is how to take advantage of the extra time while also beginning to close your own execution gap.

None of this requires a massive transformation or additional resources. It requires sequencing.

Days 1–30: Increase visibility into your system

Deploy Amazon GuardDuty in your environment for continuous detection. Amazon Macie can then be run against your Amazon S3 storage to identify sensitive data in unexpected locations. Afterwards, conduct a shared-responsibility analysis, which maps each compliance requirement to your obligations or your cloud provider’s attestable controls, revealing which items your team must actively prove and which are already covered. It’s a high-impact exercise that can provide HCLS organizations significant efficiencies. Finally, use AWS CloudTrai l for API activity logging across your accounts.

Collectively, these lay the groundwork to provide the visibility and monitoring manual efforts can’t sustain. They also provide effective, automated discovery, analysis, and evidence logging that establishes an enhanced baseline.

Days 30–60: Operationalize your visibility

Configure AWS Security Hub to aggregate account findings and evaluate your posture against Foundational Security Best Practices, providing you with a single view instead of isolated alerts. Conformance packs in AWS Config further help by continually evaluating configurations against HIPAA and National Institute of Standards and Technology (NIST) SP 800-53 control baselines, identifying risks as they occur instead of during periodic reviews or audit preparation.

Those steps operationalize your new visibility to make it actionable and increase detective and prevention layers of defense. It also helps you move from a state of preparing for audits to operating in an audit-ready state that continuously protects your organization and helps you demonstrate compliance. Your evidence now becomes a byproduct of operations and not a quarterly sprint consuming team capacity or shifting their focus from defense and posture improvement.

Days 60–90: Communicate and sustain

Take your new visibility and translate it into language your leadership can act on. Quantify what you found and frame it as business risk instead of technical debt. If you discovered your team was already doing the work and the operating model was hiding it, show leadership: here is what we do, here is the evidence, and here is how we sustain and evolve it. This is the bridge from discretionary project funding to sustained operational investment.

Each step is independently valuable and moves you from knowing what’s needed to doing it and being able to demonstrate program maturity.

What comes next

The execution gap won’t close because someone publishes another best-practices guide or leadership agrees to fund additional staffing, probably at the cost of needed technology. It closes when teams start using the solutions they possess now to shrink visibility gaps, automate evidence, and reduce manual efforts. This means your team can focus on defense, strategy, and translating findings into language that moves leadership to act.

This is the first of three connected posts. The focus in this post is to close the execution gap with existing resources. The next post examines how AI can multiply a stretched team’s capacity to help strengthen your security posture maturity without increasing overhead or risk. The last post turns to the element most technical programs struggle with: communicating risk to leadership in language that secures sustained support.

Get started

Activate Amazon GuardDuty in your account for continuous detection and initiate a shared-responsibility analysis using the AWS Compliance Center. Specific HCLS guidance can be found at AWS HCLS compliance solutions or contact your account team for help.

Which of these forces (economic pressure, regulatory acceleration, or AI-enabled risks) is hitting your team hardest right now?

Modernizing state, local digital government services with AWS and Presidio

Mike Baur — Thu, 27 Aug 2026 22:44:51 +0000

Nearly seven in 10 states now have or are building a unified resident portal, according to the National Association of State Technology Directors (NASTD) 2025 Constituent Experience: State Government IT Strategies survey.

That’s an important step forward, but it also raises the bar. Residents don’t judge government by the portal itself. They judge it by whether they can complete tasks quickly and without friction. Behind every great digital experience are modern workflows, connected data, accessible design, and governance that keeps services running reliably. Without them, even the best-looking portal falls short.

Today’s state and local government agencies face a practical modernization challenge. Residents expect faster, more accessible, transparent services, but agency teams struggle to deliver. From legacy systems to fragmented data to evolving compliance requirements, the gap is clear.

A recent State CIO Survey from the National Association of State Chief Information Officers (NASCIO) highlights that modernization extends beyond a single piece of technology. Digital accessibility, AI, modernization funding, cloud, data governance, collaboration, and service delivery are now all connected priorities that influence constituent-facing experiences and the operating models that make those experiences possible. Amazon Web Services (AWS) and partners like Presidio help agencies address these priorities through cloud-based modernization patterns that connect workflow, data, experience, and governance.

Digital services modernization is the process of shifting from isolated tools, siloed applications, and time-consuming manual processes to a more connected, governed, and reusable service environment. For state and local governments, that means modernizing the workflows, data exchanges, security controls, and resident experiences that are connected to services, such as benefits enrollment, licensing, permitting, case management, and public safety coordination.

Why digital services modernization matters now

The core systems that state and local governments rely on were designed for a different era of service delivery. Although these legacy systems might still perform important agency functions, they weren’t created to focus on resident engagement. So when residents need to move across programs, submit information, track a case, or receive updates, friction often follows.

The result of that friction moves beyond a technology problem and becomes an operating one:

Workflows that depend on manual handoffs create a burden on staff, pulling them away from resolving resident needs.
Data that sits in disconnected systems creates multiple touchpoints that frustrate residents because they must repeat the same information across agencies.
Digital services that aren’t compliant with current accessibility requirements isolate residents who need public services most while putting the agency at risk of noncompliance.

Workforce pressure also shapes this modernization challenge. MissionSquare Research Institute found in its 2025 State and Local Government Workforce Survey that concerns around recruitment, retention, compensation, organizational culture, and succession planning are top of mind for government employers. Rather than add new systems for workers to manage, we recommend that agencies prioritize modernization that reduces the manual burden that falls on staff.

Making the move toward modernization

The pivot away from siloed services toward a unified service delivery model is already underway, as the NASTD Constituent Experience survey confirms. That progress matters, but it also sets a higher standard. Portals improve the resident experience only when agencies also address the workflows, data, accessibility, and governance behind them.

We recommend that modernization efforts start with the service journey that causes the most delays for residents and staff. When you modernize around that journey, you can identify the points where cloud capabilities can reduce friction without forcing a full replacement of every underlying system at once.

A digital modernization strategy connects four areas: workflow, data, experience, and governance. These four areas are impactful on their own, but the value comes from treating each as one operating model.

A practical framework for digital services modernization

This framework connects four areas that, when addressed together, form a cohesive operating model for modern service delivery:

Modernize the workflow – Intake, routing, review, approval, exception handling, and notification steps often reveal where services slow down. Cloud-based workflow orchestration, event-driven architecture, and managed integration services can help agencies standardize common processes while adapting to program-specific rules.
Build trusted data exchange – Interoperability means that authorized systems can exchange data in a more secure, governed, and usable way. In practice, it helps residents avoid repeating information, helps staff see more complete case context, and helps agencies reduce duplicative work across programs.
Design around the resident experience – Resident-centered digital services use accessible, mobile-responsive, plain-language interactions that reflect how people actually reach out for support. They also connect the frontend experience to the operating model behind it. A portal might streamline access, but residents still judge the service by whether they can complete the process, receive updates, avoid duplicate submissions, and understand the next step.
Embed governance from the beginning – Security, identity, auditability, records management, privacy, and compliance can’t sit outside the modernization plan. National Institute of Standards and Technology (NIST) Cybersecurity Framework 2.0 gives organizations a common structure for managing cybersecurity risk. NIST’s CSF 2.0 quick start guidance connects cybersecurity with enterprise risk management and workforce management. For agencies modernizing digital services, that connection matters because security, compliance, staffing, and service delivery risks often intersect.

How cloud capabilities support modernization

AWS can support government modernization by helping agencies assemble scalable infrastructure, managed services, security capabilities, automation tools, data services, and AI services around mission needs. Cloud modernization helps agencies move from one-off system upgrades to reusable service capabilities that can support multiple programs over time.

For example, cloud-based integration and compute services such as AWS Step Functions and Amazon EventBridge can help agencies connect systems and automate workflow steps without building every component from scratch.

Amazon API Gateway powers the exchange between an agency’s applications and the data that fuels them. Managed databases and analytics services can support case records, transactions, reporting, and governed data access. Identity, monitoring, logging, and audit services can help technology and compliance teams maintain visibility across digital service environments.

The modernization advantage comes from using these capabilities as reusable patterns. Rather than treating each service as a separate custom build, agencies can create repeatable approaches for intake, eligibility review, notifications, identity, document handling, and case updates. That shift can reduce delivery risk because teams can deliver incremental improvements while building a foundation that supports future services.

Prepare for responsible AI in government services

Generative AI and agentic AI will shape the next phase of digital government, but we recommend that agencies approach them through governance before automation. Agentic AI refers to AI systems that can plan, take defined actions, and coordinate steps toward an outcome within human-approved boundaries. In government services, those boundaries matter because decisions might affect benefits, eligibility, safety, access, and public trust.

AI can help agency teams search policy guidance, summarize case information, classify documents, draft resident communications, or guide users through complex processes. The primary risk is when agencies deploy AI before they define human review, auditability, access controls, data boundaries, and escalation paths.

Services like Amazon Bedrock give agencies a foundation for building and scaling generative AI and agentic applications while maintaining the security and privacy of sensitive government data.

Leaders need to treat AI readiness as an extension of modernization readiness. If workflows remain unclear, data remains fragmented, and governance remains manual, AI might amplify those weaknesses. When agencies first clarify service journeys, data rules, identity models, and accountability structures, AI can support staff capacity while preserving human judgment for consequential decisions.

What agencies can consider next

The goal of modernization is to build a more responsive, resilient operating model for public services that can adapt as resident needs and policy priorities change.

When agencies connect workflow, data, experience, and governance through cloud-based patterns, they can reduce operational bottlenecks, improve staff capacity, and strengthen resident trust. That same foundation also positions teams to adopt responsible AI in a way that reinforces (not replaces) human judgment in consequential decisions.

Taken together, a cloud-aligned, pattern-based approach gives public sector leaders a practical way to improve today’s services while preparing for the next generation of digital government.

In a future post, we’ll explore how agencies are applying these patterns to accelerate specific service delivery outcomes.

Explore how Presidio and AWS are helping agencies apply this framework.

How ITHAKA built an on-demand PDF remediation pipeline on AWS

Dane Hillard — Thu, 27 Aug 2026 20:21:35 +0000

ITHAKA is a not-for-profit organization dedicated to improving access to knowledge and education. Through its platforms, including JSTOR, one of the most widely used digital libraries in the world, ITHAKA provides millions of researchers, students, and educators access to scholarly content spanning centuries of academic work. That mission depends on making content accessible to every user, regardless of ability.

ITHAKA’s digital corpus includes approximately 156 million pages across 20 million PDFs, with source material dating as far back as 1550. The collection spans 30 years of humanities, arts, and social sciences publishing—born-digital documents, scanned print materials with varying optical character recognition (OCR) quality, and content ranging from single-column journal articles to complex mixed-media layouts. The U.S. Department of Justice (DOJ) revised the title II rule of the Americans with Disabilities Act (ADA) to give state and local government entities until 2027 for populations over 50,000 and 2028 for populations less than 50,000 to meet PDF/Universal Accessibility (PDF/UA) standards. ITHAKA faced a question central to its mission: how do you make 156 million pages accessible—responsibly?

In this post, we describe how ITHAKA and Amazon Web Services (AWS) collaborated to build an on-demand PDF accessibility pipeline that remediates documents when users need them, serving researchers while using nonprofit resources responsibly. For organizations managing a large document collection under accessibility compliance deadlines, this post shows there is an affordable, practical path forward that doesn’t require converting an entire library upfront.

How to remediate at scale

Making knowledge accessible is core to ITHAKA’s mission. The ADA title II revised rule provided a concrete deadline, but ITHAKA’s commitment to accessibility predates the regulation. The question was never whether to remediate, it was how to do it at scale.

Manual PDF remediation typically costs $1–4 per page. For ITHAKA’s 156 million-page corpus, that translates to $156 million–$624 million in upfront remediation costs. Even at the low end, bulk remediation of the full collection wasn’t a responsible use of nonprofit funds, and it was unnecessary.

Most users request a fraction of the corpus at any given time. A user searching JSTOR for a specific journal article doesn’t need all 20 million PDFs remediated; they need the one they’re reading. This usage pattern pointed to a different approach: rather than remediating the entire collection upfront, build an efficient automated process that converts PDFs on demand, based on actual user requests.

On-demand remediation serves users immediately, builds an accessible content library organically based on real demand, and directs resources where they have the most impact. As more users request accessible PDFs, the remediated collection grows, driven by the people who need it most.

The technical challenges compounded the economic ones. ITHAKA’s corpus includes born-digital PDFs with proper structure, scanned documents with partial or no OCR data, and everything in between. A remediation pipeline needed to handle this diversity reliably while integrating with ITHAKA’s existing content delivery infrastructure, security controls, and operational standards.

The starting point: an open source foundation

The Arizona State University (ASU) Artificial Intelligence Cloud Innovation Center (AI CIC), powered by AWS, developed an open source PDF accessibility remediation solution under the MIT License. The solution automates PDF remediation using the Adobe PDF Accessibility Auto-Tag API for structural tagging, Amazon Bedrock for generating image alt text, AWS Step Functions for orchestration, AWS Lambda for serverless processing, and AWS Fargate for containerized workloads. An earlier post on the Public Sector Blog, From inaccessible to inclusive, describes the solution and its initial use at The Ohio State University Libraries.

ITHAKA’s engineering team identified this solution as a strong starting point. Deploying it in production at ITHAKA’s scale, however, required several adaptations:

Infrastructure as code (IaC) – Migration from AWS Cloud Development Kit (AWS CDK) to Terraform, ITHAKA’s standard for infrastructure management
Event-driven API – Replacing Amazon Simple Storage Service (Amazon S3) object triggers with Amazon EventBridge for programmatic invocation, traceability, and status reporting
Security integration – Aligning with ITHAKA’s service control policies (SCPs), network boundaries, and AWS Identity and Access Management (IAM) least-privilege requirements
Observability – Integrating with ITHAKA’s existing monitoring and logging tools

In addition, the ITHAKA team adopted PDFix and veraPDF for structural tagging and validation to meet ITHAKA’s specific remediation requirements.

Architecture

The production architecture separates two concerns: the user-facing application flow and the underlying remediation pipeline.

The user experience follows a straightforward flow:

A JSTOR user navigates to a content item and chooses Request accessible PDF for an unremediated item or Download accessible PDF for a previously remediated item.
If an accessible PDF is available and newer than the source document, the user downloads it immediately.
If no accessible version exists, the system triggers the remediation pipeline and optionally notifies the user when processing is complete.

Remediated PDFs are cached and reused. A remediated PDF is only reprocessed if the source PDF is updated or the remediation pipeline has improved, avoiding redundant processing while keeping content current.

The following diagram shows the user-facing flow: a JSTOR application user requests an accessible PDF, the system checks for a cached remediated version, and if none exists, initiates the pipeline and notifies the user upon completion.

Figure 1: Application integration with PDF remediation

The remediation pipeline processes each PDF through a series of steps:

An EventBridge event initiates the workflow, carrying a tracing identifier and metadata that follows the job through every service.
A Lambda function splits the PDF into individual pages for parallel processing.
Step Functions orchestrates the remediation tasks: PDFix applies structural tagging (headings, paragraphs, lists, and tables) to each page, and Amazon Bedrock generates alt text descriptions for images and charts.
A merge step reassembles the tagged pages into a single remediated PDF with a generated document title.
Accessibility validation checks the output against PDF/UA standards using tools such as veraPDF.
The remediated PDF and a complete event log are stored in Amazon S3.

The following architecture diagram shows EventBridge initiating the workflow, Lambda splitting the PDF into pages, Step Functions orchestrating PDFix structural tagging and Amazon Bedrock alt text generation, followed by merging, PDF/UA validation, and storage in Amazon S3.

Figure 2: PDF remediation pipeline

Three design decisions shaped the architecture:

End-to-end tracing – Every remediation job carries a tracing identifier from initiation through completion. EventBridge emits status events at each pipeline stage (splitting, processing, merging, and validation), and an event log aggregator stores the full job history alongside the remediated PDF in Amazon S3. This provides auditability and operational visibility across the entire workflow.
Modular, swappable processing tools – The pipeline is designed so the remediation tools can be swapped out or chained with additional processors. As an example, the Adobe PDF Accessibility Auto-Tag API was replaced with PDFix and veraPDF without rebuilding the entire pipeline. As new tools become available, including generative AI capabilities, ITHAKA can integrate them to expand how they meet their users’ accessibility needs.
Heuristic pre-analysis with human fallback – Before processing, the system evaluates what remediation each source PDF requires, reducing unnecessary computation. When automated remediation doesn’t meet accessibility standards, the system signals for human intervention, providing a safety net for documents that require manual attention.

Building and deploying together

In February 2026, ITHAKA engineers and AWS solutions architects held a 2-day build-and-demo workshop to adapt the open source solution for ITHAKA’s environment.

Day one focused on infrastructure and deployment. The team converted the deployment from CDK to Terraform, deployed core services including Lambda functions, the Step Functions state machine, Fargate tasks, S3 buckets, and Amazon Virtual Private Cloud (Amazon VPC) configuration, and tested the pipeline with sample PDFs. The team then replaced the S3 event trigger with an EventBridge based API, adding support for tracing identifiers and status events.

Day two shifted to validation, security, and operations. The team tested the pipeline against diverse PDF types from ITHAKA’s corpus and addressed production requirements: IAM policy hardening, network ingress and egress controls, and integration with ITHAKA’s observability tools.

The workshop surfaced real engineering challenges:

ITHAKA’s SCPs restricted S3 bucket policy modifications, conflicting with the solution’s deployment scripts. The team resolved this by adjusting the SCP rules to permit public access blocks without interfering with infrastructure as code (IaC) deployments.
Amazon Bedrock model availability required explicit Region configuration to align with ITHAKA’s account constraints.
ITHAKA’s engineers used agentic coding tools to accelerate the adaptation work during the workshop.

Following the workshop, ITHAKA and AWS held multiple working sessions through April 2026 to support production deployment, addressing pipeline tuning for ITHAKA’s specific corpus characteristics, deployment refinements, and production readiness validation.

Results

Early results from the pipeline demonstrate the viability of on-demand remediation at scale.

Metric	Result
Accessibility check pass rate	98%
Cost per page	$0.026
Cost reduction compared to manual remediation	97%+ (from approximately $1–4 per page)
Time from workshop to production deployment	Approximately 2 months

Dane Hillard, associate director of Product Engineering at ITHAKA said, “Our collaborators at AWS were incredibly helpful in understanding what others were already doing in the accessibility remediation space, thinking through how we could adopt and adapt prior work, and in validating approaches we had thought of toward creating something sustainable in support of our accessibility mission.”

The on-demand model means ITHAKA remediates PDFs as users request them. Each remediated document is cached for future users, so the accessible content library grows with actual demand. Over time, the most-requested content is remediated first, directing resources to where they serve the most people.

Looking ahead

ITHAKA plans to extend the pipeline to support remediation at content ingestion, processing new PDFs as they arrive from publishers. Portico, ITHAKA’s digital preservation service, is exploring applying a similar approach to its own corpus.

The modular pipeline architecture positions ITHAKA to adopt emerging generative AI tools as they become available, without rebuilding core infrastructure. As the economics of AI-driven remediation continue to improve, ITHAKA is working toward costs below $0.01 per page at scale.

The underlying solution remains open source. Other institutions—universities, libraries, government agencies, and nonprofits—facing similar accessibility challenges can adapt it for their own environments and content types. The ADA title II compliance deadline applies broadly, and many organizations hold large PDF collections that need remediation. This post demonstrates that there is an affordable, achievable path to compliance, one that meets users where they are, without the upfront cost of remediating an entire collection. The architecture and approach are designed to be replicable.

Get started

Learn more about AWS Cloud for Higher Education.
If your organization is working on document accessibility, fill out the AWS Public Sector – Contact Us form.

How HOT uses open source on AWS to power humanitarian AI

DK Benjamin — Thu, 27 Aug 2026 20:18:29 +0000

When disasters strike, the first thing responders need is an accurate map. But for much of the world, detailed maps don’t exist. Humanitarian OpenStreetMap Team (HOT) has been fulfilling that need since 2010. Today, HOT is a global network of over 500,000 contributors across 94 countries. By combining local ground-truth mapping, regional hubs, and open source tools, HOT coordinates massive, crowdsourced efforts to provide immediate data to responders without licensing costs or procurement barriers.

However, manually tracing satellite imagery is slow when time is critical. To accelerate mapping, HOT developed fAIr, an open source, AI-assisted tool that detects geographic features for human verification, giving volunteers a head start. This post explores the architecture behind fAIr, which HOT built on Amazon Web Services (AWS) with a tech stack composed almost entirely of open source tools, bridging open source innovation and cloud infrastructure to scale community impact.

How fAIr works

A mapper traditionally opens a satellite image tile and manually traces every visible building footprint. This is a time-consuming process that keeps mappers from building a complete, accurate map of the disaster area in time for responders.

With fAIr, the mapper opens the same tile and sees predrawn polygons already overlaid. Their job shifts away from having to trace everything manually. Instead, mappers review, correct, and approve the work created by the AI tool. Users can also fine-tune per region because the models are localized to that specific area.

The following image shows AI-generated building footprint predictions (the purple polygons) overlaid on drone imagery using the YOLO_V8_V2 model. Mappers can review the image, correct any mistakes, and approve each prediction rather than tracing from scratch. For a demo of the process, visit the fAIr Learn page.

Figure 1: Drone image overlaid with building footprint predictions

Technical architecture

This section walks through fAIr’s architecture in three parts: where data is stored, how models get trained, and how predictions get served. Each layer pairs AWS infrastructure with open source tooling for the job.

Amazon Simple Storage Service (Amazon S3) serves as the central artifact and model repository for low-cost storage. PostgreSQL databases, managed by the CloudNativePG operator, handle runtime metadata and the SpatioTemporal Asset Catalog (STAC) database, which serves as the registry for GeoAI models.

The ZenML MLOps framework on Amazon Elastic Kubernetes Service (Amazon EKS) orchestrates training, provisioning ephemeral NVIDIA GPU instances using Karpenter only when jobs are requested. This scale-to-zero approach eliminates GPU costs when training is inactive. Upon completion, ZenML updates the artifact store and registers the new model into the STAC API and streams metrics to MLflow.

To secure low-latency performance, inference is decoupled from training using Knative for serverless workload management. The system uses CPU-based scaling on Amazon Elastic Compute Cloud (Amazon EC2) instances to run the models, eliminating the need for permanently running GPU infrastructure while responding to client requests quickly with predicted features.

The entire system architecture is provisioned with Helm Charts and deployed using ArgoCD. This infrastructure as code (IaC) approach keeps environments consistent, making staging-to-production transitions seamless and reproducible.

The following diagram shows the fAIr architecture. For more information, visit the fAIr mapping tool repo on GitHub.

Figure 2: fAIr technical architecture

Community impact

In addition to producing data quickly, HOT’s open source mapping ecosystem changes how communities prepare for, respond to, and recover from crises. The following examples show how these tools translate into real-world outcomes.

How fAIr was used in the Venezuela response

Most recently, an area outside of Caracas, Venezuela, was impacted by earthquakes on June 24, 2026. As part of the response, HOT activated to bring high-quality, up-to-date data to communities working on the ground for recovery efforts, coordinating with the United Nations’ International Organization for Migration (IOM), MapAction, iMMAP, and GiveDirectly. Through Vantor’s Open Data Program, recent high-resolution satellite imagery was made open source, and the HOT team immediately began running the imagery through fAIr to generate an initial picture of the damage to affected communities. Within 24 hours of the event, fAIr outputs were delivered to key early responders, providing data on building density, AI-assisted building digitization, and building damage predictions.

HOT didn’t release raw AI predictions as final data. The team merged outputs from fAIr and the Microsoft AI For Good Lab, then used the open source tool MapSwipe to crowdsource human validation of every prediction. The first batch of human-validated damage assessment was completed for three cities, Caraballeda, La Guaira, and Caracas, representing the most complete validated dataset produced for this event. In parallel, 451 volunteer mappers digitized approximately 53,000 buildings through the HOT Tasking Manager in less than a week.

The following image shows the fAIr building density estimation for northern Venezuela. The darker hexagons indicate higher concentrations of buildings, helping responders prioritize search and rescue operations.

Figure 3: fAIr building density estimation for northern Venezuela

The following screenshot shows a fAIr damage assessment model predicting different levels of damage in Catia La Mar, Venezuela, based on pre- and post-event imagery.

Figure 4: fAIr damage assessment model predicting different levels of damage based on pre- and post-event imagery. Source: Kshitij Sharma

Mapping for Climate Ready Cities: Sierra Leone

Across Bangladesh and 12 other countries, the Mapping for Climate Ready Cities program puts mapping tools in the hands of communities documenting transit networks, drainage infrastructure, and accessibility gaps. This data feeds into resilience planning such as evacuation plans for at least 80 households in Timor-Leste; drainage upgrades in Nakuru, Kenya, which have benefitted over 10,000 residents; clearer directions for investment in heat-resilient public spaces for the 60,000 residents of Maipú, Chile; and the potential to protect over 3.5 million people in Nigeria’s growing cities through air-quality monitoring.

In Freetown, Sierra Leone, the program focuses on heat resilience. Working with local organizations including Convention for a Democratic South Africa (CODESA), the Federation of Informal Settlements (FODU), and OSM Sierra Leone, the team trains university students and community members to capture drone imagery, digitize features using fAIr, and collect ground-truth data using Field Tasking Manager. From approximately 550 square kilometers of drone imagery, the team digitized all visible features and shared them with the Freetown City Council (FCC).

fAIr identifies trees and solar panels from aerial imagery, helping planners understand where shade and cooling exist. “We have more time to go to the field for data collection because we spent less time on digitalization,” says Lamine N’Diaye, project coordinator at HOT in Sierra Leone. The data has already influenced policy where the FCC used it to build a new taxation plan for marketplace areas, and the same dataset supports emergency access planning. Before HOT’s tools arrived, communities had the will to adapt but not the means. “People have many initiatives for mitigation, but we didn’t know the right technology to do that,” Lamine explains. fAIr is positioned to accelerate this work.

Countries participating in HOT’s Mapping for Climate Ready Cities program span Latin America, West Africa, East Africa, and South Asia.

Map4Mangrove: Indonesia

In Indonesia, the Map4Mangrove project works with coastal rehabilitation organizations to map mangrove coverage and improve monitoring using open spatial data. After a 2018 tsunami struck Pandeglang in Banten, the Indonesian Biodiversity Foundation (KEHATI) and local conservation group SALAKA launched the Blue Carbon Program, a rehabilitation initiative covering 14 hectares across five sites. But monitoring relied on paper-based records, making reporting labor-intensive and difficult for donors to verify.

Through Map4Mangrove, HOT’s Asia-Pacific Hub trained 20–30 university students on Field Tasking Manager, KoboToolbox, and Mapillary, then built a centralized UMap dashboard integrating drone imagery, geotagged field data, and carbon sequestration estimates. “The donor didn’t need to go to the field, they could just see the geotagged image on Mapillary and compare it with the collected data,” says Dinar Adiatma, data quality lead at HOT’s Asia-Pacific Hub.

The following image shows a mangrove rehabilitation site in Banten, Indonesia. The Map4Mangrove project monitors five sites like this one across 14 hectares, tracking growth and carbon sequestration through open mapping tools.

Figure 5: A mangrove rehabilitation site in Banten, Indonesia. Photo: Tony Liong, Open Mapping Hub – Asia-Pacific

Two students maintain the dashboard full time, and SALAKA has begun extending the approach to fish distribution data from local fishermen. In the following image, the Map4Mangrove field team reviews drone imagery at the Banten rehabilitation site.

Figure 6: The Map4Mangrove field team reviews drone imagery. Photo: Tony Liong, Open Mapping Hub – Asia-Pacific

What connects these stories

Each example follows a common pattern: open source tools lower participation barriers, AWS scales compute when needed, AI accelerates tedious work, and human validation improves quality and accuracy. Whether assessing earthquake damage in Caracas, identifying heat islands in Freetown, or monitoring mangrove rehabilitation in Banten, the architecture stays the same. The community changes, the model changes, but the platform holds.

Get involved

Visit HOT to learn more about their work. To start mapping, join a task on the HOT Tasking Manager. To explore fAIr and its open source AI models, visit the fAIr project page. To learn more about how AWS supports customers and partners to innovate across health, education, and climate, check out AWS Impact and Open Data Sponsorship Program.

FSU researchers improve cloud skills with AWS Research Skilling Accelerator

Jay Nappy — Tue, 25 Aug 2026 20:19:17 +0000

Modern research is increasingly data-intensive. Whether analyzing millions of satellite images for transportation safety, building predictive models from sensitive health records, or running high-performance computing workloads, today’s researchers need cloud and AI skills to accelerate science. At Florida State University (FSU), a growing community of faculty, staff, and students is proving what’s possible when researchers gain hands-on cloud expertise. The Amazon Web Services (AWS) Research Skilling Accelerator (RSA) is helping make it happen.

The challenge: Bridging the cloud and AI skills gap in research

Universities across the globe face a common challenge: Researchers generate massive datasets and need powerful computing capabilities, but many lack the cloud or AI skills to take full advantage of the tools available to them. Traditional training often doesn’t account for the unique workflows of health science researchers or the infrastructure professionals who support them.

At FSU, the university’s partnership with AWS has already delivered meaningful results, including a $20,000 Research Acceleration Fund that provides AWS credits to faculty and no-cost cloud services training available campus-wide. But researchers wanted something more: a structured, guided program that would build practical cloud skills around real research scenarios.

Introducing the AWS Research Skilling Accelerator

The AWS Research Skilling Accelerator (RSA) is a structured, 5-week, no-cost cloud skilling program designed specifically for health science researchers and research IT professionals at universities. Participants complete hands-on labs in AWS Workshop Studio built around authentic health science datasets and scenarios. The curriculum covers five progressive modules:

AI-powered research tools with Kiro – Participants use Kiro, an AI-powered integrated development environment (IDE), to explore agentic coding workflows purpose-built for accelerating research software development.
Machine learning model development with Amazon SageMaker – Researchers build, train, and deploy machine learning (ML) models using Amazon SageMaker, applying techniques like feature engineering and hyperparameter tuning to health science datasets.
Genomics research agents with Amazon Bedrock and Agents Strands SDK – Participants construct AI-powered research agents using Amazon Bedrock and the Strands Agents SDK to automate genomics literature review and data analysis tasks.
Cost optimization for research workloads – Participants focus on right-sizing compute resources, using Spot Instances, and using AWS cost management tools to maximize research budgets.
Specialized elective (medical image classification or high-performance compute bursting) – Researchers choose between building a medical image classification pipeline using deep learning on AWS or configuring hybrid high-performance compute (HPC) bursting to scale on-premises clusters into the cloud for computationally intensive simulations.

The program runs with two parallel tracks built for both researchers and research IT professionals so those doing the science and those supporting the infrastructure gain practical, directly applicable skills in tandem. Throughout the 5 weeks, participants engage with AWS Solutions Architects through discussion hours, dedicated communication channels, and hands-on program support. Those who complete all five assignments receive AWS promotional credits to continue exploring on their own.

FSU’s experience with the RSA

FSU was initially selected as a pilot school for the first RSA cohort in October 2025 with four participants, and then re-enrolled in the second cohort with double the typical enrollment, which is a testament to the university’s commitment to building cloud competency across its research enterprise. FSU RSA participants included both research IT and research participants who reported gaining skills they could immediately apply to their work.

When asked how the RSA has impacted researchers and research IT professionals at FSU, Breeze Howard, director of IT Infrastructure Services, responded, “The Research Skilling Accelerator has given FSU researchers a practical path to build cloud and AI skills they can apply directly to their work. Faculty have responded very positively to the program because it connects hands-on training with real research challenges and helps them move faster from idea to discovery.”

Balu Bhasuran, research faculty in FSU’s School of Information specializing in Clinical NLP and Machine Learning, shared their experience as a participant of the program: “The RSA helped me develop a scalable data analysis pipeline using Amazon SageMaker, enabling more efficient processing and analysis of research data. Working with Amazon Q and AWS Cost Builder was also a valuable experience, helping me better understand cloud-based development, resource planning, and cost management.”

Results that speak for themselves

Across two cohorts spanning 11 universities globally, the RSA has reached 102 active participants and delivered measurable outcomes:

NPS of 51, indicating strong participant advocacy (industry benchmark sits at 30 for education and training programs)
91% satisfaction (CSAT 4.5 out of 5)
72% full completion rate (percentage of active participants who completed all five assignments; industry benchmark sits at 15–25% for structured online learning cohorts)
25% increase in self-reported AWS comfort levels

AWS plans to begin its third cohort with a target of 30 institutions globally, including repeat participation from FSU and seven other R1 research universities across the US, Canada, and the UK.

A model for research cloud adoption

The RSA represents a scalable approach to closing the cloud skills gap in higher education research. By meeting researchers where they are with health science-specific scenarios, dual tracks for different roles, and ongoing expert support, the program builds confidence alongside competence.

If your university is interested in bringing the AWS RSA to your campus, contact the AWS Research Skilling Accelerator team at aws-rsa@amazon.com. Visit the AWS Public Sector Blog to explore how cloud computing is accelerating scientific discovery across disciplines.

One scan, many findings: Floy’s foundation model platform for opportunistic screening on AWS

Kenneth Schröder — Mon, 24 Aug 2026 14:18:01 +0000

Osteoporosis, cardiovascular disease, and neurodegenerative conditions affect tens of millions of Europeans, yet the majority go undiagnosed. Evidence of these conditions is often already visible on routine CT and MRI scans acquired for entirely different clinical questions, at no additional imaging, radiation, or cost. For example, 73 percent of women eligible for osteoporosis treatment in the EU’s six largest markets do not receive it (Borgström et al., Archives of Osteoporosis 2020), largely because formal assessment requires a dedicated dual-energy X-ray absorptiometry (DEXA) scan. Yet bone density loss is measurable on routine scans already being acquired.

These conditions go undetected not because the evidence is absent, but because no systematic process exists to look for them. With MRI exams in Germany alone totaling 13.5 million in 2023 (Eurostat Healthcare Resource Statistics 2023), this gap between what imaging data contains and what gets reported represents a population-scale public health opportunity. Closing it requires AI systems that are accurate, fast, and traceable end to end, not only for research rigor but for the regulatory audit trails mandated under EU MDR Class IIb medical device requirements

Opportunistic screening means analyzing scans already acquired for one clinical question to detect unrelated conditions at no extra cost or radiation to the patient. Making this systematic, in clinical routine, at scale, is the problem Floy was built to solve. Floy is a Munich-based medical AI company whose foundation model (FM)-based platform is deployed across more than 200 radiology practices in Germany, has processed over 100,000 studies, and handles hundreds of new scans daily. The platform returns structured AI reports within 5 minutes of image acquisition, routinely surfacing clinically relevant findings, including aneurysms with a 36.2 percent increased detection rate (Teodorescu et al., Journal of Stroke and Cerebrovascular Diseases 2024) and bone lesions detected 5.7 months earlier than by unassisted radiologists (Fritzsche, M., Kara-Schmidt, P., Kirchler, M., Schroeder, K., Wiedemeyer, C., & Braunschneider, L. E. (2026). Enabling earlier detection of spinal lesions in CT imaging with artificial intelligence—a case study. Frontiers in Artificial Intelligence, 9, 1767814). Built on Amazon Web Services (AWS) and certified up to EU MDR Class IIb, the platform combines large-scale self-supervised pre-training with the elastic, secure infrastructure required for regulated clinical deployment. In February 2025, Floy closed an extended seed round of €9 million.

This post describes how Floy built an FM-based AI platform on AWS, from training and inference to clinical integration, that scales to meet the demands of modern radiology.

The clinical challenge: Opportunistic screening at scale

When a patient undergoes an MRI of the head, the radiologist focuses on answering the referring physician’s clinical question. But the same scan might contain early indicators of Global Cortical Atrophy (GCA), Fazekas-graded white matter lesions, or other findings with significant long-term clinical implications. Catching these routinely, on every applicable study, requires consistent, quantitative analysis that can be difficult for humans to perform reliably under time pressure at volume.

Floy’s medical devices perform exactly this analysis automatically across head, shoulder, breast, thorax/abdomen, and knee imaging, triggered by a single click from the radiology information system (RIS). The platform retrieves applicable prior studies, preprocesses the imaging data, runs it through up to 14 AI models in the cloud, and delivers a structured report without requiring the radiologist to change their workflow.

The scale of this operation demands infrastructure that is simultaneously fast, elastic, cost-efficient, and compliant with stringent European medical device regulations. Floy built this capability on AWS.

Domain-specific foundation models: A platform for clinical AI

The core of Floy’s next-generation head products is an MR Head FM trained on more than 11 million MRI slices drawn from 175,000 head studies. Floy developed the research in collaboration with the German Cancer Research Center (DKFZ) as part of the Human Radiome Project.

Rather than build a separate model from scratch for each clinical question, Floy’s model learns a general understanding of brain MRI across scanners, protocols, and patient populations through self-supervised learning on hundreds of thousands of scans, with no manual annotation. The training method builds on Franca, an extension of the DINOv2 self-supervised learning paradigm, which Floy fine-tuned on large collections of radiology scans. The model learns to produce consistent internal representations from differently augmented views of the same scan, forcing it to capture what is anatomically meaningful rather than superficial pixel patterns.

The resulting Vision Transformer serves as a frozen base on which Floy trains lightweight, task-specific classifiers. The FM itself never changes; only the thin layer on top does. This is what makes the approach a platform rather than a product.

The following diagram illustrates the FM training pipeline.

Figure 1: Foundation model training pipeline: A single self-supervised base encoder (center) is fine-tuned into multiple EU MDR-certified medical devices (right) from small annotated datasets (left)

The payoff is both technical and clinical: on internal benchmarks, the approach improved average performance by 3.3 percent and cut training time by roughly 94 percent compared to classical 3D convolutional neural networks. Because the shared base is reused, a new indication can move from research to clinical deployment in a fraction of the time previously required, meaning patients gain access to new detection capabilities sooner.

The MLOps stack: Valohai and AWS

Fast iteration in a regulated environment requires full traceability from annotation to deployment. All data processing, model training, and evaluation runs on Valohai, a machine learning operations (MLOps) platform connected to Floy’s AWS data stores and GPU compute. Valohai operates on a split architecture: its management control plane is a hosted software as a service (SaaS) offering on AWS, and the data and compute plane runs entirely inside Floy’s private AWS account.

Every experiment is fully traceable from data ingestion to final evaluation, a requirement not only for research rigor but for the regulatory audit trails required under EU MDR.

Floy’s team produces training annotations on Encord and exports them directly to Valohai for processing. The development environments use custom Docker images with shared base images across all execution contexts (Valohai training jobs, local devcontainers, and production inference), so the model seen in evaluation is the model that runs in the clinic.

The integration architecture: From PACS to report in 5 minutes

Foundation model performance is necessary but not sufficient for clinical adoption. One of the harder problems is getting AI results into the clinical workflow reliably, automatically, and fast enough to be useful before the radiologist has moved on to the next case.

A single click from the radiologist’s RIS triggers the entire Floy workflow. A local integration component retrieves the new study and applicable prior exams from the Picture Archiving and Communication System (PACS) while acquisition is still underway, adaptively beginning processing as soon as sufficient data is available and reducing wait times by up to 50 percent. A local AI-based filter evaluates more than 30 metadata tags to determine which medical device modules apply.

The pipeline uploads preprocessed Digital Imaging and Communications in Medicine (DICOM) data to Amazon Simple Storage Service (Amazon S3) and hands it off to Floy’s cloud-based pipeline. Fourteen AI models run on GPU-accelerated Amazon Elastic Compute Cloud (Amazon EC2) G5 instances. A custom Amazon Simple Queue Service (Amazon SQS) driven AWS Lambda function automatically scales the fleet based on queue depth and time-based scheduling, scaling to zero overnight for cost-efficiency. Floy deploys additional services as Amazon Elastic Container Service (Amazon ECS) on AWS Fargate tasks, with a Kong API Gateway handling routing and a FastAPI-based backend managing business logic. The full pipeline completes in approximately 5 minutes, with real-time status updates streamed to the clinician throughout.

Amazon Relational Database Service (Amazon RDS) for PostgreSQL stores the processing metadata, including automatically issued Unique Device Identification (UDI) labels and model version numbers for every study, providing the audit trail required under EU MDR.

The following diagram illustrates the solution architecture.

Floy’s AWS infrastructure satisfies EU MDR Class IIb and ISO 13485 requirements at every layer, combining end-to-end encryption, least-privilege access controls, and continuous compliance monitoring.

Looking ahead

Today, Floy’s platform processes hundreds of studies daily across more than 200 radiology practices. To date, it has analyzed more than 100,000 studies, each representing a patient who received systematic opportunistic screening without an additional appointment, scan, or radiation dose.

Floy has already extended its FM approach beyond head imaging. An MR Knee FM now powers automated ICRS grading of cartilage, and the same self-supervised pre-training approach is being applied to bone mineral density products to improve accuracy and accelerate the path to new use cases.

Conclusion

Floy’s FM-based AI platform on AWS scales to meet the demands of modern radiology, supporting a pipeline from training and inference to clinical integration.

To learn more about how AWS supports healthcare and life sciences organizations, visit AWS Health. To explore how Floy is transforming radiology with opportunistic screening, visit floy.com.

To learn more about how other imaging HealthTechs are using AWS, check out the following resources: