Getting Started with Serverless on AWS: Lambda and API Gateway for Beginners

You have heard that serverless means no servers to manage, and that is mostly true. But "no servers" does not mean no infrastructure decisions. Your first AWS Lambda function is straightforward. Wiring it into a real production system — with a public endpoint, correct permissions, and predictable costs — is where most people hit unexpected walls.

This guide walks you through how AWS Lambda and API Gateway actually work, how to deploy your first function, and the gotchas worth knowing before you build on top of this stack.

How AWS Lambda Works

Lambda is a compute service that runs code in response to events. You write a function, package it, and upload it to Lambda. AWS handles provisioning, scaling, and cleanup of the underlying compute.

Your function runs when triggered by an event source. Common event sources include:

• API Gateway or HTTP endpoint — an HTTP request triggers the function
• S3 — a file upload or deletion triggers the function
• SQS — a message in a queue triggers the function
• EventBridge — a scheduled event or custom event triggers the function

Lambda functions are stateless. Each invocation receives an event object and a context object, and returns a response. Any state you need to persist across invocations must live in an external store — DynamoDB, S3, ElastiCache, or similar.

The Execution Model

When a function is invoked, Lambda either:

1. Reuses an existing warm execution environment (fast — no initialization cost)
2. Creates a new execution environment from scratch (cold start — slower first request)

Warm reuse is why you initialize expensive resources — database connections, SDK clients — at module scope rather than inside the handler. Those resources survive across warm invocations; the handler itself is the only code that runs on every call.

How API Gateway Works With Lambda

API Gateway is a managed HTTP endpoint service. It receives requests, applies transformations and authorization, routes to a backend integration (in this case Lambda), and returns the response.

When you connect API Gateway to a Lambda function:

1. A client sends an HTTP request to the API Gateway URL
2. API Gateway invokes the Lambda function with an event object containing the request details (method, path, headers, body, query parameters)
3. Your Lambda function processes the event and returns a response object with statusCode, headers, and body
4. API Gateway forwards that response to the client

The event structure depends on whether you use HTTP API (simpler, preferred) or REST API (more features, more complex). For most use cases, start with HTTP API.

Your First Lambda Function

A minimal Node.js Lambda handler looks like this:

export const handler = async (event) => {
  const name = event.queryStringParameters?.name ?? "world";
  return {
    statusCode: 200,
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ message: `Hello, ${name}` }),
  };
};

The handler receives the API Gateway event, reads a query parameter, and returns a JSON response.

Deploying to AWS

You have several options for deploying Lambda functions:

AWS Console — upload a ZIP file manually. Fine for a first test, not suitable for real projects.

AWS SAM (Serverless Application Model) — AWS's own IaC tool for serverless. YAML-based, integrates tightly with CloudFormation, good for teams already deep in AWS tooling.

Serverless Framework — a popular open-source tool that abstracts over CloudFormation. Easier to get started, large plugin ecosystem.

Terraform — AWS-agnostic IaC that can provision Lambda, API Gateway, IAM roles, and everything else. Best for teams with existing Terraform workflows.

For a new project, the Serverless Framework or AWS SAM are both reasonable starting points. Terraform is worth adopting early if you plan to grow beyond a single AWS service.

IAM: The Part Most Beginners Skip

Lambda functions run with an IAM role. That role determines what AWS services the function can access. By default, a new Lambda function has minimal permissions — only the ability to write logs to CloudWatch.

If your function needs to read from S3, write to DynamoDB, or call other AWS services, you must add the appropriate IAM policies to the function's execution role. The principle of least privilege applies: grant only the specific actions on specific resources the function actually needs.

A common beginner mistake: attaching AdministratorAccess to the Lambda execution role because it makes things work. This creates a significant security exposure. Take the time to write specific policies. AWS Policy Generator and the IAM policy simulator help.

Environment Variables and Secrets

Lambda functions can receive configuration through environment variables. Set them in the function configuration; they are available to your code as process.env.VARIABLE_NAME.

For sensitive values — database passwords, API keys — do not put them in environment variables directly if your AWS account has broad team access. Instead:

• Store secrets in AWS Secrets Manager or Parameter Store
• Grant the Lambda execution role secretsmanager:GetSecretValue or ssm:GetParameter permission
• Fetch the secret once at cold start (outside the handler) and cache it in memory

This keeps sensitive values out of the function configuration UI and access logs.

Key Limits to Know Early

Lambda and API Gateway have limits that affect application design:

• Lambda timeout: maximum 15 minutes per invocation. API Gateway-triggered functions have an effective maximum of 29 seconds (API Gateway's timeout).
• Lambda payload: 6MB synchronous request/response limit. For large files, use S3 pre-signed URLs instead of passing file data through the function.
• Lambda concurrent executions: default 1,000 per region per account, shared across all functions. Plan your concurrency allocation before production.
• API Gateway payload: 10MB maximum request body size.

Designing around these limits early prevents architectural refactors later. If your use case involves long-running compute, large file processing, or high concurrency, factor those into your design before committing to a Lambda-centric architecture.

What Comes Next

Once you have Lambda and API Gateway running, the natural next steps are:

• Add a custom domain via API Gateway domain name configuration and Route 53
• Implement authorization with a Lambda authorizer or JWT authorizer (built-in to HTTP APIs)
• Connect DynamoDB for persistent state
• Set up CloudWatch alarms on error rate, duration, and throttle metrics
• Add X-Ray tracing for request visibility

Serverless on AWS scales well and costs relatively little at low volumes. The operational model is genuinely simpler than managing EC2 instances. The tradeoffs — cold starts, statelessness, payload limits, IAM complexity — are manageable if you know them going in.

If you are building a product on AWS and want the infrastructure designed correctly from the start, talk to Clixo. We design and build cloud systems for product teams who need to move fast without accumulating technical debt.