Amazon API Gateway: Build and Secure REST APIs

By Khimananda Oli | Last reviewed: August 2026

Exposing backend logic without managing servers is the promise of serverless, but misconfiguring the entry point creates security holes and performance bottlenecks. Using Amazon API Gateway: Build and Secure REST APIs correctly requires understanding resource modeling, IAM integration, and infrastructure-as-code patterns rather than just clicking through the console. This guide covers the production-grade configuration needed to connect Lambda backends safely while maintaining auditability.

How do you architect Amazon API Gateway to build and secure REST APIs with Lambda?

The most common mistake I see in Nepal’s growing startup scene and global remote teams alike is treating API Gateway as a simple pass-through without considering the request/response lifecycle. When you use Amazon API Gateway: Build and Secure REST APIs in production, you must decide between REST APIs (v1) and HTTP APIs (v2). For most serverless applications requiring fine-grained IAM control, WAF integration, or usage plans, REST APIs remain the standard in 2026 despite HTTP APIs being cheaper.

Before writing any code, understand the data flow. Requests hit the edge-optimized or regional endpoint, traverse optional WAF rules, hit the gateway layer for auth/throttling, invoke Lambda, and return transformed responses. If you are new to provisioning this infrastructure declaratively, review my guide on infrastructure as code with Terraform first, as manual console changes are unauditable and drift-prone.

Choosing the right endpoint type

• Regional: Best for low-latency within a specific AWS region. Use this if your users and Lambda functions reside in the same geography (e.g., ap-south-1 for South Asia).
• Edge-Optimized: Routes traffic through CloudFront POPs globally. Higher cost but better for international user bases.
• Private: Accessible only via VPC endpoints. Mandatory for internal microservices that should never touch the public internet.

What is the correct Terraform configuration for API Gateway and Lambda integration?

Never configure API Gateway manually in production. Manual setups lack version history, make disaster recovery impossible, and fail compliance audits. Below is a battle-tested Terraform pattern that uses the proxy integration model, which passes the entire request context to Lambda without complex mapping templates.

<!-- main.tf -->
resource "aws_api_gateway_rest_api" "app_api" {
  name        = "production-api"
  description = "Managed via Terraform - Do not edit in console"
  
  endpoint_configuration {
    types = ["REGIONAL"]
  }
}

resource "aws_api_gateway_resource" "users" {
  rest_api_id = aws_api_gateway_rest_api.app_api.id
  parent_id   = aws_api_gateway_rest_api.app_api.root_resource_id
  path_part   = "users"
}

resource "aws_api_gateway_method" "get_users" {
  rest_api_id   = aws_api_gateway_rest_api.app_api.id
  resource_id   = aws_api_gateway_resource.users.id
  http_method   = "GET"
  authorization = "AWS_IAM"  # Never use NONE in production
}

resource "aws_api_gateway_integration" "lambda_integration" {
  rest_api_id             = aws_api_gateway_rest_api.app_api.id
  resource_id             = aws_api_gateway_resource.users.id
  http_method             = aws_api_gateway_method.get_users.http_method
  integration_http_method = "POST"
  type                    = "AWS_PROXY"
  uri                     = aws_lambda_function.api_handler.invoke_arn
}

# Critical: Grant API Gateway permission to invoke Lambda
resource "aws_lambda_permission" "apigw_lambda" {
  statement_id  = "AllowAPIGatewayInvoke"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.api_handler.function_name
  principal     = "apigateway.amazonaws.com"
  source_arn    = "${aws_api_gateway_rest_api.app_api.execution_arn}/*/*"
}

A frequent failure point is forgetting the aws_lambda_permission resource. Without it, API Gateway returns 500 Internal Server Error even though both resources exist. Always tie the source_arn to the specific API execution ARN to follow least-privilege principles, a core tenet discussed in my AWS IAM best practices article.

How do you implement authentication and authorization securely?

Security is where most "serverless" tutorials fail. Leaving authorization set to NONE exposes your Lambda to unlimited unauthenticated invocations, risking massive bills and data breaches. In 2026, three primary auth strategies dominate for those learning how to use Amazon API Gateway: Build and Secure REST APIs:

Enabling IAM authentication correctly

When using AWS_IAM, clients must sign requests with SigV4. This is native for AWS SDKs but requires extra libraries for browser-based clients. Ensure your IAM policies restrict access to specific API stages and methods:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:ap-south-1:123456789:abc123/prod/GET/users"
    }
  ]
}

For user-facing applications, Cognito User Pools act as a managed OIDC provider. Attach the authorizer at the API or method level. Crucially, validate tokens server-side in Lambda as well — never trust gateway-only validation for sensitive operations.

How do you configure throttling and monitoring for production stability?

Without throttling, a buggy client or DDoS attack can invoke Lambda millions of times in minutes. Configure account-level and stage-level limits defensively. I recommend starting conservative (e.g., 100 RPS burst, 50 RPS steady) and increasing based on observed load.

resource "aws_api_gateway_stage" "prod" {
  deployment_id = aws_api_gateway_deployment.app_deployment.id
  rest_api_id   = aws_api_gateway_rest_api.app_api.id
  stage_name    = "prod"

  # Stage-level throttling
  variables = {
    rate_limit  = "100"
    burst_limit = "200"
  }
}

resource "aws_api_gateway_method_settings" "all" {
  rest_api_id = aws_api_gateway_rest_api.app_api.id
  stage_name  = aws_api_gateway_stage.prod.stage_name
  method_path = "*/*"

  settings {
    throttling_rate_limit  = 100
    throttling_burst_limit = 200
    metrics_enabled        = true
    logging_level          = "INFO"
  }
}

Access logging is non-negotiable

Default CloudWatch metrics show latency and error rates but not who called your API or what payload they sent. Enable access logs with a structured JSON format for forensic analysis and SOC 2 compliance. Create a log group first, then attach it to the stage. For broader observability strategy, see my piece on monitoring with Prometheus and Grafana to correlate API metrics with infrastructure health.

REST API vs HTTP API: Which should you choose in 2026?

AWS now offers two distinct gateway products. Choosing wrong leads to either overspending or hitting feature walls mid-project.

Choose REST API when: You need WAF protection, API key monetization, complex request/response mapping, or VPC link integrations to NLBs. Most enterprise and compliance-bound workloads still require REST API.

Choose HTTP API when: You have pure Lambda-proxy integrations, use OIDC/OAuth2 natively, prioritize lowest latency, and don't need WAF or usage plans. High-volume webhook receivers and internal microservices often fit here.

In practice, many teams start with HTTP API for speed and migrate to REST API when security requirements mature. Plan for this possibility by abstracting your integration layer in Lambda so the handler doesn't depend on gateway-specific event shapes.

Next Steps for Production-Ready APIs

Mastering Amazon API Gateway: Build and Secure REST APIs means treating the gateway as a security boundary, not just a routing layer. Define everything in Terraform, enforce authentication on every method, throttle defensively, and enable structured access logs before handling real traffic. These steps separate demo projects from systems that survive audits and traffic spikes.

If your team needs help designing compliant serverless architectures or migrating from monolithic APIs to gateway-backed Lambda, reach out to discuss your infrastructure requirements. I regularly assist organizations in Nepal and globally with audit-ready AWS deployments that balance developer velocity with security governance.