How to Build and Deploy AWS Apps on Your Local Machine: Beginner Guide
By Braincuber Team
Published on April 8, 2026
Stop burning your AWS budget on development environments and "testing" accounts that rack up charges while you sleep. Most founders don't realize they are losing $1,400+ a year just by letting developers "mess around" in a live sandbox. If your dev team says they *need* a live AWS account to build a simple Pet Store API, they're wasting your cash. You can mimic the entire AWS ecosystem—Lambda, DynamoDB, API Gateway—right on a local machine using LocalStack and AWS SAM. This isn't about "simplicity"; it's about 18.5% faster deployment cycles because you aren't waiting for CloudFormation to crawl every time you fix a typo.
What You'll Learn:
- Setting up a local AWS environment with AWS SAM and Docker
- Creating a serverless project structure from scratch
- Mocking Amazon DynamoDB and API Gateway using LocalStack
- Configuring Dependency Injection (DI) for cloud-native apps
- Testing local REST API endpoints without an AWS bill
Prerequisites for Local Development
Before you start hacking, you need the right tools installed. Skip this and you'll waste 37 minutes debugging environment errors that shouldn't exist. You need AWS SAM CLI and Docker. If you don't have an AWS account, don't worry—that's the whole point of this guide. We're going to build a Pet Store application that actually works without ever touching the public internet.
Install AWS SAM CLI
This is your command-line interface for managing serverless apps. Follow the official AWS docs to get it on Windows or Mac.
Enable Docker Desktop
LocalStack and SAM use Docker to simulate Lambda runtimes. Ensure it's running before you try to fire up your local cloud.
Phase 1: Initializing the Project
We'll use a standard template to get moving. Run the following command in your terminal. This creates a folder named pet-store in your directory. (Warning: If you're on Windows, use PowerShell or CMD—don't try to get fancy with old terminal emulators).
sam init -r java11 -d maven --app-template pet-store -n pet-store
Phase 2: Coding the Logic & DynamoDB Interaction
Your application needs to store data. We're using DynamoDB because it's fast, but only if you use it correctly. First, add the SDK dependencies to your pom.xml. This brings in the DynamoDbClient we need. (Yes, you have to deal with XML—welcome to Java).
Performance Warning
A SCAN request in DynamoDB hits every item in the table. Never use this in a retail environment with 10k+ SKUs unless you want to crash your Lambda and pay through the nose.
public void putPet(Pet pet) {
PutItemRequest request = PutItemRequest.builder()
.tableName("pet-store")
.item(pet.asAttributes())
.build();
dynamoDbClient.putItem(request);
}
Phase 3: Setting Up the Local Mock (LocalStack)
Here is where the magic happens. LocalStack spins up a Docker container that pretends to be AWS. It exposes everything on port 4566. No internet needed. No credit card required. Create a docker-compose.yaml file in your project root.
version: "3.8"
services:
localstack:
image: localstack/localstack
ports:
- "4566:4566"
environment:
- SERVICES=dynamodb
- DEFAULT_REGION=us-west-1
- LAMBDA_EXECUTOR=local
- DATA_DIR=/tmp/localstack/data
Phase 4: Creating the Local Table
Now that LocalStack is running (docker-compose up), you need to create the DynamoDB table. Since your environment thinks it's AWS, you use the standard AWS CLI, but crucially, you point the endpoint URL to your localhost.
aws --endpoint-url "http://localhost:4566" dynamodb create-table --table-name pet-store --attribute-definitions AttributeName=id,AttributeType=S --key-schema AttributeName=id,KeyType=HASH --billing-mode PAY_PER_REQUEST
Phase 5: Running & Testing the API
Finally, build your project and start the local API server. This exposes your REST endpoints on port 3000. You can use curl to verify everything works without ever sending a single packet to US-EAST-1.
Build Project
Run sam build to compile and package your Lambda functions.
Start Local API
Run sam local start-api to host the endpoints on localhost:3000.
curl --location --request PUT 'http://127.0.0.1:3000/pet' --header 'Content-Type: application/json' --data-raw '{ "name": "Rocket", "age": 2, "category": "Dog" }'
Frequently Asked Questions
Why use LocalStack instead of a Sandbox account?
Cost and speed. LocalStack eliminates the latent CloudFormation wait times and prevents unwanted billing surprises from forgotten resources.
Is the local environment exactly the same as live AWS?
It's a very close mock. 99% of IAM roles and API behaviors match, but always do a final staging check on live AWS before production.
What happens if I forget to use the --endpoint-url flag?
The CLI will try to reach the real AWS servers. If you aren't logged in, it fails. If you are, it might create resources and charge you.
Does this work for Python or Node.js too?
Yes. SAM CLI supports most runtimes. You just need to change the runtime flag during the sam init phase.
Can I mock S3 and SQS too?
Absolutely. LocalStack supports a wide range of AWS services. Just add them to the SERVICES list in your docker-compose file.
Tired of Paying for Dev Environments?
Our cloud experts can help you automate your AWS local development cycles and cut your monthly bill by 25% or more.