Develop AWS Serverless Locally

typical workflow:

Write your Lambda function code in your favorite IDE.

Define your resources (the function, the API, the DB table) in a SAM template.yaml file.

Use sam local start-api to test the API and function.

Point your function’s code to a local instance of DynamoDB (either from LocalStack or DynamoDB Local) for database testing.

Once everything works locally, you use sam deploy to push it to the real AWS cloud.

These are two of the most common and valid concerns when moving to a serverless, cloud-native stack. Let’s break them down.

Your assumption about local development is a common myth, but the good news is: You absolutely can develop and test this entire stack locally.

🎯 How to Develop AWS Serverless Locally

You don’t need to deploy to the cloud every time you want to test a change. Here are the standard tools and methods:

  • AWS SAM CLI: This is the official tool from AWS (Serverless Application Model). It’s a framework that lets you define your application (Lambda, API Gateway, DynamoDB table) in a simple template.yaml file.
    • sam local invoke: This command runs your Lambda function code locally in a Docker container, exactly as it would run on AWS.
    • sam local start-api: This command spins up a local web server that emulates API Gateway, allowing you to test your API endpoints from your browser or Postman.

  • LocalStack: This is a very popular third-party tool that spins up a “fully functional local AWS cloud stack” inside a single Docker container. It emulates a wide range of services, including API Gateway, Lambda, DynamoDB, S3, SQS, and many more. This is the gold standard for full integration testing locally, as you can test how your Lambda function interacts with a “fake” DynamoDB or S3 bucket.

  • DynamoDB Local: If you only need to develop against DynamoDB, AWS provides a downloadable version you can run on your machine. Your application’s AWS SDK can be pointed to localhost:8000 instead of the real AWS endpoint.

The typical workflow:

  1. Write your Lambda function code in your favorite IDE.
  2. Define your resources (the function, the API, the DB table) in a SAM template.yaml file.
  3. Use sam local start-api to test the API and function.
  4. Point your function’s code to a local instance of DynamoDB (either from LocalStack or DynamoDB Local) for database testing.
  5. Once everything works locally, you use sam deploy to push it to the real AWS cloud.

🔒 Understanding Vendor Lock-in

Your first concern is 100% correct. This is the fundamental trade-off of “serverless.”

  • What it is: When you use DynamoDB, you are writing code for DynamoDB’s specific API. When you use API Gateway, you are configuring an AWS-specific service. Moving this exact setup to Google Cloud or Azure would require a full rewrite of the infrastructure and, in the case of DynamoDB, the database logic.
  • The Trade-Off: You are trading portability for power and convenience. The “lock-in” is the price you pay for:
    • Zero server management: You never have to patch a server, manage an OS, or worry about a web server (like Nginx or Apache) crashing.
    • Infinite scaling: Your Lambda functions and DynamoDB tables can scale to handle massive traffic with zero effort from you.
    • Pay-per-use: You pay only for what you use (per-millisecond for Lambda, per-request for API Gateway), which is often far cheaper than a 24/7 running server.

How to manage and reduce (but not eliminate) lock-in:

  1. Use Abstraction: The best practice is to isolate the AWS-specific code. For example, your main business logic should not know it’s talking to DynamoDB. It should talk to a “Repository” class you write, like UserRepository.getUser(id). Inside that UserRepository, you write the DynamoDB-specific code. If you ever wanted to move to another database, you only have to rewrite that one repository file, not your entire application.
  2. Focus on Code Portability: The code inside your Lambda function (e.g., your Python, Node.js, or PHP logic) is still just code. As long as you follow the abstraction principle above, your core business logic is perfectly portable.
  3. Use Containers: For a less “locked-in” approach, you could put your application in a Docker container and run it on AWS Fargate. This is still serverless (no servers to manage), but because it’s a standard container, you could run that exact same container on Google Cloud Run or Azure Container Apps with minimal changes.

For most projects, the benefits of serverless (speed, cost, scalability) are considered to be worth the strategic risk of vendor lock-in.

How to Build a Serverless API with Lambda and API Gateway This video gives a practical, step-by-step walkthrough of how to connect the exact services you’re asking about: API Gateway, Lambda, and DynamoDB. http://googleusercontent.com/youtube_content/0

Written on October 30, 2025