The pitch for a managed API gateway is easy to make: no clusters to run, no patches to schedule, automatic scaling, and a per-call pricing model that is transparently low at modest volumes. AWS API Gateway fits that description. What the pitch tends to understate is that “managed” means AWS manages the infrastructure — the compute, the TLS certificates for the gateway itself, the availability zones. The security posture of the gateway — which traffic is allowed in, how callers are authenticated, which WAF rules are enforced, where the audit logs go — remains entirely your responsibility. Getting those decisions wrong does not produce a P1 incident immediately; it produces a finding in the next SAMA security review.
A managed service eliminates operational overhead. It does not eliminate security responsibility. The shared responsibility model means your team still owns the configuration layer — and that layer is where regulated-environment risk concentrates.
The shared responsibility question no one asks at the design review
AWS’s shared responsibility model is well-understood at the infrastructure level. What is less often examined at the design review is what happens at the API Gateway configuration layer. AWS is responsible for the availability and patching of the gateway service itself. You are responsible for: the WAF rules that filter inbound traffic, the custom authoriser that validates caller identity, the VPC link configuration that keeps your backend services off the public internet, the mTLS truststore that specifies which partner certificates to accept, and the access log format that provides the audit trail your CISO needs. Each of these has a default state that is not a secure production configuration. The default WAF state is “no WAF.” The default authoriser state is “no authentication.” The default access log state is “no logging.” Approving a deployment without these in place is approving an exposure.
What SAMA’s review specifically looks for
SAMA’s Cyber Security Framework (CSF) and Open Banking Technical Standards reference the API boundary as a regulated enforcement point. When an architecture review covers an AWS-hosted API, the questions surface in four areas. Data residency: is all customer data — in transit and at rest — confined to the Bahrain (me-south-1) or UAE (me-central-1) region? API Gateway regional endpoints in those regions keep data in-region, but CloudWatch Logs and S3 buckets for audit logs must also be explicitly pinned to the same region with no cross-region replication outside the GCC footprint. Authentication and non-repudiation: can you demonstrate, for any given API call, who made it, with what credential, and when? The Lambda authoriser and access log configuration are what provide this evidence. Encryption in transit: SAMA CSF requires TLS 1.2 minimum for all external connections. AWS API Gateway defaults to TLS 1.0 on legacy custom domain configurations; the security_policy field must be explicitly set to TLS_1_2. Vulnerability scanning: the WAF must be active and its rules must cover OWASP Top 10 at minimum. The AWS Managed Rules Common Rule Set satisfies this requirement, but it must be in enforce mode (not count mode) before go-live.
The vendor lock-in question for the board
SAMA’s IT Governance Framework explicitly identifies cloud provider concentration risk as something institutions must manage. This is not abstract: if AWS API Gateway becomes mission-critical for Open Banking partner connectivity and your institution subsequently needs to move to a different cloud or back to on-premises, the migration cost is real. API Gateway VTL mapping templates, the Lambda authoriser code, the custom domain configuration, and the WAF rule sets are all AWS-specific constructs. They do not port to Kong, IBM API Connect, or Azure API Management without a rewrite. The practical question for the board is not “are we locked in” — we are, to some degree, with any technology choice — but “is the lock-in proportionate to the value delivered?” For a greenfield cloud-native programme on AWS, the answer is almost certainly yes. For an institution with a significant on-premises investment and a hybrid-cloud strategy, the answer is worth examining before the architecture is committed.
The cost model at scale
API Gateway’s pricing is per-call plus data transfer. At 100 million API calls per month in me-south-1, the gateway cost is approximately SAR 1,300–1,600 per month for REST API. That is low. What grows with call volume are the components around the gateway: CloudWatch Logs ingestion and storage (which can exceed the gateway cost at high volume if log verbosity is unconstrained), Lambda invocations for the authoriser (a cost that grows with unique callers unless caching is configured), and WAF charges (per-rule evaluation, per million requests). Build a 12-month cost model that includes all four components before committing to the architecture — the headline gateway price understates the total by 40–60% at high volume with a full security stack enabled.
What the platform team needs from leadership to ship this correctly
There are four enablers that determine whether the team can configure AWS API Gateway correctly for a regulated environment, none of which are technical. An IaC-first mandate. The gateway configuration, WAF rules, Lambda authoriser code, and VPC link definition must all be in Terraform or CloudFormation and deployed through a CI/CD pipeline. Console changes are invisible to the change management process that the audit expects. This requires a policy decision from leadership, not a technical decision from the team. A CISO sign-off process for WAF rule changes. Every WAF rule exclusion (and there will be legitimate ones — ISO 20022 payloads routinely trigger size rules) must go through a security review. The team needs a lightweight process for this that does not create a bottleneck; absent one, teams start making exclusions without oversight. Access log retention and SIEM integration from day one. The audit log pipeline — CloudWatch Logs to Kinesis to S3 to SIEM — must be in place before the first production call, not added later. Retrofitting a log pipeline to an existing gateway is operationally disruptive and leaves a gap period in the audit trail that is difficult to explain to a regulator. A partner certificate rotation workflow. mTLS is only as strong as the process for rotating partner certificates before they expire. Build the rotation workflow and the expiry monitoring into the partner onboarding runbook before the first partner goes live. A certificate that expires because no one tracked the NotAfter field is a service outage, not a minor oversight.
The institutions that run AWS API Gateway well in regulated environments are not the ones that deployed it fastest. They are the ones where the CISO, CTO, and platform lead aligned on the configuration standards before the first deployment, treated the gateway as a regulated component rather than a utility, and staffed the IaC and security-policy work explicitly rather than leaving it to whoever had spare capacity. The service is excellent. The organisational discipline is what determines whether the configuration that surrounds it holds up when the examiner asks for evidence.
For the technical depth behind these decisions — VPC private integrations, WAF rule configuration, Lambda authoriser design, mTLS truststore management, and the comparison with Kong and IBM API Connect — see the companion Lab article: AWS API Gateway for Regulated Workloads: VPC Integration, WAF & Custom Authorisers.