How to Emulate Cloud Services Locally (Without an AWS, Azure, or GCP Account)

You emulate cloud services locally by running open-source, API-compatible stand-ins for AWS, Azure, and GCP on your own machine, then pointing your existing code at them instead of the real cloud. LocalStack recreates AWS. Azurite recreates Azure Storage. MinIO recreates S3. None of them require a cloud account, a credit card, or an internet connection to work.

That's the mechanics. The reason to bother is bigger than convenience.

Why local emulation is really about ownership

Most teams treat cloud dependency as a production problem. Dev and test environments quietly inherit the same risk. If every engineer needs a live AWS account to run integration tests, your ability to build software is gated by a vendor's uptime, IAM permissions, and pricing page, even when nothing you're building has shipped yet.

The October 20, 2025 AWS outage made that risk concrete. A DNS race condition in DynamoDB's internal endpoint management in us-east-1 cascaded into a roughly 15-hour disruption that took down EC2, Lambda, SQS, and more than a dozen other services, generating over 6.5 million Downdetector reports across more than 1,000 affected services.¹² Teams that had never touched production that day still couldn't run their CI pipelines, because their test suites depended on a live account in the wrong region.

That's the same lock-in logic covered in the ownership renaissance happening across tech stacks: if you can't run your own software without someone else's servers being up, you don't fully own it. Emulating cloud services locally is the dev/test version of that same argument.

What does "emulating cloud services locally" actually mean?

The term covers three distinct approaches, and mixing them up leads to wasted setup time.

• API emulators. Tools like LocalStack and the Firebase Local Emulator Suite reimplement a provider's actual service APIs, so unmodified SDK and CLI calls work against a local endpoint instead of the real cloud.
• Drop-in compatible services. MinIO doesn't emulate S3, it implements the S3 API directly as its own object storage server, so existing S3 clients work against it without modification.³
• Real dependencies in disposable containers. Testcontainers spins up actual services, including LocalStack, in throwaway Docker containers for a test run or dev session, then tears them down.⁴⁵

All three get you to the same place: infrastructure your code talks to without a vendor account in the loop.

Step 1: Pick the right emulation strategy for your stack

Match the tool to the provider you actually use in production, rather than reaching for whatever's popular.

1. AWS-heavy stacks. Use LocalStack, which emulates more than 90 AWS services and works with unmodified AWS CLI, SDK, and infrastructure-as-code tooling.⁶
2. Azure Storage workloads. Use Azurite, Microsoft's official open-source emulator for Blob, Queue, and Table storage, which has replaced the deprecated Azure Storage Emulator.⁷
3. Firebase or GCP-adjacent projects. Use the Firebase Local Emulator Suite, which bundles emulators for Auth, Firestore, and Storage, built to mirror live Firebase behavior.
4. Any stack using object storage, regardless of provider. Use MinIO as a permanent S3-compatible backend rather than a temporary stand-in, since it runs the same way in dev, CI, and self-hosted production.³
5. Mixed or polyglot stacks. Use Testcontainers as the orchestration layer, since it can wrap LocalStack, MinIO, and other services under one consistent lifecycle across languages.⁴

Step 2: Stand up an AWS-equivalent stack with LocalStack

LocalStack runs as a single Docker container and exposes a local endpoint, typically localhost:4566, that emulates the AWS APIs your code already calls.⁶⁸ The setup follows a consistent pattern:

1. Start the container. Pull the LocalStack image and run it with Docker, mapping the emulator's port to your host.
2. Point your tools at it. Configure an AWS CLI profile with dummy credentials and an endpoint override, or use the awslocal and cdklocal wrapper commands, thin shims over the standard AWS CLI and CDK that redirect calls automatically.
3. Deploy as usual. Run your existing CloudFormation, Terraform, or CDK project against the local endpoint. AWS's own guidance notes this cuts deploy times for cloud and serverless applications from minutes to seconds, since nothing is provisioning real infrastructure.⁶
4. Exercise a real flow. Create an S3 bucket, drop an object in it, trigger a Lambda function on that event, and write the result to a local DynamoDB table, all without leaving your laptop.
5. Onboard new engineers without new IAM grants. Since the sandbox needs no cloud account access, new hires can experiment with real AWS scenarios immediately, which lowers onboarding friction and the risk of handing broad permissions to every new engineer on day one.⁶

This is the same pattern behind running your dev stack independent of any single vendor's outage window: the code doesn't know or care that the infrastructure underneath it isn't the real thing.

Step 3: Emulate Azure and GCP services

The AWS pattern generalizes, which matters if your organization is multi-cloud or migrating.

For Azure Storage, Azurite runs on Node.js, works cross-platform, and supports Blob, Queue, and Table storage without any Azure subscription.⁷ Start it as a local process or container, swap in local connection strings for Azure endpoints, and your existing Azure SDK calls work unchanged.

For Firebase and GCP-adjacent projects, the Local Emulator Suite runs the same core services side by side and is built to mirror live behavior rather than approximate it. The workflow is nearly identical to LocalStack's: start the emulators, redirect your app's configuration to local ports, and run your normal test suite against them.

The practical lesson: "emulate cloud services locally" isn't an AWS-specific trick. Every major provider has a credible local counterpart, and setup effort per provider runs about a day, not a quarter.

Step 4: Wire emulators into Testcontainers for repeatable environments

Running an emulator by hand on your machine is a dev convenience. Wiring it into Testcontainers turns it into something you can version-control and reproduce identically in CI, which is the actual mechanism that makes this an ownership strategy rather than a local hack.

Testcontainers provides libraries across major languages that programmatically start and stop real services, including LocalStack, inside Docker containers scoped to a test run.⁴⁵ A typical setup:

1. Declare the container in code, specifying LocalStack (or MinIO, or Azurite) and the services you need, instead of documenting setup steps in a README that goes stale.
2. Let the test suite start and stop it automatically, so every CI run gets a clean environment with no leftover state from the last run.
3. Add Testcontainers Desktop for local development, which layers on reusable containers and fixed ports so you're not waiting on a fresh container spin-up every time you save a file.⁹

Once this is in place, the emulator setup lives in your repository, not in a wiki page or a senior engineer's head. Anyone who clones the repo gets the same infrastructure instantly, with no cloud credentials required.

What should stay local, and what still needs the real cloud

Local emulation isn't a full substitute for the real thing. Be upfront with your team about the gaps:

• IAM fidelity. Emulators approximate permission models but don't replicate the full nuance of AWS IAM, Azure RBAC, or GCP IAM at scale, so security testing still needs a real environment before launch.
• Managed-service internals. Features tied to a provider's actual infrastructure, like DynamoDB's real scaling behavior or Azure's actual network topology, can't be fully reproduced locally.
• Load and scale testing. A laptop or CI runner can't stand in for real production load, so performance validation still belongs in a staging environment on the real cloud.
• Final integration checks. Before a release, run the same test suite once against the real provider to catch drift between the emulator's behavior and the live API.

The right split is local by default, real cloud for the last mile. That's not a compromise, it's how most teams already run local-first tools alongside a thinner cloud footprint.

How much does cloud dependency really cost you?

The numbers back this up.

Flexera's 2026 State of the Cloud Report found estimated wasted IaaS/PaaS spend rose to 29%, reversing five years of decline, largely driven by AI workload growth.¹⁰ Gartner estimates shadow IT and unsanctioned cloud spend account for 30% to 40% of total IT spending in large enterprises.¹¹ Every dev account left running, every test environment provisioned against real infrastructure instead of an emulator, adds to that waste.

Downtime costs sharpen the case further. The 2026 Splunk and Cisco "Hidden Costs of Downtime" report puts average downtime at $15,000 per minute, with Global 2000 companies losing a combined $600 billion annually to unplanned outages.¹² ITIC's 2024-2025 survey found 93% of organizations report over $300,000 per hour of downtime cost.¹² None of that is specific to AWS, Azure, or GCP. It's the price of dependency itself, and it applies just as much to a blocked CI pipeline as a production incident.

Teams building internal tools, whether that's a scheduling system, an internal dashboard, or an agent-driven workflow through something like Remy, get a real return from decoupling development from live cloud accounts: faster onboarding, faster CI, and no exposure to a vendor's bad day. The emulator setup takes a few hours. The insurance it buys is measured in the outages you never notice.