December 18, 2025 · 5 min read · devopssaudi.com

Building Cloud-Native on AWS in Saudi Arabia: NCA Compliance and PDPL Data Residency

A technical guide to building cloud-native infrastructure on AWS Middle East (Riyadh) - Saudi NCA compliance, PDPL data residency requirements, and Terraform patterns for the Kingdom.

Building Cloud-Native on AWS in Saudi Arabia: NCA Compliance and PDPL Data Residency

AWS launched its Middle East (Riyadh) region (me-central-1) in 2022 with three availability zones, making it the primary cloud platform for Saudi organisations with data residency requirements. For engineering teams building cloud-native applications in the Kingdom, this region - combined with NCA Essential Cybersecurity Controls and PDPL data residency - defines the infrastructure architecture.

AWS Middle East (Riyadh): What You Get

The me-central-1 region provides three availability zones with the full AWS service catalogue relevant to cloud-native workloads: EC2 (including GPU instances for AI workloads), EKS (managed Kubernetes), RDS (managed databases), S3 (object storage), Lambda (serverless), and the supporting services (CloudTrail, GuardDuty, KMS, IAM Identity Center).

For Saudi organisations, this region is the default choice for any workload processing personal data of Saudi residents. PDPL data residency requirements effectively mandate in-Kingdom infrastructure for personal data processing - and AWS Riyadh is the most mature option.

AWS Bahrain (me-south-1) provides the disaster recovery target - close enough for low-latency replication, far enough for geographic separation. A Riyadh-primary, Bahrain-DR architecture satisfies both PDPL residency (primary processing in-Kingdom) and business continuity requirements.

Saudi NCA Data Residency: What Actually Stays In-Country

The NCA and PDPL create specific requirements for data handling, but the rules are more nuanced than “everything must stay in Saudi Arabia.” Understanding what data must remain in-Kingdom versus what can be processed internationally is critical for cost-effective architecture:

Must stay in Saudi Arabia: Personal data of Saudi residents (names, national ID numbers, contact information, financial data, health data). This means primary databases, backup storage, and any processing pipeline that handles this data must run on Saudi-hosted infrastructure.

Can be processed internationally (with conditions): Anonymised or aggregated data, public data, data from non-Saudi residents (with appropriate consent), and non-personal operational data. Cross-border transfer is permitted under PDPL Article 29 with adequate safeguards.

Practical implication: Not every service needs to run in me-central-1. A microservices architecture can route personal data workloads to AWS Riyadh while running non-personal workloads (content delivery, analytics on anonymised data, internal tools) in other regions where capacity is cheaper and more available.

Terraform Patterns for NCA-Compliant Infrastructure

NCA ECC controls translate directly to Terraform configurations. Here are the key patterns:

Encrypted Storage (ECC Control 2-6-1)

All storage must be encrypted at rest. In Terraform, this means KMS keys for every storage service:

  • S3 buckets with server_side_encryption_configuration using customer-managed KMS keys
  • EBS volumes with encrypted = true and KMS key specification
  • RDS instances with storage_encrypted = true and kms_key_id
  • EKS secrets encrypted with envelope encryption using a customer-managed KMS key

Audit Logging (ECC Control 2-8-1)

CloudTrail must be enabled organisation-wide, logging all management events and data events for sensitive services:

  • CloudTrail with is_multi_region_trail = true (within the me-central-1 region account)
  • S3 access logging enabled for all buckets containing sensitive data
  • RDS audit logging enabled with CloudWatch Logs export
  • VPC Flow Logs enabled for all VPCs with CloudWatch or S3 destination

Network Segmentation (ECC Control 2-4-1)

VPC design must implement proper network segmentation:

  • Public subnets for load balancers only - no direct internet access to application or database tiers
  • Private subnets for application workloads with NAT gateway for outbound access
  • Isolated subnets for databases with no internet access (inbound or outbound)
  • Security groups following least-privilege: explicit allow rules, deny-all default
  • Network ACLs as an additional defence layer at the subnet boundary

Access Control (ECC Control 2-3-1)

IAM policies must follow least-privilege principles:

  • IAM Identity Center (SSO) for human access with MFA enforced
  • IAM roles for service-to-service access (no long-lived credentials)
  • Service control policies (SCPs) to prevent accidental use of non-Saudi regions for sensitive workloads
  • Permission boundaries for developer-created IAM roles

Multi-Region Architecture: Riyadh + Bahrain

A production architecture for Saudi workloads typically uses:

  • Primary: me-central-1 (Riyadh) - all production workloads, primary databases, application services
  • DR: me-south-1 (Bahrain) - standby infrastructure, database replicas, S3 cross-region replication

The DR architecture depends on your recovery objectives:

  • Pilot light: Database replicas running in Bahrain, application infrastructure defined in Terraform but not running. RTO: 30-60 minutes. Cost: low (database replication + S3 storage only).
  • Warm standby: Scaled-down application running in Bahrain behind a Route 53 health check. RTO: 5-15 minutes. Cost: moderate.
  • Active-active: Full application running in both regions with Route 53 latency-based routing. RTO: near-zero. Cost: approximately 2x.

For most Saudi workloads, pilot light or warm standby provides the best balance of cost and recovery time. Active-active is reserved for payment-critical systems where any downtime has immediate financial impact.

SDAIA Data Governance Overlay

For organisations working with AI and data-intensive workloads, SDAIA’s National Data Management Office adds governance requirements beyond PDPL:

  • Data cataloguing: All data assets must be catalogued with ownership, classification, and retention policies
  • Data lineage: Processing pipelines must track where data came from, how it was transformed, and where it went
  • Access governance: Data access must be role-based, logged, and reviewable

In AWS, these translate to: AWS Glue Data Catalog for data cataloguing, CloudTrail + custom logging for data lineage, and Lake Formation for access governance. Terraform modules can enforce these controls across all data workloads.

Getting Started

Building cloud-native infrastructure in Saudi Arabia requires understanding the intersection of cloud architecture, NCA compliance, and PDPL data residency. Getting it right from the start is dramatically cheaper than retrofitting compliance later.

devopssaudi.com designs and implements NCA-compliant cloud infrastructure on AWS Middle East (Riyadh) using Terraform. Book a free 30-minute consultation - we’ll review your current infrastructure against NCA ECC controls and identify the gaps.

Get Started for Free

Schedule a free consultation. 30-minute call, actionable results in days.

Talk to an Expert