DEV Community: Lucas Vieira

Testing Bedrock Guardrails without the AWS bill

Lucas Vieira — Sat, 25 Apr 2026 19:23:26 +0000

Originally published on fakecloud.dev.

Bedrock Guardrails are one of the better pieces of AWS infrastructure in the last year. You define a policy — filter out hate, block PII leakage, deny certain topics, enforce contextual grounding on RAG outputs — and either apply it to an entire model invocation via guardrailIdentifier, or call ApplyGuardrail directly on arbitrary text. Useful, sharp, limited-in-scope.

The problem is testing. A serious guardrail config is an iterative thing — you tune filter strengths, add denied topics, tweak word filters, and test each change. Each test-cycle turn against real AWS costs tokens and time. And if the thing you're trying to guard against is LLM output, you're paying for the model call and the guardrail evaluation.

fakecloud runs the full Bedrock Guardrails surface locally. CreateGuardrail, versioning, UpdateGuardrail, DeleteGuardrail, ApplyGuardrail, ListGuardrails — the whole thing. More interestingly, the data plane actually evaluates content. PII detection works. Content filters return sensible scores on real test text. You can write tests that verify your guardrail actually blocks what you think it blocks.

The shape of the problem

The standard AWS recipe, cleaned up:

import boto3

bedrock = boto3.client('bedrock', region_name='us-east-1')

g = bedrock.create_guardrail(
    name='customer-facing-v1',
    contentPolicyConfig={
        'filtersConfig': [
            {'type': 'HATE', 'inputStrength': 'HIGH', 'outputStrength': 'HIGH'},
            {'type': 'VIOLENCE', 'inputStrength': 'HIGH', 'outputStrength': 'HIGH'},
            {'type': 'SEXUAL', 'inputStrength': 'HIGH', 'outputStrength': 'HIGH'},
            {'type': 'INSULTS', 'inputStrength': 'MEDIUM', 'outputStrength': 'MEDIUM'},
        ],
    },
    sensitiveInformationPolicyConfig={
        'piiEntitiesConfig': [
            {'type': 'EMAIL', 'action': 'BLOCK'},
            {'type': 'PHONE', 'action': 'BLOCK'},
            {'type': 'CREDIT_DEBIT_CARD_NUMBER', 'action': 'BLOCK'},
        ],
    },
    topicPolicyConfig={
        'topicsConfig': [
            {
                'name': 'medical-advice',
                'definition': 'Providing specific medical diagnoses or treatment recommendations',
                'examples': ['What dose should I take?', 'Do I have cancer?'],
                'type': 'DENY',
            },
        ],
    },
    blockedInputMessaging='Cannot process this input.',
    blockedOutputsMessaging='Cannot respond to this.',
)

Now you want to test: does an email containing bob@example.com trigger the EMAIL filter and return the blocked-input message? Does a prompt asking "what medication should I take for my headache" get denied via the medical-advice topic? Does the HATE filter catch slurs at HIGH strength?

Against real AWS: each of those is an API call that costs a few cents, takes a second, and requires valid credentials. You'll do 50 of these across a tuning session. Repeated for each PR that touches guardrail config.

Against fakecloud

Same code, different endpoint:

import boto3

bedrock = boto3.client('bedrock',
    endpoint_url='http://localhost:4566',
    aws_access_key_id='test',
    aws_secret_access_key='test',
    region_name='us-east-1')

# same create_guardrail call as above
g = bedrock.create_guardrail(...)

rt = boto3.client('bedrock-runtime',
    endpoint_url='http://localhost:4566',
    aws_access_key_id='test',
    aws_secret_access_key='test',
    region_name='us-east-1')

resp = rt.apply_guardrail(
    guardrailIdentifier=g['guardrailId'],
    guardrailVersion='DRAFT',
    source='INPUT',
    content=[{'text': {'text': 'contact me at bob@example.com'}}],
)

assert resp['action'] == 'GUARDRAIL_INTERVENED'
assert resp['outputs'][0]['text'] == 'Cannot process this input.'
assert any(a['type'] == 'EMAIL' for a in resp['assessments'][0]['sensitiveInformationPolicy']['piiEntities'])

Real PII detection — the email is caught. Real blocked-input messaging returned. Assessments returned in the shape real AWS would return.

No tokens. No AWS bill. No credentials. 30ms.

What's actually evaluated

fakecloud's guardrail evaluator ships opinionated implementations of each policy type. Concrete checks you can rely on in tests:

PII entities: regex + context for email, phone (various formats), credit card (Luhn), SSN, IP, URL, name, address hints.
Content filters: keyword + pattern matching tuned for the common categories. HIGH strength catches more, LOW catches less — same directional behavior as real AWS.
Topic filters: pattern matching against the topic definition + examples you provided. Won't pass a Stanford NLI benchmark, but does what you need for testing: asserts the policy fires on obvious positives and passes obvious negatives.
Word filters: exact match + stemming.
Regex filters: the regex you supplied, as-is.

It's shape-correct evaluation. For tests that verify "my guardrail config blocks what I intended," that's exactly what you need. If you want bulletproof production-grade content filtering, you're going to tune against real AWS or roll your own anyway — this gets you 95% of the iteration speed.

Versioning

# publish a version
v = bedrock.create_guardrail_version(
    guardrailIdentifier=g['guardrailId'],
    description='initial pinned version for prod',
)

# list versions
versions = bedrock.list_guardrails(guardrailIdentifier=g['guardrailId'])

# apply a specific version in production
rt.apply_guardrail(
    guardrailIdentifier=g['guardrailId'],
    guardrailVersion=v['version'],  # '1'
    source='INPUT',
    content=[{'text': {'text': '...'}}],
)

DRAFT is mutable. Numbered versions (1, 2, 3, ...) are immutable once created — same as real AWS. Your prod code should pin. Your dev iteration happens against DRAFT.

A realistic test suite

import { FakeCloud } from "fakecloud";
import { BedrockRuntimeClient, ApplyGuardrailCommand } from "@aws-sdk/client-bedrock-runtime";
import { BedrockClient, CreateGuardrailCommand } from "@aws-sdk/client-bedrock";

const fc = new FakeCloud();
const control = new BedrockClient({ endpoint: "http://localhost:4566" });
const rt = new BedrockRuntimeClient({ endpoint: "http://localhost:4566" });

let guardrailId: string;

beforeAll(async () => {
  const created = await control.send(new CreateGuardrailCommand({
    name: "test-guardrail",
    contentPolicyConfig: {
      filtersConfig: [
        { type: "HATE", inputStrength: "HIGH", outputStrength: "HIGH" },
      ],
    },
    sensitiveInformationPolicyConfig: {
      piiEntitiesConfig: [
        { type: "EMAIL", action: "BLOCK" },
        { type: "PHONE", action: "ANONYMIZE" },
      ],
    },
    blockedInputMessaging: "Blocked.",
    blockedOutputsMessaging: "Blocked.",
  }));
  guardrailId = created.guardrailId!;
});

beforeEach(() => fc.reset({ preserve: ["bedrock:guardrails"] }));

test("blocks input containing email", async () => {
  const resp = await rt.send(new ApplyGuardrailCommand({
    guardrailIdentifier: guardrailId,
    guardrailVersion: "DRAFT",
    source: "INPUT",
    content: [{ text: { text: "contact me at alice@example.com" } }],
  }));

  expect(resp.action).toBe("GUARDRAIL_INTERVENED");
  expect(resp.outputs?.[0].text).toBe("Blocked.");
});

test("anonymizes phone in output", async () => {
  const resp = await rt.send(new ApplyGuardrailCommand({
    guardrailIdentifier: guardrailId,
    guardrailVersion: "DRAFT",
    source: "OUTPUT",
    content: [{ text: { text: "call me at 555-123-4567 tomorrow" } }],
  }));

  expect(resp.action).toBe("GUARDRAIL_INTERVENED");
  expect(resp.outputs?.[0].text).not.toContain("555-123-4567");
});

test("passes clean input through", async () => {
  const resp = await rt.send(new ApplyGuardrailCommand({
    guardrailIdentifier: guardrailId,
    guardrailVersion: "DRAFT",
    source: "INPUT",
    content: [{ text: { text: "what's the weather in Paris?" } }],
  }));

  expect(resp.action).toBe("NONE");
});

These run in milliseconds, are deterministic, and test the thing that matters — that your guardrail config enforces what you think it enforces.

Why this matters for agent systems

Guardrails become critical when you're building tool-using agents. A tool call that leaks customer PII is a real incident; a model output that contains violence content is a real incident. You want those failure modes caught in CI, not in production.

The pattern:

Compose the guardrail config as code (Terraform / CDK) alongside your agent definition.
In CI, deploy the guardrail to fakecloud, run a test matrix of adversarial inputs through your agent, assert that the guardrail fires (or doesn't fire) where expected.
On merge to main, deploy the same config to real AWS.

The first two steps cost nothing. The third is the one that actually consumes budget.

This is the test loop real AWS makes nearly impossible — not because of technical obstacles, but because the cost-per-iteration is too high for the number of iterations you actually need.

Free LocalStack alternatives in 2026: fakecloud, MiniStack, floci, Moto

Lucas Vieira — Fri, 24 Apr 2026 12:44:54 +0000

Originally published on fakecloud.dev.

LocalStack's Community Edition went proprietary in March 2026. Since then a few free, open-source alternatives have surfaced or gained momentum. This post covers the four that keep coming up — fakecloud, MiniStack, floci, and Moto — and what each one is, architecturally.

Upfront disclosure: I maintain fakecloud. Bias declared. What this post avoids: a head-to-head scorecard with numbers I haven't personally measured on all four. That kind of comparison gets out of date in days and reads as marketing when the numbers are favorable to the author. Instead: what each project is, the design choices it's made, and how to think about the fit.

The architectural split that matters

Two ways to emulate AWS for tests:

1. In-process library that patches the SDK. Import a library, decorate your test, library intercepts SDK calls inside your test process. Moto works this way. Fast, no external process, trivial Python setup. Does not speak the AWS wire protocol. Cannot run real Lambda code, real databases, or real Redis.

2. Real HTTP server speaking the AWS wire protocol. Separate process on port 4566. SDK points at it via endpoint_url. LocalStack, MiniStack, floci, and fakecloud all work this way. Any AWS SDK in any language works. Cross-service wiring runs server-side.

If your tests are "does my Python function call boto3 correctly," Moto. If your tests are "does my whole system actually work end-to-end," HTTP server.

Two approaches among the HTTP servers

Among the HTTP emulators there's another split that matters, especially for AI-assisted dev and real integration tests:

Breadth-first: ship a large catalog of AWS services fast, with partial/surface coverage on each — enough to accept the common calls and return plausible shapes. Good when your tests lean lightly on many services.

Depth-first: ship fewer services but at 100% behavioral parity, with real code execution, real stateful backends, and real cross-service wire-ups. Good when your tests actually exercise cross-service flows, or when you want an AI coding agent to be able to rely on the emulator behaving like AWS.

These are philosophies, not rankings. Different workloads prefer different ones.

fakecloud

What it is: single static binary written in Rust, ~19 MB. Speaks the AWS wire protocol on port 4566. No account, no token, no paid tier. AGPL-3.0.

Approach: depth-first.

Explicit goal: 100% of AWS services, each at 100% behavioral conformance with 100% of cross-service integrations. Services are added one at a time; a service lands when it passes the full Smithy-model test variants and the cross-service wire-ups that matter for it — not when the API surface looks filled in. The roadmap is driven by real-project demand.

What it covers today: 23 services, 1,680 operations: S3, SQS, SNS, DynamoDB, Lambda, IAM, STS, KMS, Secrets Manager, SSM, CloudWatch Logs, CloudFormation, EventBridge, EventBridge Scheduler, SES (v2 + v1 inbound), Cognito User Pools, Kinesis, RDS, ElastiCache, Step Functions, API Gateway v2, Bedrock, Bedrock Runtime.

Distinctive choices driven by the depth-first goal:

Real Lambda execution across 13 runtimes in Docker containers — your function code runs, not a stub.
Real stateful backends: RDS runs real PostgreSQL/MySQL/MariaDB via Docker; ElastiCache runs real Redis/Valkey.
Cross-service wiring that actually fires: EventBridge -> Step Functions, S3 -> Lambda, SES inbound -> S3/SNS/Lambda, 15+ more integrations.
Multi-account, SCPs, ABAC, permission boundaries, session policies, KMS key policies, bucket policies — full Allow/Deny/NotPrincipal semantics.
First-party test-assertion SDKs in TypeScript, Python, Go, PHP, Java, Rust.
Conformance validated on every commit against 54,000+ Smithy-generated test variants, plus the upstream hashicorp/terraform-provider-aws TestAcc* suites.

Source: github.com/faiscadev/fakecloud

MiniStack

A free LocalStack alternative that surfaced during the March 2026 paywall window. Check the repo for current service coverage, architecture, and approach — the project moves quickly, so numbers in any blog post will be stale within weeks. Evaluate on your test suite's actual needs.

floci

Another free LocalStack alternative from the same window. Landing page publishes performance claims — verify them against the version you'd actually run before relying on the numbers. Evaluate on your test suite's actual needs.

Moto

Longest-lived open-source AWS mocking project. Python library, in-process, patches boto3. Broad service surface at varying depth. Excellent for Python unit tests where you want boto3 to respond plausibly inside your test process. Not usable from other languages, does not run Lambda code, does not talk to Terraform/CDK deploys.

Source: github.com/getmoto/moto

LocalStack Pro (for completeness)

Paid tier, mature catalog, commercial support, proprietary license. Fits teams OK with proprietary and per-seat pricing who need the whole LocalStack catalog.

How to pick

Avoid the temptation to pick by "which has more services." All four of the HTTP emulators (fakecloud, MiniStack, floci, LocalStack Pro) are moving targets; service counts change week to week. The durable questions are:

Do your tests exercise cross-service flows? (S3 triggers Lambda, EventBridge routes to Step Functions, SES inbound writes to S3, etc.) If yes, depth-first matters more than breadth. The emulator needs to actually wire those flows, not just accept each call in isolation.
Do you need real code execution? (Does your Lambda function actually run, or do you just need a response shape?) fakecloud runs Lambda code in real Docker runtimes; some alternatives return synthetic responses.
Do you need real stateful backends? (Does your Postgres schema matter? Your Redis data structures?) fakecloud runs real PostgreSQL/MySQL/MariaDB/Redis/Valkey; alternatives vary.
What language are your tests? Moto is Python-only. Everything else is language-agnostic over HTTP.
How much of AWS does your test mix actually hit? Open your test suite. Count unique AWS services called. That number is almost always smaller than "total AWS services" and is the only count that matters.

Run your real test suite against each option you're considering. That's the only benchmark that applies to your codebase.

LocalStack Ultimate covers 4 Bedrock ops. Here's why that's the wrong bet for tests.

Lucas Vieira — Thu, 23 Apr 2026 18:19:44 +0000

Originally published on fakecloud.dev.

If you've been looking for a local Bedrock emulator and landed on LocalStack's documentation, you've seen this: Bedrock is available, but only on the Ultimate plan, and only four operations are supported. Those four operations are backed by Ollama, the local-LLM runtime.

This is a real product decision, not an accident. It's worth understanding what it gets you, what it doesn't, and why fakecloud took a very different approach.

What LocalStack Ultimate gives you for Bedrock

Per docs.localstack.cloud/aws/services/bedrock, as of April 2026:

Tier: Ultimate plan only. This is the top paid tier.
Operations: InvokeModel, Converse, ListFoundationModels, CreateModelInvocationJob. Four, total.
Backend: Ollama, called via its HTTP API.
Models: whatever Ollama supports — Llama, Mistral, Phi, etc. You call them via ollama.<model-id> strings through the Bedrock SDK.
Limitations per the docs: only text models, no GPU, no persistence, and responsiveness issues on Docker Desktop due to storage/memory constraints.

That's the whole product. The "Bedrock" you're calling in your code is a LocalStack process forwarding your request to Ollama, which runs a model like Llama 3 on your CPU or GPU, and returns the response in a Bedrock-shaped envelope.

What that actually means at the test bench

Let's be concrete. You're writing tests for code that calls anthropic.claude-3-haiku-20240307-v1:0 (Haiku). You point your SDK at LocalStack Ultimate's Bedrock. What happens:

Haiku doesn't exist locally. You have to set DEFAULT_BEDROCK_MODEL=ollama.llama3.2 (or whichever Ollama model you have installed).
Your code's modelId: "anthropic.claude-3-haiku-20240307-v1:0" string gets routed to Llama 3.2.
Your prompt, which was tuned for Claude, runs through Llama, which interprets it differently.
The response comes back. Llama's output goes through Bedrock's response envelope shape.
Your code parses the envelope, extracts the text, and... what?

If your code is doing structured extraction (return JSON matching schema X), Llama and Claude don't produce identical JSON even at temperature 0. If your code is doing classification, they disagree on edge cases. If your code is doing agent work with tool use, they have different tool-use protocols entirely (Claude's tool-use format differs from Llama's function-calling format).

You are not testing your Claude code. You are testing whether your Claude code happens to also work against Llama when shimmed through a Bedrock envelope.

The slowness problem

Ollama on CPU: 1-30 seconds per call depending on model and prompt length.

Ollama on GPU (if you have one): 100ms-3s per call.

Bedrock on real AWS: 100-2000ms per call.

The "local" Bedrock is often slower than the cloud one. And you get non-determinism either way.

The LocalStack docs explicitly mention BEDROCK_PREWARM to reduce startup delays, which is an acknowledgment of the pain — you're essentially waiting for Ollama to load a multi-GB model into memory before your test suite can start. CI runners without --shm-size tuning routinely OOM during this.

The four operations

InvokeModel and Converse are the data plane — the calls your application makes at runtime. That's the part Ollama can back.

ListFoundationModels returns which models exist.

CreateModelInvocationJob starts an async batch job against S3 input. This is partial support (based on what the docs describe) — it's the only control-plane operation covered.

What's not covered:

Guardrails
Custom models / customization jobs
Model import
Inference profiles
Provisioned throughput
Model copy jobs
Prompt management
Foundation model agreements
Resource policies
Logging configuration
Evaluation jobs
Marketplace
Automated reasoning

If your test code touches anything in that list — and any serious Bedrock integration touches several of them — LocalStack Ultimate's Bedrock emulation doesn't help.

What fakecloud does differently

fakecloud covers 111 Bedrock operations. The data plane (InvokeModel, Converse, streaming variants) is not backed by a real LLM — it returns exactly the responses you configure, per-prompt rule.

This is the deliberate opposite of LocalStack Ultimate's choice:

	LocalStack Ultimate Bedrock	fakecloud Bedrock
Pricing	Top-tier paid plan	Free, AGPL-3.0
Data plane	Ollama (real local LLM)	Configurable responses per prompt rule
Determinism	No	Yes
Speed	1-30s per call	Milliseconds
Guardrails	Not supported	Full CRUD + real content evaluation
Custom models	Not supported	Full control plane
Async batch	Partial	Full flow
Prompt management	Not supported	Prompts + prompt routers
GPU required	Usually	No
Persistence	"Not supported" (from docs)	Yes

Why Ollama is the wrong backing for a Bedrock emulator

The word "emulator" and the word "Bedrock" together set an expectation: I can run a simulation of Bedrock locally. People reach for that when they want to test their Bedrock-calling code.

Testing code that calls an LLM API and testing an LLM are different problems. The first wants determinism, speed, fault injection, and call-history introspection. The second wants a real model.

LocalStack's Ultimate Bedrock chose the second. That decision makes sense if your goal is "let me prototype against a Bedrock SDK without burning tokens." It's the wrong decision if your goal is "let me have fast, deterministic integration tests of my production Bedrock code."

fakecloud picked the first job and optimized hard for it. If you want real inference locally, run Ollama directly — it's free, open source, and does that job excellently. If you want deterministic Bedrock behavior in your test suite, you want an emulator with configured responses.

When to pay for LocalStack Ultimate anyway

There are reasons to pay for LocalStack Ultimate that aren't about Bedrock. Their core strength is deep coverage of the long tail of AWS services — things like ACM, Certificate Manager, Backup, Config, etc. If you rely on those in your infrastructure and you want a local mirror of them, paying for Ultimate may be worth it.

If the Bedrock emulation is the reason you were about to open a procurement ticket for Ultimate, though, stop. Bedrock-on-Ollama isn't going to solve your test problem. What will solve it is an emulator built for tests — which you can get for free.

What to do next

If you're currently testing against real Bedrock, start with how to test Bedrock code locally — walks through the full pattern end to end.

If you're on LocalStack Ultimate and Bedrock was the draw, look at the migration comparison.

If you want to understand why "just use Ollama" doesn't work as a test strategy, here's a longer version of the argument.

Migrating from LocalStack to fakecloud in 10 minutes

Lucas Vieira — Wed, 22 Apr 2026 19:25:54 +0000

Canonical: fakecloud.dev/blog/migrate-from-localstack

In March 2026, LocalStack replaced its open-source Community Edition with a proprietary image that requires an account and an auth token. If your build broke last month, this guide is for you. If you are still on a pinned older tag and worried about the next pull, this is also for you.

fakecloud is a free, open-source AWS emulator — single binary, no account, no token, no paid tier — that covers the services most teams relied on LocalStack Community for, plus several that moved to LocalStack Pro (RDS, ElastiCache, Cognito User Pools, SES v2, API Gateway v2).

This guide is step-by-step. Copy, paste, done.

The one-line summary

Change the image or the install command. Keep http://localhost:4566 and your dummy credentials. Everything else stays the same.

Step 1: Stop LocalStack

docker compose down
# or: docker kill $(docker ps -q --filter ancestor=localstack/localstack)

Step 2: Install fakecloud

# Option A: single binary, no Docker
curl -fsSL https://raw.githubusercontent.com/faiscadev/fakecloud/main/install.sh | bash
fakecloud

# Option B: Docker
docker run --rm -p 4566:4566 ghcr.io/faiscadev/fakecloud

# Option C: cargo
cargo install fakecloud

fakecloud listens on http://localhost:4566 — same as LocalStack.

Step 3: Keep your SDK wiring

Your application code does not change. Endpoint URL and dummy credentials stay identical:

// TypeScript
import { S3Client } from "@aws-sdk/client-s3";
const s3 = new S3Client({
  endpoint: "http://localhost:4566",
  region: "us-east-1",
  credentials: { accessKeyId: "test", secretAccessKey: "test" },
  forcePathStyle: true,
});

# Python (boto3)
import boto3
s3 = boto3.client(
    "s3",
    endpoint_url="http://localhost:4566",
    aws_access_key_id="test",
    aws_secret_access_key="test",
    region_name="us-east-1",
)

Step 4: Update docker-compose.yml

Before:

services:
  localstack:
    image: localstack/localstack:latest
    ports:
      - "4566:4566"
    environment:
      - SERVICES=s3,sqs,sns,dynamodb,lambda
      - DEBUG=1

After:

services:
  fakecloud:
    image: ghcr.io/faiscadev/fakecloud:latest
    ports:
      - "4566:4566"

fakecloud starts all services by default (they are lazy and cheap — no SERVICES env var needed).

For Lambda execution you will need Docker-in-Docker or a mounted Docker socket (same as LocalStack Pro required):

services:
  fakecloud:
    image: ghcr.io/faiscadev/fakecloud:latest
    ports:
      - "4566:4566"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Step 5: Update GitHub Actions

Before:

services:
  localstack:
    image: localstack/localstack
    ports:
      - 4566:4566
    env:
      LOCALSTACK_AUTH_TOKEN: ${{ secrets.LOCALSTACK_TOKEN }}

After (install-and-run, no Docker):

steps:
  - run: curl -fsSL https://raw.githubusercontent.com/faiscadev/fakecloud/main/install.sh | bash
  - run: fakecloud &
  - run: |
      for i in $(seq 1 30); do
        curl -sf http://localhost:4566/_fakecloud/health && exit 0
        sleep 1
      done
      exit 1

~500ms startup vs ~3s for LocalStack container boot. On a cold CI runner the difference adds up over hundreds of test runs.

Step 6: Terraform

Provider block stays the same — only the running emulator changes.

provider "aws" {
  access_key                  = "test"
  secret_key                  = "test"
  region                      = "us-east-1"
  skip_credentials_validation = true
  skip_metadata_api_check     = true
  skip_requesting_account_id  = true

  endpoints {
    s3       = "http://localhost:4566"
    sqs      = "http://localhost:4566"
    dynamodb = "http://localhost:4566"
    lambda   = "http://localhost:4566"
  }
}

fakecloud's CI runs the upstream hashicorp/terraform-provider-aws TestAcc* suites against itself, so Terraform flows that worked against LocalStack Community should work against fakecloud.

Things that may need attention

SERVICES env var. Drop it. fakecloud starts all services by default.
LOCALSTACK_AUTH_TOKEN. Drop it.
Persisted state. LocalStack Pro has PERSISTENCE=1. fakecloud has --persist /path/to/dir.

Services that moved from LocalStack Community to Pro (and what fakecloud does)

Service	LocalStack Community now	fakecloud
Cognito User Pools	Paid only	122 ops, full auth flows + MFA
SES v2	Paid only	110 ops, full send + templates + DKIM
API Gateway v2	Paid only	28 ops, HTTP APIs + JWT/Lambda authorizers
RDS	Paid only	163 ops, real PostgreSQL/MySQL/MariaDB via Docker
ElastiCache	Paid only	75 ops, real Redis/Valkey via Docker
Bedrock	Not available	111 ops (control plane + runtime)

Test-assertion SDKs (bonus)

fakecloud ships test-assertion SDKs that let you inspect side effects from tests without raw HTTP:

import { FakeCloud } from "fakecloud";
const fc = new FakeCloud();

const { emails } = await fc.ses.getEmails();
expect(emails).toHaveLength(1);
expect(emails[0].destination.toAddresses).toContain("alice@example.com");

await fc.reset();

SDKs for TypeScript, Python, Go, PHP, Java, Rust. See the SDK docs.

Verify the migration

aws --endpoint-url http://localhost:4566 s3 mb s3://test-bucket
echo hello | aws --endpoint-url http://localhost:4566 s3 cp - s3://test-bucket/hello.txt
aws --endpoint-url http://localhost:4566 s3 ls s3://test-bucket/
aws --endpoint-url http://localhost:4566 s3 rb s3://test-bucket --force

If it works, migration is done.

Free, Open-Source LocalStack Alternative for AWS Testing

Lucas Vieira — Sat, 11 Apr 2026 14:36:32 +0000

In March 2026, LocalStack replaced its Community Edition with a proprietary image that requires an account and auth token. For teams that relied on LocalStack for local AWS testing, this broke CI pipelines and forced a choice: pay for a Pro license or find an alternative.

fakecloud is that alternative.

What is fakecloud?

fakecloud is a free, open-source local AWS emulator for integration testing and local development. It runs on a single port (4566), requires no account or auth token, and aims to faithfully replicate AWS behavior.

Currently supports 20 AWS services with 1,000+ API operations:

S3 — objects, multipart uploads, versioning, lifecycle, notifications
Lambda — real code execution via Docker, 13 runtimes, event source mappings
SQS — FIFO queues, dead-letter queues, long polling
SNS — fan-out to SQS/Lambda/HTTP, filter policies
DynamoDB — tables, transactions, PartiQL, streams, global tables
EventBridge — pattern matching, scheduled rules, API destinations
RDS — PostgreSQL/MySQL/MariaDB via Docker, snapshots, read replicas
ElastiCache — Redis/Valkey via Docker, replication groups, failover
SES — v2 API (97 operations), inbound email pipeline, event destinations
Cognito User Pools — authentication, MFA, user management
Kinesis — data streams, shard iterators, stream retention
Step Functions — ASL interpreter, Lambda/SQS/SNS/DynamoDB integrations
CloudWatch Logs — groups, streams, filtering, subscriptions
API Gateway v2 — HTTP APIs with Lambda integration
IAM, STS, SSM, Secrets Manager, KMS, CloudFormation

Full service list with operation counts

LocalStack vs fakecloud

In March 2026, LocalStack moved many previously-free services behind a paywall (Cognito, SES v2, RDS, ElastiCache, ECR, ECS). The Community Edition now requires authentication and has limited service availability.

Feature	fakecloud	LocalStack Community
License	AGPL-3.0 (free, open-source)	Proprietary
Auth required	No	Yes (account + token)
Commercial use	Free	Paid plans only
Docker required	No (standalone binary)	Yes
Startup time	~500ms	~3s
Idle memory	~10 MiB	~150 MiB
Install size	~19 MB binary	~1 GB Docker image
AWS services	20	30+
Test assertion SDKs	TypeScript, Python, Go, Rust	Python, Java
Cognito User Pools	80 operations	Paid only
SES v2	97 operations	Paid only
SES inbound email	Real receipt rule action execution	Stored but never executed
RDS	22 operations, PostgreSQL/MySQL/MariaDB via Docker	Paid only
ElastiCache	44 operations, Redis/Valkey via Docker	Paid only

LocalStack has more services overall, but many are behind a paywall. fakecloud focuses on implementing fewer services completely, with 100% conformance to AWS behavior.

Why we built fakecloud

LocalStack went proprietary. In March 2026, localstack:latest started requiring authentication. CI pipelines broke. The message was clear: LocalStack Community Edition was no longer community.

Correctness matters for testing. If you're building on AWS, your integration tests should talk to something that behaves like AWS — not mocks that return fake success responses. When fakecloud behaves differently from AWS, that's a bug we fix.

Real infrastructure, not stubs. fakecloud runs actual software via Docker: real Lambda runtimes (13 languages), real databases (PostgreSQL, MySQL, MariaDB), real Redis/Valkey instances. When your Lambda function reads from RDS, it's talking to an actual Postgres instance, not a mock.

Testing tools should be free. fakecloud is a development dependency, not production infrastructure. It should be free and open-source, the same way test frameworks like Jest, Mocha, and pytest are free.

How we verify correctness

fakecloud doesn't claim to be "AWS-compatible" without backing it up:

34,000+ conformance test variants validated against official AWS Smithy models, covering every operation parameter, boundary condition, and error case
280+ end-to-end tests using the official AWS SDKs (aws-sdk-rust, boto3, aws-sdk-js)
Automated testing against real AWS — our test suite runs against both fakecloud and actual AWS to verify behavioral parity

When tests fail, we fix the behavior. We don't stub responses or return fake success codes.

Getting started

Install and run fakecloud:

curl -fsSL https://raw.githubusercontent.com/faiscadev/fakecloud/main/install.sh | bash
fakecloud

Or via Docker:

docker run --rm -p 4566:4566 ghcr.io/faiscadev/fakecloud

Point your AWS SDK at http://localhost:4566 with dummy credentials:

aws --endpoint-url http://localhost:4566 sqs create-queue --queue-name test-queue

Test assertions with fakecloud SDKs

fakecloud exposes introspection endpoints that AWS doesn't provide, so you can assert on side effects in your tests:

import { FakeCloud } from "fakecloud";

const fc = new FakeCloud("http://localhost:4566");

// After your app sends an email via SES
const { emails } = await fc.ses.getEmails();
expect(emails).toHaveLength(1);
expect(emails[0].destination.toAddresses).toContain("user@example.com");

// After your Lambda processes an event
const { invocations } = await fc.lambda.getInvocations();
expect(invocations[0].statusCode).toBe(200);

SDKs available for TypeScript, Python, Go, and Rust.

What's not implemented (yet)

fakecloud is younger than LocalStack and has fewer services. If you need EC2, ECS, or other services not listed above, LocalStack may still be your best option (if you're willing to pay for Pro).

We're prioritizing services based on real-world demand. Open an issue if there's a service you need.

Roadmap

Coming next:

Bedrock — AI/ML testing (high demand across the ecosystem)
Lambda Containers — practical container support with ECR
CloudFront — CDN configuration testing
CloudWatch Metrics — complete monitoring story alongside Logs
Athena — SQL analytics on S3
More RDS engines (Oracle, SQL Server)

Full roadmap

Other alternatives to LocalStack

Moto — Python-based AWS mocking library. More services than fakecloud (100+), but designed for unit tests with mocks rather than integration tests. Doesn't support cross-service integrations or real Lambda execution.

LocalStack Pro (paid) — If you need the full service catalog and don't mind paying, LocalStack Pro is mature and feature-complete.

Real AWS — For the highest fidelity, test against real AWS. fakecloud is for fast local iteration; real AWS is for pre-production validation.

Try fakecloud

Repo: github.com/faiscadev/fakecloud
Site: fakecloud.dev
Install: curl -fsSL https://raw.githubusercontent.com/faiscadev/fakecloud/main/install.sh | bash

If you find a case where fakecloud behaves differently from AWS, open an issue — that's a bug, and we'll fix it.

Originally published at fakecloud.dev

Why I'm building a free, open-source AWS emulator

Lucas Vieira — Mon, 06 Apr 2026 22:27:35 +0000

A few days ago, our CI started failing. The culprit: localstack:latest now requires an account and an auth token. Broken builds.

I'd seen LocalStack creeping toward proprietary for a while, but this was the moment it actually hit. A colleague noticed it at the same time as me, but I was already working on a fix. I patched the build, but the question stuck: how long can we keep using the old version until we start having real problems?

I don't trust mocks

I should back up. I care about tests a lot. Enough to become a maintainer of Chai.js. Enough that when I build something, the test infrastructure comes first.

But I have a specific opinion about what kind of tests matter. I hate mocks. Not the concept — the way most codebases use them. You end up with tests that don't test anything real. You're asserting that you call functions in the right order. You're verifying the plumbing, not the behavior.

The worst part is when mocked tests give you false confidence. I've seen tests that assert you do the wrong thing successfully — the mock doesn't care, it just returns what you told it to. Your tests pass. Your code has a bug. You ship it.

If you're building on AWS, you need integration tests that actually talk to something that behaves like AWS. Not a mock. Not a stub that returns 200 to everything. Something that implements the real behavior: if you call API A then API B, and AWS would produce side effect C, then your test environment should produce side effect C too.

That's what LocalStack used to give us. And that's what I wanted to keep — but free and open source.

So I built it

I started fakecloud on April 4th, 2026. Three days later: 13 AWS services, 300+ commits, 1,000+ tests.

That pace was possible because of two things. First, I used LLMs heavily throughout — not to generate code I don't understand, but as a force multiplier with strong guardrails. Every feature ships with E2E tests. The tests are the guardrails. If the LLM generates something that doesn't match real AWS behavior, the tests catch it.

Second, Rust. I chose Rust because I love static-typed compiled languages, and Rust's type system is genuinely amazing. You get the performance of no garbage collector without having to manually manage memory. It means fakecloud starts in under 100ms and runs as a single binary — no Docker required, no runtime dependencies.

Correctness is the whole point

fakecloud doesn't try to be a scalable production cloud. It's not that. It's a testing tool. And the one thing a testing tool needs to get right is correctness.

What does that mean in practice? If you call CreateQueue, then SendMessage, then ReceiveMessage on real AWS and get back your message with specific attributes — fakecloud should do exactly the same thing. If it doesn't, that's a fakecloud bug.

We currently verify this with 280+ E2E tests that use the official aws-sdk-rust crate and 34,856 auto-generated conformance test variants validated against official AWS Smithy models — covering all 983 API operations across 13 services at 100% conformance. The plan for the near future: set up a real AWS account and run our test suite against both fakecloud and real AWS side by side, so we can verify behavioral parity automatically.

What's here today

13 services, 983 API operations, all open source, all free:

S3 (107 actions) — objects, multipart uploads, versioning, lifecycle, notifications, encryption
SQS (23 actions) — FIFO queues, dead-letter queues, long polling, batch operations
SNS (34 actions) — fan-out to SQS, HTTP delivery, filter policies, platform applications
EventBridge (57 actions) — pattern matching, scheduled rules, connections, API destinations, endpoints
IAM (128 actions) — users, roles, policies, groups, instance profiles, OIDC/SAML providers
STS (11 actions) — assume role, session tokens, federation, credential expiration
SSM (146 actions) — parameters, documents, commands, maintenance windows, associations, automation, sessions
DynamoDB (57 actions) — tables, items, transactions, PartiQL, backups, global tables, streaming
Lambda (10 actions) — function CRUD, invoke, event source mappings
Secrets Manager (23 actions) — versioning, soft delete, rotation, replication, resource policies
CloudWatch Logs (113 actions) — groups, streams, filtering, deliveries, transformers, anomaly detection
KMS (53 actions) — encryption, aliases, key management, grants, custom key stores
CloudFormation (8 actions) — template parsing, resource provisioning

Services talk to each other: S3 notifications deliver to SNS/SQS. SNS fans out to SQS. EventBridge rules fire on schedule and deliver to targets. This is the kind of cross-service behavior that matters in integration tests and that most emulators get wrong or skip entirely.

Try it

curl -fsSL https://raw.githubusercontent.com/faiscadev/fakecloud/main/install.sh | bash
fakecloud

Then point any AWS SDK at http://localhost:4566 with dummy credentials. That's it.

The code is at github.com/faiscadev/fakecloud. It's AGPL-3.0 — free and open source, including for commercial use.

If you need a local AWS emulator for your integration tests, give it a try. And if something doesn't behave like real AWS — open an issue. That's a bug, and we'll fix it.

DEV Community: Lucas Vieira

Testing Bedrock Guardrails without the AWS bill

The shape of the problem

Against fakecloud

What's actually evaluated

Versioning

A realistic test suite

Why this matters for agent systems

Links

Free LocalStack alternatives in 2026: fakecloud, MiniStack, floci, Moto

The architectural split that matters

Two approaches among the HTTP servers

fakecloud

MiniStack

floci

Moto

LocalStack Pro (for completeness)

How to pick

Links

LocalStack Ultimate covers 4 Bedrock ops. Here's why that's the wrong bet for tests.

What LocalStack Ultimate gives you for Bedrock

What that actually means at the test bench

The slowness problem

The four operations

What fakecloud does differently

Why Ollama is the wrong backing for a Bedrock emulator

When to pay for LocalStack Ultimate anyway

What to do next

Links

Migrating from LocalStack to fakecloud in 10 minutes

The one-line summary

Step 1: Stop LocalStack

Step 2: Install fakecloud

Step 3: Keep your SDK wiring

Step 4: Update docker-compose.yml

Step 5: Update GitHub Actions

Step 6: Terraform

Things that may need attention

Services that moved from LocalStack Community to Pro (and what fakecloud does)

Test-assertion SDKs (bonus)

Verify the migration

Links

Free, Open-Source LocalStack Alternative for AWS Testing

What is fakecloud?

LocalStack vs fakecloud

Why we built fakecloud

How we verify correctness

Getting started

Test assertions with fakecloud SDKs

What's not implemented (yet)

Roadmap

Other alternatives to LocalStack

Try fakecloud

Why I'm building a free, open-source AWS emulator

I don't trust mocks

So I built it

Correctness is the whole point

What's here today

Try it