Securing & Throttling Your APIs in AWS (Auth, WAF, Quotas) (Part - 4)
So far in this series, we have built fast HTTP APIs and real-time WebSocket APIs. But right now, we have a major problem: Our "front door" is wide open. Anyone on the internet can hit our API endpoint, run our backend code, and potentially run up a massive AWS bill.
Security in the cloud is a "shared responsibility" . AWS secures the physical servers and the network infrastructure, but you are responsible for deciding who is allowed to walk through your API's front door and what they are allowed to do once inside .
In this post, we will look at how to lock down your API Gateway using authentication, firewalls, and throttling rules.
The Bouncers: Authentication & Authorization
You wouldn't let just anyone walk into a private club without checking their ID. In API Gateway, you have a few different "bouncers" you can hire to check IDs before letting a request through .
Amazon Cognito (The Standard Bouncer) If you are building a mobile or web app where users need to log in with a username and password (or via Google/Facebook), Amazon Cognito is usually the best choice . When a user logs in, Cognito gives their app a digital token. When the app calls your API, it flashes this token. API Gateway automatically checks with Cognito: "Is this token valid? Did this user really log in?" If yes, the request goes through .
AWS IAM Roles (The VIP List) Sometimes, your API isn't meant for regular users. Maybe you have an internal AWS Lambda function or an EC2 server that needs to call your API. In this case, you use AWS Identity and Access Management (IAM) . Instead of passwords, you give your internal servers special IAM roles. API Gateway checks this VIP list. If the server calling the API isn't on the list, it gets blocked immediately .
Lambda Authorizers (The Custom Bouncer) What if you are already using a third-party login system like Auth0, or you have a weird, custom security requirement? You can write a Lambda Authorizer . This is simply a piece of custom code you write that runs before your actual API request. API Gateway hands the user's token (or headers) to your Lambda Authorizer. Your code inspects the data and returns a simple "Allow" or "Deny" .
The Security Guards: Firewalls and Policies
Checking IDs is great, but what if someone is trying to blow up the building? You need deeper security layers.
AWS WAF (Web Application Firewall)
If you chose to build a REST API (as we discussed in Part 2), you can attach AWS WAF directly to your API Gateway .
AWS WAF acts as a smart firewall that protects your API from common web exploits . If a hacker tries to send a malicious SQL injection attack or a flood of bot traffic, AWS WAF will intercept and block the request before it even reaches your API Gateway .
Resource Policies
Sometimes, you want to restrict access based on where the request is coming from, not just who is sending it. Resource Policies let you tell API Gateway: "Only allow requests if they come from this specific IP address, or from inside this specific private network (VPC)" . This is perfect for internal company APIs.
The Managers: Usage Plans & Throttling
Even legitimate users can crash your system if they send too many requests at once. To prevent your backend servers from melting (and your AWS bill from exploding), you need to set limits.
API Keys and Usage Plans
If you want to sell access to your API (like a weather data service) or limit how much third-party developers can use it, you can generate API Keys .
You group these keys into Usage Plans . For example:
Basic Plan: The user's API Key allows 1,000 requests per month.
Pro Plan: The user's API Key allows 10,000 requests per month .
Once a user hits their limit, API Gateway automatically blocks them with a "Too Many Requests" error .
Throttling and Burst Limits
What if a user tries to send all 1,000 of their monthly requests in a single second? That spike could crash your database.
API Gateway allows you to set Rate Limits (how many steady requests per second are allowed) and Burst Limits (how many sudden, simultaneous requests are allowed). This ensures smooth, predictable traffic flow to your backend servers.
What's Next in the Series?
Now our API is fast, supports real-time communication, and is locked down tight. But what happens when we need to release a new version of our API without breaking the old one? Or what if we want our API to live at api.mycoolstartup.com instead of a random, ugly AWS URL?
In Part 5: Data Mapping, Custom Domains & Deployments, we will look at how to transform data on the fly and how to launch your API into production like a pro.
