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.
Top comments (0)