DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • AWS Managed Database Observability: Monitoring DynamoDB, ElastiCache, and Redshift Beyond CloudWatch
  • Cost Is a Distributed Systems Bug
  • The Terraform State Locking Migration You Need to Know About: Moving Beyond DynamoDB
  • From Distributed Monolith to Composable Architecture on AWS

Trending

  • RAG Done Right: When to Use SQL, Search, and Vector Retrieval and How To Combine Them
  • Why SAP S/4HANA Landscape Design Impacts Cloud TCO More Than Compute Costs
  • Bridging Gaps in SOC Maturity Using Detection Engineering and Automation
  • AWS Managed Database Observability: Monitoring DynamoDB, ElastiCache, and Redshift Beyond CloudWatch
  1. DZone
  2. Data Engineering
  3. Databases
  4. Rapid AWS Prototyping With LocalStack: A Developer’s Guide to Building AWS PoCs Locally

Rapid AWS Prototyping With LocalStack: A Developer’s Guide to Building AWS PoCs Locally

This article shows how to use LocalStack to build and test AWS-based Proof of Concepts (PoCs) entirely on your local machine.

By 
Akash Verma user avatar
Akash Verma
·
Jul. 17, 25 · Tutorial
Likes (1)
Comment
Save
Tweet
Share
4.3K Views

Join the DZone community and get the full member experience.

Join For Free

Proof of Concepts (PoCs) play a critical role in modern software development. They allow engineers and architects to validate technical assumptions, test integrations, and explore new ideas quickly and with minimal investment. When working with Amazon Web Services (AWS), however, even simple experimentation often requires deploying cloud infrastructure. This can be time-consuming, costly, and constrained by organizational permissions.

Enter LocalStack — a fully functional AWS cloud emulator that enables developers to simulate AWS services entirely on their local machines. By replicating AWS APIs and service behavior, LocalStack empowers teams to build and iterate faster without depending on live cloud environments.

In this article, we’ll walk through how to use LocalStack to build a complete serverless PoC. You will learn how to emulate key AWS services, deploy a working order-processing workflow, and validate cloud architecture decisions locally, saving both time and resources while maintaining high development velocity.

What Is LocalStack?

LocalStack is a powerful tool that emulates a broad range of AWS cloud services locally. It supports dozens of AWS services, including but not limited to:

  • S3 for object storage
  • Lambda for serverless compute
  • DynamoDB for NoSQL databases
  • SQS for queue-based messaging
  • SNS, CloudWatch, API Gateway, and more

By providing local access to these services via the same AWS SDKs and CLI commands developers are used to, LocalStack enables rapid prototyping and testing without provisioning real cloud infrastructure. This reduces development friction, accelerates feedback loops, and eliminates cloud costs during early-stage development.

Why Use LocalStack for PoCs?

There are several compelling reasons to adopt LocalStack when working on AWS-based PoCs:

Speed

You can spin up or shut down entire environments in seconds using Docker. There is no need to wait for CloudFormation templates or infrastructure-as-code pipelines to finish provisioning.

Cost

LocalStack eliminates the need to provision paid AWS resources. You can experiment freely without watching your AWS bill grow.

Independence

Working locally means you don’t need AWS cloud access or elevated IAM permissions. This is especially beneficial in corporate environments where AWS accounts are tightly governed.

Confidence

Test complete, complex workflows and integrations locally. Validate your design and logic before promoting anything to production.

Getting Started With LocalStack

In this walkthrough, we'll use Docker to run LocalStack and interact with it using the AWS CLI and awslocal, a wrapper for AWS CLI commands tailored for LocalStack.

Prerequisites

  • Download and install from https://www.docker.com
  • Clone the Example Project

git clone https://github.com/akash4488/localstack-poc cd localstack-poc

  • Install LocalStack CLI

 pip install awscli-local

  • Install and Configure AWS CLI . Use dummy credentials. LocalStack does not validate real credentials.

aws configure

# Use dummy values for access key, secret key, region

Start LocalStack Using -> docker Compose docker-compose up


Example PoC: Order Processing Workflow

Let’s simulate a simple order processing workflow involving three AWS services:

  • An API receives orders and places them into an SQS queue.
  • A Lambda function polls the queue.
  • The Lambda writes order data into a DynamoDB table.

Step 1: Create an SQS Queue


Shell
 
awslocal sqs create-queue --queue-name order-queue


This creates a named queue in LocalStack. It will serve as the message broker for order events.

Step 2: Create a DynamoDB Table

Shell
 
awslocal dynamodb create-table \

  --table-name Orders \

  --attribute-definitions AttributeName=orderId,AttributeType=S \

  --key-schema AttributeName=orderId,KeyType=HASH \

  --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5


This table stores the order records. We define orderId as the partition key.

Step 3: Create and Deploy the Lambda Function

In the example repo, the handler.py file contains the Lambda code to read messages from SQS and write to DynamoDB.

Package the function:

Shell
 
cd src

zip -r function.zip handler.py


Deploy the Lambda:

Shell
 
awslocal lambda create-function \

  --function-name my-lambda-function \

  --runtime python3.9 \

  --role arn:aws:iam::000000000000:role/execution_role \

  --handler handler.lambda_handler \

  --zip-file fileb://function.zip \

  --timeout 30


Step 4: Send a Message to the Queue


Shell
 
awslocal sqs send-message \

  --queue-url http://localhost:4566/000000000000/order-queue \

  --message-body '{"orderId": "123", "item": "Book"}'




This mimics an order submission. The message is placed on the SQS queue.

Step 5: Invoke the Lambda (Optional)

Shell
 
aws --endpoint-url=http://localhost:4566 lambda invoke \

  --function-name my-lambda-function output.txt


This manually triggers the Lambda to process the queue.

Step 6: Query DynamoDB for Inserted Records

Shell
 
aws --endpoint-url=http://localhost:4566 dynamodb scan --table-name Orders


You should see the inserted order in the response.

Observability and Testing

Monitoring and debugging are critical aspects of building reliable PoCs. With LocalStack, developers have several options for observing application behavior:

  • Docker Logs: The LocalStack container provides real-time logs. Use the command docker logs -f localstack_main to stream output and monitor service activity such as Lambda execution and SQS message handling.
  • Print Statements: Add logging or print statements within your Lambda functions to output useful debugging information during execution.
  • CloudWatch Simulation: Although limited, LocalStack emulates CloudWatch logs for some services. You can configure functions to send logs there and inspect them via CLI.
  • REST API Testing: If your PoC includes API Gateway, you can test endpoints locally using tools like Postman, curl, or any HTTP client of your choice. This is useful for validating request/response behavior and authorization headers.
  • Resource Inspection: Use awslocal commands to inspect the state of SQS queues, DynamoDB tables, or Lambda configurations. This helps confirm the side effects of each operation.
  • Test Automation: Integrate your LocalStack setup with testing frameworks like Jest, Pytest, or Mocha to simulate full test runs as part of your CI/CD pipeline.

By combining these strategies, you ensure that your PoC is not only functional but also observable, maintainable, and aligned with best practices in local-first cloud development.

Best Practices for PoCs With LocalStack

  1. Limit Scope: Use only the AWS services essential to your use case.
  2. Automate Setup: Use init/ready.d/ scripts in Docker to auto-create resources.
  3. Use awslocal: Simplifies CLI commands by eliminating the need for --endpoint-url.
  4. Follow Naming Conventions: Mirror production naming (e.g., dev-orders-table) for easier migration.
  5. Leverage IaC Tools: Tools like Terraform or CDK help scale your PoC into production-grade deployments.
  6. Secure by Default: Always use dummy credentials locally and never hardcode secrets.
  7. Log Aggressively: Print debug logs in all key service layers.
  8. Keep It Ephemeral: Clean up resources after every run or use throwaway tables.
  9. Focus on Logic, Not Scale: Use LocalStack to validate correctness, not performance.
  10. Check Feature Support: Some AWS services are partially implemented; consult the LocalStack Docs for details.

Limitations to Be Aware Of

  • Incomplete Service Parity: Some AWS services may not fully replicate all features.
  • Not for Load Testing: LocalStack is optimized for functionality, not performance simulation.
  • Debugging Asynchronous Flows: Combining services like Lambda and SQS may require careful log inspection and retries.

Conclusion

LocalStack offers a fast, flexible, and cost-effective environment for developing and testing AWS-based PoCs. By simulating key AWS services on your local machine, you can design, build, and iterate on serverless applications without waiting on infrastructure provisioning or dealing with account restrictions.

Whether you're validating a workflow, integrating with third-party APIs, or experimenting with infrastructure-as-code tools, LocalStack helps you move faster while reducing cloud-related overhead. It’s a must-have for every developer and architect looking to prototype AWS solutions efficiently and securely.

AWS Amazon DynamoDB Command-line interface

Opinions expressed by DZone contributors are their own.

Related

  • AWS Managed Database Observability: Monitoring DynamoDB, ElastiCache, and Redshift Beyond CloudWatch
  • Cost Is a Distributed Systems Bug
  • The Terraform State Locking Migration You Need to Know About: Moving Beyond DynamoDB
  • From Distributed Monolith to Composable Architecture on AWS

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook