DEV Community: maryam mairaj

Catch It Before Your Customers Do: A Practical Guide to Cloud Observability on AWS

maryam mairaj — Tue, 03 Nov 2026 09:22:31 +0000

If your customers are the first to tell you something is broken, your monitoring has already failed. The ticket arrives, the war room opens, and the team spends the first hour working out where the problem is before anyone can fix it.

For IT operations and engineering leaders across the region, this pattern is common. Workloads have moved to AWS, architectures have spread across containers, serverless functions and managed services, but the monitoring setup still looks like it did on-premises: a few CPU alarms, some dashboards nobody watches, and logs that only get opened after something goes wrong.

The result is two expensive gaps:

• Detection gap: the time between something breaking and your team knowing about it.

• Resolution gap: the time between knowing and fixing, most of which is spent searching for the cause.

This guide covers how to close both gaps on AWS: what observability actually means, which signals matter, and five practical changes that cut detection and resolution time without a full re-platform.

What is cloud observability on AWS?

Cloud observability on AWS is the ability to understand how applications and infrastructure running on AWS behave by using the metrics, logs, and traces they emit. Amazon CloudWatch, AWS X-Ray, and AWS Distro for OpenTelemetry bring these signals together so teams can detect issues early and quickly find the cause.

Monitoring tells you something is wrong. Observability tells you why.

Monitoring answers questions you already knew to ask: Is CPU above 80%? Is the instance up? Did the health check pass? It works well for failures you have seen before.

Modern incidents rarely look like that. A slow checkout might come from a throttled DynamoDB table, a misconfigured connection pool, or a third-party API timing out. No single CPU alarm will catch it, and no static dashboard will explain it.

Observability is the ability to understand what is happening inside your systems from the data they emit, including problems you did not predict. In practice, the difference looks like this:

The signals that matter on AWS

Observability rests on three signals: metrics, logs, and traces. AWS gives you native tools for each, plus dedicated views for application performance and GenAI workloads. Most teams already pay for more of them than they use.

The tools are rarely the problem. The gaps usually come from how they are set up:

• Logs are collected but not structured, so searching them during an incident is slow.

• Metrics exist for every EC2 instance but not for the business transactions customers care about.

• Tracing is switched off, so nobody can see which downstream call caused the slowdown.

• Alarms fire on dozens of low-value thresholds, and the team learns to ignore them.

Five moves that cut detection and resolution time

You do not need a new platform to improve. These five changes work with the AWS services you already have, and each one closes part of the detection or resolution gap.

1. Alert on symptoms, not just causes

Customers do not feel high CPU. They feel slow pages and failed payments. Define service level objectives (SLOs) for your critical user journeys, such as login, checkout, or API response time, and alert when they are at risk.

CloudWatch APM (Application Signals) lets you set SLOs on latency and availability directly. It also brings in Synthetics canaries that test key journeys every few minutes and Real User Monitoring (RUM) data from actual browser sessions, so you know a flow is broken even when no real user has reported it yet.

2. Cut alert noise with composite alarms and anomaly detection

Alert fatigue is a detection problem. When a team receives hundreds of low-value alerts a week, the important one gets missed.

• Use CloudWatch anomaly detection for metrics with daily or weekly patterns, instead of fixed thresholds that fire every peak hour.

• Use composite alarms to page only when several related conditions are true together, such as rising errors and rising latency on the same service.

• Review every alarm that fired in the last month. If nobody acted on it, tune it or delete it.

3. Structure your logs and connect them to traces

Unstructured log lines turn every investigation into a text search. Emit logs as JSON with consistent fields such as service name, request ID, customer or tenant ID, and error code. CloudWatch Logs Insights can then filter and aggregate them in seconds.

Pass the same trace ID through every service using OpenTelemetry or X-Ray. When an alert fires, your engineer can jump from the failing metric to the exact trace and then to the logs for that one request, instead of searching across consoles.

4. Build dashboards around services, not resources

A dashboard with 40 EC2 CPU graphs does not tell you whether customers are affected. Build one dashboard per critical service showing the four golden signals: latency, traffic, errors, and saturation.

Add a top-level view that shows the health of each service against its SLO. During an incident, the team should open this first.

5. Write runbooks and automate the first response

Much of the resolution gap is spent deciding what to do. Link every critical alarm to a short runbook that lists what to check first and how to mitigate.

For common, well-understood issues, automate the response with AWS Systems Manager Automation or Amazon EventBridge rules, such as restarting a stuck service, scaling out a target group, or rotating a full disk. The on-call engineer then reviews a fix instead of starting one.

Let AI take the first hour of the investigation

AWS has built generative AI directly into CloudWatch to shrink the resolution gap. Instead of an engineer jumping between consoles to form a theory, AI scans your telemetry and proposes likely causes in minutes.

CloudWatch investigations

CloudWatch Investigations is a generative AI assistant for incident response. You start one from an alarm, a metric, or a Logs Insights query, and it analyses:

• Metrics and logs

• X-Ray traces and Application Signals service health

• Deployment events and CloudTrail change events

• AWS Health events

It returns observations, root-cause hypotheses with natural-language explanations, and suggested AWS Systems Manager Automation runbooks you can run to fix the issue. Your team accepts or discards each suggestion and shares the findings in an investigation report. It uses your existing permissions, creates no resources, and logs every action in CloudTrail.

GenAI Observability

If you are building generative AI applications or agents, CloudWatch GenAI Observability gives you out-of-the-box views of latency, token usage, errors, and performance, from model invocations through to agent operations. End-to-end prompt tracing helps pinpoint issues such as gaps in vector database retrieval or authentication failures.

It supports agents built with Amazon Bedrock AgentCore and frameworks such as Strands Agents, LangChain and LangGraph, and works with Application Signals, alarms and Logs Insights. The feature itself has no additional charge; standard CloudWatch pricing applies to the telemetry.

Ask questions in plain language

CloudWatch Logs Insights and Metrics Insights can generate queries from a plain-English question, such as "show the top 10 API errors by service in the last hour". Engineers who do not know the query syntax can still investigate quickly during an incident.

CloudWatch Omni: the next evolution of CloudWatch

In September 2026, AWS announced CloudWatch Omni, an AI-powered observability experience organised around teams and the applications they run. Key capabilities include:

• Spaces: one view of telemetry across multiple AWS accounts and Regions, and other clouds including Azure.

• Automatic discovery: maps services and their dependencies and surfaces golden metrics without manual dashboard building.

• Natural-language questions: ask what is wrong, and Omni finds the relevant telemetry and builds a view of it.

• AI-powered investigations: reach root cause with AWS DevOps Agent through chat or a guided experience.

• Open standards: built on OpenTelemetry, available as a standalone web experience with SSO or an IDE extension.

• AI agent observability: for teams building generative AI agents, trace explorer, built-in evaluators and experiments show how agents reason and call tools.

A note for MENA teams: As of October 2026, CloudWatch Omni is available in 11 AWS Regions, but none in the Middle East yet. Organisations with data residency requirements should check regional availability before planning around it.

One point matters more than any feature: AI is only as good as the telemetry it reads. Structured logs, tracing, and well-tuned alarms (moves 1 to 4 above) are what make these AI features accurate.

Where does your team sit? The observability maturity model

Most teams move through four stages. Each one shortens the time between something breaking and someone fixing it.

Many organisations we work with sit between Stage 1 and Stage 2: they have alarms and dashboards, but customers still report problems first, and investigations rely on manual log searches. Moving to Stage 3 usually delivers the biggest drop in resolution time, because engineers can finally follow a request from symptom to cause.

Scaling cloud observability on AWS: cost and multi-account tips

As telemetry grows, a little planning keeps observability affordable and easy to manage across teams.

• Set log retention by value. Apply CloudWatch Logs retention policies to each log group, and use the CloudWatch Logs Infrequent Access log class for logs that are kept mainly for audits.

• Sample traces sensibly. Use AWS X-Ray sampling rules to capture enough requests for clear insight without tracing every call.

• Collect what supports decisions. Prioritise telemetry linked to SLOs and critical customer journeys, and review unused metrics and dashboards each quarter.

• Use cross-account observability. CloudWatch cross-account observability lets a central monitoring account view metrics, logs, and traces from linked source accounts, giving operations teams one place to start every investigation.

For a wider view of the practices behind this, see our guide to monitoring and logging in DevOps.

How SUDO helps

SUDO Consultants is an AWS Premier Tier Services Partner holding the AWS Managed Service Provider (MSP), DevOps, Resilience, and Generative AI Competencies. Our team of 100+ AWS-certified engineers has supported 200+ customer launches on AWS from our offices in Dubai and Riyadh.

Through our managed cloud operations service, we run 24/7 monitoring and incident response for enterprises across the region. We bring that operational experience to every observability engagement:

• Assess: review your current alarms, dashboards, logging, and tracing against your critical customer journeys.

• Design: define SLOs, an alerting strategy, and a service-level dashboard structure that fits your architecture.

• Implement: roll out structured logging, OpenTelemetry tracing, composite alarms, synthetics, and runbook automation using Infrastructure as Code.

• Operate: hand over to your team, or let SUDO run detection and first response around the clock.

Frequently asked questions

What is the difference between monitoring and observability on AWS?

Monitoring checks known conditions, such as CPU or health checks, and alerts when they cross a threshold. Observability links metrics, logs, and traces so teams can understand why a system behaves the way it does, including for issues nobody predicted.

Which AWS services are used for cloud observability?

The core services are Amazon CloudWatch for metrics, logs, alarms, and dashboards, AWS X-Ray for tracing, AWS CloudTrail for API activity, and Amazon Managed Service for Prometheus. CloudWatch Application Signals adds application performance monitoring and SLOs.

How does OpenTelemetry work with AWS?

AWS Distro for OpenTelemetry is the AWS-supported distribution of OpenTelemetry. It collects metrics and traces from applications and sends them to CloudWatch, AWS X-Ray, and other destinations using open standards.

How can teams keep CloudWatch costs under control?

Set log retention policies, use the Infrequent Access log class for audit logs, apply trace sampling, and focus custom metrics on the customer journeys that matter most.

Is CloudWatch Omni available in the Middle East?

As of October 2026, CloudWatch Omni is available in 11 AWS Regions, none of them in the Middle East. Teams in the UAE and Saudi Arabia can use CloudWatch Application Signals, CloudWatch Investigations, and the other features covered in this guide today.

Conclusion: Building Cloud Observability on AWS step by step

Strong cloud observability on AWS comes from a few clear habits: alerting on customer symptoms, structured logs linked to traces, service level dashboards, and automated first response. With these in place, AI features in Amazon CloudWatch become more accurate, and teams spot and resolve issues before customers notice.

Ready to strengthen observability on AWS?

Our team reviews current alarms, logging, and tracing, and builds a clear plan to shorten detection and resolution time. Learn more about our 24/7 NOC and SOC monitoring services or talk to our team to book an observability assessment.

Faster Citizen Services, Full Data Compliance: A Practical Cloud Roadmap for Saudi Government Entities

maryam mairaj — Tue, 03 Nov 2026 08:20:04 +0000

Citizens in Saudi Arabia now expect government services to work like the best apps they use every day. They want to renew a document, book an appointment, or pay a fee in minutes, from their phone, at any hour. For government IT leaders, meeting that expectation is a direct part of delivering Vision 2030.

The pressure is real, and so are the constraints. Legacy systems slow every release. Peak demand can overwhelm portals that were sized years ago. And every decision must respect national requirements for cybersecurity, data governance, and data residency.

The good news is that speed and compliance are not a trade-off. With the right roadmap, government entities can do both. This article lays out a practical path to get there on AWS.

What is public sector digital transformation?

Public sector digital transformation is the move from paper-based and legacy processes to secure digital services that citizens and businesses can use at any time. In Saudi Arabia, it supports Vision 2030 and is guided by national bodies such as the Digital Government Authority (DGA), the National Cybersecurity Authority (NCA), and the Saudi Data and AI Authority (SDAIA).

Why citizen-facing services are hard to modernize

Most government entities face the same set of obstacles.

• Legacy infrastructure. On-premises systems take months to change, so new services reach citizens slowly.

• Unpredictable demand. A deadline, a campaign, or a new regulation can send traffic far above normal levels in a single day.

• Regulatory weight. Teams must align with frameworks from the National Cybersecurity Authority (NCA), the National Data Management Office (NDMO), and the Personal Data Protection Law (PDPL).

• Limited cloud capacity. Few teams have deep, hands-on experience designing and running compliant cloud environments.

These obstacles often push entities toward one of two bad options: delay the move to the cloud or move quickly and fix compliance later. Neither works for a government entity.

Treat compliance as a design input, not a final check

The most common mistake is to build first and ask compliance questions afterward. That leads to rework, delays, and avoidable risk.

A better approach is to bring compliance into the first design conversation. Start by classifying your data and mapping each workload to the national requirements that apply to it. That mapping decides where data can live, who can access it, and what controls must be in place.

When requirements are built into the architecture, compliance becomes repeatable. Every new service inherits the same guardrails instead of being reviewed from scratch.

A simple rule of thumb

Decide where each type of data may live before you decide how to migrate it. Data classification drives architecture, not the other way around.

The national frameworks behind government cloud in KSA

Saudi Arabia has one of the most detailed digital government and cloud rulebooks in the region. Platforms such as GOV.SA already bring many government services into one place, and the frameworks below shape how each new cloud service is designed.

Requirements differ by entity, sector, and data classification, so each roadmap starts by confirming which frameworks apply.

A phased roadmap for government cloud in KSA

A phased approach lowers risk, builds confidence, and shows results early. Here is a five-step roadmap we recommend.

1. Assess and prioritize

Inventory your applications, data, and dependencies. Classify data by sensitivity and score each workload on business value, citizen impact, and migration complexity. This gives you a ranked list instead of a vague ambition. A cloud migration readiness assessment gives this step a clear structure.

2. Build a secure landing zone

Before moving anything, set up a well-architected AWS foundation: a multi-account structure, identity and access controls, encryption, network segmentation, logging, and policy guardrails aligned to NCA and NDMO requirements. Doing this once, properly, saves months later. AWS Region choice matters here too. AWS has announced an AWS infrastructure Region in the Kingdom of Saudi Arabia, planned to open by the end of 2026, so data that must stay in the Kingdom can be hosted in an AWS Region in the country.

3. Start with high-impact workloads

Choose a first wave that citizens will notice: a high-traffic portal, an e-service, or a legacy application that slows delivery. Early wins build momentum and give your team practical experience.

4. Migrate and modernize

Not every workload needs the same treatment. Some can be rehosted quickly. Others benefit from re-platforming or re-architecting with containers and managed services. Match the approach to the value, not to a one-size-fits-all plan.

5. Operate with confidence

Go-live is the start of the work, not the end. Continuous monitoring, patching, security posture management, and cost control keep services healthy and compliant over time.

What "reliable" really means for citizen services

A government portal that is down during a peak deadline erodes public trust quickly. Reliability needs to be designed in from the start.

• Resilient architecture. Spread workloads across multiple Availability Zones so a single failure does not take a service offline.

• Disaster recovery. Define recovery time and recovery point targets for each service and test them regularly.

• Elastic scaling. Let capacity grow automatically with demand, then scale back when it passes.

• Proactive monitoring. Detect problems before citizens do and respond with clear runbooks and escalation paths.

• 24/7 operations. Citizen services do not keep office hours, so operations should not either.

Where to begin

You do not need to move everything at once. A practical first step is a short readiness assessment that answers three questions:

• Which services would deliver the most visible value to citizens if modernized first?

• Which data classifications apply to those services, and what do they require?

• What foundation (landing zone, security controls, operating model) must be in place before the first migration?

The answers become the backbone of your roadmap, with clear priorities, owners, and timelines.

How SUDO supports public sector entities in KSA

SUDO Consultants is an AWS Premier Tier Services Partner with a deep understanding of the Saudi regulatory landscape.

We support the full lifecycle. We help you plan the roadmap, build the secure foundation, migrate and modernize the services, and then operate them with 24/7 managed services. Your entity works with one trusted partner from strategy through to day-to-day operations.

• Strategic collaboration with AWS. SUDO Consultants has signed a strategic collaboration agreement with AWS focused on helping public and private sector entities across Saudi Arabia accelerate cloud adoption.
• Certified expertise. Our team holds more than 100 AWS Certifications, and SUDO Consultants holds four AWS Competencies, including DevOps and Resilience, and 13 AWS Service Delivery designations, including Amazon RDS, Amazon EKS, and AWS WAF.
• Local presence. Our Riyadh office in Kingdom Tower keeps our team close to government clients.
• End-to-end support. From planning and security to migration and operations, we cover every stage. Learn more about our work with government entities.

Frequently asked questions

What is public sector digital transformation in Saudi Arabia?

It is the shift of government services from legacy and paper-based processes to secure digital services, in line with Vision 2030. Cloud platforms such as AWS help entities launch services faster, scale with demand, and meet national compliance requirements.

Can Saudi government entities use public cloud services?

Yes, within the national frameworks. The Cloud First Policy encourages government entities to consider cloud services first, and NCA, NDMO, and PDPL requirements decide which data can be hosted where and which controls must be in place.

Does government data need to stay inside the Kingdom?

It depends on the data classification. Sensitive government data is generally expected to remain in Saudi Arabia, so each entity confirms its data residency requirements for every classification level before choosing an AWS Region.

How long does a government cloud migration take?

It varies with scope. A readiness assessment and secure landing zone usually come first, then services move in planned waves, so citizens can see results from the first wave while the wider programme continues.

Which compliance frameworks apply to government cloud projects in KSA?

The most common are the NCA Essential Cybersecurity Controls and Cloud Cybersecurity Controls, NDMO data management standards, and the Personal Data Protection Law. Sector regulators can add further requirements.

How do we choose the first services to move to the cloud?

Start with services that citizens use most and that deliver clear value when modernized, such as high-traffic portals and e-services, and score each one on citizen impact, data classification, and migration complexity.

Planning a public sector cloud roadmap?

We help government entities across Saudi Arabia plan, build, and operate secure, compliant AWS environments. Talk to our team to start with a readiness assessment.

Healthcare Cloud in the UAE: Modernizing Patient Care Without Breaking Compliance

maryam mairaj — Fri, 30 Oct 2026 09:15:35 +0000

If you run IT or compliance for a hospital, clinic group, or health tech company in the UAE, you've probably sat through this conversation more than once. Leadership wants faster systems, better patient apps, and real-time data. Then compliance asks the hard questions: where will patient data live, who can see it, and what happens when the auditor arrives?

Both sides have a point. For years, that tension kept many healthcare providers on ageing on-premises systems that nobody really liked, but everyone felt safe with.

With healthcare cloud in the UAE, it doesn't have to be a trade-off anymore.

What is healthcare cloud in the UAE?

Healthcare cloud in the UAE means running hospital, clinic, and health tech systems, such as electronic health records, patient portals, and telehealth apps, on a cloud platform hosted inside the country. It brings faster, more scalable services while keeping patient data in the UAE and aligned with federal and emirate-level health data rules.

Why healthcare cloud in the UAE is different

Health data in the UAE isn't treated like ordinary business data. The UAE health data law, Federal Law №2 of 2019 on the use of ICT in health fields, requires health data to be stored and processed inside the country, with only limited exceptions. On top of that, each emirate's regulator adds its own layer. In Dubai, the Dubai Health Authority (DHA) has its own data policies and NABIDH integration. In Abu Dhabi, the Department of Health enforces the ADHICS standard.

Here is how the main rules and platforms fit together:

So "just move it to the cloud" was never a real option. You need to know which region your workloads run in, how data is encrypted, who holds the keys, and how you'll prove all of it during an audit.

How AWS for healthcare in the UAE solves data residency

Data residency used to be the main blocker. Since AWS opened its Middle East (UAE) Region, providers can run workloads and keep patient data in the country while still using the scale and services of a global cloud.

That makes a few things much easier than they used to be:

Electronic health records that hold up during peak clinic hours
Patient portals and telehealth apps that work properly on mobile
Reporting on patient flow, bed occupancy, and outcomes without weeks of manual spreadsheet work
Disaster recovery that doesn't rely on a single server room in the basement

The region is only the starting point, though. Compliance depends on how you build on top of it.

Common patient data protection gaps to close early

In our work with healthcare organizations, the problems we find are rarely about the technology. They're usually gaps nobody noticed.

Data ends up in the wrong place. A backup, a log bucket, or a test environment quietly sits in a region outside the UAE.

Access is too wide. Developers, vendors, and support staff can reach far more production patient data than their jobs require.

Encryption is on, but nobody manages it. The data is encrypted, yet no one can say who controls the keys or when they were last rotated.

Audit evidence is scattered. When DHA or an internal auditor asks for proof, the team loses weeks collecting screenshots and spreadsheets.

None of these are hard to fix. They just need to be part of the design from day one, not patched in later.

DHA and ADHICS compliance on AWS: five practical controls

On AWS, protecting patient data under DHA, ADHICS, and federal rules comes down to these five steps:

Keep data in the UAE. Use service control policies so resources can't be created outside approved regions in the first place.
Encrypt everything and own the keys. AWS KMS with customer-managed keys gives you control over access and a clear record of every time a key is used.
Give people only the access they need. Role-based access through IAM Identity Center, MFA for everyone, and no shared accounts.
Monitor continuously. AWS Config, Security Hub, and CloudTrail show your security posture as it stands today and keep a full record of who did what.
Audit-ready by default. Keep your evidence ready before anyone asks for it. And when an auditor wants proof that AWS itself is secure, you can download AWS's compliance reports straight from AWS Artifact.

With this foundation in place, teams tend to move faster, not slower. Developers can ship new patient features without waiting on approval for every change, because the guardrails are already doing that job.

The AWS shared responsibility model

AWS is responsible for security of the cloud, including the data centers and infrastructure of the AWS Middle East (UAE) Region. Healthcare providers are responsible for security in the cloud, which covers how they configure access, encryption, logging, and backups. The five controls above are the practical side of that shared model. For a deeper look at key management, see our guide to AWS KMS encryption best practices.

How SUDO helps

SUDO Consultants works with healthcare organizations across the UAE as a compliance and modernization partner. As an AWS Premier Tier Partner, we've helped teams move off legacy systems while keeping regulators, auditors, and patients confident in how their data is handled.

AWS Premier Tier Partner. SUDO Consultants holds the highest tier in the AWS Partner Network.
Certified team. Our team holds more than 100 AWS Certifications.
Proven AWS expertise. Four AWS Competencies, including DevOps and Resilience, and 13 AWS Service Delivery designations.
Local presence. Headquartered in Dubai Media City, close to the healthcare providers we support across the UAE.
Healthcare focus. We design secure, compliant platforms for patient data. Read more about healthcare cloud architecture on AWS.

We usually start with one question: where are you today? We review your current setup against UAE healthcare data requirements, point out the gaps that matter most, and give you a clear plan you can act on. You won't get a 200-page report that ends up in a drawer.

Frequently asked questions about healthcare cloud in the UAE

Can healthcare providers in the UAE store patient data on the cloud?

Yes, when the cloud services run inside the UAE and meet federal and emirate health data rules. The AWS Middle East (UAE) Region lets providers keep patient data in the country while using AWS services.

Does patient data have to stay in the UAE?

In most cases, yes. Federal Law №2 of 2019 requires health data to be stored and processed in the UAE, and a 2021 Ministerial Resolution sets out specific exceptions, such as telemedicine and insurance claims.

What is the difference between DHA and ADHICS requirements?

DHA sets the rules for healthcare facilities licensed in Dubai, including NABIDH integration. ADHICS is the Department of Health Abu Dhabi standard for information and cybersecurity in facilities licensed in Abu Dhabi.

Which AWS services help protect patient data?

Common choices include AWS Key Management Service for encryption, AWS IAM Identity Center for access, AWS CloudTrail and AWS Config for audit records, and AWS Security Hub for a single view of security findings.

How long does it take to move a healthcare system to AWS?

It depends on the number of systems and integrations. Most programmes start with an assessment and a secure foundation, then move systems in planned stages, starting with those that bring the quickest benefit to patients.

Start with an honest look at where you stand

You don't need everything figured out before you talk to us. Most teams come to us with a mix of cloud, on-premises, and "we're not quite sure" systems.

Assess Your Healthcare Cloud Compliance Posture

Book a session with our team. We'll show you where you're compliant, where you're exposed, and what to fix first.

AWS Landing Zone Explained: Why Every Enterprise Cloud Needs a City Plan Before It Scales

maryam mairaj — Tue, 27 Oct 2026 13:03:18 +0000

Picture a city full of energy, where new buildings rise almost overnight and appear wherever there is space. Roads were added only when traffic became unbearable. Nobody issued ID cards, there were no building codes, and the only record of who lived where existed in a few people's heads. For a while, the city worked. Then it got big.

Many AWS environments grow in the same way. A team opens one account to launch a product quickly. A second team joins, then a third. Developers experiment next to production databases, admin access gets shared to save time, and nobody is quite sure who created that expensive cluster last quarter. The early speed is real. So is the hidden debt building up underneath it.

This is the problem an AWS landing zone solves. Think of it as the master plan for your cloud: the districts, laws, ID cards, roads, and records office that a city needs before thousands of people move in. This article walks through that plan in plain language, maps each part to the AWS service behind it, and explains why it matters to the business, not only to the engineering team.

What is an AWS landing zone?

An AWS landing zone is a secure, well-architected multi-account AWS environment, set up with identity, security, networking, and logging foundations before applications move in. Most organizations build and govern it with AWS Control Tower, which creates accounts from approved templates and applies guardrails to every account from day one.

1. When the Cloud Grows Faster Than the Plan

An unplanned cloud rarely fails on day one. It fails gradually, and the symptoms usually appear in four places:

• Security risk spreads easily. When everything lives in one account, one wrong permission or one compromised credential can reach production, testing, and experiments at the same time.

• Access gets out of hand. Users and access keys pile up over time, and removing access when someone leaves becomes a manual hunt.

• New projects wait. Every new team needs a safe environment. Without a standard way to create one, each request turns into a small custom project.

• Audits become painful. When an auditor asks who changed a setting, the answer depends on whether logging was switched on, and on whether anyone could have deleted the logs. As we explored in Prove It or Pay for It, evidence that has to be reconstructed by hand is expensive evidence.

None of this happens because teams are careless. Each shortcut made sense on the day it was taken: one shared account was faster to set up, one admin role was easier to manage, and logging could always be switched on later. The problem is that shortcuts compound. By the time the environment is large enough to hurt, untangling it is a project of its own.

2. Why an AWS Landing Zone Matters for Compliance in the UAE and Saudi Arabia

Cloud adoption across the GCC is accelerating, driven by national programs such as Saudi Vision 2030 and the UAE's digital government agenda. The same governments are also building some of the most detailed cloud and cybersecurity rulebooks anywhere. For government entities, banks and financial institutions, and critical infrastructure operators, governance is no longer something to add later. It is part of the price of entry.

Saudi Arabia

The National Cybersecurity Authority (NCA) sets the national baseline through its Essential Cybersecurity Controls (ECC). Its Cloud Cybersecurity Controls (CCC) extend the ECC specifically for cloud, with requirements both for cloud service providers and for the organizations that use them, which the NCA calls cloud service tenants. The CCC applies to government organizations and to private sector organizations that own, operate, or host critical national infrastructure. Banks and other financial institutions also answer to the Saudi Central Bank (SAMA) and its cybersecurity framework, which we cover on our SAMA compliance page.

United Arab Emirates

In the UAE, requirements come from both federal and emirate-level authorities:

• UAE Cyber Security Council. Its National Cloud Security Policy, first released in 2023 and since updated, sets requirements for both cloud consumers and cloud service providers. It applies to federal ministries and authorities and to non-government critical information infrastructure entities. Where an emirate runs its own critical infrastructure protection program, that emirate's lead authority handles applicability and enforcement.

• Telecommunications and Digital Government Regulatory Authority (TDRA). The UAE Information Assurance Regulation sets management and technical security controls for information and the systems that handle it, including information stored or processed through cloud services.

• Dubai Electronic Security Center (DESC). Its Information Security Regulation (ISR) defines security practices for Dubai Government entities. Its Cloud Service Provider (CSP) Security Standard is the certification that Dubai government and semi-government organizations must ensure their cloud provider meets. AWS holds this certification for its Middle East (UAE) Region.

• Data protection and sector regulators. The federal Personal Data Protection Law (Federal Decree-Law №45 of 2021) and sector regulators, such as the Central Bank of the UAE and the financial free-zone regulators in DIFC and ADGM, add further obligations depending on industry and location.

If data residency is shaping your provider decision, our guide on how to evaluate a cloud service provider in the UAE covers it in depth, and Cost-Efficient and Sovereign looks at how data rules interact with cloud spend across the GCC.

What the regulators have in common

The details differ by country, sector, and data classification, but these frameworks keep returning to the same expectations. This is where a landing zone earns its place: it turns those expectations into structure that exists by default, instead of evidence assembled by hand before an audit.

An important distinction

A landing zone supports compliance, but it does not deliver compliance on its own. A cloud provider's certifications cover the provider's side of the shared responsibility model. How you configure, operate, and evidence your own environment remains your responsibility, so always confirm which frameworks apply to you with your compliance team

3. What Is an AWS Landing Zone?

An AWS landing zone is a well-architected, multi-account AWS environment, set up with security, identity, networking, and logging foundations before applications move in. In city terms, it is the master plan drawn up before construction begins.

A landing zone is not a single product. It is a design built from several pieces working together. AWS Control Tower is the managed service most organizations use to build and govern it. For highly regulated environments, AWS also provides the open-source Landing Zone Accelerator on AWS, which is designed to work alongside Control Tower and adds deeper, configuration-driven control over networking and security. Choosing between the two and designing the structure itself is usually where cloud consulting support adds the most value.

Already running applications on AWS?

A landing zone is easiest to build before the first application goes live, but it is not too late afterwards. AWS Control Tower can register existing organizations and enroll existing accounts, so an unplanned city can be brought under a master plan step by step.

AWS Control Tower, Landing Zone Accelerator or a custom build?

There are three common ways to build an AWS landing zone. AWS recommends starting with AWS Control Tower and adding Landing Zone Accelerator on AWS when compliance requirements call for deeper control.

Some older guides refer to the AWS Landing Zone solution. That was an earlier AWS offering, and AWS has since stopped active development on it and directs organizations to AWS Control Tower as its successor, so new designs start with Control Tower.

4. Key Components of an AWS Landing Zone Architecture

Each part of a well-planned city has a direct equivalent in a landing zone. Here is how they fit together.

The city council: AWS Organizations and the management account

Every city needs a council that sets the rules, approves new districts, and pays the bills. In AWS, this role belongs to AWS Organizations and its management account. In a Control Tower landing zone, the management account handles consolidated billing, provisions new accounts, and manages organizational units and controls.

One rule matters here: the council does not run shops. AWS does not recommend running production applications in the management account, partly because service control policies do not apply to users and roles in that account. Keep it small, quiet, and tightly protected, with very few people able to sign in.

Districts and neighbourhoods: multi-account architecture

A city separates residential areas from industrial zones for good reason, and AWS accounts work the same way. Each account is a natural isolation boundary, so a failure or a mistake in one account stays there instead of spreading across one large, shared environment. Service quotas are also tracked per account, so one busy team cannot exhaust limits for everyone else.

Accounts are grouped into organizational units (OUs), which act like districts. A typical design includes a Security OU for logging and audit accounts, an Infrastructure OU for shared networking, a Workloads OU for production and development, and a Sandbox OU where teams can experiment safely. A useful rule of thumb: group accounts by the rules they need, not by the company org chart.

City laws: guardrails and service control policies

Laws only work when they apply to everyone, automatically. In a landing zone, these laws are called controls, often referred to as guardrails. AWS Control Tower classifies each control by when it acts: before a resource is built, at the moment of an action, or after a change has happened.

In a real landing zone, the three types work together. A few examples:

• Before deployment: a proactive control can reject an infrastructure template that would create a storage bucket without encryption configured, so the resource is never created.

• At the moment of action: a preventive control can stop anyone from changing the audit logging configuration or the bucket policy protecting the log archive, including administrators inside member accounts.

• After the fact: a detective control can flag an existing resource that has drifted out of policy, such as a storage volume that is not encrypted, so the team can fix it.

A useful detail for technical readers: service control policies (SCPs) never grant permissions. They set the maximum permissions available in member accounts, which is why they make such effective guardrails.

AWS Control Tower also offers optional preventive controls implemented with resource control policies (RCPs). Where SCPs limit what the identities in your accounts can do, RCPs limit what can be done to your resources, including requests that come from outside your organization. Used together, they help you build a strict data perimeter: for example, allowing only identities from your own organization to access resources such as Amazon S3 buckets, even if a bucket policy is accidentally made too permissive.

Guardrails are one layer of a wider AWS security strategy, not a replacement for it.

Resident ID cards: IAM Identity Center

In a planned city, every resident carries one ID card that opens only the doors they are entitled to. AWS IAM Identity Center plays this role. It is AWS's recommended service for managing human access across multiple accounts, and it can connect to the identity provider your company already uses.

Access is defined through permission sets, which describe what a role can do, and then assigned to groups for specific accounts. A developer might hold broad rights in a development account and read-only access in production. People sign in through a single portal and receive temporary credentials, which removes the need for long-lived access keys scattered across accounts.

Roads and utilities: networking

Roads connect districts, but you do not let every household build its own highway. Many landing zones place shared networking, such as a central connectivity hub built with AWS Transit Gateway, in a dedicated network account. Traffic between accounts and to on-premises systems then follows planned, inspectable routes, which is the foundation of strong infrastructure security.

Network design deserves its own article, and we have written one: Beyond Security Groups: Building a Layered AWS Network Defense for Regulated Enterprises.

CCTV and the records office: centralized logging

A well-run city keeps records that cannot be quietly erased. In an AWS Control Tower landing zone, a dedicated Log Archive account stores a copy of the AWS CloudTrail and AWS Config log files from the other accounts in a central Amazon S3 bucket. A separate, restricted Audit account gives security and compliance teams programmatic access to review the other accounts.

Because the logs live outside the accounts that generate them, a mistake or a compromised account in one district cannot wipe the city's records. Many landing zones also turn on Amazon GuardDuty for threat detection and AWS Security Hub to bring security findings from every account into one view. Collecting logs is only half the job, though. Someone has to watch them, which is where 24/7 monitoring through a NOC and SOC comes in.

The planning office: AWS Control Tower and Account Factory

Every city needs a planning office that approves new buildings from standard, pre-approved designs. AWS Control Tower brings the building blocks above together and automates much of the setup. Its Account Factory works like a vending machine for new accounts: teams request an account from a template with pre-approved settings, including network configuration and AWS Region selections, and receive it with the guardrails already applied. Teams that manage infrastructure as code can use Account Factory for Terraform, which fits naturally into existing DevOps workflows.

SUDO Consultants is an AWS Premier Tier partner with more than 100 AWS certifications across our team and wide AWS service delivery expertise. For most organizations we work with in the UAE and Saudi Arabia, AWS Control Tower is the fastest route to a well-governed foundation.

Note for practitioners

AWS Control Tower landing zone version 4.0 introduced more flexibility. For example, a Security OU is no longer required, and mandatory controls are no longer applied by default. Check which landing zone version you are running before following older guides.

The whole city at a glance

Putting it all together: people enter through one identity service, guardrails apply from the top of the organization, applications live in their own districts, traffic travels through a shared network hub, and every account's records flow to one protected office.

5. Business Benefits of an AWS Landing Zone

Once the master plan is in place, the benefits reach well beyond the engineering team:

• Faster project setup. New teams receive a governed account from a standard template instead of waiting for a custom build.

• Easier audits. Logs, access assignments, and control status already exist in one place, so evidence is collected rather than reconstructed.

• Contained risk. An incident in a development account stays in its own district instead of reaching production, which also makes resilient infrastructure easier to design.

• Clearer cost ownership. Every account has a purpose and an owner, so spend maps directly to teams and products, a strong starting point for an AWS cost optimization review.

• Room to grow. Adding the fiftieth account follows the same process as adding the fifth.

What an AWS landing zone costs and how long it takes

AWS Control Tower has no separate charge. Organizations pay for the AWS services it enables, such as AWS CloudTrail, AWS Config and Amazon S3 storage for logs, so the monthly cost grows with the number of accounts, regions, and controls in use.

Landing Zone Accelerator on AWS also carries no additional charge. AWS publishes a sample estimate of roughly USD 430 a month for its sample configuration with AWS Control Tower in a sandbox environment with no activity, in the US East (N. Virginia) Region. Actual costs vary by Region, design, and activity, so we recommend an estimate built on the planned account structure.

On timing, a baseline AWS Control Tower setup can be ready within hours, while a regulated design with a full account structure, network hub, and tailored controls usually takes several weeks of planning, building, and testing.

6. A Practical Example

Imagine a regional retail group with an online store, a loyalty app, and a data team, all sharing two AWS accounts. A developer testing a new feature accidentally changes a security group that production also depends on, and the checkout page goes down for an hour. Afterwards, the team struggles to explain to management who made the change and why it was even possible.

With a landing zone, the same developer works in a development account inside the Workloads OU. Their access comes from IAM Identity Center and stops at that account's boundary. Guardrails block risky changes, the activity is recorded in the Log Archive account, and production never feels the mistake. The incident report becomes a short note instead of a crisis meeting.

This scenario is illustrative and does not describe a specific customer.

7. How to Set Up an AWS Landing Zone: Five Practical Steps

1. Map what you have. List your AWS accounts, their owners, who holds admin access, what runs where, and which regulations apply to each application. An AWS Well-Architected Review is a structured way to find the biggest gaps. If you are still planning your move to AWS, a cloud migration readiness assessment is the right place to design the landing zone from day one.

2. Draw the district map. Design your OU and account structure around how policies differ between applications, for example, regulated versus non-regulated data, or production versus development. Keep it simple: a structure that is easy to explain is easier to govern.

3. Lay the foundation. Set up AWS Control Tower from a clean management account, and choose the home Region with care, because it is difficult to change later and shapes data residency from day one. For heavy compliance requirements, Landing Zone Accelerator on AWS adds deeper control alongside it.

4. Add laws gradually. Start with a small set of well-understood controls, test them in the Sandbox OU, then extend them to production and development accounts. Document every exception, because exceptions are exactly what auditors ask about.

5. Keep the plan alive. Cities change, and so will your landing zone. Review access, controls, and structure on a regular schedule and resolve drift as soon as it appears, or work with a managed cloud services partner to operate it day to day.

8. Common Mistakes to Avoid

• Recreating shared admin access in the new structure. Moving to many accounts does not help if everyone still receives full administrator rights everywhere. Define permission sets per role and per environment.

• Changing landing zone resources by hand. AWS warns that modifying or deleting Control Tower-managed resources outside supported methods can leave the landing zone in an unknown state.

• Treating the landing zone as a one-time project. Without ongoing ownership, configurations drift, and the city slowly becomes unplanned again.

• Copying someone else's map. Your OUs and controls should reflect your own business, risk, and regulatory needs, not another company's template.

Conclusion: Plan the City Before the Crowd Arrives

Nobody would build a city by pouring concrete first and drawing the map later, yet that is how many cloud environments are built. A landing zone reverses the order. It gives every team a safe place to build, gives leadership confidence that the rules apply automatically, and gives auditors and regulators clear answers instead of a scramble for evidence.

Whether an organization is starting fresh on AWS or bringing order to an environment that grew too fast, a well-planned AWS landing zone is the place to begin.

Frequently Asked Questions About AWS Landing Zones

What is the difference between an AWS landing zone and AWS Control Tower?

A landing zone is the design: the accounts, guardrails, identity, networking, and logging that form a governed AWS foundation. AWS Control Tower is the managed AWS service most organizations use to build and operate that design, so Control Tower is one way to create a landing zone rather than an alternative to it.

How much does an AWS landing zone cost?

AWS Control Tower and Landing Zone Accelerator on AWS carry no separate charge. The cost comes from the services they enable, such as logging, configuration recording, and security monitoring, and it depends on the number of accounts, regions, and controls in the design.

How long does it take to set up an AWS landing zone?

A baseline AWS Control Tower setup can be ready within hours. A design for a regulated organization, with a tailored account structure, network hub, and controls, usually takes several weeks, including planning and testing.

Can existing AWS accounts be moved into a landing zone?

Yes. AWS Control Tower can register existing organizational units and enroll existing accounts, so an environment that grew without a plan can be brought under governance step by step, starting with non-production accounts.

Does an AWS landing zone help with NCA and DESC compliance?

A landing zone supports compliance by building access control, central logging, and continuous monitoring into the environment by default. It does not deliver compliance on its own, so each organization confirms which NCA, SAMA, DESC, or other requirements apply with its compliance team.

When should an organization use Landing Zone Accelerator on AWS?

Landing Zone Accelerator suits organizations with strict regulatory requirements, such as government entities and financial institutions, that need deeper control over networking, encryption, and security settings. It is deployed alongside AWS Control Tower rather than replacing it.

Why Choose SUDO Consultants

We help organizations plan, build, and run AWS foundations that stay secure and well governed as they grow:

• AWS Premier Tier Services partner. SUDO Consultants holds AWS Premier Tier Services status in the AWS Partner Network.

• Certified team. Our team holds more than 100 AWS certifications.

• Proven AWS expertise. Four AWS competencies, including DevOps, Generative AI, and Resilience, and 13 AWS service delivery validations.

• Local presence. Headquartered in Dubai Media City, with an office in Kingdom Tower, Riyadh.

• End-to-end support. We design, migrate, secure, and operate AWS environments, from landing zone design to managed cloud services.

Planning your landing zone?

SUDO Consultants helps organizations across the UAE, Saudi Arabia, and beyond design, build, and operate secure AWS foundations. If you are planning a landing zone, or want a second opinion on the one you already have, talk to our team.

Prove It or Pay for It: The Real Cost of Weak Data Governance in GCC Financial Services

maryam mairaj — Wed, 07 Oct 2026 07:18:01 +0000

Data governance is a business capability rather than a compliance document. When an organisation cannot answer a regulator’s question about its own data, the consequences appear in places leadership can measure: penalty notices, remediation programmes that suspend the technology roadmap, artificial intelligence initiatives held at risk review, and analyst time spent reconstructing evidence manually.

For banks and financial institutions in the GCC, strong data governance means being able to show a regulator, on request, where regulated data sits, who accessed it, and where reported figures came from, using records the platform produces automatically.

Across banks and financial institutions in the UAE and Saudi Arabia, the inability to demonstrate compliance is among the more consistently underestimated business problems in technology. This blog examines the cost of weak data governance in GCC financial services, what regulators currently accept as proof, what an evidence-ready data platform on AWS requires, how to assess current maturity, and how agentic AI is likely to change the economics of this work. It is written for the practitioners who own this work: cloud architects, platform engineers, heads of infrastructure, and the compliance leads responsible for signing off on what is built.

What Weak Data Governance Costs

Compliance discussions typically begin with a governance framework presentation: control domains, ownership, board sign-off date. The intended message is that the area is addressed.

A more specific question tends to establish the actual position. If a regulator submitted a request identifying every system holding customer personal data, the physical location of each copy, and a record of who accessed the transaction tables in the preceding quarter, how long would the organisation require to respond, and would the response be suitable for submission?

In many institutions, the honest answer is measured in weeks rather than days. The controls are generally present. What is absent is the ability to demonstrate that they operate, and that gap carries cost in five areas.

In June 2026, the CBUAE fined a foreign bank branch AED 20 million for significant, repeated failures in its anti-money laundering, counter terrorist financing and sanctions framework, and imposed a separate AED 300,000 penalty on the branch’s Head of Compliance and Money Laundering Reporting Officer.

The second penalty is significant beyond its value. Regulatory exposure in the region now extends to named individuals, and it attaches to whether a control demonstrably operates rather than whether it is documented.

The fourth category is the one organisation rarely forecast. The person-days spent assembling evidence before each examination, extracting reports, reconciling inconsistent exports and obtaining confirmations from system owners, recur every supervisory cycle and produce no durable capability, because the underlying platform is unchanged.

The fifth category has the longest-term effect. Where an organisation cannot establish the location of regulated data or the history of access to it, generative AI initiatives remain at risk review, new products require individual data assessments, and migration progresses at the pace of legal clearance. Weak data governance creates regulatory exposure and also constrains the rate at which the institution can change.

What GCC Regulators Require as Proof

Supervisory examination has shifted over the past five years from assessing whether appropriate frameworks exist to assessing whether those frameworks produce evidence.

The CBUAE’s updated AML/CFT/CPF guidance, issued in April 2026, places greater weight on ongoing monitoring, robust record-keeping, and timely remediation of control gaps. The institutions subject to findings generally hold frameworks. What they cannot do is evidence them.

Kingdom of Saudi Arabia

The Saudi Central Bank (SAMA) Cloud Computing Regulatory Framework requires customer data, transaction records, and business continuity backups to remain on infrastructure within the Kingdom. Backups are specified explicitly, which affects institutions whose primary workload is compliant and whose disaster recovery copy is not.

The National Cybersecurity Authority (NCA) requires data classification, data flow mapping, and technical enforcement of geographic boundaries. The National Data Management Office (NDMO), operating under the Saudi Data and Artificial Intelligence Authority (SDAIA), adds national data governance controls covering classification, data quality, metadata, and retention. SDAIA also oversees the Personal Data Protection Law, and SAMA has directed the institutions it supervises to align their data governance policies with it.

United Arab Emirates

CBUAE’s anti-money laundering and counter terrorist financing expectations centre on demonstrated operational effectiveness: transaction monitoring that functions rather than transaction monitoring that exists, consistent application of customer due diligence, and governance oversight supported by a traceable record.

Personal data obligations depend on where an institution is licensed. CBUAE regulation applies onshore, the UAE PDPL covers personal data outside the categories it excludes, and the DIFC and ADGM free zones apply their own data protection laws. Each regime assumes the institution already knows where personal data resides.

Taken together, these frameworks reduce to four questions with four corresponding evidence artefacts. The mapping below translates regulatory language into requirements an engineering team can implement.

None of these requirements are satisfied by attestation. The expectation is also long established: the Basel Committee published BCBS 239 in 2013, requiring accurate and timely risk data aggregation, and continues to report incomplete implementation across large institutions thirteen years later. A requirement that remains unmet across that period indicates a structural problem rather than insufficient effort.

Why Institutions With Established Frameworks Still Fall Short

The cause is generally accumulation rather than negligence.

Customer data becomes distributed across a core banking platform, several CRM systems inherited through acquisition, a data warehouse, analytical extracts without formal ownership, and software as a service applications procured directly by business units. No single function retains a complete view, so no authoritative map exists.

Logging coverage is commonly weaker than assumed:

• Organisations frequently believe they hold comprehensive access records when they hold control plane activity only.

• Object-level reads on storage and function-level invocations are often not captured, as this logging is disabled by default and incurs additional cost.

• Log data is distributed across multiple accounts with inconsistent retention periods and no common identity for correlation.

• Access granted for completed projects is not revoked, as revocation requires explicit action.

• Classification was conducted as a point-in-time exercise, so the resulting map describes an estate that has since changed.

Consequently, when an examiner requests a record of who accessed a given dataset, the position is that no record exists. The records were not deleted; they were never generated. This is not recoverable retrospectively, which is the reason audit logging warrants priority over other remediation activity.

How the AWS Shared Responsibility Model Strengthens Your Compliance

This point warrants separate treatment, as it is the most common misunderstanding in regulated cloud estates and is specific to hyperscale platforms.

AWS maintains an extensive compliance programme, with attestations available through AWS Artifact covering SOC 1, SOC 2, SOC 3, ISO 27001, ISO 27017, ISO 27018, PCI DSS and a range of regional frameworks. Institutions reviewing that portfolio may conclude that the platform substantially addresses the compliance question.

The AWS Shared Responsibility Model explains why this isn't the case. AWS is responsible for security of the cloud: physical data centres, hardware, the hypervisor, and managed service infrastructure. The customer is responsible for security in the cloud: data classification, identity and access management, encryption configuration, network controls, logging, and the evidence that these operate as intended.

Applied to SAMA, NCA, NDMO, and CBUAE requirements, the boundary is clear. AWS Artifact provides evidence of the Region’s physical and operational controls, which addresses part of a cloud outsourcing assessment. It does not address whether an S3 bucket policy permits cross-account access, whether object-level reads are logged, whether a backup vault resides in the correct jurisdiction, or whether deployment to an unapproved Region is technically possible.

Those are the areas in which findings are raised, and each falls on the customer side of the boundary. Establishing where that boundary sits, and maintaining evidence on the customer side of it, accounts for much of the difference between a clean examination and a remediation programme.

Data Residency and the AWS Saudi Arabia Region

AWS has confirmed that its first infrastructure Region in Saudi Arabia is on track to launch in December 2026, representing more than $5.3 billion in planned investment. Separately, AWS and HUMAIN plan to make up to 50MW of AI capacity available in the Kingdom’s first AI Zone by 2028.

For regulated institutions in the Kingdom, this removes the principal structural obstacle to cloud adoption. In-country residency for customer data, transaction records and continuity backups becomes achievable within a hyperscale environment rather than solely through local hosting arrangements. Institutions should still confirm which AWS services are available in the Region at launch before finalising their architecture.

Two consequences follow.

For institutions migrating in 2027, data governance sits on the critical path. Migration exposes governance gaps immediately. Data cannot be classified if it has not been mapped, residency cannot be enforced across flows that have not been traced, and account and network boundaries cannot be designed around undocumented access patterns. Organisations that complete this work during the planning window migrate into a controlled environment. Those that defer it transfer the existing position into new infrastructure and encounter it again at the first post-migration examination.

For institutions with obligations arising before the Region opens, interim options exist. The AWS Well-Architected Data Residency and Hybrid Cloud Lens addresses this scenario, recommending AWS Outposts or AWS Local Zones where data must reside in a country without a local Region, with AWS Dedicated Local Zones available for stricter sovereign requirements. These are supported architectures rather than workarounds. The governance layer can be established now, and the workload relocated subsequently, as the evidence model does not change when the Region becomes available.

The Evidence Ready Data Platform on AWS: Five Layers

Where the objective is framed as evidence on demand rather than improved documentation, the architecture follows directly. The requirement is a platform in which compliance evidence is generated as a byproduct of normal operation.

Each layer below maps to controls in the SAMA Cyber Security Framework, which helps when presenting the design to an examiner in terminology they already use.

Layer 1: Residency as a Technical Control

A governed landing zone on AWS Control Tower and AWS Organizations establishes account structure, guardrails, and Region restrictions at the organizational level. Service control policies denying unapproved Regions convert data residency from a written commitment into a technical constraint that individual teams cannot bypass, including unintentionally.

Service traffic should remain off the public internet through VPC endpoints, and encryption key custody should remain in Region under AWS KMS with key policies subject to formal review. Sovereignty concerns include who can compel access to encryption keys as well as where data is stored, and this distinction is generally the one legal functions prioritise.

Layer 2: Classification Through Discovery

Amazon Macie provides continuous discovery and classification of sensitive data across Amazon S3, replacing periodic questionnaires with a map reflecting the current state. Scoping through sampling and targeted jobs is advisable rather than applying it across the full estate initially, as cost scales with volume scanned.

A map that updates weekly and contains some inaccuracy is more useful than a complete map that was accurate eighteen months previously.

Layer 3: Audit Trails Suitable for Examination

AWS CloudTrail data events should be enabled for storage holding regulated data, in addition to management events. Consolidating CloudTrail data into a dedicated log archive account, with retention matched to the applicable regulatory obligation, makes access history queryable rather than requiring manual extraction from object storage. AWS closed CloudTrail Lake to new customers in May 2026 and directs new users to Amazon CloudWatch for equivalent query capability; institutions already using CloudTrail Lake can continue to do so.

Amazon S3 Object Lock should be applied to the archive in compliance mode rather than governance mode. Governance mode permits a sufficiently privileged principal to override retention, which is the specific objection examiners raise. Compliance mode cannot be overridden by any principal, including the account root. The same distinction applies to AWS Backup Vault Lock, which addresses the SAMA backup residency and immutability requirements through a single control.

Layer 4: Lineage and Enforced Permissions

AWS Glue Data Catalog and AWS Lake Formation centralise definitions and enforce tag-based access control, making access rights and data origin queryable rather than subject to investigation.

This layer delivers value beyond compliance, as it provides the same foundation required by analytics and generative AI workloads. Organisations that position data governance as an enabler of AI capability rather than solely as a compliance cost generally secure approval more readily.

Layer 5: Continuous Evidence Generation

AWS Config with conformance packs evaluates configuration state against the defined control set continuously. AWS Security Hub, Amazon GuardDuty and Amazon Security Lake normalise findings across a multi-account estate into a single queryable layer. AWS Audit Manager assembles collected evidence into structured report packages on a defined schedule.

One qualification applies: Audit Manager provides collection and structure, not the control mapping. Personnel who understand both the regulatory framework and the estate are still required to map SAMA, NCA, NDMO or CBUAE requirements onto technical evidence. This step is consistently underestimated and is where programme schedules most often extend.

Combined with continuous monitoring, configuration drift is identified within hours rather than appearing as an examination finding.

Assessing Data Governance Maturity

Before selecting tooling, organisations should establish a baseline. Identify the three data questions the regulator is most likely to ask, then measure the time required to answer them with evidence suitable for submission. That measurement provides a more accurate indication of maturity than a framework assessment, and generally supports the business case more effectively.

Institutions that run this test honestly often place themselves between Reactive and Documented. Controlled is achievable within a quarter for a defined scope. Evidence ready represents a programme, but one with a measurable completion point.

Agentic AI and the Next Phase of Compliance Evidence

The direction of development here is worth noting, as it alters the economics of compliance operations.

The principal cost in compliance is not the generation of evidence but its interpretation: reviewing a regulatory control, identifying the technical artefacts that demonstrate it, assembling those into a form an examiner will accept, and repeating the process each cycle. This work requires judgement, is repetitive, and is currently performed by senior personnel under time constraints.

This class of problem is well suited to agentic systems. With a governed data platform in place, an agent can query the audit log archive for access history, retrieve Config state for a given control, obtain the relevant Audit Manager evidence, and prepare the mapping for human review. Amazon Bedrock with retrieval over an organisation’s own control documentation and evidence store supports this pattern today.

The prerequisite is the significant point. An agent cannot query evidence that was never captured. Organisations establishing the governance layer now will be positioned to automate the interpretation layer subsequently. Those that do not will continue to perform it manually.

A 90 Day Data Governance Plan on AWS

Common Implementation Errors

Treating AWS Artifact as complete compliance coverage. It addresses the infrastructure layer. Requirements above that layer remain the customer’s responsibility to evidence, and that is where findings are raised.

Treating management-level logs as access logs. Without CloudTrail data events on regulated storage, read activity cannot be established, and remediation does not recover history that was never captured.

Applying Object Lock or Vault Lock in governance mode. The control appears equivalent in architectural documentation but does not satisfy examination scrutiny.

Addressing the primary workload without the backup. SAMA specifies business continuity backups explicitly. A disaster recovery copy in a non-approved jurisdiction constitutes a finding irrespective of the primary configuration.

Treating classification as a time-bounded project. An exercise completed eighteen months previously describes an estate that has since changed.

Attempting estate-wide remediation simultaneously. Enterprise-wide governance programmes reliably produce documentation while leaving the original questions unanswered. A defined scope delivering verifiable evidence, subsequently extended, is more effective.

Managing cost optimisation and governance as separate programmes. Region selection, tagging schema and disaster recovery topology are simultaneously cost and compliance decisions.

Who Should Own Compliance Evidence and How SUDO Helps

The technical requirements described above are well understood. Programme outcomes are more commonly determined by organisational factors: compliance and engineering functions report to different executives, apply different terminology, and hold no shared definition of completion.

The effective change is to treat evidence as a platform deliverable rather than a compliance deliverable. Where the engineering function owns production of evidence, and the compliance function owns validation, examination preparation becomes a reporting activity rather than an event. That change in ownership has greater effect on examination outcomes than any individual service described here.

SUDO Consultants, an AWS Premier Tier Partner with offices in Dubai and Riyadh, helps financial institutions in the UAE and KSA build AWS environments that produce compliance evidence as part of normal operation. An engagement can cover:

• Baseline assessment against the three regulator questions and the shared responsibility boundary

• Governed landing zone with Region guardrails, VPC endpoints and in-region key custody

• Immutable audit trails using CloudTrail data events, S3 Object Lock and AWS Backup Vault Lock

• Data classification and lineage using Amazon Macie, AWS Glue Data Catalog and AWS Lake Formation

• Continuous evidence generation with AWS Config, Security Hub, Security Lake and Audit Manager

• Agentic AI on Amazon Bedrock to prepare control mappings for compliance review

Key Takeaways

• GCC supervision has moved from framework review to evidence review, and enforcement now extends to named individuals in addition to institutions.

• The penalty is rarely the highest cost. Remediation cycles, recurring manual evidence assembly, and constrained strategic initiatives generally exceed it.

• The AWS Shared Responsibility Model establishes where AWS Artifact coverage ends, and customer obligation begins. Most examination findings fall on the customer side.

• The AWS Saudi Arabia Region creates a dated planning requirement for institutions in the Kingdom. Outposts, Local Zones, and Dedicated Local Zones are supported interim patterns.

• Residency enforcement, immutable backups, and audit logging offer the highest return as initial measures. They escalate most rapidly with regulators and are least expensive to address early.

• A governed data platform is also the prerequisite for automating compliance interpretation through agentic AI, and for generative AI use cases currently held at risk review.

Frequently Asked Questions

Does the AWS Saudi Arabia Region satisfy the SAMA data residency requirement independently?

It removes the infrastructure constraint but not the governance obligation. SAMA requires evidence that regulated data, including business continuity backups, remains within the Kingdom. This requires Region-deny guardrails, data flow mapping, in-Region key custody, immutable backup vaults, and audit trails demonstrating no unauthorized egress. The Region makes compliant architecture achievable rather than automatic.

Can AWS compliance certifications be relied upon for SAMA and NCA requirements?

For the portion within AWS control. AWS Artifact provides attestations covering the Region’s physical and operational controls, addressing part of a cloud outsourcing assessment. Configuration, identity and access management, encryption posture, logging, and residency enforcement remain the customer’s responsibility to evidence under the Shared Responsibility Model.

What is the difference between S3 Object Lock governance mode and compliance mode?

Governance mode allows a sufficiently privileged principal to override retention settings. Compliance mode cannot be overridden by any principal, including the account root, which is why examiners expect regulated audit archives and backups to use compliance mode.

Is an existing AWS landing zone sufficient for examination?

Generally not on its own. Most landing zones are designed for operational separation rather than evidence production. The most frequently identified gaps are CloudTrail data events disabled, log retention shorter than the regulatory obligation, mutable log storage, backup vaults without Vault Lock, and absence of mapping between technical controls and framework requirements.

What is a realistic timeline to achieve evidence on demand for one data domain?

For a single regulated domain on an existing AWS footprint, 90 days is realistic for residency enforcement, audit trail, and scheduled evidence generation. Full classification and lineage across a large estate requires longer and should follow rather than precede that work.

What are the ongoing costs?

The material recurring costs are CloudTrail data events, log archive storage and query, and Macie scanning, each scaling with volume and warranting deliberate scoping rather than estate-wide enablement initially. In most estates, these costs fall below the person-days currently allocated to manual evidence assembly each cycle.

Prove It Before You Are Asked.

Data governance in GCC financial services is now judged on evidence, not intent. Book a free consultation with SUDO to measure how quickly your institution can answer the three regulator questions today, and what it takes to become evidence-ready on AWS.

► Assess Your Data Governance Evidence Readiness with SUDO

Explore SUDO’s SAMA compliance solutions built on AWS.

► View Our SAMA Compliance Services

Every Failed Deployment Costs More Than You Think: Building Delivery Confidence on AWS

maryam mairaj — Tue, 06 Oct 2026 10:15:45 +0000

Delivery speed is not a technical metric. It is a business outcome. Every time a deployment fails, rolls back, or triggers a release freeze, the cost appears somewhere leadership can see: a missed launch window, a customer who abandons during an outage, a senior engineer spending Friday night firefighting instead of building.

Across enterprise teams in the UAE and KSA, deployment risk is one of the most consistently underestimated business problems in technology. This blog covers why it costs more than most teams realize, what a production-grade delivery pipeline on AWS looks like, how to measure your team against the benchmarks that matter, and where AI agents are taking this next.

At SUDO Consultants, an AWS Premier Tier Partner working with banking, retail, logistics, and government teams across the UAE, Saudi Arabia, and the wider MENA region, we design and build the delivery pipelines described below, and the guidance here comes from that hands-on work.

1. What a Failed Deployment Actually Costs

Most teams measure deployment failures by time to recovery. That is the right operational question but the wrong business question. The business question is: what did this cost across every dimension?

Gartner estimates the average cost of IT downtime at over 5,600 USD per minute. For payment platforms and banking applications in the region, that is the number your CFO starts calculating the moment a deployment alert lands in a group chat.

2. Why Teams Are Still Deploying Manually

The justifications for manual deployment are not irrational. They reflect real experience and real risk aversion.

We tried to automate, and it broke something. Poorly designed automation can amplify risk. The answer is better automation design, not a return to manual processes.

Our application is too complex to automate. Complexity is rarely the real barrier. The barriers are undocumented dependencies and inconsistent environments. Automation surfaces those problems. Avoiding automation avoids the harder conversation.

Everything is running, and we do not want to risk it. The most expensive reason. A team that deploys monthly because everyone is afraid to release is not stable. It is brittle. The risk has not been eliminated. It has been concentrated into one high-stakes event every four weeks.

3. Measuring Delivery: The DORA Framework

Delivery confidence is measurable. The DORA metrics, from the DevOps Research and Assessment programme, are the four numbers that tell you more about the health of your delivery process than any internal dashboard. They are increasingly what investors, enterprise procurement committees, and boards ask for in technology due diligence.

• Deployment Frequency: How often you successfully release. Elite teams deploy on demand. Most MENA teams deploying manually sit at Low or Medium, releasing monthly or less.

• Lead Time for Changes: Commit-to-production duration. Elite teams achieve under one hour. Manual processes typically take days to weeks.

• Change Failure Rate: Percentage of deployments causing an incident. Elite teams hold below 5 percent. Teams without automated testing routinely exceed 15 percent.

• Mean Time to Recovery: How quickly you restore after a failure. Elite teams recover in under one hour. Manual rollback routinely takes hours or longer.

4. The AWS CI/CD Pipeline Architecture

A production-grade delivery pipeline on AWS is a set of services working together as a system. Each stage has a specific purpose and an automated gate. A failure at any gate stops the pipeline before bad code moves forward.

• Source: AWS CodePipeline connects to GitHub, GitLab, Bitbucket, and CodeCommit. Branch protection rules ensure no code proceeds without a peer review and passing status check.

• Build with CodeBuild: Fully managed build environment. Compiles code, runs unit tests, and packages the artefact. Integrates with AWS Secrets Manager so credentials never appear in build logs.

• Test: Integration tests, SAST security scanning, dependency vulnerability checks, and load testing run automatically. Code that fails any gate is stopped, and the developer is notified immediately.

• Staging with Approval Gate: Auto-deploys to staging, runs smoke tests, and presents a manual approval step before production. Approval is logged and timestamped as part of the audit trail.

• Production with CodeDeploy: Deploys using the strategy appropriate for the workload. CloudWatch monitors key metrics and triggers automatic rollback if error rates or latency degrade beyond the defined threshold.

• Observe with CloudWatch and X-Ray: Continuous metric tracking, distributed tracing, and deployment markers so your team sees exactly what changed when, and where any issue originates.

5. Choosing the Right Deployment Strategy

The pipeline delivers code to production. The deployment strategy determines how safely it arrives.

• Blue/Green: Full parallel environment. Switch traffic from current to new in one action. Instant rollback if anything degrades. The right default for mission-critical production workloads.

• Canary: Route a small percentage of traffic to the new version first. CloudWatch monitors error rate and latency. Expand progressively on success, roll back automatically on failure. Right for high-traffic applications needing real-world validation.

• Rolling: Replace instances gradually. Lower cost than Blue/Green. Right for lower-criticality workloads with graceful degradation.

• Feature Flags with AWS AppConfig: Deploy code without activating features. Enable for specific users or traffic percentages independently of the deployment. Separates deployment from release entirely.

6. Infrastructure as Code and Secrets Management

Your pipeline is infrastructure. It should be version-controlled, peer-reviewed, and deployed the same way your application code is. If it exists only as manual console configurations, it is not reproducible, not auditable, and one misclick away from breaking your entire delivery capability.

• AWS CDK: Define your pipeline in TypeScript, Python, or Go. CDK Pipelines creates self-mutating pipelines that update themselves as part of a deployment. Your pipeline becomes a code artefact reviewed in pull requests.

• GitHub Actions with OIDC Federation: Eliminates long-lived AWS credentials stored as GitHub secrets. Your build environment authenticates with AWS using temporary credentials scoped to exactly the permissions needed.

• AWS Secrets Manager: No credential, API key, or certificate should appear in pipeline configuration as plaintext. Secrets Manager provides centralized storage with automatic rotation and native integration with CodeBuild, ECS, EKS, and Lambda.

7. AWS DevOps Agent and Kiro: The Agentic Layer

Two AWS services released in late 2025 and 2026 are beginning to change the DevOps operating model in a meaningful way. Both are production-ready and available today.

AWS DevOps Agent

Launched in preview in December 2025, generally available from March 2026. When a CloudWatch alarm fires, or Datadog, Dynatrace, New Relic, or Splunk detect an anomaly, AWS DevOps Agent begins investigating immediately. It builds an application topology from your resources, correlates metrics, logs, traces, and deployment history autonomously, and generates a root cause analysis and mitigation plan in minutes. During the preview period, customers reported a 75 percent reduction in mean time to resolution and 80 percent faster investigations. The agent routes findings through Slack, ServiceNow, and PagerDuty automatically. Beyond incident response, it analyses patterns across historical incidents to proactively recommend improvements to your pipeline, observability, and infrastructure.

Kiro

Announced in July 2025, generally available from May 7, 2026. Kiro is AWS’s spec-driven agentic IDE and the successor to Amazon Q Developer for IDE-based AI assistance. New Amazon Q Developer signups were closed as of May 15, 2026. Kiro’s design principle is that it generates a structured specification, including requirements, design, and a task list, before writing any code. Those files stay in your repository as living documentation. For DevOps workflows, the Kiro CLI receives mitigation specifications from the AWS DevOps Agent, implements the fix across the relevant files, and opens a pull request automatically. The Kiro Autonomous Agent operates in the background, picking up tasks and opening PRs without a human in the loop.

The combined workflow: CloudWatch alarm fires. DevOps Agent investigates and generates a mitigation spec. Kiro CLI implements the fix and opens a pull request. Engineer reviews and approves. Pipeline deploys. The entire cycle completes in minutes, not hours. The only human step is the pull request review.

8. Where Your Team Sits Today

Most MENA enterprise teams operate between Level 2 and Level 3 on the DevOps maturity model. Some automation exists, but deployment is still stressful, metrics are not consistently tracked, and the pipeline is not yet fully trusted. The move from Level 2 to Level 3 is achievable in a focused 90-day program.

9. The Cultural Shift and How SUDO Helps

Pipeline architecture solves the technical problem. Culture determines whether the investment sticks. Automation changes who owns what, from a small group of people with deployment access to a pipeline the whole team trusts. Teams that make this transition successfully do three things: they start with one application fully automated and demonstrate it working before asking the organisation to follow; they publish DORA metrics so the improvement is visible; and they treat pipeline failures in lower environments as learning opportunities rather than incidents.

We have designed and built delivery pipelines for enterprise teams in banking, retail, logistics, and government across the UAE and KSA. Every engagement starts with a DevOps maturity assessment and DORA baseline, and builds a programme around your specific workloads, team, and compliance requirements.

• DevOps maturity assessment and DORA baseline measurement

• CI/CD pipeline build using CodePipeline, CodeBuild, and CodeDeploy

• Blue/Green and canary deployment configuration across EKS, ECS, EC2, and Lambda

• Infrastructure as Code using AWS CDK or Terraform with self-mutating pipelines

• GitHub Actions integration using OIDC federation

• AWS DevOps Agent integration for autonomous incident investigation

• Kiro implementation for spec-driven development and agentic code remediation

• Team enablement, ownership transition, and DORA tracking dashboards

Stop Fearing Deployments. Start Owning Them.

Book a free DevOps maturity review with SUDO. We will show you exactly where your team sits and what it takes to build delivery confidence on AWS.

Get in touch at sudoconsultants.com or reach@sudoconsultants.com

► Review Your DevOps Maturity and Pipeline Architecture with SUDO

Explore SUDO’s DevOps and Automation services built on AWS.

► View Our DevOps and Automation Services

Frequently asked questions

What does a failed deployment actually cost?

Beyond time to recovery, a failed deployment hits four business dimensions: wasted senior-engineer time, lost customer trust and revenue during outages, missed launch windows, and eroded leadership confidence in the delivery team.

What are the DORA metrics?

The four DevOps Research and Assessment metrics: deployment frequency, lead time for changes, change failure rate, and mean time to recovery. Together, they measure the health of a delivery process better than any internal dashboard.

What does a production-grade AWS CI/CD pipeline look like?

Six stages, each with an automated gate: source (CodePipeline), build and unit tests (CodeBuild), automated testing and security scans, staging with an approval gate, production with CodeDeploy and automatic rollback, and observability with CloudWatch and X-Ray.

Which AWS deployment strategy should I use?

Blue/Green for mission-critical workloads, Canary for high-traffic apps needing real-world validation, Rolling for lower-criticality workloads, and Feature Flags with AWS AppConfig to separate deployment from release. AWS CodeDeploy supports all four natively.

What are AWS DevOps Agent and Kiro?

AWS DevOps Agent (generally available from March 2026) autonomously investigates incidents and generates a root-cause analysis and mitigation plan in minutes. Kiro (generally available from May 2026), AWS’s spec-driven agentic IDE and successor to Amazon Q Developer, implements the fix and opens the pull request.

Cost-Efficient and Sovereign: Aligning AWS Cloud Spend with Vision 2030 and GCC Data Rules

maryam mairaj — Thu, 20 Aug 2026 12:27:01 +0000

Most cloud cost conversations I have with customers in the Gulf start the same way. Finance wants the AWS bill down by a fixed percentage before the next board review. The compliance team, separately, wants a written answer to a simple question: where does our personal data physically sit, and who can reach it?

Those two requests land on the same cloud team, usually in the same month, and they get treated as two unrelated projects. Cost optimisation goes to one engineer with a spreadsheet. Data residency goes to a compliance workshop with a consultant. Six months later, the organisation has spent money on both and solved neither properly, because every decision one team makes quietly changes the other team's numbers.

Region choice is a compliance decision and a pricing decision at the same time. A tagging schema is a chargeback tool and an audit artefact at the same time. A disaster recovery topology sets both your recovery time and your cross-border data exposure. In a regulated GCC enterprise, cost governance and data sovereignty are not two programmes. They are one programme viewed from two seats.

This post is about running them as one. It is written for the people who actually carry both numbers: cloud leads, heads of infrastructure, and the CFO or CTO who has to sign off on the bill and the audit response.

At SUDO Consultants, an AWS Premier Tier Services Partner working with regulated enterprises across the UAE, Saudi Arabia, and the wider GCC, we help teams run cost governance and data sovereignty as one programme, and the guidance below comes from that hands-on work.

Why sovereignty shows up on your AWS bill

Sovereignty is rarely a line item. It hides inside five other line items, and if you do not know where to look, it reads as general cloud waste.

1. Region choice, and the Saudi Region that has not landed yet

This is the one that surprises people, so it is worth stating plainly. As of this writing, AWS has announced an infrastructure Region in the Kingdom of Saudi Arabia but has not launched it. The AWS global infrastructure page still lists the Kingdom among announced Regions, not available ones. The Middle East Regions you can actually deploy into today are Bahrain and the UAE.

That single fact drives a lot of architecture in KSA right now. An organisation with a hard in-country requirement cannot simply pick a Riyadh Region from a dropdown. The realistic options are the UAE Region, where cross-border transfer can be justified under the transfer rules, an in-country footprint using AWS Outposts or Dedicated Local Zones, or a hybrid split between the two. Each of those carries a different cost profile, and the gap between them is much wider than the gap between two ordinary Regions.

It also means commitment purchases need care. More on that later, because it is the single most expensive mistake I see right now.

2. Regional price deltas

Middle East Regions generally price above the large North American and European Regions for the same instance family and the same storage class. The delta varies by service and changes over time, so the honest advice is to price your actual bill of materials in the AWS Pricing Calculator for each candidate Region rather than trusting a rule of thumb. What matters is that the delta is real and it compounds monthly. When a workload is moved in-Region purely out of caution, and the data it handles was never in scope for residency rules, that premium is bought for nothing.

3. Cross-border and cross-Region data transfer

Replication, backup copies, centralised logging, and observability pipelines all move bytes. Teams that build a compliant primary Region and then ship every CloudWatch log and every VPC Flow Log to a central account in Ireland have created two problems at once. They are paying inter-Region transfer every hour, and they have quietly moved data that may be in scope for residency rules out of the jurisdiction. The audit finding and the bill arrive from the same architecture diagram.

4. Service and capacity parity

Smaller Regions carry fewer services and fewer instance families than the larger ones. Practically, that means less optimisation headroom. The newest Graviton generation may not be available yet. Spot capacity pools are shallower, so Spot is less dependable for production batch. Some managed services that would have removed operational cost are simply absent, and the team ends up self-managing the equivalent on EC2, which is a staffing cost rather than an infrastructure cost, and therefore never appears in Cost Explorer.

Check parity before you commit to an architecture, not after. The AWS regional services list is the authoritative source, and it moves.

5. Key management and encryption posture

Regulated workloads usually attract customer-managed KMS keys rather than AWS-managed ones, and sometimes CloudHSM or an external key store. Each customer-managed key carries a monthly charge plus request charges, which is trivial for ten keys and material for a thousand. I have seen environments where an automated per-resource key policy quietly produced several thousand keys. That is a governance decision with a recurring bill attached.

What the rules actually require

You cannot right-size a compliance premium without knowing what the regulator asked for. A short, practical summary of the two regimes SUDO works with most.

Kingdom of Saudi Arabia

The Personal Data Protection Law is administered by the Saudi Data and Artificial Intelligence Authority. It has extraterritorial reach, so it binds a company processing the data of Saudi residents regardless of where that company is incorporated. SDAIA issued dedicated regulations on transferring personal data outside the Kingdom, together with standard contractual clauses, which means cross-border transfer is a documented and conditional act rather than a blanket prohibition or a free pass. Breach notification runs to a 72-hour expectation.

This has moved from paper to practice. SDAIA has issued dozens of formal enforcement decisions, covering failures ranging from unlawful collection through to inadequate security safeguards. The compliance posture that was acceptable in 2023 is not acceptable now.

Alongside PDPL, the National Cybersecurity Authority sets the technical control expectations through its Essential Cybersecurity Controls and cloud-specific controls, including data classification and access governance. Financial institutions carry SAMA obligations on top. In practice, the three frameworks overlap heavily, and the evidence you generate for one is usually reusable for the others, which is a cost saving in itself if you plan for it.

United Arab Emirates

Federal Decree-Law No. 45 of 2021 is the onshore federal law, supervised by the UAE Data Office, and it also reaches organisations outside the country that process UAE residents' data. The executive regulations that were meant to pin down transfer procedures and notification timelines have been slow to arrive as a discrete published instrument, and AWS's own UAE data privacy page still reflects that. The working assumption across the market has been to apply the substantive obligations now and align to a 72-hour breach norm rather than wait.

The detail that catches architects out is the free zones. DIFC operates under its own data protection law and ADGM under its own regulations. Neither treats onshore UAE as an adequate jurisdiction. A data flow from a DIFC entity to a mainland entity is a cross-border transfer requiring safeguards, even though both sit inside the same city and often inside the same AWS Region. Sector rules layer on further, with the central bank imposing localisation expectations on banking data and health authorities on patient records.

The practical conclusion from both regimes is the same, and it is the hinge of this whole article. The rules attach to categories of data, not to the entire estate. Nothing in either law says every workload must live in-Region. Teams that behave as if it does are paying a sovereignty premium on test environments and anonymised analytics.

Classify first, then choose a Region

The single highest-return control in this whole exercise is a data classification that engineers can actually apply. Not a 40-page policy. Four tiers, each with a default landing zone and a default cost posture.

Two things make this work in practice. First, the classification has to be a tag that CI/CD applies at deployment time, not a spreadsheet a governance analyst maintains after the fact. Second, tier two needs a real tokenisation boundary. If your analytics platform can join a token back to a name using another table in the same account, the data never actually left tier one, and you have bought risk instead of savings.

Architecture patterns that satisfy both mandates

Region guardrails in the landing zone

Residency should be enforced by the platform, not by a wiki page. In AWS Organizations, service control policies keyed on the aws:RequestedRegion condition will deny resource creation outside an approved Region set, per organisational unit. Resource control policies handle the other direction, constraining who outside the organisation can reach resources at all. AWS Control Tower ships data residency controls that wrap the same idea in a managed form.

The finance benefit is immediate and often overlooked. Once Regions are constrained by policy, a surprising amount of shadow spend disappears, because the accidental us-east-1 deployment that nobody claimed ownership of can no longer happen.

In-country compute where no Region exists yet

For KSA workloads with a hard in-country requirement today, Outposts and Dedicated Local Zones are the AWS-native answers. They work, and I would rather see them than an unmanaged colocation rack. But the economics are different from a Region, and that difference needs to be on the table before the contract is signed.

• Capacity is committed and billed whether or not you use it, so the elasticity argument that justifies public cloud pricing does not apply in the same way.
• Right-sizing has to happen before deployment, not iteratively afterwards. Getting the initial sizing wrong is expensive in both directions.
• Service coverage is narrower than a full Region, so the target workload set should be validated against what is actually supported.

Where the requirement is regulatory preference rather than statutory obligation, the UAE Region with documented transfer safeguards under the SDAIA rules is often the more sensible commercial position. That is a conversation for legal and finance together, and it should be a documented decision with a date on it, because the position changes when the Saudi Region launches.

Disaster recovery sized to a real RTO

Multi-Region hot standby is the most expensive DR posture available, and it is bought far more often than it is needed, usually because nobody wrote down the recovery time objective before the architecture review. For most regulated workloads outside core banking, a pilot light or warm standby in the second GCC Region delivers a recovery time the business is happy with at a fraction of the run cost.

Write the RTO and RPO down first, per workload tier. Then buy the cheapest topology that meets it. Doing it in that order routinely takes a meaningful share off the resilience portion of the bill, and it produces exactly the documented rationale an auditor asks for.

Data transfer hygiene

Egress and inter-AZ traffic are where compliant architectures leak money quietly. The fixes are unglamorous, and they work.

• Use VPC gateway endpoints for S3 and DynamoDB so that traffic does not traverse a NAT gateway. NAT processing charges on high-volume data pipelines are a recurring surprise in cost reviews.
• Use interface endpoints for the AWS services your private subnets call most, and check that the endpoint cost is actually lower than the NAT charge it replaces at your volume.
• Keep chatty application tiers AZ-aware. Cross-AZ traffic between a service and its database is invisible in an architecture diagram and very visible in a bill.
• Aggregate logs in-Region first, then ship a filtered and, where appropriate, redacted subset onward. This cuts transfer cost and shrinks the residency question at the same time.

One tagging schema for finance and for audit

This is the part I push hardest with customers, because it costs almost nothing and it pays twice.

Most organisations build a tagging schema for cost allocation, then build a separate set of resource attributes for compliance evidence. There is no reason for these to be different. Define one mandatory tag set, enforce it in infrastructure as code and in service control policies, and let both functions read from it.

Once the tags exist, the tooling is straightforward and mostly free.

• Cost Categories to group accounts and tags into jurisdictions and business units for reporting that finance recognises.
• CUR 2.0 delivered to S3 with Athena for per-entity showback. This is the only first-party source that ties resource identifiers, tags, and commitment attribution on the same row, which is what real chargeback needs. Cost Explorer is for looking; CUR is for answering.
• AWS Budgets and Cost Anomaly Detection per entity, not just at the organisation root, so a spike in one regulated subsidiary is visible to the people responsible for it.
• Cost Optimization Hub to consolidate the recommendations that otherwise arrive separately from Compute Optimizer, Trusted Advisor, and Cost Explorer. It gives one prioritised list across the organisation instead of three review processes.
• AWS Config rules reading the same tags to catch residency drift and untagged resources. The compliance control and the cost control become the same check.

Commitments, and the mistake that is being made right now

This deserves its own section because the timing matters and the window is open today.

Reserved Instances and EC2 Instance Savings Plans are scoped to a Region. Compute Savings Plans are not, and apply across Regions, instance families, and compute services. In a normal year, that distinction is a modest optimisation detail. With a Saudi Region announced and not yet launched, it is a strategic one.

If a KSA customer buys three-year, Region-locked commitments against workloads running in the UAE Region today, and those workloads move in-country when the Saudi Region opens, that commitment does not follow them. The organisation ends up paying for coverage it cannot use while paying on-demand rates for the workloads it actually runs. I have already seen this planned in good faith by teams who simply had not connected the launch timeline to the commitment term.

The practical guidance for GCC customers with a likely in-country migration ahead:

Prefer Compute Savings Plans over EC2 Instance Savings Plans and Reserved Instances for any workload that is a migration candidate.
Ladder commitments in tranches with staggered end dates rather than buying one large block on one date.
Consider one-year terms over three-year terms for the migration-candidate portion of the estate, accepting the lower discount rate as the price of optionality.
Keep the genuinely static, non-migrating baseline on longer terms where the discount is worth having. Optionality has a cost. So does a stranded commitment. Right now, in this specific market, the second one is larger for most Saudi customers.

What Vision 2030 actually asks of a cloud budget

It is easy to use Vision 2030 as decoration on a slide. The substance that touches a cloud team is narrower and more useful than the slogan.

The efficiency agenda is about doing more with the same public and private spend, which is precisely the FinOps argument made at national scale. A cloud programme that cannot show unit economics, cost per transaction, cost per customer, cost per service, is not aligned with that agenda regardless of what the slide says. The digital government agenda pushes services online at volume, which rewards architectures that scale elastically rather than by procurement cycle. And the localisation agenda favours in-country capability and local skills, which is a genuine argument for building operational capability in the region rather than treating cloud operations as something that happens on another continent.

Put together, the alignment is not a marketing position. Classify data, place it deliberately, measure unit cost, build local capability. Those four things satisfy the regulator, the CFO, and the national agenda with the same work.

A 90-day plan

If you are starting from a typical position, meaning tags are inconsistent, residency is assumed rather than enforced, and cost review is a monthly spreadsheet, this sequence works.

Mistakes I see repeatedly

• Localising the entire estate. Test environments and anonymised analytics pay a premium they were never required to pay. Classification is what stops this.
• Buying resilience without an RTO. Hot standby gets purchased because it sounds responsible, not because a business requirement asked for it.
• Two schemas for one truth. A finance tagging standard and a separate compliance attribute set means double the maintenance and two versions of reality.
• Region-locked long-term commitments during a pending Region launch. Covered above. This is the expensive one this year.
• Treating DIFC, ADGM, and mainland UAE as one jurisdiction. They are not, and the transfer safeguards between them are a real architectural requirement.
• Centralising logs out of Region by default. It is the standard reference pattern in most documentation, and in a GCC-regulated context it is often the wrong one.

Key takeaways

• Cost governance and data sovereignty are the same programme. Region choice, tagging, and DR topology each set both numbers at once.
• AWS has announced but not yet launched a Saudi Region. Architect and buy commitments with that timeline in mind.
• The rules attach to categories of data, not to the whole estate. Classification is the control that stops you from overpaying for compliance you do not owe.
• Enforce residency with service control policies and Control Tower controls, not with documentation.
• One tag set should serve chargeback and audit evidence. Build it once.
• Prefer Compute Savings Plans and shorter terms for workloads likely to move in-country.
Frequently asked questions

Is the AWS Saudi Arabia Region available yet?

No. AWS announced an infrastructure Region in the Kingdom with a multi-billion dollar investment commitment, and it appears on the AWS global infrastructure page among announced Regions rather than launched ones. Several third-party articles state a launch date that AWS has not confirmed, so verify against the AWS global infrastructure page before making an architecture or procurement decision. Available Middle East Regions today are Bahrain and the UAE.

Does Saudi PDPL require all personal data to stay inside the Kingdom?

Not as a blanket rule. SDAIA issued specific regulations governing the transfer of personal data outside the Kingdom, including standard contractual clauses and safeguard requirements, which makes cross-border transfer a conditional and documented act rather than a prohibition. Certain categories and certain sectors carry tighter localisation expectations, so the answer depends on your data classification and your regulator. Get a documented legal position per data tier rather than applying one rule to everything.

How much does data residency add to an AWS bill?

There is no single figure, and anyone quoting one without seeing your workload is guessing. The drivers are regional price deltas, inter-Region transfer, duplicated environments per jurisdiction, reduced access to Spot and newer instance families, and key management volume. The useful exercise is to price your actual bill of materials per candidate Region and then separate the portion of the estate that genuinely requires in-Region placement from the portion that does not.

Can one tagging schema really serve both FinOps and compliance?

Yes, and it should. A tag set covering data classification, jurisdiction, legal entity, environment, and owner supports cost allocation and chargeback for finance while providing the classification and residency evidence a regulator asks for. Enforce it in infrastructure as code, validate it with AWS Config, and read it through Cost Categories and CUR 2.0.

Should we use AWS Outposts for in-country data residency in Saudi Arabia?

It is a valid option where the requirement is a genuine statutory obligation to keep specific data in-country and the Region is not yet available. Go in knowing the economics differ from a Region, because capacity is committed and billed regardless of utilisation, and service coverage is narrower. Where the requirement is preference rather than obligation, the UAE Region with documented transfer safeguards is frequently the better commercial answer until the Saudi Region launches.

Working through this with SUDO

SUDO Consultants is an AWS Premier Tier Services Partner working with regulated enterprises across the UAE and Saudi Arabia. We build landing zones with residency enforced at the platform level, run FinOps engagements that produce both a lower run rate and the documentation your auditor asks for, and advise on Region and commitment strategy against the Saudi Region timeline.

If you are carrying both a cost target and a residency requirement this year, we can help you run them as one programme instead of two. Get in touch to arrange an assessment. Get in touch at sudoconsultants.com or reach@sudoconsultants.com.

From Monolith to Microservices: A Legacy App Modernization Roadmap on AWS

maryam mairaj — Tue, 18 Aug 2026 09:08:18 +0000

Every enterprise with a legacy monolith knows the symptoms. A single bug takes down the entire application, not just the broken feature. Releases happen once a quarter because nobody wants to risk touching the whole system. Scaling means scaling everything on one Amazon EC2 fleet, even the one component that actually needs more capacity.

The instinct is to rewrite. The better move is to modernize in place, incrementally, using AWS's container, serverless, and data migration services to peel functionality away from the monolith without ever taking the system offline. This is what "monolith to microservices" actually means on AWS, and it looks nothing like the diagrams in most vendor whitepapers.

At SUDO Consultants, an AWS Premier Tier Partner working with teams across the UAE, Saudi Arabia, and the wider MENA region, we help organizations modernize legacy monoliths into microservices on a solid AWS cost-optimization and architecture foundation. The roadmap below comes from that hands-on work.

The Problem With Monoliths Isn't the Code. It's the Coupling.

A monolith isn't a technical failure. It was often the right choice years ago, when the team was small and the product was simple, running as a single deployable unit on a fixed set of servers. The problem shows up later, when the business grows faster than the architecture can support.
Three symptoms tend to show up together:

• Deployment risk: every release touches the entire codebase, so every release carries the risk of the entire codebase.
• Scaling inefficiency: if the checkout module needs more compute during a sale, the entire monolith scales with it on the same Auto Scaling group, driving up cost for capacity most of the system doesn't need.
• Team bottlenecks: multiple engineering teams working in one codebase and one deployment pipeline creates merge conflicts, release queues, and slower delivery cycles as headcount grows.

None of these are solved by rewriting the application from scratch. They are solved by decomposing it correctly, using the right AWS services in the right order.

Why the Big-Bang Rewrite Is the Most Common Mistake

The most tempting path is also the riskiest: freeze the legacy system, spend twelve months building a clean microservices architecture from zero, then cut over in one release.

This rarely works. Business requirements do not pause for a year while engineering rebuilds. The legacy system keeps evolving with bug fixes and urgent features, widening the gap between what the new system was designed for and what the business now needs.

The proven alternative is the strangler fig pattern, implemented on AWS using an Application Load Balancer (ALB) or Amazon API Gateway as the routing layer in front of both systems. The new microservices architecture is built around the edges of the monolith; traffic is routed incrementally to the new services, and the legacy system shrinks over time until there is nothing left to retire. The monolith keeps running on its existing infrastructure the entire time. The business never stops.

The Modernization Roadmap

The services below aren't listed up front. Each one shows up exactly where it earns its place in the sequence, since that sequencing, not the tool selection, is what makes or breaks a modernization program.

Phase 0: Runtime Readiness

Decomposition assumes the monolith can still be built and deployed. Often it can’t. A Java 8 application on Spring Boot 2.x with an AWS SDK v1 dependency tree cannot have a service cleanly extracted from it, because the extracted service inherits a runtime that is already out of support. This phase is unglamorous, and it is where modernization programs quietly stall.

AWS Transform custom handles this class of work as managed transformations: language version upgrades, Spring Boot 2.x to 3.x, SDK v1 to v2, and Log4j to SLF4J, applied across repositories rather than one at a time. The agent accumulates knowledge items from each execution, so the second hundred repositories cost less effort than the first ten. Run this to completion before any bounded context is extracted, not in parallel with it.

Phase 1: Domain Decomposition

Before provisioning any AWS resource, map the monolith into bounded contexts, the natural seams where one business capability ends and another begins (orders, payments, inventory, customer profile). This is a modeling exercise, not an infrastructure exercise, and it is the single most under-invested step in most modernization programs.

Getting this wrong means standing up ECS services or Lambda functions that mirror the monolith’s internal code structure instead of the business’s actual domains, which recreates the same coupling problems in a new, more expensive form.

Phase 2: Strangler Fig Routing

Once a bounded context is identified, extract it as an independent service running on Amazon ECS, Amazon EKS, or AWS Fargate, and place an Application Load Balancer (or Amazon CloudFront in front of the ALB for web-facing traffic) ahead of both the legacy monolith and the new service. Amazon API Gateway can front the new service directly if it’s exposed as a discrete API.

Getting the extracted service into a deployable container is work in its own right. AWS Transform can containerize source code directly from GitHub, Bitbucket, or GitLab, generating Dockerfiles and images with CVE scanning, then emitting deployment-ready Terraform and Helm charts for the ECS or EKS target. It handles monorepos, which is the usual shape of a monolith repository, and private dependency resolution through CodeArtifact.

Traffic is routed incrementally using ALB path-based or weighted target group routing: a percentage of requests, or specific endpoints, go to the new service while everything else continues through the monolith unchanged.

This is what makes the migration reversible. If something breaks, shifting the ALB weighting back to the legacy target group restores the original path immediately, with no user-facing disruption.

Phase 3: Data Decoupling

This is the phase most teams get wrong, and it deserves its own warning.
Splitting the application into ECS or Lambda-based services while leaving one shared Amazon RDS or on-premises database behind them does not create microservices. It creates a distributed monolith, the operational complexity of microservices, with all of the coupling problems of a monolith still intact.

The fix is a database-per-service model, implemented using AWS DMS to replicate data with minimal downtime as new services get their own data stores:

Use AWS Schema Conversion Tool (SCT) to assess schema compatibility if migrating between engines (for example, a legacy SQL Server schema moving to Aurora PostgreSQL-compatible).
Stand up the target data store: Amazon Aurora for services needing relational consistency, Amazon DynamoDB for services needing high-scale key-value or document access.
Configure a DMS replication task for ongoing change data capture (CDC), keeping the new data store in sync with the legacy database during the transition.
Cut the new service over to reading and writing its own data store once replication lag and validation checks confirm consistency.
Decommission the shared table’s usage by that service, repeating for the next bounded context.

Phase 4: Asynchronous Communication

Early in decomposition, new services often call each other directly and synchronously through API Gateway, which just relocates the monolith’s tight coupling into network calls. As the architecture matures, direct calls are replaced with asynchronous, event-driven communication using Amazon SQS for point-to-point decoupling, Amazon SNS for fan-out notification patterns, or Amazon EventBridge for a broader event bus across services and, where relevant, third-party SaaS integrations.

This is also where service discovery and traffic management are formalized using Amazon VPC Lattice or AWS App Mesh, giving the architecture consistent, observable service-to-service traffic instead of ad hoc API calls scattered across teams.

Phase 5: Observability and Delivery Maturity

A system with fifteen services is only manageable if it is observable. AWS X-Ray provides distributed tracing across service boundaries, so a slow checkout flow can be traced to the specific service causing the delay instead of triggering a search across the entire system. Amazon CloudWatch unifies logs, metrics, and alarms across the legacy monolith and the new services during the period when both are running side by side.

On the delivery side, each new service should be independently deployable through its own AWS CodePipeline, using AWS CodeBuild for build and test stages. This is what actually delivers the outcome the whole roadmap is working toward: teams shipping independently, without waiting on a shared release train tied to the monolith’s deployment schedule.

MENA-Specific Considerations

For banks, insurers, and government-adjacent organizations across the UAE and Saudi Arabia, modernization has to happen without breaking data residency or compliance posture along the way.

During the transition period, legacy and new services often run in parallel, sometimes for a year or more. Both the legacy environment and the new ECS, EKS, or Lambda-based services need to remain within the approved compliant region for the duration of the migration, not just at the finish line. AWS Config rules can be used to continuously flag any resource, including DMS replication instances, that gets provisioned outside the approved region.

Teams working under SAMA or NESA frameworks should treat the strangler fig transition period as a compliance checkpoint in its own right: the hybrid state, with DMS replicating data between legacy and new systems, is where sovereignty gaps are most likely to appear.

Cost Considerations

A few cost patterns are worth planning for before the migration starts:

• Running two environments in parallel is temporary, not permanent. Budget for the overlap period explicitly rather than treating it as a surprise line item; this is typically the highest-cost phase of the entire program.
• Fargate reduces operational cost for smaller services where the overhead of managing EC2 instances for a handful of containers isn’t justified, but at higher, steady-state scale, ECS or EKS on EC2 with Savings Plans is often more cost-efficient.
• DMS replication instances should be sized for the migration window, not left running indefinitely. Decommission them once cutover is validated and stable.
• AWS Compute Optimizer is worth running against the new services once they stabilize, since initial sizing during migration is often conservative and leaves rightsizing opportunity on the table.

What We’ve Seen in the Field

In one modernization program for a regional financial services client, the team’s first instinct was to decompose the order management and payments modules simultaneously on Amazon ECS, since both were high priority. The bigger constraint turned out to be the database: both modules shared several core tables in the same Amazon RDS instance, and splitting the services without first resolving the data layer through DMS would have created exactly the distributed monolith problem described above.

Resequencing the work to decouple the data layer first, then extract the services, added a few weeks up front but avoided months of rework later. The lesson holds broadly: the roadmap’s value is in the sequence, not just the AWS services chosen.

Practical Next Steps

For teams evaluating where to start:

• Run AWS Transform custom against the legacy codebase first to clear runtime and dependency debt, before extracting a single service. Skipping this step is the most common reason modernization programs stall before Phase 1 even begins.
• Map bounded contexts before provisioning any AWS resource. This is a business modeling exercise that should occur before any service is extracted.
• Start with the highest-change, lowest-risk module first, using Fargate or Lambda to keep the initial footprint small while the pattern is validated.
• Resolve the data layer with AWS DMS before splitting services, not after. This is the single most common sequencing mistake.
• Instrument AWS X-Ray and CloudWatch from day one of the transition, not after the first outage makes it necessary.
• Use AWS Config to enforce residency and compliance controls on the hybrid state itself, since the transition period, not just the end state, is where compliance gaps typically appear.

Where This Goes Next

Monolith-to-microservices modernization is not a project with a finish line so much as a capability an engineering organization builds on AWS. The enterprises that get the most value from it are the ones that treat the roadmap and the underlying service choices as a repeatable pattern, applying it to the next legacy system once the first one is done, rather than a one-time initiative.

What does your team’s biggest bottleneck look like today: deployment risk, scaling cost, or team velocity? The answer usually points to which AWS service should come first.

How SUDO Consultants can help

As an AWS Premier Tier Partner, SUDO Consultants helps organizations put the modernization foundation in place, runtime and dependency remediation, bounded-context modeling, strangler fig routing, and data decoupling with AWS DMS that makes a monolith-to-microservices program succeed, and integrates it into your existing engineering and delivery workflows. If your team wants to modernize on a solid footing, we can help you get there.

Through our AWS Cloud Migration & Modernization and DevOps as a Service engagements, we plan and run the full monolith-to-microservices roadmap for you and embed modern, independently deployable services into your day-to-day cloud operations across the UAE, Saudi Arabia, and the wider MENA region.

Get in touch at sudoconsultants.com or reach@sudoconsultants.com.

Frequently asked questions

What does “monolith to microservices” mean on AWS?
It means decomposing a single deployable application into independently deployable services, incrementally, using AWS container, serverless, and data-migration services, so functionality is peeled away from the monolith without taking the system offline.

What is the strangler fig pattern?
A migration approach where new microservices are built around the edges of the monolith and traffic is routed to them incrementally through an Application Load Balancer or Amazon API Gateway, until the legacy system shrinks to nothing. It keeps the migration reversible and the business online throughout.

How do you avoid creating a distributed monolith?
Give each service its own data store (database-per-service) instead of sharing one database. AWS DMS replicates data with minimal downtime while each service cuts over to its own store, so you get real service isolation rather than microservices bolted onto a shared database.

In what order should you modernize a monolith on AWS?
Clear runtime and dependency debt first, map bounded contexts, apply strangler fig routing, decouple the data layer, move to asynchronous communication, then add observability and independent delivery. The sequence, not the tool choice, is what makes or breaks the program.

Does this work for regulated organizations in the UAE and Saudi Arabia?
Yes, provided legacy and new services stay within the approved compliant region for the entire transition, not just at the end. AWS Config can flag any resource provisioned outside the approved region, and teams under SAMA or NESA frameworks should treat the hybrid state as a compliance checkpoint.

Keywords: monolith to microservices on AWS, legacy application modernization AWS, strangler fig pattern, database-per-service, AWS DMS migration, microservices decomposition MENA

AWS FinOps Agent: Bringing Agentic AI to Cloud Cost Management

maryam mairaj — Mon, 03 Aug 2026 07:17:00 +0000

On June 9, 2026, AWS put the FinOps Agent into public preview: an AI agent that answers cost questions in plain language, investigates spending anomalies down to their root cause, and surfaces optimization opportunities, all inside the tools your teams already use. For teams who have spent years manually chasing cost anomalies across many accounts, it is a genuinely useful arrival. But it is not a set-and-forget cost autopilot, and knowing exactly what it does, and what it does not, is what separates a smart rollout from a disappointed one.

This article walks through the FinOps Agent end to end: what it is, how we set one up in a real AWS account, and what it returns when you actually use it. Every screenshot below is from that live setup.

At SUDO, an AWS Premier Tier Partner working with teams across the UAE, Saudi Arabia, and the wider MENA region, we help organizations adopt agentic AI cost management like this on a solid AWS cost-optimization foundation. The walkthrough below comes from one such hands-on engagement.

What the FinOps Agent actually is?

The FinOps Agent is a frontier agent built on Amazon Bedrock that turns cloud cost management into a conversational experience. Instead of navigating multiple dashboards and reports, you ask questions in plain language and get answers drawn from your real cost and usage data.

It does four things: answers cost questions in natural language, automatically investigates cost anomalies to root cause, surfaces optimization opportunities (rightsizing, idle resources, Savings Plans), and runs recurring FinOps workflows on a schedule you define. It delivers findings in a web application, and optionally into Slack and Jira.

To do this, it draws on the cost stack AWS already has: Cost Explorer for cost and usage data, Cost Anomaly Detection for alerts, Cost Optimization Hub and Compute Optimizer for rightsizing recommendations, and AWS CloudTrail to trace the root cause of cost changes by correlating a spike with the record of who changed what and when.

Before you start: the foundation the agent depends on

The agent is only as good as the cost data underneath it. If these are not in place, it has nothing to work with, so set them up first. We cover the reasoning behind tagging and budgets in depth in our FinOps fundamentals guide; here is the checklist:

• Enable Cost Explorer: This is the agent's primary source of cost and usage data. Data can take up to 24 hours to populate, so do this a day ahead.

• Enable Cost Anomaly Detection: This is what the agent's automatic investigations listen for. No monitor, no anomaly investigations.

• Enable Cost Optimization Hub (and confirm Compute Optimizer): These power the rightsizing, idle-resource, and Savings Plans recommendations. Easy to miss, and the agent will look thin without them.

• Confirm CloudTrail is logging management events: In the regions you use, or the root-cause correlation has no data to work with.

• Tag resources with owner or team tags: The agent names the responsible owner far more reliably when tags exist.

In our walkthrough account, an active Cost Anomaly Detection monitor was already in place, the foundation that lets the agent investigate later.

Creating the agent: a five-step setup

The agent is created in the AWS console. As of the preview, it runs only in the US East (N. Virginia), us-east-1 Region, though once created in a management account it can monitor costs across all Regions and accounts, including workloads in the Middle East, Europe, and Asia Pacific. It simply runs from us-east-1 while managing spend everywhere.

From the console, search for FinOps Agent, open it, and click Create Agent. The setup has five steps.

Step 1 and 2: Name the agent, grant AWS resource access
First, you name the agent (we used demo-FinOpsAgent) and optionally add a description. Then you grant the IAM permissions the agent needs to read your cost data. The setup creates the role for you, auto-create is the recommended default, so you do not configure IAM manually unless your organization manages permissions centrally.

Step 3: Grant web app access

This is a distinct step worth noting: the agent gets a second, separate IAM role that controls what its web application can do, creating tasks, viewing execution history, and managing context files. Web app authentication is handled through the AWS Console. This is the role that powers the chat interface you will use to interact with the agent.

Step 4: Third-party integrations (optional)

The setup offers optional Jira and Slack integrations. Jira lets the agent create tickets; Slack lets it post findings to a channel. You can connect them now or later from agent settings. For this walkthrough, we skipped both to validate the core agent first; connecting them is a natural next step once the agent is proven.

One practical gotcha when you do connect Slack: the FinOps Agent app must be added to the channel before you configure the integration, or it will fail with an unhelpful error. AWS marks this as important, but it is easy to skip.

Step 5: Review and create

The final screen summarizes everything: the agent name, both auto-created IAM roles, and the integrations (none, since we skipped them). Confirm and click Create Agent.

The agent provisions in a few moments and appears in the Agents list with an Open link. Note the useful detail here: each agent operates with its own IAM permissions, context files, memory, task queue, and integrations, with no data or permissions shared across agents- a clean isolation boundary that matters for regulated environments.

Using the agent: a conversational interface over real cost data
Clicking Open launches the agent's web application, a separate, chat-style interface distinct from the AWS console. This is where you actually work with the agent: ask questions, run tasks, manage automations, upload context files, and view artifacts.

The interface is a chatbot in form, but the value is what sits behind the chat. A normal chatbot would guess or answer generically. This one pulls actual figures from Cost Explorer, breaks them down by service, computes month-over-month change, and, for anomalies, correlates them with CloudTrail to identify who caused the spike. Conversational interface, real cost intelligence underneath.

The interface also suggests common tasks that show its range in AWS's own words: find EC2 rightsizing opportunities and generate an HTML report, investigate anomalies in the last 7 days correlated with CloudTrail to identify the API calls and IAM principals behind them, automate anomaly alerts over a dollar threshold to a Slack channel, compare monthly costs, produce an executive-ready PPT report, or detect idle RDS instances. Prompts are capped at 1000 characters.

Asking a real question
To test it, we asked a plain-language question: "What was my cost in May 2026, and how did it change compared to the prior month?" Within seconds, the agent returned a structured answer, a per-service breakdown table comparing April and May, the month-over-month change, and a short analysis naming the two services that drove the difference. It correctly excluded zero-cost services and labeled the metric it used (UnblendedCost). A Show thinking process link exposes the reasoning steps it took to get there.

Follow-up questions work the same way, conversationally. Ask "How many active services are in my account?" and it inventories them; ask for a multi-month trend, and it breaks the spend down by service with a brief analysis and offers to drill deeper. You steer it like a chat, and it answers from your real account each time.

For example, asking for a six-month service breakdown returns a per-service table across the period, with a chart and a totals row, again, from a single plain-language question, with no dashboard to build.

What it deliberately does not do
This is where an honest read matters, because the launch coverage tends to skip it.

It is read-only: The agent investigates, reports, and (when connected) files tickets or posts messages, but it does not stop, resize, delete, or remediate anything. A human still decides and acts. That is the right design choice: autonomous action on production cost requires trust the industry is still building, but it means the agent is an analyst, not a brake.

It is reactive: It triggers on anomaly alerts or scheduled reviews, working from billing data after a cost change has already happened. It does not watch resource-creation events at the moment an expensive resource launches. By the time it investigates, the money is already being spent.

The practical takeaway

Treat the FinOps Agent as a very sharp investigator, not a guardrail that stops the bill before it lands. It complements preventative controls, budgets, tagging discipline, guardrails, and SCPs, but does not replace them. Most teams need both: preventative controls to stop surprises, and the agent to explain the ones that get through.

Availability and cost

The FinOps Agent is currently available only in us-east-1, but once deployed in a management account, it monitors costs across all Regions and member accounts. During the public preview, it is free, subject to a monthly usage limit; standard charges still apply for the underlying services it reads, such as Cost Explorer API calls. Pricing at general availability has not been announced, so confirm current terms before building it into a long-term cost-governance plan.

The honest verdict

The FinOps Agent is a real, capable tool that automates the single most tedious part of cloud cost management: root-cause investigation and plain-language cost analysis. It is not a replacement for preventative cost controls; it is not autonomous, and it is only as good as the cost foundation you have already built. Get that foundation right, and it is a strong addition to how modern teams keep cloud spend under control, turning cost from a monthly report the FinOps team chases into a real-time answer any engineer can get for themselves.

How SUDO can help

As an AWS Premier Tier Partner, SUDO helps organizations put the cost-governance foundation in place: cost anomaly detection, budget structures, tagging strategy, CloudTrail configuration- that makes tools like the FinOps Agent genuinely useful, and integrates them into your existing FinOps and engineering workflows. If your team wants to adopt agentic cost management on a solid footing, we can help you get there.

Through our AWS Managed Cloud Services and DevOps as a Service engagements, we build and run that cost-governance foundation for you and integrate agentic FinOps into your day-to-day cloud operations across the UAE, Saudi Arabia, and the wider MENA region.

Get in touch at sudoconsultants.com or reach@sudoconsultants.com.

Frequently asked questions

What is the AWS FinOps Agent?

The AWS FinOps Agent is a frontier AI agent built on Amazon Bedrock that answers cloud cost questions in plain language, investigates spending anomalies to their root cause using CloudTrail, and surfaces optimization opportunities delivered in a web app and, optionally, Slack and Jira.

Is the AWS FinOps Agent available in the Middle East?

During preview, the agent runs only in us-east-1, but once created in a management account, it monitors costs across all Regions and accounts, including workloads in the UAE, Saudi Arabia, and the wider MENA region. It simply runs from us-east-1 while managing spend everywhere.

Does the FinOps Agent replace preventative cost controls?

No. It is read-only and reactive; it explains a spike after it lands but does not stop, resize, or remediate anything. Most teams pair it with preventative controls such as budgets, tagging, and SCPs. SUDO Consultants helps put both in place.

Beyond Security Groups: Building a Layered AWS Network Defense for Regulated Enterprises

maryam mairaj — Wed, 22 Jul 2026 09:45:25 +0000

By the SUDO team, an AWS Premier Tier Services Partner helping regulated banks and government entities across the UAE and Saudi Arabia build compliant, audit-ready cloud environments.

When it comes to AWS network security, most teams stop at Security Groups and NACLs. I have lost count of how many AWS accounts I have opened up expecting a mess and instead found the opposite: Security Groups locked down tight, Network ACLs written with real care, workloads sitting quietly in private subnets. Whoever built it did the homework. And that is usually where the story ends, because once the perimeter looks clean, most teams tick the box and move on to the next thing.

The trouble is that the perimeter looking clean and the network actually being defended are two different claims. Security Groups and NACLs are very good at one thing: answering “is this IP allowed to reach this port?” But a production environment in a regulated industry gets hit by plenty of things that never ask that question in the first place. A box that has been quietly compromised and is now beaconing out to a command-and-control server. A flood of traffic big enough to knock your load balancer over before any rule gets a chance to say “denied.” Data leaving your VPC one DNS query at a time. None of that is stopped by the two controls almost everyone leans on.

And if you run workloads for a bank under the Saudi Central Bank (SAMA) Cyber Security Framework, for an entity covered by the National Cybersecurity Authority (NCA) Essential Cybersecurity Controls, or for anyone handling personal data under the UAE or Saudi PDPL, this is not just a security worry. It is the kind of thing that turns into an audit finding. Every one of those frameworks now expects layered, defense-in-depth network controls. A single perimeter does not cut it anymore.

So in this post I want to walk through the five gaps I see most often in GCC production AWS accounts, and the AWS services that actually close them: AWS Network Firewall, AWS WAF, AWS Shield Advanced, VPC Flow Logs, and Route 53 Resolver DNS Firewall. Wherever it makes sense to get hands-on in the console, I have flagged exactly what to set up so you can follow along in your own account.

At SUDO, an AWS Premier Tier Services Partner working with regulated enterprises across the UAE and Saudi Arabia, these are the five gaps we see most often in GCC production AWS accounts and the AWS services we deploy to close them.

Why Security Groups and NACLs are not enough

Before getting into the gaps, it is worth being honest about what these two controls actually do, because the limitation is baked into how they work. It is not something you can fix by trying harder with the configuration.

A Security Group is a stateful firewall that sits on a network interface. It looks at Layer 3 and Layer 4: source, destination, protocol, port. Because it is stateful, return traffic comes back automatically. What it cannot do is look inside the packet. It has no idea whether the HTTPS session it just allowed on port 443 is a normal API call or someone probing you with an SQL injection payload. It cannot tell the difference between an outbound connection to your package repo and an outbound connection to an attacker’s server sitting on the same port.

A Network ACL works at the subnet edge and is stateless, which makes it handy as a blunt guardrail but painful and easy to get wrong once you want anything fine-grained. Same core blind spot as the Security Group: it sees headers, never the payload.

That is really the whole point. Both controls decide based on where traffic is going, never on what the traffic actually is. That gap is exactly what modern attacks live in, and it is exactly what GCC regulators have started poking at. When you read the SAMA infrastructure security requirements, they call for network segmentation, protection against malicious code and advanced persistent threats, DDoS protection, and secure protocols. Honestly, it reads almost like a shopping list for the services in the rest of this article.

How the regulators frame it

It helps to keep the regulator’s language in the back of your mind as we go, because every control below maps to something an assessor is going to ask you about.

SAMA Cyber Security Framework (Saudi financial sector). The Operations and Technology domain wants firewalls, intrusion detection and prevention, segmentation to stop lateral movement, DDoS mitigation, and centralised logging feeding a SIEM. It is principle-based and scored on a maturity scale from 0 to 5, so “we have Security Groups” is not going to move your score. Assessors want to see controls that are enforced, monitored, and layered.

NCA Essential Cybersecurity Controls (Saudi government and critical national infrastructure). A baseline of 114 controls around confidentiality, integrity, and availability, with network security, monitoring, and event logging sitting right in the core technical domains. The related Cloud Cybersecurity Controls push further and expect data residency and control to be enforced technically, not just promised on paper.

UAE PDPL and Saudi PDPL. Both put obligations on you around protecting personal data, notifying breaches, and controlling cross-border transfers. One thing that catches people out: your logging and DNS infrastructure usually carries personal data too, so visibility and control over where data can flow becomes a privacy control, not only a security one.

The short version: every one of these frameworks expects you to see your traffic, control it beyond the header, contain lateral movement, ride out a volumetric attack, and prove all of it with logs. Security Groups and NACLs give you a slice of that, not the whole thing.

Gap 1: No deep packet inspection or egress control

Close it with AWS Network Firewall

This is the first gap and, if you ask me, the one that matters most. Nothing in a default VPC inspects the content of your traffic, and almost nothing controls where your workloads are allowed to reach outbound. Everyone pours effort into ingress and then leaves egress wide open. From an attacker’s point of view, that is backwards. Once they land on a box, their whole operation happens on the way out: pulling down tooling, moving data off, calling home to a C2 server. All of it rides the egress path nobody bothered to lock down.

AWS Network Firewall is the managed service that plugs this hole. It is a stateful, VPC-level firewall and intrusion prevention system that does real deep packet inspection, meaning it reads the payload of your packets and not just the headers. Its stateful engine is Suricata-compatible, so it talks the same rule language as one of the most widely used open-source IPS engines out there. That is a bigger deal than it sounds if your team already has Suricata rules or wants to pull in community threat rules.

What it actually lets you do

Domain-based egress filtering. You can build an allow-list of exactly the domains your workloads are allowed to reach, your package repos, your partners’ APIs, AWS endpoints, and drop everything else. If I had to pick one control to contain a compromised host, this would be it. It also lines up directly with the “stop lateral movement and APT activity” language in the SAMA and NCA frameworks.

Intrusion prevention with Suricata rules. The stateful engine runs deep packet inspection against IPS-style rules, so you can drop known exploit patterns, malicious signatures, and protocol oddities. AWS also ships managed rule groups aimed at evasive command-and-control channels and malicious URLs, so you are not writing every rule from a blank page.

Stateless and stateful evaluation. The fast, header-based stateless rules run first for the obvious high-volume decisions, and anything that needs a proper look gets handed to the stateful engine. Getting that split right is what keeps both your latency and your bill sensible.

Actions you can take. Rules can pass, drop, reject, or alert. The way I roll new rules out is always the same: put them in alert mode first, watch the logs for a while, and only then flip them to drop. That way you are not black-holing something legitimate on day one.

Architecture note: Network Firewall sits in its own dedicated subnet, and you send traffic through it using VPC route tables. In a multi-account, multi-VPC setup, which is basically every GCC enterprise I work with, the clean way to do this is a central inspection VPC behind AWS Transit Gateway. One firewall deployment ends up protecting many VPCs, and your policy stays consistent everywhere.

Gap 2: Application-layer attacks walk straight in

Close it with AWS WAF

Your Security Group will wave through every packet on port 443, because as far as it is concerned, HTTPS hitting your web tier is completely normal. The catch is that SQL injection, cross-site scripting, credential stuffing, and bot abuse all show up as perfectly valid HTTPS. The nasty part is inside the request, at Layer 7, which is precisely where your network controls are blind.

AWS WAF is a web application firewall that reads HTTP and HTTPS requests before they ever reach your app. You attach it to a Layer 7 entry point, a CloudFront distribution, an Application Load Balancer, or an API Gateway, and it checks each request against a web ACL made up of rules.

What to set up beyond the defaults

AWS Managed Rules. Start here. The Core Rule Set, the Known Bad Inputs set, the SQL database protections, and a few others. AWS maintains and updates these as new threats appear, which happens to be exactly the “kept current” story assessors like to hear.

Rate-based rules. Set a threshold of requests per source over a time window and block or challenge anything above it. This is your first answer to brute-force login attempts and application-layer floods, and it pairs nicely with the volumetric protection in the next section.

Geo matching. A lot of GCC businesses serve a clearly defined region. Geo rules let you tighten access to the countries you actually expect and treat the rest with more suspicion. Useful for security, and sometimes for data-flow governance too.

Custom rules for your own app. On top of the managed sets, write rules for the paths you know are sensitive, admin panels, upload endpoints, that sort of thing.

Logging to your SIEM. Send WAF logs into your central logging pipeline. The SAMA expectation around centralised logging and correlation applies here directly.

Deploy in count mode first. Every new WAF rule has a “count” action that logs what it would have blocked without actually blocking anything. Run new rules in count mode against real traffic, look at what they catch, then switch them to block. This is how you avoid the classic WAF launch day where a legitimate business flow gets caught by a rule that was a touch too broad. I have seen that go wrong more than once, and it is always avoidable.

Gap 3: A volumetric attack takes you offline

Close it with AWS Shield Advanced

No amount of Security Group tuning saves you from a distributed denial-of-service attack. If a botnet is hurling hundreds of gigabits a second at your public endpoint, your capacity is gone long before any allow-or-deny decision even becomes relevant. And for a regulated business, availability is not a bonus feature. Both the SAMA and NCA frameworks treat availability and DDoS protection as things you are required to have.

Every AWS customer already has AWS Shield Standard at no extra cost, and it automatically handles the most common network and transport layer attacks across CloudFront, Route 53, and Global Accelerator, using the sheer scale of the AWS edge to soak them up. For most public-facing production workloads in a regulated shop, though, Standard is the floor, not the ceiling.

What Shield Advanced adds on top

Detection tuned to your resources. Shield Advanced learns the normal traffic pattern of the resources you protect and gives you always-on, flow-based monitoring with near real-time alerts on suspected incidents. So detection is shaped around your traffic instead of a generic threshold.

Wider coverage.You can protect CloudFront distributions, Route 53 hosted zones, Global Accelerator, Application and Classic Load Balancers, and EC2 Elastic IPs.

Layer 7 DDoS protection. Application-layer DDoS protection ties into AWS WAF, which connects the volumetric defense here to the request-level defense from the last section.

The Shield Response Team. If you are on Business or Enterprise Support, you can pull in the SRT around the clock during an attack, and with proactive engagement turned on, they will reach out to you when a Route 53 health check on a protected resource goes unhealthy during an event they have detected.

Cost protection. If an attack forces your protected resources to scale up, you can request credits for those charges, as long as the resource was protected before the attack started. That condition is the whole reason to onboard resources ahead of time instead of scrambling in the middle of an incident.

Be honest about the budget. Shield Advanced is a real commitment. It is a monthly subscription per organisation, in the region of US$3,000 a month plus data transfer, and it usually comes with a one-year term. For a revenue-generating or compliance-critical workload, that number is tiny next to what a sustained outage costs you in business and in regulatory pain. But it is still a line item, and it should be a deliberate call rather than a reflex. For lower-risk workloads, Shield Standard plus WAF rate-based rules might be the right-sized answer.

Gap 4: You cannot see your own traffic

Close it with VPC Flow Logs

Here is a question I like to ask about any production VPC, and it usually gets an awkward pause: if a box got compromised right now and started talking to somewhere it should not, would you even know? Without flow logging, the honest answer is almost always no. Security Groups and NACLs make decisions, but on their own they do not leave you a durable, searchable record of what actually crossed your network.

VPC Flow Logs capture the metadata of IP traffic going in and out of the network interfaces in your VPC: source and destination addresses and ports, protocol, packet and byte counts, and, importantly, whether each flow was accepted or rejected by your Security Groups and NACLs. You can switch them on at the VPC, subnet, or individual interface level, and send them to CloudWatch Logs, Amazon S3, or Amazon Data Firehose.

Why this is a compliance keystone, not just an ops nicety

It is your evidence. The centralised logging and monitoring requirements that run through SAMA and NCA are not satisfied by controls alone. Assessors want proof that you can see what is happening. Flow logs are the raw material an auditor, an incident responder, or a CERT-SA notification all end up leaning on.

It turns rejects into signal. A sudden spike of rejected flows to one port, or accepted flows heading somewhere nobody recognises, is exactly the kind of anomaly flow logs surface and your SIEM can alert on.

It makes the other four controls safer. When you roll out Network Firewall or WAF in alert or count mode first, the flow logs and the service logs together confirm that you are about to block the right things, not the wrong ones.

A privacy point people trip over: logging infrastructure can carry personal data, which puts it within scope under PDPL. When you decide where flow logs and other telemetry live and who can get at them, treat that pipeline as a data-protection question. Keep it in-region, lock down access, and set retention on purpose. A logging design that ignores residency can quietly undercut the very compliance posture it was meant to support.

Making the logs actually usable

Raw flow logs are a firehose; there are a lot of them. The pattern that works is to land them in S3 and query with Amazon Athena, or stream them to CloudWatch Logs and build metric filters and alarms for the patterns you care about. Either way, the aim is the same: get from “we are collecting logs” to “we get told when something looks wrong.” That second thing is what an auditor is really checking for.

Gap 5: DNS is an open exfiltration channel

Close it with Route 53 Resolver DNS Firewall

This is the gap teams overlook the most, and I get why. DNS feels like plumbing, not an attack surface. But nearly every environment lets outbound DNS resolve freely, and attackers absolutely know that. DNS tunnelling sneaks data out of a VPC encoded inside the queries themselves. Malware uses domain-generation algorithms to find its C2 server among thousands of throwaway domains. Compromised hosts resolve known-bad domains as step one of the attack. Your Security Groups happily allow port 53 without blinking, and none of it ever shows up as a “denied” connection.

Route 53 Resolver DNS Firewall lets you filter the outbound DNS queries coming from your VPCs. You define domain lists and rule groups that allow, block, or alert on queries, and you attach them to your VPCs so the Resolver enforces them.

What to put in place

Block the known-bad domains. Use the AWS Managed Domain Lists, the curated low-reputation and malicious lists, as an immediate baseline, then stack your own block and allow lists on top.

Allow-list where it counts. For your most sensitive VPCs, flip the model around: only permit resolution for the domains your workloads genuinely need, and block the rest. This is the DNS-layer twin of the egress allow-listing you did with Network Firewall, and together they make exfiltration genuinely hard.

Catch the advanced stuff. DNS Firewall Advanced targets DNS tunnelling and domain-generation-algorithm traffic specifically, the evasive techniques that threat-intel feeds alone struggle to catch in time, by watching for anomalies in the domain names being queried and blocking them in real time.

Close the loop with GuardDuty. A neat pattern is to let Amazon GuardDuty spot a suspicious DNS query and automatically push that domain into a DNS Firewall block list, so detection becomes prevention without anyone lifting a finger.

Why this maps so cleanly to GCC compliance: DNS exfiltration is a data-flow problem, and controlling where data can leave your environment sits at the heart of both the “stop data leaking” spirit of the PDPL laws and the APT-protection requirements in SAMA and NCA. DNS Firewall is a small service that closes a surprisingly large gap.

Putting it together: one layered defense, not five separate products

The reason these five services matter is not that any one of them is dazzling on its own. It is that together they add up to the defense-in-depth architecture every GCC framework is actually asking you for. Read from the edge inward, it looks like this:

At the edge: Shield Advanced soaks up the volumetric and sophisticated DDoS attacks, and WAF inspects and filters every application-layer request before it reaches your app.

Inside the VPC: Network Firewall does the deep packet inspection and decides exactly where your workloads are allowed to connect, while DNS Firewall shuts the DNS exfiltration channel.

At the subnet and instance: your existing Security Groups and NACLs stay as the innermost ring. Still needed, just not carrying the whole load on their own anymore.

Across all of it: VPC Flow Logs, together with your WAF, firewall, and Resolver logs, give you the visibility and the evidence that turn a pile of controls into a posture you can actually prove.

That last point is where regulated businesses pass or fail an assessment. SAMA maturity scoring, NCA self-assessment submissions, PDPL accountability- all of them reward the organisation that can demonstrate its controls work, not just claim they do. Layered controls plus centralised, in-region logging is the combination that holds up when a reviewer, or an attacker, decides to test it.

This is exactly the layered model we implement for clients through our AWS Managed Cloud Services and DevOps as a Service engagements: built once, monitored continuously, and mapped to SAMA, NCA and PDPL.

The five services working together as one defense-in-depth architecture, from edge to instance.

Each gap maps to a specific service and the GCC regulatory requirement it helps satisfy.

A sensible order to roll this out

If today you are mostly running on Security Groups and NACLs, here is the order I would tackle it in, because each step makes the next one safer to deploy:

Turn on VPC Flow Logs first. You cannot safely deploy anything else without visibility, and this is the quickest win on the list.
Add WAF to your public Layer 7 entry points, in count mode, then switch to enforce.
Deploy Network Firewall for egress control and IPS, in alert mode, then move to drop.
Add DNS Firewall with the managed bad-domain list, then tighten toward allow-listing for your sensitive VPCs.
Weigh up Shield Advanced for the workloads that are genuinely business or compliance critical, as a deliberate budget decision.

If you would rather not tackle this alone, this is precisely the kind of AWS network security consulting work SUDO Consultants delivers for banks and government entities in the UAE and Saudi Arabia.

Where SUDO fits in

SUDO is an AWS Premier Tier Services Partner based in Dubai with a presence in Riyadh, and we design and run production AWS environments for regulated businesses across the UAE and Saudi Arabia. Layered network defenses like the one I have walked through here are part of how we deliver Managed Cloud Services and DevOps as a Service, mapped to the specific SAMA, NCA, and PDPL requirements they need to meet, deployed with the alert-first safety patterns above, and backed by centralised, in-region logging that holds up in an audit.

If your AWS environment still rests mostly on Security Groups and NACLs, that is a common place to be and a very fixable one. The best time to sort it out is before an assessment or an incident forces your hand.

Book a layered network defense review with SUDO and walk into your next SAMA, NCA or PDPL assessment, whether in Dubai or Riyadh, with the evidence already in place.

www.sudoconsultants.com
reach@sudoconsultants.com

Frequently asked questions

Is AWS Network Firewall required for SAMA compliance?

SAMA does not name specific AWS services, but its Operations and Technology domain expects firewalls, intrusion detection and prevention, and segmentation that stops lateral movement. AWS Network Firewall's deep packet inspection and domain-based egress filtering are a direct way to evidence those controls at the VPC level.

How does SUDO Consultants help UAE and Saudi enterprises meet PDPL on AWS?

We design and run AWS environments with in-region, access-controlled logging and DNS controls, so personal data flows stay visible and contained, mapping the technical controls to UAE and Saudi PDPL obligations around data protection, breach notification, and cross-border transfer.

Do I still need Security Groups if I use AWS WAF and Shield Advanced?

Yes. Security Groups and NACLs stay as the innermost ring of a defense-in-depth model. WAF, Shield Advanced, Network Firewall, and DNS Firewall add the application-layer, volumetric, deep-packet, and DNS controls that Security Groups cannot see. They complement the basics, not replace them.

When the Cloud Goes Dark, Will Your Business Stay On?

maryam mairaj — Wed, 15 Jul 2026 06:54:12 +0000

The Enterprise Blueprint for Resilient, AI-Ready AWS Architectures

Let me be honest with you. I have spent a long time helping enterprises build resilient architectures on AWS, and the question that keeps me up at night is not whether a cloud provider can fail. We know it can. The real question is: when it does, is your business designed to survive it?

In early 2026, that question became a reality for enterprises across the Middle East. The region experienced one of the most significant cloud infrastructure disruptions in its history, with widespread service impacts across critical sectors, including banking, payments, logistics, and enterprise software. Organizations that had not designed for regional failure scenarios found themselves without a recovery path. The disruption was not the result of a configuration error or a software defect. It was an infrastructure-level event that most resilience frameworks are rarely stress-tested against.

And here is what separated the enterprises whose services stayed online from those that experienced unplanned service outages: they had already done the architecture work. They had designed for failure. They had distributed their workloads across regions. They had tested their recovery scenarios. And in 2026, the most forward-thinking of them had already started laying the foundation for AI-managed, self-healing cloud environments that reduce human reaction time from hours to seconds.

This blog is your blueprint for building that kind of architecture, before you need it.

What Is AWS Resiliency?

AWS resiliency is the ability of a workload to resist and recover from disruptions, including infrastructure failures, sudden load spikes, transient network issues, and security attacks, ensuring minimal downtime and continuous service availability.

Why a Single-Region AWS Architecture Is No Longer a Strategy

I understand why teams end up single-region. It feels like the right call when you are moving fast, controlling costs, and dealing with everything else that comes with running production infrastructure. A region has multiple AZs. AWS has SLAs. The probability of a full regional failure seemed like a footnote in a risk register, until it was not.

Single-region architectures carry risks that most teams do not fully consider until they are staring at an incident report:

A full regional failure, regardless of the cause, takes everything down simultaneously
Data sovereignty laws in the UAE and KSA can change, forcing unplanned migration with no live failover to fall back on
Cascading service failures within a single region have no blast radius boundary
Sustained DDoS attacks targeting a region have no automatic escape route
Compliance audits increasingly require documented multi-region DR capability

The question to ask yourself is simple: if ME-CENTRAL-1 disappeared today, what would happen to your customers, your revenue, and your SLA commitments? If the answer is uncomfortable, keep reading.

What AWS Resilience Actually Means, The Four Failure Domains

Before you can design for resilience, you need to be honest about what you are designing against. AWS resiliency is not one thing. It spans four distinct failure domains, and most architectures are only built to handle one or two of them well.

The four failure domains of AWS resiliency are infrastructure failure, sudden load spikes, transient network issues, and security attacks.

If your resilience plan only addresses infrastructure failure, you are three-quarters exposed. The architectures I am most proud of treat each of these as an independent failure domain with its own detection, response, and recovery path

Multi-AZ vs Multi-Region vs Multi-Cloud on AWS: Which One Do You Actually Need?

This is where most teams overcomplicate things, or worse, underbuild. Let me cut through it.

Multi-AZ: The Baseline, Not the Goal

Every production workload should be multi-AZ. Full stop. Multiple AZs within a region are physically separate facilities with independent power and networking. A multi-AZ RDS, multi-AZ EKS node group, or multi-AZ Auto Scaling group protects you from single-facility failure. This is table stakes, not architecture. It does not protect you from regional failure.

Multi-Region: Where Real Resilience Begins

For workloads where uptime is a business-critical requirement, a multi-region AWS architecture is the standard. Your three options here are not equally expensive, and they do not all suit the same scenarios:

Active-Active: Both regions handle live traffic simultaneously. Near-zero RTO. Highest cost. Right for globally distributed applications where latency and availability are both non-negotiable.
Warm Standby: Secondary region runs at reduced capacity and scales up in minutes when the primary fails. Moderate RTO (1-15 min). The sweet spot for most enterprise workloads.
Pilot Light: Minimal core services run in the secondary region. Full activation needed during failover. Lowest cost multi-region option. RTO of 15-60 minutes. Right for lower-criticality workloads with tighter budgets.

Multi-Cloud: The Strategic Hedge

Multi-cloud means running your disaster recovery (DR) or standby environment in Azure or Google Cloud rather than a second AWS region. More complex, more expensive, and frankly, overkill for most scenarios.
But for enterprises in regulated industries or regions where infrastructure continuity cannot be tied to a single provider, it is the only approach that truly eliminates that dependency. Recent events in the region have made this conversation more common in boardrooms than it has ever been.

SUDO Recommendation: For most MENA enterprises, a multi-AZ primary deployment paired with a warm standby in a second AWS region gives the best cost-to-resilience ratio. Add a pilot light third region or secondary cloud for regulated workloads where sovereignty and uptime commitments intersect.

RTO and RPO: The Numbers Your Architecture Must Be Built Around

I have seen more resilience failures caused by undefined RTO and RPO than by any architecture mistake. These two numbers are the foundation of every decision in this space, and they need to come from the business, not be assumed by engineering.

These are business decisions with architectural consequences. A payment platform might need an RTO of under 60 seconds. An internal analytics dashboard might be fine with 4 hours. The architecture you build should be designed to meet the commitment the business has made, not the one that is technically interesting to build.

The AWS-Native Resilience Toolkit: 8 Services That Do the Heavy Lifting

AWS gives you everything you need. The challenge is knowing which tool solves which problem, and understanding that resilience is a system, not a feature you turn on.

Amazon Route 53: Health-check-based failover routing that redirects traffic to a healthy region or endpoint within seconds of detecting failure. This is your traffic brain. Configure failover, latency-based, or weighted routing policies based on your architecture. Without it, multi-region is just two deployments that do not talk to each other.

AWS Auto Scaling + Elastic Load Balancing: Automatically adjusts compute capacity in response to real demand. Define scaling policies on CloudWatch metrics. Combined with ELB, you get seamless traffic distribution across healthy instances with no manual intervention.

Amazon RDS Multi-AZ and Cross-Region Replicas: Multi-AZ gives you synchronous replication and automatic failover within a region. Cross-region read replicas can be promoted to primary during a regional failure, your database’s escape hatch.

AWS Backup: Centralised backup management across EC2, RDS, EFS, DynamoDB, S3, and more. Enable cross-region replication and vault lock for immutable backup storage. If you are not testing your restores quarterly, your backups do not exist.

AWS Fault Injection Simulator (FIS): Run controlled chaos engineering experiments against your actual infrastructure. Instance failures. Network latency injection. API throttling. AZ outages. If you have not deliberately broken your architecture in a controlled environment, you will find out how it behaves in the worst possible moment.

Amazon CloudWatch + EventBridge: Real-time monitoring, composite alarms, and event-driven automation. The combination of CloudWatch detecting a problem and EventBridge triggering a Lambda response is the foundation of self-healing architecture.

AWS Global Accelerator: Routes user traffic through AWS’s global network backbone, reducing latency and automatically rerouting to the next available healthy endpoint during disruption. Invisible to users. Invaluable during a regional event.

Amazon CloudFront Origin Groups: An often overlooked but highly effective resilience pattern for static and web workloads, and one we have validated in our own lab environment. The architecture works as follows: Route 53 routes users to a CloudFront distribution configured with an Origin Group, a primary S3 bucket in your main region serving your static website, and a replica S3 bucket in your DR region as the secondary origin. S3 Cross-Region Replication (CRR) keeps the DR bucket continuously in sync with the primary. If CloudFront detects a failure on the primary origin, it automatically routes requests to the DR replica with no DNS change, no manual intervention, and no disruption to end users. For enterprises hosting static websites, SPAs, or media assets on S3, this is one of the most straightforward and cost-effective ways to add genuine regional resilience to your front-end layer.

AWS Resilience Hub: The One Service Most Teams Are Not Using Enough

I want to spend some real time here because AWS Resilience Hub is one of the most impactful services you can adopt for resilience management, and it is built specifically for what we are talking about.

Most teams audit their resilience manually: someone books a Well-Architected Review, a list of recommendations comes out, a few things get fixed, and then six months pass, and the architecture has drifted. Resilience Hub replaces that cycle with something continuous.

Here is what it does: You define your application by mapping your AWS resources. You set your RTO and RPO targets. Resilience Hub assesses your architecture against those targets and gives you a Resilience Score out of 100, along with a precise breakdown of where your gaps are, not just that a gap exists, but which resource, which failure mode, and which action to take.

Think of AWS Resilience Hub as a continuous Well-Architected Reliability review, automated, repeatable, and integrated into your CI/CD pipeline, DevOps / Platform Engineering service, so resilience is validated before deployment, not discovered during an incident.

What Makes Resilience Hub Different

Resilience Score (0-100): A quantified measure of how well your application meets your defined RTO and RPO. Updated continuously as your architecture changes.
Auto-Generated SOPs: Resilience Hub generates runbooks specific to your application and failure scenarios. Not generic templates. Actual operational procedures based on your resources.
Alarm Recommendations: It maps the gap between what you are currently monitoring and what you should be monitoring, then tells you exactly which CloudWatch alarms to create.
CI/CD Integration: Embed resilience assessments into your deployment pipeline. A release that degrades your Resilience Score below your threshold gets flagged before it ships.
Drift Detection: Continuously monitors your live environment against its last assessed state. The moment a configuration change reduces your resilience, you are notified.

Other AWS Services Worth Having in Your Resilience and Disaster Recovery (DR) Stack

Resilience Hub is the management layer. These services are the execution layer, each one solving a specific failure domain.

AWS Elastic Disaster Recovery (AWS DRS): Formerly CloudEndure, AWS DRS does continuous block-level replication of your servers, whether they are on-premises, in another cloud, or in another AWS region, into a staging area in your target region. When you need to fail over, you launch fully provisioned recovery instances in minutes. This is the service that closes the gap between ‘we have backups’ and ‘we can actually recover fast.’

AWS Systems Manager: Systems Manager is the operational backbone of resilience automation. Use it to define Automation documents (runbooks) that respond to failure events: restart a service, promote a replica, quarantine an instance, or run a health check sequence. Combined with EventBridge, it turns your monitoring from observation into action.

Amazon EventBridge: EventBridge is what wires your resilience tooling together. Route 53 health check failures, CloudWatch alarms, GuardDuty findings, Resilience Hub drift notifications, all of them can trigger EventBridge rules that invoke Lambda functions, Systems Manager runbooks, or Step Functions workflows. Without EventBridge, your detection and your remediation live in separate worlds.

AWS Config: Config continuously records your resource configurations and evaluates them against compliance rules. For resilience, this means you can automatically detect and alert on changes that degrade your architecture, a Multi-AZ RDS instance quietly converted to single-AZ, a backup policy removed, or an Auto Scaling group min-capacity set to zero. Config rules can trigger automatic remediation, turning a potential outage into a corrected configuration.

AWS Step Functions: For multi-step recovery workflows that involve decisions, branching, retries, and parallel actions across multiple services, Step Functions gives you the orchestration layer. Define your recovery procedure as a state machine. It is auditable, versioned, testable, and far more reliable than a runbook that exists only in a Confluence page someone last updated eighteen months ago.

Your AWS Resilience Checklist: Run This Against Your Environment This Week

Print this out. Put it in your next architecture review. Be honest with the answers.

All production workloads are deployed across at least two Availability Zones.
RTO and RPO targets defined, documented, and signed off by business stakeholders, not assumed by engineering.
Multi-region failover strategy implemented and tested for every critical workload.
Automated backups are enabled with cross-region replication and quarterly tested restores.
Route 53 health checks and failover routing have been configured, validated, and tested in the last 90 days.
AWS Resilience Hub assessment completed and Resilience Score reviewed for all critical applications.
Chaos engineering experiments run against production-equivalent environments using AWS FIS.
AWS Well-Architected Reliability Pillar review completed in the last 12 months.
Data sovereignty and compliance requirements are explicitly mapped to region configurations.
Incident runbooks documented, tested, and team-trained, not just written and filed.
Monitoring and alerting covering all four failure domains: infrastructure, load, network, and security.
CI/CD pipeline includes a Resilience Hub assessment gate before production deployment.

The Future of AWS Resilience: When the Architecture Heals Itself

Everything I have covered so far describes how the best teams operate today. What follows is where this is heading, and why the enterprises that start laying this foundation now will have a real competitive advantage within the next two to three years.

Traditional resilience still has humans in the loop, and a CloudWatch alarm fires. Someone gets paged. A runbook gets opened. A decision gets made. A failover gets executed. Even in the most well-prepared teams, that chain takes 15 to 60 minutes. In a catastrophic failure event, those minutes are everything.

AI-managed and agentic architectures close that loop. This is what a self-healing cloud architecture looks like in practice:

–> Proactive Detection with Amazon DevOps Guru: DevOps Guru uses machine learning trained on millions of AWS deployments to surface operational anomalies before they breach a threshold. It is not waiting for something to break. It identifies the pattern that precedes a break and gives you a recommendation before your users notice anything.

–> Autonomous Failover Agents: Purpose-built agents on Amazon Bedrock SUDO Generative AI service wired to Route 53, Systems Manager, and RDS, can evaluate failure conditions and execute recovery actions, trigger a failover routing policy, promote a read replica, spin up warm standby capacity, without waiting for a human approval step. The
agent executes the runbook. You review the audit log.

–> Predictive Auto Scaling: Predictive Scaling uses historical CloudWatch metrics and machine learning to forecast demand and proactively provision capacity before load arrives. For MENA enterprises with predictable patterns around prayer times, national holidays, and regional business cycles, this is not theoretical; it is immediately applicable.

–> Multi-Agent Orchestration: The most advanced implementations today run multiple specialised agents in coordination: an availability agent, a cost agent, a security agent, a compliance agent. Each monitors its domain, surfaces insights to a central orchestration layer built on Bedrock Agents and Step Functions, and executes actions within its defined authority boundaries. Some financial services enterprises in the region are already running early versions of this in production.

The shift is not from fragile to resilient. It is from resilient to self-healing, where the architecture detects, decides, and recovers faster than any human team ever could.

Frequently Asked Questions:

What is AWS resiliency?
AWS resiliency is the ability of a workload to resist and recover from disruptions, infrastructure failures, sudden load spikes, transient network issues, and security attacks, ensuring minimal downtime and continuous service availability.

What is the difference between RTO and RPO?
RTO (Recovery Time Objective) is the maximum acceptable time a service can be down. RPO (Recovery Point Objective) is the maximum acceptable amount of data loss, measured as the time since the last recovery point. Both should be set by the business, not assumed by engineering.

What is the difference between multi-AZ and multi-region on AWS?
Multi-AZ spreads a workload across physically separate facilities within one region and protects against single-facility failure. Multi-region replicates the workload to a second AWS region and protects against full regional failure; the scenario multi-AZ alone cannot survive.

What is the difference between warm standby and pilot light?
Warm standby runs a scaled-down but fully functional copy of your environment in a second region (RTO 1–15 minutes). Pilot light keeps only minimal core services running and requires full activation during failover (RTO 15–60 minutes) at a lower cost.

What is AWS Resilience Hub?
AWS Resilience Hub continuously assesses an application against its RTO and RPO targets, produces a Resilience Score out of 100, auto-generates runbooks, recommends CloudWatch alarms, and detects configuration drift, a continuous, automated Well-Architected Reliability review.

How do MENA data sovereignty rules affect AWS architecture?
UAE and KSA sovereignty and compliance requirements can dictate where data resides and may change, so regulated enterprises should map compliance requirements explicitly to region configurations and maintain a tested multi-region or secondary-cloud failover path.

What SUDO Builds for MENA Enterprises

We have been designing and implementing resilient AWS architectures across banking, healthcare, government, logistics, and retail in the UAE, KSA, and the broader MENA region for years. What I have described in this blog is not a theory for us; it is what we build every week.

We do not offer resilience templates. Every engagement starts with an honest assessment of where you are, what your business actually needs in terms of RTO and RPO, what your regulatory obligations require, and where your team’s operational maturity sits. From there, we design and implement a layered resilience architecture that fits your real constraints, not a textbook solution.

Our resilience engagements typically cover:

AWS Well-Architected Reliability Pillar assessment and remediation
Multi-AZ and multi-region architecture design and implementation
AWS Resilience Hub setup, scoring, and CI/CD integration
Disaster recovery strategy, runbook development, and failover testing
Backup architecture design with cross-region replication and validated restores
Chaos engineering programme using AWS Fault Injection Simulator
Route 53 failover routing, Global Accelerator, and AWS DRS configuration
AI-readiness assessment for autonomous monitoring and self-healing patterns
Ongoing managed resilience monitoring and continuous improvement

Ready to Build an Architecture That Stays On When Everything Else Goes Dark?

See how SUDO designs and implements resilient infrastructure for MENA enterprises. And book a free AWS Resiliency Assessment with SUDO's certified cloud architects.
Book Your Free AWS Resiliency Assessment

The Cloud Was Supposed to Fix This

maryam mairaj — Wed, 24 Jun 2026 06:46:07 +0000

A Practical Guide to AWS Cloud Migration and Modernization for MENA Enterprises

Every enterprise migration conversation I have starts the same way. Someone in the room says, “We want to move to the cloud.” What they usually mean is: we want to move our workloads off ageing on-premises infrastructure, reduce our data center footprint, and stop worrying about hardware refresh cycles.

That is migration. It is a valid goal. But it is also just the first chapter. For MENA enterprises, AWS cloud migration provides a foundation for reducing data centre costs, modernizing legacy workloads, and meeting regional compliance requirements such as the UAE PDPL and the SAMA CSF.

The enterprises that actually realize the value of cloud are the ones that use migration as the trigger for something bigger: modernizing how their applications are built, deployed, and operated. Organizations that migrate without a modernization strategy often end up with higher costs, slower delivery, and the same technical constraints, just running on someone else’s hardware in a different location.

In this guide, I want to walk through the full Migration and Modernization journey on AWS. Not a marketing overview, but the practitioner’s version: what the tools actually do, where the hard problems are, what the latest AI-powered capabilities change, and how MENA enterprises specifically need to think about this.

AWS Migration Assessment and Strategy: Before You Move Anything

The most common mistake in migration programs is starting execution too early. Teams want to move fast, so they pick a handful of workloads and start migrating before they fully understand their portfolio. Six months later, they have completed the easy workloads and are facing the complex ones with no map, no wave plan, and a growing list of undocumented dependencies.

A proper assessment is not overhead. It is the single highest-return investment you make before the first workload moves.

AWS Transform: The Central Platform

AWS Transform, which replaced AWS Migration Hub in late 2025, is where every serious migration program should start. It is the central platform for migration and modernization planning, and it has evolved significantly beyond its predecessor.

Portfolio discovery and dependency mapping: Automated discovery of your application portfolio across on-premises and cloud environments. AWS Transform maps dependencies between applications so you understand what breaks if you move workload A before workload B.
Migration readiness scoring: Each workload receives a readiness score based on complexity, dependencies, and risk factors. This determines your wave sequence before you touch a single server.
7Rs strategy recommendation: For each workload, AWS Transform recommends the right migration strategy based on its analysis. Not every workload should be migrated the same way.
Business case generation: TCO analysis and business case built per migration wave. This is what your CFO actually needs before approving the program budget.
Wave planning and program management: End-to-end migration tracking across workloads, teams, and timelines in a single platform.

In its first year, AWS Transform processed over 4.5 billion lines of code and saved 1.69 million engineering hours across customer programs. That is a fundamentally different way of running a migration assessment.

The 7Rs Framework: Asking the Right Question Per Workload

The 7Rs framework gives you a decision structure for each application in your portfolio. Applying the same strategy to every workload is where migration programs get into trouble.

Core Migration Execution: AWS MGN and DMS

AWS Application Migration Service (MGN)

MGN is the primary tool for infrastructure migration. It uses agent-based continuous block-level replication: it copies your source servers into AWS in real time with minimal performance impact on running workloads. Before you cut over, you can test your migrated workloads in AWS while your source servers remain live. The actual cutover window is typically under an hour.

MGN works across physical servers, VMware, Hyper-V, and other cloud environments. It handles Windows, Linux, and most enterprise operating systems. For enterprise migrations running a lift-and-shift strategy, this is where execution starts.

AWS Database Migration Service (DMS)

Databases are the hardest part of almost every migration program. They carry the most risk, have the lowest tolerance for downtime, and frequently run on versions and configurations that require careful handling.

AWS DMS handles both homogeneous migrations (Oracle to Oracle, SQL Server to SQL Server) and heterogeneous migrations (Oracle to Aurora PostgreSQL, SQL Server to MySQL). It maintains continuous replication during migration, meaning your source database stays fully live until the moment of cutover. DMS Serverless, now generally available, removes the need to provision and manage replication instances. It scales replication capacity automatically based on workload volume.

For heterogeneous migrations, AWS Schema Conversion Tool (SCT) automates schema conversion and clearly identifies what converts automatically versus what requires manual attention. This is where you understand your true migration effort for database workloads before you commit to a timeline.

VMware Migrations: The Relocate Path

For enterprises running large VMware estates, VMware Cloud on AWS allows you to move VMware workloads to AWS without changing the hypervisor, the operations model, or the management tooling. Your VMware administrators continue working with familiar tools. Your applications see no change.

This is the fastest path out of on-premises VMware with the lowest operational disruption. It buys you time to then modernize individual workloads at a pace that works for your team, rather than forcing a big-bang migration.

Mainframe Modernization

Mainframe modernization is its own discipline, and AWS Transform has invested significantly in making it tractable. The challenge is that mainframe codebases, particularly COBOL applications, often contain decades of accumulated business logic that no living engineer fully understands. A direct rewrite approach almost always fails.

AWS Transform approaches mainframe modernization in six stages: code analysis, document generation, code decomposition, migration planning, code refactor (including automated COBOL to Java conversion), and deployment with Infrastructure as Code. The AI-powered analysis phase produces documentation of what the system actually does before anyone attempts to change it.

AWS Cloud Modernization: What Comes After Migration

Migration moves your workloads to AWS. Modernization changes how they work. The enterprises that unlock real cloud economics are the ones that do both. A workload running on a single EC2 instance, the same way it ran on-premises, has not gained elastic scaling, deployment velocity, or managed service economics. It has gained a monthly AWS bill.

Containerization: Amazon EKS and ECS

Containerization is the most common first modernization step for application workloads. Moving from virtual machines to containers gives you faster deployment cycles, significantly better resource utilization, and the ability to scale individual application components rather than entire servers.

Amazon EKS (Elastic Kubernetes Service) is the managed Kubernetes option. It handles the control plane, provides native AWS integrations for networking, security, and storage, and supports both EC2 worker nodes and AWS Fargate for serverless container execution. Fargate removes the need to manage underlying compute entirely: you define what you want to run, and AWS runs it.

Amazon ECS (Elastic Container Service) is the AWS-native container orchestration alternative. It has a simpler operational model and integrates tightly with the rest of the AWS ecosystem. For teams not already invested in Kubernetes, ECS is often the faster path to production.

Serverless: AWS Lambda and Event-Driven Architecture

With AWS Lambda, you write functions that execute in response to events. You pay only for the compute time your code actually uses. There is no infrastructure to manage, no capacity to provision, and no patching cycle.

The right workloads for Lambda are event-driven, stateless processes with variable load: API backends, data processing pipelines, automation and orchestration logic, and scheduled jobs. The practical approach for most enterprise applications is incremental decomposition: identify the components that fit an event-driven model and start there, rather than attempting a full monolith-to-serverless conversion in one step.

Database Modernization

The highest-impact database modernization move for most enterprises is migrating from commercial databases (Oracle, SQL Server) to AWS-managed open-source alternatives. Amazon Aurora gives you up to five times the throughput of standard PostgreSQL and three times MySQL performance, with multi-AZ replication, automated backups, and managed patching. Eliminating Oracle licensing alone delivers significant cost reduction.

For organizations not ready for a full engine change, Amazon RDS provides managed patching, automated backups, multi-AZ, and read replicas without any application changes. It is the Replatform strategy for databases and the right first step for many teams.

Agentic AI in AWS Cloud Migration and Modernization

The tooling landscape for migration and modernization has changed significantly in 2025 and 2026. AI agents are now handling phases of the migration lifecycle that previously required senior architects and months of manual effort. This is not an incremental improvement. It is a different way of running these programs.

–> AWS Transform AI Agents: ARA and MODA

Beyond portfolio assessment, AWS Transform now includes AI agents for two high-value phases of modernization:

Agentic Readiness Analysis (ARA): Evaluates whether your existing systems are safe to be called by AI agents. It examines APIs, identity and access patterns, state management, human-in-the-loop controls, and observability coverage. If you are planning to build AI-powered applications on your modernized infrastructure (and per Gartner, 40% of enterprise applications will incorporate AI agents by the end of 2026), ARA tells you exactly what needs to be addressed before those systems are exposed to an agent.

Modernization Analysis (MODA): Scans your codebase for cloud-native maturity gaps and maps every finding to a specific AWS modernization pathway. It identifies containerization candidates, serverless opportunities, and hidden dependencies that would complicate migration. It produces in hours what a senior architect would take weeks to produce manually, with more consistency.

–> Kiro: Spec-Driven Agentic Development

Kiro is Amazon’s agentic IDE, launched in 2026 as the evolution of Amazon Q Developer. It is built on Code OSS (the open-source base of VS Code) and introduces a structural requirement that most AI coding tools skip: it will not generate code until a formal specification exists.

When you start a feature or modernization task in Kiro, it runs a three-phase workflow before writing any code:

Requirements: Unpacks your prompt into structured user stories with EARS notation acceptance criteria. Assumptions are made explicit.
Design: Analyzes your codebase and generates data flow diagrams, interfaces, database schemas, and API endpoints based on your approved requirements.
Tasks: Sequences implementation tasks based on dependencies, links each to requirements, and includes unit tests, integration tests, and non-functional requirements. Nothing falls through the cracks.

Kiro also has hooks: event-driven automations that trigger when you save, create, or delete files. Update tests when a component changes, refresh API documentation when an endpoint is modified, scan for security issues before a commit. Once committed to Git, hooks run automatically for the entire team, enforcing standards consistently across every engineer.

For cloud modernization specifically, Kiro connects to official AWS MCP servers for real-time AWS documentation, current pricing, and infrastructure code generation. Assessment work that previously took weeks is being completed in days.

–> AWS MCP Servers

AWS has published an official ecosystem of Model Context Protocol (MCP) servers that give AI tools direct, real-time access to AWS services, documentation, and pricing. Key servers for modernization programs:

AWS Documentation MCP: Real-time access to current AWS documentation rather than training data that may be months out of date.
AWS Pricing MCP: Live cost modeling as you design architectures, so trade-off decisions happen at design time, not after deployment.
CDK MCP and Terraform MCP: Infrastructure code generation with built-in security scanning via CDK Nag and Checkov. Compliance checks run as part of code generation.
AWS Diagram MCP: Architecture diagram generation directly from code and service analysis.

AWS DevOps Agent: Operations After Migration

One thing migration programs consistently underestimate is post-migration operations. Workloads behave differently on AWS than they did on-premises. New failure modes emerge. The team that managed your data center is not always the team best equipped to operate your AWS environment.

AWS DevOps Agent, generally available since March 2026, addresses this directly. It is not a chatbot you ask questions to. When an alert fires, it begins investigating immediately, whether at 2 AM or during peak hours, without waiting for a human to start the process.

It connects to your observability tools (CloudWatch, Dynatrace, Datadog, Grafana, New Relic, Splunk), your code repositories (GitHub, GitLab, Azure DevOps), and your incident channels (Slack, ServiceNow, PagerDuty), then correlates telemetry, code changes, and deployment history simultaneously to identify root cause and recommend resolution steps.

Western Governors University reduced incident resolution time from two hours to 28 minutes on a production incident using AWS DevOps Agent, a 77% reduction. The agent surfaced the root cause in a Lambda configuration from internal documentation that the team had not found. United Airlines and T-Mobile are among the other enterprise adopters reporting meaningful MTTR improvements.

Beyond incident response, AWS DevOps Agent analyzes historical incident patterns and generates improvement recommendations across four areas: observability gaps, infrastructure optimization, deployment pipeline improvements, and application resilience. Each recommendation arrives as an agent-ready spec you can pass directly to Kiro for implementation.

For migration programs, the post-migration window is when teams are most exposed. AWS DevOps Agent gives you an experienced operations engineer watching your migrated environment from day one, not just during the period when your migration team is still engaged.

FinOps: Making the Economics Work: Managing AWS Cloud Migration Costs

Cloud economics only deliver if you actively manage them. The teams that see the promised savings are the ones that treat cost optimization as a continuous engineering discipline, not a quarterly finance review. The teams that do not often find their AWS bill is higher than their previous data center cost.

The most common causes:

Incorrect sizing: On-premises, you provision for peak. On AWS, you pay for what you run. Migrating a server that was 20% utilized to a comparable EC2 instance means paying full price for 80% wasted compute. AWS Compute Optimizer analyzes actual utilization and recommends right-sized instances. Savings Plans provide discounts of up to 72% for predictable workloads.

No cost allocation: Without a tagging strategy, you cannot see what is spending what. AWS Cost Explorer is only as useful as the tagging data behind it. Tagging must be part of migration design, not an afterthought.

Unmodelled data transfer costs: Applications that were co-located on-premises generate data transfer charges when spread across AWS services and availability zones. This is one of the most common bill surprises post-migration and one of the easiest to model in advance.

Non-production environments running 24/7: Dev and test environments do not need to run around the clock. Instance scheduling for non-production alone typically reduces cloud spend by 30 to 40%.

The AWS FinOps MCP Server

AWS has released a Billing and Cost Management MCP Server that connects your AI assistant directly to Cost Explorer, Compute Optimizer, Savings Plans, Budgets, and Cost Anomaly Detection. You ask in natural language, and it pulls real data from your account with specific, actionable answers. No custom scripts. No console navigation. No waiting for a monthly FinOps review to find out something went wrong three weeks ago.

Compliance and Data Sovereignty in MENA

Compliance requirements in the MENA region are more demanding than most global frameworks, and they have direct implications for how you design your AWS architecture. Treating them as a blocker rather than a design input is the most expensive mistake you can make in this region.

The right approach: compliance requirements tell you which data classification applies to which workload, which region it must reside in, which encryption standard applies, and which audit logs must be retained. That is your architecture brief. Design it from the start. Retrofitting compliance after migration is far more disruptive and expensive.

AWS has invested heavily in the MENA region. ME-CENTRAL-1 (UAE) and ME-SOUTH-1 (Bahrain) both support the full suite of compliance and sovereignty tools. AWS Control Tower provides multi-account governance with guardrails that enforce compliance policies at the organizational level. AWS Config and Security Hub provide continuous compliance monitoring with automated remediation. AWS Artifact gives you on-demand access to compliance reports for ISO 27001, PCI-DSS, SOC 2, and regional frameworks.

Migration Acceleration Program (MAP): Reduce Migration Cost and Risk

MAP is AWS’s funded program for enterprise migrations. It provides migration credits that offset program costs, AWS solutions architects and migration specialists assigned to your engagement, and partner support through Premier Partners like SUDO.

A well-structured MAP engagement can significantly reduce the total cost and risk of a migration program. The key is engaging it at the assessment phase, before you start moving workloads. MAP credits scale based on the size and complexity of your portfolio. Teams that engage MAP after they have already started migration consistently leave value on the table.

Assess phase: AWS-funded portfolio assessment and TCO analysis. This is typically where MAP engagement begins.
Mobilize phase: Credits, technical resources, and partner support for landing zone build, skills development, and pilot migrations.
Migrate and Modernize phase: Production migration credits and ongoing technical support through cutover.

SUDO: AWS Premier Partner for Cloud Migration in MENA

We have run migration and modernization programs across banking, retail, healthcare, logistics, and government sectors in the UAE, KSA, and Bahrain. Every engagement looks different. Every one of them has had at least one barrier from the list above. And everyone has taught us something that made the next one better.

As an AWS Premier Partner, our migration engagements typically cover:

Migration readiness assessment: Using AWS Transform for portfolio discovery, dependency mapping, and TCO analysis. We size your program before you commit to a timeline.

7Rs strategy assignment: Workload-by-workload strategy across your full application portfolio, with a clear rationale for each decision.

Landing zone design: AWS account structure, Control Tower setup, networking, and governance guardrails aligned to your compliance requirements.

Wave-based migration execution: Using AWS MGN and DMS, sequenced by the dependency map, not by what is easiest to move first.

Database migration and schema conversion: Strategy, tooling, and execution, including heterogeneous database modernization where applicable.

MAP engagement and credit management: We engage MAP on your behalf and structure the engagement to maximize the credits and technical support available.

Compliance architecture: UAE, KSA, and Bahrain regulatory requirements designed in from the start, not retrofitted.

Post-migration optimization: Right-sizing, tagging, cost governance, and AWS DevOps Agent onboarding for ongoing operational excellence.

Modernization roadmap: Containerization, serverless adoption, CI/CD pipeline build, and the agentic tooling (Kiro, AWS MCP servers) to accelerate delivery.

We do not run the same playbook for every customer and hope it fits. We start with a proper understanding of your portfolio, your team, your compliance obligations, and your business objectives, and we design a program built around your actual constraints.

Ready to Start Your Migration Program?

Talk to SUDO’s migration architects. We will tell you exactly where you are and what it will take to move.

Book a Free AWS Cloud Migration Assessment

View Our AWS Migration Services for MENA