AWS is applying AI to the challenge of evaluating and improving cloud environments with a public preview of a new agentic service aimed at automating the discovery and optimization of architectural issues.

Despite its name, AWS makes no claims for the architectural qualities of its Well-Architected Agent, the name of which refers to a long line of frameworks and tools for cloud architecture management dating back over a decade. AWS launched the first, the Well-Architected Framework, in 2015, later introducing the Well-Architected Tool in 2018 to help customers review their own workloads against the framework’s best practices.

In contrast to the Tool’s reliance on enterprise teams to provide information about their workloads through a structured set of questions, the Agent analyzes the AWS environment itself and uses that information to generate recommendations, the company wrote in a blog post.

Enterprises can also give the agent business objectives and application context to enable it to rank its findings against those goals, AWS said.

The Agent surfaces recommendations at three levels: individual resources, applications, and overall architecture, suggesting remediation steps and identifying their potential cost impact.

Those remediation steps can include environment-specific implementation guidance such as console walkthroughs, AWS CLI commands, and updated infrastructure-as-code changes, AWS said, while the existing Tool merely proposes an improvement plan.

Optimizing cloud optimization

For enterprise users, particularly cloud architects, DevOps teams, and platform engineers, the new agent can speed up optimization and change the way they manage cloud environments, moving from periodic architecture reviews and reactive remediation toward more continuous, AI-assisted optimization, said Siddharth Mehta, research leader at consulting and services company Avasant.

That shift in how cloud environments are managed will become increasingly relevant as enterprises scale agentic applications, according to Nhat Bui, deputy director of engineering at Scopic Software. 

“First, AI applications change faster and have less predictable cost profiles than traditional workloads, so a review done last quarter goes stale quickly. Second, more infrastructure is now being written by AI coding tools, and human reviewers can’t keep pace with that volume,” Bui said.

There are limits to the agent’s ability to offer timely recommendations, though: “The Agent refreshes resource-and application-level recommendations weekly, while architecture-level recommendations are generated through on-demand reviews,” Bui said. That distinction could be particularly important for fast-changing workloads, including agentic applications, where infrastructure and resource usage can change between recommendation refreshes, he added.

That said, the new agent could help accelerate the pace of cloud-related decision-making, said Pareekh Jain, principal analyst at Pareekh Consulting. “Instead of giving CIOs hundreds of technical recommendations, the agent can help identify which improvements matter most to the business. That means CIOs can decide where to prioritize cloud investments and engineering resources, and where to accept trade-offs,” he said.

Limitations of the new Agent

However, the Well-Architected Agent has its own set of limitations, said Mehta. “The Agent only understands the context available to it. It may not know about regulatory obligations, third-party dependencies, business-process dependencies, contractual SLAs, internal risk appetite, multi-cloud dependencies, and organizational policies not represented in AWS,” he said. “Therefore, business-goal alignment improves prioritization but does not replace enterprise architecture or risk governance.”

For Jain, however, the bigger limitation is the Agent’s requirement for a high-tier AWS Support plan, which could limit its adoption among enterprises that do not already subscribe to those plans.

The Agent is available only to customers on AWS Business+, Enterprise On-Ramp, Enterprise Support, or Unified Operations plans, unlike the Well-Architected Tool, which does not require a paid Support plan, he said.

Moreover, Mehta said, the Agent is narrower in scope, currently covering cost, security, performance, and resilience, while the Well-Architected Tool continues to support all six pillars of the Well-Architected framework, including operational excellence and sustainability.

There is no specific additional fee for the Agent or the Tool, although enterprises are charged for some of the underlying AWS resources, services, and data that they consume, including those from Trusted Advisor, Compute Optimizer, Security Hub CSPM, Resilience Hub, Cost Optimization Hub, and Cost Explorer.

While its flagship Dreamforce event was in full swing on Wednesday, Salesforce was triaging a roughly seven and a half hour-long service outage that disrupted user access and caused “severe delays” and intermittent errors. Some customers were also unable to submit new support cases.

The service outage hit at 3:50 a.m. EDT, impacting “multiple instances across all regions,” Salesforce reported. It was marked resolved right around 3 p.m. EDT, after several hours of monitoring to determine that fixes had been successful.

Salesforce initially pegged the issue to an “external dependency failure” impacting the legacy login server. A core system component experienced increased load, limiting its capacity to process requests. The company confirmed that there were no issues with third-party infrastructure.

Beyond the obvious embarrassment from the outage occurring during Dreamforce, an analyst said the incident highlights a cloud resilience problem, rather than purely a legacy one.

“Cloud does not eliminate architectural dependencies,” said Abbas Jaffery, a principal advisory director at Info-Tech Research Group. “It can sometimes make them less visible. And when the platform is your system of record, those hidden dependencies become an enterprise risk rather than simply a technology risk.”

Rolling restarts, persistent issues throughout the day

Salesforce began experiencing service issues at 3:50 a.m. EDT on September 16, and initial investigation determined that requests were stalling while waiting on responses from an internal login service that was using up available server resources.

Initially, Salesforce blocked application programming interface (API) endpoints and attempted rolling restarts to revive the service, then pushed out fixes region-by-region. At 7:20 a.m., some customers were seeing service return to normal, and Salesforce was working on a “code-level permanent fix.”

However, the rollout did not complete for a number of instances, and some automated fixes didn’t fully resolve the issue. For example, customers reported that scheduled jobs were not running as expected, even after service was restored. Salesforce manually restarted those ‌instances.

Salesforce later reported that the impact radius was “narrower than initially understood” and saw signs of recovery by around 11 a.m. EDT, with most customers coming back online.

A sub-set of Hyperforce instances were the last to be restored. Mitigations were in place across all instances by 11:39 a.m. EDT, and Salesforce continued to monitor the issue until marking the incident resolved at 2:59 p.m. EDT.

“We apologize for how this incident affected you and your business,” Salesforce posted on its incident blog. “We will undertake a full investigation of the incident, establishing the technical trigger, the underlying cause, and preventive action to avoid a repeat in the future.”

Creating a ‘temporal’ data problem

For customers for whom Salesforce is a system of record, several hours of authentication and service disruption can create a “temporal data problem,” Info-Tech’s Jaffery explained. “Events that should have happened at different points in time may occur later, fail altogether, or arrive out of sequence,” he said.

For instance, a customer interaction may occur through another channel while Salesforce is unavailable, but an integration, workflow, or scheduled process that normally records or propagates that event is unable to run.

This has several potential consequences, Jaffery said. Transactions and customer service processes are delayed; APIs and middleware may accumulate retries, timeouts, and queues. Records can become temporarily inconsistent, and scheduled jobs and workflows may be missed. Employees could lose visibility into customer history or case status, even when the underlying data has not been lost, creating a “data divergence.”

The first mistake would be to assume that just because users can log in, the incident is over, he noted. “Enterprises should move immediately into a reconciliation and integrity phase,” Jaffery advised. This means not only verifying interactive access, but APIs, integrations, scheduled jobs, queues, workflows, automation, authentication flows, and downstream systems.

Enterprises should ask what transactions failed, partially completed, or were duplicated during the outage? Which scheduled or asynchronous processes did not execute? Did integrations retry successfully, or did they create a backlog or retry storm? Are downstream systems now consistent with Salesforce?

Security teams should also validate authentication and session behavior, privileged access, integration credentials, and any emergency changes made during recovery, Jaffery explained. “The most important question is not simply ‘Is Salesforce back?’, but ‘What did the business expect to happen during the outage, and can we prove that it actually happened?,’” he said.

What to look for in post-incident reports

A credible post-incident review from Salesforce should establish a causal chain: The trigger, dependency failure, technical propagation, customer impact, detection, mitigation, recovery, and permanent corrective action, Jaffery said.

The company should be able to answer these questions, he said:

• What was the actual initiating failure and why did the failure propagate into the login path?
• Why could the affected dependency consume sufficient capacity to affect core services?
• Why didn’t isolation or failover prevent the impact?
• Why did initial remediation attempts fail and why did the subsequent rollout require additional intervention?
• What safeguards are being added to prevent recurrence?
• How will Salesforce demonstrate that the corrective action actually works under failure conditions?

Service restoration simply tells customers: “We got it working again,” he noted. But root cause analysis tells customers: “We understand why it failed, why our controls didn’t prevent it, and what has changed so that the same failure mode is less likely to recur.”

It’s not just about ‘legacy’ pieces in the stack

One architectural lesson is that a legacy component does not have to be large to be critical, Jaffery pointed out. An older authentication service can remain part of a modern stack, and therefore become a dependency for newer services.

“The component’s age matters less than its position in the dependency graph, its blast radius, and the quality of its isolation and failure handling,” he said, pointing to this incident’s progression: Requests stalled waiting on an internal login service due to increased resource consumption led to investigation into an external dependency failure, which in turn revealed impact on a legacy login server. Finally, Salesforce said, “core system components experienced increased load, which limited its capacity to process request”.

That is a classic resilience question, Jaffery pointed out: Can a failure in one dependency remain in that one dependency, or does it become a platform-wide failure?

Modernization should not be identified simply by how much old technology has been replaced, he noted, it should also measure dependency concentration, isolation, “graceful degradation,” recovery paths, and failure blast radius.

“For enterprise architects, that is the real takeaway,” he said.

Maybe driven by agentic AI, exacerbated by layoffs

At this point, there are no obvious signs that this was a security incident, noted David Shipley, CEO of Beauceron Security. “Right now, this bears all the hallmarks of an update gone horribly wrong.”

He pointed to an incident in December 2025 when Amazon’s internal AI coding agent, Kiro, caused a 13-hour AWS outage in a mainland China region, noting, “I’m not going to be shocked if we don’t see some kind of agent role in this kind of scale disaster.”

Significant Salesforce layoffs over the last few years could also have had a negative impact on the outage and recovery, he added. “Having it happen during Dreamforce had to be all kinds of hell, though, for their sales and customer support teams,” he said. “Pour one out for them as they work on rebuilding relationships, face-to-face.”

The cloud computing conversation has changed significantly over the past few years. Earlier, enterprises selected cloud platforms mainly for scalability, global reach, agility and cost flexibility. Today, those priorities remain important, but they are no longer sufficient. Governments, regulators, boards and customers are asking a deeper question: where does critical data reside, who can access it, who operates the infrastructure and which legal jurisdiction ultimately governs it? This is the context in which sovereign cloud has moved from a specialist requirement for governments into a mainstream enterprise architecture consideration.

Sovereign cloud refers to cloud environments designed to preserve data residency, legal control, operational independence and regulatory compliance within a defined jurisdiction. In practical terms, it is not merely a cloud region located inside a country. A mature sovereign cloud model includes a combination of local data storage, strict identity and access control, encryption key ownership, local personnel controls, auditability, contractual protections, operational segregation and, in some cases, disconnected or air-gapped deployment options. Its central purpose is to allow organizations to consume cloud and AI capabilities while reducing exposure to cross-border data transfer risk, extraterritorial access concerns and regulatory uncertainty.

Recent trends in sovereign cloud

The first major trend is the shift from data residency to full digital sovereignty. Data residency answers the question of where data is stored. Digital sovereignty goes further by addressing legal jurisdiction, administrative access, operational control, encryption key management and dependency on foreign technology providers. This distinction has become increasingly important as enterprises recognize that locating data in a domestic region does not automatically remove legal or operational exposure.

The second trend is the rapid convergence of sovereign cloud and artificial intelligence. Generative AI and large-scale analytics rely on sensitive enterprise data, customer information, intellectual property, telemetry and domain-specific knowledge. As a result, enterprises are increasingly asking whether AI training, inference, prompts, embeddings, logs and model outputs should remain within national or regional boundaries. Sovereign AI infrastructure is therefore emerging as a natural extension of sovereign cloud, especially in regulated industries and public-sector environments.

In the figure above, you can see each layer builds on the ones before it, moving from a storage question to a question of legal, operational and technological independence, showing sovereignty is cumulative.

The third trend is the rise of hybrid sovereign architectures. Few enterprises can move every workload into a fully isolated sovereign environment without affecting agility or cost. Instead, many organizations are adopting a layered model. Highly regulated workloads such as citizen services, payment systems, healthcare records, defense data and critical infrastructure systems are placed in sovereign or private cloud environments, while less sensitive workloads continue to use mainstream public cloud regions. This approach allows enterprises to balance sovereignty, innovation, performance and economics.

In the figure above, hybrid sovereign architecture model is built as a layered approach that balances sovereignty, innovation, performance and economics.

The fourth trend is the growing importance of local partnerships. Hyperscale providers are increasingly working with regional telecom operators, system integrators, government-backed entities and local infrastructure providers to meet country-specific sovereignty requirements. These collaborations help address demands for local operations, domestic ownership, regional support and compliance with national security policies. At the same time, local cloud providers are refreshing their platforms to offer modern automation, cloud-native services, security tooling and managed operations.

The fifth trend is the growing use of policy-as-code and sovereign-by-design controls. Enterprises want sovereignty to be enforced through architecture, not only through contractual language. This is creating demand for region-locked deployment policies, controlled replication, customer-managed keys, confidential computing, localized identity administration, immutable audit trails and automated evidence collection for regulators and auditors.

Industry adoption of sovereign cloud

Government and public sector organizations remain the most visible adopters of sovereign cloud. Their workloads often include citizen identity, taxation, welfare, defense, justice, digital public infrastructure, border management and national emergency systems. These systems carry high public trust obligations and governments increasingly prefer cloud platforms that provide clear control over data location, local administration, audit rights and national continuity.

Banking, financial services and insurance are also strong candidates for sovereign cloud adoption. Banks handle personal financial data, payment transactions, fraud signals, credit records, trading information and regulatory reporting data. Sovereign cloud helps financial institutions align with central bank expectations, operational resilience mandates, cybersecurity requirements and audit obligations. It also enables safer use of AI for fraud detection, customer intelligence, risk modeling and compliance monitoring.

Healthcare and life sciences organizations are adopting sovereign cloud to protect patient records, clinical trials, diagnostics, genomics data, medical imaging and public health information. The sensitivity of healthcare data makes jurisdictional clarity extremely important. Sovereign cloud can support secure collaboration, research analytics, hospital modernization, AI-assisted diagnostics and telemedicine platforms while maintaining tighter data governance.

Telecommunications providers use sovereign cloud for network functions, 5G core workloads, subscriber data, lawful interception systems, edge platforms and national communication infrastructure. Because telecom networks are often classified as critical infrastructure, sovereignty requirements can influence decisions on hosting, operations, resiliency and supply-chain assurance. Here is a summarized view of various industrial adoption across different use cases.

Manufacturing, energy, utilities and transportation sectors are beginning to view sovereign cloud as part of industrial resilience. Operational technology data, plant telemetry, grid analytics, digital twins, predictive maintenance models and supply-chain intelligence are increasingly valuable assets. For these industries, sovereignty is closely tied to business continuity, cyber resilience, industrial secrecy and national economic security.

Cost implications of sovereign cloud adoption

Sovereign cloud adoption may increase cost when compared with standard public cloud deployment, especially in the early stages. Additional costs can arise from localized infrastructure, dedicated regions, private cloud environments, local operations teams, specialized compliance controls, sovereign connectivity, encryption key management, audit tooling and managed security services. In some cases, organizations may also need to redesign applications to prevent unapproved cross-border replication or dependency on non-sovereign platform services.

However, the cost discussion should not be limited to infrastructure premiums. Enterprises must compare the added cost of sovereign controls with the potential cost of regulatory penalties, reputational damage, business interruption, loss of public trust, failed audits, contractual exclusion from regulated markets and inability to use sensitive data for AI safely. For a regulated enterprise, sovereignty can become an enabler of revenue protection and market access rather than a pure compliance expense.

FinOps discipline becomes essential in sovereign cloud programs. Organizations should classify workloads by sovereignty need, avoid over-engineering low-risk applications, monitor data egress, negotiate transparent pricing, standardize deployment patterns and use automation to reduce operational overhead. A pragmatic cost model normally separates workloads into tiers: highly sovereign, regulated but cloud-friendly and general enterprise workloads. This allows the organization to apply the highest controls where they matter most.

Benefits of sovereign cloud for enterprises

The most direct benefit of sovereign cloud is improved regulatory alignment. Enterprises operating across multiple jurisdictions can demonstrate stronger control over data storage, processing, access and movement. This is especially valuable when serving government clients, regulated sectors or customers with strict data protection expectations.

A second benefit is enhanced trust. Customers, regulators and partners are more likely to support digital initiatives when an enterprise can explain where sensitive information resides, who operates the environment and how access is governed. In sectors such as healthcare, banking, public services and critical infrastructure, trust is not a soft value; it is a commercial and operational requirement.

A third benefit is stronger resilience. Sovereign cloud can support local continuity planning, controlled dependency management, regional disaster recovery and clearer operational accountability. When designed properly, it reduces the risk that geopolitical disruption, foreign legal orders, supply-chain fragility or cross-border service restrictions will affect mission-critical systems.

A fourth benefit is responsible AI enablement. Many organizations hesitate to use AI on sensitive data because of uncertainty about retention, training, inference and cross-border processing. Sovereign cloud provides a more controlled foundation for AI adoption by combining data isolation, model governance, auditable operations and policy-driven controls.

Analyst perspective on future trends

Analyst research indicates that sovereign cloud is becoming a fast-growing part of the cloud market rather than a narrow compliance niche. Gartner forecasts worldwide sovereign cloud infrastructure-as-a-service spending to reach US$80 billion in 2026, reflecting 35.6% growth from 2025 and also notes that sovereign cloud spending could shift a meaningful share of workloads from global to local providers. Earlier Gartner research also projected strong long-term growth for sovereign cloud IaaS, driven by regulatory demand, operational independence and technological autonomy.

Forrester’s recent work on digital sovereignty highlights that organizations are no longer treating sovereignty as a simple data residency issue. Its sovereign cloud platform research emphasizes that different deployment models are required for different risk profiles, ranging from public cloud with sovereign controls to private, partner-operated and disconnected environments. This reinforces an important market reality: sovereignty is becoming a design principle across the IT stack, not a single product category.

IDC’s digital sovereignty research points to regulatory compliance, national and regional legislation, protection against extraterritorial data requests, AI adoption and strategic partnerships as key forces shaping the market. IDC’s infrastructure predictions also caution that sovereignty programs can add cost and complexity, requiring stronger data classification, governance, security controls, partner ecosystems and skills development.

Everest Group’s research frames sovereign cloud as closely connected to sovereign AI, enterprise autonomy, data governance and operational control. Its European sovereign cloud analysis describes a market being shaped by geopolitical tension, stronger privacy mandates, concerns about foreign surveillance laws and the need for clearer sovereignty frameworks across data, operational and technical dimensions. Everest Group’s broader private cloud research also indicates that AI, automation, workload repatriation, hybrid-first strategies and sovereignty mandates are increasing demand for controlled cloud environments.

Conclusion

Sovereign cloud is best understood as a response to a broader shift in enterprise technology: the movement from borderless cloud consumption to governed digital autonomy. It does not reject public cloud innovation; rather, it asks cloud platforms to operate within clearer legal, operational and architectural boundaries. For enterprises, the strategic question is not whether every workload must become sovereign. The better question is which data, systems, AI workloads and business processes require sovereign protection and how that protection can be delivered without slowing innovation.

The future of sovereign cloud will likely be hybrid, policy-driven, AI-aware and industry-specific. Organizations that treat sovereignty as an architectural capability will be better positioned than those that approach it as a last-minute compliance checkbox. The winners will be enterprises that build a balanced operating model: global where possible, local where necessary and sovereign where trust, regulation and resilience demand it.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?