AWS Public Sector Blog

Can AI Help Our Cities Beat the Heat? Inside the University of Michigan’s AI for Urban Heat Resilience Hackathon

Chris Edwards — Tue, 09 Jun 2026 15:09:06 +0000

Extreme heat is now the leading weather-related cause of death in the United States. In 2023, heat claimed over 2,300 lives, the highest number in 45 years of records, according to an Associated Press analysis of CDC data. Heat-related deaths have risen 117 percent since 1999 (JAMA), and the economic toll reaches an estimated $220 billion annually in lost U.S. productivity (Duke University Nicholas Institute). The burden falls disproportionately on low-income communities, older adults, outdoor workers, and residents of dense urban environments with little tree canopy or green space.

Yet urban heat remains one of the most data-poor problems in public health. Publicly available satellite thermal imagery — the most widely accessible — have low spatial and temporal resolution. For example, the harmonization of surface reflectance data from NASA’s Landsat and European Space Agency’s Sentinel-2 satellites produces a spatial resolution of about 30m and provides a temporal resolution of ~1.6 days. That’s useful regionally, but far too coarse and sparse for the street-level planning decisions that actually shape heat exposure in neighborhoods. Though commercial satellite systems such as SatVu have thermal sensors that can achieve up to 3.5m resolution and with multiple scans (10-20 revisits per day) of the earth’s surface, this comes at high cost.

This spring, AWS partnered with the University of Michigan’s Center for Global Health Equity (CGHE), the Michigan Institute for Data & AI in Society (MIDAS), SmithGroup, and Ecosystems, Finance and Health (EFH) to co-sponsor the AI for Urban Heat Resilience Hackathon — a two-day event built around a deceptively simple question: Can machine learning generate thermal imagery from standard RGB photographs?

If yes, urban heat mapping becomes feasible at a scale and cost currently out of reach for most cities and research groups worldwide.

Why We Got Involved

As an AWS team supporting higher education, we see firsthand how universities are tackling society’s hardest problems — but often face infrastructure constraints that slow the pace of discovery. When the University of Michigan approached us about this hackathon, the opportunity was clear: a real-world public health challenge, a strong AI/ML use case, and a chance to put cloud-scale compute directly in the hands of researchers and students working on something that matters. This is exactly the kind of collaboration we believe in.

The Urban Heat Island Effect

The urban heat island (UHI) effect is a predictable consequence of how cities are built. Low-albedo surfaces, anthropogenic heat from HVAC and traffic, and the thermal mass of concrete and asphalt absorb heat by day and release it after sunset. The result: urban areas can be 1–7°F warmer than surrounding areas during the day, and up to 22°F warmer at night (EPA Heat Island Resource Center).

As Verrah Otiende, Eric and Wendy Schmidt AI in Science African Faculty Fellow at the University of Michigan and hackathon co-lead, put it:

“The communities most exposed to urban heat are often the least represented in the data we use to study it. This hackathon pushed us to build tools that are technically rigorous and genuinely useful to the people who need them most.”

For lower-income countries, the picture is grimmer — higher vulnerability, fewer protections, and a heat burden that already outstrips existing resources. Mapping that risk at a useful scale, neighborhood by neighborhood, remains technically difficult. That’s where AI and cloud computing come in.

The Challenge: RGB to Thermal at Street-Level Resolution

The hackathon was led by Geoffrey Siwo (Research Assistant Professor, Department of Learning Health Sciences and Pharmacology; AI Lead CGHE) and Verrah Otiende, who shaped both its technical direction and its commitment to equitable design. Siwo framed the core insight: RGB cameras are universal. If a model can reliably infer thermal information from standard color imagery, the barrier to high-resolution urban heat mapping drops dramatically.

“Urban heat is a public health crisis that we can now address with the tools of modern AI — but only if we build those tools with the communities most at risk in mind.” — Geoffrey Siwo

The dataset included 468 paired RGB and thermal drone images from Ann Arbor, MI, supplemented with satellite embeddings, GPS coordinates, timestamps, and weather variables. Teams were evaluated on a held-out test set of 202 images using Peak Signal-to-Noise Ratio (PSNR), Structural Similarity Index (SSI), and Learned Perceptual Patch Similarity (LPIPS).

Keenan Gibbons, a landscape architect at SmithGroup and University of Michigan faculty member, provided the applied research context. His work uses UAV-mounted thermal cameras to map streetscapes at sub-centimeter resolution — orders of magnitude finer than satellite data.

“High-resolution thermal data enables an evidence-based approach to urban design — one where the thermal performance of a proposed intervention can be modeled before construction begins.” — Keenan Gibbons

How AWS Powered the Research

AWS provided investment, technical guidance, and cloud infrastructure to support hackathon teams. Participants used Amazon SageMaker for model training and experimentation and Amazon Bedrock for generative AI capabilities — giving researchers access to the same enterprise-grade tools used by organizations worldwide to build, train, and deploy ML models at scale.

By removing infrastructure barriers, researchers could focus on the science — iterating faster on the complex modeling challenges that problems like urban heat demand.

What the Teams Built — and What They Found

Teams pursued three broad technical strategies:

Conditional U-Net — Encoder-decoder architectures with auxiliary conditioning inputs (land cover, temperature, drone metadata) injected at the bottleneck to improve spatial feature learning.

Pix2Pix (Conditional GAN) — Image-to-image translation using a conditional generative adversarial network, with a discriminator supervising output realism alongside reconstruction loss.

Cross-Sensor Alignment — Preprocessing pipelines addressing the modality gap between RGB and thermal sensors through edge-detection-based feature matching, scale correction, and viewpoint alignment.

Key findings:

The most consistent challenge was spatial structure preservation — predicted thermal maps frequently lost structural correspondence with ground-truth scans, blurring boundaries between impervious and vegetated surfaces even in well-tuned architectures.

Performance varied with land cover composition: scenes with strong material contrast (impervious vs. vegetated) scored better than structurally homogeneous scenes — an important insight for real-world deployment across diverse urban environments.

Results suggest the problem is partially inherent to the signal mismatch between RGB and thermal sensors, pointing toward multi-modal fusion approaches as a promising next direction.

These findings don’t represent a dead end — they represent a research frontier. The hackathon demonstrated that RGB-to-thermal translation is achievable, while clearly mapping the technical challenges that remain.

A Model for University-Industry Collaboration

This hackathon demonstrates what becomes possible when research universities and AWS work together on problems that matter. The University of Michigan brought domain expertise, research infrastructure, and a commitment to equitable design. AWS brought scalable AI/ML services, technical guidance, and investment to help researchers push boundaries.

What’s Next

The research doesn’t stop here. The University of Michigan team is exploring expanded datasets across additional cities and climates, model architectures that better preserve spatial structure, and pathways to make these tools accessible to urban planners and public health practitioners globally. AWS remains committed to supporting this work as it moves from hackathon prototype toward real-world application.

Urban heat is a solvable problem. The data gap is real, but it is closing — and AI, powered by cloud infrastructure, is accelerating that progress.

Figure 1: Photo of the best performing team – GeoHeat-AI presenting the results of their approach.

Production-ready in months: AWS Partners deliver agentic AI solutions for public sector

Jasmine Thakkar — Tue, 09 Jun 2026 00:15:01 +0000

Tags: Artificial Intelligence, Partner Solutions, Public Sector, Public Sector Partners

Citizens expect faster responses. Clinicians need time back for patient care. Students need personalized support at scale. The public sector’s appetite for AI that can reason, decide, and act is surging—89% of public sector IT leaders say AI adoption is important to their mission, yet many public sector organizations remain in the earliest stages of AI maturity, with skills gaps cited as the primary barrier to deploying agentic AI at scale.

The AWS Partner Transformation Program (PTP) agentic AI module was built to help AWS Partners move from idea to deployed solutions faster and with the technical depth and governance frameworks that public sector customers require.

As the following partner stories demonstrate, partners completing the module are achieving 50–80% reductions in solution delivery timelines, creating multifold increases in qualified AI opportunities, and deploying AI agents that handle everything from multilingual citizen services to complex regulatory document analysis. These aren’t proofs of concept (POCs) sitting on a shelf, they’re production systems serving real public sector customers today.

“We’re not just teaching partners about agentic AI, we’re helping them build real solutions that solve real problems for government agencies, healthcare systems, and educational institutions.” — Troy Anderson, Sr. Manager, Partner Programs, AWS Worldwide Public Sector

How partners are building agentic AI solutions

The PTP agentic AI module offers two pathways designed around where partners are in their journey and what their customers need. The Foundational Path helps partners identify and prioritize high-impact agentic AI use cases, develop strategic insights through design thinking, and build a functional proof of concept, which is ideal for partners whose customers are exploring how agentic AI can address operational challenges. The Solution Development Path is built for partners that have already experimented with agentic AI and are ready to build production-grade autonomous agents, accelerating them into production using Amazon Web Services (AWS) services such as Amazon Bedrock AgentCore and Strands Agents SDK.

Partners receive one-on-one personalized sessions with an AWS qualified transformation consultant (an expert third-party consultant), along with AWS sandbox credits and AWS Marketplace listing guidance to scale their solutions and reach more customers.

“Partners aren’t just learning AgentCore and the Strands Agents SDK, they’re building production-grade AI solutions with governance, observability, security, and compliance engineered in from day one. That’s the standard public sector customers demand, and it’s exactly what our partners are delivering.” — Jeff Wright, Director of Partner Solutions Architecture, AWS Worldwide Public Sector

The PTP agentic AI module is structured as 10-person workshops delivered over a 60–90 day timeline, guided by a dedicated transformation consultant, with AWS sandbox credits provided for hands-on building. Partners begin by identifying a customer challenge, such as government response times, healthcare administrative burden, education scalability, or compliance requirements, and follow either the Foundational Path or the Solution Development Path. The module is built on Amazon Bedrock, Amazon Bedrock AgentCore, Strands Agents SDK, and Amazon Nova Act. Production outcomes include 50–80% faster delivery, deployed AI agents, AWS Marketplace listing, repeatable solutions, and measurable customer impact.

The following graphic summarizes this end-to-end flow.

Figure 1: AWS PTP agentic AI module

Grupo TX: From AI experimentation to a production-ready agent solution for government

For partners with deep public sector expertise, the emergence of agentic AI presents both an opportunity and a challenge. The technology is evolving rapidly, customers are asking for AI-powered solutions, and partners need a structured path from experimentation to production.

Grupo TX, an AWS Advanced Tier Services Partner, has built a strong reputation in government modernization across Latin America. But as their customers began requesting AI-powered automation and intelligent service agents, Grupo TX identified critical gaps in their ability to respond:

Limited internal experience designing agentic AI architectures using Amazon Bedrock and related AWS AI services
Difficulty identifying high-impact, monetizable use cases within government and education sectors
No structured AI solution development methodology, from ideation through production deployment
Need to differentiate in a competitive Latin American public sector services market

These gaps slowed Grupo TX’s ability to respond to agentic AI–related requests for proposal (RFPs), limited their pipeline generation, and constrained their positioning as a strategic innovation partner.

“We had the relationships and the domain expertise, but we needed a framework to turn AI concepts into deployable products.” — Carlos González, CEO, Grupo Tx

Through the AWS PTP agentic AI module, AWS transformation consultant, EDT Partners guided Grupo TX through a structured transformation—from AI exploration to a production-ready solution and go-to-market plan. The team identified a high-impact use case: an AI-powered citizen services agent for state and municipal government agencies. The solution, TxGov Agent, was architected on Amazon Bedrock for foundation models (FMs), Amazon Bedrock AgentCore for workflow orchestration, and Strands Agents SDK for agent behavior logic.

Government agencies can use TxGov Agent to automate citizen inquiries, provide accurate policy-based responses in Spanish, and orchestrate service workflows through a secure, cloud-based architecture, with full conversation traceability and escalation to human operators when needed.

Within 6 months of completing the module, Grupo Tx achieved the following impacts on business growth and citizen impact.

Business growth:

9 times increase in qualified AI opportunities
55% faster time to market for custom AI development (9 months to 4 months)
40% reduction in POC development time

Citizen impact:

35% reduction in call-center volume for their government customer
50% faster citizen response time (on average from 48 hours to 24 hours)
92% citizen satisfaction score

Grupo TX established a dedicated AI and agentic solutions practice with six trained specialists and is now pursuing an AWS Marketplace listing for TxGov Agent to bring the solution to more government agencies across the region.

“We moved from conceptual discussions about generative AI to deploying a production-grade agentic solution for a government customer in less than 6 months, positioning Grupo TX as a leader in AI-driven public sector modernization.” — Carlos González, CEO, Grupo TX

ELAD Software Systems: Scaling consulting delivery to serve more public sector customers

ELAD Software Systems, an AWS Advanced Tier Services Partner in EMEA, was hitting a common consulting bottleneck: their teams had the expertise, but not the capacity. AI proofs of concept were taking months, and document-heavy deliverables were consuming weeks of consultant time.

Through the PTP agentic AI module, ELAD designed and built an enterprise multi-agent AI platform on Amazon Bedrock and the Strands Agents framework. The platform deploys specialized AI agents that autonomously generate documents, design AWS architectures, analyze data, and query knowledge bases through a unified, secure interface that meets public sector governance requirements.

As a result, ELAD software systems can now serve more public sector customers, faster, without proportional headcount increases, achieving measurable impact from build to business outcome.

Delivery speed:

82% faster AI POC delivery time (4 months to 3 weeks)
65% reduction in POC build time through reusable Amazon Bedrock AgentCore scaffolding
40% faster time to market overall

Operational efficiency:

75–90% reduction in document authoring time for statements of work (SOWs) and architecture summaries
7 production-ready AI agent solutions built and deployable across multiple verticals

Business growth:

35% year-over-year professional services revenue growth
Serving more public sector customers without proportional headcount increases

“Through the PTP program and the agentic AI module, we’ve been able to operationalize our vision of scaling intelligence, not just headcount, by building a structured approach to deploying digital employees at scale.” — Gal Vekselman, Chief AI Officer, ELAD Software Systems

More partners solving public sector challenges with agentic AI

The momentum extends across multiple regions, with partners building solutions that address specific public sector pain points:

SoftwareOne (formerly Crayon) tackled a citizen access challenge for Kyiv Municipality, replacing a costly 500 GB static storage system with a live-web grounded AI agent that delivers multilingual citizen services in Ukrainian, Russian, and English. The solution achieved over 95% storage reduction while providing around-the-clock citizen access to municipal information. They went from concept to functional minimum viable product (MVP) in only 50 days.
Amber, an AWS Advanced Tier Partner operating across Peru and the United States, built TARS, a multi-agent AI operations platform and launched Amber Ignite, a productized consulting program that helps enterprise clients adopt agentic AI capabilities. They created multiple qualified agentic AI opportunities within 4 months of program completion, addressing automation needs across government and business operations.

What public sector challenges could agentic AI solve for your customers?

Every partner in this program started with a customer problem:

Citizens waiting days for government responses that should take minutes
Healthcare staff spending more time on documentation than patient care
Consulting teams unable to scale delivery to meet growing public sector demand
Educational institutions struggling to provide personalized support at scale

The PTP agentic AI module is available globally to AWS Services and Technology Partners serving public sector customers. Partners who complete the program can also publish their newly deployed solutions to the AI Agent and Tools solution page in AWS Marketplace, extending their reach to customers across the public sector.

Get started

The PTP agentic AI module is available at no cost to qualified AWS Partners. The partners featured in this post began by identifying a customer challenge and engaging their AWS Partner account manager or distributor—within months, they were deploying production-ready solutions transforming how public sector organizations operate.

To be eligible, AWS Partners must meet the following requirements:

AWS Select Tier Services or validated AWS Partner Network (APN) Tier or higher
Executive commitment for program participation
AWS Partner account manager or AWS Distributor nomination for the program

Ready to start your agentic AI journey? Register your interest in the PTP agentic AI module to connect with the program team. Your AWS Partner account manager or AWS distributor can also submit a nomination on your behalf.

Accelerating cloud-powered cybersecurity learning with IBM Cyber Campus and AWS

Shawn Reynolds — Sun, 07 Jun 2026 20:48:09 +0000

The cybersecurity industry faces a historic workforce challenge. The global cybersecurity workforce gap exceeds 4.8 million unfilled positions, with roughly 67% of organizations actively reporting severe staffing shortages. (StationX, May, 2026) With cybersecurity jobs projected to grow 33% this decade, colleges and universities must evolve rapidly to prepare the next generation of defenders.

IBM Cyber Campus, powered by Amazon Web Services (AWS) and platformed by Cloud Range and Cyviz, addresses the challenge. This cloud-powered solution combines the cybersecurity expertise of IBM with the global cloud infrastructure of AWS to deliver scalable, immersive cyber training experiences that mirror the pace and complexity of real-world defense.

Cybersecurity education that meets workforce realities

IBM and AWS, along with Cloud Range and Cyviz, share a common mission: building the cyber workforce required to secure the world’s critical systems. This collaboration brings together IBM’s decades of leadership in cybersecurity innovation with AWS infrastructure agility and reach.

The IBM Cyber Campus uses the AWS secure, elastic cloud infrastructure to enable institutions to deploy fully operational security operations center (SOC) training environments without costly hardware investments. In partnership with Cloud Range and Cyviz, IBM delivers an immersive, cloud-enabled learning experience that combines real-world incident response simulations, analytics-driven learning paths, and collaborative visualization environments aligned with NICE and National Institute of Standards and Technology (NIST) frameworks. This education-to-workforce model establishes a training ground for advanced cybersecurity education, equipping students with hands-on experience defending live cyberattacks and accelerating the development of a skilled, job-ready cybersecurity talent pipeline.

Cloud-enabled learning without limits

IBM Cyber Campus was built to meet the demands of modern cybersecurity education at scale—a globally available platform capable of running multiple simultaneous labs, supporting entire classrooms concurrently and expanding instantly as enrollment grows. AWS delivers the foundational infrastructure that makes this possible:

Amazon Elastic Kubernetes Service (Amazon EKS) and Amazon Elastic Compute Cloud (Amazon EC2) work in concert to power the platform’s compute backbone. Amazon EKS orchestrates containerized lab environments across the cluster, and Amazon EC2 provides the underlying dedicated compute capacity that provisions isolated virtual machines for every student, enabling dozens of parallel, hands-on labs to run simultaneously without performance degradation or resource contention.
Amazon Elastic File System (Amazon EFS) and Amazon Elastic Block Store (Amazon EBS) deliver a fully managed, layered storage foundation. Amazon EFS provides a shared file system accessible across all student sessions for lab materials and configurations, and Amazon EBS supplies high performance block storage attached directly to each compute instance for fast, consistent I/O during active exercises.
AWS Auto Scaling enables the platform to dynamically adjust compute capacity in response to classroom demand—whether onboarding a single cohort or running institution-wide training events—eliminating over-provisioning costs while providing consistent performance at scale.

This architecture removes the need for on-premises infrastructure while preserving enterprise-grade security and operational control. Instructors gain a fully managed environment to design and deploy live, cloud-based SOC and incident-response simulations, enabling entire classrooms to experience cyber defense in action, simultaneously, at scale.

A workforce-ready learning model

IBM Cyber Campus fundamentally transforms how cybersecurity is taught in higher education. It doesn’t replace traditional labs that build foundational skills. The Cyber Campus extends learning beyond the lab environment to deliver career-level experience through live, cloud-powered environments where students practice, adapt, and perform like real cybersecurity professionals. Students train on the same enterprise tools—security information and event management (SIEM), intrusion detection systems (IDSs), and analytics platforms—used across the commercial and government sectors.

IBM Cyber Campus recently released the Range 2.0 platform, which delivers concurrent, cloud-powered cybersecurity training with unlimited scalability. It operates as a live, enterprise-grade SOC and includes an extensive commercial catalog of current cyberattack simulations. The scalable architecture supports unlimited simulations and unlimited learners, enabling continuous, parallel hands-on experiences across courses, institutions, educational systems, and states.

Expanding access to cyber education

The IBM Cyber Campus initiative is a strategy to strengthen economies by building cyber talent pipelines, enhancing local workforce readiness, and fostering innovative systems that attract investment and create jobs across industries. By combining IBM cybersecurity consulting, AWS elastic infrastructure, Cloud Range scenario technology, and Cyviz visualization environments, the Cyber Campus delivers a comprehensive, repeatable, cloud-based learning model for academic and workforce development programs worldwide.

For institutions, this model removes cost and complexity barriers. For employers, it builds stronger pipelines and job-ready talent. And for students, it opens the door to real-world cybersecurity experience—available anytime, anywhere, in the cloud.

The Full Sail University IBM cyber defense range powered by AWS and Cloud Range

Full Sail University, located in Winter Park, Florida, recently opened its IBM cyber defense range powered by AWS and Cloud Range. The range is a new campus facility that will help Full Sail’s emerging technologies students gain hands-on experience with the tools and techniques used by professionals in the cybersecurity industry.

In the cyber defense range, students in the Cybersecurity Bachelor of Science Completion Program and the Information Technology Bachelor’s program will experience a simulated cyber environment to safely practice defending networks, responding to cyber incidents and testing security tools without risk to live systems. They can participate in live attack-and-defense exercises, conduct incident response practices, and more. This live scenario training provides Full Sail students with the technical expertise, critical thinking, and collaborative capabilities required in today’s complex security environment.

Shaping the next generation of cyber defenders

IBM Cyber Campus continues to evolve by introducing new modules focused on AI, quantum security, and protection for operational technology (OT) and Internet of Things (IoT). Future initiatives will extend learning pathways into K12 settings, shaping early awareness and expanding diversity in cybersecurity.

“This collaboration modernizes cybersecurity education by giving students hands-on, orchestrated training,” said Shawn Reynolds, IBM Cyber Campus Offering Manager. “We’re transforming classrooms into live cyber ranges—building talent with the skills needed to help make the world more secure.”

Learn how AWS helps institutions build solutions that address cybersecurity education needs. Contact AWS today.

Read related stories on the AWS Public Sector Blog

AWS GovCloud (US) account management best practices

Brian Dao — Wed, 03 Jun 2026 18:33:49 +0000

Introduction

AWS GovCloud (US) was purpose-built for US government agencies and contractors handling sensitive data under frameworks like FedRAMP High, DoD SRG, ITAR, and CJIS. This specialized environment comes with unique account management challenges. From US person staffing requirements to enhanced audit trails, organizations working in the AWS GovCloud (US) partition must rethink traditional AWS account approaches to successfully balance stringent security requirements with operational efficiency.

Without proper account management practices in place, organizations risk compliance violations, unauthorized access to sensitive data, audit failures, and operational disruptions that can jeopardize mission-critical workloads. These risks are amplified in AWS GovCloud (US), where the dual-partition account structure, separate authentication systems, and unique credential model introduce complexity that standard AWS guidance doesn’t fully address.

In this post, we explore the essential best practices for AWS GovCloud (US) account management and avoid common pitfalls. By following these practices, you can reduce compliance risk and streamline operations across your AWS GovCloud (US) environments.

Understanding AWS GovCloud (US) Account Structure

AWS GovCloud (US) operates as a separate partition from the AWS commercial partition. Accounts, resources, and services exist in isolated environments that can’t directly communicate across partition boundaries. One exception is that for every AWS GovCloud (US) account, there is a standard account associated with it. So, when you create an AWS GovCloud (US) account, you get two accounts:

AWS GovCloud (US) account – An AWS account created within the isolated AWS GovCloud (US) partition, designed specifically for US government agencies and contractors to handle sensitive data under strict compliance frameworks. It operates in a physically and logically separated environment with enhanced security controls and US person staffing requirements to meet government regulatory requirements.
Standard account – An AWS account created in the commercial partition, often referred to as the associated commercial account. The standard account has its own credentials and is linked to the AWS GovCloud (US) account for billing purposes and, most importantly, can be used to recover access to the AWS GovCloud (US) account.

You can run workloads in the standard account; however, we recommend that you limit the standard account’s use to billing, AWS GovCloud (US) account access recovery, and actions that require root user privileges. Don’t deploy workloads in it. This architectural separation keeps sensitive government data within the compliance boundaries of the AWS GovCloud (US) partition while enabling cost management and account governance through commercial AWS tools.

Figure 1: One-to-one mapping between a standard account and AWS GovCloud (US) account. Never run workloads in Standard Accounts A or B.

The one-to-one relationship between the AWS GovCloud (US) account and the standard account can’t be broken. You can’t unlink the two accounts after they are created. This means you can’t have an AWS GovCloud (US) account without its associated standard account in the commercial partition, and you can’t reassociate the AWS GovCloud (US) account to another standard account.

Authentication and access management systems are separate between commercial and AWS GovCloud (US) partitions, meaning access control mechanisms like AWS Identity and Access Management (IAM) users, roles, and policies created in one partition can’t be used to access resources in the other. Similarly, AWS Organizations structures — including organizational units (OUs) and service control policies (SCPs) — are partition-specific and must be configured independently in each partition. You must implement independent identity management, access control, and organizational governance for each partition to secure the accounts.

Account Creation

There are three ways to create an AWS GovCloud (US) account, and they all begin with a standard account. For detailed instructions, see Creating an AWS GovCloud (US) account. The following is a high-level summary of the three methods:

Method 1: Sign in as root user – Sign in to the standard account using root user credentials (email and password). From there you can sign up for an AWS GovCloud (US) account. If this process fails (for example, due to eligibility or verification requirements), contact AWS Support for assistance, as described in Method 2.
Method 2: Open a support case or ticket – If you are working with an AWS Partner or Reseller, open a ticket with them for assistance; otherwise, open a support case directly with the AWS Account & Billing Team and request an AWS GovCloud (US) account.
Method 3: Use AWS Organizations APIs – Use the AWS Organizations APIs to programmatically create an AWS GovCloud (US) account. This requires an AWS organization to be created, and you have access to the management account in the commercial partition. Additionally, you need to have an AWS GovCloud (US) account created (using either of the previous methods) from the management account of the commercial organization. You will need to supply a unique email address, which will be used as the username for each new standard account. Refer to Automate AWS GovCloud (US) account creation using AWS Organizations APIs if you want to automate this process.

Credentials Management

As mentioned previously, a new AWS GovCloud (US) account also comes with a new standard account. That means you will need to manage two sets of credentials, one for each account. The following table summarizes the details.

Credentials management	Standard Account	AWS GovCloud (US) Account
Root user (email/password)	Yes	No
Root credentials (access keys)	Yes	Yes
Console sign-in	Root or IAM	IAM only
Default IAM role (org-created)	OrganizationAccountAccessRole	OrganizationAccountAccessRole

Figure 2: Differences between credentials for standard account and AWS GovCloud (US) account

Standard Account

A standard account uses the following credentials:

Root user credentials – This is the email and password used to sign in to the AWS Management Console. If you create the AWS GovCloud (US) account using Method 2, you should have the credentials. If you use Method 3, the username is the email address you supplied, but the password isn’t created. If you need the password, you will need to perform a password recovery.
IAM role – When you use Method 3 to create the AWS GovCloud (US) account, AWS creates an IAM role named OrganizationAccountAccessRole (or a custom role name you provided) in the new standard account. You can use it to access the new account using assume role from the management account.

AWS GovCloud (US) Account

Depending on the method you use to create the AWS GovCloud (US) account and onboard it, you might have root credentials, an administrator user, or an IAM role that you can use for initial access to the account:

Root credentials – An AWS GovCloud (US) account doesn’t support root user console access (email and password). Instead, it uses root credentials, which comprise an access key and a secret access key. Root credentials can’t be used to sign in to the AWS GovCloud (US) Management Console. Instead, you can use the root credentials to onboard the account and manually create an administrator user. You can also use the root credentials with the AWS Command Line Interface (AWS CLI) or AWS Software Development Kits (SDKs). After onboarding, either delete the root credentials or lock them in a secure, auditable location with strictly limited access.
Administrator user – When you onboard the account using root credentials, AWS creates an IAM user with full administrator access named Administrator and a password. You can sign in to the AWS GovCloud (US) Management Console with it just like other IAM users.
IAM role – When you create the AWS GovCloud (US) account using Method 3, AWS creates an IAM role named OrganizationAccountAccessRole (or a custom role name you provided) in the new AWS GovCloud (US) account. You can use it to access the new account using assume role from the AWS GovCloud (US) account associated with the management account in the commercial partition.

The following diagram illustrates this setup.

Figure 3: Use assume role to gain access to newly created accounts (dashed blue lines represent one-to-one links)

Initial Account Configurations

After you gain access to the accounts, you should immediately perform initial configuration to secure the accounts, such as creating IAM users or roles, enabling multi-factor authentication (MFA), and configuring single sign-on (SSO). If you are using AWS Organizations, you should invite the new accounts to their respective organizations.

When the initial configuration is complete, store the root credentials in a safe, auditable location with restricted access. Certain organizations might require the root credentials to be deleted after proper access control mechanisms have been implemented for the accounts. Root credentials can only be deleted programmatically and not using the AWS console.

AWS automatically enables AWS CloudTrail for new AWS GovCloud (US) accounts and records global service events in the us-gov-west-1 AWS Region. Review your CloudTrail configuration and adjust it to align with your security requirements; specifically, check for duplicate trails, because they can lead to unexpected costs.

Additional Account Configurations

After initial access and configurations are complete, the next step is establishing a security and governance baseline. The following AWS services should be enabled and configured as part of your account onboarding process—not as an afterthought. Together, they form the foundation for continuous compliance monitoring, threat detection, and audit readiness that government workloads demand. Although not every service may be required for your specific compliance framework, the following list represents the recommended baseline for most AWS GovCloud (US) organizations:

AWS Backup – Implement centralized backup policies across accounts to automate data protection for critical resources such as Amazon Elastic Block Store (Amazon EBS) volumes, Amazon Relational Database Service (Amazon RDS) databases, Amazon DynamoDB tables, and Amazon Elastic File System (Amazon EFS) file systems.
AWS CloudTrail – Enable CloudTrail in Regions immediately upon account creation so that API calls, console actions, and service events are logged to a centralized, tamper-evident location with appropriate retention periods.
Amazon CloudWatch – Deploy comprehensive monitoring and alerting across accounts with centralized log aggregation, custom metrics for security events, and automated responses to threshold breaches with appropriate retention policies for audit requirements.
AWS Config – Configure AWS Config to continuously monitor resource configurations against compliance baselines, setting up rules that align with your specific compliance frameworks like FedRAMP or DoD SRG requirements.
Amazon EventBridge – Establish event-driven security automation by routing security-related events from AWS services to automated response workflows, enabling real-time incident response and compliance monitoring across the organization. Route events from linked accounts to a centralized account for processing.
Amazon GuardDuty – Implement GuardDuty across accounts for continuous threat detection and malicious activity monitoring, with centralized findings management and automated response workflows for high-severity security events.
AWS IAM Identity Center – Implement centralized identity management with SSO across AWS accounts, enforcing MFA and role-based access controls.
AWS Key Management Service (AWS KMS) – Establish account-level encryption policies that mandate encryption at rest and in transit for data with customer managed keys when required by your compliance framework.
Amazon Organizations – Implement AWS Organizations in both the commercial and AWS GovCloud (US) partitions to centrally manage and govern your accounts at scale. Structure organizational units (OUs) to reflect your agency’s hierarchy, workload classifications, or security boundaries and enabling consistent policy enforcement.
AWS Organizations SCPs – Implement Service Control Policies (SCPs) to prevent the disabling of security services and enforce baseline security configurations across member accounts to include protecting critical resources from accidental deletions.
AWS Security Hub – Implement Security Hub as a centralized dashboard to aggregate, prioritize, and manage security findings across accounts. Enable compliance standards aligned with your regulatory requirements, such as NIST 800-53 or CIS AWS Foundations Benchmark, and configure automated workflows to route critical findings to the appropriate teams for remediation.
VPC Flow Logs – Enable across virtual private clouds (VPCs) and subnets to capture network traffic metadata and stream to a dedicated security account with centralized storage to capture and retain account-level activities for security analysis, compliance auditing, and network troubleshooting.

In addition to these configurations, consider the following additional best practices when setting up a new organization:

Management account – Reserve for governance and billing only. Don’t deploy workloads in it and restrict access to a small group of trusted administrators.
Member accounts – Create dedicated accounts per workload or environment and automate provisioning with AWS Organizations APIs to maintain consistent security baselines.

For detailed guidance, see Best practices for a multi-account environment.

Account Contact Information

AWS GovCloud (US) accounts don’t have their own contact information. Contact information, including email, phone, and alternate email contacts (for example, Security, Billing, and Operations), is configured in the associated standard account.

Email addresses – Designate a Non-Person Entity (NPE) mailbox for each email address tied to the account so AWS updates are received in a timely manner. Multiple authorized personnel should monitor each NPE mailbox, with clear escalation procedures in place. This approach maintains continuity during personnel changes, leave periods, or emergencies common in government environments due to staff rotations or deployments.
Phone number – Make sure each account has a direct phone number listed. Don’t use a switchboard number or line that is routed through a receptionist. Having a valid, direct phone number is critical for account verification and recovery processes but often overlooked. Password reset for standard account relies on both a valid email and phone number.

Establish a regular review process to verify that contact information remains current, mailboxes are actively monitored, and personnel accessing these accounts maintain appropriate authorization and security requirements to handle account information.

Conclusion

Managing AWS GovCloud (US) accounts requires a deliberate, disciplined approach that goes beyond standard AWS account management practices. The unique characteristics of the AWS GovCloud (US) partition—one-to-one account relationship with the commercial partition, separate authentication systems, and root credential handling—demand that organizations plan carefully and establish strong operational foundations from day one.

To recap the key takeaways from this post:

Understand the account structure – Every AWS GovCloud (US) account comes with an associated standard account. Manage both but keep commercial workloads out of the associated standard account.
Choose the right account creation method – Whether you’re creating a single account or provisioning at scale using AWS Organizations APIs, understand the trade-offs and credential implications of each approach.
Secure credentials immediately – AWS GovCloud (US) root credentials are access keys, not console logins. Perform initial configuration promptly, store root credentials securely or delete them, and implement proper IAM and SSO controls before handing the account to users.
Establish security baselines early – Enable CloudTrail, GuardDuty, Security Hub, AWS Config, and encryption policies as part of your account onboarding—not as an afterthought.
Maintain accurate contact information – Use NPE mailboxes, keep phone numbers current, and review contact information regularly. Account access recovery depends on it.
Organize accounts at scale with AWS Organizations – Implement AWS Organizations in both partitions with OUs and SCPs to enforce compliance guardrails and manage accounts consistently.

By following these best practices, your organization can build a secure, compliant, and scalable AWS GovCloud (US) foundation that meets the demands of government workloads while minimizing operational overhead. As AWS continues to expand AWS GovCloud (US) capabilities, staying current with service availability and evolving your account management practices will keep your cloud environment both mission-ready and audit-ready. To get started with AWS GovCloud (US) account management, visit the AWS GovCloud (US) User Guide or reach out to your AWS account team.

Introducing AWS Cloud WAN in AWS GovCloud (US) Regions

Tushar Jagdale — Wed, 03 Jun 2026 16:45:50 +0000

Amazon Web Services (AWS) announced the general availability of AWS Cloud WAN in AWS GovCloud (US-West) and AWS GovCloud (US-East) Regions. With AWS Cloud WAN, you can use a central dashboard and network policies to create a global network that spans multiple locations and networks, removing the need to configure and manage different networks using different technologies. You can use network policies to specify which Amazon Virtual Private Clouds (VPCs), AWS Transit Gateways, and on-premises locations to connect using AWS Site-to-Site VPN, AWS Direct Connect, or third-party SD-WAN products. AWS Cloud WAN automatically creates a global network across AWS Regions using Border Gateway Protocol (BGP) so that you can exchange routes across Regions, and generates a view of the network to help you monitor network health, security, and performance.

Previously, organizations operating in AWS GovCloud (US) that needed to connect resources across GovCloud (US-West) and GovCloud (US-East) Regions, on-premises data centers, and branch offices had to configure and manage different networks individually using different technologies, resulting in operational complexity that grows with each new location, network appliance, and security requirement. With this launch, organizations processing Controlled Unclassified Information (CUI), International Traffic in Arms Regulations (ITAR)-controlled data, and other sensitive workloads can now use the same policy-based automation and centralized management capabilities available in commercial Regions, enabling multi-Region disaster recovery architectures, hybrid connectivity, and streamlined network operations while maintaining the compliance boundaries AWS GovCloud (US) provides.

In this post, we cover the use cases for AWS Cloud WAN in AWS GovCloud (US), walk through the key capabilities now available to government organizations and regulated industries, provide guidance on getting started, and discuss important considerations for deployment.

What is AWS Cloud WAN?

AWS Cloud WAN is a managed wide-area networking (WAN) service that streamlines building and operating networks through a centralized control plane that automates network configuration across multiple Regions. Instead of manually configuring individual networking components, you define your network architecture through declarative JSON policies, and AWS Cloud WAN implements the configuration automatically. The service creates isolated routing domains called segments, similar to globally consistent virtual routing and forwarding (VRF) tables in traditional networks, that let you separate different environments or workload types at the network level.

In AWS GovCloud (US), the AWS Cloud WAN control plane home Region is AWS GovCloud (US-West) (us-gov-west-1). This means the central dashboard, network policies, and Amazon CloudWatch metrics for your core network are managed from AWS GovCloud (US-West), while Core Network Edges (CNEs) operate in both AWS GovCloud (US-West) and AWS GovCloud (US-East) as defined in your core network policy. The Network Manager API endpoint for GovCloud is networkmanager.us-gov-west-1.amazonaws.com, which is FIPS 140-3 validated as listed on the AWS FIPS 140-3 compliance page.

For detailed information about core network architecture, network segments, attachments, and routing behavior, refer to the AWS Cloud WAN documentation.

Figure 1 illustrates an example of AWS Cloud WAN implementation across two AWS GovCloud (US) Regions.

Figure 1: Example AWS Cloud WAN implementation across two AWS GovCloud (US) Regions

AWS GovCloud (US) Regions overview

AWS GovCloud (US) is an isolated AWS partition designed exclusively for US government agencies, their partners, and organizations with regulated workloads. The partition consists of two Regions, AWS GovCloud (US-West) and AWS GovCloud (US-East), that are physically and logically isolated from commercial AWS Regions, with no commingling of government and commercial data. Access is restricted to verified US citizens, with root account holders undergoing rigorous vetting to confirm their US person status. Data sovereignty is maintained. Data resides within the US, complying with regulations such as ITAR. Additionally, AWS GovCloud (US) offers a range of AWS services with enhanced security features, such as advanced encryption and network protections, which are tailored to government needs.

This isolation supports the compliance requirements that drive organizations to AWS GovCloud (US) in the first place. The partition holds Federal Risk and Authorization Management Program (FedRAMP) High authorization, the highest baseline for nonclassified systems. It supports Department of Defense (DoD) Cloud Computing Security Requirements Guide (CC SRG) for Impact Levels (ILs) 4 and 5, enabling DoD mission owners to process CUI and mission-critical workloads for National Security Systems. Additional compliance frameworks include ITAR, Export Administration Regulations (EAR), Criminal Justice Information Services (CJIS) Security Policy, Internal Revenue Service (IRS)-1075 for tax data protection, and Federal Information Processing Standard (FIPS) 140-3 for cryptographic standards.

Data sovereignty is a foundational design principle. Data in AWS GovCloud (US) remains physically within the United States, and administrative access is limited to vetted US persons. For organizations subject to ITAR, EAR, or other data residency requirements, this provides a compliance boundary at the infrastructure level.

With the availability of AWS Cloud WAN in this partition, organizations can now apply centralized, policy-driven network automation across both GovCloud Regions, bringing the same operational model used in commercial Regions to workloads that require this level of isolation and compliance.

Use cases in AWS GovCloud (US)

Multi-Region disaster recovery – Connect applications across AWS GovCloud (US-East) and AWS GovCloud (US-West) Regions with automated failover and dynamic routing, so mission-critical systems remain operational during regional disruptions.
Hybrid connectivity – Integrate on-premises data centers with AWS GovCloud (US) environments using Direct Connect through Transit Gateway attachments, centralizing hybrid connectivity management through a single policy framework.
SD-WAN integration – Extend your SD-WAN infrastructure into AWS GovCloud (US) using Tunnel-less Connect for higher performance and streamlined operations compared to traditional tunneled approaches.
Network segmentation for workload isolation – Create isolated routing domains for workloads with different classification levels or compliance requirements, with the ability to confine segments to a specific Region for data residency needs.

Key capabilities

Policy-based networking with version control

AWS Cloud WAN uses centralized, declarative network configuration defined in JSON policies. You specify your desired network state, including which VPCs connect to which segments, how traffic flows between Regions, and where security inspection occurs, and AWS Cloud WAN implements the configuration automatically. Each policy change creates a new version with rollback capabilities, providing the audit trail and change management controls that frameworks such as FedRAMP and DoD SRG require. You can test a new network configuration, validate it, and if something is not right, roll back to the previous version.

Service insertion for security inspection

AWS Cloud WAN service insertion supports integration of network and security services, including AWS Network Firewall and third-party security appliances through Gateway Load Balancer. You define inspection requirements in your policy, and AWS Cloud WAN automatically steers traffic through the appropriate security controls with no complex static routes and no manual configuration across Regions. This capability supports east-west (VPC-to-VPC), north-south (internet egress), and hybrid traffic inspection between on-premises and cloud environments. For organizations required to inspect traffic at trust boundaries under Trusted Internet Connections (TIC) 3.0 or similar frameworks, service insertion provides a centralized, policy-driven approach to traffic steering.

Dynamic routing for cross-Region connectivity

AWS Cloud WAN automatically establishes BGP peering between Core Network Edges, dynamically exchanging routes and adapting to network changes. When building disaster recovery architectures across AWS GovCloud (US-East) and AWS GovCloud (US-West), this dynamic routing replaces the complexity of managing static routes between transit gateways. Traffic automatically reroutes around failures without manual intervention.

AWS Cloud WAN also supports Routing Policy, providing fine-grained controls to optimize route management, control traffic patterns, and customize network behavior across your global network. This includes route filtering, summarization, and BGP path manipulation, capabilities that let you control which on-premises routes are accepted in each Region and optimize traffic paths between Regions.

Hybrid connectivity with Direct Connect

In AWS GovCloud (US) Regions, AWS Cloud WAN integrates with Direct Connect through AWS Transit Gateway attachments. This architecture provides dedicated, high-bandwidth connections while maintaining centralized policy-driven management.

Tunnel-less Connect for SD-WAN

You can integrate SD-WAN technologies to simplify branch connectivity to AWS using GRE or IPsec tunnels. AWS Cloud WAN supports Tunnel-less Connect as a higher-performant alternative. Third-party SD-WAN appliances can peer with AWS Cloud WAN using BGP without specialized tunneling protocols, delivering up to 100 Gbps per Availability Zone while streamlining operations.

Centralized network management

AWS Cloud WAN provides a unified view of your network, including topology, health, performance, and security posture, through a single dashboard and policy framework. For organizations managing networks across both AWS GovCloud (US) Regions, this eliminates the need to context-switch between different services or piece together network state from multiple consoles.

Regional segment confinement

AWS Cloud WAN segments can be configured with regional scope so you can create network isolation boundaries that do not extend beyond a specific Region. This capability addresses compliance scenarios where data residency requirements mandate that certain workloads remain within specific geographic boundaries. For organizations subject to ITAR or handling workloads across different Impact Levels, you get the benefits of automation and centralized management while maintaining the isolation boundaries your compliance frameworks demand.

Getting started in AWS GovCloud (US)

The configuration process for AWS Cloud WAN in AWS GovCloud (US) follows the same workflow as in commercial Regions. You can configure AWS Cloud WAN using the AWS Management Console, AWS Command Line Interface (AWS CLI), JSON policy, AWS APIs (SDKs), or infrastructure as code (IaC) tools such as AWS CloudFormation or Terraform.

There are a few GovCloud-specific details to be aware of:

Home Region: The AWS Cloud WAN control plane home Region in the GovCloud partition is AWS GovCloud (US-West) (us-gov-west-1). Network policies, dashboard data, and CloudWatch metrics are managed from this Region.
Edge locations: Your core network policy specifies us-gov-west-1 and us-gov-east-1 as edge locations, as shown in the example below.
FIPS endpoint: The Network Manager API endpoint (networkmanager.us-gov-west-1.amazonaws.com) is FIPS 140-3 validated.
Partition isolation: AWS Cloud WAN core networks in AWS GovCloud (US) are separate from commercial partition core networks. They cannot span across partitions.

For detailed step-by-step instructions, refer to the AWS Cloud WAN User Guide.

The following JSON policy illustrates the example used to create the AWS Cloud WAN network shown in Figure 1. You don’t need to be proficient in JSON because the service automatically creates and version-controls the policy when you use other configuration methods.

{
  "version": "2025.11",
  "core-network-configuration": {
    "vpn-ecmp-support": true,
    "dns-support": true,
    "security-group-referencing-support": false,
    "asn-ranges": [
      "64612-64712"
    ],
    "edge-locations": [
      {
        "location": "us-gov-west-1"
      },
      {
        "location": "us-gov-east-1"
      }
    ]
  },
  "segments": [
    {
      "name": "Prod",
      "edge-locations": [
        "us-gov-west-1",
        "us-gov-east-1"
      ],
      "require-attachment-acceptance": false
    },
    {
      "name": "Dev",
      "edge-locations": [
        "us-gov-east-1",
        "us-gov-west-1"
      ],
      "require-attachment-acceptance": false
    },
    {
      "name": "Hybrid",
      "edge-locations": [
        "us-gov-west-1",
        "us-gov-east-1"
      ],
      "require-attachment-acceptance": false
    }
  ],
  "network-function-groups": [
    {
      "name": "NFG",
      "require-attachment-acceptance": false
    }
  ],
  "attachment-policies": [
    {
      "rule-number": 101,
      "condition-logic": "and",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "Name",
          "value": "Prod"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "Prod"
      }
    },
    {
      "rule-number": 102,
      "condition-logic": "and",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "Name",
          "value": "Dev"
        }
      ],
      "action": {
        "association-method": "constant",
        "segment": "Dev"
      }
    },
    {
      "rule-number": 103,
      "condition-logic": "and",
      "conditions": [
        {
          "type": "tag-value",
          "operator": "equals",
          "key": "Name",
          "value": "Insp"
        }
      ],
      "action": {
        "add-to-network-function-group": "NFG"
      }
    }
  ]
}

Considerations

AWS Cloud WAN core networks cannot stretch between AWS GovCloud (US) and commercial partitions. Because of compliance and isolation requirements, these operate as separate network domains. If you need connectivity between partitions, use patterns such as VPN over the internet or connectivity through on-premises gateways. For current regional availability and service limitations, refer to the AWS Services by Region page.
At the time of this writing, Direct Connect gateways cannot be attached directly to AWS Cloud WAN in AWS GovCloud (US) Regions. Check the AWS Cloud WAN documentation for the latest updates on this capability.
AWS Cloud WAN and AWS Transit Gateway coexist during transitions, meaning you can incrementally migrate workloads without disrupting production traffic. For detailed migration patterns and best practices, refer to AWS Cloud WAN and AWS Transit Gateway migration and interoperability patterns.
AWS Cloud WAN supports both IPv4 and IPv6 for traffic across its Core Network Edges (CNEs).
AWS Cloud WAN has default quotas for segments, attachments, and other resources per core network. For the full list of quotas and how to request increases, refer to the AWS Cloud WAN endpoints and quotas page.
AWS Cloud WAN pricing in AWS GovCloud (US) Regions follows the same structure as commercial Regions. For detailed pricing information, refer to the AWS Cloud WAN pricing page.

Conclusion

AWS Cloud WAN in AWS GovCloud (US) Regions brings policy-driven network automation to government organizations and regulated industries operating mission-critical workloads. Whether you are connecting AWS GovCloud (US-West) and AWS GovCloud (US-East) for disaster recovery, integrating on-premises data centers through Direct Connect, or extending SD-WAN infrastructure to distributed field locations, AWS Cloud WAN provides centralized management and automation while maintaining the compliance boundaries your mission requires. To get started, refer to the AWS Cloud WAN documentation.

Accelerating life sciences research with Kiro: A unified AI interface to 100+ open source databases

Edwin Sandanaraj — Wed, 03 Jun 2026 13:33:08 +0000

Life sciences researchers face a persistent integration challenge. A single investigation such as linking a somatic mutation to a druggable target might require querying the National Center for Biotechnology Information (NCBI) for gene context, ClinVar for clinical significance, UniProt for protein function, the Protein Data Bank (PDB) for structural data, STRING for interaction partners, and ChEMBL for compound bioactivity. Each database has its own API, authentication scheme, data format, and rate limits. Researchers either context-switch across dozens of browser tabs or write bespoke scripts that break every time an API changes.

This post introduces Kiro for Life Sciences, a Kiro power package that transforms Kiro into a unified research interface spanning more than 100 databases across 24 scientific disciplines. It’s not a portal or a dashboard but an AI-assisted development environment where researchers ask questions in natural language and receive structured, cross-referenced answers pulled directly from authoritative sources.

Data silos slow discovery

A computational biologist studying BRCA1 variants today might need to:

Search NCBI Gene for basic annotation.
Pull the protein sequence from UniProt.
Check ClinVar for pathogenic variants.
Look up the 3D structure in PDB or AlphaFold.
Find interaction partners in STRING.
Cross-reference OMIM for disease associations.
Check gnomAD for population frequencies.
Search ChEMBL for compounds targeting the pathway.

That’s eight databases, eight authentication flows, and eight result formats—for a single gene. Multiply this across every variant and every project. The cognitive overhead is significant, and the risk of missing a critical cross-reference is real.

Solution overview: Kiro for Life Sciences

Kiro for Life Sciences uses an architecture that combines Kiro powers and modular Model Context Protocol (MCP) servers. A central power acts as the hub providing an onboarding dashboard, searchable resource catalog, credential manager, domain skills, and guided workflows. Twenty-four domain-specific MCP servers handle the actual database connections, each independently deployable and configurable.

The solution is guided by the following key architectural decisions:

Modular by design – Install only the servers you need. A proteomics lab doesn’t need the ecology server. Each server is a standalone Python package.
Single credential surface – Configure API keys one time in mcp.json. The credential manager handles token refresh, rate limiting, and retry logic with exponential backoff.
Cross-database search – Ask one question, get answers from multiple databases simultaneously. No manual orchestration required.

Coverage at a glance

The following table outlines the coverage each database or tool provides for each domain.

Domain	Databases and tools	Tool count
Genomics and sequencing	NCBI, Ensembl, ClinVar, gnomAD, COSMIC, dbSNP, ENCODE, GEO, SRA, DDBJ, 1000 Genomes	18
Proteomics	UniProt, InterPro, STRING, PRIDE, neXtProt	8
Structural biology	PDB, AlphaFold DB, CATH, SCOP	6
Clinical and pharma	OMIM, DrugBank, ChEMBL, PharmGKB, OpenTargets, ClinicalTrials.gov, FDA FAERS	10
Cheminformatics	PubChem, ChemSpider, RDKit, SwissDock	8
Immunology	IEDB, ImmPort, IMGT, abYsis	4
Microbiology and metagenomics	SILVA, QIIME 2, MG-RAST, BV-BRC, CARD	8
Pathways and interactions	KEGG, Reactome, BioCyc, WikiPathways, IntAct	7
Ecology and environment	GBIF, IUCN, iNaturalist, BOLD, MGnify	7
Molecular biology	BLAST, Primer3, HMMER, REBASE, Clustal Omega	9
More than 14 more domains	Neuroscience, cell biology, metabolomics, epigenomics, imaging, agriculture, healthcare, biobanking, pipelines, data standards, AI/ML	More than 50
Total	More than 100 databases and tools	More than 250

How it works

The interface is designed to provide answers from multiple databases to a single query. To use it, begin by asking Kiro, I'm studying TP53. Get its UniProt sequence, find experimental structures in PDB, check AlphaFold for predicted structure, pull interaction partners from STRING, and show me the domain architecture from InterPro.

Kiro dispatches parallel queries to five databases and returns a consolidated protein profile with no scripting, no tab switching, no format wrangling.

Cross-database search intelligence

The cross-database search feature orchestrates parallel queries across installed MCP servers with automatic result aggregation and graceful degradation.

Search type	Databases queried in parallel
gene	NCBI Gene, UniProt, Ensembl, ClinVar, OMIM, Gene Ontology, KEGG, Reactome
drug	DrugBank, ChEMBL, PharmGKB, OpenTargets, PubChem, HMDB, CARD
protein	UniProt, PDB, AlphaFold DB, InterPro, STRING, neXtProt, ESM
species	GBIF, IUCN Red List, BOLD, iNaturalist, NCBI Taxonomy, MGnify
metabolite	HMDB, MetaboLights, METLIN, MassBank, PubChem, KEGG
cell_type	CellxGene, Single Cell Expression Atlas, Cell Atlas, Allen Brain Atlas

Guided multistep workflows

The power includes 16 steering files, which are step-by-step workflow guides that automatically activate based on your workspace file patterns:

Variant calling pipeline – Set up and run somatic or germline variant calling through AWS HealthOmics.
Gene-disease associations – Cross-reference ClinVar with OMIM and HPO to build a complete variant-to-phenotype map.
Compound screening – Search PubChem for candidates, compute RDKit descriptors, filter through ZINC, and finish with molecular docking.
Primer design and cloning – Design primers with Primer3, verify specificity through PrimerBLAST, perform restriction analysis, and assemble the final construct.
Microbiome analysis – Assign taxonomy using SILVA, assess diversity with QIIME 2, and profile resistance genes through CARD.

These aren’t documentation pages. They’re executable guides that Kiro follows step-by-step, calling the right tools in the right order.

Domain skills with encoded best practices

Ten domain skills provide contextual guidance that activates based on what you’re working on:

Bioinformatics file formats – FASTA, FASTQ, BAM, VCF, GFF, and BED handling patterns
Genomics pipeline best practices – WDL, Nextflow, or CWL design patterns for reproducible workflows
Data compliance – HIPAA, GDPR, GxP, MIAME, and MINSEQE requirements
Clinical interoperability – FHIR, HL7, and OMOP CDM integration patterns
Cheminformatics – SMILES or InChI handling, Lipinski rules, and SAR analysis

When you’re writing a pipeline, Kiro knows the conventions. When you’re handling patient data, it knows the compliance requirements.

Example: From variant to drug target in one session

Here’s what a realistic research session looks like. A researcher asks a question, and the tool returns an answer, automatically drawing from the appropriate database:

Search ClinVar for pathogenic variants in EGFR: Returns variant IDs with clinical significance.
Get the protein structure for EGFR from PDB: Returns 1M17 with resolution and method.
What are the known drug interactions for EGFR in ChEMBL?: Returns compound bioactivity data.
Check OpenTargets for EGFR disease associations: Returns scored associations across cancer types.
Predict ADMET properties for this lead compound: Returns solubility, BBB permeability, and CYP450 predictions.
Submit a docking job with receptor 1M17 and this ligand SMILES: Returns binding affinity and interacting residues.

The researcher searched six databases in one conversation using six steps—no context switching, no format translation, no authentication juggling.

What makes this different

Web portals such as Galaxy and UCSC Genome Browser are powerful but domain specific. They don’t span 24 disciplines in a single interface. Kiro for Life Sciences provides a unified experience across all life sciences domains, accessible directly within your IDE.

Script libraries such as Biopython give you programmatic access but require writing and maintaining integration code for every database. Kiro handles the API calls, pagination, error handling, and rate limiting so you can focus on the science rather than the plumbing.

Generic AI assistants can discuss biology, but they can’t execute live queries against databases. Kiro makes authenticated, structured API calls that return machine readable results: real data, not summaries from training corpora.

The solution provides the unique value of letting researchers ask a question in plain English. Kiro determines which databases to query, executes the calls in parallel, handles authentication and retries, and returns consolidated results within the same environment where they write code, run pipelines, and analyze data.

Architecture for computational scientists

Each MCP server is a standalone Python package built with async HTTP clients, exponential backoff, and structured error handling. A shared base package called life-sciences-common provides the HTTP client, retry logic, and error taxonomy that all servers inherit from, so behavior is consistent across every domain.

Servers are runnable using uvx with no Docker containers or infrastructure management required. The bundle manifest declaratively describes all 24 servers, making it straightforward to check status and configure your setup. Property-based testing with Hypothesis offers robustness across edge cases, giving confidence that the tools behave correctly even with unexpected inputs.

For large-scale computation, the AWS HealthOmics integration enables running nf-core, WDL, and CWL pipelines without managing your own cluster infrastructure.

The solution offers benefits for researchers across multiple disciplines:

Bioinformaticians who currently maintain wrapper scripts for every database API can retire that boilerplate and let Kiro handle the integration layer. Computational biologists who need to cross reference findings across multiple data sources will find they can do in one conversation what previously required stitching together outputs from half a dozen tools.

Clinical researchers benefit from being able to map variants to diseases to drugs without leaving their analysis environment, keeping the entire investigative thread in one place. Lab scientists who want to look up protein structures or design primers no longer need to learn programmatic APIs; they can ask in natural language.

For research teams, the shared and reproducible approach to querying databases means everyone works from the same tooling, reducing the “it works on my machine” problem that plagues collaborative science.

Getting started

Install the power, configure the MCP servers for your domain, and start asking questions. The onboarding dashboard shows what’s available, what needs credentials, and what’s ready to use.

The following code block is an example mcp.json configuration:

{
  "mcpServers": {
    "life-sciences-genomics": {
      "command": "uvx",
      "args": ["life-sciences-genomics"],
      "env": {
        "NCBI_API_KEY": "your-ncbi-api-key"
      }
    },
    "life-sciences-proteomics": {
      "command": "uvx",
      "args": ["life-sciences-proteomics"]
    },
    "life-sciences-structural": {
      "command": "uvx",
      "args": ["life-sciences-structural"]
    }
  }
}

The result is that three servers are configured, and you can already query NCBI, Ensembl, ClinVar, UniProt, PDB, AlphaFold, and a dozen more databases from a single chat interface.

Conclusion

Life sciences research doesn’t have a compute problem, but it has an integration problem. The data exists across hundreds of databases. The challenge is accessing it efficiently, cross-referencing it correctly, and doing so without building a custom integration layer for every project.

Kiro for Life Sciences eliminates that integration tax by providing one interface, one authentication surface, and one place where a researcher can go from gene to variant to structure to drug target to clinical trial in minutes, not days. The databases remain the single source of truth, and Kiro is the single point of access. To get started, find the full power package including all 24 MCP servers, skills, steering files, and example configurations on GitHub.

Why the location of your AI agent is a security decision

Gabriel Fuentes — Tue, 02 Jun 2026 14:13:21 +0000

US Federal agencies face dual mandates: adopt AI rapidly and secure it at every layer. Executive Order 14179 directs accelerated AI adoption. OMB M-25-21 requires agencies to assign Chief AI officers, CFO Act agencies to publish AI strategies within 180 days, and delegate accountability for AI risk acceptance to appropriate officials. OMB M-26-04 directs agencies to apply unbiased AI principles when procuring large language models, including requirements for truthfulness and transparency. The March 2026 National AI Legislative Framework outlines the administration’s priorities for proposed Congressional AI legislation, including innovation acceleration and responsible AI governance.

The through line across all four directives: innovate fast, but not recklessly. Teams evaluating AI agents (autonomous software that can reason, plan, and act) must resolve how to authorize such code within regulated information systems.

An AI agent is code running in a compute environment, calling APIs. On a user’s laptop, it inherits the user’s full permissions (files, credentials, network access) as well as any established isolation boundaries. On Amazon Web Services (AWS), it operates inside a scoped compute environment with an AWS Identity and Access Management (IAM) execution role, network segmentation, and defense-in-depth security meeting FISMA, FedRAMP, and DoD CCSRG standards. Those controls are deterministic. They do not change based on what the model thinks.

The shift in perspective—from asking “How do we trust the AI?” to “Are we running it where our controls already apply?”—helps teams move from deliberation to scoped agent pilots. This post unpacks that reasoning.

Treat your agent as code

An AI agent is an application. It runs in AWS Lambda, Amazon Elastic Container Service (Amazon ECS), or Amazon Elastic Kubernetes Service (Amazon EKS). It has an IAM execution role. It sits inside an Amazon Virtual Private Cloud (Amazon VPC). It writes logs to AWS CloudTrail.

The foundation model (FM), whether Amazon Nova 2 Lite or Amazon Nova 2 Sonic on Amazon Bedrock, is a stateless API call. It returns text. It can’t execute code, overwrite files, or reach into your infrastructure. Your application code in your compute environment parses that response and decides whether to act on it. When you add agent capabilities—action groups, tool use, code interpretation—it is your execution layer, governed by your IAM roles and network controls, that carries out those actions, not the model. Amazon Bedrock is the reasoning layer. Your compute layer is the execution layer. They are separate, and the execution layer is fully under your control.

This means the security controls you already enforce on your workloads (IAM least privilege, VPC isolation, security groups, encryption, logging) apply to your AI agent. You don’t start from zero. You start from the security posture you have already built.dd

What you already have vs. what you add

The following table shows how existing cloud security controls map to AI agent workloads, and where AI-specific controls extend them. The left column represents standards and mechanisms that predate AI. The right column represents the targeted additions.

Security Concern	Controls You Already Use	AI-Specific Additions
Identity and authorization	IAM execution roles, AWS Security Token Service (AWS STS) temporary credentials, Amazon Cognito authentication, JWT-based identity propagation	Propagate user identity through agent interactions using standard OAuth/JWT flows so agent actions trace back to the human who initiated it.
Network isolation	VPC segmentation, security groups, AWS Network Firewall, AWS WAF rate limiting, AWS Shield DDoS protection	Rate limiting for AI endpoints to control both abuse and cost.
Data protection	AWS Key Management Service (AWS KMS) encryption at rest and in transit, AWS Secrets Manager credential rotation, AWS PrivateLink for inter-service traffic	Amazon Bedrock Guardrails for real-time personally identifiable information (PII) detection and redaction on inputs and outputs. Amazon Macie for scanning data stores.
Application protection	Input validation, AWS Organizations service control policies, OAuth authorization flows	Amazon Bedrock Guardrails for prompt injection defense and content filtering. Human-in-the-loop approval hooks for agent actions. Resource control policies scoped to AI capabilities.
Threat detection and audit	CloudTrail API logging, Amazon CloudWatch monitoring, incident response procedures	Amazon GuardDuty AI-specific threat detection (suspicious model invocations, unusual guardrail removal, disabled logging).

Figure 1. Existing cloud security controls (left) map directly to AI agent workloads. AI-specific additions (right) extend, not replace, the controls public sector organizations already operate.

The pattern is consistent: the foundation is the same. IAM, Amazon VPC, AWS KMS, CloudTrail, and JWT have operated across millions of workloads for years. AI agents inherit all of them. The additions are targeted: guardrails for content filtering, identity propagation for agent-to-human traceability, and threat detection tuned to AI-specific signals.

Scope the controls to the workload

The compute environment stays the same regardless of how much autonomy you give the agent. What changes is how many AI-specific controls you layer on top. The Agentic AI Security Scoping Matrix, referenced by organizations including OWASP and the Coalition for Secure AI (CoSAI), helps you decide how much to apply:

Scope 1 – The AI responds but takes no action. Your existing compute, IAM, and network controls are sufficient.
Scope 2 – The agent suggests actions, and a human approves each one. Add human-in-the-loop hooks and tighter IAM permission boundaries on the execution role.
Scope 3 – Automated agentic actions with monitoring. Layer in Amazon Bedrock Guardrails, GuardDuty AI threat detection, and identity propagation for full traceability.
Scope 4 – Fully autonomous agent action. Apply the complete control set from the preceding table, with continuous evaluation and AI-specific incident response procedures.

Start at Scope 2, the same incremental approach you would take when granting a new application additional permissions. The IAM role, VPC, and encryption do not change between scopes. You start restrictive and expand based on evidence.

For AWS GovCloud (US) customers, this compute-level framing is especially relevant. Managed agent orchestration services, including Amazon Bedrock AgentCore, are now available in AWS GovCloud (US-West). But the underlying pattern doesn’t depend on them. Agent runtimes deploy on Lambda, Amazon ECS, or Amazon EKS, the same compute services already authorized in your environment. The reasoning layer is an API call to Amazon Bedrock. Identity propagation uses standard OAuth/JWT flows. Encryption uses AWS KMS. Logging uses CloudTrail. The controls in the preceding table are available in AWS GovCloud (US) at the time of writing because they are compute and infrastructure controls, not AI-specific services. AWS was the first major cloud provider to achieve ISO 42001 certification, the international standard for AI management systems, providing an independently audited foundation for AI governance.

Getting started

Map your agent deployments against the scoping matrix, verify your existing controls extend to AI workloads, and add targeted AI-specific mechanisms.

Scope your use cases. Map planned agent deployments against the Agentic AI Security Scoping Matrix. Start at Scope 2.
Verify your existing controls extend to AI. Confirm that IAM least privilege, VPC isolation, encryption, and CloudTrail logging cover your agent compute environments.
Add AI-specific controls. Deploy Amazon Bedrock Guardrails for content filtering and PII detection. Configure GuardDuty AI threat detection. Implement human-in-the-loop approval for agent actions.
Design your agent threat model. Work with your security team—and your AWS Technical Account Manager and Solutions Architect—to map agent-specific threats against your existing control framework.

The security of an AI agent is not about trusting the model. It is about running it where your controls already work, and adding the targeted set of AI-specific mechanisms on top. The standards that protect your workloads today are the same standards that protect your agents tomorrow.

To learn more, review the AWS Well-Architected Generative AI Lens , Security Pillar and the infrastructure security guidance for agentic AI on AWS.

The Registry of Open Data on AWS surpasses 1,000 datasets

Kyle Cook — Tue, 02 Jun 2026 00:13:30 +0000

Unlocking Innovation: A growing community of data providers is making the world’s most impactful datasets freely available for research, discovery, and innovation

We’re excited to announce that the Registry of Open Data on Amazon Web Services (AWS) has surpassed a major milestone: 1,122 datasets are now freely available to anyone. Within the last two years the Registry of Open Data on AWS has more than doubled in size—growing from 556 to over 1,100 datasets, representing a 102% increase in datasets.

With the Registry of Open Data, our goal was straightforward: remove the barriers that prevent researchers, developers, and innovators from accessing high-value datasets. Today, that vision is thriving, powered by a global community of data providers spanning government agencies, research institutions, nonprofits, and private organizations.

What is the Registry of Open Data on AWS?

The Registry of Open Data on AWS simplifies finding and accessing datasets on AWS that are available for anyone to use. These datasets are hosted on AWS infrastructure, meaning users can analyze them in the cloud without needing to download massive files or manage their own storage. Whether you’re a climate scientist, a genomics researcher, or a machine learning engineer, the registry provides a single place to discover datasets that can accelerate your work.

A milestone worth celebrating

Reaching 1,122 datasets is more than just a number—it reflects the growing momentum of the open data movement. Here are a few highlights:

Diverse domains – The registry spans genomics, satellite imagery, climate and weather, natural language processing, autonomous vehicles, and much more.
Over 400 Petabytes of data – Collectively, these datasets represent petabytes of freely accessible information, hosted and ready for analysis.
Global contributors – Data providers include organizations like National Oceanic and Atmospheric Administration (NOAA), National Aeronautics and Space Administration (NASA), the Allen Institute, the National Institutes of Health (NIH), Biohub and hundreds of others committed to making data open and accessible.
Enabling reproducibility – By providing stable, cloud-hosted datasets, the registry helps ensure that scientific research is reproducible and that results can be independently verified.

How the AWS Open Data Program drives innovation

AWS Open Data fuels breakthroughs across industries. Here are just a few examples of what it makes possible:

Climate research – Scientists use open weather and satellite datasets to model climate change, predict extreme weather events, and inform policy decisions.
Genomics and healthcare – Researchers use datasets like the 1000 Genomes Project and CellxGene Census to advance our understanding of human biology and disease.
Machine learning – Developers train and benchmark AI models on open datasets, accelerating progress in computer vision, natural language processing, and beyond.
Public policy – Government agencies and civic organizations use open data to improve transparency, drive evidence-based decision-making, and better serve communities.

What’s next?

We’re just getting started. As the open data community continues to grow, we’re committed to improving how these datasets are discovered, accessed, and used. We’re investing in better search and discovery tools, expanding our partnerships with data providers, and working to ensure that the Registry of Open Data on AWS remains a trusted, go-to resource for open data.

If you have a dataset you want to share with the world, we’d love to hear from you. Learn more about Open Data on AWS.

Get started

Ready to explore? Browse the full catalog of datasets within the Registry of Open Data on AWS and start building today.

Failing forward: How AI and structured reflection drive continuous improvement

Brigette Bucke — Mon, 01 Jun 2026 19:13:32 +0000

A practical framework for turning every project into an engine of organizational learning, accelerated by AI

The problem no one schedules time for

Your team just wrapped a major initiative: a student information system migration, a benefits platform launch, a multi-campus integration. Stakeholders are satisfied, and everyone pivots to the next priority. The workarounds invented, the communication breakdowns, the collaboration wins. All of it quietly evaporates.

This isn’t a talent problem. It’s a systems problem. When reflection isn’t baked into the operational model, even high-performing teams plateau. They carry the same unexamined habits from one project to the next. The fix? Build reflection into your operational model. And increasingly, it’s AI that makes that reflection faster, deeper, and more actionable.

This post gives you a practical framework for turning project experience into organizational learning and shows how Amazon Web Services (AWS) AI services accelerate the process.

What failing forward actually means

Failing forward doesn’t mean normalizing poor performance. It means building a deliberate process for extracting value from every experience, especially the ones that didn’t go as planned. A team that misses a key stakeholder, causes rework, and then creates a stakeholder mapping checklist for future projects? That’s failing forward: not the mistake itself, but what you build from it.

The same principle applies to what went right. The collaboration approach that unlocked a breakthrough? Document it. The communication rhythm that kept the team aligned? Name it, preserve it, replicate it.

Speed matters. Many decisions are reversible and don’t need extensive study. Calculated risk taking becomes sustainable when you pair it with the discipline of structured reflection.

The framework: Start, Stop, Continue

One of the most effective formats for structured reflection is the Start, Stop, Continue framework. Start: What should we begin doing? Stop: What should we stop doing? Continue: What’s working that we should preserve?

This framework creates the conditions for candor. When people see their feedback produce real change, trust compounds. Teams that listen attentively, speak candidly, and treat each other respectfully build the psychological safety that makes honest reflection possible.

How AI accelerates failing forward

Structured reflection has always been valuable. What’s changed is that AI now compresses the feedback loop, so teams fail faster, learn sooner, and course-correct before the cost compounds. Speed and governance are no longer trade-offs. Six ways AI transforms the practice:

Prototype in hours, not weeks

Kiro transforms requirements into structured specs, generates production-ready code, and validates against acceptance criteria. Amazon Bedrock gives teams access to multiple foundation models (including Amazon Nova and Amazon Titan) through a single API, letting them prototype with different models and pick the right one for the workload. A bad idea that takes two hours to discard is cheap. One that takes six weeks is expensive.

Develop fast and deploy with confidence

AI generates test scenarios, edge cases, and synthetic data that surface failures in development instead of production. Kiro’s test-driven approach catches issues before code ships. Amazon Bedrock Guardrails adds another layer, defining safety, compliance, and quality thresholds that AI outputs must meet at runtime. You move fast in development, and Guardrails enforces compliance in production.

Real-time pattern recognition

AI surfaces anomalies, trends, and regressions as they happen, not in a post-mortem three weeks later. With Amazon Bedrock AgentCore, teams are enabled to build autonomous agents that monitor systems, detect patterns, and take corrective action without waiting for a human to schedule a review.

Structured reflection at scale

AI analyzes retrospective notes, incident reports, and project data across teams to identify systemic patterns no single team would see. The Start, Stop, Continue framework becomes data-driven — teams ask “what does the data show?” instead of “what do we think happened?”

Lower the cost of experimentation

When AI handles boilerplate (code, documentation, tests, infrastructure), the human cost of trying something new drops dramatically. More experiments mean more learning. AI removes the friction that makes experimentation expensive, freeing teams to invent more boldly.

Democratize expertise

AI gives team members access to architectural guidance, best practices, and pattern libraries that previously required a senior engineer in the room. With Amazon Bedrock and Amazon Bedrock AgentCore, organizations encode institutional knowledge into agents that team members can query, turning years of accumulated expertise into an always-available resource. Junior teams fail less catastrophically. Senior teams fail more productively.

Making it work

Four conditions determine whether a reflection session produces real change: visible leadership sponsorship (participate, don’t delegate), cross-functional participation (insights emerge at role boundaries), psychological safety (focus on systems, not blame), and a commitment to action (owned items with deadlines). Build the session into the project schedule at kick-off, not close-out. Compile a summary within 48 hours. Schedule 30-day check-ins.

Structured reflection isn’t a nice-to-have — it’s a key input that compounds the quality of every subsequent delivery.

Why this matters for state, local government, and education

For state agencies, school districts, and universities, structured reflection is especially critical. Multi-year initiatives governed by funding cycles, board approvals, and legislative oversight leave little room for repeated mistakes, whether you’re deploying an AI-powered student advising platform, modernizing a state benefits eligibility system, or rolling out a district-wide technology integration. When a district or agency can point to documented lessons and the specific process changes they generated, they build the credibility that sustains bond funding, community trust, and long-term support. And when multiple departments or agencies co-deliver a program, a shared retrospective creates a neutral, forward-looking space for improving collaboration without post-incident blame.

The AI-accelerated reflection cycle

Traditional cycle: Build (weeks) → Ship → Discover issues (days) → Schedule retrospective (weeks) → Identify lessons → Maybe implement changes.

AI-accelerated cycle: Spec in Kiro (hours) → Prototype on Amazon Bedrock → Kiro generates and runs tests → Catch failures early → Iterate same-day → Ship with Amazon Bedrock Guardrails enforcing compliance → Amazon Bedrock AgentCore surfaces patterns in real time → Continuous course-correction.

The difference isn’t just speed. It’s learning cycles per unit of time. A team that completes ten prototype-test-learn cycles in a week generates more organizational knowledge than a team that completes one build-ship-retrospect cycle in a quarter.

Your next step

Somewhere in your organization, a project is wrapping up and hard-won lessons are evaporating. You need 60 minutes, a willing team, and three questions: What worked? What didn’t? What should we continue? Then the discipline to do something with the answers.

Failing forward isn’t about accepting failure. It’s about refusing to let experience go to waste — and building organizations that continuously grow more capable of delivering what matters most: value for your students, your constituents, and your communities. The best time to start was at the end of your last project. The second best time is now.

Quick-start checklist

Block 60 minutes at project kick-off for a reflection session.
Select 6–10 cross-functional participants with a leadership sponsor.
Run Start, Stop, Continue: quiet writing first, then cluster, vote, close with 3–5 action items.
Assign owners and deadlines. Distribute summary within 48 hours.
Schedule 30-day follow-up. Repeat. Reflection compounds.

AI boost: Use Kiro to spec, prototype, and test; Amazon Bedrock to build with multiple foundation models; Amazon Bedrock Guardrails to enforce compliance at runtime; and Amazon Bedrock AgentCore to monitor patterns continuously.

Learn more

What is Amazon Bedrock? — Get started with foundation models through a single API
Amazon Bedrock Guardrails — Implement customizable safeguards for your generative AI applications
Amazon Bedrock AgentCore — Deploy and operate AI agents with enterprise-grade security and governance
Kiro documentation — Spec-driven development that transforms requirements into production-ready code
Amazon Bedrock pricing — Understand costs for prototyping and production workloads

Building a healthier future for women: How AWS customers are transforming women’s health across the lifespan

Dr. Dawn Heisey-Grove — Fri, 29 May 2026 12:33:29 +0000

How AWS customers are transforming women’s health across the lifespan

Every May, Women’s Health Month reinforces that the health of women is a global imperative. The data tells a sobering story: Women represent half of the global population, but only 5% of health research funding focuses on women’s health issues. Women spend $15.4 billion more out-of-pocket on healthcare than men, even after controlling for maternity care. Despite living longer than men in most countries, women do so with more disability. And the economic stakes are enormous: Closing the women’s health gap could unlock $1 trillion in annual global GDP by 2040.

At Amazon Web Services (AWS), we believe cloud and AI technology are powerful tools to address these challenges. This Women’s Health Month, we spotlight six organizations supported by AWS social impact credits that are using the cloud to change what’s possible for women’s health. Together, their work spans the arc of a woman’s life from adolescence to cancer research, showing what happens when technology meets women where they are.

Adolescence

Breaking taboos and empowering girls through digital health

For 1.8 billion women and girls worldwide, menstruation is a natural monthly occurrence. Yet in many parts of the world, it remains surrounded by stigma and silence, leaving adolescent girls without the trusted information they need to manage their health with confidence. Girls who lack access to accurate menstrual health information are more likely to miss school, experience anxiety, and face long-term consequences for their well-being. For many, the issue is not only access to information but also whether digital platforms are safe, relevant, and designed for their realities.

Oky is more than a period tracker. It’s a girl-centered digital public good co-created with adolescent girls to close critical gaps in health knowledge, digital access, and confidence. Today, each new country localization involves at least 200 adolescent girls, including girls with disabilities, and their social circles. The result is a gamified, lightweight application that functions fully offline, requires no personally identifiable information, supports shared devices, and works on lower-end smartphones with older operating systems, meeting girls where they are in their digital realities.

With AWS Cloud infrastructure supporting its open source platform, Oky continues to scale while maintaining local ownership and trust. Oky is now localized across more than a dozen countries across Asia Pacific and sub-Saharan Africa, available in over 25 languages, and reaching over 1 million users.

“Oky shows that technology can go beyond delivering trusted health information. When it is built with girls and for their realities, it helps shift confidence, conversations, and access to knowledge,” says Gerda Binder, senior advisor for gender and technology at UNICEF. “Cloud infrastructure and AWS support enable us to bring that vision to more adolescents and their communities, safely and responsibly.”

Reproductive health

New class of therapy for bacterial vaginosis

As women move into their reproductive years, they face health challenges that have long lacked effective solutions. Bacterial vaginosis (BV) is one of the most common vaginal conditions affecting women of reproductive age, and one of the most undertreated. Associated with preterm birth, sexually transmitted infections, and infertility, BV has lacked effective, durable treatment options for decades. Ancilia Biosciences is working to change that.

Ancilia is a biotechnology company harnessing bacteria’s natural immune system, CRISPR, to develop a new class of live biotherapeutics that are immune to predatory viruses. Their initial focus is on treating BV using the microbiome, which is made up of the beneficial bacteria that play a critical role in maintaining vaginal health. Ancilia’s solutions use AWS AI and high-performance computing services to identify and characterize the viruses’ genomes to develop therapies targeting destructive viruses that otherwise undermine beneficial bacterial therapies.

“Our goal is to apply our advanced analytic and biological tools to unlock the vast potential of an entirely new class of therapies with major applications in both women’s health and beyond,” says Dr. Alexandra Sakatos, co-founder and CEO of Ancilia Biosciences.

Maternal health

Bringing care to the world’s hardest-to-reach mothers

For expectant mothers in the world’s most remote communities, the gap between needing care and receiving it can be a matter of life and death. Across sub-Saharan Africa and South Asia, millions face the same reality: a health system that ends where the paved road does.

Medic designs and supports open source software for health workers in hard-to-reach communities. As the technical steward of the Community Health Toolkit (CHT), an open source solution supporting over 182,000 health workers across 24 countries, Medic has facilitated more than 263 million moments of care.

“Community health workers are the backbone of last-mile care—and when we equip them with the right digital tools, we close the gap between where health systems end and where families live,” says Shreya Bhatt, co-executive director of Medic. “The CHT gives health workers an accessible, context-adapted system to track mothers before, during, and after delivery, identify and refer risks early, and connect remote communities to the wider health system. AWS is a critical part of how we deliver that at scale: It provides the secure, reliable cloud infrastructure to serve millions of people globally, while keeping costs sustainable for the governments and partners who own these systems.”

A clearer view in the delivery room

Maternal and fetal risks related to childbirth remain a critical challenge with the United States, which ranks 65th among industrialized nations in maternal deaths and has the highest rates of maternal and fetal mortality of any developed country. While the reasons for this are multifactorial, three compounding factors include difficulty getting clarity from clinical data, challenges with communication across care teams, and inability to maintain consistent care delivery across every shift. To address these problems, CareIntellect for Perinatal* was developed by GE Healthcare, built on six decades of fetal monitoring expertise and informed by more than 75 million births. The cloud-based solution unifies raw waveform data, nursing inputs, and other essential clinical data elements into a view that helps clinicians in labor and delivery units hone in on what matters most instead of navigating multiple systems and receiving delayed updates.

“Input and feedback from clinicians was fundamental to the solution’s development,” says Jeff Caron, chief digital and technology officer of patient care solutions at GE HealthCare. “That clinical voice informed every stage of development to help ensure relevance and impact at the point of care.”

Screening and prevention

Fueling AI-driven breast cancer research through open data

The Registry of Open Data on AWS also advances breast cancer research by hosting five breast cancer-focused datasets that are freely available to researchers worldwide. These datasets span the full diagnostic pipeline: the RSNA Screening Mammography Breast Cancer Detection Dataset provides nearly 20,000 imaging studies to help develop AI that streamlines mammography evaluation, while Emory University’s EMory BrEast Imaging Dataset (EMBED) offers 3.4 million mammograms.

On the computational pathology side, Radboud University Medical Center contributes two complementary datasets: the CAncer MEtastases in LYmph nOdes challeNge (CAMELYON) Dataset, with 1,399 whole-slide images for detecting breast cancer metastases in lymph nodes, and Tumor InfiltratinG lymphocytes in breast cancER (TIGER), the first challenge dataset for automated assessment of tumor-infiltrating lymphocytes, which is an emerging biomarker that helps target immunotherapy and reduce reliance on chemotherapy. Guy’s Hospital London’s Guy’s Breast Cancer Lymph Nodes (GRAPE) dataset rounds out the collection with 1,523 high-resolution lymph node images from 177 patients. Together, these datasets provide a freely accessible foundation for building AI tools that can improve breast cancer detection and treatment for all women, everywhere.

Cancer research and discovery

Powering AI-driven discovery at global scale

Every year, over 740,000 women worldwide are diagnosed with gynecologic cancers, with ovarian and endometrial cancers accounting for nearly 90,000 new diagnoses and over 26,000 deaths in the United States alone. Progress has been slow, not because the science isn’t there, but because the necessary infrastructure doesn’t exist.

Ovarian Cancer Research Alliance (OCRA) is changing that by moving beyond funding research to powering the infrastructure that enables it. Their Community Accelerated Research Exchange integrates patient data, scientific collaboration, and continuously updated global research intelligence into a single AI-powered ecosystem that delivers tailored insights from thousands of studies worldwide, highlights relevant conferences and scientific events, and gives every part of the gynecologic cancer community a single destination for the information most important to them. Two core components make up the research exchange:

The Living Lab – A patient registry capturing longitudinal, consent-driven real-world data, giving patients an active role in advancing research while creating a continuously expanding dataset grounded in lived experience, treatment history, and outcomes.
The Discovery Lab – A trusted research environment built on the Cirro Bio data platform—technology already trusted by more than 160 organizations—empowering researchers to integrate clinical, genomic, imaging, and spatial datasets and deploy AI workflows within compliant infrastructure.

“The Community Accelerated Research Exchange represents a fundamental shift in how discovery happens,” says Audra Moran, president and CEO of OCRA. “By bringing patients, researchers, and clinicians into a single, AI-powered ecosystem—and breaking down the silos that have slowed progress for far too long—we are accelerating breakthroughs that can improve care today while driving the discoveries of tomorrow. Powered by AWS Cloud resources, this global AI initiative enables the data-intensive gynecologic cancer research needed to accelerate discovery at unprecedented scale.

The arc of a life, the promise of technology

The organizations spotlighted here represent a powerful truth: When cloud and AI technology are placed in the hands of mission-driven innovators, the impact on women’s health can be transformative.

From adolescence to midlife and beyond, these stories show what’s possible when technology serves women’s health holistically across every stage of life.

Amazon is also highlighting its broader Together framework, a companywide model for connecting customers, employees, and communities through shared Amazon experiences, including in women’s health. One part of that framework, In This Together, creates pathways for communities, organizations, and individuals to access Amazon resources and opportunities.

In healthcare, that includes bringing forward Amazon organizations such as AWS Skilling and Social Impact, which helps connect innovation and partnership to practical pathways that expand access and support stronger outcomes across the health ecosystem.

At AWS, we are committed to supporting this work. We provide cloud technology and technical expertise to organizations working to close the gaps in women’s health research, access, and outcomes.

Learn more about how AWS supports women’s health

Jacaranda Health’s journey to support pregnant people in Africa
Korea University in conducting research on East Asian women’s risk for autism
Social impact
Open Data Sponsorship Program for high-value datasets
Health innovation

*CareIntellect Perinatal, formerly Mural Perinatal Surveillance, a 510(k)-cleared device in the U.S., is the product name. CareIntellect for Perinatal might appear in descriptive content. Not all features and functionality are available in all markets. Product configurations are subject to change without notice. Availability is dependent on regional regulatory authorizations.

What if swapping your weather model was boring? How dynamical.org is making AI weather forecasting accessible on AWS

Marshall Moutenot — Wed, 27 May 2026 22:41:44 +0000

As part of the Registry of Open Data on AWS, AWS invited Marshall Moutenot of dynamical.org to share how their team is making operational weather forecasts easier to use for researchers, developers, and downstream applications.

Weather data can be hard to use

I’ve spent the last 10 years forecasting rivers. As you can imagine, weather (past, present, and future) played an outsized role in how much water is going to flow through a river tomorrow. It also represented an outsized portion of the infrastructure our engineering team had to build.

To train our deep learning foundational hydrology models, we needed to process and store not just the latest forecast, but a vast historical archive in our own cloud. Integrating a new weather model required a big processing effort, which in some cases would take months of arduous backfill (tape data access is slow!).

Integrating new weather models was a primary driver of performance improvements, especially as we expanded globally—but the ingestion effort for each new model was painful enough that it was sometimes hard to justify before we knew the benefits.

With the relatively recent proliferation of AI weather forecasts, the urgency to speed up experimentation was high. That’s when the idea took shape.

In this post, I share how dynamical.org is making weather data products, including AI weather forecasts, accessible on AWS.

It doesn’t have to be hard

We weren’t alone. Talking to organizations ranging from peer startups to giant energy utilities, we realized the challenge of integrating new weather models was widespread. Ease of access was a bottleneck. If we were going to solve it for ourselves, we might as well solve it for everyone.

So we started dynamical.org, a not-for-profit with the mission to advance humanity’s ability to access, understand, and act on accurate weather and climate data. The most useful weather datasets in the world should be as simple to open as any other modern dataset.

No data format spelunking, no renaming files, no parameter name bingo, no reprojecting, and most importantly: no more manually creating a separate ingest pipeline for every model you want to try.

The catalog

dynamical.org hosts a set of the world’s most widely used operational weather forecast models on AWS, each in the same cloud-optimized Icechunk 2.0 Zarr format on Amazon Simple Storage Service (Amazon S3) in the Registry of Open Data on AWS:

US National Oceanic and Atmospheric Administration (NOAA) Global Forecast System (GFS), the US flagship deterministic global model. Four runs per day, 16-day forecasts, hourly steps.
NOAA Global Ensemble Forecast System (GEFS), NOAA’s global ensemble. 35-day forecasts, 31 members. 115 TB compressed, 815 TB uncompressed.
NOAA High-Resolution Rapid Refresh (HRRR). 3 km, hourly, continental US forecast and analysis, going back to 2014.
European Centre for Medium-Range Weather Forecasts (ECMWF) Integrated Forecasting System Ensemble (IFS ENS), the operational European ensemble. 15-day, 0.25°.
NOAA Multi-Radar Multi-Sensor (MRMS), not a forecast, but the merged radar and gauge precipitation analysis over CONUS, hourly, since 2014. Useful for answering “How much did it actually rain here, at this exact hour?”

Each of these comes from a different modeling center, with its own metadata conventions, variable naming, release cadence, and (in the case of ECMWF) its own opinions about European geography. When we re-host them, we normalize: same chunking, same variable names where possible, same coordinate conventions, same access pattern. We create full-history analysis versions of the forecast archives. The goal is that once you have learned how to read one of our datasets, you have learned how to read all of them.

AI weather with a few keystrokes

The latest addition to our catalog, now available on the Registry of Open Data on AWS, marks an exciting milestone. Our existing suite formed the foundation of the most popular traditional numerical weather prediction models. ECMWF’s Artificial Intelligence Forecasting System (AIFS) Single is our first AI weather model—which means, for the first time, you can line up physics-based forecasting with AI-based forecasting side by side, with just a few keystrokes.

The proliferation of AI weather models is, in our opinion, one of the most exciting advancements in weather forecasting of the last decade. Rather than numerically integrating the equations of atmospheric motion on a supercomputer for several hours, AIFS produces a full global forecast in minutes on a single GPU using a neural network trained on decades of reanalysis data. It is competitive with (and on some metrics, frequently ahead of!) the best operational physics-based models.

In the dynamical.org catalog, the AIFS Single dataset looks like the following table.

Spatial Domain	Global
Spatial Resolution	0.25° (~28 km)
Time Domain	Forecasts initialized from ECMWF operational runs to present
Forecast Domain	0–15 days
Forecast Resolution	6-hourly
Format	Icechunk 2 Zarr

And in code, it looks like the following example:

import dynamical_catalog

# Physics-based forecast
gfs = dynamical_catalog.open("noaa-gfs-forecast")

# AI-based forecast
aifs = ds = dynamical_catalog.open("ecmwf-aifs-single-forecast")

Boring, right? Well, that’s the point. We wanted the implementation details of ingesting and aligning the data products to vanish into the proverbial abstraction that “just works.”

Get your hands dirty

To make all of the above concrete, we’ve published a Python notebook that walks through opening different weather models and comparing their outputs.

You can open it in Amazon SageMaker AI, or in Amazon SageMaker Studio Lab if you don’t have an AWS account. We’ve also listed it on the dataset’s Registry of Open Data on AWS page under Tutorials.

In the notebook, we compute heating degree days at Nashville International Airport from both NOAA GFS and ECMWF AIFS, then compare both against hourly ASOS observations. The downstream analysis code is the same in both cases! Swapping in the AI model becomes trivial.

Figure 1: Charts showing 1-day, 3-day, and 5-day lead forecasts comparing GFS and AIFS models against observed heating degree days

Start building

The full catalog (GFS, GEFS, HRRR, IFS ENS, MRMS, and now AIFS Single) is available on the Registry of Open Data on AWS through the AWS Open Data Sponsorship Program.

You can read directly from computer environments that can talk to Amazon S3, from SageMaker, to your laptop, to your cluster.

If you build something interesting, we’d love to hear about it—reach out at feedback@dynamical.org.

Thanks to Chris Stoner and the AWS Open Data team for the sponsorship and collaboration, and to the contributors and supporters of dynamical.org!

Enjoy the weather.

—MM, co-founder, dynamical.org

Introducing US-based, US citizen, 24/7 technical support for AWS GovCloud (US) customers: Your mission never sleeps, neither do we

Drew Calloway — Tue, 26 May 2026 22:02:37 +0000

Starting today, AWS GovCloud (US) customer technical support cases are routed to US-based, US citizens. This means that 24/7, AWS Support will make every effort to ensure your cases are handled exclusively by US-based, US citizens throughout the entire case lifecycle – no opt-in or special request required.

Why this matters for your mission

Government workloads don’t wait for business hours. Federal, state, and local government agencies, along with private companies, non-profits, and academic institutions working with government, operate systems that run continuously. Having 24/7 access to AWS GovCloud (US) cloud support engineers who are US citizens on US soil can mean the difference between service delivery and system failure. To meet these always-on operational demands, AWS services undergo compliance assessments that address the specific conformity requirements government customers require for their mission-critical workloads.

What’s new and how it helps you

Previously, AWS GovCloud (US) technical support cases might be assigned to support engineers outside the US. When access to restricted resources was required in support of the case, US-based engineers were available to assist. Starting today, technical support cases for AWS GovCloud (US) customers are now routed by default to US-based, US citizen cloud support engineers – no action is required from you. This team specializes in supporting workloads across both AWS GovCloud (US) Regions and they are trained in maintaining International Traffic in Arms Regulations (ITAR) compliance and other applicable GovCloud (US) requirements.

Streamlined support experience

Our cloud support engineers are full-time AWS employees who are US citizens based in the US and understand the government context in which you operate. They are familiar with:

ITAR restrictions with recommended Business or Enterprise support plans
Federal Risk and Authorization Management Program (FedRAMP)
The urgency behind mission-critical government applications

Our US-based, US citizen cloud support engineers have the permissions and tools needed to work within AWS GovCloud (US) environments for faster diagnosis and resolution. You can reach the team through channels you’re already using:

Your AWS GovCloud (US) Console
API access for automated support workflows
Click-to-call for urgent issues
Chat support for quick questions

Note on billing and account support: Billing and account questions route through your commercial account and may be handled by non-AWS GovCloud (US) teams. Billing and account questions include invoice inquiries, payment method updates, and account consolidation requests – not technical issues with AWS services or configurations.

Getting started

If you’re already an AWS GovCloud (US) customer, you don’t need to do anything – this support is already active as a general practice for your account. The next time you need technical help, simply open a case through your existing channels:

Log into your AWS GovCloud (US) Console
Navigate to the Support Center
Create a case or use chat/phone for technical support

New to AWS GovCloud (US)? Follow our Getting Started: Sign Up for AWS GovCloud (US) guide to sign up, or contact AWS GovCloud (US) sales for more information.

AWS Support will make every reasonable effort to ensure cases related to AWS GovCloud (US) partitions are handled exclusively by US-based personnel who are US citizens throughout the entire case lifecycle.

Learn more

Ready to experience the difference? Visit AWS GovCloud (US) FAQs – Amazon Web Services to learn more about AWS GovCloud (US) support for your mission-critical operations.

For additional resources:

AWS GovCloud (US) documentation
AWS GovCloud (US) compliance information
Contact your AWS government account team for personalized assistance

Frequently Asked Questions

General Information
Q: What is AWS GovCloud (US)?

A: AWS GovCloud (US) is an isolated AWS region designed to host sensitive data and regulated workloads in the cloud, helping customers support their US government compliance requirements. AWS GovCloud (US) is operated by US citizens on US soil and provides two regions, AWS GovCloud (US-East) and AWS GovCloud (US-West), that are physically and logically separated from commercial AWS regions. It enables government agencies and their partners to meet specific regulatory and compliance requirements, including ITAR, FedRAMP High, DoD SRG, and other federal security standards. Learn more at AWS GovCloud (US) FAQs.

Q: What’s the difference between the AWS GovCloud (US-West) and AWS GovCloud (US-East) Regions?

A: Both regions provide the same level of security and compliance but are geographically separated for redundancy and disaster recovery. Customers can choose the region closest to their operations or use both for enhanced availability.

Security & Compliance
Q: How does AWS GovCloud (US) support compliance requirements?

A: AWS GovCloud (US) is designed to help address specific regulatory and compliance requirements of US government agencies at the federal, state, and local level, as well as contractors, educational institutions, and other U.S. customers that run sensitive workloads in the cloud. The AWS GovCloud (US) Regions help customers to adhere to U.S. International Traffic in Arms Regulations (ITAR), Federal Risk and Authorization Management Program (FedRAMP), and Department of Defense (DoD) Cloud Computing Security Requirements Guide (SRG) Impact Levels 2, 4, and 5. Visit the Compliance Programs page for a complete list of U.S. compliance standards supported by AWS GovCloud (US). Learn more about AWS GovCloud (US) compliance.

Q: How are you protecting my data and my privacy when I use this product?

A: Protecting data is AWS’s top priority. For additional information, please see our Data Privacy FAQs.

Support Operations
Q: Who provides AWS GovCloud (US) technical support and what are their qualifications?

A: Technical support is provided by full-time AWS cloud support engineers who are US citizens based on US soil. They undergo validation of United States citizenship and are trained in maintaining ITAR compliance. They specialize in supporting workloads across both AWS GovCloud (US) Regions.

Q: What are the support hours and channels for AWS GovCloud (US)?

A: Technical support is available 24 hours a day, 7 days a week, including Federal holidays. Customers can submit technical support cases through multiple channels including the Support Console, API access, click-to-call, and chat options.

Q: What counts as a billing or account question versus a technical support question?

A: Billing and account questions include things like invoice inquiries, payment method updates, account consolidation, and subscription management. Technical support covers issues with AWS service functionality, configurations, performance, and errors within your AWS GovCloud (US) environment. If you’re unsure, open a case through your AWS GovCloud (US) console, consult with GovCloud (US) technical support on the matter, and the team will help route it appropriately.

A governance framework for building trustworthy agentic AI for public sector and regulated organizations

Paul Keastead — Tue, 26 May 2026 14:44:52 +0000

Public sector organizations face a growing challenge as they adopt agentic AI systems. They need to confront how to benefit from increased AI autonomy while continuing to meet security, compliance, and accountability expectations. Unlike traditional AI systems that respond to prompts or execute narrowly defined tasks, agentic AI systems can understand context, make decisions, plan multistep workflows, and take autonomous actions. These capabilities introduce governance and risk considerations that existing AI control models don’t fully address.

As agentic AI systems gain the ability to act across systems, data, and services, the consequences of design gaps, misconfiguration, or unintended behavior increase. For organizations operating in regulated environments, this makes governance, auditability, and operational control foundational requirements rather than optional enhancements.

This post outlines a practical governance framework for agentic AI systems, with a focus on public sector and other highly regulated environments. It introduces a scope-based model for classifying agent autonomy, identifies core security dimensions, and describes how organizations can align agentic AI governance with existing risk, compliance, and assurance programs. You’ll learn how to classify AI systems by autonomy level, implement scope-appropriate security controls, and align your governance approach with international standards such as ISO/IEC 42001:2023.

In a future post, we’ll cover the practical implementation steps, including phased rollout, threat modeling, automation, and audit preparation.

This post covers:

How agentic AI systems differ from traditional AI from a governance and risk perspective
A scope-based model for classifying agent autonomy and authority
Six security dimensions that support trustworthy agentic AI systems
How agentic AI governance can align with existing compliance and audit expectations
Amazon Web Services (AWS) service capabilities and compliance posture relevant to agentic AI governance

Understanding agentic AI

Agentic AI represents an evolution from reactive assistants to proactive, autonomous systems that can understand, decide, and act with minimal oversight. These systems access tools, data, and external services to navigate complex tasks, adapt to changing conditions, and collaborate with other agents to accomplish goals.

Two characteristics are especially important for governance:

Autonomy – The degree to which the system can make decisions without human intervention
Agency – The scope of actions the system is authorized to take within its environment

Understanding where your AI systems fall on these dimensions is the first step toward implementing appropriate governance. Treating all AI systems as equivalent can result in either over-constraining low-risk use cases or under-governing highly autonomous systems.

A scope-based approach to agentic AI security

Not all agentic AI systems require the same level of security controls. Applying a single control model across all implementations often leads to unnecessary friction or unaddressed risk. A scope-based classification approach helps organizations match governance controls to actual system capability and impact.

The following framework defines four scope levels based on the degree of agency and autonomy.

Scope 1: No agency

Scope 1 systems operate in read-only or advisory mode. They are human-initiated, follow fixed execution paths, and can’t modify systems or data.

These systems typically analyze information, summarize content, or provide recommendations. Governance is still required, but risk is limited because the system can’t take direct action.

Scope 2: Prescribed agency

Scope 2 systems can propose or prepare changes but require explicit human approval before execution. They might access multiple tools or systems, but a human remains responsible for authorizing each consequential action.

This scope is appropriate for systems that draft policy updates, generate configuration recommendations, or prepare remediation steps for human review.

Scope 3: Supervised agency

Scope 3 systems execute end-to-end workflows after human initiation. They select tools dynamically and can complete tasks autonomously within predefined boundaries. Human oversight remains available through monitoring, intervention points, or escalation paths.

Effective human escalation in scope 3 means the agent can recognize when a situation exceeds its authority or confidence threshold and surface the decision to a human with full context, including what it attempted, why it’s uncertain, and what options it recommends. The human receives enough information to make an informed decision without reinvestigating the situation from scratch.

Examples include systems that respond automatically to defined security events while escalating higher-risk situations for review.

Distinguishing scope 2 from scope 3

The boundary between scope 2 and scope 3 is where many organizations need the most clarity. The following table provides concrete attributes to help classify a system.

Attribute	Scope 2 (prescribed agency)	Scope 3 (supervised agency)
Action execution	Proposes actions; human approves each one before execution	Executes actions autonomously within defined boundaries
Tool selection	Uses a fixed, predefined set of tools	Selects tools dynamically based on context
Data access	Read access to operational data; write access gated by human approval	Read and write access within scoped permissions
Decision authority	Human makes every consequential decision	Agent makes decisions within policy; escalates exceptions
Workflow complexity	Single-step or linear workflows	Multistep, branching workflows with conditional logic
Human involvement	Approval required before each action	Monitoring and intervention available; approval required only at escalation points
Example	Agent drafts a remediation plan and waits for engineer approval	Agent detects a misconfiguration, applies a preapproved fix, and notifies the team

Decision criteria: If the system can execute any action that modifies state without a human explicitly approving that specific action, it’s scope 3 or higher. If every write operation requires a human to review and confirm, it’s scope 2.

Scope 4: Full agency

Scope 4 systems operate with continuous autonomy and can initiate actions without direct human prompting. They might adapt behavior over time and operate independently for extended periods, with humans providing strategic oversight rather than task-level control.

This scope requires the most rigorous governance and is appropriate only where organizations have mature controls, monitoring, and assurance mechanisms in place.

Six security dimensions for agentic AI governance

Regardless of scope level, effective governance of agentic AI systems requires controls across six security dimensions. These dimensions aren’t new security concepts, but agentic systems combine them in ways that increase the impact of gaps or misconfiguration.

Identity context

Agentic systems must operate under clearly defined identities with explicit authorization boundaries. This includes the ability to act on behalf of users or services while maintaining traceability and accountability. With AWS Identity and Access Management (IAM), you can define granular permissions that specify exactly which actions each agent can perform and under what conditions. Strong identity controls help support auditability and help prevent unintended privilege escalation.

Data, memory, and state protection

Agentic AI systems often maintain persistent memory and state across interactions. Protecting this information requires access controls, encryption, and safeguards against unauthorized modification. AWS Key Management Service (AWS KMS) and AWS Secrets Manager help protect sensitive data and credentials that agents access, but they address what the agent can reach, not the integrity of the agent’s own memory.

Memory integrity requires additional controls that protect the agent’s reasoning context from corruption or manipulation:

Memory expiration and retention policies – Define how long agent memory persists and when it must be purged. Short-lived memory reduces the window for memory-based issues and helps prevent stale context from influencing future decisions. Implement time-to-live (TTL) policies on conversation history, session state, and cached tool outputs.
Read-only memory for lower scopes – For scope 1 and scope 2 systems, enforce read-only memory where the agent can reference prior context but can’t modify its own memory store. This helps prevent an agent from being manipulated into rewriting its own instructions or context through adversarial inputs.
Memory isolation between sessions – Prevent cross-session memory contamination by isolating memory stores per user, per task, or per security boundary. An agent processing one user’s request must not carry over context from another user’s session.
Integrity validation – Implement checksums or cryptographic signatures on memory state so that unauthorized modifications to an agent’s stored context can be detected before the agent acts on corrupted data.

These controls become increasingly important as scope increases. A scope 1 system with read-only memory and short TTLs has a limited surface area for issues. A scope 4 system with persistent, writable memory across sessions requires all these protections plus continuous monitoring for memory drift or injection.

Audit and logging

When AI systems act autonomously, comprehensive logging becomes essential. Governance requires visibility into what actions were taken, when they occurred, and the context that led to those decisions.

AWS CloudTrail and Amazon CloudWatch provide visibility into API-level actions and system events, but to capture the full decision context (the reasoning chain that leads to those actions), you must combine these with Amazon Bedrock invocation logging and custom application-level tracing of agent steps.

This distinction matters for governance:

API-level logging (CloudTrail, CloudWatch) – Records what happened, including which APIs were called, by which identity, at what time, with what parameters. This is the foundation for accountability and audit trails.
Decision-context logging (Amazon Bedrock invocation logging, custom tracing) – Records why it happened, including what prompt the agent received, what reasoning it applied, what alternatives it considered, and why it chose a specific action. This is what auditors and incident responders need to understand agent behavior.

For regulated environments, both layers are required. API logs alone can tell you that an agent modified a security group, but decision-context logs tell you what triggered that decision and whether the agent’s reasoning was sound.

Agent and foundation model (FM) controls

Guardrails help prevent agents from producing harmful outputs or executing unsafe actions. These controls might include input validation, output filtering, behavioral constraints, and isolation mechanisms to help limit the scope of impact if a system behaves unexpectedly. Amazon Bedrock Guardrails provides customizable safeguards for content filtering, and process isolation helps keep a compromised agent from affecting other systems.

Agency boundaries and policies

Clear, enforceable boundaries define what an agent can and can’t do. These boundaries must be implemented through technical controls rather than relying solely on policy documentation.

IAM alone provides significant boundary enforcement for agentic systems. IAM policies can restrict which API actions an agent can call, which resources it can access, and under what conditions, such as time of day, source IP, and whether multi-factor authentication (MFA) is present. IAM session policies can further constrain permissions for individual agent invocations, and permissions boundaries can set a maximum privilege ceiling that no policy can exceed. For many scope 1 and scope 2 systems, IAM policies combined with resource-based policies provide sufficient boundary enforcement without additional tooling.

For higher-scope systems, layer AWS Organizations service control policies (SCPs) to establish account-level guardrails that no agent can bypass regardless of its IAM permissions. SCPs help prevent privilege escalation by setting hard boundaries at the organizational level. Explicit limits help reduce the risk of unintended behavior as system autonomy increases.

Orchestration

Agentic systems often rely on orchestration layers to coordinate tools, services, and other agents. AWS Step Functions provides workflow orchestration with built-in approval gates and state management, helping you maintain control over complex multi-agent workflows. Structured workflows, approval gates, and state management help maintain control over complex interactions and support consistent governance across implementations.

Aligning agentic AI governance with ISO/IEC 42001

ISO/IEC 42001:2023 provides an internationally recognized management system framework for responsible AI use. Organizations can align agentic AI governance with this standard by mapping the six security dimensions to specific Annex A controls.

Security dimension	ISO 42001 Annex	Alignment
Identity context	Annex A.9 (responsible AI use)	Agent identity, authorization boundaries, and traceability support responsible use requirements
Data, memory, and state protection	Annex A.7 (data for AI systems)	Memory retention policies, data governance, and integrity controls map to data management requirements
Audit and logging	Annex A.6 (AI system lifecycle, monitoring)	Decision-context logging and API-level audit trails support lifecycle monitoring and accountability
Agent and FM controls	Annex A.4 (AI system impact assessment)	Guardrails, output filtering, and behavioral constraints support impact assessment and risk mitigation
Agency boundaries and policies	Annex A.5 (AI system policies)	IAM policies, SCPs, and technical boundary enforcement implement organizational AI policies
Orchestration	Annex A.8 (AI system operation)	Workflow controls, approval gates, and state management support operational governance

This mapping helps organizations build governance frameworks that satisfy both technical security needs and compliance requirements simultaneously, without creating parallel control structures. If you already maintain an ISO 42001 management system, the six-dimension model provides a technical implementation layer that maps to your existing control objectives.

AWS compliance posture for agentic AI workloads

Organizations building agentic AI systems in regulated environments need to understand the compliance posture of the underlying services. Amazon Bedrock is the primary AWS service for building agentic AI applications, and its authorization status determines which FMs you can use within your compliance boundary.

Amazon Bedrock FedRAMP authorization

Amazon Bedrock is a Federal Risk and Authorization Management Program (FedRAMP) High authorized service in the AWS GovCloud (US-West) Region and is FedRAMP Moderate authorized in the US East and US West commercial AWS Regions. This means organizations with FedRAMP High requirements can build agentic AI systems in AWS GovCloud (US), and those operating under FedRAMP Moderate can use commercial Regions.

Not all FMs available in Amazon Bedrock carry the same authorization status. For a current list of which Amazon Bedrock FMs are FedRAMP Moderate and FedRAMP High authorized, refer to the Amazon Bedrock models – FedRAMP authorization status page. This page is updated as new models receive authorization. For more information about the overall FedRAMP scope of AWS services, refer to AWS Services in Scope by Compliance Program.

When selecting FMs for agentic systems in regulated environments, verify that your chosen model is authorized at the appropriate FedRAMP level for your use case. A governance framework is only as strong as the compliance posture of the services it relies on.

Data protection in Amazon Bedrock

Your data remains under your control. With Amazon Bedrock, your content isn’t used to improve base models and isn’t shared with model providers. This is a critical consideration for agentic systems that process sensitive data because agent memory, conversation history, and tool outputs constitute data that must remain within your compliance boundary.

Supporting compliance standards

Beyond FedRAMP, AWS supports a broad set of security standards and compliance certifications relevant to agentic AI workloads, including FIPS 140-2 and NIST 800-171. Organizations subject to these requirements can build agentic AI systems on AWS while maintaining their compliance posture, provided they implement appropriate controls at the application layer (which is where the six security dimensions and scope model from this post apply).

Conclusion

If you’re planning to deploy agentic AI in a regulated environment, the time to establish governance is before your first agent goes into production, not after an audit finding forces the conversation.

Start by inventorying every AI system in your environment and classifying it using the four-scope model. Most organizations find they already have scope 1 and scope 2 systems they haven’t formally categorized. After completing that inventory, evaluate your current controls against the six security dimensions. Pay particular attention to audit logging and agency boundaries because these are the areas where existing IT governance frameworks have the largest gaps for agentic systems.

Rather than jumping straight to scope 4, build your governance muscle with prescribed-agency systems where a human still approves every consequential action. Use what you learn to calibrate controls for higher-autonomy systems over time.

The scope-based model in this post isn’t a theoretical exercise. It’s a classification system you can apply to your current AI inventory this week and use to make concrete decisions about what controls each system needs.

Next steps and resources

AWS Security Assurance Services – Engage with a trusted advisor to establish agentic AI governance and support your ISO 42001 certification efforts.
Amazon Bedrock Security and Privacy – Learn about security features, compliance certifications, and data protection capabilities in Amazon Bedrock.
OWASP Top 10 for Large Language Model Applications – Community-driven framework for identifying and mitigating risks specific to large language model (LLM) based applications.

Amazon Web Services Partner KBR achieves 27% savings migrating to AWS Graviton

Brian McGuire — Tue, 26 May 2026 14:28:32 +0000

Organizations processing satellite imagery at scale can significantly reduce infrastructure costs while improving performance by migrating to instances based in Amazon Web Services (AWS) Graviton.

In this post, you’ll learn how KBR—a global science, technology and engineering solutions organization—achieved a 33.5% cost savings and a 27.09% increase in pipeline processing speed by migrating geospatial processing workloads from an x86 Amazon Elastic Compute Cloud (Amazon EC2) M7i instance to AWS Graviton processors. This was accomplished while maintaining data accuracy within 0.002% of x86 outputs.

Rising costs for geospatial processing at scale

If you process massive volumes of satellite imagery for Earth observation and scientific analysis, you understand the computational demands of transforming raw sensor data into analysis-ready geospatial products.

KBR faced increased projected processing needs through 2040, prompting the identification of cost-effective infrastructure solutions without compromising performance or data quality.

Traditional x86-based processing infrastructure delivered reliable results, but rising computational demands meant escalating costs. KBR evaluated whether AWS Graviton instances could provide a viable alternative by reducing the total cost of ownership while maintaining or improving processing speeds.

Performance testing across multiple processor types

KBR evaluated different AWS instance types to compare AWS Graviton and x86 performance: M7i, M7a, M7g, and M8g. Each instance processed identical scenes through cold cache and warm cache trials to measure real-world performance across all processing stages.

The testing revealed that Advanced RISC Machine (ARM)-based instances consistently matched or exceeded x86 performance. The M8g instance powered by AWS Graviton4 delivered the strongest results, processing imagery 27.09% faster than the M7i baseline. The M7g instance with AWS Graviton3 achieved 12.89% better performance, and the Advanced Micro Devices (AMD) EPYC-based M7a showed 19.38% improvement over M7i powered by Intel Xeon Scalable processors. These results are illustrated in the following graphs:

Figure 1: Performance percentages illustrated per instance

Network performance testing confirmed that M8g delivered the highest download and upload speeds among all tested instances. This advantage proved particularly valuable for workloads involving large data transfers from Amazon Simple Storage Service (Amazon S3).

AWS services power the solution

KBR’s geospatial processing pipeline uses multiple AWS services to deliver cost-effective, high-performance results:

AWS Graviton processors are optimized for price performance
Amazon Elastic Kubernetes Service (Amazon EKS) orchestrates containerized processing workloads
Amazon S3 stores raw satellite imagery and processed outputs
AWS Lambda handles event-driven processing tasks
Amazon EC2 Spot Instances reduce costs for fault-tolerant workloads

The migration required implementing multi-architecture Docker builds supporting both AMD64 and ARM64, updating GitLab runners for ARM64 compatibility and configuring Amazon EKS node groups with ARM instance types.

Cost savings and performance gains

The financial impact of migrating to AWS Graviton proved substantial: M8g instances cost $0.1795 per hour compared to $0.2016 for M7i instances, an 11% reduction in hourly costs while delivering 27% faster processing.

When you project these savings from 2026 to 2040, switching to the M8g would reduce total processing costs by 27.4%, saving $1,907,723.11 and bringing total costs down from $6.97 million to $5.06 million. This calculation doesn’t include gains from newer versions of AWS Graviton.

Data validation confirmed the migration maintained scientific accuracy. Pixel-by-pixel comparison of AWS Graviton and x86-generated GeoTIFF outputs showed only 0.002% difference. This is well within acceptable tolerances for geospatial analysis. Both radiometric precision and geometric accuracy remained consistent across processor architectures, attesting to the robustness of the software underlying the methods. These results are illustrated in the following image:

Figure 2: AWS Graviton and x86 output comparison

Dual-architecture support implementation approach

KBR’s migration strategy supports both AWS Graviton and x86 architectures to maintain flexibility. Implementing the first subsystem required an estimated 136 hours, including 56 hours for general infrastructure updates (GitLab runners, Amazon EKS Karpenter configuration, multi-architecture Docker builds, Lambda functions and continuous integration and continuous delivery pipeline enhancements) plus 80 hours for subsystem-specific work, split evenly between regression testing and Dockerfile refactoring).

The recommended deployment model uses M7g instances for persistent workloads and M8g instances for ephemeral tasks, enabling dynamic cost optimization while maintaining backward compatibility with x86 when needed.

Broader implications for geospatial processing

KBR’s successful proof of concept demonstrates that AWS Graviton processors deliver immediate value for compute-intensive geospatial workloads. If you process satellite imagery, LiDAR data or other large-scale geospatial datasets, you can achieve similar cost reductions and performance improvements by migrating to AWS Graviton.

The combination of lower hourly costs, faster processing speeds, enhanced security features and validated data accuracy makes AWS Graviton an attractive option for government agencies, research institutions and commercial organizations operating geospatial processing pipelines at scale.

Conclusion

KBR achieved a 27% cost savings and significant performance improvements by migrating geospatial processing workloads to AWS Graviton. If you use a similar approach—evaluating multiple instance types, implementing multi-architecture support and using Amazon EC2 Spot Instances—you can optimize your compute-intensive workloads for better price performance while maintaining data accuracy.

Ready to explore how AWS Graviton can reduce costs for your compute-intensive workloads? Visit AWS Graviton to learn more about ARM64-based processors optimized for price performance. You can also review the AWS Graviton documentation for migration best practices and architecture-specific considerations.

For geospatial processing solutions, explore the Registry of Open Data on AWS to discover how AWS services support satellite imagery analysis, remote sensing applications and location-based intelligence at scale.

How agentic AI can accelerate the federal rulemaking lifecycle

Sanjeev Pulapaka — Mon, 25 May 2026 22:35:03 +0000

Each year, federal agencies issue thousands of final rules through the Federal Register, which recently reached a record number of pages in a single year. Behind each rule is one of the most document-intensive processes in government—a journey through eight phases spanning research, drafting, clearance, public comment, analysis, revision, approval, and publication. Complex rules can take years from proposal to implementation, limiting every agency’s ability to respond to emerging safety, environmental, financial, and labor challenges.

Three bottlenecks consume most of that time: Notice of Proposed Rulemaking (NPRM) development and internal clearance, public comment analysis, and final rule clearance. Of these, comment analysis is the most severe bottleneck—agencies can receive hundreds of thousands of submissions, some containing thousands of pages of detailed analysis, and this single phase can stretch well over a year. Many agencies have invested in tools to manage comment volume, particularly for identifying duplicates using keyword matching or basic natural language processing (NLP). But these tools detect textual similarity only—they miss comments that make the same substantive argument in entirely different language or organized campaigns that vary wording to evade matching.

Agentic AI offers a fundamentally different approach. Agentic AI deploys multiple specialized agents that collaborate across the full rulemaking lifecycle—each with a focused role, access to authoritative sources, and the ability to hand off to the next. Critically, these agents can also understand intent and context, not merely match text. For comment analysis, this means agents can review entire sets of submissions to understand the substantive arguments being made, identify true duplicates regardless of how they’re worded, and surface the unique comments that require a response.

Amazon Web Services (AWS) is working with federal agencies to explore how this approach can meaningfully compress rulemaking timelines while maintaining regulatory quality and public participation requirements.

Where agentic AI fits across the lifecycle

The eight phases of rulemaking group naturally into four capability clusters where agentic AI can deliver the greatest impact. Within each cluster, specialized agents replicate the division of labor that already exists in practice—researchers, drafters, and reviewers are different people with different expertise—while operating at machine speed. The four capability clusters are:

Pre-rulemaking and research synthesis – Agents can continuously monitor safety databases, inspector general reports, legislation, court decisions, and stakeholder petitions, flagging issues that warrant regulatory attention. Agentic systems can independently formulate research strategies, query multiple information sources, synthesize findings across disparate datasets, identify gaps in available information, and compile baseline data for regulatory impact analysis. This autonomous navigation of information landscapes can dramatically accelerate the preliminary research phase.
NPRM development – Agents can generate initial regulatory text from policy outlines, produce preamble language citing statutory authority, create technical specifications based on engineering standards, cross-reference existing regulations for consistency, and format documents to Federal Register style. A separate compliance agent can review drafts against the Administrative Procedure Act (APA), applicable executive orders governing regulatory review, and agency-specific requirements, verifying that all required analyses are complete, citations are correct, and potential legal vulnerabilities are flagged before the draft moves to clearance.
Public comment analysis – Agentic AI can move agencies beyond existing tools in ways that benefit both the agency and the public. Agents can identify comments that make the same substantive argument regardless of phrasing, catch coordinated campaigns that vary wording to evade matching, and distinguish between genuinely unique comments and paraphrased duplicates. Rather than waiting until the comment period closes, agents can monitor incoming submissions in real time—clustering by theme, flagging emerging campaigns, and giving agencies a head start on what is typically the longest phase. On the public side, an AI assistant could help citizens structure their feedback more effectively, identifying whether a similar comment already exists, suggesting how to frame novel arguments, and ensuring submissions address the specific questions posed in the NPRM.
Final rule, clearance, and publication – Agents can revise regulatory text to incorporate comment-driven changes, generate comprehensive responses to comments, coordinate parallel reviews across divisions, and track the clearance workflow through departmental and Office of Information and Regulatory Affairs (OIRA) review. Version control across multiple review iterations—a persistent pain point in complex rulemakings—becomes an automated capability. Finally, agents can ensure the finished rule meets Federal Register publication formatting and compliance standards before submission.

The following graphic illustrates these capability clusters, with agentic AI capabilities mapped to each. Specialized agents serve focused roles across the full lifecycle.

Figure 1: The eight phases of federal rulemaking grouped into four capability clusters

Orchestrating the workflow itself

Another advantage with agentic AI is its ability to manage the operational complexity of rulemaking itself. Traditional robotic process automation follows rigid preset rules and breaks when processes change. Agentic AI uses contextual reasoning to understand situations, make judgment calls within defined parameters, and adapt in real time.

For federal rulemaking, this means an agentic system can autonomously manage the sequential dependencies and parallel workflows that characterize the regulatory process:

Phase transitions – Monitor the status of each rulemaking phase, identify when prerequisites for the next phase are complete, and initiate handoffs automatically.
Intelligent document routing – Route documents to appropriate reviewers based on content analysis and subject matter expertise rather than relying on manual assignment or fixed distribution lists.
Interagency coordination – Coordinate parallel activities such as simultaneous interagency consultations, schedule and manage review meetings, consolidate feedback from multiple reviewers, and identify conflicting recommendations requiring resolution.
Stakeholder management – Track which stakeholders have submitted comments, identify additional stakeholders who should be consulted based on the regulatory topic, send automated status updates, maintain communication logs for transparency and accountability, and flag concerns requiring senior leadership attention.
Exception handling – Intelligently recover from unexpected conditions—missing information, conflicting feedback, deadline changes, personnel transitions—finding alternative paths rather than failing.

Crucially, these agents maintain comprehensive audit trails of all actions taken, providing the traceability that regulated environments demand.

In the following graphic, an agentic orchestrator on Amazon Bedrock coordinates specialized agents, manages workflow capabilities, draws from authoritative knowledge bases, and escalates to human oversight for substantive policy decisions.

Figure 2: The autonomous orchestration layer

Grounding agents in Amazon Bedrock Knowledge Bases makes AI-generated content traceable to authoritative sources rather than relying on model training data alone. Amazon Bedrock provides flexible deployment options for agentic workloads, from open frameworks like the Strands Agents SDK running on Amazon Bedrock AgentCore to fully managed deployments through Amazon Bedrock Managed Agents. Either way, agents provide natural checkpoints between phases so you can rerun research without regenerating the draft or revise compliance checks without repeating upstream work.

Governance and human oversight

Deploying AI in rulemaking demands a governance framework that is as deliberate as the regulatory process itself. Under current Office of Management and Budget (OMB) guidance, agencies must implement minimum risk management practices for high-impact AI, including pre-deployment testing, impact assessments, ongoing monitoring, and human oversight mechanisms.

The key principle is that agentic AI can autonomously manage workflow routing, document tracking, stakeholder coordination, and content generation, but human experts must retain decision-making authority for substantive policy questions, regulatory interpretations, and responses to significant public comments. This boundary is not a limitation of the technology. It reflects the reality that rulemaking involves judgment calls that carry legal weight, and the public has a right to know that those judgments are made by accountable human decision-makers.

Agencies should establish clear use policies specifying which tasks are appropriate for AI assistance, create quality assurance processes to detect and correct AI errors, ensure transparency about AI use in the rulemaking process, and train staff on effective AI oversight. The goal is augmentation, not replacement, which frees experts from mechanical processing so they can focus on the policy judgments that require human insight.

A phased approach for agency leaders

Implementing agentic AI for rulemaking doesn’t require an all-or-nothing commitment. Agencies can build capability in stages:

Augment existing tools – Enhance comment deduplication with semantic understanding, add real-time monitoring during open comment periods, and deploy AI for document formatting and Federal Register compliance. These are high-volume, lower-risk applications that deliver immediate value while building organizational confidence.
Agentic drafting and analysis – Introduce specialized agents for NPRM development—research agents grounded in authoritative knowledge bases, drafting agents for regulatory text and preambles, and compliance agents for legal review. Expand comment analysis to include substantive summarization, preliminary response drafting, and commenter-facing AI assistance.
Full lifecycle orchestration – Deploy the complete multi-agent pipeline from pre-rulemaking research through final clearance, with an orchestrator coordinating phase transitions, managing parallel reviews, handling exceptions, coordinating stakeholder communications, and maintaining an auditable record of every decision point.

Getting started

Federal rulemaking is structured, document-intensive, and high-impact—a natural fit for agentic AI. The technology is mature enough for deployment in lower-risk applications today, with more sophisticated capabilities following as agencies gain experience. To explore how these workflows can transform your agency’s regulatory operations, visit Amazon Bedrock or contact your AWS account team.

Building an editorial AI assistant to support peer review with AWS Generative AI Innovation Center

Ian Mulvany — Fri, 22 May 2026 14:18:44 +0000

This post was written with Ian Mulvany and Helen Macdonald from the BMJ (British Medical Journal).

For over 185 years, BMJ Group has advanced its purpose to improve health outcomes by working toward a vision of a healthier world for all. It does this mainly by publishing peer reviewed, evidence-based research across a portfolio of nearly 70 scientific and allied health journals, led by its flagship title, The BMJ.

In partnership with the AWS Generative AI Innovation Center, BMJ Group has developed an AI-powered editorial assistant designed to help journal editors screen submitted research manuscripts to make better decisions about which papers to send for further peer review, which to reject, and why. The tool also aims to improve article capture rates without compromising publication quality.

“Working with the Generative AI Innovation Center has given us the technical foundation to move quickly while maintaining the rigor that healthcare and medical research domains demand. This partnership went beyond technology: the Generative AI Innovation Center team worked closely with us in navigating the complexities of applying AI to scholarly publishing. AI can be a powerful ally in this domain, but only if we approach the opportunity with appropriate humility about the importance of the work.” — Ian Mulvany, Chief Technology Officer, BMJ Group

The challenge of finding quality research in a sea of submissions

BMJ Group’s journal portfolio receives tens of thousands of manuscript submissions annually. The editorial assessment and peer review process of submitted manuscripts lies at the core of the Group’s operations. This process is a rigorous, multistage quality control mechanism, typically spanning 3–6 months, where several independent experts evaluate each manuscript’s methodology, validity, and significance.

Two interconnected challenges define the operational reality:

1. Optimizing peer review through better upstream screening – Currently, around half of submissions are rejected at initial editor screening, but a further significant percentage are rejected after peer review. This high downstream rejection rate signals that issues are passing through early screening undetected, consuming valuable reviewer and editorial time. Where submissions are rejected, editors should also articulate reasons for rejection to authors.
2. Better placement of manuscripts across the portfolio – With a broad portfolio of nearly 70 journals across the Group, BMJ editors also face the challenge of identifying suitable homes for manuscripts that might not fit their journal’s scope. Without a cross-portfolio transfer system with defined criteria, rejected manuscripts often require rescreening by the receiving journal. In all, 16% of manuscripts rejected without a transfer offer go on to be published elsewhere; a proportion of these articles could potentially have found a home within the Group’s portfolio.

A human-centered agentic AI assistant

Peer review remains fundamental to trustworthy research. Today, agentic AI solutions have the potential to help the editor make better informed decisions earlier in the process. From the outset, we established two design principles: the AI assistant should augment the work of editors, not replace their judgment, and editors must retain full autonomy over all screening decisions.

These principles, together with BMJ Group’s embedded subject matter experts and editors, guided our joint proof of concept (POC) collaboration.

The resulting Editorial AI Assistant delivers structured, evidence-backed analysis that would otherwise require substantial manual review. The generated analyses are accompanied by detailed source attribution and reasoning. From a technical perspective, the solution uses a multi-agent architecture comprising eight specialized agents, built on Amazon Bedrock AgentCore:

Scope and content fit agent – Assesses alignment with the target journal’s themes based on internal editorial guidelines.
Novelty and impact agent – Contextualizes submissions against existing literature by querying OpenAlex and PubMed to assess originality.
Methodology reporting agent – Evaluates study design and methodological flaws against EQUATOR (specifically, CONSORT, STROBE, and PRISMA) and CASP guidelines.
Methodology validation agent – Generates and executes code to verify statistical claims directly from the manuscript.
Ethics and compliance agent – Verifies basic research ethics and regulatory standards.
Author integrity agent – Consolidates signals from PubPeer, ORCID, and other databases to flag authorship concerns, such as conflicts of interest.
Synthesis agent – Combines findings from the evaluation agents to produce recommended actions.
Writer agent – Provides coherent editorial commentary based on the outputs of the Synthesis agent.

Each agent is powered by Claude by Anthropic in Amazon Bedrock models with tools tailored to its task. AWS Step Functions orchestrates the pipeline, with gatekeeper logic enabling early exit when a manuscript is clearly out of scope, saving compute and editor time. The agents connect to external systems through the Model Context Protocol (MCP), providing a standardized interface for tool use through Amazon Bedrock AgentCore Gateway.

The following diagram illustrates the solution architecture.

Figure 1: High-level architecture of the Editorial AI Assistant

Early results produced encouraging signs

Initial testing across 21 manuscripts with editors from Emergency Medical Journal (EMJ) and BMJ Open demonstrated encouraging results, with particular strength in methodology review and novelty assessment. Editors validated the practical value of surfaced insights. The solution supported deeper analyses that wouldn’t have been achievable at the editor screening stage due to time constraints. Beyond the POC, further efforts would focus on output focus and succinctness.

The POC solution achieved over 80% success rate across three technical evaluation dimensions: accuracy of flagging known errors, detection of fundamental methodological flaws, and the degree of alignment between AI generated recommendations and actual publishing outcomes.

The following bar graph illustrates the solution evaluation results. It shows mean helpfulness ratings with 95% bootstrap confidence intervals, as rated by practicing editors, for each agent. The methodology agents scored highest (above 3.0), followed by the investigative agents (novelty and integrity), with the gatekeeper agents (scope and ethics) scoring lowest (around 2.0). The methodology and gatekeeper groups have non-overlapping confidence intervals.

Figure 2: BMJ Editor solution evaluation results

Implications for agentic AI adoption in academic publishing

This work has reinforced that AI in scholarly publishing must be developed with its users, not deployed upon it. Our key learnings are:

1. Cocreate using scholarly best practices – Cross-functional teams of editors and publication integrity specialists worked alongside technologists from the start, jointly defining evaluation criteria, reviewing agent outputs, and providing rapid feedback that guided iterative improvement.
2. Decompose complex workflows into focused tasks – Specialized agents, each responsible for a single evaluation dimension, produced more reliable and actionable outputs than a single broad evaluation.
3. Predictable workflows build editorial trust – A multi-agent workflow pattern, designed to mirror the editor’s workflow, reflected the priorities of the academic publishing domain where consistency, predictability, and auditability are valued more highly than flexibility. This workflow is shown in the following flow diagram.

Figure 3: High-level overview of the workflow multi-agentic pattern powering the Editorial AI Assistant

3. Structure drives quality – Agents performed best when evaluating manuscripts against well-defined standards such as reporting checklists, and editors valued structured outputs with clear reasoning and source attribution most. Where evaluation required nuanced judgment built from years of editorial experience, the agentic AI solution has less reliable outputs. This reinforces that AI solutions should augment editorial expertise, not fully automate it.
4. Presentation shapes trust – Outputs should be structured to let editors scan top-level findings quickly and drill into detailed reasoning and sources where warranted—surfacing complexity on demand rather than all at once.

Scaling from POC into practice

This project has validated that AI might meaningfully support editor screening while respecting scholarly best practices. BMJ Group envisions further development, additional testing, and integration with their ScholarOne manuscript management system. Eventually, this tool might be extended to serve peer reviewers beyond initial editor screening.

For stakeholders considering similar AI initiatives, this collaboration offers clear lessons on thoughtful AI adoption in this domain: start with defined success metrics, maintain human expertise at the center, instill transparency in AI-assisted decision-making, and collaborate with technology providers who are prepared to dive deep to understand your unique requirements.

To learn how AWS can help your organization build AI-powered solutions, contact the AWS Generative AI Innovation Center.

AWS at Locked Shields 2026: Strengthening Allied Cyber Defence at Scale

Thomas Gray — Fri, 22 May 2026 14:11:31 +0000

For the third consecutive year, Amazon Web Services (AWS) is delighted to support Locked Shields – the NATO Cooperative Cyber Defence Centre of Excellence’s (NATO CCDCOE’s) premier live-fire cyber defence exercise. Locked Shields is a demonstration of how commercial cloud capabilities can directly strengthen collective security, at a moment when the cyber threat landscape has never been more complex.

Training at the Speed and Scale of Modern Cyber Threats

Locked Shields 2026 brought together more than 4,000 cyber defenders from over 40 nations, organised into 16 blue teams, testing their ability to protect critical IT systems and infrastructure against more than 8,000 sophisticated, real-time cyberattacks. AWS provided the cloud backbone for more than half of the virtual machines running in the exercise environment. More than 50 AWS accounts were vended for the teams, each with multiple web and other applications to defend from red team attackers. The scale of this exercise demands hyperscale, resilient infrastructure. AWS delivered the compute, networking, and security services that allowed defenders to train in conditions mirroring the contested environments they will face in the real world. AWS specialist teams were also engaged on the ground, providing technical support and enablement directly to NATO CCDCOE and the training audience throughout the exercise – accelerating the development of critical cloud skills across NATO allies and likeminded nations.

“Exercise Locked Shields 2026 demonstrated that cyber defense is no longer the responsibility of governments or militaries alone. Critical resilience emerges only when industry, government, and military organizations train, experiment, and innovate together under realistic pressure. In the cyber domain, trust, interoperability, and adaptation cannot be improvised during a crisis — they must be built through continuous collective exercises. AWS’s participation in the exercise is a good example of doing what is needed to face crises and challenges in and or through cyberspace,” said LTC Teet Laeks, Locked Shields 2026 deputy director.

Proven under fire – Realising security and Innovation in the Cloud

Blue teams used AWS-native security tooling throughout the exercise, utilising Amazon Inspector for container vulnerabilities, Amazon GuardDuty for threat detection, and AWS Security Hub CSPM for centralising security events as well as other third party and open source tools. Under live-fire pressure, defenders chose AWS tooling due to the operational credibility of AWS security services in contested environments. The red team, meanwhile, used more than 100 AWS CloudFront deployments to host Command and Control infrastructure during the exercise – an inventive use of CloudFront to disguise C2 traffic.

“Locked Shields is central to cyber resilience planning across NATO. 2026 most successful ever. Across 2 days of sustained attack, AWS infra reported 0 downtime and 0 incidents.”

Security is Job Zero

AWS’s engagement with Locked Shields reflects broader AWS strategy: security is not a feature – it is the foundation of cloud adoption for multinational and national security & defence organisations. Across AWS, thousands of security professionals continuously monitor and automate responses to attack patterns across millions of global customers. The depth of operational security experience is what enables AWS to stand out for the defence community – we provide exceptional security without compromising the innovation that makes cloud transformative.

At the time of writing, AWS supports 143 security standards and compliance certifications and attestations helping customers satisfy compliance requirements around the globe. This breadth of compliance coverage means defence and national security organisations can meet their most stringent data security obligations while operating under the AWS shared responsibility model – retaining control and the flexibility to deploy the services they need.

A Strategic Partnership for Collective Cyber Resilience

Our partnership with NATO CCDCOE positions AWS as the trusted cloud platform for cyber defence training across the NATO alliance and likeminded nations. AWS supports NATO’s digital transformation objectives by demonstrating – at operational scale – how commercial cloud capabilities can enhance national security & defence operations. As cyber threats grow in sophistication and scale, AWS remains committed to providing the infrastructure, expertise, and security architecture that nations need to defend, adapt, and prevail.

To learn more about AWS for Defence and National Security, visit aws.amazon.com/government-education/defense.

Intelligent energy systems that serve tactical forces

Ignacio Solis — Thu, 21 May 2026 19:37:42 +0000

Fuel convoys are among the most dangerous missions in modern warfare. Every resupply run exposes personnel to significant risk while consuming logistics capacity that could support primary mission objectives. Yet tactical forces have long operated power systems without the telemetry and analytics that commercial utilities consider standard—leaving commanders to make energy decisions without visibility into consumption patterns, generator health, or remaining operational capacity.

The Department of War (DoW) has identified this capability gap as a strategic vulnerability. Amazon Web Services (AWS), working with Sentient Industries, addressed it directly by developing an intelligent energy management system that connects tactical power assets to cloud-based analytics and machine learning (ML). The Technology Readiness Experimentation (T-REX) 26-1 exercise at Camp Atterbury, Indiana, validated this approach in December 2025, demonstrating real-time monitoring, predictive analytics, and automated optimization across 20 technologies operating simultaneously.

Operating energy systems blind creates visibility gap

Modern military operations depend on reliable electrical power. Communications systems, computing platforms, sensor networks, and weapon systems all require continuous energy supply. However, supplying energy is only half of the problem. Without telemetry infrastructure, field commanders can’t see consumption patterns, generator health status, or remaining operational capacity in real time.

This visibility gap forces a difficult choice: over-provision resources and increase the logistics burden, or risk mission failure through power shortages. In addition, maintenance occurs on fixed schedules rather than actual equipment conditions. Energy planning relies on historical averages rather than predictive models informed by current operational tempo. The result is more frequent and potentially unnecessary resupply missions in contested environments.

Cloud-integrated energy management closes visibility gap

AWS and Sentient Industries built an architecture that connects Sentient’s Modular Energy for Tactical Expeditionary Operations Resource (METEOR) system to AWS Cloud services, creating a complete pipeline from the tactical edge to actionable intelligence in the cloud.

AWS IoT Greengrass provides an edge runtime on METEOR power modules, hosting custom software components that collect, transform, and transmit telemetry to an Amazon Kinesis stream in the AWS Cloud. Transmission occurs over dual transport paths, with cellular as the primary link and Iridium satellite as a fallback for communications-challenged environments. AWS provided IoT Greengrass components, stream manager and disk spooler, provide complementary resilience. Stream manager buffers and manages export of data streams to cloud destinations, and disk spooler persistently queues MQTT messages to disk, preventing telemetry from being lost during outages of either pathway and automatically resuming delivery after connectivity is restored.

These components publish telemetry into an Amazon Kinesis Data Streams pipeline, which ingests and streams incoming data points for parallel downstream processing. AWS Glue performs extract, transform, and load (ETL) operations, normalizing sensor data before loading it into Amazon Timestream, a purpose-built time-series database optimized for Internet of Things (IoT) and operational telemetry workloads. Amazon Quick Sight connects directly to this data store to provide operational dashboards showing energy posture across deployed systems. AI-powered analytics, driven by Amazon Bedrock, deliver predictive maintenance recommendations and consumption forecasts based on historical patterns. AWS Wickr provides secure, encrypted coordination of power distribution decisions across tactical networks.

The architecture sends Cursor-on-Target data (as defined by MIL-STD-6090) to common operational picture tools, such as Team Awareness Kit (TAK) and Accenture’s Ageon, to provide geospatial energy awareness. Operators can view power system status through tactical map overlays showing generator locations, current output, fuel levels, and predicted operational duration.

The following diagram is the IoT telemetry system architecture, showing edge devices to AWS Cloud integration. The diagram depicts a telemetry module with cellular modem (4G connectivity and GPS) and Iridium 9704 satellite modem connected using USB and universal asynchronous receiver-transmitter (UART) interfaces. Data flows through dual transport paths—with 4G cell provider as primary and Iridium satellite as fallback—to AWS Cloud services including Kinesis Data Streams and IoT Greengrass deployment. The architecture includes battery systems connecting through a switch to tactical command systems using TAK Server and a local tactical microgrid (TMG) monitor for operational awareness.

Figure 1: IoT telemetry system architecture

T-REX 26-1: Field validation

The T-REX 26-1 exercise, led by the Office of the Under Secretary of War for Research and Engineering, tested these capabilities under demanding operational conditions over 2 weeks in December 2025. The exercise engaged multiple sensor technologies, counter-unmanned aerial system (UAS) operations, and tactical command systems in scenarios designed to stress energy resilience.

The Sentient and AWS solution supplied electrical power to 20 different technologies simultaneously throughout the exercise, with 14 technologies actively demonstrating capabilities ranging from electronic warfare systems to autonomous aerial platforms. Tactical operators gained real-time visibility into consumption patterns, generator health metrics, and remaining fuel capacity through Amazon Quick Sight dashboards and TAK map overlays. Logistics officers received advance notice of projected fuel requirements through Amazon Bedrock forecasting, supporting proactive resource allocation to help prevent shortages. The dual-path communications architecture maintained data flow throughout the exercise, validating resilience in contested communications scenarios.

The following diagram illustrates the AWS Cloud data processing pipeline from raw telemetry to analytics and user dashboard. The diagram shows data ingestion through Iridium message staging and Kinesis Data Streams, processing through AWS Lambda and AWS Glue for normalization, storage in Amazon Timestream and Amazon Relational Database Service (Amazon RDS) for PostgreSQL, and analytics delivery through Amazon Quick Sight. Amazon EventBridge provides event-driven alerts, and Amazon Bedrock powers predictive analytics. The architecture includes secure communications using AWS Wickr, with components deployed in a virtual private cloud (VPC) endpoint featuring NAT Gateway, Application Load Balancer, Amazon Elastic Container Service (Amazon ECS) with Amazon Elastic Container Registry (Amazon ECR), Amazon DynamoDB, and Amazon API Gateway connected through Amazon VPC interface endpoints.

Figure 2: AWS Cloud data processing pipeline architecture

Operational impact

The validated architecture delivers six operational advantages for forces in contested environments:

Extended operational duration – Intelligent load balancing and consumption optimization reduce the frequency of tactical energy system recharging and replacement, decreasing dependence on auxiliary fossil fuel–based power sources. This directly reduces both fuel resupply convoys and battery swap logistics, cutting the overall sustainment footprint and enabling units to operate longer on existing energy resources.
Enhanced situational awareness – Real-time telemetry eliminates the energy blind spot in tactical planning. Commanders incorporate power considerations into tactical decisions with confidence in their energy posture.
Reduced logistics burden – Predictive analytics enable more accurate forecasting of energy resource requirements—including fuel consumption and battery replacement intervals—reducing the safety margins required to account for uncertainty. Fewer resupply missions and optimized swap schedules mean less exposure to the risks of convoy operations in contested environments.
Autonomous optimization – The system continuously optimizes load management and energy allocation based on mission requirements and system health, reducing operator workload while maximizing efficiency across the tactical microgrid.
Predictive maintenance – Analytics identify equipment degradation patterns before failures occur, transitioning maintenance from reactive repairs to proactive interventions and extending system operational life.
Safety – The system’s remote monitoring capability reduces the need for personnel to physically inspect power systems in contested or hazardous environments. Continuous telemetry detects fault conditions—including overloads, thermal anomalies, and voltage irregularities—before they escalate, protecting both personnel and the equipment they depend on for mission-critical operations.

What’s next

The T-REX 26-1 results establish a foundation for broader implementation. Three areas will advance the technology from prototype validation to operational deployment.

Future exercises will validate performance across multiple simultaneous deployments, stress-testing the architecture’s ability to coordinate energy distribution at battalion and brigade scale. Tactical microgrid integration will extend the solution beyond individual METEOR unit monitoring to coordinate power distribution across multiple generation sources, storage systems, and consumption points, creating resilient energy networks for contested environments. As operational data accumulates, Amazon Bedrock ML models will identify equipment degradation signatures with greater precision, maturing predictive maintenance from concept to operational capability.

This architecture also addresses energy management challenges beyond defense. Remote mining operations, disaster response teams, and humanitarian missions all face similar visibility gaps in distributed power systems. The AWS and Sentient solution provides a proven reference architecture applicable wherever intelligent energy management delivers operational advantages.

Conclusion

Tactical forces no longer need to operate energy systems without visibility. The AWS and Sentient Industries solution transforms energy management from a vulnerability into a force multiplier—providing commanders with the real-time telemetry, predictive analytics, and automated optimization needed to make informed power distribution decisions in contested environments.

The T-REX 26-1 exercise validated this approach at scale. As the DoW continues to modernize how it executes operations and serves the warfighter, intelligent energy management provides the foundation for mission success across defense, commercial, and humanitarian applications.

Learn more

Learn about Cloud Computing for U.S. Defense. Explore Deploying Small Language Models at Scale with AWS IoT Greengrass and Strands Agents. Discover Amazon Bedrock Agents.

Secure, AI-driven cloud migration for DoW using CloudHedge

Ronald Hudson — Wed, 20 May 2026 14:40:46 +0000

Somewhere in the Department of War (DoW), a mission-critical application is running on a codebase that’s older than some of the soldiers who depend on it. It works, but every day it stays unmodernized is a day of compounding risk: security vulnerabilities, rising maintenance costs, and a widening gap between warfighter needs and information technology (IT) capability.

CloudHedge, running on Amazon Web Services (AWS), was built for exactly this moment. Powered by the generative AI capabilities of Amazon Bedrock, the CHAI platform brings together automated discovery, AI-driven transformation, and defense-grade security to modernize the applications that matter most, faster and more securely than ever before.

CloudHedge’s CHAI platform brings together three transformative components: DART (Discovery, Assessment, and Rationalization Tool), Flow Federal Edition, and CHAI Universe Model Context Protocol (MCP). All three components are grounded in the intelligence of Amazon Bedrock. These tools work in concert to provide a complete, AI-driven solution for modernizing legacy applications while maintaining the highest security standards required by the DoW.

The following graphic illustrates the migration and transformation flow of data. It begins with DART for a combined source code, workload, and application assessment and relevant recommendations. Then, it uses Flow for migration and modernizations from lift and shift and containers to direct-to-agentic AI app modification. The entire flow is powered by Amazon Bedrock.

Figure 1: CHAI MCP data pipeline

DART: The intelligence behind the migration

DART forms the foundation of CloudHedge’s modernization process, with its capabilities dramatically amplified by Amazon Bedrock for unified intelligence and reinforcement learning.

Unlike traditional methods relying on manual surveys, DART delivers automated, comprehensive application intelligence through its Tri-Vector Analyzer assessment approach. CHAI captures information from source code assessments, runtime assessments, and workload assessments, creating an accurate picture of an application landscape. The platform captures detailed inventories of applications, dependencies, and hardware utilization without human intervention, along with available source code analysis, then applies AI-powered reasoning to shape modernization strategy.

Amazon Bedrock enables DART to analyze legacy codebases, uncover hidden dependencies, and assess technical debt with expert-level nuance. It intelligently predicts migration complexity, flagging compatibility issues early, and generating context-aware recommendations for each application’s optimal modernization path. Where source code isn’t available—for example, in third-party commercial off-the-shelf (COTS) applications or vendor-locked systems—CHAI can profile applications using both runtime and workload-based assessments.

Executing the transformation with Flow Federal Edition

Flow Federal Edition takes DART’s AI-enhanced insights and transforms them into executable action. Rather than relying on generic migration templates, Flow uses Amazon Bedrock to generate custom containerization strategies, infrastructure as code (IaC) configurations, and deployment blueprints tailored to each application’s unique characteristics and DoW compliance requirements.

Amazon Bedrock analyzes application architectures and automatically determines the optimal approach, containerizing workloads for Amazon Elastic Kubernetes Service (Amazon EKS) or optimizing them for Amazon Elastic Compute Cloud (Amazon EC2). Kubernetes manifests and Terraform configurations are generated with Security Technical Implementation Guide (STIG) compliance embedded from the start. The Amazon Bedrock assessment of AWS Graviton workloads provides optimal performance, cost efficiency, and mission alignment.

The following architecture diagram illustrates the workflow. Applications are migrated to AWS using AWS Application Migration Service to lift and shift, then either containerized into Amazon EKS or placed on Amazon EC2. Direct-to-containers and direct-to-agentic application deployments are available.

Figure 2: CloudHedge workflow

CHAI MCP offers sovereign intelligence for secure environments

The core of CloudHedge’s AI integration is CHAI MCP. It’s a groundbreaking capability that brings Amazon Bedrock generative AI directly into secure, air-gapped DoW environments. CHAI MCP delivers what CloudHedge calls “sovereign intelligence”: AI-driven modernization insights and assistance that never require data to leave the protected enclave. Context injection enriches every model call with CloudHedge’s patented Tri-Vector Assessment, a multidimensional evaluation framework that provides a precise, actionable view of an application’s cloud readiness, ensuring context-aware responses rather than generic outputs.

Through a natural language interface, DoW teams can interact with CHAI MCP to query modernization assessments, request architectural recommendations, and receive plain-language explanations of complex migration decisions and still maintain complete data sovereignty. Amazon Bedrock models power these interactions, but data remains firmly within the secure environment, maintaining compliance with the most restrictive DoW data handling requirements.

CHAI MCP also serves as the intelligent orchestration layer between DART’s discovery data and Flow’s execution capabilities. It synthesizes runtime data, network traffic patterns, licensing information, and application dependencies, then uses Amazon Bedrock to generate comprehensive modernization blueprints complete with risk assessments, effort estimates, and sequencing recommendations. These blueprints are not static documents but living artifacts, refined through conversational interaction, allowing architects and mission owners to explore hypothetical scenarios and adjust strategies in real time. The result is a modernization experience where human expertise is amplified, not replaced.

Meeting DoW standards for security and compliance with AI-enhanced vigilance

CloudHedge’s security framework stands as one of its differentiators, and when combined with the intelligence of Amazon Bedrock, it becomes an enabler for DoW modernization. Architected from the ground up to meet the most demanding defense requirements, the standalone platform can support Impact Level (IL) 4 or 5 workloads. CloudHedge additionally supports the stringent requirements of IL6 through various pathways, such as cold migration and virtual machine (VM) export. Regardless of application sensitivity or data classification, CloudHedge is equipped to handle it while maintaining the strict security protocols that DoW missions demand.

Amazon Bedrock elevates this security posture well beyond rule-based automation. By intelligently analyzing security scan outputs, surfacing vulnerability patterns, and prioritizing remediation based on mission impact and exploit likelihood, Amazon Bedrock enables security teams to respond faster and more effectively than traditional alert-driven approaches allow. During containerization, Amazon Bedrock continually validates IaC configurations against STIGs and DoW security policies. When deviations are detected, it doesn’t merely flag them. It explains their significance, predicts potential impact, and recommends compliant alternatives that preserve functional requirements. The result is a platform that doesn’t merely check compliance boxes but actively reinforces the integrity of every workload it touches. This gives DoW organizations the confidence to modernize faster, smarter, and without ever loosening their grip on security.

Accelerating mission-critical migrations

CloudHedge’s real-world impact on modernization can be seen in one implementation where the platform modernized a complex Army logistics system running on a legacy .NET codebase that had been in operation for more than two decades. The agency benefited from CloudHedge tooling that drove a 900% improvement in delivery speed, compressing the estimated 24-month timeframe to only 10 weeks. This efficiency enabled a reduction of more than 25,000 human hours in overall effort to assess, plan, modernize, and deploy on AWS GovCloud (US). For the DoW, where modernization pace is directly tied to mission readiness, this acceleration is operationally significant.

These outcomes are powered by the synergy between CloudHedge’s automation capabilities and Amazon Bedrock intelligent reasoning. By eliminating the manual assessment phases, iterative troubleshooting, and decision bottlenecks that slow traditional migrations, CloudHedge delivers:

AI-driven dependency mapping
Cloud-agnostic workload portability across Amazon EKS and Amazon EC2
Integrated DevSecOps pipelines with context-aware security validation
Predictive AWS service configurations tailored to mission requirements

This forms a modernization engine purpose-built to compress timelines, reduce risk, and deliver mission-ready systems faster than any conventional approach.

Operational excellence in DoW environments

CloudHedge’s deployment model within DoW environments is purpose-built to preserve operational integrity without sacrificing efficiency. Operating entirely within authorized boundaries, the platform keeps sensitive data securely contained. This design philosophy isn’t incidental; it’s a foundational requirement for DoW applications, where the stakes of data exposure are too high to leave to chance.

The platform’s integration with AWS services reflects this same commitment to security without compromise. CloudHedge deploys directly to Amazon EKS clusters, providing a robust and scalable container orchestration foundation that aligns with DoW’s operational demands. Its optimization for AWS Graviton based EC2 instances further enhances performance and cost efficiency so that mission-critical workloads run at peak capability. Interactions with AWS services are conducted through approved channels, maintaining strict adherence to access control requirements and eliminating unauthorized pathways that could introduce risk.

Perhaps most significantly, CloudHedge extends its support to air-gapped AWS GovCloud (US) environments, a capability that speaks directly to the most sensitive and isolated operational contexts within the DoW. In these environments, where connectivity to the outside world is deliberately severed, CloudHedge continues to deliver its full modernization capabilities so that even the most security-constrained organizations can benefit from cloud-based transformation without compromising the integrity of their data or operations.

DevSecOps integration and automation

CloudHedge fundamentally reimagines how organizations approach migration, transforming cumbersome, manual processes into fully integrated, AI-enhanced DevSecOps pipelines. Rather than treating security as an afterthought, the platform weaves consistent security controls into every stage of the development and deployment lifecycle, ensuring that speed and compliance advance together rather than in tension.

At the heart of this transformation is intelligent orchestration by Amazon Bedrock. Container images are intelligently optimized, with Amazon Bedrock analyzing configurations for security anti-patterns and prioritizing vulnerabilities by exploitability and mission impact. Infrastructure provisioning is fully automated through AI-generated IaC, with Amazon Bedrock embedding cost optimization and security hardening directly into Terraform and AWS CloudFormation templates. Security policies are enforced continually across all environments, with Amazon Bedrock monitoring for policy drift and generating remediation workflows in real time. Deployment workflows and scaling operations adapt dynamically to application behavior, providing consistent performance without manual intervention. This makes rapid deployment and robust governance not competing priorities, but complementary strengths.

Support and maintenance framework

CloudHedge’s support model is tailored for DoW environments, working in partnership with systems integrators (SIs) and global systems integrators (GSIs). To support DoW workloads, CloudHedge’s on-premises deployment model delivers the platform’s entire capability within the agency’s secure environments, such as data centers or an existing AWS account. CloudHedge doesn’t require external connectivity to deliver assessment or modernization capabilities. This helps support and maintenance activities maintain the required security posture while delivering optimal performance.

Future-ready DoW applications

CloudHedge’s capacity to modernize applications while upholding security compliance makes it an asset in DoW’s digital transformation journey. By facilitating the seamless migration of legacy systems to modern cloud architectures, the platform empowers DoW organizations to operate more efficiently, shedding the burden of outdated processes in favor of streamlined, cloud-based workflows. This shift drives down maintenance costs and unlocks significant gains in application performance, helping critical systems run faster and more reliably.

Beyond operational improvements, CloudHedge strengthens the security posture of DoW organizations, which means modernization efforts don’t come at the expense of compliance or data protection. Equally important, the platform equips teams with rapid deployment capabilities, so they can bring new capabilities and updates to production with speed and confidence.

Conclusion

CloudHedge, powered by Amazon Bedrock, represents a significant advancement in DoW application modernization, uniting the rigor of defense-grade security architecture with the transformative power of generative AI. Its combination of automated discovery, AI-enhanced assessment, secure transformation, and compliant deployment makes it an ideal solution for the DoW’s most complex modernization challenges. As the defense sector continues its digital transformation journey, platforms such as CloudHedge will play an increasingly crucial role in making migrations successful, secure, and efficient.

The platform’s alignment with DoW security requirements, coupled with its proven ability to accelerate modernization timelines using Amazon Bedrock, positions it as an indispensable asset for organizations looking to modernize their application portfolios. By providing a secure, automated, AI-powered path to cloud adoption, CloudHedge bridges the gap between legacy systems and modern cloud capabilities to help keep DoW applications cutting-edge and compliant. Most importantly, CloudHedge demonstrates that speed, security, and intelligence aren’t competing priorities but complementary strengths, unified through thoughtful architecture and the strategic application of generative AI.

Ready to accelerate your agency’s cloud modernization journey? CloudHedge’s CHAI platform is available today for Department of War programs seeking to reduce migration timelines, eliminate manual assessment overhead, and maintain the highest levels of security compliance.

To learn more about the CHAI platform and request a demo, visit CloudHedge. To discuss how CloudHedge and Amazon Bedrock can support your modernization mission, reach out to your AWS solutions architect or contact the AWS Public Sector team. To learn how AWS supports IL4 and IL5 workloads and provides pathways to IL6, visit AWS GovCloud (US).

A faster, more resilient digital repository: Migrating DSpace to AWS

Kai Xu — Sat, 16 May 2026 15:33:43 +0000

Automated bot traffic has surged across academic digital repositories, creating real performance problems for institutions that make research openly accessible. At Johns Hopkins University (JHU), the problem was compounding an already difficult situation. The Sheridan Libraries’ installation of DSpace—an open-source digital repository system used by thousands of institutions worldwide—was running on on-premises infrastructure that the team could no longer update without significant manual work. The system was many versions behind the latest release, and the single-server setup required significant dedicated resources to handle frequent traffic spikes.

These challenges made modernizing DSpace a necessity to support the university community. The Digital Research and Curation Center (DRCC), the group within the Sheridan Libraries that builds and manages digital infrastructure for open scholarship, migrated DSpace to the cloud with Amazon Web Services (AWS). Using Amazon Elastic Container Service (Amazon ECS) with AWS Fargate, the team achieved a faster, more scalable repository without the operational burden of maintaining on-premises infrastructure.

Frozen infrastructure and surging traffic

DSpace, known at Johns Hopkins as JScholarship, is the central repository for the university’s research and cultural collections, housing over 150 collections that include research papers, theses, dissertations, historical documents, newsletters, articles, images, audio, video, sheet music, and maps.

“JScholarship users range from students depositing theses, to government employees researching state land maps, to musicians searching for historic sheet music compositions,” said Digital Repositories Manager for the Sheridan Libraries, Allison Fischbach. JScholarship also supports the university’s open-access policy, providing faculty with a place to make their research publicly discoverable. “DSpace is used to maintain a permanent record of university scholarship,” said Hodson Director of the DRCC and Open Source Programs Office, Bill Branan.

But running DSpace on-premises had become unsustainable. Recent licensing changes resulted in increased hosting costs, and much of the maintenance and administration for supporting DSpace relied on manual processes. Pushing code updates into production took months.

“Updates hadn’t really been done to DSpace for a very long time because there was a lack of confidence in the process,” explained Senior Cloud Engineer in the DRCC, Steven Miklovic.

Meanwhile, automated bot traffic—driven largely by AI companies scraping open-access research—had surged, and the infrastructure needed frequent manual intervention to keep up.

Before the migration, the DRCC team evaluated whether to replace DSpace entirely. They determined that the software was still the right fit, but it was necessary to increase the speed of moving software changes into production, and the deployment environment needed to be able to scale to meet demand without manual intervention. These requirements pointed to a container-based deployment with an automated build pipeline.

“Given the on-premises architecture, deploying changes in a timely manner would have been very difficult,” said Senior Software Engineer in the DRCC, Russell Poetker.

Building on an existing modernization effort

The DRCC team brought relevant experience to the project. Engineers on the team had already modernized the Public Access Submission System (PASS), a custom application that allows researchers to deposit articles into DSpace, using a similar containerized architecture. The team also drew on experience with DSpaceDirect, a hosted service run through Lyrasis, the organizational home of the DSpace open-source project. That prior work showed that hosting DSpace in the cloud could deliver consistency, repeatability, and resiliency.

Throughout the project, the DRCC team worked with AWS through a consultation-based approach, meeting at key milestones for architectural reviews. Those sessions validated the architecture and surfaced important security features and optimizations.

Six months from architecture to production

The technical implementation spanned about six months. The first three to four months focused on defining the initial architecture, including a significant data migration sub-project. The on-premises environment for DSpace stored files differently than Amazon Simple Storage Service (Amazon S3), so the team went through several iterations of migrating data, validating it, and refining scripts.

“Steps like that are how you build the confidence in the cloud for people,” Miklovic noted.

This phase also included the DRCC’s creation of infrastructure as code (IaC) to automate the deployment process, laying a repeatable foundation for future migrations.

Once the production environment was created using IaC tooling, the team performed testing and validation prior to a final production launch on January 12, 2026. Post-launch, they tuned scaling policies and optimized resource allocation to handle bot traffic spikes, followed by additional efficiency improvements.

A serverless architecture built for maintainability

Moving to a serverless architecture was more complex than a straightforward lift-and-shift, but the DRCC team chose that path deliberately. An earlier attempt at JHU to run a different application in a more advanced container orchestration environment had proven too burdensome. Amazon ECS with AWS Fargate offered a managed middle path.

“We wanted to really simplify the operational burden of an advanced architecture and focus on the developers being the primary support for the application,” said Miklovic. By shifting infrastructure management to AWS-managed services, the team could redirect their focus from operational maintenance to development, effectively adopting a DevOps model where the engineers who build the application also own its deployment and observability.

DSpace naturally breaks into several components, including a front end, back-end API, search index, and scheduled jobs, which the team split into separate containers so each can scale independently. The architecture includes Amazon Relational Database Service (Amazon RDS) for PostgreSQL configured for high availability; Amazon S3 for the DSpace asset store; AWS WAF in combination with Cloudflare for application security and bot traffic management; Elastic Load Balancing using Application Load Balancers for public and internal traffic; Amazon EventBridge for scheduled tasks; and Amazon CloudWatch for monitoring. The team also used Amazon Q Developer for the first time to support architectural decisions.

The migration also gave back to the open-source community. The team found that DSpace’s Amazon S3 storage integration relied on an outdated version of the AWS software development kit, upgraded it, and contributed the fix upstream.

“That’s one of the nice things about working in open source,” said Branan. “If we find something that’s a problem, not only can we fix it, but we can push it back up for anyone else who needs to use it.”

Faster performance, faster deployments, and greater confidence

Since launching, the new environment has reached stable performance after an anticipated tuning period. The public-facing load balancer typically averages 400,000 to 500,000 requests per day, while a second, internal load balancer handles over 2 million, which reflects the volume of communication between DSpace’s internal components.

The difference has been immediate for the people who use DSpace every day. Students searching for dissertations, faculty accessing research, and staff managing collections all noticed faster response times as soon as the cutover happened. Where the old single-server setup left the repository vulnerable to bot traffic spikes, the new architecture absorbs surges without degrading the experience for real users.

Centralized logging and alerts now give the DRCC team real-time visibility across the environment, replacing the reactive troubleshooting of the old setup. The serverless nature of the deployment also gives engineers more time to focus on improving the application itself.

The new deployment pipeline has also shortened the path from code change to a testable environment.

“Verification of application changes in a pre-production environment now happens within a few minutes after a PR is merged. This is a big improvement for our development and test cycle,” said Poetker.

With faster performance for users and a streamlined workflow for developers, the DSpace migration has given the DRCC team confidence that they can apply the same approach with other applications in their portfolio. Stakeholders for other library systems are eager for similar transitions.

A roadmap for other institutions

The DRCC team is already migrating more applications into a similar architecture and exploring how AI can support DevOps visibility over time. Other academic libraries and cultural institutions considering this type of migration can draw on the team’s experience: start with a managed service like Amazon ECS as a pathway into the cloud; take small steps to build confidence; and use what others have built.

To that end, the DRCC team published an open-source reference architecture for DSpace on AWS on GitHub, which also breaks out components that other institutions can reuse for different applications, so they don’t have to build it all from scratch.

With bot traffic continuing to grow and on-premises infrastructure increasingly difficult to maintain, modernizing digital collections in the cloud is becoming a practical necessity. Explore how AWS helps institutions build secure, scalable solutions for higher education.