Protect and Manage a REST API

Secure a REST API with request validation, a Lambda authorizer, and rate limiting.

Introduction

30 Second Summary

When you deploy an API, the default state is wide open. Anyone on the internet can call it with any data they want, and your backend has no choice but to deal with it.

In this project, you will build a REST API on AWS and lock it down with request validation, a custom authorizer, and per-client rate limiting. By the end, only authorized clients with valid API keys can call your API, and only with properly structured data.

What You'll Build

Send garbage data, a bad token, or a flood of requests to your API and watch API Gateway block each one at the gate while your Lambda function stays completely untouched.

By the end of this project, you'll have:

  • Request validation powered by a JSON Schema model that automatically rejects malformed pet data at the gateway level. Send a pet with a price of 4000 and watch it bounce back with a 400 error before your Lambda function ever runs.
  • A Lambda authorizer that checks bearer tokens and returns Allow or Deny IAM policies. Unauthorized callers get a 403 Forbidden response.
  • Usage plans with API keys and throttling that cap each client at 5 requests per second and 100 per day. Flood your endpoint and watch it return 429 Too Many Requests.
  • Secret Mission: Create a premium usage plan tier with higher rate limits and its own API key, just like real API providers offer multi-tier access.

Do I need prior experience with APIs?

This project assumes a basic understanding of APIs and HTTP methods. Prior experience building a CRUD API with API Gateway is helpful but not required.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Create a REST API with a Lambda Backend

Every API management feature you add in this project sits on top of a working API. Before you can validate requests, authorize callers, or throttle traffic, you need a live endpoint that accepts requests and returns responses.

In this step, you create a Lambda function that handles pet data, wire it up to a REST API in API Gateway, and call it with curl to prove it works.

In this step, get ready to:
  • Create a Lambda function that returns and stores pet data.
  • Build a REST API with GET and POST methods connected to your function.
  • Test the API with curl and discover the problem with unvalidated requests.
Create a Lambda function in the AWS Console

Your API needs a backend to process requests. A Lambda function handles the logic without you managing any servers.

  • Open the Lambda console at https://console.aws.amazon.com/lambda.
  • Click Create function.
  • Select Author from scratch.
  • For Function name, enter PetStoreFunction.
  • For Runtime, choose Node.js 22.x or the latest available Node.js version.
  • Leave all other settings at their defaults and click Create function.

Lambda creates a default index.mjs file with a Hello World handler. You will replace this with your pet store code.

  • In the code editor on the Code tab, select all the existing code in index.mjs and delete it.
  • Paste in the pet data and the GET handler by copying this code:
// Sample pet data stored in memory
const pets = [
  { id: 1, type: "dog", name: "Rex", price: 250 },
  { id: 2, type: "cat", name: "Whiskers", price: 100 },
  { id: 3, type: "fish", name: "Nemo", price: 30 },
];

// Lambda handler - entry point for API Gateway requests
export const handler = async (event) => {
  // Extract the HTTP method from the API Gateway event
  const method = event.httpMethod;

  // Return the full pet list for GET requests
  if (method === "GET") {
    return {
      statusCode: 200,
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(pets),
    };
  }

What does this code do?

The pets array is a simple in-memory data store with three sample pets. Each pet has an id, type, name, and price.

The handler function reads event.httpMethod to decide what to do. For GET requests, it returns the full pet list as JSON. You will add the POST handler next.

  • Place your cursor at the end of the code you just pasted and add the POST handler and fallback directly below:
  // Parse the body and add a new pet for POST requests
  if (method === "POST") {
    const body = JSON.parse(event.body);
    const newPet = {
      id: pets.length + 1,
      type: body.type,
      name: body.name,
      price: body.price,
    };
    pets.push(newPet);
    return {
      statusCode: 200,
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        message: "Pet added successfully",
        pet: newPet,
      }),
    };
  }

  // Reject any other HTTP methods
  return {
    statusCode: 400,
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ message: "Unsupported method" }),
  };
};

What does the POST handler do?

When a POST request arrives, the handler parses the JSON body, builds a new pet object, and pushes it into the pets array. It returns a success message with the newly created pet.

The fallback return at the bottom catches any HTTP method that is not GET or POST and returns a 400 error.

  • In the DEPLOY section of the code editor, click Deploy.

You should see a green banner confirming the function was updated successfully.

Don't see the Deploy button?

Make sure you are on the Code tab of your function. The Deploy button appears in the DEPLOY section above the code editor.

If the button is greyed out, you may not have made any changes to the code. Try selecting all and re-pasting the code.

Why can't I deploy my Lambda function?

✔️ Awesome, I've got everything!

Great. Make sure you have saved and deployed your function before moving on.

ⓧ I'd like to double check the full code

Scroll up and confirm you have both code blocks pasted into index.mjs in order:

  • The pets array and the GET handler (starting with const pets = [).
  • The POST handler and fallback (starting with if (method === "POST"), ending with };).

The complete function should start with const pets = [ and end with }; closing the handler. Make sure there are no duplicate lines or missing closing braces.

Create a REST API and integrate it with your Lambda function

Now you need a public URL that routes HTTP requests to your Lambda function. API Gateway creates that URL and maps specific HTTP methods to your function.

  • Open the API Gateway console at https://console.aws.amazon.com/apigateway.
  • Find the REST API card and click Build.
  • For API name, enter PetStoreAPI.
  • Keep API endpoint type set to Regional.
  • For IP address type, select IPv4.
  • Click Create API.

What is a REST API vs an HTTP API?

API Gateway offers two types. REST APIs support request validation, usage plans with API keys, per-client throttling, and Lambda authorizers. HTTP APIs are simpler but do not support any of those features.

You are using a REST API because every management feature in this project depends on it.

You now see the Resources tree with just the root resource (/). Next you create a /pets resource under it.

  • Click Create resource.
  • Keep Proxy resource turned off.
  • Keep Resource path as /.
  • For Resource name, enter pets.
  • Keep CORS (Cross Origin Resource Sharing) turned off.
  • Click Create resource.

The /pets resource appears in the tree. Now you connect it to your Lambda function by creating a POST method.

  • Select the /pets resource in the tree, then click Create method.
  • For Method type, select POST.
  • For Integration type, select Lambda function.
  • Turn on Lambda proxy integration.
  • For Lambda function, enter PetStoreFunction and select it from the dropdown.
  • Click Create method.

What is Lambda proxy integration?

With Lambda proxy integration, API Gateway passes the entire incoming request straight to your Lambda function as an event object. Your function reads the HTTP method, headers, and body directly from that event and returns a response in a specific format: statusCode, headers, and body.

If a popup asks you to add permission for API Gateway to invoke your Lambda function, click OK. This grants the required permission automatically.

  • Repeat the process to create a GET method. Select the /pets resource and click Create method.
  • For Method type, select GET.
  • For Integration type, select Lambda function.
  • Turn on Lambda proxy integration.
  • For Lambda function, enter PetStoreFunction and select it.
  • Click Create method.

Your /pets resource now shows both GET and POST methods in the Resources tree. Time to make this API accessible over the internet by deploying it.

  • Click Deploy API.
  • For Stage, select New stage.
  • For Stage name, enter test.
  • Click Deploy.

You should see the stage details page with an Invoke URL displayed at the top. This is your API's live public address.

  • Copy the Invoke URL and save it. You will use it for every test in the rest of this project: your invoke URL

What does the invoke URL look like?

Your URL follows the format https://{api-id}.execute-api.{region}.amazonaws.com/test. The api-id and region are unique to your setup.

Don't see the Invoke URL?

Make sure you clicked Deploy after selecting the stage. If the deployment succeeded, click Stages in the left navigation, then select the test stage to see the URL.

Help me find my API Gateway invoke URL

Test your open API with curl

Your API is live. Time to call it from your terminal and confirm that Lambda is processing requests.

  • Open your terminal.
  • Fetch the pet list by running this GET request:
curl [[INVOKE_URL="your invoke URL"]]/pets

You should see the JSON array of three pets: Rex, Whiskers, and Nemo.

Seeing a 'Missing Authentication Token' error?

Make sure your URL ends with /pets (not just the base URL). The base URL without a resource path returns this error because no method is configured on the root / resource.

Also confirm you copied the full invoke URL, including https:// at the start and /test at the end.

Help me troubleshoot my curl request to API Gateway

  • Now test adding a pet by running a POST request with valid data:
curl -X POST [[INVOKE_URL="your invoke URL"]]/pets \
  -H "Content-Type: application/json" \
  -d '{"name": "Bella", "type": "dog", "price": 400}'

You should see a response containing "message": "Pet added successfully" and the new pet object with id 4.

Both methods work. But here is the question: what happens if someone sends completely invalid data?

  • Before you run the next command, predict what will happen. Do you think the API will reject a POST request with wrong field names and missing required data?
  • Test it by sending a POST with invalid data:
curl -X POST [[INVOKE_URL="your invoke URL"]]/pets \
  -H "Content-Type: application/json" \
  -d '{"breed": "poodle"}'

You see a 200 OK response. Lambda happily accepted the garbage data and created a pet with undefined values for name, type, and price. That is the problem.

Why is this a problem?

Right now, every request hits your Lambda function regardless of what data it contains. Invalid requests waste compute time and could corrupt a real database. In a production API, you want bad requests rejected before they ever reach your backend.

This is exactly what request validation in API Gateway solves. You will add that in the next step.

Your API is live and working, but it accepts anything. Next up, you add request validation to block malformed data before it ever reaches your Lambda function.

Add Request Validation with a JSON Schema Model

In the last step, you deployed a live REST API and called it with curl. You also saw the problem: your API accepted completely invalid data without blinking.

Every bad request that reaches your Lambda function wastes compute and could corrupt data in a real backend. In this step, you will create a JSON Schema model that defines exactly what a valid pet looks like. API Gateway will reject anything that does not match, before your Lambda function ever runs.

In this step, get ready to:
  • Create a JSON Schema model that defines the valid shape of pet data.
  • Attach the model to your POST method as a request validator.
  • Test that invalid requests get rejected with a 400 error before reaching Lambda.
Create a JSON Schema model

A model in API Gateway is a blueprint that describes the exact shape of the data your API accepts. You define it using JSON Schema, and API Gateway uses it to check every incoming request body automatically.

  • Switch back to the API Gateway console in your browser.
  • In the left navigation pane, make sure your PetStoreAPI is selected.
  • Click Models in the left navigation pane.
  • Click Create model.
  • For Name, enter PetModel.
  • For Content Type, enter application/json.
  • Paste the following schema into the Model schema code editor:
{
  "type": "object",
  "required": ["name", "price", "type"],
  "properties": {
    "id": {
      "type": "integer"
    },
    "type": {
      "type": "string",
      "enum": ["dog", "cat", "fish"]
    },
    "name": {
      "type": "string"
    },
    "price": {
      "type": "number",
      "minimum": 25.0,
      "maximum": 500.0
    }
  }
}

What does this schema do?

  • required lists the three fields every pet must have: name, price, and type. A request missing any of these is rejected.
  • type is locked to one of three allowed values: dog, cat, or fish. Anything else (like "parrot") is rejected.
  • price must be a number between 25 and 500. A price of 4000 fails validation instantly.
  • id is optional. If it is included, it must be an integer.
  • Click Create model.

You should see PetModel appear in your Models list alongside the default Empty and Error models.

Model not appearing?

  • Make sure you entered application/json exactly for Content Type. A typo here means the model won't match incoming requests.
  • Check that the JSON schema you pasted is valid JSON. A missing comma or extra bracket will prevent the model from being created.
  • Help me create my PetModel in API Gateway.
Attach the model to your POST method

The model defines your rules. Now you need to tell API Gateway to enforce those rules on every POST request that comes in.

  • Click Resources in the left navigation pane.
  • Select the POST method under /pets.
  • Click the Method request tab.
  • Under Method request settings, click Edit.
  • For Request validator, select Validate body from the dropdown.
  • Scroll down to Request body and click Add model.
  • For Content type, enter application/json.
  • For Model, select PetModel from the dropdown.
  • Click Save.

What is Validate body?

API Gateway offers three validation options. Validate body checks the request body against your model. The other two options validate query string parameters and headers. For this project, you only need body validation because your /pets POST method accepts data in the request body.

  • Redeploy your API by clicking Deploy API.
  • Select the test stage from the dropdown.
  • Click Deploy.

You should see a confirmation that the API was deployed to the test stage. Your validation rules are now live.

Don't see the Deploy API button?

  • Make sure you are viewing the Resources page, not the Models page. The Deploy API button appears on the Resources page.
  • Help me redeploy my API Gateway REST API.
Test validation with valid and invalid requests

Your model is attached and the API is redeployed. Time to see if API Gateway actually blocks bad data.

  • First, confirm that valid data still works by running this command in your terminal:
curl -s -X POST [[INVOKE_URL="your API invoke URL"]]/pets \
  -H "Content-Type: application/json" \
  -d '{"name": "Bella", "type": "dog", "price": 400}'

You should see a 200 response with "message": "Pet added successfully". The valid request passes through just like before.

Now for the real test. The next request has a price of 4000, which is way above the 500 maximum you set in your schema. Before you run it, what do you think will happen?

  • Send an invalid request with an out-of-range price by running:
curl -s -X POST [[INVOKE_URL="your API invoke URL"]]/pets \
  -H "Content-Type: application/json" \
  -d '{"name": "Bella", "type": "dog", "price": 4000}'

You should see a 400 response with {"message": "Invalid request body"}. API Gateway rejected the request before it ever reached your Lambda function.

  • Test with a missing required field by running:
curl -s -X POST [[INVOKE_URL="your API invoke URL"]]/pets \
  -H "Content-Type: application/json" \
  -d '{"type": "dog", "price": 100}'
  • Test with an invalid pet type by running:
curl -s -X POST [[INVOKE_URL="your API invoke URL"]]/pets \
  -H "Content-Type: application/json" \
  -d '{"name": "Rex", "type": "parrot", "price": 100}'

Both return the same {"message": "Invalid request body"} with a 400 status. Every rule you defined in the schema is enforced automatically.

Your Lambda function never ran

If you check your Lambda function's Monitor tab in the Lambda console, you will see that the rejected requests did not trigger any invocations. API Gateway blocked them at the gateway level, saving your Lambda compute for valid requests only.

Still seeing 200 on invalid requests?

  • Make sure you redeployed the API to the test stage after saving your method request changes. Changes to method settings do not take effect until you redeploy.
  • Confirm that the Request validator on your POST method is set to Validate body, not None.
  • Check that you added application/json as the Content type under Request body and selected PetModel. Without this mapping, API Gateway skips validation.
  • Make sure your curl command includes -H "Content-Type: application/json". If the content type header is missing, API Gateway cannot match the request to your model and skips validation.
  • Help me troubleshoot my API Gateway request validation.

Your API now rejects malformed data at the gateway level, saving Lambda compute and protecting your backend. But anyone on the internet can still call your API freely. Next up, you will add a Lambda authorizer to control who can access your API.

Add Usage Plans, API Keys, and Throttling

Your API now validates request bodies and checks authorization tokens. But there is still a gap: any authorized client can send unlimited requests. A single client could flood your backend with thousands of calls per second, driving up costs and degrading performance for everyone else.

Usage plans with API keys solve this. They let you assign per-client rate limits and quotas, controlling not just who can access your API, but how much. This is the same pattern API providers like Stripe and Twilio use to manage access at scale.

In this step, get ready to:
  • Require API keys on your API methods and create a key.
  • Create a usage plan with throttling and quotas.
  • Test the full flow with authorization, API keys, and rate limiting.
Require API keys on your methods and create a key

Right now your API checks authorization tokens, but it has no concept of per-client identity. API keys give each client a unique identifier that API Gateway can use to track and throttle usage.

  • Switch back to the API Gateway console and select your PetStoreAPI.
  • In the left navigation pane, choose Resources.
  • Click the /pets resource.
  • Select the POST method.
  • Click the Method request tab.
  • Click Edit.
  • Select API key required to turn it on.
  • Click Save.

Your POST method now requires an API key. Apply the same setting to the GET method.

  • Select the GET method on /pets.
  • Click the Method request tab.
  • Click Edit.
  • Select API key required to turn it on.
  • Click Save.

Both methods now require an API key. Next, create the key itself.

  • In the left navigation pane, choose API keys.
  • Click Create API key.
  • For Name, enter DevAPIKey.
  • For API key, select Auto generate.
  • Click Save.
  • Copy the generated API key value and keep it somewhere handy. You will need it for testing shortly.

API keys are not for authentication

AWS explicitly recommends against using API keys for authentication or authorization. API keys are for throttling and metering. That is why you added a Lambda authorizer first (for access control) and are now layering API keys on top (for rate limiting).

  • Redeploy the API to the test stage by clicking Deploy API.
  • For Stage, select test.
  • Click Deploy.

Before you test, think about what will happen. You are about to send a request with a valid authorization token but no API key. What do you expect?

  • Return to your terminal and test the API with only the authorization token by running this command:
curl -X GET [[INVOKE_URL="your API invoke URL"]]/pets \
  -H "authorizationToken: allow"

You get a 403 Forbidden response. Even though your authorization token is valid, the API now also requires an API key in every request. Without one, API Gateway rejects the call before it reaches your Lambda function.

Still seeing 200 instead of 403?

  • Make sure you clicked Deploy API after enabling API key required on both methods. Changes to method settings only take effect after redeployment.
  • Confirm that both the GET and POST methods have API key required turned on, not just one of them.

Help me debug my API key requirement

Create a usage plan and associate your API stage

You have an API key, but it is not connected to any rate limits yet. A usage plan ties everything together: it defines throttling and quota rules, then links them to your API stage and key.

  • In the left navigation pane, choose Usage plans.
  • Click Create usage plan.
  • For Name, enter BasicPlan.
  • For Rate, enter 5 requests per second.
  • For Burst, enter 10.
  • For Requests (quota), enter 100 per Day.
  • Click Create usage plan.

What do rate, burst, and quota mean?

API Gateway uses the token bucket algorithm for throttling. The rate (5 requests per second) is how fast new tokens are added to the bucket. The burst (10) is the maximum number of tokens the bucket can hold at once, allowing short spikes above the steady rate.

The quota (100 per day) is a hard ceiling on total requests within the time period. Once a client hits 100 requests in a day, every subsequent request is rejected until the quota resets.

Now link your API stage and API key to the plan.

  • Under the Associated stages tab, click Add stage.
  • For API, select PetStoreAPI.
  • For Stage, select test.
  • Click Add to usage plan.
  • Switch to the Associated API keys tab and click Add API key.
  • Select Add existing key and choose DevAPIKey from the dropdown.
  • Click Add API key.

Propagation delay

After you add an API key to a usage plan, the update may take a few minutes to propagate. If your first test with the API key returns a 403, wait a minute or two and try again.

Test the full flow: auth token, API key, and throttling

Your API now has all three pillars of API management in place: validation, authorization, and rate limiting. Time to see them work together.

  • Test a successful request by running this command, replacing your-api-key-here with the API key value you copied earlier:
curl -X GET [[INVOKE_URL="your API invoke URL"]]/pets \
  -H "authorizationToken: allow" \
  -H "x-api-key: your-api-key-here"

What does this command do?

  • -H "authorizationToken: allow" passes the authorization check from your Lambda authorizer.
  • -H "x-api-key: your-api-key-here" identifies this client for throttling and quota tracking. x-api-key is the standard header name API Gateway expects for API keys.

You should see a 200 response with your list of pets. Both layers passed: the authorizer approved the token, and the usage plan accepted the API key.

Getting 403 Forbidden with both headers?

  • If you just added the API key to the usage plan, wait 1-2 minutes for the change to propagate and try again.
  • Double-check that you copied the full API key value. API keys are long alphanumeric strings (20-128 characters).
  • Confirm the DevAPIKey appears under Associated API keys in the BasicPlan usage plan, and PetStoreAPI / test appears under Associated stages.

Help me debug my API key and usage plan setup

Now let's test throttling. What do you think will happen if you send 20 rapid-fire requests in a row when the rate limit is 5 per second?

  • Send 20 rapid requests to your API by running this bash loop, replacing your-api-key-here with your API key value:
for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -H "authorizationToken: allow" \
    -H "x-api-key: your-api-key-here" \
    [[INVOKE_URL="your API invoke URL"]]/pets
done

What does this loop do?

This sends 20 GET requests back-to-back. The -s flag silences progress output. -o /dev/null discards the response body. -w "%{http_code}\n" prints only the HTTP status code for each request. You will see a stream of status codes, one per line.

You should see a mix of 200 and 429 status codes. The 429 Too Many Requests responses prove that throttling is working.

Why is the exact count unpredictable?

Usage plan throttling and quotas are applied on a best-effort basis, not as hard limits. You might not see 429 at exactly the 6th request. The important thing is that some requests get throttled, proving the rate limit is enforced.

Not seeing any 429 responses?

  • Make sure the BasicPlan has the PetStoreAPI / test stage associated. Without the stage association, throttling rules do not apply.
  • Run the loop again. Network latency can space out requests enough that the 5 req/s limit is never reached on the first try.
  • Confirm the rate is set to 5 and burst to 10 in the BasicPlan usage plan settings.

Help me debug my throttling setup

Your API now validates data, authorizes callers, and rate-limits clients. That is the full trio of API management features that production APIs need.

Secret mission

Create a Premium Tier with Higher Rate Limits

Real API providers like Stripe and Twilio offer multiple pricing tiers with different rate limits. In this mission, you will create a premium usage plan with 4x the rate limit and its own API key, then test both tiers side by side to prove each client operates under its own limits independently.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses serverless AWS resources covered by the AWS Free Tier. Lambda's free tier (1 million requests per month) is permanent. API Gateway's free tier (1 million REST API calls per month) lasts 12 months from account creation.

Cost warning

If your AWS account is older than 12 months, API Gateway calls are no longer covered by the free tier. Leaving the API deployed does not incur charges on its own, but every call you make will be billed. Delete your resources if you are past the 12-month window and do not plan to use them.

Resources you used:

  • Lambda function PetStoreFunction.
  • Lambda function PetStoreAuthorizer.
  • REST API PetStoreAPI with stage test (includes the PetStoreTokenAuthorizer and PetModel).
  • Usage plan BasicPlan with API key DevAPIKey.
  • Usage plan PremiumPlan with API key PremiumDevKey (Secret Mission).

Keep everything running

No action needed. Choose this if you are still actively building or testing your API.

  • Lambda's free tier covers 1 million requests per month permanently, so your two functions will not incur charges under normal testing.
  • API Gateway's free tier covers 1 million REST API calls per month for 12 months from account creation.
  • Usage plans and API keys do not incur any additional cost on their own.
  • Your API is only called when you (or someone with your URL and API key) sends a request. It does not generate traffic or charges on its own.

Pause - I'll come back to this later

API Gateway does not have a built-in pause feature. To stop access without deleting your configuration, you can delete the deployment stage.

  • In the API Gateway console, select PetStoreAPI.
  • In the left navigation, select **Stages**.
  • Select the test stage and delete it.
  • This removes the live endpoint so no one can call your API. Your resource definitions, methods, authorizer, model, usage plans, and API keys all remain intact.
  • When you are ready to come back, redeploy the API to a new test stage and everything will work again.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow these steps in order to avoid dependency issues.

Delete the usage plans:

  • In the API Gateway console, select **Usage Plans** in the left navigation.
  • Select BasicPlan.
  • Remove the associated API key (DevAPIKey) and the associated stage (PetStoreAPI / test), then delete the usage plan.
  • Repeat for PremiumPlan if you completed the Secret Mission. Remove its associated API key (PremiumDevKey) and stage, then delete the plan.

Delete the API keys:

  • In the API Gateway console, select **API Keys** in the left navigation.
  • Select DevAPIKey and delete it.
  • Select PremiumDevKey and delete it (if you completed the Secret Mission).

Delete the REST API:

  • In the API Gateway console, select **APIs** in the left navigation.
  • Select PetStoreAPI.
  • Delete the API. This removes the test stage, the /pets resource, both methods, the PetStoreTokenAuthorizer, and the PetModel along with it.

Delete the Lambda functions:

  • Open the Lambda console.
  • Select PetStoreFunction, then choose **Actions** and **Delete function**.
  • Repeat for PetStoreAuthorizer.

Total cost if deleted now: $0.

Nice Work!

Nice Work!

You just built a production-ready REST API on AWS that validates requests, authorizes callers, and rate-limits clients. That is the same layered security model that companies like Stripe and Twilio use to protect their APIs at scale.

You've learned how to:

  • Build a REST API with Lambda proxy integration and deploy it to a stage on Amazon API Gateway.
  • Add request validation using a JSON Schema model that blocks malformed data at the gateway level, before your Lambda function ever runs.
  • Create a TOKEN-based Lambda authorizer that controls access with bearer tokens and IAM policies.
  • Configure usage plans with API keys, throttling, and quotas to rate-limit individual clients.
  • Secret Mission: Create a multi-tier access system with separate plans for basic and premium clients, just like real API providers.

Ready to quiz yourself?