AWS API Gateway security is one of the most frequently tested interview topics, and also one where engineers make dangerous mistakes. Most default to “just use Cognito” without understanding IAM auth, Lambda authorizers, or rate limiting. That answer will cost you the job.
This guide cuts through the noise. By the end, you’ll know exactly which authentication mechanism to use when, how to implement rate limiting, and how to explain it confidently in any interview.
Quick Answer: API Gateway Security at a Glance
| Auth Method | Use Case | Caller Type | Implementation Effort |
|---|---|---|---|
| IAM Auth | Service-to-service within AWS | AWS principals (roles, users) | Low |
| Cognito | User-facing APIs with sign-up/login | End users, web/mobile clients | Medium |
| Lambda Authorizer | Custom auth logic, external identity providers | Any, custom validation | High |
| API Keys | Rate limiting only (not authentication) | Public API consumers | Low |
| mTLS | Certificate-based auth, service-to-service | Clients with certificates | High |
What is AWS API Gateway Security?
AWS API Gateway is the entry point for all client requests to backend services. Securing API Gateway requires multiple layers: authentication (who are you), authorization (what are you allowed to do), encryption (protect data in transit), rate limiting (prevent abuse), and network isolation (restrict access). Security is not a single control but a defense-in-depth strategy.
The biggest mistake I see in interviews is treating API Gateway security as authentication alone. It’s not. Authentication verifies identity, but you also need authorization rules, encryption, rate limiting, and network isolation. A complete answer touches all five layers.
API Gateway Security: 5 Practices That Actually Matter in Interviews
1. IAM Authentication for Service-to-Service Communication
IAM authentication is the strongest option for internal service-to-service communication where all callers are AWS principals. The caller signs the API request with their AWS access key and secret key using AWS Signature Version 4. API Gateway validates the signature and checks that the signing credentials have permission to invoke the API. This ensures only authorized AWS principals can call the API.
I use IAM authentication for APIs consumed by Lambda functions, EC2 instances running in the same account, and other AWS services. It requires no external identity provider, no tokens to manage, and no user credentials to distribute. The caller’s IAM role is the identity, and policy is the authorization. This is seamless because all AWS services understand IAM.
Interview tip: Say “IAM auth is native to AWS and requires no extra infrastructure. It’s perfect for service-to-service APIs within the same account where all callers are AWS principals.” This shows understanding of when to use IAM authentication and why it’s simpler than alternatives.
2. Cognito User Pools vs Lambda Authorizers
Cognito user pools are managed identity providers that handle user authentication for you. Users sign up, confirm their email, and log in through Cognito’s hosted UI or custom client app. Cognito issues ID tokens and access tokens in JWT format. API Gateway validates these tokens and extracts claims, passing them to your backend. Cognito handles password policies, multi-factor authentication, and session management, offloading authentication complexity from your backend.
Lambda authorizers provide maximum flexibility. API Gateway invokes a Lambda function on every request, passing the request context. The Lambda function implements custom authentication logic and returns an authorization decision. You can validate API keys against a database, call external identity providers, or implement custom token validation. The flexibility comes at the cost of additional Lambda invocations per request, which increases latency and cost.
I use Cognito for user-facing APIs where users need sign-up and login. I use Lambda authorizers when Cognito doesn’t fit, like when integrating with an external identity provider or implementing custom token validation logic. The rule of thumb is Cognito first, Lambda authorizers as a fallback when Cognito constraints are limiting.
3. Usage Plans and Rate Limiting per API Key
API Gateway throttles all requests at the account level: 10,000 requests per second across all APIs in a region. For additional granularity, usage plans allow you to define per-API-key throttling limits. A usage plan associates one or more API stages with API keys and defines rate limits for each key. You might create a standard plan with 100 requests per second and a premium plan with 1,000 requests per second. Clients include an API key in requests, and API Gateway enforces the associated limits.
API keys alone are not authentication. They’re opaque identifiers that enable rate limiting and usage tracking. Many engineers mistakenly treat API keys as security. They’re not. A security model based on API keys alone allows anyone who knows the key to call your API. Always combine API keys with a real authentication method like Cognito or Lambda authorizers.
Interview tip: Say “API keys enable per-client rate limiting, not authentication. Always combine them with Cognito or IAM auth to create a complete security model.” This shows you understand the difference and avoid the common mistake of treating API keys as security.
4. WAF Integration for DDoS and Injection Protection
AWS WAF protects API Gateway from DDoS attacks and injection attacks like SQL injection and cross-site scripting (XSS). WAF rules inspect requests and block those matching attack patterns. You can create rate-based rules that block IPs making more than a threshold number of requests in a short time window, adding another layer of rate limiting on top of usage plans. AWS also offers Shield Standard, which provides free DDoS protection for all AWS customers, and Shield Advanced, which adds more aggressive DDoS mitigation.
I attach WAF to API Gateway to protect against application-layer attacks. Rate-based WAF rules block IPs making unusual numbers of requests, catching bot attacks. Custom WAF rules can block requests with suspicious patterns in headers or parameters. This is especially important for public APIs where you cannot trust the caller’s intent.
One detail many engineers miss: WAF rules have false positive risk. If your WAF rule is too aggressive, it blocks legitimate traffic. Test WAF rules in count mode before enabling them in block mode. Monitor CloudWatch metrics to ensure legitimate traffic isn’t being blocked.
5. VPC Link and Resource Policies for Network Isolation
VPC Link creates a private connection between API Gateway and backend services running in a VPC. Instead of exposing backend load balancers to the internet, you create a VPC Link endpoint. API Gateway forwards requests through the VPC Link to the backend network load balancer. This keeps backend services off the public internet, accessible only through API Gateway. Traffic through VPC Link stays within AWS’s internal network.
Resource policies on API Gateway restrict who can invoke the API. You can write a policy that only allows requests from a specific VPC endpoint, a specific AWS account, or an IP address range. For example, you might restrict access to requests originating from your corporate VPN. This creates a network-level boundary that prevents external callers from reaching your API, even if they obtained valid authentication credentials.
Combining VPC Link and resource policies creates highly isolated architecture. Backend services aren’t exposed to the internet. API Gateway is accessible only from authorized sources. Requests between API Gateway and backends traverse private network connections. This is appropriate for APIs handling sensitive data or supporting critical business functions.
When to Use Each Authentication Method
Use IAM Auth when:
- All API callers are AWS principals (roles, users, services)
- You’re building internal service-to-service APIs
- You want the strongest security with no external dependencies
- You don’t need to manage tokens or credentials
Use Cognito when:
- You have user-facing APIs with sign-up and login
- You want user authentication without building it yourself
- You need features like multi-factor authentication
- You want a managed identity provider
Use Lambda Authorizers when:
- Your authentication logic doesn’t fit Cognito or IAM
- You need custom validation or external identity provider integration
- You’re willing to accept the latency of per-request Lambda invocations
- You need to implement authorization logic beyond authentication
Use WAF when:
- You need DDoS and injection attack protection
- You’re exposing APIs to the public internet
- You want rate limiting at the WAF level in addition to usage plans
- You need to block requests matching specific patterns
Use VPC Link when:
- You want to keep backend services off the public internet
- You’re handling sensitive data and need network isolation
- You want traffic between API Gateway and backends to stay private
Example Interview Answer
Here’s how to answer “How would you secure an API Gateway deployed on AWS?”
Watch a real Senior AWS DevOps Engineer explain API security in a mock interview:
“I secure API Gateway through multiple layers: authentication, authorization, encryption, rate limiting, and network isolation. The authentication mechanism depends on the caller type. For internal service-to-service APIs, I use IAM authentication where the caller signs the request with AWS credentials. API Gateway validates the signature and checks IAM permissions.
For user-facing APIs, I use Cognito user pools. Cognito handles user registration, login, and token issuance. Clients authenticate with Cognito, receive a JWT, and include it in API Gateway requests. API Gateway validates the token before forwarding the request. This offloads authentication complexity from my backend.
For APIs with custom authentication requirements, I use Lambda authorizers. A Lambda function runs on every request and implements custom validation logic. This is flexible but adds latency, so I use it only when Cognito and IAM don’t fit.
For rate limiting, I use usage plans to define per-API-key throttling limits. Different clients get different rate limits based on their subscription tier. Combined with WAF, I can block DDoS attacks and injection attempts at the WAF level before traffic even reaches my backend.
For encryption, I enforce HTTPS by disabling HTTP listeners. All communication between clients and API Gateway uses TLS. For network isolation, I use VPC Link to route traffic to backend services over private network connections, keeping infrastructure off the public internet. I combine VPC Link with resource policies that restrict access to specific VPC endpoints.
The philosophy is defense-in-depth. Authentication, encryption, rate limiting, and network isolation work together to create a secure API.”
Common Mistakes to Avoid
Using API keys as authentication. API keys enable rate limiting, not authentication. They’re opaque identifiers that anyone who knows them can use. Always combine API keys with real authentication like Cognito or IAM auth.
Choosing Lambda authorizers without justifying the latency. Lambda authorizers add per-request latency because API Gateway invokes Lambda on every call. Use them only when Cognito and IAM don’t fit your requirements. Otherwise, the latency is unjustified.
Forgetting about network isolation. A fully authenticated and encrypted API can still be exposed to the public internet. Use VPC Link to keep backend services private and resource policies to restrict who can invoke the API. Authentication and network isolation work together.
Enabling WAF without testing. Overly aggressive WAF rules block legitimate traffic, causing customer-facing outages. Test rules in count mode first, monitor metrics, then enable in block mode.
Key Takeaway
API Gateway security comes down to defense-in-depth: authentication verifies who the caller is, rate limiting prevents abuse, WAF protects against attacks, encryption protects data in transit, and network isolation keeps backends private. The right combination depends on your caller types and security requirements. Being able to explain these layers and their interactions is exactly what interviewers are listening for. These controls pair naturally with understanding the broader choice between ALB vs API Gateway for hosting APIs, the AWS IAM least privilege patterns used for authorisation, and the security pillar of the AWS Well-Architected Framework.
