Back to Blog
Lesson 22 of the AWS: AWS Core Services for Developers course
Cloud NativeJuly 29, 20264 min read

Securing APIs with API Keys: A Practical AWS Guide

Learn how to implement API Security by requiring API keys and configuring usage plans in Amazon API Gateway to protect your serverless backend.

AWSAPI GatewayAPI SecurityServerlessCloud Native
A beekeeper in a bright suit checking hives outdoors, ensuring bee health and productivity.

Previously in this course, we covered API Gateway Routing and Integration to connect your frontend to your backend logic. Now that your API is routing traffic, it’s time to restrict that access.

In the early stages of building a public-facing API, you need a mechanism to identify who is calling your service and to prevent anonymous abuse. While robust identity providers are the gold standard for user authentication—as discussed in REST API Authentication: Choosing Between Bearer Tokens and API KeysAPI Keys provide a lightweight, administrative layer of security perfect for internal tools or controlled third-party access.

Understanding API Security with Keys and Usage Plans

When you require an API key, you are essentially asking the client to present a "password" in the HTTP header of every request. If the key is missing or invalid, API Gateway rejects the request before it ever reaches your Lambda function.

To manage these keys, we use Usage Plans. A usage plan acts as a policy wrapper. It defines:

  1. Which API stages require the key.
  2. How many requests a specific key holder can make (throttling).
  3. The quota of total requests allowed over a specific period.

Think of it like a subscription model: you issue a unique key to a client, and the usage plan enforces the "terms of service" for that key.

The Lifecycle of an API Key

To implement this, we follow a three-step workflow in the AWS Console:

  1. Create the API Key: A unique, cryptographically strong string generated by AWS.
  2. Create the Usage Plan: Define the limits (e.g., 100 requests per second).
  3. Associate and Deploy: Link the key to the plan and ensure the API method is configured to "Require API Key."

Worked Example: Implementing Key-Based Access

A mysterious scene of keys floating above an open hand against a dark background.

Let’s secure a hypothetical /data endpoint.

1. Enable Key Requirement

In your API Gateway console, navigate to the Resources tab. Select your method (e.g., GET /data), click Method Request, and set API Key Required to true.

Note: You must redeploy your API to a Stage for this change to take effect.

2. Create the API Key

Navigate to the API Keys section in the left-hand menu of API Gateway.

  • Click Create API Key.
  • Give it a name (e.g., Client-App-Key).
  • Choose "Auto-generate" for the key value and hit Save.

3. Configure the Usage Plan

Go to the Usage Plans section:

  • Click Create. Name it Standard-Plan.
  • Set the Throttling (e.g., Rate: 10, Burst: 20).
  • Under Associated API Stages, click Add API Stage. Select your API and your deployed stage (e.g., prod).
  • Once saved, click the API Keys tab inside the usage plan and select Add API Key to Usage Plan. Choose the Client-App-Key we created earlier.

Testing the Implementation

When you try to call your endpoint via curl or Postman, you will now receive a 403 Forbidden error. To succeed, you must include the key in your header:

Bash
curl -X GET https://api-id.execute-api.region.amazonaws.com/prod/data \
  -H "x-api-key: YOUR_GENERATED_API_KEY_HERE"

Hands-on Exercise

  1. Navigate to your existing API Gateway project.
  2. Enable the "API Key Required" setting on one of your GET methods.
  3. Deploy the API to your existing stage.
  4. Attempt to hit the URL without a key to confirm you get a 403.
  5. Create a Usage Plan and an API Key, associate them, and make a successful authenticated request using the header shown above.

Common Pitfalls

  • Deployment Lag: The most common mistake is forgetting to redeploy the API after changing the "API Key Required" setting. Changes to method settings are not live until a deployment occurs.
  • Header Mismatch: The default header name is x-api-key. Ensure your client-side code is passing this specific header name.
  • Over-reliance: Remember that API keys are not a replacement for proper user authentication. They are easily intercepted if not used over HTTPS. As noted in Advanced Sanitization Techniques: Securing WordPress REST API Data, always assume the client side is untrusted; never put sensitive business logic on the client just because you have an API key.

FAQ

Q: Can I use API keys for user authentication? A: No. API keys identify the application or client, not the individual user. Use them for service-to-service communication or to manage rate limits for specific partners.

Q: If I lose my API Key, can I recover it? A: No. AWS displays the key value once. If you lose it, you must generate a new one and update your clients.

Q: Do API Keys cost money? A: API Keys themselves are free, but they are a feature of API Gateway, which has its own pricing based on request volume.

Recap

Team members presenting a project in a modern office setting with a focus on collaboration.

By requiring an API key and mapping it to a usage plan, you gain granular control over who accesses your API and how much traffic they can consume. This is the first step toward professionalizing your API infrastructure.

Up next: Project Integration: Exposing the API where we will move these manual configurations into our infrastructure-as-code setup.

Similar Posts