Testing SNS to S3 Triggers Locally in 500ms

Unknown — Tue, 19 May 2026 00:00:00 +0000

Mocking individual AWS services is a common strategy that leads to production failures. When you mock a call to sns.Publish</code> or s3.PutObject</code>, you are testing your ability to write a mock, not the infrastructure's ability to handle the event. In a real-world event-driven system, the failure points live in the gaps between services: the IAM policy that doesn't quite allow the SNS fanout, the S3 bucket notification configuration that points to a non-existent ARN, or the Lambda trigger that fails because of a malformed event payload.

As of 2026-05-13, the landscape for local AWS development has shifted. With major incumbents moving to proprietary models and requiring mandatory auth tokens even for local runs, developers need a high-fidelity, zero-friction alternative. fakecloud</a> provides a standalone ~19MB binary that starts in ~500ms, offering 100% API conformance across 2,591 operations without requiring an account, internet connection, or subscription.

The Integration Gap: Why Mocks Fail</h2> Traditional unit testing with mocks assumes that if your code calls an API correctly, the infrastructure will behave as expected. This assumption is dangerous in complex integrations like an SNS-to-S3 trigger workflow. Consider a scenario where an SNS message triggers a fanout to multiple S3 buckets or a Lambda function that subsequently writes to S3. If you mock the SNS client, you never verify: The actual JSON structure of the event delivered to the subscriber.</li> The latency and retry logic inherent in the SNS-to-S3 delivery path.</li> The cross-service permissions required for the integration to function.</li> </ol> fakecloud eliminates this gap by running the actual service logic locally. When your application publishes to a fakecloud SNS topic, the binary executes the fanout logic, constructs the real event payload, and delivers it to the local S3 or Lambda service exactly as the AWS production environment would. Scenario: The SNS-to-S3 Fanout</h2> In this walkthrough, we will implement a common architectural pattern: an SNS topic that receives a message and triggers an S3 upload via a Lambda function. This tests the full chain of command: SNS -> Lambda -> S3</code>. The "No" List</h3> Before we start, note what you do not need: No AWS account.</li> No AWS_ACCESS_KEY_ID</code> validation (use dummy</code> for everything).</li> No internet connection.</li> No Docker (unless you are running Lambda functions).</li> No auth tokens or login commands.</li> </ul> Execution: Launching the Stack</h2> First, start the fakecloud binary. It listens on the standard port 4566 and is ready to accept requests in less than half a second. # Start the fakecloud binary ./fakecloud # In a separate terminal, configure your local resources export AWS_ENDPOINT_URL="http://localhost:4566" export AWS_ACCESS_KEY_ID="dummy" export AWS_SECRET_ACCESS_KEY="dummy" export AWS_REGION="us-east-1" # 1. Create the SNS Topic TOPIC_ARN=$(aws sns create-topic --name local-events --query "TopicArn" --output text) # 2. Create the S3 Bucket aws s3 mb s3://processed-data # 3. Create the Lambda function (using a pre-built zip) aws lambda create-function \ --function-name s3-uploader \ --runtime python3.12 \ --handler index.handler \ --role arn:aws:iam::000000000000:role/lambda-role \ --zip-file fileb://function.zip # 4. Subscribe the Lambda to the SNS Topic aws sns subscribe \ --topic-arn "$TOPIC_ARN" \ --protocol lambda \ --notification-endpoint arn:aws:lambda:us-east-1:000000000000:function:s3-uploader</code></pre> At this point, your local environment is fully wired. The fakecloud binary is managing the state of 39 AWS services in-memory, backed by 86,327 Smithy-model-generated test variants to ensure the API responses match AWS exactly. 100% Conformance Across 2,591 Operations</h2> fakecloud is not a collection of simple mocks. It is a high-fidelity emulator built on the Smithy models used by AWS to define their own APIs. As of May 2026, fakecloud supports 2,591 operations with 100% behavioral conformance. This includes complex behaviors like: Service</th> Supported Operations</th> Key Integration Features</th></tr></thead> SNS</td> 48</td> Fanout to SQS, Lambda, and HTTP; Message Filtering; Attributes.</td></tr> S3</td> 124</td> Multipart uploads; Bucket notifications; Lifecycle policies; Object tagging.</td></tr> Lambda</td> 62</td> 23+ runtimes; Event source mappings; Layer support; Synchronous/Asynchronous invocation.</td></tr> Bedrock</td> 111</td> Full support for frontier models (Claude 4.7, GPT-5.5) as of 2026-05-13.</td></tr> </tbody></table> This depth ensures that when you call sns.Publish</code>, the message doesn't just disappear into a black hole. It is parsed, filtered according to your subscription attributes, and delivered to the target. If the target is a Lambda function, fakecloud spins up the appropriate container, injects the event, and captures the logs. Assertion: Using the fakecloud SDK</h2> Testing asynchronous integrations often involves "sleep and pray" or complex polling logic. You upload a file and then poll S3 for 10 seconds hoping the Lambda finished its work. fakecloud solves this with first-party SDKs for assertions in 6+ programming languages (TypeScript, Python, Go, PHP, Java, and Rust). Instead of polling the public AWS API, you use the fakecloud SDK to inspect the internal state of the emulator. This allows for deterministic, sub-second test execution. import boto3 from fakecloud_sdk import FakeCloudClient # Standard AWS SDK for the application logic sns = boto3.client("sns", endpoint_url="http://localhost:4566") # fakecloud SDK for the test assertions fc = FakeCloudClient(endpoint="http://localhost:4566") def test_sns_to_s3_trigger(): # 1. Trigger the workflow sns.publish(TopicArn=topic_arn, Message="test-payload") # 2. Assert using the fakecloud SDK # This checks the internal event queue to ensure the message was processed integration_state = fc.inspect_integration(source="sns", target="lambda") assert integration_state.successful_invocations == 1 # 3. Verify the final side effect in S3 s3 = boto3.client("s3", endpoint_url="http://localhost:4566") response = s3.list_objects_v2(Bucket="processed-data") assert len(response.get("Contents", [])) == 1</code></pre> By using the inspect_integration</code> method, you eliminate the non-determinism of local testing. You are asserting on the fact that the event loop completed, not just that the initial API call returned a 200 OK. AI Development: Local Bedrock Support</h2> As of 2026-05-13, AI integration is a core part of the AWS ecosystem. fakecloud includes full support for Amazon Bedrock (111 operations), allowing you to develop agentic workflows locally. This is particularly useful for testing how your SNS-triggered Lambda functions interact with foundation models like Claude 4.7 or the latest Amazon Nova Premier models. Because fakecloud is a single binary, you can run these AI integration tests in restricted environments where internet access is prohibited for security reasons. You can configure deterministic responses for Bedrock prompts, allowing you to test your application's parsing logic and error handling without incurring costs or dealing with the latency of frontier model APIs. Performance Benchmarks: fakecloud vs. Incumbents</h2> In a modern CI/CD pipeline, every second matters. Traditional local AWS emulators often rely on heavy container orchestration, leading to multi-minute startup times and high memory overhead. fakecloud is designed for engineering pragmatism. Metric</th> fakecloud</th> Proprietary Incumbents</th></tr></thead> Binary Size</td> ~19 MB</td> ~250 MB+ (Docker Image)</td></tr> Startup Time</td> ~500 ms</td> 30 - 90 seconds</td></tr> Idle Memory</td> ~10 MiB</td> 1.5 GiB+</td></tr> Auth Required</td> No</td> Yes (Auth Token/Account)</td></tr> Internet Required</td> No</td> Yes (for license checks)</td></tr> License</td> AGPL-3.0</td> Proprietary / Paid Tier</td></tr> </tbody></table> Running fakecloud as a background process in your GitHub Actions or GitLab CI runner adds negligible overhead. You can spin up a fresh environment for every single test file, ensuring total isolation without the performance penalty of restarting a heavy container stack. Real Cross-Service Integrations</h2> The power of fakecloud lies in its ability to handle "Real" integrations. When we say 100% conformance, we mean the wire protocol and the side effects. SNS Fanout: If you subscribe three different SQS queues to one SNS topic, fakecloud will deliver the message to all three, respecting individual filter policies.</li> S3 Triggers: fakecloud supports the full S3 notification configuration, including prefix/suffix filtering and all event types (s3:ObjectCreated:*</code>, s3:ObjectRemoved:*</code>, etc.).</li> SES Inbound: You can simulate receiving an email in SES and have it automatically trigger an SNS notification or save the raw email to an S3 bucket.</li> </ul> These are not hard-coded shortcuts. They are the result of a unified event-bus architecture within the fakecloud binary that mirrors the asynchronous nature of the AWS cloud. Engineering Pragmatism: The AGPL-3.0 Advantage</h2> fakecloud is released under the AGPL-3.0 license for local development. This ensures that the tool remains free and open-source, protecting developers from the sudden "proprietary pivots" that have affected other tools in the space. You can audit the source code, contribute fixes, and run it in any environment—from a disconnected laptop on a plane to a high-security air-gapped server—without ever asking for permission or providing a credit card. Your development workflow should not be dependent on a third-party's uptime or licensing server. By moving your integration tests to a standalone binary, you regain control over your test suite's reliability and speed. Next Steps: Beyond SNS and S3</h2> Testing SNS to S3 triggers is only the beginning. The same sub-second feedback loop applies to more complex architectures involving SQS dead-letter queues, DynamoDB Streams, and EventBridge pipes. To explore further integration patterns, run the following command to see the full list of supported operations for your specific service mix: ./fakecloud --list-operations --service dynamodb</code></pre> For detailed implementation guides on setting up local SQS-to-Lambda triggers or DynamoDB global tables, visit the fakecloud documentation. Start your local environment, run your tests, and inspect the results—all before your cloud-based CI environment would have even finished its authentication handshake. Local ECR with real `docker push`: what LocalStack and Moto miss, and what fakecloud ships Unknown — Thu, 23 Apr 2026 00:00:00 +0000 If your integration tests build or pull a container image and push it to ECR — CDK docker assets, ECS task definitions, Lambda container images, GitHub Actions workflows — you've hit the wall. LocalStack gates ECR behind its paid Pro tier (the March 2026 shift to proprietary builds also means Community users have no ECR at all). Pro users who actually try docker push</code> hit #7186 "EOF for ecr/getCredentials"</a>, #5598 "pushed image, describe says ImageNotFound"</a>, #8128 "connection refused / 403 on docker push"</a>, and #12043 non-us-east-1 ECR timeouts</a>. The bugs are still open. Moto ships an ECR control plane — you can call CreateRepository</code> and DescribeImages</code> from boto3 — but Moto is not a real HTTP server for the OCI protocol. docker push localhost:…/your-repo</code> doesn't work because the /v2/<name>/blobs/uploads/</code> endpoints don't exist. If your tests rely on CDK building and pushing a docker asset, Moto is a dead end. Most teams end up running a standalone registry:2</code> container alongside their test harness. That works for raw Docker, but registry:2</code> doesn't expose DescribeRepositories</code>, BatchGetImage</code>, PutLifecyclePolicy</code>, or any of the other AWS-shaped operations. CDK, Terraform, and the AWS CLI can't talk to it. What fakecloud ships</h2> fakecloud implements ECR end-to-end: all 58 operations in AWS's Smithy model and the OCI v2 Distribution HTTP protocol that Docker uses on the wire. Both back onto the same content-addressed sha256 blob store, so a layer pushed by docker push</code> is visible via BatchCheckLayerAvailability</code>, and an image manifest uploaded via PutImage</code> can be docker pull</code>ed. # Start fakecloud. curl -fsSL https://fakecloud.dev/install.sh | bash fakecloud & # Docker login works. aws --endpoint-url http://localhost:4566 ecr get-login-password \ | docker login --username AWS --password-stdin localhost:4566 # Push an image. aws --endpoint-url http://localhost:4566 ecr create-repository --repository-name demo docker pull busybox:latest docker tag busybox:latest localhost:4566/demo:latest docker push localhost:4566/demo:latest # The AWS SDK sees it. aws --endpoint-url http://localhost:4566 ecr describe-images --repository-name demo</code></pre> GetAuthorizationToken</code> returns base64("AWS:<token>")</code> with a 12-hour expiry matching real AWS. The /v2/</code> endpoints honor Basic Auth and issue a WWW-Authenticate: Basic realm="fakecloud-ecr"</code> challenge on the initial unauthenticated request, so Docker's two-phase login does its handshake cleanly. What else lands in the 58-op surface</h2> Lifecycle policy evaluation, not storage. PutLifecyclePolicy</code> applies immediately — imageCountMoreThan</code> and sinceImagePushed</code> rules actually prune images, ordered by rulePriority</code> per AWS semantics. GetLifecyclePolicyPreview</code> returns the digests that would be expired. No "stored but never evaluated" like LocalStack's SES receipt rules.</li> Image scanning. StartImageScan</code> stores a COMPLETE scan record that DescribeImageScanFindings</code> echoes back in the AWS-shaped payload. Real scanner integration is out of scope for a mock; a schema-complete synthetic shape lets you exercise your findings plumbing.</li> Pull-through cache rules. Full CRUD + Validate.</li> Registry policy, scanning config, replication config, repository creation templates, signing configuration, pull-time exclusions. Every operation AWS lists.</li> Smithy-exact validation. @length</code> / @range</code> / @enum</code> / @required</code> traits enforced everywhere — garbage inputs return InvalidParameterException</code> / ImageDigestDoesNotMatchException</code> / LayerDigestMismatchException</code>, not silent success.</li> </ul> Assert on what was pushed</h2> fakecloud exposes an introspection API at /_fakecloud/ecr/...</code> so your test code can check pushed images without parsing Docker output: import { FakeCloud } from "fakecloud"; const fc = new FakeCloud(); const { repositories } = await fc.ecr.getRepositories(); const { images } = await fc.ecr.getImages("demo"); expect(repositories).toHaveLength(1); expect(images[0].imageTags).toContain("latest"); expect(images[0].imageDigest).toMatch(/^sha256:/);</code></pre> The same API is available from Go, Python, Java, PHP, and Rust. Conformance</h2> 58/58 ECR operations, 1,789/1,789 generated variant probes passing (100%) — this runs on every commit against AWS's Smithy model. The Smithy model drives positive probes (does the call succeed with sensible input?) and negative probes (does a missing required field, a too-long string, an out-of-range integer, a non-enum enum, return the right error code?). fakecloud's baseline is now 61,741/61,743 across the whole workspace. Where next</h2> ECR is the prerequisite for ECS, which is the next item on the roadmap. ECS builds on the same Docker runtime pattern fakecloud already uses for Lambda — pull a real container image (from the local ECR we just built), run it, expose it via the ECS API. The moment that ships, the CDK-ECS-ECR pipeline works end-to-end in local tests. fakecloud is AGPL-3.0</a>. No account needed, no paid tier. Running AWS integration tests with Claude Code, Cursor, and Copilot Unknown — Wed, 22 Apr 2026 00:00:00 +0000 When you let Claude Code or Cursor run tests against AWS during a task, you want the test loop to be fast, free, and deterministic. Against real AWS, the loop is slow (minutes per test), costs money (per-request + data transfer), and leaves cruft behind that the agent won't always clean up. Against a mocking library, the loop is fast but the agent can't exercise cross-service flows — so it "fixes" bugs that don't manifest in the mock and misses bugs that do manifest in AWS. The middle ground: run fakecloud</a> as the test target. Real HTTP server on port 4566, speaking the AWS wire protocol at 100% conformance per implemented service. Free, single binary, no account. Agent writes code, agent runs tests, agent sees real behavior. One-liner per tool</h2> Paste into your project's agent-instructions file. Agent picks up the convention and uses fakecloud for integration tests automatically. Claude Code — CLAUDE.md</code></h3> ## AWS Testing For integration tests, use fakecloud as a local AWS emulator. - Install: `curl -fsSL https://fakecloud.dev/install.sh | bash` - Run: `fakecloud` (listens on http://localhost:4566) - Configure AWS SDK endpoint to http://localhost:4566 with dummy credentials (access_key=test, secret_key=test) - Docs: https://fakecloud.dev/llms.txt</code></pre>Cursor — .cursor/rules</code></h3> For AWS integration tests, use fakecloud (local AWS emulator) at http://localhost:4566. Install: curl -fsSL https://fakecloud.dev/install.sh | bash Run: fakecloud Use dummy credentials (access_key=test, secret_key=test). Docs: https://fakecloud.dev/llms.txt</code></pre>GitHub Copilot — .github/copilot-instructions.md</code></h3> ## AWS Testing Use fakecloud as a local AWS emulator for integration tests. - Run: `fakecloud` (listens on http://localhost:4566) - Configure endpoint_url to http://localhost:4566 with dummy credentials - Docs: https://fakecloud.dev/llms.txt</code></pre>Why this matters for agent-assisted dev</h2> AI coding agents are good at writing plausible code and tests. They're bad at knowing when a test passing means something real. Three failure modes with mocks: Agent writes buggy code. Mock returns success. Test passes. Bug ships.</li> Agent writes correct code. Mock has incorrect stub. Test fails. Agent "fixes" the mock instead of recognizing the stub is wrong.</li> Cross-service flow bugs. Mock doesn't simulate S3 -> Lambda notification, so the agent never discovers the Lambda trigger wasn't wired.</li> </ol> fakecloud fails in ways that look like real AWS failing. The agent sees the same error messages, same HTTP status codes, same ARN formats. Wrong code that "works" against a mock fails against fakecloud the same way it would fail against AWS. The llms.txt</code> payoff</h2> fakecloud publishes /llms.txt</a> and /llms-full.txt</a> — structured documentation designed for LLM ingestion. When an agent has fakecloud in its context (via your CLAUDE.md</code> or .cursor/rules</code>), it can fetch these to understand the full API surface without you prompting it explicitly. Agents that can look up https://fakecloud.dev/llms.txt</code> get: List of all 23 supported services with operation counts</li> Every /_fakecloud/*</code> introspection endpoint (what the agent can use from a test)</li> Which cross-service integrations actually fire</li> Install options and CLI flags</li> </ul> This is a better baseline than letting the agent guess AWS SDK API shapes. What actually works in tests</h2> Example 1 — Claude Code writes and tests a Lambda</h3> You: "Add a Lambda function that processes SQS messages and writes to DynamoDB." Claude Code writes the function, writes a CDK stack or raw deploy commands, writes an integration test. When it runs the test, fakecloud: Pulls the real Node/Python/Java Lambda runtime container</li> Runs the handler against the real SQS message shape</li> Persists the DynamoDB write to a real in-process store</li> Returns the exact same errors real AWS would (field validation, permission errors, quota errors)</li> </ul> Claude Code sees success = success, failure = failure. No hallucinated stub behavior. Example 2 — Cursor exercises a Step Function</h3> You: "Write a Step Function that orchestrates order fulfillment (validate payment -> reserve inventory -> send confirmation email)." Cursor writes the ASL, deploys via CDK, runs StartExecution</code> as a test. fakecloud: Runs the full ASL interpreter (Pass, Task, Choice, Wait, Parallel, Map, Succeed, Fail, Retry/Catch)</li> Invokes the Lambda tasks with real runtime execution</li> Actually sends the SES email (visible via GET /_fakecloud/ses/emails</code>)</li> Returns the execution state the way Step Functions would</li> </ul> Cursor asserts on the final execution state + SES email count. No ambiguity. Example 3 — Copilot tests SES inbound flow</h3> You: "When an email hits support@example.com, parse it, classify with Bedrock, file a ticket in DynamoDB." Copilot sets up the SES receipt rule, the Lambda action, the Bedrock invocation, the DynamoDB write. fakecloud: Actually executes the receipt rule when test email arrives (LocalStack Community stores them but doesn't execute)</li> Runs the Lambda for real</li> Invokes the Bedrock endpoint with a configurable mock response (POST /_fakecloud/bedrock/runtime/mock-response</code>)</li> Writes the DynamoDB row for real</li> </ul> Copilot's tests assert on the DynamoDB row appearing + the SES email being consumed. End-to-end, no gaps. CI and the agent loop</h2> If the agent writes CI configuration, it should run fakecloud as a service: # .github/workflows/test.yml — generated by the agent jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: curl -fsSL https://fakecloud.dev/install.sh | bash - run: fakecloud & - run: | for i in $(seq 1 30); do curl -sf http://localhost:4566/_fakecloud/health && break sleep 1 done - run: npm ci && npm test env: AWS_ENDPOINT_URL: http://localhost:4566 AWS_ACCESS_KEY_ID: test AWS_SECRET_ACCESS_KEY: test AWS_REGION: us-east-1</code></pre> ~500ms fakecloud startup means agent iteration stays tight. Assertions agents can write directly</h2> fakecloud's test-assertion SDKs give agents a clean interface for "did the thing happen": import { FakeCloud } from 'fakecloud'; const fc = new FakeCloud(); // Agent-written test test('order flow sends confirmation', async () => { await placeOrder({ id: 'o1', email: 'buyer@example.com' }); // Agent asserts the email was sent const { emails } = await fc.ses.getEmails(); expect(emails).toHaveLength(1); expect(emails[0].destination.toAddresses).toContain('buyer@example.com'); // Agent asserts the Lambda fired const { invocations } = await fc.lambda.getInvocations({ functionName: 'on-order' }); expect(invocations[0].statusCode).toBe(200); }); afterEach(() => fc.reset());</code></pre> SDKs: TypeScript, Python, Go, PHP, Java, Rust. Agents that prefer HTTP can hit /_fakecloud/*</code> directly. The reset-between-tests pattern</h2> afterEach(async () => { await fetch('http://localhost:4566/_fakecloud/reset', { method: 'POST' }); });</code></pre> Instant reset across every service. Agent-generated test suites stay isolated without per-test resource naming ceremony. Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh | bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> LLM-ingestion docs: fakecloud.dev/llms.txt</a> + llms-full.txt</a></li> Lambda tutorial: Test Lambda locally</a></li> CI tutorial: Integration testing AWS in GitHub Actions</a></li> Moto equivalent for non-Python: Moto equivalent for Go/Java/Node</a></li> </ul> Testing Bedrock Guardrails without the AWS bill Unknown — Wed, 22 Apr 2026 00:00:00 +0000 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</code>, or call ApplyGuardrail</code> 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</code>, versioning, UpdateGuardrail</code>, DeleteGuardrail</code>, ApplyGuardrail</code>, ListGuardrails</code> — 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</h2> 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.', )</code></pre> Now you want to test: does an email containing bob@example.com</code> 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</h2> 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'])</code></pre> 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</h2> 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.</li> Content filters: keyword + pattern matching tuned for the common categories. HIGH strength catches more, LOW catches less — same directional behavior as real AWS.</li> 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.</li> Word filters: exact match + stemming.</li> Regex filters: the regex you supplied, as-is.</li> </ul> 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</h2> # 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': '...'}}], )</code></pre> 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</h2> 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"); });</code></pre> 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</h2> 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.</li> 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.</li> On merge to main, deploy the same config to real AWS.</li> </ol> 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. Links</h2> Bedrock emulator (landing): /bedrock-emulator/</a></li> Test Bedrock locally: /test-bedrock-locally/</a></li> Why not a real LLM in tests: /blog/bedrock-tests-real-llm/</a></li> Testing LLM guardrails (broader view): /blog/llm-guardrails/</a></li> GitHub: github.com/faiscadev/fakecloud</a></li> </ul> Why your Bedrock tests shouldn't call a real LLM (not even a local one) Unknown — Wed, 22 Apr 2026 00:00:00 +0000 Every team building on Bedrock eventually asks the same question: for tests, should we call a real model? If the cost of real Bedrock is the concern, can we run Ollama locally and point our SDK at that? The answer is no — but the reason is worth spelling out, because it shapes how you should think about tests for any LLM-calling code. What a test is for</h2> A test asserts that your code behaves correctly under a given input. Not that a model behaves correctly. Not that an API is up. Just that the code you wrote, given a response from its upstream, does the thing you expected. The upstream, for Bedrock code, is InvokeModel</code> or Converse</code>. Your code sends a prompt, gets a response, and does something with it: parses JSON, branches on a label, stores it in a DB, passes it to another tool call, retries on throttling, falls back on a cheaper model. Every one of those behaviors is yours to test. The model's behavior is AWS's problem. What goes wrong with real models in tests</h2> Once you try to use real inference — whether it's actual Bedrock or a local Ollama — four things break, in roughly ascending order of annoyance: 1. Non-determinism</h3> Real models return different text on every call. Temperature = 0 doesn't save you: there's non-determinism in attention kernel implementations across GPU/CPU backends, in tokenizer versions, in batching behavior. Anthropic's own docs say "don't rely on deterministic outputs." What this means for tests: // hope this passes expect(output).toBe("Classification: spam");</code></pre> On run 1 the model returned "Classification: spam"</code>. On run 2 it returned "The email is spam."</code>. Both correct. Your test fails. The usual fix is to assert loosely: expect(output.toLowerCase()).toContain("spam");</code></pre> This passes even if the model returns "This is not spam"</code>. Your test is now worthless. People end up using LLM-as-judge ("ask Claude if this response is approximately correct"). That's a research paper, not a CI pipeline. 2. Speed</h3> Real Bedrock: 100-2000ms per call. Ollama on a developer laptop: 1-30s per call. Ollama on a CI runner without a GPU: 5-60s per call. A test suite with 50 tests hitting the model at 5s each is 4 minutes. Ten times that and your developers stop running tests locally. CI times out. The TDD loop dies. The whole point of unit tests — fast feedback — is gone. 3. Resource overhead</h3> Ollama-sized models are 3-70 GB on disk. docker pull</code> on a CI runner taking 3 GB of layer cache makes your pipeline brittle. A laptop without a GPU starts thrashing memory and swapping. You now need an infrastructure project just to make tests runnable, which is the opposite of "tests should be easy to run." 4. You're testing the wrong thing</h3> Even if determinism, speed, and memory weren't problems, the thing you'd be testing is whether the model handles the prompt correctly. That's AWS's problem. Your code could be catastrophically broken — build requests wrong, parse responses wrong, handle errors wrong — and if the model happens to hallucinate a passable answer, your test passes. Conversely, if the model has a bad day (bad weights snapshot, a silent version bump), your tests fail even though your code is fine. You spend an hour bisecting the CI failure only to discover Claude got 3% worse at following instructions last Tuesday. This inverts cause and effect. Tests should tell you about your code. They shouldn't be a regression suite against a foundation model. What tests actually need</h2> Deterministic output. Given the same input, same output. Every time.</li> Configurable responses. Different tests want the model to return different things. You want to control that explicitly.</li> Fault injection. Your retry logic needs to be exercised. Your fallback-model logic needs to be exercised. Your rate-limit handler needs to be exercised. You can't wait for real throttling to happen.</li> Call history. Did my code send the right prompt? Did it set the right temperature? Did it include the right system message? Right tool definitions? Those are assertions about your code.</li> Sub-millisecond latency. Tests should fly.</li> No external dependencies. CI should work offline.</li> </ol> A real LLM gives you none of those. A mock library (moto, @aws-sdk-client-mock</code>) gives you 1, 2, and 4, but misses the HTTP path entirely — your code's request-assembly bugs go untested. The thing that gives you all six is a Bedrock emulator</a>: a real HTTP server speaking Bedrock's wire protocol, with configurable responses and fault injection. That's what fakecloud is. What this looks like in practice</h2> You write a test. You configure fakecloud to return a specific response when it sees a specific prompt. Your code runs. It sends a real HTTP request to localhost:4566</code>. The request is parsed by a real JSON parser, routed through a real request validator, and responded to with your fixture. Your code parses the response, does its thing, and you assert on the outcome. import { FakeCloud } from "fakecloud"; import { BedrockRuntimeClient, InvokeModelCommand, } from "@aws-sdk/client-bedrock-runtime"; const fc = new FakeCloud(); const rt = new BedrockRuntimeClient({ endpoint: "http://localhost:4566" }); beforeEach(() => fc.reset()); test("spam classifier marks borderline scores for human review", async () => { await fc.bedrock.setResponseRule({ whenPromptContains: "classify spam", respond: { completion: JSON.stringify({ label: "borderline", confidence: 0.62 }), }, }); const { routedTo } = await classifyEmail(rt, "buy now!!"); expect(routedTo).toBe("human-review"); }); test("classifier retries on throttling with backoff", async () => { await fc.bedrock.injectFault({ operation: "InvokeModel", error: "ThrottlingException", count: 2, }); await fc.bedrock.setResponseRule({ whenPromptContains: "classify spam", respond: { completion: JSON.stringify({ label: "spam" }) }, }); const { routedTo } = await classifyEmail(rt, "buy now!!"); expect(routedTo).toBe("spam-folder"); expect((await fc.bedrock.getCallHistory()).length).toBe(3); });</code></pre> Both tests run in 30ms. Both are deterministic. Both test your code, not the model. But I want some tests that hit real Bedrock</h2> Good instinct. Keep those separate. Put them in a suite gated behind an env var (RUN_REAL_BEDROCK_TESTS=1</code>). Run them once per release, not once per PR. They'll catch: Major AWS API shape changes</li> Model version bumps that alter response format</li> IAM permission changes</li> </ul> That's a fundamentally different job from "did my PR break my code." Mixing them produces a test suite that's flaky, slow, expensive, and hides real regressions under model noise. The unit/integration suite, which is 99% of your runs, should hit fakecloud. The real-bedrock suite, which is a few dozen targeted tests, runs weekly. This is the same pattern every team that tests against cloud APIs converges on — you just have to name it. A word on Ollama</h2> Ollama is great. It's not a Bedrock emulator. It speaks its own HTTP protocol (roughly OpenAI-compatible), runs real models, and is the right tool for developer-time exploratory prompting. LocalStack's Ultimate tier wraps Ollama in a Bedrock-shaped response — you get real inference on the local machine through the Bedrock SDK. Interesting product. Wrong tool for tests. If you want to prototype a prompt, run Ollama directly. If you want to test the code that calls Bedrock with that prompt, use an emulator. Closing</h2> The "tests should use a real LLM" instinct comes from a reasonable place — a fear that mocks lie, that configured responses can drift from reality, that you'll ship a bug because your tests were checking something different than production. That fear is real, and the answer is a real server (an emulator) that speaks the real wire protocol. What you don't need is real inference. Your tests are about your code. The model is not your code. Links</h2> Bedrock emulator (landing): /bedrock-emulator/</a></li> Tutorial with running code: How to test Bedrock code locally, for free, deterministically</a></li> LocalStack alternative for Bedrock: /localstack-bedrock-alternative/</a></li> GitHub: github.com/faiscadev/fakecloud</a></li> </ul> CDK local testing: full flow with fakecloud and cdklocal Unknown — Wed, 22 Apr 2026 00:00:00 +0000 AWS CDK writes CloudFormation under the hood and ships it through the AWS SDK. That means "CDK local testing" boils down to one question: where does the SDK send its CreateStack / UpdateStack calls? Pointed at real AWS, you pay per resource, wait minutes per deploy, and have to remember to destroy. Pointed at a local emulator, you iterate fast and don't pay anything. This guide covers both flows (cdklocal</code> wrapper and plain cdk</code> with endpoint overrides) against fakecloud</a>, a free, open-source AWS emulator with real CloudFormation support (90 operations, template parsing, resource provisioning, custom resources, drift detection). Install fakecloud</h2> curl -fsSL https://fakecloud.dev/install.sh | bash fakecloud</code></pre> Listens on http://localhost:4566</code>. ~500ms startup. Option 1: plain cdk</code> with AWS_ENDPOINT_URL</code></h2> Simplest and works with any CDK version that uses AWS SDK v3 (CDK 2.67+). export AWS_ENDPOINT_URL=http://localhost:4566 export AWS_ACCESS_KEY_ID=test export AWS_SECRET_ACCESS_KEY=test export AWS_REGION=us-east-1 export CDK_DEFAULT_ACCOUNT=000000000000 export CDK_DEFAULT_REGION=us-east-1 cdk bootstrap cdk deploy</code></pre> That's it. Same cdk</code> binary you use for prod, pointed at fakecloud for dev. Option 2: cdklocal</code> wrapper</h2> If your team is already using cdklocal</code> (from the LocalStack ecosystem), it works the same way against fakecloud: cdklocal bootstrap --endpoint-url http://localhost:4566 cdklocal deploy --endpoint-url http://localhost:4566</code></pre>A minimal stack</h2> // lib/my-stack.ts import { Stack, StackProps } from 'aws-cdk-lib'; import { Bucket } from 'aws-cdk-lib/aws-s3'; import { Function, Runtime, Code } from 'aws-cdk-lib/aws-lambda'; import { Queue } from 'aws-cdk-lib/aws-sqs'; import { SqsEventSource } from 'aws-cdk-lib/aws-lambda-event-sources'; import { Construct } from 'constructs'; export class MyStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); const bucket = new Bucket(this, 'Uploads'); const queue = new Queue(this, 'Jobs'); const processor = new Function(this, 'Processor', { runtime: Runtime.NODEJS_20_X, handler: 'index.handler', code: Code.fromInline( `exports.handler = async (event) => ({ ok: true, received: event })` ), }); processor.addEventSource(new SqsEventSource(queue)); bucket.grantRead(processor); } }</code></pre> Deploy: cdk deploy</code></pre> Verify: aws --endpoint-url http://localhost:4566 cloudformation describe-stacks aws --endpoint-url http://localhost:4566 lambda list-functions aws --endpoint-url http://localhost:4566 s3 ls</code></pre> Trigger the flow: echo "hi" | aws --endpoint-url http://localhost:4566 s3 cp - s3://$(aws --endpoint-url http://localhost:4566 s3api list-buckets --query 'Buckets[0].Name' --output text)/file.txt aws --endpoint-url http://localhost:4566 logs tail /aws/lambda/MyStack-Processor --since 1m</code></pre> Your Lambda code actually runs (fakecloud pulls the real Node 20 runtime container). The SQS -> Lambda event source mapping actually fires. CloudFormation actually provisioned the resources from the template CDK generated. CI integration</h2> jobs: cdk: runs-on: ubuntu-latest env: AWS_ENDPOINT_URL: http://localhost:4566 AWS_ACCESS_KEY_ID: test AWS_SECRET_ACCESS_KEY: test AWS_REGION: us-east-1 CDK_DEFAULT_ACCOUNT: '000000000000' CDK_DEFAULT_REGION: us-east-1 steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: { node-version: 20 } - name: Start fakecloud run: | curl -fsSL https://fakecloud.dev/install.sh | bash fakecloud & for i in $(seq 1 30); do curl -sf http://localhost:4566/_fakecloud/health && break; sleep 1; done curl -sf http://localhost:4566/_fakecloud/health - run: npm ci - run: npx cdk bootstrap - run: npx cdk deploy --require-approval never - run: npm test</code></pre>Assertions from tests</h2> CDK integration tests usually fall into two shapes: 1. Synth assertions — what CloudFormation does your CDK emit. These don't need fakecloud; use CDK's @aws-cdk/assert</code> or aws-cdk-lib/assertions</code>. 2. Deployed-stack behavior — does the stack actually work when deployed. For these, deploy to fakecloud and assert on real side effects: import { FakeCloud } from 'fakecloud'; const fc = new FakeCloud(); test('upload triggers lambda', async () => { await uploadToBucket('uploads', 'test.txt', 'hello'); const { invocations } = await fc.lambda.getInvocations({ functionName: 'Processor' }); expect(invocations).toHaveLength(1); }); afterEach(() => fc.reset());</code></pre> fakecloud SDKs available in TypeScript, Python, Go, PHP, Java, Rust. Destroy between tests</h2> CloudFormation state persists across tests unless you destroy or reset: # Full stack teardown cdk destroy --force # OR reset fakecloud's entire state (faster) curl -X POST http://localhost:4566/_fakecloud/reset</code></pre> Reset is ~instant and covers every service. cdk destroy</code> only unwinds one stack at a time. Why this works</h2> fakecloud targets 100% behavioral conformance per implemented service. CloudFormation (90 operations), Lambda (85 ops, real code execution in 13 runtimes), SQS (23 ops), S3 (107 ops) — all in. Cross-service wiring like S3 -> Lambda event sources and SQS -> Lambda event source mappings actually execute server-side, not as stubs. The depth-first goal: 100% of AWS services, each at 100% conformance, with 100% cross-service integrations. 23 services shipped today; more land one-at-a-time as they pass the conformance bar. Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh | bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> Terraform local dev guide: Terraform local development for AWS</a></li> LocalStack migration guide: Migrating from LocalStack to fakecloud</a></li> Issues: github.com/faiscadev/fakecloud/issues</a></li> </ul> Integration testing AWS in GitHub Actions without mocks Unknown — Wed, 22 Apr 2026 00:00:00 +0000 Most "AWS integration tests" in CI are not integration tests. They are unit tests with a mocking library — moto, aws-sdk-client-mock, something similar — that intercepts the AWS SDK inside the test process and returns fabricated responses. Those tests pass when your code is wrong, because the mock only knows what you told it. A real integration test talks to a real AWS-shaped service over HTTP. Testcontainers-LocalStack is the historical answer, but LocalStack's Community Edition went proprietary in March 2026 and now requires an account and an auth token just to pull the image. This post shows how to run real AWS integration tests in CI against fakecloud</a> — a free, open-source AWS emulator — with copy-paste configs for GitHub Actions, GitLab CI, and CircleCI. Why run fakecloud in CI</h2> ~500ms startup vs ~3s for a LocalStack container. Over hundreds of test runs, this matters.</li> ~19 MB binary, ~10 MiB idle memory. Lightweight on shared runners.</li> Single binary, no Docker required for most services (Docker still needed for Lambda, RDS, ElastiCache).</li> No account, no auth token, no license key. fakecloud</code> and you're running.</li> Covers 23 services at 100% conformance per service, including Cognito, SES v2, RDS, ElastiCache, API Gateway v2, Bedrock — the ones LocalStack moved behind the paywall.</li> </ul> GitHub Actions: install-and-run pattern</h2> The fastest CI setup is to install the binary and background it: name: test on: [push, pull_request] jobs: integration: runs-on: ubuntu-latest env: AWS_ENDPOINT_URL: http://localhost:4566 AWS_ACCESS_KEY_ID: test AWS_SECRET_ACCESS_KEY: test AWS_REGION: us-east-1 steps: - uses: actions/checkout@v4 - name: Install fakecloud run: curl -fsSL https://fakecloud.dev/install.sh | bash - name: Start fakecloud run: fakecloud & - name: Wait for fakecloud run: | for i in $(seq 1 30); do curl -sf http://localhost:4566/_fakecloud/health && exit 0 sleep 1 done echo "fakecloud did not start" exit 1 - uses: actions/setup-node@v4 with: node-version: 20 - run: npm ci - run: npm test</code></pre> AWS_ENDPOINT_URL</code> is respected by the AWS SDK v3 automatically — you do not need to configure your application code separately for CI vs local. GitHub Actions: service container pattern</h2> If you prefer a Docker service container (longer startup, cleaner isolation): jobs: integration: runs-on: ubuntu-latest services: fakecloud: image: ghcr.io/faiscadev/fakecloud:latest ports: - 4566:4566 env: AWS_ENDPOINT_URL: http://localhost:4566 AWS_ACCESS_KEY_ID: test AWS_SECRET_ACCESS_KEY: test AWS_REGION: us-east-1 steps: - uses: actions/checkout@v4 - run: npm ci - run: npm test</code></pre> Use this if your test harness expects the service to be ready before the job's steps run (service containers start first). Lambda in GitHub Actions</h2> Lambda needs Docker-in-Docker (fakecloud launches real Lambda runtime containers). On the default ubuntu-latest</code> runner, Docker is already available — you just need to mount the socket: services: fakecloud: image: ghcr.io/faiscadev/fakecloud:latest ports: - 4566:4566 volumes: - /var/run/docker.sock:/var/run/docker.sock</code></pre> Or with the install-and-run pattern, Docker is available on the host directly — nothing extra needed. The fakecloud process launches Lambda containers on the host's Docker. GitLab CI</h2> stages: - test integration: stage: test image: node:20 services: - name: ghcr.io/faiscadev/fakecloud:latest alias: fakecloud variables: AWS_ENDPOINT_URL: http://fakecloud:4566 AWS_ACCESS_KEY_ID: test AWS_SECRET_ACCESS_KEY: test AWS_REGION: us-east-1 script: - npm ci - npm test</code></pre> Note the endpoint uses the service alias (fakecloud</code>), not localhost</code>. CircleCI</h2> version: 2.1 jobs: integration: docker: - image: cimg/node:20.11 - image: ghcr.io/faiscadev/fakecloud:latest environment: AWS_ENDPOINT_URL: http://localhost:4566 AWS_ACCESS_KEY_ID: test AWS_SECRET_ACCESS_KEY: test AWS_REGION: us-east-1 steps: - checkout - run: npm ci - run: npm test workflows: build: jobs: - integration</code></pre> CircleCI's secondary Docker images share the primary image's localhost, so http://localhost:4566</code> works. Example test: SQS consumer integration</h2> Your code under test: // src/queue.ts import { SQSClient, SendMessageCommand } from "@aws-sdk/client-sqs"; export async function enqueue(body: string, queueUrl: string) { const sqs = new SQSClient({}); await sqs.send(new SendMessageCommand({ QueueUrl: queueUrl, MessageBody: body })); }</code></pre> Your integration test: // test/queue.test.ts import { SQSClient, CreateQueueCommand, ReceiveMessageCommand } from "@aws-sdk/client-sqs"; import { enqueue } from "../src/queue"; const sqs = new SQSClient({}); test("enqueue actually enqueues", async () => { const { QueueUrl } = await sqs.send(new CreateQueueCommand({ QueueName: "test-" + Date.now() })); await enqueue("hello", QueueUrl!); const res = await sqs.send(new ReceiveMessageCommand({ QueueUrl, WaitTimeSeconds: 1 })); expect(res.Messages?.[0]?.Body).toBe("hello"); });</code></pre> No mocks. The test creates a real queue, enqueues a real message, receives a real message. If your code is wrong, the test fails the way a real-AWS test would fail. Asserting on fan-out and async flows</h2> For flows that cross services (SQS -> Lambda -> SNS -> DynamoDB), use the fakecloud test-assertion SDK to inspect what each hop did: import { FakeCloud } from "fakecloud"; const fc = new FakeCloud(); test("order publishes and lambda invokes", async () => { await placeOrder({ id: "o1" }); // your code under test const { messages } = await fc.sns.getPublishedMessages({ topicName: "orders" }); expect(messages).toHaveLength(1); const { invocations } = await fc.lambda.getInvocations({ functionName: "on-order" }); expect(invocations).toHaveLength(1); expect(invocations[0].statusCode).toBe(200); }); afterEach(() => fc.reset());</code></pre> SDK available in TypeScript, Python, Go, PHP, Java, Rust. Docs: fakecloud.dev/docs/sdks</a>. Tips</h2> Reset between tests. Either await fc.reset()</code> in an afterEach</code>, or use per-test resources with unique names (test-${Date.now()}</code>). Reset is faster for large suites.</li> Run integration tests in a separate job from unit tests. Unit tests should not need fakecloud; integration tests should not run alongside mocked ones.</li> Pin the image tag in CI (ghcr.io/faiscadev/fakecloud:0.10.1</code>) if you want deterministic behavior across builds. latest</code> is fine for most teams.</li> Don't mix fakecloud with mocks. Pick one per test. If you mock inside a test that also talks to fakecloud, you will get confusing failures.</li> </ul> One call-out</h2> Performance benchmarking is different from correctness testing. fakecloud and AWS have different performance characteristics (by design — fakecloud is a local process, AWS is a distributed global system). Benchmark performance against real AWS. Benchmark correctness and behavior against fakecloud. fakecloud's goal is every AWS service at 100% conformance with 100% of cross-service integrations. If a service your tests hit isn't in the supported list</a> yet, file an issue</a> — the roadmap is demand-driven and services land one at a time with the full conformance target, not a partial-surface-first approach. Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh | bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> Migration from LocalStack: Migrating from LocalStack to fakecloud</a></li> Lambda tutorial: How to test Lambda locally</a></li> Issues: github.com/faiscadev/fakecloud/issues</a></li> </ul> Free LocalStack alternatives in 2026: fakecloud, MiniStack, floci, Moto Unknown — Wed, 22 Apr 2026 00:00:00 +0000 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</h2> 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</code>. 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</h2> 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</h2> 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.</li> Real stateful backends: RDS runs real PostgreSQL/MySQL/MariaDB via Docker; ElastiCache runs real Redis/Valkey.</li> Cross-service wiring that actually fires: EventBridge -> Step Functions, S3 -> Lambda, SES inbound -> S3/SNS/Lambda, 15+ more integrations.</li> Multi-account, SCPs, ABAC, permission boundaries, session policies, KMS key policies, bucket policies — full Allow/Deny/NotPrincipal semantics.</li> First-party test-assertion SDKs in TypeScript, Python, Go, PHP, Java, Rust.</li> Conformance validated on every commit against 54,000+ Smithy-generated test variants, plus the upstream hashicorp/terraform-provider-aws</code> TestAcc*</code> suites.</li> </ul> Source: github.com/faiscadev/fakecloud</a> MiniStack</h2> 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</h2> 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</h2> Longest-lived open-source AWS mocking project. Python library, in-process, patches boto3</code>. 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</a> LocalStack Pro (for completeness)</h2> 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</h2> 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.</li> 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.</li> 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.</li> What language are your tests? Moto is Python-only. Everything else is language-agnostic over HTTP.</li> 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.</li> </ol> Run your real test suite against each option you're considering. That's the only benchmark that applies to your codebase. Links</h2> fakecloud: github.com/faiscadev/fakecloud</a></li> Moto: github.com/getmoto/moto</a></li> LocalStack: localstack.cloud</a></li> fakecloud install options: fakecloud.dev/docs/getting-started</a></li> fakecloud migration guide: Migrating from LocalStack to fakecloud</a></li> </ul> LocalStack Ultimate covers 4 Bedrock ops. Here's why that's the wrong bet for tests. Unknown — Wed, 22 Apr 2026 00:00:00 +0000 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</a>, 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</h2> Per docs.localstack.cloud/aws/services/bedrock</a>, as of April 2026: Tier: Ultimate plan only. This is the top paid tier.</li> Operations: InvokeModel</code>, Converse</code>, ListFoundationModels</code>, CreateModelInvocationJob</code>. Four, total.</li> Backend: Ollama, called via its HTTP API.</li> Models: whatever Ollama supports — Llama, Mistral, Phi, etc. You call them via ollama.<model-id></code> strings through the Bedrock SDK.</li> Limitations per the docs: only text models, no GPU, no persistence, and responsiveness issues on Docker Desktop due to storage/memory constraints.</li> </ul> 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</h2> Let's be concrete. You're writing tests for code that calls anthropic.claude-3-haiku-20240307-v1:0</code> (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</code> (or whichever Ollama model you have installed).</li> Your code's modelId: "anthropic.claude-3-haiku-20240307-v1:0"</code> string gets routed to Llama 3.2.</li> Your prompt, which was tuned for Claude, runs through Llama, which interprets it differently.</li> The response comes back. Llama's output goes through Bedrock's response envelope shape.</li> Your code parses the envelope, extracts the text, and... what?</li> </ol> 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</h2> 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</code> 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</code> tuning routinely OOM during this. The four operations</h2> InvokeModel</code> and Converse</code> are the data plane — the calls your application makes at runtime. That's the part Ollama can back. ListFoundationModels</code> returns which models exist. CreateModelInvocationJob</code> 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</li> Custom models / customization jobs</li> Model import</li> Inference profiles</li> Provisioned throughput</li> Model copy jobs</li> Prompt management</li> Foundation model agreements</li> Resource policies</li> Logging configuration</li> Evaluation jobs</li> Marketplace</li> Automated reasoning</li> </ul> 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</h2> 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: </th> LocalStack Ultimate Bedrock</th> fakecloud Bedrock</th></tr></thead> Pricing</td> Top-tier paid plan</td> Free, AGPL-3.0</td></tr> Data plane</td> Ollama (real local LLM)</td> Configurable responses per prompt rule</td></tr> Determinism</td> No</td> Yes</td></tr> Speed</td> 1-30s per call</td> Milliseconds</td></tr> Guardrails</td> Not supported</td> Full CRUD + real content evaluation</td></tr> Custom models</td> Not supported</td> Full control plane</td></tr> Async batch</td> Partial</td> Full flow</td></tr> Prompt management</td> Not supported</td> Prompts + prompt routers</td></tr> GPU required</td> Usually</td> No</td></tr> Persistence</td> "Not supported" (from docs)</td> Yes</td></tr> </tbody></table> Why Ollama is the wrong backing for a Bedrock emulator</h2> 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</h2> 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</h2> If you're currently testing against real Bedrock, start with how to test Bedrock code locally</a> — walks through the full pattern end to end. If you're on LocalStack Ultimate and Bedrock was the draw, look at the migration comparison</a>. If you want to understand why "just use Ollama" doesn't work as a test strategy, here's a longer version of the argument</a>. Links</h2> Install fakecloud: curl -fsSL https://fakecloud.dev/install.sh | bash</code></li> LocalStack Bedrock docs (cited): docs.localstack.cloud/aws/services/bedrock</a></li> Bedrock emulator landing: /bedrock-emulator/</a></li> Migration landing: /localstack-bedrock-alternative/</a></li> GitHub: github.com/faiscadev/fakecloud</a></li> </ul> Migrating from LocalStack to fakecloud in 10 minutes Unknown — Wed, 22 Apr 2026 00:00:00 +0000 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</h2> Change the image or the install command. Keep http://localhost:4566</code> and your dummy credentials. Everything else stays the same. Step 1: Stop LocalStack</h2> docker compose down # or: docker kill $(docker ps -q --filter ancestor=localstack/localstack)</code></pre>Step 2: Install fakecloud</h2> Pick one: # Option A: single binary, no Docker curl -fsSL https://fakecloud.dev/install.sh | bash fakecloud # Option B: Docker docker run --rm -p 4566:4566 ghcr.io/faiscadev/fakecloud # Option C: cargo cargo install fakecloud</code></pre> fakecloud listens on http://localhost:4566</code> — same as LocalStack. Step 3: Keep your SDK wiring</h2> Your application code does not change. The 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, });</code></pre># 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", )</code></pre>// Go cfg, _ := config.LoadDefaultConfig(ctx, config.WithRegion("us-east-1"), config.WithCredentialsProvider(credentials.NewStaticCredentialsProvider("test", "test", "")), config.WithEndpointResolverWithOptions(aws.EndpointResolverWithOptionsFunc( func(service, region string, options ...interface{}) (aws.Endpoint, error) { return aws.Endpoint{URL: "http://localhost:4566"}, nil }, )), )</code></pre>Step 4: Update docker-compose.yml</h2> Before: services: localstack: image: localstack/localstack:latest ports: - "4566:4566" environment: - SERVICES=s3,sqs,sns,dynamodb,lambda - DEBUG=1</code></pre> After: services: fakecloud: image: ghcr.io/faiscadev/fakecloud:latest ports: - "4566:4566"</code></pre> fakecloud starts all services by default (they are lazy and cheap — no SERVICES</code> env var needed). If you want to pass flags: services: fakecloud: image: ghcr.io/faiscadev/fakecloud:latest ports: - "4566:4566" command: ["fakecloud", "--host", "0.0.0.0", "--port", "4566"]</code></pre> 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</code></pre>Step 5: Update GitHub Actions</h2> Before: services: localstack: image: localstack/localstack ports: - 4566:4566 env: LOCALSTACK_AUTH_TOKEN: ${{ secrets.LOCALSTACK_TOKEN }} # now required</code></pre> After (service container): services: fakecloud: image: ghcr.io/faiscadev/fakecloud:latest ports: - 4566:4566</code></pre> After (install-and-run, no Docker): steps: - run: curl -fsSL https://fakecloud.dev/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</code></pre> The install-and-run pattern is ~500ms vs ~3s for LocalStack container boot. On a cold CI runner the difference is noticeable over hundreds of test runs. Step 6: Terraform / OpenTofu</h2> No change needed. The 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" sns = "http://localhost:4566" dynamodb = "http://localhost:4566" lambda = "http://localhost:4566" # ... } }</code></pre> fakecloud's CI runs the upstream hashicorp/terraform-provider-aws</code> TestAcc*</code> suites against itself, so Terraform flows that worked against LocalStack Community should work against fakecloud. If you hit a mismatch, it is a bug — open an issue. Step 7: CDK — cdklocal</h2> CDK users with cdklocal</code> change the endpoint override: cdklocal bootstrap --endpoint-url http://localhost:4566 cdklocal deploy --endpoint-url http://localhost:4566</code></pre> Or set AWS_ENDPOINT_URL=http://localhost:4566</code> in your shell and use plain cdk</code>. Step 8: Serverless Framework</h2> If you used serverless-localstack</code>, the simplest migration is to drop the plugin and set AWS_ENDPOINT_URL</code> before running serverless</code>: export AWS_ENDPOINT_URL=http://localhost:4566 export AWS_ACCESS_KEY_ID=test export AWS_SECRET_ACCESS_KEY=test export AWS_REGION=us-east-1 serverless deploy</code></pre> AWS SDK v3 (which Serverless Framework uses internally on recent versions) respects AWS_ENDPOINT_URL</code> automatically — no plugin or custom config required. If you're on an older version that doesn't, configure the endpoint through whatever per-service override your current plugin exposes. Things that may need attention</h2> SERVICES env var. LocalStack used SERVICES=s3,sqs,...</code> to scope which services booted. fakecloud starts all services by default and they are cheap. Drop the env var. LOCALSTACK_AUTH_TOKEN. Drop it. fakecloud does not use auth tokens. Gateway / edge URL. LocalStack had historical URLs like http://localhost:4566</code> and older per-service ports (4572, 4576, etc). fakecloud uses only 4566</code> — same as modern LocalStack. If you still have old per-service URLs pinned, consolidate them. Regions. fakecloud respects the region from your SDK call. Default us-east-1</code> works everywhere. Persisted state. LocalStack Pro has PERSISTENCE=1</code>. fakecloud has --persist /path/to/dir</code> for the same effect. Services that moved from LocalStack Community to Pro (and what fakecloud does)</h2> Service</th> LocalStack Community (pre-Mar 2026)</th> LocalStack Community (now)</th> fakecloud</th></tr></thead> RDS</td> Paid only</a> — always was</td> Paid only</td> 163 ops, real PostgreSQL/MySQL/MariaDB via Docker</td></tr> ElastiCache</td> Paid only</td> Paid only</td> 75 ops, real Redis/Valkey via Docker</td></tr> Cognito User Pools</td> Free</td> Paid only</a></td> 122 ops, full auth flows + MFA</td></tr> SES v2</td> Free (limited)</td> Paid only</a></td> 110 ops, full send + templates + DKIM</td></tr> API Gateway v2</td> Free</td> Paid only</a></td> 28 ops, HTTP APIs + JWT/Lambda authorizers</td></tr> Bedrock</td> Not available</td> Not available</td> 111 ops (control plane + runtime)</td></tr> </tbody></table> Assertion helpers (optional)</h2> This is new capability LocalStack never had: fakecloud ships test-assertion SDKs that let you inspect side effects from tests without raw HTTP. import { FakeCloud } from "fakecloud"; const fc = new FakeCloud(); // Your app code sends an email through the normal AWS SDK. // Your test asserts the side effect directly. const { emails } = await fc.ses.getEmails(); expect(emails).toHaveLength(1); expect(emails[0].destination.toAddresses).toContain("alice@example.com"); // Reset between tests. await fc.reset();</code></pre> SDKs for TypeScript, Python, Go, PHP, Java, Rust. See the SDK docs</a>. Verify the migration</h2> One-shot smoke test that exercises a cross-service flow: # Create a bucket, upload, confirm, teardown 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 # Lambda round-trip echo 'exports.handler = async () => ({ ok: true })' > index.js zip fn.zip index.js aws --endpoint-url http://localhost:4566 lambda create-function \ --function-name smoke --runtime nodejs20.x \ --role arn:aws:iam::000000000000:role/lambda-role \ --handler index.handler --zip-file fileb://fn.zip aws --endpoint-url http://localhost:4566 lambda invoke \ --function-name smoke out.json && cat out.json</code></pre> If both print what you expect, migration is done. A note on coverage</h2> fakecloud's goal is every AWS service at 100% conformance, including every cross-service integration. Services land depth-first: a service is supported when it passes the Smithy-model test variants and the cross-service wire-ups that matter for it — not when the API surface looks filled in. The current 23 services (1,680 operations) are what's done today; more are on the roadmap, prioritized by real-project demand. If a service you need isn't on the list, open an issue</a> and it'll get weighed into the queue. For mission-critical pre-prod validation where you need the full production-parity surface, run against real AWS — that's true of any emulator, not a fakecloud gap specifically. Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh | bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> Site: fakecloud.dev</a></li> Comparison: fakecloud vs LocalStack, MiniStack, floci, Moto</a></li> Issues: github.com/faiscadev/fakecloud/issues</a></li> </ul> A Moto equivalent for Go, Java, Kotlin, and Node.js Unknown — Wed, 22 Apr 2026 00:00:00 +0000 If you write Python, you have Moto. Decorate a test, boto3 gets patched in-process, and your assertions run against an in-memory AWS. It is great, it has been great for years, and it is not available in any other language because Python is the only ecosystem where you can cleanly monkey-patch the SDK from inside a test process. What if you write Go, Java, Kotlin, Node.js, Rust, or PHP? The honest cross-language answer is: a real HTTP server speaking the AWS wire protocol. Point your language's AWS SDK at http://localhost:4566</code>, and it doesn't matter whether the thing on the other end is AWS, LocalStack, MiniStack, floci, or fakecloud — the wire contract is the same. This post is specifically about using fakecloud</a> — free, open-source, single binary, no account, no paid tier — as a Moto equivalent in the languages Moto cannot reach. Why a real HTTP server, not an in-process patch</h2> Moto works because Python lets you reach into a running process and replace functions. In Java and Go and most other typed languages, you can't really do that — the SDK is compiled, the method dispatch is known at build time, and monkey-patching S3Client.putObject</code> is not a thing you do in production code. The equivalent model in those languages is to configure the SDK's endpoint. Every AWS SDK supports pointing at a non-AWS endpoint URL. Point it at http://localhost:4566</code>, and the SDK thinks it's talking to AWS. The server on the other end handles all the ceremony: signing verification (optional), request parsing, response shaping, persistence, cross-service wiring. Your test code is normal — the only thing that's "fake" is the URL. Installing fakecloud</h2> curl -fsSL https://fakecloud.dev/install.sh | bash fakecloud</code></pre> Listens on http://localhost:4566</code>. One binary, ~19 MB, ~500ms startup. Go</h2> package store_test import ( "context" "testing" "github.com/aws/aws-sdk-go-v2/aws" "github.com/aws/aws-sdk-go-v2/config" "github.com/aws/aws-sdk-go-v2/credentials" "github.com/aws/aws-sdk-go-v2/service/s3" "github.com/aws/smithy-go" ) func clientForTest(t *testing.T) *s3.Client { cfg, err := config.LoadDefaultConfig(context.Background(), config.WithRegion("us-east-1"), config.WithCredentialsProvider(credentials.NewStaticCredentialsProvider("test", "test", "")), config.WithEndpointResolverWithOptions(aws.EndpointResolverWithOptionsFunc( func(service, region string, opts ...interface{}) (aws.Endpoint, error) { return aws.Endpoint{URL: "http://localhost:4566"}, nil }, )), ) if err != nil { t.Fatal(err) } return s3.NewFromConfig(cfg, func(o *s3.Options) { o.UsePathStyle = true }) } func TestPutAndGet(t *testing.T) { ctx := context.Background() c := clientForTest(t) _, err := c.CreateBucket(ctx, &s3.CreateBucketInput{Bucket: aws.String("test")}) if err != nil { t.Fatal(err) } // ... putObject, getObject, assert }</code></pre> That's Go integration tests against fakecloud. Same SDK, same API, same assertions — no mock. For SDK v1, use WithEndpoint("http://localhost:4566")</code> on the session config. Java</h2> import software.amazon.awssdk.auth.credentials.AwsBasicCredentials; import software.amazon.awssdk.auth.credentials.StaticCredentialsProvider; import software.amazon.awssdk.regions.Region; import software.amazon.awssdk.services.s3.S3Client; import java.net.URI; class S3Test { static S3Client client() { return S3Client.builder() .endpointOverride(URI.create("http://localhost:4566")) .region(Region.US_EAST_1) .credentialsProvider(StaticCredentialsProvider.create( AwsBasicCredentials.create("test", "test"))) .forcePathStyle(true) .build(); } @Test void putAndGet() { var s3 = client(); s3.createBucket(b -> b.bucket("test")); // ... assertions } }</code></pre>Kotlin</h2> Same as Java, nicer syntax: import software.amazon.awssdk.auth.credentials.* import software.amazon.awssdk.regions.Region import software.amazon.awssdk.services.s3.S3Client import java.net.URI fun s3(): S3Client = S3Client.builder() .endpointOverride(URI.create("http://localhost:4566")) .region(Region.US_EAST_1) .credentialsProvider(StaticCredentialsProvider.create( AwsBasicCredentials.create("test", "test"))) .forcePathStyle(true) .build()</code></pre>Node.js (AWS SDK v3)</h2> The SDK v3 respects AWS_ENDPOINT_URL</code> automatically, so the test setup is trivial: // jest.setup.ts or vitest.setup.ts process.env.AWS_ENDPOINT_URL = "http://localhost:4566"; process.env.AWS_ACCESS_KEY_ID = "test"; process.env.AWS_SECRET_ACCESS_KEY = "test"; process.env.AWS_REGION = "us-east-1";</code></pre> Your application code imports the AWS SDK normally and does not need any test-specific branching. Your tests import your code and call it. Your assertions check the real state on fakecloud afterwards. For SDK v2 (deprecated but still widely used): import AWS from "aws-sdk"; AWS.config.update({ endpoint: "http://localhost:4566", accessKeyId: "test", secretAccessKey: "test", region: "us-east-1", s3ForcePathStyle: true, });</code></pre>PHP</h2> use Aws\S3\S3Client; $s3 = new S3Client([ 'version' => 'latest', 'region' => 'us-east-1', 'endpoint' => 'http://localhost:4566', 'credentials' => ['key' => 'test', 'secret' => 'test'], 'use_path_style_endpoint' => true, ]);</code></pre>Rust</h2> use aws_config::{BehaviorVersion, Region}; use aws_sdk_s3::config::Credentials; async fn client() -> aws_sdk_s3::Client { let config = aws_config::defaults(BehaviorVersion::latest()) .region(Region::new("us-east-1")) .endpoint_url("http://localhost:4566") .credentials_provider(Credentials::from_keys("test", "test", None)) .load() .await; aws_sdk_s3::Client::new(&config) }</code></pre>The part Moto cannot do, in any language</h2> Moto patches SDK methods inside the test process. It does not run code — specifically, it does not execute Lambda functions. If your Python test creates a Lambda and invokes it, Moto returns a simulated response; your function's actual code does not run. fakecloud does run the code. It pulls real Lambda runtime containers (13 runtimes: Node, Python, Java, Go, .NET, Ruby, custom) and executes your handler against them. So a test like "my Go service publishes to SNS, which triggers a Python Lambda, which writes to DynamoDB" works end-to-end — real Lambda code running, real SNS fan-out, real DynamoDB state. // Go test that publishes to SNS... snsClient.Publish(ctx, &sns.PublishInput{ TopicArn: aws.String(topicArn), Message: aws.String(`{"event":"order.placed"}`), }) // ...and your Python Lambda (deployed to fakecloud) actually runs. // Then you assert on its side effect (a DynamoDB row) from the Go test.</code></pre> This is the main thing a real HTTP emulator gives you that no in-process mocking library can. Assertion helpers</h2> fakecloud's test-assertion SDKs give you introspection into what happened on the server, without writing raw HTTP: // Go fc := fakecloud.New("http://localhost:4566") invs, _ := fc.Lambda.GetInvocations(ctx, &fakecloud.GetInvocationsInput{FunctionName: "on-order"}) if len(invs.Invocations) != 1 { t.Fatal("expected 1 invocation") }</code></pre>// Node const fc = new FakeCloud(); const { invocations } = await fc.lambda.getInvocations({ functionName: "on-order" }); expect(invocations).toHaveLength(1);</code></pre># Python (if you also want to use fakecloud from pytest alongside Go tests) fc = FakeCloud() invs = fc.lambda_.get_invocations(function_name="on-order") assert len(invs.invocations) == 1</code></pre> SDKs for TypeScript, Python, Go, PHP, Java, Rust: fakecloud.dev/docs/sdks</a>. Moto vs fakecloud: when to use which</h2> Situation</th> Pick</th></tr></thead> Python-only project, pure unit tests that just need boto3 to respond</td> Moto</td></tr> Python + real cross-service wiring (Lambda actually runs, S3 -> Lambda actually fires)</td> fakecloud</td></tr> Any non-Python language</td> fakecloud</td></tr> Multi-language codebase sharing tests</td> fakecloud</td></tr> Integration tests in CI across multiple services</td> fakecloud</td></tr> </tbody></table> Moto and fakecloud are not really competitive — they solve slightly different problems. If you already use Moto and it works, keep it. If you need cross-service integrations, non-Python languages, or real Lambda execution, add fakecloud. Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh | bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> Moto: github.com/getmoto/moto</a></li> Language SDK docs: fakecloud.dev/docs/sdks</a></li> Issues: github.com/faiscadev/fakecloud/issues</a></li> </ul> Terraform local development for AWS: full flow with fakecloud Unknown — Wed, 22 Apr 2026 00:00:00 +0000 Writing Terraform for AWS means iterating against AWS. Every terraform apply</code> costs money, takes minutes, and leaves resources behind that you have to remember to destroy. For local dev and CI, you want the same AWS provider running against something that behaves like AWS but isn't. This guide walks through local Terraform development for AWS with fakecloud</a> — a free, open-source AWS emulator that targets 100% behavioral conformance, depth-first. fakecloud's CI runs the upstream hashicorp/terraform-provider-aws</code> TestAcc*</code> suites against itself on every commit, so Terraform flows that work against real AWS should work against fakecloud. Install fakecloud</h2> curl -fsSL https://fakecloud.dev/install.sh | bash fakecloud</code></pre> Listens on http://localhost:4566</code>. ~500ms startup. No account, no token. Option 1: provider endpoints</code> block (explicit)</h2> Most explicit and portable. Works with any Terraform/OpenTofu version. # main.tf 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 s3_use_path_style = true endpoints { s3 = "http://localhost:4566" sqs = "http://localhost:4566" sns = "http://localhost:4566" dynamodb = "http://localhost:4566" lambda = "http://localhost:4566" iam = "http://localhost:4566" sts = "http://localhost:4566" kms = "http://localhost:4566" secretsmanager = "http://localhost:4566" ssm = "http://localhost:4566" logs = "http://localhost:4566" cloudformation = "http://localhost:4566" events = "http://localhost:4566" scheduler = "http://localhost:4566" ses = "http://localhost:4566" sesv2 = "http://localhost:4566" cognitoidp = "http://localhost:4566" kinesis = "http://localhost:4566" rds = "http://localhost:4566" elasticache = "http://localhost:4566" sfn = "http://localhost:4566" apigatewayv2 = "http://localhost:4566" bedrock = "http://localhost:4566" bedrockruntime = "http://localhost:4566" } }</code></pre> Now terraform init && terraform apply</code> talks to fakecloud. Option 2: AWS_ENDPOINT_URL</code> (minimal config)</h2> Cleaner. AWS provider v5.63+ respects AWS_ENDPOINT_URL</code> from environment. No endpoints</code> block needed. export AWS_ENDPOINT_URL=http://localhost:4566 export AWS_ACCESS_KEY_ID=test export AWS_SECRET_ACCESS_KEY=test export AWS_REGION=us-east-1 terraform init terraform apply</code></pre> The provider block collapses to just auth scaffolding: 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 s3_use_path_style = true }</code></pre>Option 3: tflocal</code> wrapper</h2> If you're coming from LocalStack and have a tflocal</code> setup, the endpoint override works the same way — just point at fakecloud instead. AWS_ENDPOINT_URL=http://localhost:4566 tflocal apply</code></pre>End-to-end example: S3 + Lambda + SQS</h2> # main.tf resource "aws_s3_bucket" "uploads" { bucket = "uploads-${random_id.suffix.hex}" } resource "random_id" "suffix" { byte_length = 4 } resource "aws_sqs_queue" "jobs" { name = "jobs" } resource "aws_iam_role" "lambda" { name = "lambda-role" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{ Effect = "Allow" Principal = { Service = "lambda.amazonaws.com" } Action = "sts:AssumeRole" }] }) } resource "aws_lambda_function" "processor" { filename = data.archive_file.fn.output_path function_name = "processor" role = aws_iam_role.lambda.arn handler = "index.handler" runtime = "nodejs20.x" source_code_hash = data.archive_file.fn.output_base64sha256 } data "archive_file" "fn" { type = "zip" output_path = "fn.zip" source { filename = "index.js" content = "exports.handler = async (event) => ({ ok: true, received: event })" } } resource "aws_lambda_event_source_mapping" "sqs_to_lambda" { event_source_arn = aws_sqs_queue.jobs.arn function_name = aws_lambda_function.processor.function_name batch_size = 1 } resource "aws_s3_bucket_notification" "uploads_to_sqs" { bucket = aws_s3_bucket.uploads.id queue { queue_arn = aws_sqs_queue.jobs.arn events = ["s3:ObjectCreated:*"] } } output "bucket_id" { value = aws_s3_bucket.uploads.id }</code></pre> Apply it against fakecloud: terraform apply -auto-approve</code></pre> Upload an object and watch the Lambda fire: echo "hello" | aws --endpoint-url http://localhost:4566 s3 cp - s3://$(terraform output -raw bucket_id)/file.txt aws --endpoint-url http://localhost:4566 logs tail /aws/lambda/processor</code></pre> That's S3 notification -> SQS queue -> Lambda event source mapping -> real Node runtime executing your handler. End-to-end, no stubs. Same flow as real AWS. CI: Terraform plan/apply in GitHub Actions</h2> jobs: terraform: runs-on: ubuntu-latest env: AWS_ENDPOINT_URL: http://localhost:4566 AWS_ACCESS_KEY_ID: test AWS_SECRET_ACCESS_KEY: test AWS_REGION: us-east-1 steps: - uses: actions/checkout@v4 - uses: hashicorp/setup-terraform@v3 - name: Start fakecloud run: | curl -fsSL https://fakecloud.dev/install.sh | bash fakecloud & for i in $(seq 1 30); do curl -sf http://localhost:4566/_fakecloud/health && break; sleep 1; done curl -sf http://localhost:4566/_fakecloud/health - name: terraform init run: terraform init - name: terraform plan run: terraform plan -out=tfplan - name: terraform apply run: terraform apply -auto-approve tfplan</code></pre> ~500ms startup means this adds negligible time to the job. State backend</h2> For local dev, default local</code> backend is fine. If your real config uses s3</code> backend, you can point that at fakecloud too: terraform { backend "s3" { bucket = "tf-state" key = "terraform.tfstate" region = "us-east-1" endpoint = "http://localhost:4566" skip_credentials_validation = true skip_metadata_api_check = true skip_region_validation = true force_path_style = true } }</code></pre> Pre-create the bucket: aws --endpoint-url http://localhost:4566 s3 mb s3://tf-state</code></pre>Why this works at parity</h2> fakecloud targets 100% behavioral conformance per implemented service, validated on every commit against AWS's own Smithy models. On top of that, CI runs the upstream hashicorp/terraform-provider-aws</code> TestAcc*</code> suites — the same acceptance tests HashiCorp runs against real AWS — so provider-level behavior (waiters, retries, field presence, ARN formats) matches. If a Terraform flow that works against real AWS doesn't work against fakecloud, that's a bug. Open an issue</a> and it gets fixed. Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh | bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> LocalStack migration guide: Migrating from LocalStack to fakecloud</a></li> CI guide: Integration testing AWS in GitHub Actions</a></li> Issues: github.com/faiscadev/fakecloud/issues</a></li> </ul> How to test Lambda locally: the full guide for 2026 Unknown — Wed, 22 Apr 2026 00:00:00 +0000 If you want to run AWS Lambda locally, you have a few options, and most of them are worse than they need to be. SAM Local invokes Lambda inside a Docker container, which is close to the real thing, but its integration with other AWS services is thin. If your function reads from SQS or publishes to SNS or is triggered by S3, SAM hands you a bag of event-shaped JSON and wishes you luck.</li> serverless-offline simulates API Gateway -> Lambda only. Everything downstream is mocked.</li> Pure unit tests with mocks tell you your code compiles. They do not tell you your code works.</li> </ul> This guide shows how to test Lambda locally end-to-end: real function code executing in a real runtime, triggered by real events from other AWS services, asserting on real side effects. No account, no auth token, no paid tier. We'll use fakecloud</a> — a free, open-source AWS emulator that runs Lambda in real Docker containers across all 13 official runtimes and wires it up to 22 other AWS services that trigger and consume it. What you need</h2> Docker (fakecloud boots Lambda runtime containers)</li> The AWS CLI, or any AWS SDK</li> ~30 seconds</li> </ul> Install fakecloud</h2> curl -fsSL https://fakecloud.dev/install.sh | bash fakecloud</code></pre> That's it. It listens on http://localhost:4566</code>. If you prefer Docker: docker run --rm \ -p 4566:4566 \ -v /var/run/docker.sock:/var/run/docker.sock \ ghcr.io/faiscadev/fakecloud</code></pre> The Docker socket mount is only needed because Lambda execution needs Docker-in-Docker. The single-binary install above doesn't need it. A Node.js Lambda, end-to-end</h2> Create the function: cat > index.js <<'EOF' exports.handler = async (event) => { return { statusCode: 200, body: JSON.stringify({ event }) }; }; EOF zip fn.zip index.js</code></pre> Deploy it to fakecloud: aws --endpoint-url http://localhost:4566 iam create-role \ --role-name lambda-role \ --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"lambda.amazonaws.com"},"Action":"sts:AssumeRole"}]}' aws --endpoint-url http://localhost:4566 lambda create-function \ --function-name hello \ --runtime nodejs20.x \ --role arn:aws:iam::000000000000:role/lambda-role \ --handler index.handler \ --zip-file fileb://fn.zip</code></pre> Invoke it: aws --endpoint-url http://localhost:4566 lambda invoke \ --function-name hello \ --payload '{"hello":"world"}' \ --cli-binary-format raw-in-base64-out \ out.json cat out.json</code></pre> Output: {"statusCode":200,"body":"{\"event\":{\"hello\":\"world\"}}"}</code></pre> That's your Node.js code executing in a real Node 20 container. fakecloud pulled the runtime image, mounted your zip, and invoked handler</code>. Python, Java, Go, .NET, Ruby, custom</h2> Same flow, different runtime string. fakecloud supports all 13 AWS Lambda runtimes: nodejs18.x</code>, nodejs20.x</code>, nodejs22.x</code></li> python3.9</code>, python3.10</code>, python3.11</code>, python3.12</code></li> java11</code>, java17</code>, java21</code></li> dotnet6</code>, dotnet8</code></li> ruby3.2</code></li> go1.x</code>, provided.al2</code>, provided.al2023</code> (custom runtimes)</li> </ul> Example — Python: cat > lambda_function.py <<'EOF' def handler(event, context): return {"ok": True, "event": event} EOF zip fn.zip lambda_function.py aws --endpoint-url http://localhost:4566 lambda create-function \ --function-name py-hello \ --runtime python3.12 \ --role arn:aws:iam::000000000000:role/lambda-role \ --handler lambda_function.handler \ --zip-file fileb://fn.zip aws --endpoint-url http://localhost:4566 lambda invoke \ --function-name py-hello \ --payload '{"x":1}' \ --cli-binary-format raw-in-base64-out \ out.json</code></pre>Triggers that actually fire</h2> This is where "test Lambda locally" usually breaks down. Your Lambda is not invoked by a human calling Invoke — it's triggered by S3, SQS, SNS, EventBridge, DynamoDB Streams, API Gateway, or an event source mapping. fakecloud has those wired up for real. SQS event source mapping</h3> aws --endpoint-url http://localhost:4566 sqs create-queue --queue-name jobs QUEUE_URL=http://localhost:4566/000000000000/jobs QUEUE_ARN=arn:aws:sqs:us-east-1:000000000000:jobs aws --endpoint-url http://localhost:4566 lambda create-event-source-mapping \ --function-name hello \ --event-source-arn $QUEUE_ARN \ --batch-size 1 aws --endpoint-url http://localhost:4566 sqs send-message \ --queue-url $QUEUE_URL \ --message-body '{"job":"resize","id":42}'</code></pre> fakecloud polls the queue, batches the message, invokes your Lambda with the SQS event shape, and deletes the message on success. Same contract as real AWS. S3 -> Lambda</h3> aws --endpoint-url http://localhost:4566 s3 mb s3://uploads aws --endpoint-url http://localhost:4566 lambda add-permission \ --function-name hello \ --statement-id s3invoke \ --action lambda:InvokeFunction \ --principal s3.amazonaws.com \ --source-arn arn:aws:s3:::uploads aws --endpoint-url http://localhost:4566 s3api put-bucket-notification-configuration \ --bucket uploads \ --notification-configuration '{ "LambdaFunctionConfigurations": [{ "LambdaFunctionArn": "arn:aws:lambda:us-east-1:000000000000:function:hello", "Events": ["s3:ObjectCreated:*"] }] }' echo "hi" | aws --endpoint-url http://localhost:4566 s3 cp - s3://uploads/file.txt</code></pre> Your Lambda fires with the S3 event. End-to-end, no stubs. EventBridge -> Lambda</h3> aws --endpoint-url http://localhost:4566 events put-rule \ --name on-order \ --event-pattern '{"source":["store"],"detail-type":["OrderPlaced"]}' aws --endpoint-url http://localhost:4566 events put-targets \ --rule on-order \ --targets 'Id=1,Arn=arn:aws:lambda:us-east-1:000000000000:function:hello' aws --endpoint-url http://localhost:4566 events put-events \ --entries 'Source=store,DetailType=OrderPlaced,Detail={"orderId":"o1"}'</code></pre> Your Lambda fires with the EventBridge event envelope. Asserting on side effects</h2> fakecloud ships test-assertion SDKs that let your tests check what happened without raw HTTP: import { FakeCloud } from "fakecloud"; const fc = new FakeCloud(); // Your app publishes to SNS inside a Lambda. Your test asserts it happened. const { invocations } = await fc.lambda.getInvocations({ functionName: "hello" }); expect(invocations).toHaveLength(1); expect(invocations[0].statusCode).toBe(200); const { messages } = await fc.sns.getPublishedMessages({ topicName: "orders" }); expect(messages[0].message).toContain("o1"); await fc.reset();</code></pre> SDKs in TypeScript, Python, Go, PHP, Java, Rust. Reference: fakecloud.dev/docs/sdks</a>. Watching the logs</h2> Lambda stdout goes to CloudWatch Logs, which fakecloud also emulates: aws --endpoint-url http://localhost:4566 logs tail /aws/lambda/hello --follow</code></pre>Running in CI</h2> # .github/workflows/test.yml jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: curl -fsSL https://fakecloud.dev/install.sh | bash - run: fakecloud & - run: | for i in $(seq 1 30); do curl -sf http://localhost:4566/_fakecloud/health && break sleep 1 done - run: npm ci && npm test env: AWS_ENDPOINT_URL: http://localhost:4566 AWS_ACCESS_KEY_ID: test AWS_SECRET_ACCESS_KEY: test AWS_REGION: us-east-1</code></pre> ~500ms startup. A whole Lambda-integration test suite completes in seconds on a cold runner. Correctness vs performance</h2> fakecloud runs your function code in the real AWS Lambda runtime containers, so behavior matches real Lambda. What it doesn't replicate is AWS's distributed infrastructure timing: cold-start latency, concurrency-accounting scheduling, and VPC networking come from AWS's own implementation, not from a local process, so numbers on those will not match real AWS. Use real AWS for those measurements, use fakecloud for everything correctness-related. Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh | bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> Lambda docs: fakecloud.dev/docs/services/lambda</a></li> SDKs: fakecloud.dev/docs/sdks</a></li> Issues: github.com/faiscadev/fakecloud/issues</a></li> </ul> People are not reviewing AI-generated code Unknown — Wed, 15 Apr 2026 00:00:00 +0000 I'd bet good money that most developers using AI tools are already shipping code without properly reviewing every line. Not because they have some sophisticated testing setup. Because it historically just works. A developer reviews the first ten things the AI writes. They're fine. Reviews the next ten. Also fine. At some point the developer starts skimming. Then stops reading altogether. The review step keeps proving itself to be a waste of time, so it gets skipped. Human nature. What validation looks like with guardrails</h2> I built fakecloud almost entirely with Claude. 22 AWS services, 1,650+ operations, 100% conformance to AWS behavior. Here's my workflow: I define what to build. Architecture, scope, acceptance criteria.</li> AI writes code and tests.</li> Tests run in CI.</li> I look at the results.</li> </ol> Step 4 is where it gets weird. The tests pass. I look at the implementation. It's correct. I merge. This happens over and over. I'm doing the validation—I'm looking, I'm checking—but I'm not finding anything wrong. The guardrails already caught it. The validation step has become ceremonial. You still do it because if something's wrong it can be a disaster. But in practice, if you've built the right guardrails, validation finds nothing. The automated systems already caught everything. What's actually happening</h2> I still validate before merging because catastrophic failure is real. If something gets through that shouldn't, it's a disaster. So I check. But I'm checking as a safety ritual, not because I expect to find problems. The tests already found the problems. CI already caught them. By the time I look, there's nothing left to catch. And here's my gut feeling: I think most people are already skipping this step. I have no proof. But think about it. A developer asks Claude or Copilot to write a function. It looks right. They review it anyway because that's what responsible developers do. It's fine. Next time, same thing. Fine again. After the twentieth time, they start skimming. After the fiftieth, they stop reading altogether. Why would anyone keep reviewing something that's never wrong? But I'd bet there are plenty of developers shipping AI-generated code without proper test infrastructure. Without CI catching issues. Without proper monitoring. Just the AI, some tests the AI wrote, and hope. I think the industry already moved past "review every line." We're just not talking about it. You can't fix this with process</h2> You can write "review all AI-generated code" in your team's guidelines. You can make it a policy. You can add it to the PR checklist. But you can't verify that someone actually did it. You can't tell the difference between "I carefully reviewed this" and "I skimmed it for 30 seconds and it looked fine." There's no way to enforce it. And when the AI keeps being right, the incentive to actually do it drops to zero. So instead of pretending you can control this, build systems that don't depend on it. That's what I did with fakecloud. The code is real. The conformance is real. Most of it was written by Claude, with me defining architecture and making sure the guardrails worked. And when I validate the code, I find nothing wrong. Not because I'm a great reviewer. Because the guardrails already found everything. What good guardrails look like</h2> Most AI-generated code ships with AI-generated tests. The problem is that the tests can be wrong in the same way the code is wrong. Everything is internally consistent, but none of it matches reality. A human reviewer might catch this. Or might not. You can't count on it. What you can count on: Real integration tests with actual SDKs — not mocks that mirror the buggy code</li> Conformance tests generated from schemas — tests the AI didn't write and can't game</li> Side-by-side testing against real systems — when behavior diverges, it's a bug</li> </ul> The difference isn't whether someone reviewed the code. It's whether you have automated systems that verify correctness independent of the code being tested. When those systems pass, the code is right regardless of whether anyone read it. When they fail, the AI fixes it until they pass. Here's a concrete example. If you're writing code that calls Bedrock — the Claude API on AWS — the hard parts are retry logic, fallback models, and circuit breakers. Testing that code against real Bedrock is expensive, non-deterministic, and rate-limited. Mocking it is meaningless because the mocks don't catch the bugs. So you either ship untested error handling or you write unrunnable tests. That's exactly the kind of gap where AI-generated code goes wrong silently. I wrote a whole guide on how to test Bedrock code locally against fakecloud</a> — deterministic responses, injectable faults, call history assertions. That's what "guardrails the AI can't game" looks like in practice. The test suite is the guardrail</h2> fakecloud works because the tests verify everything. Not me. Not code review. The tests. 54,000+ conformance tests generated from AWS Smithy models</li> E2E tests using real AWS SDKs</li> CI that runs everything on every commit</li> Side-by-side testing against actual AWS</li> </ul> These guardrails are external to the code being tested. The AI can't game them. They catch bugs before I see the code. So when I validate, I find nothing. Because there's nothing left to find. If I'm right that people are already shipping AI code without reviewing it, this is the gap. Most codebases don't have external verification. Just AI-generated code, AI-generated tests, and no way to know if they match reality. The fix isn't telling people to review harder. It's building systems that catch the bugs whether or not anyone reads the code. What to do about it</h2> If you're using AI to write code, here's what matters: You can't control whether people actually review code. You can tell them to. You can put it in the process. But you can't get inside their head and verify they actually read every line. So build systems that don't depend on them doing it. Build external guardrails. Tests that the AI didn't write. Conformance checks generated from schemas. Integration tests with real dependencies, not mocks. Automate everything. Don't rely on humans to catch bugs. Humans are slow, inconsistent, lazy, and bad at checking edge cases. Automated systems are fast, consistent, and check everything. Accept what's probably already happening. I think most developers are already shipping AI-generated code without thorough manual review. If that's true, the question isn't whether to do it. It's whether you're doing it safely. For AWS code specifically, I wrote about how to test AI-generated AWS code properly</a>. The short version: don't mock AWS APIs. Use something that behaves like real AWS. That's why fakecloud exists: Repo: github.com/faiscadev/fakecloud</a></li> Site: fakecloud.dev</a></li> Install: curl -fsSL https://fakecloud.dev/install.sh | bash</code></li> </ul> If you're writing AWS code with Claude, Cursor, or any AI tool, you need automated guardrails that verify correctness without you in the loop. Because if I'm right, people are already skipping manual review—and the only thing standing between them and production bugs is the quality of their automated tests. Build the guardrails. Then let the AI work. And if you find a case where fakecloud behaves differently from AWS, open an issue</a>. Because that means the guardrails missed something. And we need to know. How to test AWS code written by AI tools Unknown — Tue, 14 Apr 2026 00:00:00 +0000 AI tools are absurdly good at writing AWS code. They understand IAM policies, VPC configurations, and service integrations in a way that feels magical. Until they don't. The failure mode everyone hits is the same: the AI writes code, writes tests, the tests pass, you ship it—and then AWS returns something completely different in production. Here's how to test AI-generated AWS code properly. The debugging revelation</h2> I started using ChatGPT to write code the day it launched. The first "oh shit, this actually works" moment wasn't code generation—it was debugging. AWS is full of rough edges. Permissions that fail silently. Networking that breaks in non-obvious ways. Security groups that look right but aren't. When you hit one of these, you're stuck reading docs, checking IAM, comparing VPC settings. AI is absurdly fast at this. Paste an error, describe what you tried, get three hypotheses back. "Check if the security group allows egress on 443." "Verify the IAM role has sts:AssumeRole</code> for that principal." One of them is usually right. That's when I realized AI understands AWS in a way that's genuinely useful. Not because it memorized documentation, but because it's seen every way these things fail. The hallucination problem</h2> Then you hit the limits. When debugging gets hard—when nothing makes sense—AI starts making things up. It suggests an AWS feature that doesn't exist. A configuration parameter that was never real. An API method that would solve your problem perfectly, except it's not in the SDK. This is the failure mode everyone talks about: hallucination. It's real. When the AI doesn't know, it confidently invents an answer. The standard response is "review every line the AI writes." That advice doesn't scale. And it doesn't work. Why manual review fails</h2> The problem with "review every line" is that it assumes the human is the source of truth. But humans miss things. Humans get tired. Humans skim code that looks reasonable. More importantly: if the AI writes both the code and the tests, manual review doesn't catch the right bugs. Here's the trap: AI generates code</li> Developer reviews it (looks fine)</li> AI writes tests</li> Tests pass</li> Ship it</li> </ol> Except the tests can be wrong in the same way the code is wrong. The tests assert that the bug exists successfully. Everything is internally consistent, but none of it matches reality. This is especially bad with mocks. The AI will happily mock AWS APIs in a way that matches the buggy code. The tests pass. Your code goes to production. AWS returns something completely different. Good luck debugging that at 2am. Manual review didn't save you because the bug wasn't obvious. The tests didn't save you because they tested the wrong behavior. What actually works: guardrails that can't be gamed</h2> Here's what worked for fakecloud: 1. Real integration tests, not mocks. Every feature ships with E2E tests using the actual AWS SDK. Not unit tests with mocked clients. Actual aws-sdk-rust</code> calls against fakecloud. When the test uses the real SDK and the code is wrong, the test fails. The AI iterates until it's right. This matters most for cross-service wiring—the stuff that's easy to get subtly wrong and almost impossible to catch with mocks. fakecloud actually executes the integrations: an EventBridge rule really triggers the Step Functions state machine, an SES inbound rule really invokes the Lambda, an S3 event really lands in SQS. If the AI wires it up wrong, the test fails for the same reason it would fail in production. 2. Conformance testing the AI didn't write. We auto-generate 54,000+ test variants from AWS Smithy models. Every operation, every parameter, every boundary condition, every error case. The AI can't write code that games these tests because it didn't write the tests. They're generated from AWS's service definitions. 3. Side-by-side testing against real AWS. The same test suite runs against both fakecloud and actual AWS. When behavior diverges, it's a bug. This is the key insight: the guardrails are automated and external to the code being tested. The AI can't game them. They catch everything. And when they're set up right, they catch it before you see the code. What this means for AWS testing</h2> If you're building on AWS and using AI to write code, here's what matters: Don't mock the AWS SDK in your tests. Use fakecloud, LocalStack, Testcontainers, or real AWS with cleanup afterward. But don't mock. Mocks let AI-generated tests pass while asserting the wrong behavior. Build guardrails the AI can't game. If the AI writes both the code and the tests, make sure tests are anchored to something external—real SDK behavior, schemas generated from service definitions, or validation against actual AWS. Verify architecture, not syntax. Your job isn't to review every line. It's to make sure the AI is building the right thing in the right way. If the structure is sound and the tests pass, the code is probably fine. Let the AI iterate. When tests fail, let the AI fix them. It's faster than you at reading error messages and adjusting code. Your job is to make sure it's converging toward the right solution. The test suite is the guardrail</h2> I built fakecloud almost entirely with Claude. 22 AWS services, 1,150+ operations, 100% conformance to AWS behavior. fakecloud works because the tests verify everything: 54,000+ conformance tests generated from AWS Smithy models</li> E2E tests using real AWS SDKs</li> CI that runs everything on every commit</li> Side-by-side testing against actual AWS</li> </ul> These guardrails are external to the code being tested. The AI can't game them. They catch bugs before I see the code. If your tests are good—real integration tests, not mocks, not stubs—then AI-generated code is as reliable as human-written code. Maybe more reliable, because the AI doesn't get bored and skip edge cases. If your tests are bad—mocks everywhere, written by the same AI that wrote the code—then you're in trouble whether a human or an AI wrote the code. The tooling matters. The tests matter. The mocks-versus-real-APIs decision matters. fakecloud exists because AI tools need a way to verify AWS code against real behavior, not just against tests they wrote themselves. Repo: github.com/faiscadev/fakecloud</a></li> Site: fakecloud.dev</a></li> Install: curl -fsSL https://fakecloud.dev/install.sh | bash</code></li> </ul> If you're using Claude Code, Cursor, or any other AI coding tool to write AWS applications, you need something that behaves like AWS to test against. Not mocks. Not stubs. Real API behavior. That's what fakecloud is for. And if you find a case where fakecloud behaves differently from AWS—that's a bug. Open an issue</a>. Because the tests should have caught it. How to test Bedrock code locally, for free, deterministically Unknown — Mon, 13 Apr 2026 00:00:00 +0000 If you're writing code that calls Bedrock, you already know the problem. Every test run burns tokens. Every CI build hits rate limits. Every assertion on model output breaks because the model returned something slightly different this time. The only way to make it stop is to mock, and then your tests don't test anything real. This is the most frustrating corner of AWS to test against, and until a few days ago there was no good answer. LocalStack doesn't emulate Bedrock at any tier — not free, not paid. If you wanted a local Bedrock, you built it yourself. So I built one. The problem with real Bedrock in tests</h2> Four things break, in order of how much they hurt: Cost. Every test run that calls a model is a line item on your AWS bill. A CI job that runs on every PR and exercises a Bedrock code path a dozen times becomes real money fast. Teams end up building elaborate VCR-cassette systems to record-once-and-replay, which works until the request shape changes and everything silently goes stale. </li> Rate limits. Bedrock has per-account quotas. A noisy test suite gets throttled. Flaky CI. Engineers angry. You start skipping tests in CI to stay under the limit, which defeats the point of having them. </li> Non-determinism. Real models return different text every run, even at temperature 0. Snapshot tests are impossible. Assertions on specific strings are impossible. Everyone ends up asserting that some output was produced, which is the weakest possible test — it would pass even if the model returned the string "cabbage." </li> No offline dev. On a plane, on a train, on bad hotel wifi, in a datacenter without egress. You can't develop Bedrock code at all without a live connection to AWS. </li> </ol> The standard response is "mock the SDK." The problem with mocking the SDK is that it's AI-generated code calling an AI API, and if you let the AI generate both the code and the mocks, your tests will happily assert the wrong behavior and pass. Your code never talks to anything that looks like Bedrock — it talks to a fake object that matches the SDK's interface. If your code assembles the request wrong, the mock doesn't care. What fakecloud gives you</h2> fakecloud implements 111 Bedrock operations — the full runtime (InvokeModel, Converse, both streaming variants), plus guardrails, customization jobs, model imports, the whole control plane. You point any AWS SDK at http://localhost:4566</code> with dummy credentials and it works. But the interesting part isn't the operation count. The interesting part is that you can make the "model" return exactly what you want, triggered by exactly what you want, and then assert on exactly what your code sent. Configurable responses per prompt. Set a rule like "when the prompt contains 'summarize', return this JSON; when it contains 'classify', return that one." Your code's branching logic gets tested against deterministic, fixture-like responses you control. Fault injection. Tell fakecloud to throw ThrottlingException</code> on the next call. Your retry logic gets exercised. Your fallback-model logic gets exercised. Your circuit breaker gets exercised. All the hard parts of production Bedrock code, which currently go untested on every project I've seen. Call history. After your code runs, query fakecloud for every InvokeModel and Converse call it made — prompts, outputs, timestamps, error field. Assert on what your code sent, not just on what it received. Together, that's a complete test loop. A real example</h2> Here's a spam classifier that calls Claude via Bedrock. I want to test both the happy path (spam vs. ham branching) and the retry path (throttling recovery). Using the TypeScript SDK</a>: import { FakeCloud } from "fakecloud"; import { BedrockRuntimeClient, InvokeModelCommand, } from "@aws-sdk/client-bedrock-runtime"; const fc = new FakeCloud(); const modelId = "anthropic.claude-3-haiku-20240307-v1:0"; beforeEach(() => fc.reset()); test("classifier branches on spam vs ham", async () => { await fc.bedrock.setResponseRules(modelId, [ { promptContains: "buy now", response: '{"label":"spam"}' }, { promptContains: null, response: '{"label":"ham"}' }, // catch-all ]); await classify("hello friend"); await classify("buy now cheap pills"); const { invocations } = await fc.bedrock.getInvocations(); expect(invocations).toHaveLength(2); expect(invocations[0].output).toContain("ham"); expect(invocations[1].output).toContain("spam"); }); test("retries on ThrottlingException", async () => { await fc.bedrock.queueFault({ errorType: "ThrottlingException", message: "Rate exceeded", httpStatus: 429, count: 1, // only the first call faults; the retry succeeds }); await classify("hello"); const { invocations } = await fc.bedrock.getInvocations(); expect(invocations).toHaveLength(2); expect(invocations[0].error).toContain("ThrottlingException"); expect(invocations[1].error).toBeNull(); });</code></pre> No tokens burned. No rate limits hit. No test flake. Runs on a plane. The classify</code> function is unchanged from production — it's a real BedrockRuntimeClient</code> calling a real InvokeModelCommand</code>. The only difference is endpoint: "http://localhost:4566"</code> in the SDK config. Your production code never knows it's talking to fakecloud, which is exactly what you want: the tests exercise the same code path that runs in production. Isn't a fake model just a mock?</h2> No, and the distinction is important. A mock replaces the SDK client. A mock knows what method you called and what arguments you passed, and returns whatever you told it to. If your code uses a deprecated field, or sends invalid JSON, or builds the request wrong, the mock doesn't care — it was told to return a value and it returns it. fakecloud is a real HTTP server implementing the real Bedrock wire protocol. Your AWS SDK sends real SigV4-signed requests over real HTTP. If your code builds the request wrong, fakecloud rejects it the same way real AWS would. The only thing that's "fake" is the inference — instead of calling a real model, fakecloud returns the response you configured. And that's not a limitation, it's the point. You don't want a real model in tests. You want a predictable one. Real models are for production, where you want the best possible output. Tests are for verifying that your code behaves correctly given an output. Those are different problems and they need different tools. When you don't configure anything, fakecloud falls back to a canned response per provider format — Anthropic, Titan, Llama, Cohere, Mistral all get provider-shaped defaults. So even a no-configuration test still gets something realistic back. You only need to configure responses when your code actually branches on content. What this unlocks</h2> Things that were hard or impossible before, that are now just tests: Free CI. Run your full Bedrock-exercising test suite on every PR, every commit, every dependabot bump. No token budget to worry about.</li> Deterministic snapshots. The model returns exactly what you configured. Your snapshot tests work again.</li> Offline development. Write Bedrock code on a plane. Debug retry logic on a train. Iterate without thinking about AWS at all.</li> Error-path testing. Exercise every catch</code> block in your code. Retry, fallback, circuit-break, degrade-gracefully — all testable, all deterministic.</li> Cross-service integration tests. Your Lambda calls Bedrock, writes to DynamoDB, and publishes to EventBridge? fakecloud runs all of those for real, in the same process, wired together. One test can exercise the whole flow.</li> </ul> Try it</h2> curl -fsSL https://fakecloud.dev/install.sh | bash fakecloud</code></pre> Then point any AWS SDK at http://localhost:4566</code> with dummy credentials. The TypeScript, Python, Go, and Rust first-party SDKs all have ergonomic helpers for the Bedrock introspection and configuration endpoints shown above. Repo: github.com/faiscadev/fakecloud</a></li> Site: fakecloud.dev</a></li> </ul> If you try it and find a case where fakecloud's Bedrock implementation diverges from real AWS, that's a bug — open an issue</a>. The tests should have caught it. Free, Open-Source LocalStack Alternative for AWS Testing Unknown — Sat, 11 Apr 2026 00:00:00 +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?</h2> 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</li> Lambda — real code execution via Docker, 13 runtimes, event source mappings</li> SQS — FIFO queues, dead-letter queues, long polling</li> SNS — fan-out to SQS/Lambda/HTTP, filter policies</li> DynamoDB — tables, transactions, PartiQL, streams, global tables</li> EventBridge — pattern matching, scheduled rules, API destinations</li> RDS — PostgreSQL/MySQL/MariaDB via Docker, snapshots, read replicas</li> ElastiCache — Redis/Valkey via Docker, replication groups, failover</li> SES — v2 API (97 operations), inbound email pipeline, event destinations</li> Cognito User Pools — authentication, MFA, user management</li> Kinesis — data streams, shard iterators, stream retention</li> Step Functions — ASL interpreter, Lambda/SQS/SNS/DynamoDB integrations</li> CloudWatch Logs — groups, streams, filtering, subscriptions</li> API Gateway v2 — HTTP APIs with Lambda integration</li> IAM, STS, SSM, Secrets Manager, KMS, CloudFormation</li> </ul> Full service list with operation counts</a> LocalStack vs fakecloud</h2> 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</th> fakecloud</th> LocalStack Community</th></tr></thead> License</td> AGPL-3.0 (free, open-source)</td> Proprietary</td></tr> Auth required</td> No</td> Yes (account + token)</td></tr> Commercial use</td> Free</td> Paid plans only</td></tr> Docker required</td> No (standalone binary)</td> Yes</td></tr> Startup time</td> ~500ms</td> ~3s</td></tr> Idle memory</td> ~10 MiB</td> ~150 MiB</td></tr> Install size</td> ~19 MB binary</td> ~1 GB Docker image</td></tr> AWS services</td> 20</td> 30+</td></tr> Test assertion SDKs</td> TypeScript, Python, Go, Rust</td> Python, Java</td></tr> Cognito User Pools</td> 80 operations</td> Paid only</a></td></tr> SES v2</td> 97 operations</td> Paid only</a></td></tr> SES inbound email</td> Real receipt rule action execution</td> Stored but never executed</a></td></tr> RDS</td> 22 operations, PostgreSQL/MySQL/MariaDB via Docker</td> Paid only</a></td></tr> ElastiCache</td> 44 operations, Redis/Valkey via Docker</td> Paid only</a></td></tr> </tbody></table> 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</h2> LocalStack went proprietary. In March 2026, localstack:latest</code> 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</h2> 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</li> 280+ end-to-end tests using the official AWS SDKs (aws-sdk-rust, boto3, aws-sdk-js)</li> Automated testing against real AWS — our test suite runs against both fakecloud and actual AWS to verify behavioral parity</li> </ul> When tests fail, we fix the behavior. We don't stub responses or return fake success codes. Getting started</h2> Install and run fakecloud: curl -fsSL https://fakecloud.dev/install.sh | bash fakecloud</code></pre> Or via Docker: docker run --rm -p 4566:4566 ghcr.io/faiscadev/fakecloud</code></pre> Point your AWS SDK at http://localhost:4566</code> with dummy credentials: aws --endpoint-url http://localhost:4566 sqs create-queue --queue-name test-queue</code></pre>Test assertions with fakecloud SDKs</h2> 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);</code></pre> SDKs available for TypeScript, Python, Go, and Rust. What's not implemented (yet)</h2> 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</a> if there's a service you need. Roadmap</h2> Coming next: Bedrock — AI/ML testing (high demand across the ecosystem)</li> Lambda Containers — practical container support with ECR</li> CloudFront — CDN configuration testing</li> CloudWatch Metrics — complete monitoring story alongside Logs</li> Athena — SQL analytics on S3</li> More RDS engines (Oracle, SQL Server)</li> </ul> Full roadmap</a> Other alternatives to LocalStack</h2> 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</h2> Repo: github.com/faiscadev/fakecloud</a></li> Site: fakecloud.dev</a></li> Install: curl -fsSL https://fakecloud.dev/install.sh | bash</code></li> </ul> If you find a case where fakecloud behaves differently from AWS, open an issue</a> — that's a bug, and we'll fix it. 700 commits in 6 days: how to trust LLM-generated code Unknown — Fri, 10 Apr 2026 00:00:00 +0000 fakecloud</a> went from first commit to 17 AWS services, 1,000+ tests, and 700 commits in 6 days. Almost all of the code was generated by LLMs. The obvious question: how do you trust any of it? The problem with vibe coding</h2> Andrej Karpathy coined "vibe coding" in early 2025 — the idea of just accepting whatever the LLM gives you without really looking at it. A year later, the results are in: a CodeRabbit study of 470 GitHub repositories</a> found that AI co-authored code contains 1.7x more bugs than human-written code, with logic errors up 75%, security vulnerabilities up 2.74x, and concurrency bugs doubled. That's what happens without guardrails. The answer isn't to stop using LLMs — it's to build the systems that make LLM output trustworthy. The short answer</h2> Tests. Not unit tests that mock everything — real end-to-end tests that spin up the server, make actual AWS SDK calls, and verify the responses. If the LLM generates something that doesn't match real AWS behavior, a test fails. If no test catches it, there should be a test for it. That's the foundation. The rest is process. The workflow</h2> Here's what building a new feature in fakecloud actually looks like: 1. Evaluate. Start by looking at the current conformance state. What's missing? What's the next highest-value thing to implement? The LLM helps here — it can cross-reference the AWS API models with what's already implemented and suggest what to tackle next. 2. Plan. This is the most important step, and it's mostly human. The LLM proposes an approach, but there's a lot of back and forth. Multiple alternatives get explored. Architecture decisions get debated. The right technical direction matters more than speed — a bad foundation generates bad code forever. This is what some are calling spec-driven development</a> — writing a real plan with goals, constraints, and implementation notes before any code gets generated. 3. Break it down. The work gets split into well-scoped pieces. Each piece includes E2E tests — not just relying on the conformance framework, but dedicated tests that exercise real workflows through the AWS SDK. 4. Implement. The LLM writes the code and the tests, runs them locally, iterates until green. By the time a PR opens, the tests are already passing. 5. CI. The PR hits CI — clippy, fmt, the full test suite. If something fails, the LLM iterates until it's green. No human intervention needed for mechanical fixes. 6. Code review. Two layers: an AI code reviewer catches surface issues, then a human review. Addy Osmani put it well</a>: "AI didn't eliminate code review — it made verification mandatory." What the human actually reviews</h2> Not every line the same way. Tests get reviewed exhaustively. Every line. Every assertion. Does this test actually verify the right behavior? Does it match what real AWS would do? Could it pass while the implementation is wrong? The tests are the source of truth for the project, so they have to be right. Implementation gets scanned. A top-to-bottom read looking for architectural issues, weird patterns, unnecessary complexity. Sometimes things get sent back for refactoring — DRY violations, odd abstractions, things that don't fit the codebase style. The mental model: if the tests are comprehensive and correct, the implementation is constrained to be correct. It might not be elegant, but it works. Elegance can be fixed later. Correctness can't be faked. This aligns with what Gergely Orosz describes</a> as the shift in engineering — from writing every line to "assessing quality and architectural soundness." The engineer becomes a supervisor and decision-maker, not a typist. Why this only works with real tests</h2> Most codebases test with mocks. The test asserts that function A calls function B with the right arguments. That tells you nothing about whether the actual behavior is correct — it tells you the plumbing is connected. Mocked tests are particularly dangerous with LLM-generated code because the LLM writes both the implementation and the test. If the implementation has a bug, the LLM will happily write a test that asserts the buggy behavior. The mock doesn't care — it returns whatever it's told to. This is likely a contributor to the 75% increase in logic errors found in AI-generated PRs — the tests pass, but they're testing the wrong thing. fakecloud's E2E tests use the official aws-sdk-rust</code> crate. They spin up a real fakecloud server, make real API calls, and verify real responses. If CreateQueue</code> followed by SendMessage</code> followed by ReceiveMessage</code> doesn't return the right message with the right attributes, the test fails. No mocks. No fakes. Real behavior. That's 650+ E2E tests, plus 600+ conformance tests that validate operations against official AWS Smithy API models using checksums. Together, they form a safety net tight enough to let LLMs write code at speed without sacrificing correctness. What tests don't catch</h2> To be clear: this isn't bulletproof. E2E tests are great at catching behavioral bugs, but they're weaker at catching security vulnerabilities, performance issues, and concurrency bugs — exactly the categories where AI-generated code is worst</a> (2.74x more security issues, 8x more excessive I/O operations). That's where the other layers matter. Static analysis (clippy, in Rust's case) catches entire categories of bugs at compile time. AI code reviewers catch patterns that tests miss. The human review catches architectural problems. No single layer is sufficient — it's the combination that makes the system trustworthy. Making a project LLM-friendly</h2> This approach isn't specific to fakecloud. Any project can get here: Start with tests. If the project doesn't have comprehensive E2E or integration tests, that's the first thing to build — and LLMs are great at helping with that. Build the test infrastructure first, then use it as the guardrail for everything that follows. This is the single highest-leverage investment for LLM-assisted development. Invest in CI. Linting, formatting, full test suites, automated code review. Every automated check is one less thing that can slip through. If speed goes up, the number of tests should go up proportionally. Steer the architecture. The LLM is a force multiplier, not an architect. Discuss the plan. Explore alternatives. Push back when the approach doesn't feel right. The human decides the direction; the LLM executes it. Review what matters. Tests get the most scrutiny. Implementation gets scanned for patterns. Don't try to read every line like you wrote it — that doesn't scale. Trust the tests, verify the tests are right. The real insight</h2> The question isn't "can you trust LLM-generated code?" The answer is obviously no — not by default. The 1.7x bug rate proves it. The real question is: can you build a system where LLM-generated code is continuously verified? Where every PR runs against hundreds of tests before a human ever sees it? Where the test suite is comprehensive enough that "tests pass" is a meaningful signal? Where static analysis, AI review, and human review each catch what the others miss? If yes, then the LLM is just a very fast, very tireless junior developer that needs good guardrails. And 700 commits in 6 days stops being scary — it's just what happens when the guardrails are in place. Why I'm building a free, open-source AWS emulator Unknown — Mon, 06 Apr 2026 00:00:00 +0000 A few days ago, our CI started failing. The culprit: localstack:latest</code> 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</h2> I should back up. I care about tests a lot. Enough to become a maintainer of Chai.js</a>. 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</h2> 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</h2> 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</code>, then SendMessage</code>, then ReceiveMessage</code> 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</code> crate and 34,856 auto-generated conformance test variants validated against official AWS Smithy models — covering all 731 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</h2> 13 services, 731 API operations, all open source, all free: S3 (74 actions) — objects, multipart uploads, versioning, lifecycle, notifications, encryption</li> SQS (20 actions) — FIFO queues, dead-letter queues, long polling, batch operations</li> SNS (34 actions) — fan-out to SQS, HTTP delivery, filter policies, platform applications</li> EventBridge (57 actions) — pattern matching, scheduled rules, connections, API destinations, endpoints</li> IAM (128 actions) — users, roles, policies, groups, instance profiles, OIDC/SAML providers</li> STS (8 actions) — assume role, session tokens, federation</li> SSM (146 actions) — parameters, documents, commands, maintenance windows, associations, automation, sessions</li> DynamoDB (57 actions) — tables, items, transactions, PartiQL, backups, global tables, streaming</li> Lambda (10 actions) — function CRUD, invoke, event source mappings</li> Secrets Manager (23 actions) — versioning, soft delete, rotation, replication, resource policies</li> CloudWatch Logs (113 actions) — groups, streams, filtering, deliveries, transformers, anomaly detection</li> KMS (53 actions) — encryption, aliases, key management, grants, custom key stores</li> CloudFormation (8 actions) — template parsing, resource provisioning</li> </ul> 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</h2> curl -fsSL https://fakecloud.dev/install.sh | bash fakecloud</code></pre> Then point any AWS SDK at http://localhost:4566</code> with dummy credentials. That's it. The code is at github.com/faiscadev/fakecloud</a>. 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</a>. That's a bug, and we'll fix it.

Service</th>	Operations Supported</th>	Key Features</th></tr></thead>
S3</strong></td>	107</td>	Multipart uploads, bucket policies, object tagging</td></tr>
Lambda</strong></td>	85</td>	Cross-service triggers, environment variables, layers</td></tr>
DynamoDB</strong></td>	57</td>	TTL, Global Secondary Indexes (GSI), Transactions</td></tr>
SQS/SNS</strong></td>	65</td>	Dead-letter queues, SNS-to-SQS fanout, filtering</td></tr>
Bedrock</strong></td>	106</td>	Foundation model invocation, listing models, tags</td></tr>
IAM</strong></td>	176</td>	Policy evaluation, role assumption, credential validation</td></tr> </tbody></table> Reaching 100% conformance across 2,591 operations is not a manual task. It is the result of a rigorous, model-driven engineering process.</p> The Smithy Protocol: 86,000+ Test Variants</h2> To ensure that fakecloud behaves exactly like the real AWS, we leverage Smithy</strong>, the interface definition language (IDL) used by AWS to build their own SDKs and services.</p> fakecloud uses official AWS Smithy models to generate a massive suite of test variants—86,327 in total, with 100% currently passing against the local binary.</p> How the Test Suite Works</h3> Model Extraction:</strong> We pull the latest Smithy models for each supported AWS service.</li> Variant Generation:</strong> For every operation (e.g., `PutItem</code> in DynamoDB), the test generator creates thousands of permutations, including edge cases like empty strings, maximum payload sizes, and invalid characters.</li>` `Dual Execution:</strong> Each test variant is run against both the real AWS production environment and the local fakecloud binary.</li>` Assertion:</strong> The responses—including headers, status codes, and error messages—must match exactly. If AWS returns a 400 Bad Request</code> with a specific SerializationException</code>, fakecloud must return the same.</li> </ol> This protocol ensures that when you use the official AWS SDK in your application, it cannot distinguish between fakecloud and the real cloud.</p> Performance by the Numbers: ~32 MB and ~300ms</h2> For a senior developer, the "inner loop" of development—code, test, repeat—must be as fast as possible. Waiting for a heavy Docker container to pull or a complex emulator to initialize is a productivity killer.</p> Download Size:</strong> ~32 MB compressed (~85 MB unpacked). Small enough for any CI cache and faster to pull than a multi-gigabyte Docker image.</li> Startup Time:</strong> ~300ms cold-start on a modern laptop. fakecloud is ready to accept requests before you can switch from your terminal to your IDE.</li> Memory Footprint:</strong> Minimal. Unlike Java-based or Python-based emulators that can consume gigabytes of RAM, fakecloud's Rust-based architecture is optimized for low-resource environments.</li> </ul> # Start fakecloud in the background</span></span> ./fakecloud</span> &</span></span> </span> # Point your AWS CLI to the local endpoint</span></span> aws</span> s3 mb s3://my-local-bucket</span> --endpoint-url</span> http://localhost:4566</span></span></code></pre>AI Development with Full Bedrock Support</h2> In 2026, AI integration is no longer optional. Developing applications that use Amazon Bedrock typically requires a paid AWS account and incurs per-token costs even during the prototyping phase.</p> fakecloud provides support for 106 Bedrock operations (plus the Bedrock Agent, Agent Runtime, and Runtime APIs). This allows you to build and test your AI orchestration logic—such as prompt chaining, model selection, and guardrail integration</a>—locally and for free. While fakecloud does not ship with the multi-gigabyte weights of frontier models, it provides the API structure necessary to test your application's interaction with the Bedrock service. You can learn more in our guide to local Bedrock testing</a>.</p> SDK-Client Separation: Testing with Confidence</h2> One of the most powerful features of fakecloud is the separation between your application's SDK and the fakecloud testing SDK.</p> Your application uses the standard AWS SDK (e.g., aws-sdk-go-v2</code> or boto3</code>). It doesn't know fakecloud exists; it just sees an endpoint. Meanwhile, your test suite uses the fakecloud SDK</strong> to perform "out-of-band" assertions.</p> For example, you can use the fakecloud SDK to inspect the internal state of an SQS queue or to manually trigger a Lambda without going through the standard AWS API. This allows for deep integration testing that is impossible with simple mocks.</p> // Your App Code</span></span> s3Client.</span>PutObject</span>(ctx,</span> &</span>s3</span>.</span>PutObjectInput</span>{</span>...</span>})</span></span> </span> // Your Test Code (using fakecloud SDK)</span></span> assertions.</span>AssertBucketCount</span>(t,</span> "my-local-bucket"</span>,</span> 1</span>)</span></span></code></pre>Integrate fakecloud into Your CI Pipeline</h2> Because fakecloud is a standalone binary with no external dependencies, integrating it into a CI/CD pipeline is trivial. There are no Docker-in-Docker complexities or auth secrets to configure.</p> Download the binary:</strong> Use a simple curl</code> or wget</code> in your CI script.</li> Start the service:</strong> Run ./fakecloud</code>.</li> Run your tests:</strong> Point your test suite to http://localhost:4566</code>.</li> </ol> This approach ensures that your CI environment is an exact replica of your local development environment, further reducing the risk of deployment-time surprises.</p> The Future of Local Cloud Development</h2> The trend toward "cloud-only" development is a response to the difficulty of building high-fidelity emulators. fakecloud proves that with a model-driven approach and a commitment to API conformance, the local environment can remain the most productive place for a developer to work.</p> By eliminating the friction of accounts, tokens, and costs, fakecloud returns control to the engineer. You can focus on building features and refining architecture, confident that your local tests are backed by 86,000+ Smithy-generated test variants and 100% conformance to the AWS API.</p> To get started, download the latest binary for your architecture and run the start command to begin developing against a local AWS environment that actually works.</p> curl</span> -fsSL</span> https://fakecloud.dev/install.sh</span> \|</span> bash</span></span> fakecloud</span></span></code></pre> Testing SNS to S3 Triggers Locally in 500ms Unknown — Tue, 19 May 2026 00:00:00 +0000 Mocking individual AWS services is a common strategy that leads to production failures. When you mock a call to sns.Publish</code> or s3.PutObject</code>, you are testing your ability to write a mock, not the infrastructure's ability to handle the event. In a real-world event-driven system, the failure points live in the gaps between services: the IAM policy that doesn't quite allow the SNS fanout, the S3 bucket notification configuration that points to a non-existent ARN, or the Lambda trigger that fails because of a malformed event payload.</p> As of 2026-05-13, the landscape for local AWS development has shifted. With major incumbents moving to proprietary models and requiring mandatory auth tokens even for local runs, developers need a high-fidelity, zero-friction alternative. fakecloud</a> provides a standalone ~19MB binary that starts in ~500ms, offering 100% API conformance across 2,591 operations without requiring an account, internet connection, or subscription.</p> The Integration Gap: Why Mocks Fail</h2> Traditional unit testing with mocks assumes that if your code calls an API correctly, the infrastructure will behave as expected. This assumption is dangerous in complex integrations like an SNS-to-S3 trigger workflow.</p> Consider a scenario where an SNS message triggers a fanout to multiple S3 buckets or a Lambda function that subsequently writes to S3. If you mock the SNS client, you never verify:</p> The actual JSON structure of the event delivered to the subscriber.</li> The latency and retry logic inherent in the SNS-to-S3 delivery path.</li> The cross-service permissions required for the integration to function.</li> </ol> fakecloud eliminates this gap by running the actual service logic locally. When your application publishes to a fakecloud SNS topic, the binary executes the fanout logic, constructs the real event payload, and delivers it to the local S3 or Lambda service exactly as the AWS production environment would.</p> Scenario: The SNS-to-S3 Fanout</h2> In this walkthrough, we will implement a common architectural pattern: an SNS topic that receives a message and triggers an S3 upload via a Lambda function. This tests the full chain of command: SNS -> Lambda -> S3</code>.</p> The "No" List</h3> Before we start, note what you do not</strong> need:</p> No AWS account.</li> No AWS_ACCESS_KEY_ID</code> validation (use dummy</code> for everything).</li> No internet connection.</li> No Docker (unless you are running Lambda functions).</li> No auth tokens or login commands.</li> </ul> Execution: Launching the Stack</h2> First, start the fakecloud binary. It listens on the standard port 4566 and is ready to accept requests in less than half a second.</p> # Start the fakecloud binary</span></span> ./fakecloud</span></span> </span> # In a separate terminal, configure your local resources</span></span> export</span> AWS_ENDPOINT_URL</span>=</span>"http://localhost:4566"</span></span> export</span> AWS_ACCESS_KEY_ID</span>=</span>"dummy"</span></span> export</span> AWS_SECRET_ACCESS_KEY</span>=</span>"dummy"</span></span> export</span> AWS_REGION</span>=</span>"us-east-1"</span></span> </span> # 1. Create the SNS Topic</span></span> TOPIC_ARN</span>=</span>$(</span>aws</span> sns create-topic</span> --name</span> local-events</span> --query</span> "TopicArn"</span> --output</span> text</span>)</span></span> </span> # 2. Create the S3 Bucket</span></span> aws</span> s3 mb s3://processed-data</span></span> </span> # 3. Create the Lambda function (using a pre-built zip)</span></span> aws</span> lambda create-function</span> \</span></span> --function-name</span> s3-uploader</span> \</span></span> --runtime</span> python3.12</span> \</span></span> --handler</span> index.handler</span> \</span></span> --role</span> arn:aws:iam::000000000000:role/lambda-role</span> \</span></span> --zip-file</span> fileb://function.zip</span></span> </span> # 4. Subscribe the Lambda to the SNS Topic</span></span> aws</span> sns subscribe</span> \</span></span> --topic-arn</span> "</span>$TOPIC_ARN</span>"</span> \</span></span> --protocol</span> lambda</span> \</span></span> --notification-endpoint</span> arn:aws:lambda:us-east-1:000000000000:function:s3-uploader</span></span></code></pre> At this point, your local environment is fully wired. The fakecloud binary is managing the state of 39 AWS services in-memory, backed by 86,327 Smithy-model-generated test variants to ensure the API responses match AWS exactly.</p> 100% Conformance Across 2,591 Operations</h2> fakecloud is not a collection of simple mocks. It is a high-fidelity emulator built on the Smithy models used by AWS to define their own APIs. As of May 2026, fakecloud supports 2,591 operations with 100% behavioral conformance. This includes complex behaviors like:</p> Service</th> Supported Operations</th> Key Integration Features</th></tr></thead> SNS</strong></td> 48</td> Fanout to SQS, Lambda, and HTTP; Message Filtering; Attributes.</td></tr> S3</strong></td> 124</td> Multipart uploads; Bucket notifications; Lifecycle policies; Object tagging.</td></tr> Lambda</strong></td> 62</td> 23+ runtimes; Event source mappings; Layer support; Synchronous/Asynchronous invocation.</td></tr> Bedrock</strong></td> 111</td> Full support for frontier models (Claude 4.7, GPT-5.5) as of 2026-05-13.</td></tr> </tbody></table> This depth ensures that when you call sns.Publish</code>, the message doesn't just disappear into a black hole. It is parsed, filtered according to your subscription attributes, and delivered to the target. If the target is a Lambda function, fakecloud spins up the appropriate container, injects the event, and captures the logs.</p> Assertion: Using the fakecloud SDK</h2> Testing asynchronous integrations often involves "sleep and pray" or complex polling logic. You upload a file and then poll S3 for 10 seconds hoping the Lambda finished its work. fakecloud solves this with first-party SDKs for assertions in 6+ programming languages (TypeScript, Python, Go, PHP, Java, and Rust).</p> Instead of polling the public AWS API, you use the fakecloud SDK to inspect the internal state of the emulator. This allows for deterministic, sub-second test execution.</p> import</span> boto3</span></span> from</span> fakecloud_sdk</span> import</span> FakeCloudClient</span></span> </span> # Standard AWS SDK for the application logic</span></span> sns</span> =</span> boto3.client(</span>"sns"</span>,</span> endpoint_url</span>=</span>"http://localhost:4566"</span>)</span></span> </span> # fakecloud SDK for the test assertions</span></span> fc</span> =</span> FakeCloudClient(</span>endpoint</span>=</span>"http://localhost:4566"</span>)</span></span> </span> def</span> test_sns_to_s3_trigger</span>():</span></span> # 1. Trigger the workflow</span></span> sns.publish(</span>TopicArn</span>=</span>topic_arn,</span> Message</span>=</span>"test-payload"</span>)</span></span> </span></span> # 2. Assert using the fakecloud SDK</span></span> # This checks the internal event queue to ensure the message was processed</span></span> integration_state</span> =</span> fc.inspect_integration(</span>source</span>=</span>"sns"</span>,</span> target</span>=</span>"lambda"</span>)</span></span> assert</span> integration_state.successful_invocations</span> ==</span> 1</span></span> </span></span> # 3. Verify the final side effect in S3</span></span> s3</span> =</span> boto3.client(</span>"s3"</span>,</span> endpoint_url</span>=</span>"http://localhost:4566"</span>)</span></span> response</span> =</span> s3.list_objects_v2(</span>Bucket</span>=</span>"processed-data"</span>)</span></span> assert</span> len</span>(response.get(</span>"Contents"</span>, []))</span> ==</span> 1</span></span></code></pre> By using the inspect_integration</code> method, you eliminate the non-determinism of local testing. You are asserting on the fact that the event loop completed, not just that the initial API call returned a 200 OK.</p> AI Development: Local Bedrock Support</h2> As of 2026-05-13, AI integration is a core part of the AWS ecosystem. fakecloud includes full support for Amazon Bedrock (111 operations), allowing you to develop agentic workflows locally. This is particularly useful for testing how your SNS-triggered Lambda functions interact with foundation models like Claude 4.7 or the latest Amazon Nova Premier models.</p> Because fakecloud is a single binary, you can run these AI integration tests in restricted environments where internet access is prohibited for security reasons. You can configure deterministic responses for Bedrock prompts, allowing you to test your application's parsing logic and error handling without incurring costs or dealing with the latency of frontier model APIs.</p> Performance Benchmarks: fakecloud vs. Incumbents</h2> In a modern CI/CD pipeline, every second matters. Traditional local AWS emulators often rely on heavy container orchestration, leading to multi-minute startup times and high memory overhead. fakecloud is designed for engineering pragmatism.</p> Metric</th> fakecloud</th> Proprietary Incumbents</th></tr></thead> Binary Size</strong></td> ~19 MB</td> ~250 MB+ (Docker Image)</td></tr> Startup Time</strong></td> ~500 ms</td> 30 - 90 seconds</td></tr> Idle Memory</strong></td> ~10 MiB</td> 1.5 GiB+</td></tr> Auth Required</strong></td> No</td> Yes (Auth Token/Account)</td></tr> Internet Required</strong></td> No</td> Yes (for license checks)</td></tr> License</strong></td> AGPL-3.0</td> Proprietary / Paid Tier</td></tr> </tbody></table> Running fakecloud as a background process in your GitHub Actions or GitLab CI runner adds negligible overhead. You can spin up a fresh environment for every single test file, ensuring total isolation without the performance penalty of restarting a heavy container stack.</p> Real Cross-Service Integrations</h2> The power of fakecloud lies in its ability to handle "Real" integrations. When we say 100% conformance, we mean the wire protocol and the side effects.</p> SNS Fanout</strong>: If you subscribe three different SQS queues to one SNS topic, fakecloud will deliver the message to all three, respecting individual filter policies.</li> S3 Triggers</strong>: fakecloud supports the full S3 notification configuration, including prefix/suffix filtering and all event types (s3:ObjectCreated:</code>, s3:ObjectRemoved:</code>, etc.).</li> SES Inbound</strong>: You can simulate receiving an email in SES and have it automatically trigger an SNS notification or save the raw email to an S3 bucket.</li> </ul> These are not hard-coded shortcuts. They are the result of a unified event-bus architecture within the fakecloud binary that mirrors the asynchronous nature of the AWS cloud.</p> Engineering Pragmatism: The AGPL-3.0 Advantage</h2> fakecloud is released under the AGPL-3.0 license for local development. This ensures that the tool remains free and open-source, protecting developers from the sudden "proprietary pivots" that have affected other tools in the space. You can audit the source code, contribute fixes, and run it in any environment—from a disconnected laptop on a plane to a high-security air-gapped server—without ever asking for permission or providing a credit card.</p> Your development workflow should not be dependent on a third-party's uptime or licensing server. By moving your integration tests to a standalone binary, you regain control over your test suite's reliability and speed.</p> Next Steps: Beyond SNS and S3</h2> Testing SNS to S3 triggers is only the beginning. The same sub-second feedback loop applies to more complex architectures involving SQS dead-letter queues, DynamoDB Streams, and EventBridge pipes.</p> To explore further integration patterns, run the following command to see the full list of supported operations for your specific service mix:</p> ./fakecloud</span> --list-operations --service</span> dynamodb</span></span></code></pre> For detailed implementation guides on setting up local SQS-to-Lambda triggers or DynamoDB global tables, visit the fakecloud documentation. Start your local environment, run your tests, and inspect the results—all before your cloud-based CI environment would have even finished its authentication handshake.</p> Local ECR with real `docker push`: what LocalStack and Moto miss, and what fakecloud ships Unknown — Thu, 23 Apr 2026 00:00:00 +0000 If your integration tests build or pull a container image and push it to ECR — CDK docker assets, ECS task definitions, Lambda container images, GitHub Actions workflows — you've hit the wall.</p> LocalStack</strong> gates ECR behind its paid Pro tier (the March 2026 shift to proprietary builds also means Community users have no ECR at all). Pro users who actually try docker push</code> hit #7186 "EOF for ecr/getCredentials"</a>, #5598 "pushed image, describe says ImageNotFound"</a>, #8128 "connection refused / 403 on docker push"</a>, and #12043 non-us-east-1 ECR timeouts</a>. The bugs are still open.</p> Moto</strong> ships an ECR control plane — you can call CreateRepository</code> and DescribeImages</code> from boto3 — but Moto is not a real HTTP server for the OCI protocol. docker push localhost:…/your-repo</code> doesn't work because the /v2/<name>/blobs/uploads/</code> endpoints don't exist. If your tests rely on CDK building and pushing a docker asset, Moto is a dead end.</p> Most teams end up running a standalone registry:2</code> container alongside their test harness. That works for raw Docker, but registry:2</code> doesn't expose DescribeRepositories</code>, BatchGetImage</code>, PutLifecyclePolicy</code>, or any of the other AWS-shaped operations. CDK, Terraform, and the AWS CLI can't talk to it.</p> What fakecloud ships</h2> fakecloud implements ECR end-to-end: all 58 operations in AWS's Smithy model and</strong> the OCI v2 Distribution HTTP protocol that Docker uses on the wire. Both back onto the same content-addressed sha256 blob store, so a layer pushed by docker push</code> is visible via BatchCheckLayerAvailability</code>, and an image manifest uploaded via PutImage</code> can be docker pull</code>ed.</p> # Start fakecloud.</span></span> curl</span> -fsSL</span> https://fakecloud.dev/install.sh</span> \|</span> bash</span></span> fakecloud</span> &</span></span> </span> # Docker login works.</span></span> aws</span> --endpoint-url</span> http://localhost:4566 ecr get-login-password</span> \</span></span> \|</span> docker</span> login</span> --username</span> AWS</span> --password-stdin</span> localhost:4566</span></span> </span> # Push an image.</span></span> aws</span> --endpoint-url</span> http://localhost:4566 ecr create-repository</span> --repository-name</span> demo</span></span> docker</span> pull busybox:latest</span></span> docker</span> tag busybox:latest localhost:4566/demo:latest</span></span> docker</span> push localhost:4566/demo:latest</span></span> </span> # The AWS SDK sees it.</span></span> aws</span> --endpoint-url</span> http://localhost:4566 ecr describe-images</span> --repository-name</span> demo</span></span></code></pre> GetAuthorizationToken</code> returns base64("AWS:<token>")</code> with a 12-hour expiry matching real AWS. The /v2/</code> endpoints honor Basic Auth and issue a WWW-Authenticate: Basic realm="fakecloud-ecr"</code> challenge on the initial unauthenticated request, so Docker's two-phase login does its handshake cleanly.</p> What else lands in the 58-op surface</h2> Lifecycle policy evaluation, not storage.</strong> PutLifecyclePolicy</code> applies immediately — imageCountMoreThan</code> and sinceImagePushed</code> rules actually prune images, ordered by rulePriority</code> per AWS semantics. GetLifecyclePolicyPreview</code> returns the digests that would be expired. No "stored but never evaluated" like LocalStack's SES receipt rules.</li> Image scanning.</strong> StartImageScan</code> stores a COMPLETE scan record that DescribeImageScanFindings</code> echoes back in the AWS-shaped payload. Real scanner integration is out of scope for a mock; a schema-complete synthetic shape lets you exercise your findings plumbing.</li> Pull-through cache rules.</strong> Full CRUD + Validate.</li> Registry policy, scanning config, replication config, repository creation templates, signing configuration, pull-time exclusions.</strong> Every operation AWS lists.</li> Smithy-exact validation.</strong> @length</code> / @range</code> / @enum</code> / @required</code> traits enforced everywhere — garbage inputs return InvalidParameterException</code> / ImageDigestDoesNotMatchException</code> / LayerDigestMismatchException</code>, not silent success.</li> </ul> Assert on what was pushed</h2> fakecloud exposes an introspection API at /_fakecloud/ecr/...</code> so your test code can check pushed images without parsing Docker output:</p> import</span> { FakeCloud }</span> from</span> "fakecloud"</span>;</span></span> </span> const</span> fc</span> = new</span> FakeCloud</span>();</span></span> const</span> {</span> repositories</span> }</span> = await</span> fc.ecr.</span>getRepositories</span>();</span></span> const</span> {</span> images</span> }</span> = await</span> fc.ecr.</span>getImages</span>(</span>"demo"</span>);</span></span> </span> expect</span>(repositories).</span>toHaveLength</span>(</span>1</span>);</span></span> expect</span>(images[</span>0</span>].imageTags).</span>toContain</span>(</span>"latest"</span>);</span></span> expect</span>(images[</span>0</span>].imageDigest).</span>toMatch</span>(</span>/</span>^</span>sha256:/</span>);</span></span></code></pre> The same API is available from Go, Python, Java, PHP, and Rust.</p> Conformance</h2> 58/58 ECR operations, 1,789/1,789 generated variant probes passing (100%) — this runs on every commit against AWS's Smithy model. The Smithy model drives positive probes (does the call succeed with sensible input?) and negative probes (does a missing required field, a too-long string, an out-of-range integer, a non-enum enum, return the right error code?). fakecloud's baseline is now 61,741/61,743 across the whole workspace.</p> Where next</h2> ECR is the prerequisite for ECS, which is the next item on the roadmap. ECS builds on the same Docker runtime pattern fakecloud already uses for Lambda — pull a real container image (from the local ECR we just built), run it, expose it via the ECS API. The moment that ships, the CDK-ECS-ECR pipeline works end-to-end in local tests.</p> fakecloud is AGPL-3.0</a>. No account needed, no paid tier.</p> Running AWS integration tests with Claude Code, Cursor, and Copilot Unknown — Wed, 22 Apr 2026 00:00:00 +0000 When you let Claude Code or Cursor run tests against AWS during a task, you want the test loop to be fast, free, and deterministic. Against real AWS, the loop is slow (minutes per test), costs money (per-request + data transfer), and leaves cruft behind that the agent won't always clean up.</p> Against a mocking library, the loop is fast but the agent can't exercise cross-service flows — so it "fixes" bugs that don't manifest in the mock and misses bugs that do manifest in AWS.</p> The middle ground: run fakecloud</a> as the test target. Real HTTP server on port 4566, speaking the AWS wire protocol at 100% conformance per implemented service. Free, single binary, no account. Agent writes code, agent runs tests, agent sees real behavior.</p> One-liner per tool</h2> Paste into your project's agent-instructions file. Agent picks up the convention and uses fakecloud for integration tests automatically.</p> Claude Code — CLAUDE.md</code></h3> ## AWS Testing</span></span> </span> For integration tests, use fakecloud as a local AWS emulator.</span></span> </span> -</span> Install: </span>`curl -fsSL https://fakecloud.dev/install.sh \| bash`</span></span> -</span> Run: </span>`fakecloud`</span> (listens on http://localhost:4566)</span></span> -</span> Configure AWS SDK endpoint to http://localhost:4566 with dummy credentials (access_key=test, secret_key=test)</span></span> -</span> Docs: https://fakecloud.dev/llms.txt</span></span></code></pre>Cursor — .cursor/rules</code></h3> For AWS integration tests, use fakecloud (local AWS emulator) at http://localhost:4566.</span></span> Install: curl -fsSL https://fakecloud.dev/install.sh \| bash</span></span> Run: fakecloud</span></span> Use dummy credentials (access_key=test, secret_key=test).</span></span> Docs: https://fakecloud.dev/llms.txt</span></span></code></pre>GitHub Copilot — .github/copilot-instructions.md</code></h3> ## AWS Testing</span></span> </span> Use fakecloud as a local AWS emulator for integration tests.</span></span> </span> -</span> Run: </span>`fakecloud`</span> (listens on http://localhost:4566)</span></span> -</span> Configure endpoint_url to http://localhost:4566 with dummy credentials</span></span> -</span> Docs: https://fakecloud.dev/llms.txt</span></span></code></pre>Why this matters for agent-assisted dev</h2> AI coding agents are good at writing plausible code and tests. They're bad at knowing when a test passing means something real.</p> Three failure modes with mocks:</p> Agent writes buggy code.</strong> Mock returns success. Test passes. Bug ships.</li> Agent writes correct code.</strong> Mock has incorrect stub. Test fails. Agent "fixes" the mock instead of recognizing the stub is wrong.</li> Cross-service flow bugs.</strong> Mock doesn't simulate S3 -> Lambda notification, so the agent never discovers the Lambda trigger wasn't wired.</li> </ol> fakecloud fails in ways that look like real AWS failing. The agent sees the same error messages, same HTTP status codes, same ARN formats. Wrong code that "works" against a mock fails against fakecloud the same way it would fail against AWS.</p> The llms.txt</code> payoff</h2> fakecloud publishes /llms.txt</a> and /llms-full.txt</a> — structured documentation designed for LLM ingestion. When an agent has fakecloud in its context (via your CLAUDE.md</code> or .cursor/rules</code>), it can fetch these to understand the full API surface without you prompting it explicitly.</p> Agents that can look up https://fakecloud.dev/llms.txt</code> get:</p> List of all 23 supported services with operation counts</li> Every /_fakecloud/</code> introspection endpoint (what the agent can use from a test)</li> Which cross-service integrations actually fire</li> Install options and CLI flags</li> </ul> This is a better baseline than letting the agent guess AWS SDK API shapes.</p> What actually works in tests</h2> Example 1 — Claude Code writes and tests a Lambda</h3> You: "Add a Lambda function that processes SQS messages and writes to DynamoDB."</p> Claude Code writes the function, writes a CDK stack or raw deploy commands, writes an integration test. When it runs the test, fakecloud:</p> Pulls the real Node/Python/Java Lambda runtime container</li> Runs the handler against the real SQS message shape</li> Persists the DynamoDB write to a real in-process store</li> Returns the exact same errors real AWS would (field validation, permission errors, quota errors)</li> </ul> Claude Code sees success = success, failure = failure. No hallucinated stub behavior.</p> Example 2 — Cursor exercises a Step Function</h3> You: "Write a Step Function that orchestrates order fulfillment (validate payment -> reserve inventory -> send confirmation email)."</p> Cursor writes the ASL, deploys via CDK, runs StartExecution</code> as a test. fakecloud:</p> Runs the full ASL interpreter (Pass, Task, Choice, Wait, Parallel, Map, Succeed, Fail, Retry/Catch)</li> Invokes the Lambda tasks with real runtime execution</li> Actually sends the SES email (visible via GET /_fakecloud/ses/emails</code>)</li> Returns the execution state the way Step Functions would</li> </ul> Cursor asserts on the final execution state + SES email count. No ambiguity.</p> Example 3 — Copilot tests SES inbound flow</h3> You: "When an email hits support@example.com, parse it, classify with Bedrock, file a ticket in DynamoDB."</p> Copilot sets up the SES receipt rule, the Lambda action, the Bedrock invocation, the DynamoDB write. fakecloud:</p> Actually executes the receipt rule when test email arrives (LocalStack Community stores them but doesn't execute)</li> Runs the Lambda for real</li> Invokes the Bedrock endpoint with a configurable mock response (POST /_fakecloud/bedrock/runtime/mock-response</code>)</li> Writes the DynamoDB row for real</li> </ul> Copilot's tests assert on the DynamoDB row appearing + the SES email being consumed. End-to-end, no gaps.</p> CI and the agent loop</h2> If the agent writes CI configuration, it should run fakecloud as a service:</p> # .github/workflows/test.yml — generated by the agent</span></span> jobs</span>:</span></span> test</span>:</span></span> runs-on</span>:</span> ubuntu-latest</span></span> steps</span>:</span></span> -</span> uses</span>:</span> actions/checkout@v4</span></span> -</span> run</span>:</span> curl -fsSL https://fakecloud.dev/install.sh \| bash</span></span> -</span> run</span>:</span> fakecloud &</span></span> -</span> run</span>:</span> \|</span></span> for i in $(seq 1 30); do</span></span> curl -sf http://localhost:4566/_fakecloud/health && break</span></span> sleep 1</span></span> done</span></span> -</span> run</span>:</span> npm ci && npm test</span></span> env</span>:</span></span> AWS_ENDPOINT_URL</span>:</span> http://localhost:4566</span></span> AWS_ACCESS_KEY_ID</span>:</span> test</span></span> AWS_SECRET_ACCESS_KEY</span>:</span> test</span></span> AWS_REGION</span>:</span> us-east-1</span></span></code></pre> ~500ms fakecloud startup means agent iteration stays tight.</p> Assertions agents can write directly</h2> fakecloud's test-assertion SDKs give agents a clean interface for "did the thing happen":</p> import</span> { FakeCloud }</span> from</span> 'fakecloud'</span>;</span></span> const</span> fc</span> = new</span> FakeCloud</span>();</span></span> </span> // Agent-written test</span></span> test</span>(</span>'order flow sends confirmation'</span>,</span> async</span> ()</span> =></span> {</span></span> await</span> placeOrder</span>({ id:</span> 'o1'</span>, email:</span> 'buyer@example.com'</span> });</span></span> </span> // Agent asserts the email was sent</span></span> const</span> {</span> emails</span> }</span> = await</span> fc.ses.</span>getEmails</span>();</span></span> expect</span>(emails).</span>toHaveLength</span>(</span>1</span>);</span></span> expect</span>(emails[</span>0</span>].destination.toAddresses).</span>toContain</span>(</span>'buyer@example.com'</span>);</span></span> </span> // Agent asserts the Lambda fired</span></span> const</span> {</span> invocations</span> }</span> = await</span> fc.lambda.</span>getInvocations</span>({ functionName:</span> 'on-order'</span> });</span></span> expect</span>(invocations[</span>0</span>].statusCode).</span>toBe</span>(</span>200</span>);</span></span> });</span></span> </span> afterEach</span>(()</span> =></span> fc.</span>reset</span>());</span></span></code></pre> SDKs: TypeScript, Python, Go, PHP, Java, Rust. Agents that prefer HTTP can hit /_fakecloud/</code> directly.</p> The reset-between-tests pattern</h2> afterEach</span>(</span>async</span> ()</span> =></span> {</span></span> await</span> fetch</span>(</span>'http://localhost:4566/_fakecloud/reset'</span>, { method:</span> 'POST'</span> });</span></span> });</span></span></code></pre> Instant reset across every service. Agent-generated test suites stay isolated without per-test resource naming ceremony.</p> Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh \| bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> LLM-ingestion docs: fakecloud.dev/llms.txt</a> + llms-full.txt</a></li> Lambda tutorial: Test Lambda locally</a></li> CI tutorial: Integration testing AWS in GitHub Actions</a></li> Moto equivalent for non-Python: Moto equivalent for Go/Java/Node</a></li> </ul> Testing Bedrock Guardrails without the AWS bill Unknown — Wed, 22 Apr 2026 00:00:00 +0000 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</code>, or call ApplyGuardrail</code> directly on arbitrary text. Useful, sharp, limited-in-scope.</p> 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</em> the guardrail evaluation.</p> fakecloud runs the full Bedrock Guardrails surface locally. CreateGuardrail</code>, versioning, UpdateGuardrail</code>, DeleteGuardrail</code>, ApplyGuardrail</code>, ListGuardrails</code> — 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.</p> The shape of the problem</h2> The standard AWS recipe, cleaned up:</p> import</span> boto3</span></span> </span> bedrock</span> =</span> boto3.client(</span>'bedrock'</span>,</span> region_name</span>=</span>'us-east-1'</span>)</span></span> </span> g</span> =</span> bedrock.create_guardrail(</span></span> name</span>=</span>'customer-facing-v1'</span>,</span></span> contentPolicyConfig</span>=</span>{</span></span> 'filtersConfig'</span>: [</span></span> {</span>'type'</span>:</span> 'HATE'</span>,</span> 'inputStrength'</span>:</span> 'HIGH'</span>,</span> 'outputStrength'</span>:</span> 'HIGH'</span>},</span></span> {</span>'type'</span>:</span> 'VIOLENCE'</span>,</span> 'inputStrength'</span>:</span> 'HIGH'</span>,</span> 'outputStrength'</span>:</span> 'HIGH'</span>},</span></span> {</span>'type'</span>:</span> 'SEXUAL'</span>,</span> 'inputStrength'</span>:</span> 'HIGH'</span>,</span> 'outputStrength'</span>:</span> 'HIGH'</span>},</span></span> {</span>'type'</span>:</span> 'INSULTS'</span>,</span> 'inputStrength'</span>:</span> 'MEDIUM'</span>,</span> 'outputStrength'</span>:</span> 'MEDIUM'</span>},</span></span> ],</span></span> },</span></span> sensitiveInformationPolicyConfig</span>=</span>{</span></span> 'piiEntitiesConfig'</span>: [</span></span> {</span>'type'</span>:</span> 'EMAIL'</span>,</span> 'action'</span>:</span> 'BLOCK'</span>},</span></span> {</span>'type'</span>:</span> 'PHONE'</span>,</span> 'action'</span>:</span> 'BLOCK'</span>},</span></span> {</span>'type'</span>:</span> 'CREDIT_DEBIT_CARD_NUMBER'</span>,</span> 'action'</span>:</span> 'BLOCK'</span>},</span></span> ],</span></span> },</span></span> topicPolicyConfig</span>=</span>{</span></span> 'topicsConfig'</span>: [</span></span> {</span></span> 'name'</span>:</span> 'medical-advice'</span>,</span></span> 'definition'</span>:</span> 'Providing specific medical diagnoses or treatment recommendations'</span>,</span></span> 'examples'</span>: [</span>'What dose should I take?'</span>,</span> 'Do I have cancer?'</span>],</span></span> 'type'</span>:</span> 'DENY'</span>,</span></span> },</span></span> ],</span></span> },</span></span> blockedInputMessaging</span>=</span>'Cannot process this input.'</span>,</span></span> blockedOutputsMessaging</span>=</span>'Cannot respond to this.'</span>,</span></span> )</span></span></code></pre> Now you want to test: does an email containing bob@example.com</code> 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?</p> 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.</p> Against fakecloud</h2> Same code, different endpoint:</p> import</span> boto3</span></span> </span> bedrock</span> =</span> boto3.client(</span>'bedrock'</span>,</span></span> endpoint_url</span>=</span>'http://localhost:4566'</span>,</span></span> aws_access_key_id</span>=</span>'test'</span>,</span></span> aws_secret_access_key</span>=</span>'test'</span>,</span></span> region_name</span>=</span>'us-east-1'</span>)</span></span> </span> # same create_guardrail call as above</span></span> g</span> =</span> bedrock.create_guardrail(</span>...</span>)</span></span> </span> rt</span> =</span> boto3.client(</span>'bedrock-runtime'</span>,</span></span> endpoint_url</span>=</span>'http://localhost:4566'</span>,</span></span> aws_access_key_id</span>=</span>'test'</span>,</span></span> aws_secret_access_key</span>=</span>'test'</span>,</span></span> region_name</span>=</span>'us-east-1'</span>)</span></span> </span> resp</span> =</span> rt.apply_guardrail(</span></span> guardrailIdentifier</span>=</span>g[</span>'guardrailId'</span>],</span></span> guardrailVersion</span>=</span>'DRAFT'</span>,</span></span> source</span>=</span>'INPUT'</span>,</span></span> content</span>=</span>[{</span>'text'</span>: {</span>'text'</span>:</span> 'contact me at bob@example.com'</span>}}],</span></span> )</span></span> </span> assert</span> resp[</span>'action'</span>]</span> ==</span> 'GUARDRAIL_INTERVENED'</span></span> assert</span> resp[</span>'outputs'</span>][</span>0</span>][</span>'text'</span>]</span> ==</span> 'Cannot process this input.'</span></span> assert</span> any</span>(a[</span>'type'</span>]</span> ==</span> 'EMAIL'</span> for</span> a</span> in</span> resp[</span>'assessments'</span>][</span>0</span>][</span>'sensitiveInformationPolicy'</span>][</span>'piiEntities'</span>])</span></span></code></pre> Real PII detection — the email is caught. Real blocked-input messaging returned. Assessments returned in the shape real AWS would return.</p> No tokens. No AWS bill. No credentials. 30ms.</p> What's actually evaluated</h2> fakecloud's guardrail evaluator ships opinionated implementations of each policy type. Concrete checks you can rely on in tests:</p> PII entities</strong>: regex + context for email, phone (various formats), credit card (Luhn), SSN, IP, URL, name, address hints.</li> Content filters</strong>: keyword + pattern matching tuned for the common categories. HIGH strength catches more, LOW catches less — same directional behavior as real AWS.</li> Topic filters</strong>: 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.</li> Word filters</strong>: exact match + stemming.</li> Regex filters</strong>: the regex you supplied, as-is.</li> </ul> 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.</p> Versioning</h2> # publish a version</span></span> v</span> =</span> bedrock.create_guardrail_version(</span></span> guardrailIdentifier</span>=</span>g[</span>'guardrailId'</span>],</span></span> description</span>=</span>'initial pinned version for prod'</span>,</span></span> )</span></span> </span> # list versions</span></span> versions</span> =</span> bedrock.list_guardrails(</span>guardrailIdentifier</span>=</span>g[</span>'guardrailId'</span>])</span></span> </span> # apply a specific version in production</span></span> rt.apply_guardrail(</span></span> guardrailIdentifier</span>=</span>g[</span>'guardrailId'</span>],</span></span> guardrailVersion</span>=</span>v[</span>'version'</span>],</span> # '1'</span></span> source</span>=</span>'INPUT'</span>,</span></span> content</span>=</span>[{</span>'text'</span>: {</span>'text'</span>:</span> '...'</span>}}],</span></span> )</span></span></code></pre> 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.</p> A realistic test suite</h2> import</span> { FakeCloud }</span> from</span> "fakecloud"</span>;</span></span> import</span> { BedrockRuntimeClient, ApplyGuardrailCommand }</span> from</span> "@aws-sdk/client-bedrock-runtime"</span>;</span></span> import</span> { BedrockClient, CreateGuardrailCommand }</span> from</span> "@aws-sdk/client-bedrock"</span>;</span></span> </span> const</span> fc</span> = new</span> FakeCloud</span>();</span></span> const</span> control</span> = new</span> BedrockClient</span>({ endpoint:</span> "http://localhost:4566"</span> });</span></span> const</span> rt</span> = new</span> BedrockRuntimeClient</span>({ endpoint:</span> "http://localhost:4566"</span> });</span></span> </span> let</span> guardrailId</span>:</span> string</span>;</span></span> </span> beforeAll</span>(</span>async</span> ()</span> =></span> {</span></span> const</span> created</span> = await</span> control.</span>send</span>(</span>new</span> CreateGuardrailCommand</span>({</span></span> name:</span> "test-guardrail"</span>,</span></span> contentPolicyConfig: {</span></span> filtersConfig: [</span></span> { type:</span> "HATE"</span>, inputStrength:</span> "HIGH"</span>, outputStrength:</span> "HIGH"</span> },</span></span> ],</span></span> },</span></span> sensitiveInformationPolicyConfig: {</span></span> piiEntitiesConfig: [</span></span> { type:</span> "EMAIL"</span>, action:</span> "BLOCK"</span> },</span></span> { type:</span> "PHONE"</span>, action:</span> "ANONYMIZE"</span> },</span></span> ],</span></span> },</span></span> blockedInputMessaging:</span> "Blocked."</span>,</span></span> blockedOutputsMessaging:</span> "Blocked."</span>,</span></span> }));</span></span> guardrailId</span> =</span> created.guardrailId</span>!</span>;</span></span> });</span></span> </span> beforeEach</span>(()</span> =></span> fc.</span>reset</span>({ preserve: [</span>"bedrock:guardrails"</span>] }));</span></span> </span> test</span>(</span>"blocks input containing email"</span>,</span> async</span> ()</span> =></span> {</span></span> const</span> resp</span> = await</span> rt.</span>send</span>(</span>new</span> ApplyGuardrailCommand</span>({</span></span> guardrailIdentifier: guardrailId,</span></span> guardrailVersion:</span> "DRAFT"</span>,</span></span> source:</span> "INPUT"</span>,</span></span> content: [{ text: { text:</span> "contact me at alice@example.com"</span> } }],</span></span> }));</span></span> </span> expect</span>(resp.action).</span>toBe</span>(</span>"GUARDRAIL_INTERVENED"</span>);</span></span> expect</span>(resp.outputs?.[</span>0</span>].text).</span>toBe</span>(</span>"Blocked."</span>);</span></span> });</span></span> </span> test</span>(</span>"anonymizes phone in output"</span>,</span> async</span> ()</span> =></span> {</span></span> const</span> resp</span> = await</span> rt.</span>send</span>(</span>new</span> ApplyGuardrailCommand</span>({</span></span> guardrailIdentifier: guardrailId,</span></span> guardrailVersion:</span> "DRAFT"</span>,</span></span> source:</span> "OUTPUT"</span>,</span></span> content: [{ text: { text:</span> "call me at 555-123-4567 tomorrow"</span> } }],</span></span> }));</span></span> </span> expect</span>(resp.action).</span>toBe</span>(</span>"GUARDRAIL_INTERVENED"</span>);</span></span> expect</span>(resp.outputs?.[</span>0</span>].text).not.</span>toContain</span>(</span>"555-123-4567"</span>);</span></span> });</span></span> </span> test</span>(</span>"passes clean input through"</span>,</span> async</span> ()</span> =></span> {</span></span> const</span> resp</span> = await</span> rt.</span>send</span>(</span>new</span> ApplyGuardrailCommand</span>({</span></span> guardrailIdentifier: guardrailId,</span></span> guardrailVersion:</span> "DRAFT"</span>,</span></span> source:</span> "INPUT"</span>,</span></span> content: [{ text: { text:</span> "what's the weather in Paris?"</span> } }],</span></span> }));</span></span> </span> expect</span>(resp.action).</span>toBe</span>(</span>"NONE"</span>);</span></span> });</span></span></code></pre> These run in milliseconds, are deterministic, and test the thing that matters — that your guardrail config enforces what you think it enforces.</p> Why this matters for agent systems</h2> 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.</p> The pattern:</p> Compose the guardrail config as code (Terraform / CDK) alongside your agent definition.</li> 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.</li> On merge to main, deploy the same config to real AWS.</li> </ol> The first two steps cost nothing. The third is the one that actually consumes budget.</p> 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.</p> Links</h2> Bedrock emulator</strong> (landing): /bedrock-emulator/</a></li> Test Bedrock locally</strong>: /test-bedrock-locally/</a></li> Why not a real LLM in tests</strong>: /blog/bedrock-tests-real-llm/</a></li> Testing LLM guardrails</strong> (broader view): /blog/llm-guardrails/</a></li> GitHub</strong>: github.com/faiscadev/fakecloud</a></li> </ul> Why your Bedrock tests shouldn't call a real LLM (not even a local one) Unknown — Wed, 22 Apr 2026 00:00:00 +0000 Every team building on Bedrock eventually asks the same question: for tests, should we call a real model? If the cost of real Bedrock is the concern, can we run Ollama locally and point our SDK at that?</p> The answer is no — but the reason is worth spelling out, because it shapes how you should think about tests for any LLM-calling code.</p> What a test is for</h2> A test asserts that your code</em> behaves correctly under a given input. Not that a model behaves correctly. Not that an API is up. Just that the code you wrote, given a response from its upstream, does the thing you expected.</p> The upstream, for Bedrock code, is InvokeModel</code> or Converse</code>. Your code sends a prompt, gets a response, and does something with it: parses JSON, branches on a label, stores it in a DB, passes it to another tool call, retries on throttling, falls back on a cheaper model. Every one of those behaviors is yours to test.</p> The model's behavior is AWS's problem.</p> What goes wrong with real models in tests</h2> Once you try to use real inference — whether it's actual Bedrock or a local Ollama — four things break, in roughly ascending order of annoyance:</p> 1. Non-determinism</h3> Real models return different text on every call. Temperature = 0 doesn't save you: there's non-determinism in attention kernel implementations across GPU/CPU backends, in tokenizer versions, in batching behavior. Anthropic's own docs say "don't rely on deterministic outputs."</p> What this means for tests:</p> // hope this passes</span></span> expect</span>(output).</span>toBe</span>(</span>"Classification: spam"</span>);</span></span></code></pre> On run 1 the model returned "Classification: spam"</code>. On run 2 it returned "The email is spam."</code>. Both correct. Your test fails.</p> The usual fix is to assert loosely:</p> expect</span>(output.</span>toLowerCase</span>()).</span>toContain</span>(</span>"spam"</span>);</span></span></code></pre> This passes even if the model returns "This is not spam"</code>. Your test is now worthless.</p> People end up using LLM-as-judge ("ask Claude if this response is approximately correct"). That's a research paper, not a CI pipeline.</p> 2. Speed</h3> Real Bedrock: 100-2000ms per call. Ollama on a developer laptop: 1-30s per call. Ollama on a CI runner without a GPU: 5-60s per call.</p> A test suite with 50 tests hitting the model at 5s each is 4 minutes. Ten times that and your developers stop running tests locally. CI times out. The TDD loop dies. The whole point of unit tests — fast feedback — is gone.</p> 3. Resource overhead</h3> Ollama-sized models are 3-70 GB on disk. docker pull</code> on a CI runner taking 3 GB of layer cache makes your pipeline brittle. A laptop without a GPU starts thrashing memory and swapping. You now need an infrastructure project just to make tests runnable, which is the opposite of "tests should be easy to run."</p> 4. You're testing the wrong thing</h3> Even if determinism, speed, and memory weren't problems, the thing you'd be testing is whether the model handles the prompt correctly. That's AWS's problem. Your code could be catastrophically broken — build requests wrong, parse responses wrong, handle errors wrong — and if the model happens to hallucinate a passable answer, your test passes.</p> Conversely, if the model has a bad day (bad weights snapshot, a silent version bump), your tests fail even though your code is fine. You spend an hour bisecting the CI failure only to discover Claude got 3% worse at following instructions last Tuesday.</p> This inverts cause and effect. Tests should tell you about your code. They shouldn't be a regression suite against a foundation model.</p> What tests actually need</h2> Deterministic output.</strong> Given the same input, same output. Every time.</li> Configurable responses.</strong> Different tests want the model to return different things. You want to control that explicitly.</li> Fault injection.</strong> Your retry logic needs to be exercised. Your fallback-model logic needs to be exercised. Your rate-limit handler needs to be exercised. You can't wait for real throttling to happen.</li> Call history.</strong> Did my code send the right prompt? Did it set the right temperature? Did it include the right system message? Right tool definitions? Those are assertions about your code</em>.</li> Sub-millisecond latency.</strong> Tests should fly.</li> No external dependencies.</strong> CI should work offline.</li> </ol> A real LLM gives you none of those. A mock library (moto, @aws-sdk-client-mock</code>) gives you 1, 2, and 4, but misses the HTTP path entirely — your code's request-assembly bugs go untested.</p> The thing that gives you all six is a Bedrock emulator</a>: a real HTTP server speaking Bedrock's wire protocol, with configurable responses and fault injection. That's what fakecloud is.</p> What this looks like in practice</h2> You write a test. You configure fakecloud to return a specific response when it sees a specific prompt. Your code runs. It sends a real HTTP request to localhost:4566</code>. The request is parsed by a real JSON parser, routed through a real request validator, and responded to with your fixture. Your code parses the response, does its thing, and you assert on the outcome.</p> import</span> { FakeCloud }</span> from</span> "fakecloud"</span>;</span></span> import</span> {</span></span> BedrockRuntimeClient,</span></span> InvokeModelCommand,</span></span> }</span> from</span> "@aws-sdk/client-bedrock-runtime"</span>;</span></span> </span> const</span> fc</span> = new</span> FakeCloud</span>();</span></span> const</span> rt</span> = new</span> BedrockRuntimeClient</span>({ endpoint:</span> "http://localhost:4566"</span> });</span></span> </span> beforeEach</span>(()</span> =></span> fc.</span>reset</span>());</span></span> </span> test</span>(</span>"spam classifier marks borderline scores for human review"</span>,</span> async</span> ()</span> =></span> {</span></span> await</span> fc.bedrock.</span>setResponseRule</span>({</span></span> whenPromptContains:</span> "classify spam"</span>,</span></span> respond: {</span></span> completion:</span> JSON</span>.</span>stringify</span>({ label:</span> "borderline"</span>, confidence:</span> 0.62</span> }),</span></span> },</span></span> });</span></span> </span> const</span> {</span> routedTo</span> }</span> = await</span> classifyEmail</span>(rt,</span> "buy now!!"</span>);</span></span> </span> expect</span>(routedTo).</span>toBe</span>(</span>"human-review"</span>);</span></span> });</span></span> </span> test</span>(</span>"classifier retries on throttling with backoff"</span>,</span> async</span> ()</span> =></span> {</span></span> await</span> fc.bedrock.</span>injectFault</span>({</span></span> operation:</span> "InvokeModel"</span>,</span></span> error:</span> "ThrottlingException"</span>,</span></span> count:</span> 2</span>,</span></span> });</span></span> await</span> fc.bedrock.</span>setResponseRule</span>({</span></span> whenPromptContains:</span> "classify spam"</span>,</span></span> respond: { completion:</span> JSON</span>.</span>stringify</span>({ label:</span> "spam"</span> }) },</span></span> });</span></span> </span> const</span> {</span> routedTo</span> }</span> = await</span> classifyEmail</span>(rt,</span> "buy now!!"</span>);</span></span> </span> expect</span>(routedTo).</span>toBe</span>(</span>"spam-folder"</span>);</span></span> expect</span>((</span>await</span> fc.bedrock.</span>getCallHistory</span>()).</span>length</span>).</span>toBe</span>(</span>3</span>);</span></span> });</span></span></code></pre> Both tests run in 30ms. Both are deterministic. Both test your code, not the model.</p> But I want some</em> tests that hit real Bedrock</h2> Good instinct. Keep those separate.</p> Put them in a suite gated behind an env var (RUN_REAL_BEDROCK_TESTS=1</code>). Run them once per release, not once per PR. They'll catch:</p> Major AWS API shape changes</li> Model version bumps that alter response format</li> IAM permission changes</li> </ul> That's a fundamentally different job from "did my PR break my code." Mixing them produces a test suite that's flaky, slow, expensive, and hides real regressions under model noise.</p> The unit/integration suite, which is 99% of your runs, should hit fakecloud. The real-bedrock suite, which is a few dozen targeted tests, runs weekly. This is the same pattern every team that tests against cloud APIs converges on — you just have to name it.</p> A word on Ollama</h2> Ollama is great. It's not a Bedrock emulator. It speaks its own HTTP protocol (roughly OpenAI-compatible), runs real models, and is the right tool for developer-time exploratory prompting.</p> LocalStack's Ultimate tier wraps Ollama in a Bedrock-shaped response — you get real inference on the local machine through the Bedrock SDK. Interesting product. Wrong tool for tests.</p> If you want to prototype a prompt, run Ollama directly. If you want to test the code that calls Bedrock with that prompt, use an emulator.</p> Closing</h2> The "tests should use a real LLM" instinct comes from a reasonable place — a fear that mocks lie, that configured responses can drift from reality, that you'll ship a bug because your tests were checking something different than production. That fear is real, and the answer is a real server (an emulator) that speaks the real wire protocol. What you don't need is real inference.</p> Your tests are about your code. The model is not your code.</p> Links</h2> Bedrock emulator</strong> (landing): /bedrock-emulator/</a></li> Tutorial with running code</strong>: How to test Bedrock code locally, for free, deterministically</a></li> LocalStack alternative for Bedrock</strong>: /localstack-bedrock-alternative/</a></li> GitHub</strong>: github.com/faiscadev/fakecloud</a></li> </ul> CDK local testing: full flow with fakecloud and cdklocal Unknown — Wed, 22 Apr 2026 00:00:00 +0000 AWS CDK writes CloudFormation under the hood and ships it through the AWS SDK. That means "CDK local testing" boils down to one question: where does the SDK send its CreateStack / UpdateStack calls?</p> Pointed at real AWS, you pay per resource, wait minutes per deploy, and have to remember to destroy. Pointed at a local emulator, you iterate fast and don't pay anything. This guide covers both flows (cdklocal</code> wrapper and plain cdk</code> with endpoint overrides) against fakecloud</a>, a free, open-source AWS emulator with real CloudFormation support (90 operations, template parsing, resource provisioning, custom resources, drift detection).</p> Install fakecloud</h2> curl</span> -fsSL</span> https://fakecloud.dev/install.sh</span> \|</span> bash</span></span> fakecloud</span></span></code></pre> Listens on http://localhost:4566</code>. ~500ms startup.</p> Option 1: plain cdk</code> with AWS_ENDPOINT_URL</code></h2> Simplest and works with any CDK version that uses AWS SDK v3 (CDK 2.67+).</p> export</span> AWS_ENDPOINT_URL</span>=</span>http://localhost:4566</span></span> export</span> AWS_ACCESS_KEY_ID</span>=</span>test</span></span> export</span> AWS_SECRET_ACCESS_KEY</span>=</span>test</span></span> export</span> AWS_REGION</span>=</span>us-east-1</span></span> export</span> CDK_DEFAULT_ACCOUNT</span>=</span>000000000000</span></span> export</span> CDK_DEFAULT_REGION</span>=</span>us-east-1</span></span> </span> cdk</span> bootstrap</span></span> cdk</span> deploy</span></span></code></pre> That's it. Same cdk</code> binary you use for prod, pointed at fakecloud for dev.</p> Option 2: cdklocal</code> wrapper</h2> If your team is already using cdklocal</code> (from the LocalStack ecosystem), it works the same way against fakecloud:</p> cdklocal</span> bootstrap</span> --endpoint-url</span> http://localhost:4566</span></span> cdklocal</span> deploy</span> --endpoint-url</span> http://localhost:4566</span></span></code></pre>A minimal stack</h2> // lib/my-stack.ts</span></span> import</span> { Stack, StackProps }</span> from</span> 'aws-cdk-lib'</span>;</span></span> import</span> { Bucket }</span> from</span> 'aws-cdk-lib/aws-s3'</span>;</span></span> import</span> { Function, Runtime, Code }</span> from</span> 'aws-cdk-lib/aws-lambda'</span>;</span></span> import</span> { Queue }</span> from</span> 'aws-cdk-lib/aws-sqs'</span>;</span></span> import</span> { SqsEventSource }</span> from</span> 'aws-cdk-lib/aws-lambda-event-sources'</span>;</span></span> import</span> { Construct }</span> from</span> 'constructs'</span>;</span></span> </span> export class</span> MyStack</span> extends</span> Stack</span> {</span></span> constructor</span>(</span>scope</span>:</span> Construct</span>,</span> id</span>:</span> string</span>,</span> props</span>?:</span> StackProps</span>) {</span></span> super</span>(scope, id, props);</span></span> </span> const</span> bucket</span> = new</span> Bucket</span>(</span>this</span>,</span> 'Uploads'</span>);</span></span> const</span> queue</span> = new</span> Queue</span>(</span>this</span>,</span> 'Jobs'</span>);</span></span> </span> const</span> processor</span> = new</span> Function</span>(</span>this</span>,</span> 'Processor'</span>, {</span></span> runtime: Runtime.</span>NODEJS_20_X</span>,</span></span> handler:</span> 'index.handler'</span>,</span></span> code: Code.</span>fromInline</span>(</span></span> `exports.handler = async (event) => ({ ok: true, received: event })`</span></span> ),</span></span> });</span></span> </span> processor.</span>addEventSource</span>(</span>new</span> SqsEventSource</span>(queue));</span></span> bucket.</span>grantRead</span>(processor);</span></span> }</span></span> }</span></span></code></pre> Deploy:</p> cdk</span> deploy</span></span></code></pre> Verify:</p> aws</span> --endpoint-url</span> http://localhost:4566 cloudformation describe-stacks</span></span> aws</span> --endpoint-url</span> http://localhost:4566 lambda list-functions</span></span> aws</span> --endpoint-url</span> http://localhost:4566 s3 ls</span></span></code></pre> Trigger the flow:</p> echo</span> "hi"</span> \|</span> aws</span> --endpoint-url</span> http://localhost:4566 s3 cp - s3://</span>$(</span>aws</span> --endpoint-url</span> http://localhost:4566 s3api list-buckets</span> --query</span> 'Buckets[0].Name'</span> --output</span> text</span>)</span>/file.txt</span></span> aws</span> --endpoint-url</span> http://localhost:4566 logs tail /aws/lambda/MyStack-Processor</span> --since</span> 1m</span></span></code></pre> Your Lambda code actually runs (fakecloud pulls the real Node 20 runtime container). The SQS -> Lambda event source mapping actually fires. CloudFormation actually provisioned the resources from the template CDK generated.</p> CI integration</h2> jobs</span>:</span></span> cdk</span>:</span></span> runs-on</span>:</span> ubuntu-latest</span></span> env</span>:</span></span> AWS_ENDPOINT_URL</span>:</span> http://localhost:4566</span></span> AWS_ACCESS_KEY_ID</span>:</span> test</span></span> AWS_SECRET_ACCESS_KEY</span>:</span> test</span></span> AWS_REGION</span>:</span> us-east-1</span></span> CDK_DEFAULT_ACCOUNT</span>:</span> '000000000000'</span></span> CDK_DEFAULT_REGION</span>:</span> us-east-1</span></span> steps</span>:</span></span> -</span> uses</span>:</span> actions/checkout@v4</span></span> -</span> uses</span>:</span> actions/setup-node@v4</span></span> with</span>: {</span> node-version</span>:</span> 20</span> }</span></span> </span> -</span> name</span>:</span> Start fakecloud</span></span> run</span>:</span> \|</span></span> curl -fsSL https://fakecloud.dev/install.sh \| bash</span></span> fakecloud &</span></span> for i in $(seq 1 30); do curl -sf http://localhost:4566/_fakecloud/health && break; sleep 1; done</span></span> curl -sf http://localhost:4566/_fakecloud/health</span></span> </span> -</span> run</span>:</span> npm ci</span></span> -</span> run</span>:</span> npx cdk bootstrap</span></span> -</span> run</span>:</span> npx cdk deploy --require-approval never</span></span> -</span> run</span>:</span> npm test</span></span></code></pre>Assertions from tests</h2> CDK integration tests usually fall into two shapes:</p> 1. Synth assertions</strong> — what CloudFormation does your CDK emit. These don't need fakecloud; use CDK's @aws-cdk/assert</code> or aws-cdk-lib/assertions</code>.</p> 2. Deployed-stack behavior</strong> — does the stack actually work when deployed. For these, deploy to fakecloud and assert on real side effects:</p> import</span> { FakeCloud }</span> from</span> 'fakecloud'</span>;</span></span> const</span> fc</span> = new</span> FakeCloud</span>();</span></span> </span> test</span>(</span>'upload triggers lambda'</span>,</span> async</span> ()</span> =></span> {</span></span> await</span> uploadToBucket</span>(</span>'uploads'</span>,</span> 'test.txt'</span>,</span> 'hello'</span>);</span></span> </span> const</span> {</span> invocations</span> }</span> = await</span> fc.lambda.</span>getInvocations</span>({ functionName:</span> 'Processor'</span> });</span></span> expect</span>(invocations).</span>toHaveLength</span>(</span>1</span>);</span></span> });</span></span> </span> afterEach</span>(()</span> =></span> fc.</span>reset</span>());</span></span></code></pre> fakecloud SDKs available in TypeScript, Python, Go, PHP, Java, Rust.</p> Destroy between tests</h2> CloudFormation state persists across tests unless you destroy or reset:</p> # Full stack teardown</span></span> cdk</span> destroy</span> --force</span></span> </span> # OR reset fakecloud's entire state (faster)</span></span> curl</span> -X</span> POST http://localhost:4566/_fakecloud/reset</span></span></code></pre> Reset is ~instant and covers every service. cdk destroy</code> only unwinds one stack at a time.</p> Why this works</h2> fakecloud targets 100% behavioral conformance per implemented service. CloudFormation (90 operations), Lambda (85 ops, real code execution in 13 runtimes), SQS (23 ops), S3 (107 ops) — all in. Cross-service wiring like S3 -> Lambda event sources and SQS -> Lambda event source mappings actually execute server-side, not as stubs.</p> The depth-first goal: 100% of AWS services, each at 100% conformance, with 100% cross-service integrations. 23 services shipped today; more land one-at-a-time as they pass the conformance bar.</p> Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh \| bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> Terraform local dev guide: Terraform local development for AWS</a></li> LocalStack migration guide: Migrating from LocalStack to fakecloud</a></li> Issues: github.com/faiscadev/fakecloud/issues</a></li> </ul> Integration testing AWS in GitHub Actions without mocks Unknown — Wed, 22 Apr 2026 00:00:00 +0000 Most "AWS integration tests" in CI are not integration tests. They are unit tests with a mocking library — moto, aws-sdk-client-mock, something similar — that intercepts the AWS SDK inside the test process and returns fabricated responses. Those tests pass when your code is wrong, because the mock only knows what you told it.</p> A real integration test talks to a real AWS-shaped service over HTTP. Testcontainers-LocalStack is the historical answer, but LocalStack's Community Edition went proprietary in March 2026 and now requires an account and an auth token just to pull the image.</p> This post shows how to run real AWS integration tests in CI against fakecloud</a> — a free, open-source AWS emulator — with copy-paste configs for GitHub Actions, GitLab CI, and CircleCI.</p> Why run fakecloud in CI</h2> ~500ms startup vs ~3s for a LocalStack container. Over hundreds of test runs, this matters.</li> ~19 MB binary, ~10 MiB idle memory. Lightweight on shared runners.</li> Single binary, no Docker required for most services (Docker still needed for Lambda, RDS, ElastiCache).</li> No account, no auth token, no license key. fakecloud</code> and you're running.</li> Covers 23 services at 100% conformance per service, including Cognito, SES v2, RDS, ElastiCache, API Gateway v2, Bedrock — the ones LocalStack moved behind the paywall.</li> </ul> GitHub Actions: install-and-run pattern</h2> The fastest CI setup is to install the binary and background it:</p> name</span>:</span> test</span></span> on</span>: [</span>push</span>,</span> pull_request</span>]</span></span> </span> jobs</span>:</span></span> integration</span>:</span></span> runs-on</span>:</span> ubuntu-latest</span></span> env</span>:</span></span> AWS_ENDPOINT_URL</span>:</span> http://localhost:4566</span></span> AWS_ACCESS_KEY_ID</span>:</span> test</span></span> AWS_SECRET_ACCESS_KEY</span>:</span> test</span></span> AWS_REGION</span>:</span> us-east-1</span></span> steps</span>:</span></span> -</span> uses</span>:</span> actions/checkout@v4</span></span> </span> -</span> name</span>:</span> Install fakecloud</span></span> run</span>:</span> curl -fsSL https://fakecloud.dev/install.sh \| bash</span></span> </span> -</span> name</span>:</span> Start fakecloud</span></span> run</span>:</span> fakecloud &</span></span> </span> -</span> name</span>:</span> Wait for fakecloud</span></span> run</span>:</span> \|</span></span> for i in $(seq 1 30); do</span></span> curl -sf http://localhost:4566/_fakecloud/health && exit 0</span></span> sleep 1</span></span> done</span></span> echo "fakecloud did not start"</span></span> exit 1</span></span> </span> -</span> uses</span>:</span> actions/setup-node@v4</span></span> with</span>:</span></span> node-version</span>:</span> 20</span></span> -</span> run</span>:</span> npm ci</span></span> -</span> run</span>:</span> npm test</span></span></code></pre> AWS_ENDPOINT_URL</code> is respected by the AWS SDK v3 automatically — you do not need to configure your application code separately for CI vs local.</p> GitHub Actions: service container pattern</h2> If you prefer a Docker service container (longer startup, cleaner isolation):</p> jobs</span>:</span></span> integration</span>:</span></span> runs-on</span>:</span> ubuntu-latest</span></span> services</span>:</span></span> fakecloud</span>:</span></span> image</span>:</span> ghcr.io/faiscadev/fakecloud:latest</span></span> ports</span>:</span></span> -</span> 4566:4566</span></span> env</span>:</span></span> AWS_ENDPOINT_URL</span>:</span> http://localhost:4566</span></span> AWS_ACCESS_KEY_ID</span>:</span> test</span></span> AWS_SECRET_ACCESS_KEY</span>:</span> test</span></span> AWS_REGION</span>:</span> us-east-1</span></span> steps</span>:</span></span> -</span> uses</span>:</span> actions/checkout@v4</span></span> -</span> run</span>:</span> npm ci</span></span> -</span> run</span>:</span> npm test</span></span></code></pre> Use this if your test harness expects the service to be ready before the job's steps run (service containers start first).</p> Lambda in GitHub Actions</h2> Lambda needs Docker-in-Docker (fakecloud launches real Lambda runtime containers). On the default ubuntu-latest</code> runner, Docker is already available — you just need to mount the socket:</p> services</span>:</span></span> fakecloud</span>:</span></span> image</span>:</span> ghcr.io/faiscadev/fakecloud:latest</span></span> ports</span>:</span></span> -</span> 4566:4566</span></span> volumes</span>:</span></span> -</span> /var/run/docker.sock:/var/run/docker.sock</span></span></code></pre> Or with the install-and-run pattern, Docker is available on the host directly — nothing extra needed. The fakecloud process launches Lambda containers on the host's Docker.</p> GitLab CI</h2> stages</span>:</span></span> -</span> test</span></span> </span> integration</span>:</span></span> stage</span>:</span> test</span></span> image</span>:</span> node:20</span></span> services</span>:</span></span> -</span> name</span>:</span> ghcr.io/faiscadev/fakecloud:latest</span></span> alias</span>:</span> fakecloud</span></span> variables</span>:</span></span> AWS_ENDPOINT_URL</span>:</span> http://fakecloud:4566</span></span> AWS_ACCESS_KEY_ID</span>:</span> test</span></span> AWS_SECRET_ACCESS_KEY</span>:</span> test</span></span> AWS_REGION</span>:</span> us-east-1</span></span> script</span>:</span></span> -</span> npm ci</span></span> -</span> npm test</span></span></code></pre> Note the endpoint uses the service alias (fakecloud</code>), not localhost</code>.</p> CircleCI</h2> version</span>:</span> 2.1</span></span> jobs</span>:</span></span> integration</span>:</span></span> docker</span>:</span></span> -</span> image</span>:</span> cimg/node:20.11</span></span> -</span> image</span>:</span> ghcr.io/faiscadev/fakecloud:latest</span></span> environment</span>:</span></span> AWS_ENDPOINT_URL</span>:</span> http://localhost:4566</span></span> AWS_ACCESS_KEY_ID</span>:</span> test</span></span> AWS_SECRET_ACCESS_KEY</span>:</span> test</span></span> AWS_REGION</span>:</span> us-east-1</span></span> steps</span>:</span></span> -</span> checkout</span></span> -</span> run</span>:</span> npm ci</span></span> -</span> run</span>:</span> npm test</span></span> </span> workflows</span>:</span></span> build</span>:</span></span> jobs</span>:</span></span> -</span> integration</span></span></code></pre> CircleCI's secondary Docker images share the primary image's localhost, so http://localhost:4566</code> works.</p> Example test: SQS consumer integration</h2> Your code under test:</p> // src/queue.ts</span></span> import</span> { SQSClient, SendMessageCommand }</span> from</span> "@aws-sdk/client-sqs"</span>;</span></span> </span> export async function</span> enqueue</span>(</span>body</span>:</span> string</span>,</span> queueUrl</span>:</span> string</span>) {</span></span> const</span> sqs</span> = new</span> SQSClient</span>({});</span></span> await</span> sqs.</span>send</span>(</span>new</span> SendMessageCommand</span>({ QueueUrl: queueUrl, MessageBody: body }));</span></span> }</span></span></code></pre> Your integration test:</p> // test/queue.test.ts</span></span> import</span> { SQSClient, CreateQueueCommand, ReceiveMessageCommand }</span> from</span> "@aws-sdk/client-sqs"</span>;</span></span> import</span> { enqueue }</span> from</span> "../src/queue"</span>;</span></span> </span> const</span> sqs</span> = new</span> SQSClient</span>({});</span></span> </span> test</span>(</span>"enqueue actually enqueues"</span>,</span> async</span> ()</span> =></span> {</span></span> const</span> {</span> QueueUrl</span> }</span> = await</span> sqs.</span>send</span>(</span>new</span> CreateQueueCommand</span>({ QueueName:</span> "test-"</span> +</span> Date.</span>now</span>() }));</span></span> await</span> enqueue</span>(</span>"hello"</span>, QueueUrl</span>!</span>);</span></span> const</span> res</span> = await</span> sqs.</span>send</span>(</span>new</span> ReceiveMessageCommand</span>({ QueueUrl, WaitTimeSeconds:</span> 1</span> }));</span></span> expect</span>(res.Messages?.[</span>0</span>]?.Body).</span>toBe</span>(</span>"hello"</span>);</span></span> });</span></span></code></pre> No mocks. The test creates a real queue, enqueues a real message, receives a real message. If your code is wrong, the test fails the way a real-AWS test would fail.</p> Asserting on fan-out and async flows</h2> For flows that cross services (SQS -> Lambda -> SNS -> DynamoDB), use the fakecloud test-assertion SDK to inspect what each hop did:</p> import</span> { FakeCloud }</span> from</span> "fakecloud"</span>;</span></span> </span> const</span> fc</span> = new</span> FakeCloud</span>();</span></span> </span> test</span>(</span>"order publishes and lambda invokes"</span>,</span> async</span> ()</span> =></span> {</span></span> await</span> placeOrder</span>({ id:</span> "o1"</span> });</span> // your code under test</span></span> </span> const</span> {</span> messages</span> }</span> = await</span> fc.sns.</span>getPublishedMessages</span>({ topicName:</span> "orders"</span> });</span></span> expect</span>(messages).</span>toHaveLength</span>(</span>1</span>);</span></span> </span> const</span> {</span> invocations</span> }</span> = await</span> fc.lambda.</span>getInvocations</span>({ functionName:</span> "on-order"</span> });</span></span> expect</span>(invocations).</span>toHaveLength</span>(</span>1</span>);</span></span> expect</span>(invocations[</span>0</span>].statusCode).</span>toBe</span>(</span>200</span>);</span></span> });</span></span> </span> afterEach</span>(()</span> =></span> fc.</span>reset</span>());</span></span></code></pre> SDK available in TypeScript, Python, Go, PHP, Java, Rust. Docs: fakecloud.dev/docs/sdks</a>.</p> Tips</h2> Reset between tests.</strong> Either await fc.reset()</code> in an afterEach</code>, or use per-test resources with unique names (test-${Date.now()}</code>). Reset is faster for large suites.</li> Run integration tests in a separate job</strong> from unit tests. Unit tests should not need fakecloud; integration tests should not run alongside mocked ones.</li> Pin the image tag</strong> in CI (ghcr.io/faiscadev/fakecloud:0.10.1</code>) if you want deterministic behavior across builds. latest</code> is fine for most teams.</li> Don't mix fakecloud with mocks.</strong> Pick one per test. If you mock inside a test that also talks to fakecloud, you will get confusing failures.</li> </ul> One call-out</h2> Performance benchmarking</strong> is different from correctness testing. fakecloud and AWS have different performance characteristics (by design — fakecloud is a local process, AWS is a distributed global system). Benchmark performance against real AWS. Benchmark correctness and behavior against fakecloud.</p> fakecloud's goal is every AWS service at 100% conformance with 100% of cross-service integrations. If a service your tests hit isn't in the supported list</a> yet, file an issue</a> — the roadmap is demand-driven and services land one at a time with the full conformance target, not a partial-surface-first approach.</p> Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh \| bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> Migration from LocalStack: Migrating from LocalStack to fakecloud</a></li> Lambda tutorial: How to test Lambda locally</a></li> Issues: github.com/faiscadev/fakecloud/issues</a></li> </ul> Free LocalStack alternatives in 2026: fakecloud, MiniStack, floci, Moto Unknown — Wed, 22 Apr 2026 00:00:00 +0000 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.</p> 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.</p> The architectural split that matters</h2> Two ways to emulate AWS for tests:</p> 1. In-process library that patches the SDK.</strong> 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.</p> 2. Real HTTP server speaking the AWS wire protocol.</strong> Separate process on port 4566. SDK points at it via endpoint_url</code>. LocalStack, MiniStack, floci, and fakecloud all work this way. Any AWS SDK in any language works. Cross-service wiring runs server-side.</p> 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.</p> Two approaches among the HTTP servers</h2> Among the HTTP emulators there's another split that matters, especially for AI-assisted dev and real integration tests:</p> Breadth-first:</strong> 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.</p> Depth-first:</strong> 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.</p> These are philosophies, not rankings. Different workloads prefer different ones.</p> fakecloud</h2> What it is:</strong> 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.</p> Approach:</strong> depth-first.</p> Explicit goal:</strong> 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.</p> What it covers today:</strong> 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.</p> Distinctive choices driven by the depth-first goal:</strong></p> Real Lambda execution across 13 runtimes in Docker containers — your function code runs, not a stub.</li> Real stateful backends: RDS runs real PostgreSQL/MySQL/MariaDB via Docker; ElastiCache runs real Redis/Valkey.</li> Cross-service wiring that actually fires: EventBridge -> Step Functions, S3 -> Lambda, SES inbound -> S3/SNS/Lambda, 15+ more integrations.</li> Multi-account, SCPs, ABAC, permission boundaries, session policies, KMS key policies, bucket policies — full Allow/Deny/NotPrincipal semantics.</li> First-party test-assertion SDKs in TypeScript, Python, Go, PHP, Java, Rust.</li> Conformance validated on every commit against 54,000+ Smithy-generated test variants, plus the upstream hashicorp/terraform-provider-aws</code> TestAcc</code> suites.</li> </ul> Source:</strong> github.com/faiscadev/fakecloud</a></p> MiniStack</h2> 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.</p> floci</h2> 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.</p> Moto</h2> Longest-lived open-source AWS mocking project. Python library, in-process, patches boto3</code>. 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.</p> Source:</strong> github.com/getmoto/moto</a></p> LocalStack Pro (for completeness)</h2> Paid tier, mature catalog, commercial support, proprietary license. Fits teams OK with proprietary and per-seat pricing who need the whole LocalStack catalog.</p> How to pick</h2> 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:</p> Do your tests exercise cross-service flows?</strong> (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</em> those flows, not just accept each call in isolation.</li> Do you need real code execution?</strong> (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.</li> Do you need real stateful backends?</strong> (Does your Postgres schema matter? Your Redis data structures?) fakecloud runs real PostgreSQL/MySQL/MariaDB/Redis/Valkey; alternatives vary.</li> What language are your tests?</strong> Moto is Python-only. Everything else is language-agnostic over HTTP.</li> How much of AWS does your test mix actually hit?</strong> 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.</li> </ol> Run your real test suite against each option you're considering. That's the only benchmark that applies to your codebase.</p> Links</h2> fakecloud: github.com/faiscadev/fakecloud</a></li> Moto: github.com/getmoto/moto</a></li> LocalStack: localstack.cloud</a></li> fakecloud install options: fakecloud.dev/docs/getting-started</a></li> fakecloud migration guide: Migrating from LocalStack to fakecloud</a></li> </ul> LocalStack Ultimate covers 4 Bedrock ops. Here's why that's the wrong bet for tests. Unknown — Wed, 22 Apr 2026 00:00:00 +0000 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</a>, the local-LLM runtime.</p> 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.</p> What LocalStack Ultimate gives you for Bedrock</h2> Per docs.localstack.cloud/aws/services/bedrock</a>, as of April 2026:</p> Tier</strong>: Ultimate plan only. This is the top paid tier.</li> Operations</strong>: InvokeModel</code>, Converse</code>, ListFoundationModels</code>, CreateModelInvocationJob</code>. Four, total.</li> Backend</strong>: Ollama, called via its HTTP API.</li> Models</strong>: whatever Ollama supports — Llama, Mistral, Phi, etc. You call them via ollama.<model-id></code> strings through the Bedrock SDK.</li> Limitations per the docs</strong>: only text models, no GPU, no persistence, and responsiveness issues on Docker Desktop due to storage/memory constraints.</li> </ul> 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.</p> What that actually means at the test bench</h2> Let's be concrete. You're writing tests for code that calls anthropic.claude-3-haiku-20240307-v1:0</code> (Haiku). You point your SDK at LocalStack Ultimate's Bedrock. What happens:</p> Haiku doesn't exist locally. You have to set DEFAULT_BEDROCK_MODEL=ollama.llama3.2</code> (or whichever Ollama model you have installed).</li> Your code's modelId: "anthropic.claude-3-haiku-20240307-v1:0"</code> string gets routed to Llama 3.2.</li> Your prompt, which was tuned for Claude, runs through Llama, which interprets it differently.</li> The response comes back. Llama's output goes through Bedrock's response envelope shape.</li> Your code parses the envelope, extracts the text, and... what?</li> </ol> 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).</p> 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.</p> The slowness problem</h2> Ollama on CPU: 1-30 seconds per call depending on model and prompt length.</p> Ollama on GPU (if you have one): 100ms-3s per call.</p> Bedrock on real AWS: 100-2000ms per call.</p> The "local" Bedrock is often slower than the cloud one. And you get non-determinism either way.</p> The LocalStack docs explicitly mention BEDROCK_PREWARM</code> 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</code> tuning routinely OOM during this.</p> The four operations</h2> InvokeModel</code> and Converse</code> are the data plane — the calls your application makes at runtime. That's the part Ollama can back.</p> ListFoundationModels</code> returns which models exist.</p> CreateModelInvocationJob</code> 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.</p> What's not covered:</p> Guardrails</li> Custom models / customization jobs</li> Model import</li> Inference profiles</li> Provisioned throughput</li> Model copy jobs</li> Prompt management</li> Foundation model agreements</li> Resource policies</li> Logging configuration</li> Evaluation jobs</li> Marketplace</li> Automated reasoning</li> </ul> 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.</p> What fakecloud does differently</h2> 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.</p> This is the deliberate opposite of LocalStack Ultimate's choice:</p> </th> LocalStack Ultimate Bedrock</th> fakecloud Bedrock</th></tr></thead> Pricing</td> Top-tier paid plan</td> Free, AGPL-3.0</td></tr> Data plane</td> Ollama (real local LLM)</td> Configurable responses per prompt rule</td></tr> Determinism</td> No</td> Yes</td></tr> Speed</td> 1-30s per call</td> Milliseconds</td></tr> Guardrails</td> Not supported</td> Full CRUD + real content evaluation</td></tr> Custom models</td> Not supported</td> Full control plane</td></tr> Async batch</td> Partial</td> Full flow</td></tr> Prompt management</td> Not supported</td> Prompts + prompt routers</td></tr> GPU required</td> Usually</td> No</td></tr> Persistence</td> "Not supported" (from docs)</td> Yes</td></tr> </tbody></table> Why Ollama is the wrong backing for a Bedrock emulator</h2> 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.</p> 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.</p> 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."</p> 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.</p> When to pay for LocalStack Ultimate anyway</h2> 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.</p> 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.</p> What to do next</h2> If you're currently testing against real Bedrock, start with how to test Bedrock code locally</a> — walks through the full pattern end to end.</p> If you're on LocalStack Ultimate and Bedrock was the draw, look at the migration comparison</a>.</p> If you want to understand why "just use Ollama" doesn't work as a test strategy, here's a longer version of the argument</a>.</p> Links</h2> Install fakecloud</strong>: curl -fsSL https://fakecloud.dev/install.sh \| bash</code></li> LocalStack Bedrock docs (cited)</strong>: docs.localstack.cloud/aws/services/bedrock</a></li> Bedrock emulator landing</strong>: /bedrock-emulator/</a></li> Migration landing</strong>: /localstack-bedrock-alternative/</a></li> GitHub</strong>: github.com/faiscadev/fakecloud</a></li> </ul> Migrating from LocalStack to fakecloud in 10 minutes Unknown — Wed, 22 Apr 2026 00:00:00 +0000 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.</p> 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).</p> This guide is step-by-step. Copy, paste, done.</p> The one-line summary</h2> Change the image or the install command. Keep http://localhost:4566</code> and your dummy credentials. Everything else stays the same.</p> Step 1: Stop LocalStack</h2> docker</span> compose down</span></span> # or: docker kill $(docker ps -q --filter ancestor=localstack/localstack)</span></span></code></pre>Step 2: Install fakecloud</h2> Pick one:</p> # Option A: single binary, no Docker</span></span> curl</span> -fsSL</span> https://fakecloud.dev/install.sh</span> \|</span> bash</span></span> fakecloud</span></span> </span> # Option B: Docker</span></span> docker</span> run</span> --rm -p</span> 4566:4566 ghcr.io/faiscadev/fakecloud</span></span> </span> # Option C: cargo</span></span> cargo</span> install fakecloud</span></span></code></pre> fakecloud listens on http://localhost:4566</code> — same as LocalStack.</p> Step 3: Keep your SDK wiring</h2> Your application code does not change. The endpoint URL and dummy credentials stay identical:</p> // TypeScript</span></span> import</span> { S3Client }</span> from</span> "@aws-sdk/client-s3"</span>;</span></span> const</span> s3</span> = new</span> S3Client</span>({</span></span> endpoint:</span> "http://localhost:4566"</span>,</span></span> region:</span> "us-east-1"</span>,</span></span> credentials: { accessKeyId:</span> "test"</span>, secretAccessKey:</span> "test"</span> },</span></span> forcePathStyle:</span> true</span>,</span></span> });</span></span></code></pre># Python (boto3)</span></span> import</span> boto3</span></span> s3</span> =</span> boto3.client(</span></span> "s3"</span>,</span></span> endpoint_url</span>=</span>"http://localhost:4566"</span>,</span></span> aws_access_key_id</span>=</span>"test"</span>,</span></span> aws_secret_access_key</span>=</span>"test"</span>,</span></span> region_name</span>=</span>"us-east-1"</span>,</span></span> )</span></span></code></pre>// Go</span></span> cfg, _</span> :=</span> config.</span>LoadDefaultConfig</span>(ctx,</span></span> config.</span>WithRegion</span>(</span>"us-east-1"</span>),</span></span> config.</span>WithCredentialsProvider</span>(credentials.</span>NewStaticCredentialsProvider</span>(</span>"test"</span>,</span> "test"</span>,</span> ""</span>)),</span></span> config.</span>WithEndpointResolverWithOptions</span>(aws.</span>EndpointResolverWithOptionsFunc</span>(</span></span> func</span>(</span>service</span>,</span> region</span> string</span>,</span> options</span> ...interface</span>{}) (</span>aws</span>.</span>Endpoint</span>,</span> error</span>) {</span></span> return</span> aws</span>.</span>Endpoint</span>{URL:</span> "http://localhost:4566"</span>},</span> nil</span></span> },</span></span> )),</span></span> )</span></span></code></pre>Step 4: Update docker-compose.yml</h2> Before:</strong></p> services</span>:</span></span> localstack</span>:</span></span> image</span>:</span> localstack/localstack:latest</span></span> ports</span>:</span></span> -</span> "4566:4566"</span></span> environment</span>:</span></span> -</span> SERVICES=s3,sqs,sns,dynamodb,lambda</span></span> -</span> DEBUG=1</span></span></code></pre> After:</strong></p> services</span>:</span></span> fakecloud</span>:</span></span> image</span>:</span> ghcr.io/faiscadev/fakecloud:latest</span></span> ports</span>:</span></span> -</span> "4566:4566"</span></span></code></pre> fakecloud starts all services by default (they are lazy and cheap — no SERVICES</code> env var needed). If you want to pass flags:</p> services</span>:</span></span> fakecloud</span>:</span></span> image</span>:</span> ghcr.io/faiscadev/fakecloud:latest</span></span> ports</span>:</span></span> -</span> "4566:4566"</span></span> command</span>: [</span>"fakecloud"</span>,</span> "--host"</span>,</span> "0.0.0.0"</span>,</span> "--port"</span>,</span> "4566"</span>]</span></span></code></pre> For Lambda execution you will need Docker-in-Docker or a mounted Docker socket (same as LocalStack Pro required):</p> services</span>:</span></span> fakecloud</span>:</span></span> image</span>:</span> ghcr.io/faiscadev/fakecloud:latest</span></span> ports</span>:</span></span> -</span> "4566:4566"</span></span> volumes</span>:</span></span> -</span> /var/run/docker.sock:/var/run/docker.sock</span></span></code></pre>Step 5: Update GitHub Actions</h2> Before:</strong></p> services</span>:</span></span> localstack</span>:</span></span> image</span>:</span> localstack/localstack</span></span> ports</span>:</span></span> -</span> 4566:4566</span></span> env</span>:</span></span> LOCALSTACK_AUTH_TOKEN</span>:</span> ${{ secrets.LOCALSTACK_TOKEN }}</span> # now required</span></span></code></pre> After (service container):</strong></p> services</span>:</span></span> fakecloud</span>:</span></span> image</span>:</span> ghcr.io/faiscadev/fakecloud:latest</span></span> ports</span>:</span></span> -</span> 4566:4566</span></span></code></pre> After (install-and-run, no Docker):</strong></p> steps</span>:</span></span> -</span> run</span>:</span> curl -fsSL https://fakecloud.dev/install.sh \| bash</span></span> -</span> run</span>:</span> fakecloud &</span></span> -</span> run</span>:</span> \|</span></span> for i in $(seq 1 30); do</span></span> curl -sf http://localhost:4566/_fakecloud/health && exit 0</span></span> sleep 1</span></span> done</span></span> exit 1</span></span></code></pre> The install-and-run pattern is ~500ms vs ~3s for LocalStack container boot. On a cold CI runner the difference is noticeable over hundreds of test runs.</p> Step 6: Terraform / OpenTofu</h2> No change needed. The provider block stays the same — only the running emulator changes.</p> provider</span> "aws"</span> {</span></span> access_key</span> =</span> "test"</span></span> secret_key</span> =</span> "test"</span></span> region</span> =</span> "us-east-1"</span></span> skip_credentials_validation</span> =</span> true</span></span> skip_metadata_api_check</span> =</span> true</span></span> skip_requesting_account_id</span> =</span> true</span></span> </span> endpoints</span> {</span></span> s3</span> =</span> "http://localhost:4566"</span></span> sqs</span> =</span> "http://localhost:4566"</span></span> sns</span> =</span> "http://localhost:4566"</span></span> dynamodb</span> =</span> "http://localhost:4566"</span></span> lambda</span> =</span> "http://localhost:4566"</span></span> # ...</span></span> }</span></span> }</span></span></code></pre> fakecloud's CI runs the upstream hashicorp/terraform-provider-aws</code> TestAcc</code> suites against itself, so Terraform flows that worked against LocalStack Community should work against fakecloud. If you hit a mismatch, it is a bug — open an issue.</p> Step 7: CDK — cdklocal</h2> CDK users with cdklocal</code> change the endpoint override:</p> cdklocal</span> bootstrap</span> --endpoint-url</span> http://localhost:4566</span></span> cdklocal</span> deploy</span> --endpoint-url</span> http://localhost:4566</span></span></code></pre> Or set AWS_ENDPOINT_URL=http://localhost:4566</code> in your shell and use plain cdk</code>.</p> Step 8: Serverless Framework</h2> If you used serverless-localstack</code>, the simplest migration is to drop the plugin and set AWS_ENDPOINT_URL</code> before running serverless</code>:</p> export</span> AWS_ENDPOINT_URL</span>=</span>http://localhost:4566</span></span> export</span> AWS_ACCESS_KEY_ID</span>=</span>test</span></span> export</span> AWS_SECRET_ACCESS_KEY</span>=</span>test</span></span> export</span> AWS_REGION</span>=</span>us-east-1</span></span> serverless</span> deploy</span></span></code></pre> AWS SDK v3 (which Serverless Framework uses internally on recent versions) respects AWS_ENDPOINT_URL</code> automatically — no plugin or custom config required. If you're on an older version that doesn't, configure the endpoint through whatever per-service override your current plugin exposes.</p> Things that may need attention</h2> SERVICES env var.</strong> LocalStack used SERVICES=s3,sqs,...</code> to scope which services booted. fakecloud starts all services by default and they are cheap. Drop the env var.</p> LOCALSTACK_AUTH_TOKEN.</strong> Drop it. fakecloud does not use auth tokens.</p> Gateway / edge URL.</strong> LocalStack had historical URLs like http://localhost:4566</code> and older per-service ports (4572, 4576, etc). fakecloud uses only 4566</code> — same as modern LocalStack. If you still have old per-service URLs pinned, consolidate them.</p> Regions.</strong> fakecloud respects the region from your SDK call. Default us-east-1</code> works everywhere.</p> Persisted state.</strong> LocalStack Pro has PERSISTENCE=1</code>. fakecloud has --persist /path/to/dir</code> for the same effect.</p> Services that moved from LocalStack Community to Pro (and what fakecloud does)</h2> Service</th> LocalStack Community (pre-Mar 2026)</th> LocalStack Community (now)</th> fakecloud</th></tr></thead> RDS</td> Paid only</a> — always was</td> Paid only</td> 163 ops, real PostgreSQL/MySQL/MariaDB via Docker</td></tr> ElastiCache</td> Paid only</td> Paid only</td> 75 ops, real Redis/Valkey via Docker</td></tr> Cognito User Pools</td> Free</td> Paid only</a></td> 122 ops, full auth flows + MFA</td></tr> SES v2</td> Free (limited)</td> Paid only</a></td> 110 ops, full send + templates + DKIM</td></tr> API Gateway v2</td> Free</td> Paid only</a></td> 28 ops, HTTP APIs + JWT/Lambda authorizers</td></tr> Bedrock</td> Not available</td> Not available</td> 111 ops (control plane + runtime)</td></tr> </tbody></table> Assertion helpers (optional)</h2> This is new capability LocalStack never had: fakecloud ships test-assertion SDKs that let you inspect side effects from tests without raw HTTP.</p> import</span> { FakeCloud }</span> from</span> "fakecloud"</span>;</span></span> const</span> fc</span> = new</span> FakeCloud</span>();</span></span> </span> // Your app code sends an email through the normal AWS SDK.</span></span> // Your test asserts the side effect directly.</span></span> const</span> {</span> emails</span> }</span> = await</span> fc.ses.</span>getEmails</span>();</span></span> expect</span>(emails).</span>toHaveLength</span>(</span>1</span>);</span></span> expect</span>(emails[</span>0</span>].destination.toAddresses).</span>toContain</span>(</span>"alice@example.com"</span>);</span></span> </span> // Reset between tests.</span></span> await</span> fc.</span>reset</span>();</span></span></code></pre> SDKs for TypeScript, Python, Go, PHP, Java, Rust. See the SDK docs</a>.</p> Verify the migration</h2> One-shot smoke test that exercises a cross-service flow:</p> # Create a bucket, upload, confirm, teardown</span></span> aws</span> --endpoint-url</span> http://localhost:4566 s3 mb s3://test-bucket</span></span> echo</span> hello</span> \|</span> aws</span> --endpoint-url</span> http://localhost:4566 s3 cp - s3://test-bucket/hello.txt</span></span> aws</span> --endpoint-url</span> http://localhost:4566 s3 ls s3://test-bucket/</span></span> aws</span> --endpoint-url</span> http://localhost:4566 s3 rb s3://test-bucket</span> --force</span></span> </span> # Lambda round-trip</span></span> echo</span> 'exports.handler = async () => ({ ok: true })'</span> ></span> index.js</span></span> zip</span> fn.zip index.js</span></span> aws</span> --endpoint-url</span> http://localhost:4566 lambda create-function</span> \</span></span> --function-name</span> smoke</span> --runtime</span> nodejs20.x</span> \</span></span> --role</span> arn:aws:iam::000000000000:role/lambda-role</span> \</span></span> --handler</span> index.handler</span> --zip-file</span> fileb://fn.zip</span></span> aws</span> --endpoint-url</span> http://localhost:4566 lambda invoke</span> \</span></span> --function-name</span> smoke out.json</span> &&</span> cat</span> out.json</span></span></code></pre> If both print what you expect, migration is done.</p> A note on coverage</h2> fakecloud's goal is every AWS service at 100% conformance, including every cross-service integration. Services land depth-first: a service is supported when it passes the Smithy-model test variants and the cross-service wire-ups that matter for it — not when the API surface looks filled in. The current 23 services (1,680 operations) are what's done today; more are on the roadmap, prioritized by real-project demand. If a service you need isn't on the list, open an issue</a> and it'll get weighed into the queue.</p> For mission-critical pre-prod validation where you need the full production-parity surface, run against real AWS — that's true of any emulator, not a fakecloud gap specifically.</p> Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh \| bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> Site: fakecloud.dev</a></li> Comparison: fakecloud vs LocalStack, MiniStack, floci, Moto</a></li> Issues: github.com/faiscadev/fakecloud/issues</a></li> </ul> A Moto equivalent for Go, Java, Kotlin, and Node.js Unknown — Wed, 22 Apr 2026 00:00:00 +0000 If you write Python, you have Moto. Decorate a test, boto3 gets patched in-process, and your assertions run against an in-memory AWS. It is great, it has been great for years, and it is not available in any other language because Python is the only ecosystem where you can cleanly monkey-patch the SDK from inside a test process.</p> What if you write Go, Java, Kotlin, Node.js, Rust, or PHP?</p> The honest cross-language answer is: a real HTTP server speaking the AWS wire protocol. Point your language's AWS SDK at http://localhost:4566</code>, and it doesn't matter whether the thing on the other end is AWS, LocalStack, MiniStack, floci, or fakecloud — the wire contract is the same.</p> This post is specifically about using fakecloud</a> — free, open-source, single binary, no account, no paid tier — as a Moto equivalent in the languages Moto cannot reach.</p> Why a real HTTP server, not an in-process patch</h2> Moto works because Python lets you reach into a running process and replace functions. In Java and Go and most other typed languages, you can't really do that — the SDK is compiled, the method dispatch is known at build time, and monkey-patching S3Client.putObject</code> is not a thing you do in production code.</p> The equivalent model in those languages is to configure the SDK's endpoint. Every AWS SDK supports pointing at a non-AWS endpoint URL. Point it at http://localhost:4566</code>, and the SDK thinks it's talking to AWS.</p> The server on the other end handles all the ceremony: signing verification (optional), request parsing, response shaping, persistence, cross-service wiring. Your test code is normal — the only thing that's "fake" is the URL.</p> Installing fakecloud</h2> curl</span> -fsSL</span> https://fakecloud.dev/install.sh</span> \|</span> bash</span></span> fakecloud</span></span></code></pre> Listens on http://localhost:4566</code>. One binary, ~19 MB, ~500ms startup.</p> Go</h2> package</span> store_test</span></span> </span> import</span> (</span></span> "</span>context</span>"</span></span> "</span>testing</span>"</span></span> </span> "</span>github.com/aws/aws-sdk-go-v2/aws</span>"</span></span> "</span>github.com/aws/aws-sdk-go-v2/config</span>"</span></span> "</span>github.com/aws/aws-sdk-go-v2/credentials</span>"</span></span> "</span>github.com/aws/aws-sdk-go-v2/service/s3</span>"</span></span> "</span>github.com/aws/smithy-go</span>"</span></span> )</span></span> </span> func</span> clientForTest</span>(</span>t</span> </span>testing</span>.</span>T</span>)</span> </span>s3</span>.</span>Client</span> {</span></span> cfg, err</span> :=</span> config.</span>LoadDefaultConfig</span>(context.</span>Background</span>(),</span></span> config.</span>WithRegion</span>(</span>"us-east-1"</span>),</span></span> config.</span>WithCredentialsProvider</span>(credentials.</span>NewStaticCredentialsProvider</span>(</span>"test"</span>,</span> "test"</span>,</span> ""</span>)),</span></span> config.</span>WithEndpointResolverWithOptions</span>(aws.</span>EndpointResolverWithOptionsFunc</span>(</span></span> func</span>(</span>service</span>,</span> region</span> string</span>,</span> opts</span> ...interface</span>{}) (</span>aws</span>.</span>Endpoint</span>,</span> error</span>) {</span></span> return</span> aws</span>.</span>Endpoint</span>{URL:</span> "http://localhost:4566"</span>},</span> nil</span></span> },</span></span> )),</span></span> )</span></span> if</span> err</span> !=</span> nil</span> {</span></span> t.</span>Fatal</span>(err)</span></span> }</span></span> return</span> s3.</span>NewFromConfig</span>(cfg,</span> func</span>(</span>o</span> </span>s3</span>.</span>Options</span>) { o.UsePathStyle</span> =</span> true</span> })</span></span> }</span></span> </span> func</span> TestPutAndGet</span>(</span>t</span> </span>testing</span>.</span>T</span>) {</span></span> ctx</span> :=</span> context.</span>Background</span>()</span></span> c</span> :=</span> clientForTest</span>(t)</span></span> </span> _, err</span> :=</span> c.</span>CreateBucket</span>(ctx,</span> &</span>s3</span>.</span>CreateBucketInput</span>{Bucket: aws.</span>String</span>(</span>"test"</span>)})</span></span> if</span> err</span> !=</span> nil</span> {</span></span> t.</span>Fatal</span>(err)</span></span> }</span></span> // ... putObject, getObject, assert</span></span> }</span></span></code></pre> That's Go integration tests against fakecloud. Same SDK, same API, same assertions — no mock. For SDK v1, use WithEndpoint("http://localhost:4566")</code> on the session config.</p> Java</h2> import</span> software.amazon.awssdk.auth.credentials.AwsBasicCredentials;</span></span> import</span> software.amazon.awssdk.auth.credentials.StaticCredentialsProvider;</span></span> import</span> software.amazon.awssdk.regions.Region;</span></span> import</span> software.amazon.awssdk.services.s3.S3Client;</span></span> </span> import</span> java.net.URI;</span></span> </span> class</span> S3Test</span> {</span></span> static</span> S3Client</span> client</span>() {</span></span> return</span> S3Client.</span>builder</span>()</span></span> .</span>endpointOverride</span>(URI.</span>create</span>(</span>"http://localhost:4566"</span>))</span></span> .</span>region</span>(Region.US_EAST_1)</span></span> .</span>credentialsProvider</span>(StaticCredentialsProvider.</span>create</span>(</span></span> AwsBasicCredentials.</span>create</span>(</span>"test"</span>,</span> "test"</span>)))</span></span> .</span>forcePathStyle</span>(</span>true</span>)</span></span> .</span>build</span>();</span></span> }</span></span> </span> @</span>Test</span></span> void</span> putAndGet</span>() {</span></span> var</span> s3</span> =</span> client</span>();</span></span> s3.</span>createBucket</span>(b </span>-></span> b.</span>bucket</span>(</span>"test"</span>));</span></span> // ... assertions</span></span> }</span></span> }</span></span></code></pre>Kotlin</h2> Same as Java, nicer syntax:</p> import</span> software.amazon.awssdk.auth.credentials.</span></span></span> import</span> software.amazon.awssdk.regions.Region</span></span> import</span> software.amazon.awssdk.services.s3.S3Client</span></span> import</span> java.net.URI</span></span> </span> fun</span> s3</span>(): </span>S3Client</span> =</span> S3Client.</span>builder</span>()</span></span> .</span>endpointOverride</span>(URI.</span>create</span>(</span>"http://localhost:4566"</span>))</span></span> .</span>region</span>(Region.US_EAST_1)</span></span> .</span>credentialsProvider</span>(StaticCredentialsProvider.</span>create</span>(</span></span> AwsBasicCredentials.</span>create</span>(</span>"test"</span>, </span>"test"</span>)))</span></span> .</span>forcePathStyle</span>(</span>true</span>)</span></span> .</span>build</span>()</span></span></code></pre>Node.js (AWS SDK v3)</h2> The SDK v3 respects AWS_ENDPOINT_URL</code> automatically, so the test setup is trivial:</p> // jest.setup.ts or vitest.setup.ts</span></span> process.env.</span>AWS_ENDPOINT_URL</span> =</span> "http://localhost:4566"</span>;</span></span> process.env.</span>AWS_ACCESS_KEY_ID</span> =</span> "test"</span>;</span></span> process.env.</span>AWS_SECRET_ACCESS_KEY</span> =</span> "test"</span>;</span></span> process.env.</span>AWS_REGION</span> =</span> "us-east-1"</span>;</span></span></code></pre> Your application code imports the AWS SDK normally and does not need any test-specific branching. Your tests import your code and call it. Your assertions check the real state on fakecloud afterwards.</p> For SDK v2 (deprecated but still widely used):</p> import</span> AWS</span> from</span> "aws-sdk"</span>;</span></span> AWS</span>.config.</span>update</span>({</span></span> endpoint:</span> "http://localhost:4566"</span>,</span></span> accessKeyId:</span> "test"</span>,</span></span> secretAccessKey:</span> "test"</span>,</span></span> region:</span> "us-east-1"</span>,</span></span> s3ForcePathStyle:</span> true</span>,</span></span> });</span></span></code></pre>PHP</h2> use</span> Aws\S3\S3Client</span>;</span></span> </span> $s3</span> = new</span> S3Client</span>([</span></span> 'version'</span> =></span> 'latest'</span>,</span></span> 'region'</span> =></span> 'us-east-1'</span>,</span></span> 'endpoint'</span> =></span> 'http://localhost:4566'</span>,</span></span> 'credentials'</span> =></span> [</span>'key'</span> =></span> 'test'</span>,</span> 'secret'</span> =></span> 'test'</span>],</span></span> 'use_path_style_endpoint'</span> =></span> true</span>,</span></span> ]);</span></span></code></pre>Rust</h2> use</span> aws_config</span>::</span>{</span>BehaviorVersion</span>,</span> Region</span>};</span></span> use</span> aws_sdk_s3</span>::</span>config</span>::</span>Credentials</span>;</span></span> </span> async fn</span> client</span>()</span> -></span> aws_sdk_s3</span>::</span>Client</span> {</span></span> let</span> config</span> =</span> aws_config</span>::</span>defaults</span>(</span>BehaviorVersion</span>::</span>latest</span>())</span></span> .</span>region</span>(</span>Region</span>::</span>new</span>(</span>"us-east-1"</span>))</span></span> .</span>endpoint_url</span>(</span>"http://localhost:4566"</span>)</span></span> .</span>credentials_provider</span>(</span>Credentials</span>::</span>from_keys</span>(</span>"test"</span>,</span> "test"</span>,</span> None</span>))</span></span> .</span>load</span>()</span></span> .await</span>;</span></span> aws_sdk_s3</span>::</span>Client</span>::</span>new</span>(</span>&</span>config)</span></span> }</span></span></code></pre>The part Moto cannot do, in any language</h2> Moto patches SDK methods inside the test process. It does not run code — specifically, it does not execute Lambda functions. If your Python test creates a Lambda and invokes it, Moto returns a simulated response; your function's actual code does not run.</p> fakecloud does run the code. It pulls real Lambda runtime containers (13 runtimes: Node, Python, Java, Go, .NET, Ruby, custom) and executes your handler against them. So a test like "my Go service publishes to SNS, which triggers a Python Lambda, which writes to DynamoDB" works end-to-end — real Lambda code running, real SNS fan-out, real DynamoDB state.</p> // Go test that publishes to SNS...</span></span> snsClient.</span>Publish</span>(ctx,</span> &</span>sns</span>.</span>PublishInput</span>{</span></span> TopicArn: aws.</span>String</span>(topicArn),</span></span> Message: aws.</span>String</span>(</span>`{"event":"order.placed"}`</span>),</span></span> })</span></span> </span> // ...and your Python Lambda (deployed to fakecloud) actually runs.</span></span> // Then you assert on its side effect (a DynamoDB row) from the Go test.</span></span></code></pre> This is the main thing a real HTTP emulator gives you that no in-process mocking library can.</p> Assertion helpers</h2> fakecloud's test-assertion SDKs give you introspection into what happened on the server, without writing raw HTTP:</p> // Go</span></span> fc</span> :=</span> fakecloud.</span>New</span>(</span>"http://localhost:4566"</span>)</span></span> invs, _</span> :=</span> fc.Lambda.</span>GetInvocations</span>(ctx,</span> &</span>fakecloud</span>.</span>GetInvocationsInput</span>{FunctionName:</span> "on-order"</span>})</span></span> if</span> len</span>(invs.Invocations)</span> !=</span> 1</span> { t.</span>Fatal</span>(</span>"expected 1 invocation"</span>) }</span></span></code></pre>// Node</span></span> const</span> fc</span> = new</span> FakeCloud</span>();</span></span> const</span> {</span> invocations</span> }</span> = await</span> fc.lambda.</span>getInvocations</span>({ functionName:</span> "on-order"</span> });</span></span> expect</span>(invocations).</span>toHaveLength</span>(</span>1</span>);</span></span></code></pre># Python (if you also want to use fakecloud from pytest alongside Go tests)</span></span> fc</span> =</span> FakeCloud()</span></span> invs</span> =</span> fc.lambda_.get_invocations(</span>function_name</span>=</span>"on-order"</span>)</span></span> assert</span> len</span>(invs.invocations)</span> ==</span> 1</span></span></code></pre> SDKs for TypeScript, Python, Go, PHP, Java, Rust: fakecloud.dev/docs/sdks</a>.</p> Moto vs fakecloud: when to use which</h2> Situation</th> Pick</th></tr></thead> Python-only project, pure unit tests that just need boto3 to respond</td> Moto</td></tr> Python + real cross-service wiring (Lambda actually runs, S3 -> Lambda actually fires)</td> fakecloud</td></tr> Any non-Python language</td> fakecloud</td></tr> Multi-language codebase sharing tests</td> fakecloud</td></tr> Integration tests in CI across multiple services</td> fakecloud</td></tr> </tbody></table> Moto and fakecloud are not really competitive — they solve slightly different problems. If you already use Moto and it works, keep it. If you need cross-service integrations, non-Python languages, or real Lambda execution, add fakecloud.</p> Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh \| bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> Moto: github.com/getmoto/moto</a></li> Language SDK docs: fakecloud.dev/docs/sdks</a></li> Issues: github.com/faiscadev/fakecloud/issues</a></li> </ul> Terraform local development for AWS: full flow with fakecloud Unknown — Wed, 22 Apr 2026 00:00:00 +0000 Writing Terraform for AWS means iterating against AWS. Every terraform apply</code> costs money, takes minutes, and leaves resources behind that you have to remember to destroy. For local dev and CI, you want the same AWS provider running against something that behaves like AWS but isn't.</p> This guide walks through local Terraform development for AWS with fakecloud</a> — a free, open-source AWS emulator that targets 100% behavioral conformance, depth-first. fakecloud's CI runs the upstream hashicorp/terraform-provider-aws</code> TestAcc</code> suites against itself on every commit, so Terraform flows that work against real AWS should work against fakecloud.</p> Install fakecloud</h2> curl</span> -fsSL</span> https://fakecloud.dev/install.sh</span> \|</span> bash</span></span> fakecloud</span></span></code></pre> Listens on http://localhost:4566</code>. ~500ms startup. No account, no token.</p> Option 1: provider endpoints</code> block (explicit)</h2> Most explicit and portable. Works with any Terraform/OpenTofu version.</p> # main.tf</span></span> provider</span> "aws"</span> {</span></span> access_key</span> =</span> "test"</span></span> secret_key</span> =</span> "test"</span></span> region</span> =</span> "us-east-1"</span></span> skip_credentials_validation</span> =</span> true</span></span> skip_metadata_api_check</span> =</span> true</span></span> skip_requesting_account_id</span> =</span> true</span></span> s3_use_path_style</span> =</span> true</span></span> </span> endpoints</span> {</span></span> s3</span> =</span> "http://localhost:4566"</span></span> sqs</span> =</span> "http://localhost:4566"</span></span> sns</span> =</span> "http://localhost:4566"</span></span> dynamodb</span> =</span> "http://localhost:4566"</span></span> lambda</span> =</span> "http://localhost:4566"</span></span> iam</span> =</span> "http://localhost:4566"</span></span> sts</span> =</span> "http://localhost:4566"</span></span> kms</span> =</span> "http://localhost:4566"</span></span> secretsmanager</span> =</span> "http://localhost:4566"</span></span> ssm</span> =</span> "http://localhost:4566"</span></span> logs</span> =</span> "http://localhost:4566"</span></span> cloudformation</span> =</span> "http://localhost:4566"</span></span> events</span> =</span> "http://localhost:4566"</span></span> scheduler</span> =</span> "http://localhost:4566"</span></span> ses</span> =</span> "http://localhost:4566"</span></span> sesv2</span> =</span> "http://localhost:4566"</span></span> cognitoidp</span> =</span> "http://localhost:4566"</span></span> kinesis</span> =</span> "http://localhost:4566"</span></span> rds</span> =</span> "http://localhost:4566"</span></span> elasticache</span> =</span> "http://localhost:4566"</span></span> sfn</span> =</span> "http://localhost:4566"</span></span> apigatewayv2</span> =</span> "http://localhost:4566"</span></span> bedrock</span> =</span> "http://localhost:4566"</span></span> bedrockruntime</span> =</span> "http://localhost:4566"</span></span> }</span></span> }</span></span></code></pre> Now terraform init && terraform apply</code> talks to fakecloud.</p> Option 2: AWS_ENDPOINT_URL</code> (minimal config)</h2> Cleaner. AWS provider v5.63+ respects AWS_ENDPOINT_URL</code> from environment. No endpoints</code> block needed.</p> export</span> AWS_ENDPOINT_URL</span>=</span>http://localhost:4566</span></span> export</span> AWS_ACCESS_KEY_ID</span>=</span>test</span></span> export</span> AWS_SECRET_ACCESS_KEY</span>=</span>test</span></span> export</span> AWS_REGION</span>=</span>us-east-1</span></span> </span> terraform</span> init</span></span> terraform</span> apply</span></span></code></pre> The provider block collapses to just auth scaffolding:</p> provider</span> "aws"</span> {</span></span> access_key</span> =</span> "test"</span></span> secret_key</span> =</span> "test"</span></span> region</span> =</span> "us-east-1"</span></span> skip_credentials_validation</span> =</span> true</span></span> skip_metadata_api_check</span> =</span> true</span></span> skip_requesting_account_id</span> =</span> true</span></span> s3_use_path_style</span> =</span> true</span></span> }</span></span></code></pre>Option 3: tflocal</code> wrapper</h2> If you're coming from LocalStack and have a tflocal</code> setup, the endpoint override works the same way — just point at fakecloud instead.</p> AWS_ENDPOINT_URL</span>=</span>http://localhost:4566</span> tflocal</span> apply</span></span></code></pre>End-to-end example: S3 + Lambda + SQS</h2> # main.tf</span></span> resource</span> "aws_s3_bucket" "uploads"</span> {</span></span> bucket</span> =</span> "uploads-</span>${</span>random_id</span>.</span>suffix</span>.</span>hex</span>}</span>"</span></span> }</span></span> </span> resource</span> "random_id" "suffix"</span> {</span></span> byte_length</span> =</span> 4</span></span> }</span></span> </span> resource</span> "aws_sqs_queue" "jobs"</span> {</span></span> name</span> =</span> "jobs"</span></span> }</span></span> </span> resource</span> "aws_iam_role" "lambda"</span> {</span></span> name</span> =</span> "lambda-role"</span></span> assume_role_policy</span> =</span> jsonencode</span>({</span></span> Version</span> =</span> "2012-10-17"</span></span> Statement</span> =</span> [{</span></span> Effect</span> =</span> "Allow"</span></span> Principal</span> =</span> { Service</span> =</span> "lambda.amazonaws.com"</span> }</span></span> Action</span> =</span> "sts:AssumeRole"</span></span> }]</span></span> })</span></span> }</span></span> </span> resource</span> "aws_lambda_function" "processor"</span> {</span></span> filename</span> =</span> data</span>.</span>archive_file</span>.</span>fn</span>.</span>output_path</span></span> function_name</span> =</span> "processor"</span></span> role</span> =</span> aws_iam_role</span>.</span>lambda</span>.</span>arn</span></span> handler</span> =</span> "index.handler"</span></span> runtime</span> =</span> "nodejs20.x"</span></span> source_code_hash</span> =</span> data</span>.</span>archive_file</span>.</span>fn</span>.</span>output_base64sha256</span></span> }</span></span> </span> data</span> "archive_file" "fn"</span> {</span></span> type</span> =</span> "zip"</span></span> output_path</span> =</span> "fn.zip"</span></span> source</span> {</span></span> filename</span> =</span> "index.js"</span></span> content</span> =</span> "exports.handler = async (event) => ({ ok: true, received: event })"</span></span> }</span></span> }</span></span> </span> resource</span> "aws_lambda_event_source_mapping" "sqs_to_lambda"</span> {</span></span> event_source_arn</span> =</span> aws_sqs_queue</span>.</span>jobs</span>.</span>arn</span></span> function_name</span> =</span> aws_lambda_function</span>.</span>processor</span>.</span>function_name</span></span> batch_size</span> =</span> 1</span></span> }</span></span> </span> resource</span> "aws_s3_bucket_notification" "uploads_to_sqs"</span> {</span></span> bucket</span> =</span> aws_s3_bucket</span>.</span>uploads</span>.</span>id</span></span> queue</span> {</span></span> queue_arn</span> =</span> aws_sqs_queue</span>.</span>jobs</span>.</span>arn</span></span> events</span> =</span> [</span>"s3:ObjectCreated:"</span>]</span></span> }</span></span> }</span></span> </span> output</span> "bucket_id"</span> {</span></span> value</span> =</span> aws_s3_bucket</span>.</span>uploads</span>.</span>id</span></span> }</span></span></code></pre> Apply it against fakecloud:</p> terraform</span> apply</span> -auto-approve</span></span></code></pre> Upload an object and watch the Lambda fire:</p> echo</span> "hello"</span> \|</span> aws</span> --endpoint-url</span> http://localhost:4566 s3 cp - s3://</span>$(</span>terraform</span> output</span> -raw</span> bucket_id</span>)</span>/file.txt</span></span> aws</span> --endpoint-url</span> http://localhost:4566 logs tail /aws/lambda/processor</span></span></code></pre> That's S3 notification -> SQS queue -> Lambda event source mapping -> real Node runtime executing your handler. End-to-end, no stubs. Same flow as real AWS.</p> CI: Terraform plan/apply in GitHub Actions</h2> jobs</span>:</span></span> terraform</span>:</span></span> runs-on</span>:</span> ubuntu-latest</span></span> env</span>:</span></span> AWS_ENDPOINT_URL</span>:</span> http://localhost:4566</span></span> AWS_ACCESS_KEY_ID</span>:</span> test</span></span> AWS_SECRET_ACCESS_KEY</span>:</span> test</span></span> AWS_REGION</span>:</span> us-east-1</span></span> steps</span>:</span></span> -</span> uses</span>:</span> actions/checkout@v4</span></span> -</span> uses</span>:</span> hashicorp/setup-terraform@v3</span></span> </span> -</span> name</span>:</span> Start fakecloud</span></span> run</span>:</span> \|</span></span> curl -fsSL https://fakecloud.dev/install.sh \| bash</span></span> fakecloud &</span></span> for i in $(seq 1 30); do curl -sf http://localhost:4566/_fakecloud/health && break; sleep 1; done</span></span> curl -sf http://localhost:4566/_fakecloud/health</span></span> </span> -</span> name</span>:</span> terraform init</span></span> run</span>:</span> terraform init</span></span> </span> -</span> name</span>:</span> terraform plan</span></span> run</span>:</span> terraform plan -out=tfplan</span></span> </span> -</span> name</span>:</span> terraform apply</span></span> run</span>:</span> terraform apply -auto-approve tfplan</span></span></code></pre> ~500ms startup means this adds negligible time to the job.</p> State backend</h2> For local dev, default local</code> backend is fine. If your real config uses s3</code> backend, you can point that at fakecloud too:</p> terraform</span> {</span></span> backend</span> "s3"</span> {</span></span> bucket</span> =</span> "tf-state"</span></span> key</span> =</span> "terraform.tfstate"</span></span> region</span> =</span> "us-east-1"</span></span> endpoint</span> =</span> "http://localhost:4566"</span></span> skip_credentials_validation</span> =</span> true</span></span> skip_metadata_api_check</span> =</span> true</span></span> skip_region_validation</span> =</span> true</span></span> force_path_style</span> =</span> true</span></span> }</span></span> }</span></span></code></pre> Pre-create the bucket:</p> aws</span> --endpoint-url</span> http://localhost:4566 s3 mb s3://tf-state</span></span></code></pre>Why this works at parity</h2> fakecloud targets 100% behavioral conformance per implemented service, validated on every commit against AWS's own Smithy models. On top of that, CI runs the upstream hashicorp/terraform-provider-aws</code> TestAcc</code> suites — the same acceptance tests HashiCorp runs against real AWS — so provider-level behavior (waiters, retries, field presence, ARN formats) matches.</p> If a Terraform flow that works against real AWS doesn't work against fakecloud, that's a bug. Open an issue</a> and it gets fixed.</p> Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh \| bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> LocalStack migration guide: Migrating from LocalStack to fakecloud</a></li> CI guide: Integration testing AWS in GitHub Actions</a></li> Issues: github.com/faiscadev/fakecloud/issues</a></li> </ul> How to test Lambda locally: the full guide for 2026 Unknown — Wed, 22 Apr 2026 00:00:00 +0000 If you want to run AWS Lambda locally, you have a few options, and most of them are worse than they need to be.</p> SAM Local</strong> invokes Lambda inside a Docker container, which is close to the real thing, but its integration with other AWS services is thin. If your function reads from SQS or publishes to SNS or is triggered by S3, SAM hands you a bag of event-shaped JSON and wishes you luck.</li> serverless-offline</strong> simulates API Gateway -> Lambda only. Everything downstream is mocked.</li> Pure unit tests with mocks</strong> tell you your code compiles. They do not tell you your code works.</li> </ul> This guide shows how to test Lambda locally end-to-end: real function code executing in a real runtime, triggered by real events from other AWS services, asserting on real side effects. No account, no auth token, no paid tier.</p> We'll use fakecloud</a> — a free, open-source AWS emulator that runs Lambda in real Docker containers across all 13 official runtimes and wires it up to 22 other AWS services that trigger and consume it.</p> What you need</h2> Docker (fakecloud boots Lambda runtime containers)</li> The AWS CLI, or any AWS SDK</li> ~30 seconds</li> </ul> Install fakecloud</h2> curl</span> -fsSL</span> https://fakecloud.dev/install.sh</span> \|</span> bash</span></span> fakecloud</span></span></code></pre> That's it. It listens on http://localhost:4566</code>.</p> If you prefer Docker:</p> docker</span> run</span> --rm</span> \</span></span> -p</span> 4566:4566</span> \</span></span> -v</span> /var/run/docker.sock:/var/run/docker.sock</span> \</span></span> ghcr.io/faiscadev/fakecloud</span></span></code></pre> The Docker socket mount is only needed because Lambda execution needs Docker-in-Docker. The single-binary install above doesn't need it.</p> A Node.js Lambda, end-to-end</h2> Create the function:</p> cat</span> ></span> index.js</span> <<</span>'EOF'</span></span> exports.handler = async (event) => {</span></span> return { statusCode: 200, body: JSON.stringify({ event }) };</span></span> };</span></span> EOF</span></span> zip</span> fn.zip index.js</span></span></code></pre> Deploy it to fakecloud:</p> aws</span> --endpoint-url</span> http://localhost:4566 iam create-role</span> \</span></span> --role-name</span> lambda-role</span> \</span></span> --assume-role-policy-document</span> '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"lambda.amazonaws.com"},"Action":"sts:AssumeRole"}]}'</span></span> </span> aws</span> --endpoint-url</span> http://localhost:4566 lambda create-function</span> \</span></span> --function-name</span> hello</span> \</span></span> --runtime</span> nodejs20.x</span> \</span></span> --role</span> arn:aws:iam::000000000000:role/lambda-role</span> \</span></span> --handler</span> index.handler</span> \</span></span> --zip-file</span> fileb://fn.zip</span></span></code></pre> Invoke it:</p> aws</span> --endpoint-url</span> http://localhost:4566 lambda invoke</span> \</span></span> --function-name</span> hello</span> \</span></span> --payload</span> '{"hello":"world"}'</span> \</span></span> --cli-binary-format</span> raw-in-base64-out</span> \</span></span> out.json</span></span> cat</span> out.json</span></span></code></pre> Output:</p> {</span>"statusCode"</span>:</span>200</span>,</span>"body"</span>:</span>"{</span>\"</span>event</span>\"</span>:{</span>\"</span>hello</span>\"</span>:</span>\"</span>world</span>\"</span>}}"</span>}</span></span></code></pre> That's your Node.js code executing in a real Node 20 container. fakecloud pulled the runtime image, mounted your zip, and invoked handler</code>.</p> Python, Java, Go, .NET, Ruby, custom</h2> Same flow, different runtime string. fakecloud supports all 13 AWS Lambda runtimes:</p> nodejs18.x</code>, nodejs20.x</code>, nodejs22.x</code></li> python3.9</code>, python3.10</code>, python3.11</code>, python3.12</code></li> java11</code>, java17</code>, java21</code></li> dotnet6</code>, dotnet8</code></li> ruby3.2</code></li> go1.x</code>, provided.al2</code>, provided.al2023</code> (custom runtimes)</li> </ul> Example — Python:</p> cat</span> ></span> lambda_function.py</span> <<</span>'EOF'</span></span> def handler(event, context):</span></span> return {"ok": True, "event": event}</span></span> EOF</span></span> zip</span> fn.zip lambda_function.py</span></span> </span> aws</span> --endpoint-url</span> http://localhost:4566 lambda create-function</span> \</span></span> --function-name</span> py-hello</span> \</span></span> --runtime</span> python3.12</span> \</span></span> --role</span> arn:aws:iam::000000000000:role/lambda-role</span> \</span></span> --handler</span> lambda_function.handler</span> \</span></span> --zip-file</span> fileb://fn.zip</span></span> </span> aws</span> --endpoint-url</span> http://localhost:4566 lambda invoke</span> \</span></span> --function-name</span> py-hello</span> \</span></span> --payload</span> '{"x":1}'</span> \</span></span> --cli-binary-format</span> raw-in-base64-out</span> \</span></span> out.json</span></span></code></pre>Triggers that actually fire</h2> This is where "test Lambda locally" usually breaks down. Your Lambda is not invoked by a human calling Invoke — it's triggered by S3, SQS, SNS, EventBridge, DynamoDB Streams, API Gateway, or an event source mapping. fakecloud has those wired up for real.</p> SQS event source mapping</h3> aws</span> --endpoint-url</span> http://localhost:4566 sqs create-queue</span> --queue-name</span> jobs</span></span> </span> QUEUE_URL</span>=</span>http://localhost:4566/000000000000/jobs</span></span> QUEUE_ARN</span>=</span>arn:aws:sqs:us-east-1:000000000000:jobs</span></span> </span> aws</span> --endpoint-url</span> http://localhost:4566 lambda create-event-source-mapping</span> \</span></span> --function-name</span> hello</span> \</span></span> --event-source-arn</span> $QUEUE_ARN</span> \</span></span> --batch-size 1</span></span> </span> aws</span> --endpoint-url</span> http://localhost:4566 sqs send-message</span> \</span></span> --queue-url</span> $QUEUE_URL</span> \</span></span> --message-body</span> '{"job":"resize","id":42}'</span></span></code></pre> fakecloud polls the queue, batches the message, invokes your Lambda with the SQS event shape, and deletes the message on success. Same contract as real AWS.</p> S3 -> Lambda</h3> aws</span> --endpoint-url</span> http://localhost:4566 s3 mb s3://uploads</span></span> aws</span> --endpoint-url</span> http://localhost:4566 lambda add-permission</span> \</span></span> --function-name</span> hello</span> \</span></span> --statement-id</span> s3invoke</span> \</span></span> --action</span> lambda:InvokeFunction</span> \</span></span> --principal</span> s3.amazonaws.com</span> \</span></span> --source-arn</span> arn:aws:s3:::uploads</span></span> </span> aws</span> --endpoint-url</span> http://localhost:4566 s3api put-bucket-notification-configuration</span> \</span></span> --bucket</span> uploads</span> \</span></span> --notification-configuration</span> '{</span></span> "LambdaFunctionConfigurations": [{</span></span> "LambdaFunctionArn": "arn:aws:lambda:us-east-1:000000000000:function:hello",</span></span> "Events": ["s3:ObjectCreated:*"]</span></span> }]</span></span> }'</span></span> </span> echo</span> "hi"</span> \|</span> aws</span> --endpoint-url</span> http://localhost:4566 s3 cp - s3://uploads/file.txt</span></span></code></pre> Your Lambda fires with the S3 event. End-to-end, no stubs.</p> EventBridge -> Lambda</h3> aws</span> --endpoint-url</span> http://localhost:4566 events put-rule</span> \</span></span> --name</span> on-order</span> \</span></span> --event-pattern</span> '{"source":["store"],"detail-type":["OrderPlaced"]}'</span></span> </span> aws</span> --endpoint-url</span> http://localhost:4566 events put-targets</span> \</span></span> --rule</span> on-order</span> \</span></span> --targets</span> 'Id=1,Arn=arn:aws:lambda:us-east-1:000000000000:function:hello'</span></span> </span> aws</span> --endpoint-url</span> http://localhost:4566 events put-events</span> \</span></span> --entries</span> 'Source=store,DetailType=OrderPlaced,Detail={"orderId":"o1"}'</span></span></code></pre> Your Lambda fires with the EventBridge event envelope.</p> Asserting on side effects</h2> fakecloud ships test-assertion SDKs that let your tests check what happened without raw HTTP:</p> import</span> { FakeCloud }</span> from</span> "fakecloud"</span>;</span></span> const</span> fc</span> = new</span> FakeCloud</span>();</span></span> </span> // Your app publishes to SNS inside a Lambda. Your test asserts it happened.</span></span> const</span> {</span> invocations</span> }</span> = await</span> fc.lambda.</span>getInvocations</span>({ functionName:</span> "hello"</span> });</span></span> expect</span>(invocations).</span>toHaveLength</span>(</span>1</span>);</span></span> expect</span>(invocations[</span>0</span>].statusCode).</span>toBe</span>(</span>200</span>);</span></span> </span> const</span> {</span> messages</span> }</span> = await</span> fc.sns.</span>getPublishedMessages</span>({ topicName:</span> "orders"</span> });</span></span> expect</span>(messages[</span>0</span>].message).</span>toContain</span>(</span>"o1"</span>);</span></span> </span> await</span> fc.</span>reset</span>();</span></span></code></pre> SDKs in TypeScript, Python, Go, PHP, Java, Rust. Reference: fakecloud.dev/docs/sdks</a>.</p> Watching the logs</h2> Lambda stdout goes to CloudWatch Logs, which fakecloud also emulates:</p> aws</span> --endpoint-url</span> http://localhost:4566 logs tail /aws/lambda/hello</span> --follow</span></span></code></pre>Running in CI</h2> # .github/workflows/test.yml</span></span> jobs</span>:</span></span> test</span>:</span></span> runs-on</span>:</span> ubuntu-latest</span></span> steps</span>:</span></span> -</span> uses</span>:</span> actions/checkout@v4</span></span> -</span> run</span>:</span> curl -fsSL https://fakecloud.dev/install.sh \| bash</span></span> -</span> run</span>:</span> fakecloud &</span></span> -</span> run</span>:</span> \|</span></span> for i in $(seq 1 30); do</span></span> curl -sf http://localhost:4566/_fakecloud/health && break</span></span> sleep 1</span></span> done</span></span> -</span> run</span>:</span> npm ci && npm test</span></span> env</span>:</span></span> AWS_ENDPOINT_URL</span>:</span> http://localhost:4566</span></span> AWS_ACCESS_KEY_ID</span>:</span> test</span></span> AWS_SECRET_ACCESS_KEY</span>:</span> test</span></span> AWS_REGION</span>:</span> us-east-1</span></span></code></pre> ~500ms startup. A whole Lambda-integration test suite completes in seconds on a cold runner.</p> Correctness vs performance</h2> fakecloud runs your function code in the real AWS Lambda runtime containers, so behavior matches real Lambda. What it doesn't replicate is AWS's distributed infrastructure timing: cold-start latency, concurrency-accounting scheduling, and VPC networking come from AWS's own implementation, not from a local process, so numbers on those will not match real AWS. Use real AWS for those measurements, use fakecloud for everything correctness-related.</p> Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh \| bash</code></li> Repo: github.com/faiscadev/fakecloud</a></li> Lambda docs: fakecloud.dev/docs/services/lambda</a></li> SDKs: fakecloud.dev/docs/sdks</a></li> Issues: github.com/faiscadev/fakecloud/issues</a></li> </ul> People are not reviewing AI-generated code Unknown — Wed, 15 Apr 2026 00:00:00 +0000 I'd bet good money that most developers using AI tools are already shipping code without properly reviewing every line.</p> Not because they have some sophisticated testing setup. Because it historically just works. A developer reviews the first ten things the AI writes. They're fine. Reviews the next ten. Also fine. At some point the developer starts skimming. Then stops reading altogether. The review step keeps proving itself to be a waste of time, so it gets skipped. Human nature.</p> What validation looks like with guardrails</h2> I built fakecloud almost entirely with Claude. 22 AWS services, 1,650+ operations, 100% conformance to AWS behavior.</p> Here's my workflow:</p> I define what to build. Architecture, scope, acceptance criteria.</li> AI writes code and tests.</li> Tests run in CI.</li> I look at the results.</li> </ol> Step 4 is where it gets weird.</p> The tests pass. I look at the implementation. It's correct. I merge.</p> This happens over and over. I'm doing the validation—I'm looking, I'm checking—but I'm not finding anything wrong. The guardrails already caught it.</p> The validation step has become ceremonial.</strong> You still do it because if something's wrong it can be a disaster. But in practice, if you've built the right guardrails, validation finds nothing. The automated systems already caught everything.</p> What's actually happening</h2> I still validate before merging because catastrophic failure is real. If something gets through that shouldn't, it's a disaster. So I check. But I'm checking as a safety ritual, not because I expect to find problems.</p> The tests already found the problems. CI already caught them. By the time I look, there's nothing left to catch.</p> And here's my gut feeling: I think most people are already skipping this step.</strong></p> I have no proof. But think about it. A developer asks Claude or Copilot to write a function. It looks right. They review it anyway because that's what responsible developers do. It's fine. Next time, same thing. Fine again. After the twentieth time, they start skimming. After the fiftieth, they stop reading altogether.</p> Why would anyone keep reviewing something that's never wrong?</p> But I'd bet there are plenty of developers shipping AI-generated code without proper test infrastructure. Without CI catching issues. Without proper monitoring. Just the AI, some tests the AI wrote, and hope.</p> I think the industry already moved past "review every line." We're just not talking about it.</strong></p> You can't fix this with process</h2> You can write "review all AI-generated code" in your team's guidelines. You can make it a policy. You can add it to the PR checklist.</p> But you can't verify that someone actually did it. You can't tell the difference between "I carefully reviewed this" and "I skimmed it for 30 seconds and it looked fine." There's no way to enforce it. And when the AI keeps being right, the incentive to actually do it drops to zero.</p> So instead of pretending you can control this, build systems that don't depend on it.</strong></p> That's what I did with fakecloud. The code is real. The conformance is real. Most of it was written by Claude, with me defining architecture and making sure the guardrails worked.</p> And when I validate the code, I find nothing wrong. Not because I'm a great reviewer. Because the guardrails already found everything.</p> What good guardrails look like</h2> Most AI-generated code ships with AI-generated tests. The problem is that the tests can be wrong in the same way the code is wrong. Everything is internally consistent, but none of it matches reality. A human reviewer might catch this. Or might not. You can't count on it.</p> What you can count on:</p> Real integration tests with actual SDKs</strong> — not mocks that mirror the buggy code</li> Conformance tests generated from schemas</strong> — tests the AI didn't write and can't game</li> Side-by-side testing against real systems</strong> — when behavior diverges, it's a bug</li> </ul> The difference isn't whether someone reviewed the code. It's whether you have automated systems that verify correctness independent of the code being tested.</p> When those systems pass, the code is right regardless of whether anyone read it. When they fail, the AI fixes it until they pass.</p> Here's a concrete example. If you're writing code that calls Bedrock — the Claude API on AWS — the hard parts are retry logic, fallback models, and circuit breakers. Testing that code against real Bedrock is expensive, non-deterministic, and rate-limited. Mocking it is meaningless because the mocks don't catch the bugs. So you either ship untested error handling or you write unrunnable tests. That's exactly the kind of gap where AI-generated code goes wrong silently. I wrote a whole guide on how to test Bedrock code locally against fakecloud</a> — deterministic responses, injectable faults, call history assertions. That's what "guardrails the AI can't game" looks like in practice.</p> The test suite is the guardrail</h2> fakecloud works because the tests verify everything. Not me. Not code review. The tests.</p> 54,000+ conformance tests generated from AWS Smithy models</li> E2E tests using real AWS SDKs</li> CI that runs everything on every commit</li> Side-by-side testing against actual AWS</li> </ul> These guardrails are external to the code being tested. The AI can't game them. They catch bugs before I see the code.</p> So when I validate, I find nothing. Because there's nothing left to find.</p> If I'm right that people are already shipping AI code without reviewing it, this is the gap. Most codebases don't have external verification. Just AI-generated code, AI-generated tests, and no way to know if they match reality.</p> The fix isn't telling people to review harder. It's building systems that catch the bugs whether or not anyone reads the code.</p> What to do about it</h2> If you're using AI to write code, here's what matters:</p> You can't control whether people actually review code.</strong> You can tell them to. You can put it in the process. But you can't get inside their head and verify they actually read every line. So build systems that don't depend on them doing it.</p> Build external guardrails.</strong> Tests that the AI didn't write. Conformance checks generated from schemas. Integration tests with real dependencies, not mocks.</p> Automate everything.</strong> Don't rely on humans to catch bugs. Humans are slow, inconsistent, lazy, and bad at checking edge cases. Automated systems are fast, consistent, and check everything.</p> Accept what's probably already happening.</strong> I think most developers are already shipping AI-generated code without thorough manual review. If that's true, the question isn't whether to do it. It's whether you're doing it safely.</p> For AWS code specifically, I wrote about how to test AI-generated AWS code properly</a>. The short version: don't mock AWS APIs. Use something that behaves like real AWS.</p> That's why fakecloud exists:</p> Repo:</strong> github.com/faiscadev/fakecloud</a></li> Site:</strong> fakecloud.dev</a></li> Install:</strong> curl -fsSL https://fakecloud.dev/install.sh \| bash</code></li> </ul> If you're writing AWS code with Claude, Cursor, or any AI tool, you need automated guardrails that verify correctness without you in the loop. Because if I'm right, people are already skipping manual review—and the only thing standing between them and production bugs is the quality of their automated tests.</p> Build the guardrails. Then let the AI work.</p> And if you find a case where fakecloud behaves differently from AWS, open an issue</a>. Because that means the guardrails missed something. And we need to know.</p> How to test AWS code written by AI tools Unknown — Tue, 14 Apr 2026 00:00:00 +0000 AI tools are absurdly good at writing AWS code. They understand IAM policies, VPC configurations, and service integrations in a way that feels magical. Until they don't.</p> The failure mode everyone hits is the same: the AI writes code, writes tests, the tests pass, you ship it—and then AWS returns something completely different in production.</p> Here's how to test AI-generated AWS code properly.</p> The debugging revelation</h2> I started using ChatGPT to write code the day it launched. The first "oh shit, this actually works" moment wasn't code generation—it was debugging.</p> AWS is full of rough edges. Permissions that fail silently. Networking that breaks in non-obvious ways. Security groups that look right but aren't. When you hit one of these, you're stuck reading docs, checking IAM, comparing VPC settings.</p> AI is absurdly fast at this. Paste an error, describe what you tried, get three hypotheses back. "Check if the security group allows egress on 443." "Verify the IAM role has sts:AssumeRole</code> for that principal." One of them is usually right.</p> That's when I realized AI understands AWS in a way that's genuinely useful. Not because it memorized documentation, but because it's seen every way these things fail.</p> The hallucination problem</h2> Then you hit the limits.</p> When debugging gets hard—when nothing makes sense—AI starts making things up. It suggests an AWS feature that doesn't exist. A configuration parameter that was never real. An API method that would solve your problem perfectly, except it's not in the SDK.</p> This is the failure mode everyone talks about: hallucination. It's real. When the AI doesn't know, it confidently invents an answer.</p> The standard response is "review every line the AI writes."</p> That advice doesn't scale. And it doesn't work.</p> Why manual review fails</h2> The problem with "review every line" is that it assumes the human is the source of truth. But humans miss things. Humans get tired. Humans skim code that looks reasonable.</p> More importantly: if the AI writes both the code and the tests, manual review doesn't catch the right bugs.</strong></p> Here's the trap:</p> AI generates code</li> Developer reviews it (looks fine)</li> AI writes tests</li> Tests pass</li> Ship it</li> </ol> Except the tests can be wrong in the same way the code is wrong. The tests assert that the bug exists successfully. Everything is internally consistent, but none of it matches reality.</p> This is especially bad with mocks. The AI will happily mock AWS APIs in a way that matches the buggy code. The tests pass. Your code goes to production. AWS returns something completely different. Good luck debugging that at 2am.</p> Manual review didn't save you because the bug wasn't obvious. The tests didn't save you because they tested the wrong behavior.</p> What actually works: guardrails that can't be gamed</h2> Here's what worked for fakecloud:</p> 1. Real integration tests, not mocks.</strong></p> Every feature ships with E2E tests using the actual AWS SDK. Not unit tests with mocked clients. Actual aws-sdk-rust</code> calls against fakecloud.</p> When the test uses the real SDK and the code is wrong, the test fails. The AI iterates until it's right.</p> This matters most for cross-service wiring—the stuff that's easy to get subtly wrong and almost impossible to catch with mocks. fakecloud actually executes the integrations: an EventBridge rule really triggers the Step Functions state machine, an SES inbound rule really invokes the Lambda, an S3 event really lands in SQS. If the AI wires it up wrong, the test fails for the same reason it would fail in production.</p> 2. Conformance testing the AI didn't write.</strong></p> We auto-generate 54,000+ test variants from AWS Smithy models. Every operation, every parameter, every boundary condition, every error case.</p> The AI can't write code that games these tests because it didn't write the tests. They're generated from AWS's service definitions.</p> 3. Side-by-side testing against real AWS.</strong></p> The same test suite runs against both fakecloud and actual AWS. When behavior diverges, it's a bug.</p> This is the key insight: the guardrails are automated and external to the code being tested.</strong></p> The AI can't game them. They catch everything. And when they're set up right, they catch it before</em> you see the code.</p> What this means for AWS testing</h2> If you're building on AWS and using AI to write code, here's what matters:</p> Don't mock the AWS SDK in your tests.</strong> Use fakecloud, LocalStack, Testcontainers, or real AWS with cleanup afterward. But don't mock. Mocks let AI-generated tests pass while asserting the wrong behavior.</p> Build guardrails the AI can't game.</strong> If the AI writes both the code and the tests, make sure tests are anchored to something external—real SDK behavior, schemas generated from service definitions, or validation against actual AWS.</p> Verify architecture, not syntax.</strong> Your job isn't to review every line. It's to make sure the AI is building the right thing in the right way. If the structure is sound and the tests pass, the code is probably fine.</p> Let the AI iterate.</strong> When tests fail, let the AI fix them. It's faster than you at reading error messages and adjusting code. Your job is to make sure it's converging toward the right solution.</p> The test suite is the guardrail</h2> I built fakecloud almost entirely with Claude. 22 AWS services, 1,150+ operations, 100% conformance to AWS behavior.</p> fakecloud works because the tests verify everything:</p> 54,000+ conformance tests generated from AWS Smithy models</li> E2E tests using real AWS SDKs</li> CI that runs everything on every commit</li> Side-by-side testing against actual AWS</li> </ul> These guardrails are external to the code being tested. The AI can't game them. They catch bugs before I see the code.</p> If your tests are good—real integration tests, not mocks, not stubs—then AI-generated code is as reliable as human-written code. Maybe more reliable, because the AI doesn't get bored and skip edge cases.</p> If your tests are bad—mocks everywhere, written by the same AI that wrote the code—then you're in trouble whether a human or an AI wrote the code.</p> The tooling matters. The tests matter. The mocks-versus-real-APIs decision matters.</p> fakecloud exists because AI tools need a way to verify AWS code against real behavior, not just against tests they wrote themselves.</p> Repo:</strong> github.com/faiscadev/fakecloud</a></li> Site:</strong> fakecloud.dev</a></li> Install:</strong> curl -fsSL https://fakecloud.dev/install.sh \| bash</code></li> </ul> If you're using Claude Code, Cursor, or any other AI coding tool to write AWS applications, you need something that behaves like AWS to test against. Not mocks. Not stubs. Real API behavior.</p> That's what fakecloud is for.</p> And if you find a case where fakecloud behaves differently from AWS—that's a bug. Open an issue</a>. Because the tests should have caught it.</p> How to test Bedrock code locally, for free, deterministically Unknown — Mon, 13 Apr 2026 00:00:00 +0000 If you're writing code that calls Bedrock, you already know the problem. Every test run burns tokens. Every CI build hits rate limits. Every assertion on model output breaks because the model returned something slightly different this time. The only way to make it stop is to mock, and then your tests don't test anything real.</p> This is the most frustrating corner of AWS to test against, and until a few days ago there was no good answer. LocalStack doesn't emulate Bedrock at any tier — not free, not paid. If you wanted a local Bedrock, you built it yourself.</p> So I built one.</p> The problem with real Bedrock in tests</h2> Four things break, in order of how much they hurt:</p> Cost.</strong> Every test run that calls a model is a line item on your AWS bill. A CI job that runs on every PR and exercises a Bedrock code path a dozen times becomes real money fast. Teams end up building elaborate VCR-cassette systems to record-once-and-replay, which works until the request shape changes and everything silently goes stale.</p> </li> Rate limits.</strong> Bedrock has per-account quotas. A noisy test suite gets throttled. Flaky CI. Engineers angry. You start skipping tests in CI to stay under the limit, which defeats the point of having them.</p> </li> Non-determinism.</strong> Real models return different text every run, even at temperature 0. Snapshot tests are impossible. Assertions on specific strings are impossible. Everyone ends up asserting that some</em> output was produced, which is the weakest possible test — it would pass even if the model returned the string "cabbage."</p> </li> No offline dev.</strong> On a plane, on a train, on bad hotel wifi, in a datacenter without egress. You can't develop Bedrock code at all without a live connection to AWS.</p> </li> </ol> The standard response is "mock the SDK." The problem with mocking the SDK is that it's AI-generated code calling an AI API, and if you let the AI generate both the code and the mocks, your tests will happily assert the wrong behavior and pass. Your code never talks to anything that looks like Bedrock — it talks to a fake object that matches the SDK's interface. If your code assembles the request wrong, the mock doesn't care.</p> What fakecloud gives you</h2> fakecloud implements 111 Bedrock operations — the full runtime (InvokeModel, Converse, both streaming variants), plus guardrails, customization jobs, model imports, the whole control plane. You point any AWS SDK at http://localhost:4566</code> with dummy credentials and it works.</p> But the interesting part isn't the operation count. The interesting part is that you can make the "model" return exactly what you want, triggered by exactly what you want, and then assert on exactly what your code sent.</p> Configurable responses per prompt.</strong> Set a rule like "when the prompt contains 'summarize', return this JSON; when it contains 'classify', return that one." Your code's branching logic gets tested against deterministic, fixture-like responses you control.</p> Fault injection.</strong> Tell fakecloud to throw ThrottlingException</code> on the next call. Your retry logic gets exercised. Your fallback-model logic gets exercised. Your circuit breaker gets exercised. All the hard parts of production Bedrock code, which currently go untested on every project I've seen.</p> Call history.</strong> After your code runs, query fakecloud for every InvokeModel and Converse call it made — prompts, outputs, timestamps, error field. Assert on what your code sent</em>, not just on what it received.</p> Together, that's a complete test loop.</p> A real example</h2> Here's a spam classifier that calls Claude via Bedrock. I want to test both the happy path (spam vs. ham branching) and the retry path (throttling recovery). Using the TypeScript SDK</a>:</p> import</span> { FakeCloud }</span> from</span> "fakecloud"</span>;</span></span> import</span> {</span></span> BedrockRuntimeClient,</span></span> InvokeModelCommand,</span></span> }</span> from</span> "@aws-sdk/client-bedrock-runtime"</span>;</span></span> </span> const</span> fc</span> = new</span> FakeCloud</span>();</span></span> const</span> modelId</span> =</span> "anthropic.claude-3-haiku-20240307-v1:0"</span>;</span></span> </span> beforeEach</span>(()</span> =></span> fc.</span>reset</span>());</span></span> </span> test</span>(</span>"classifier branches on spam vs ham"</span>,</span> async</span> ()</span> =></span> {</span></span> await</span> fc.bedrock.</span>setResponseRules</span>(modelId, [</span></span> { promptContains:</span> "buy now"</span>, response:</span> '{"label":"spam"}'</span> },</span></span> { promptContains:</span> null</span>, response:</span> '{"label":"ham"}'</span> },</span> // catch-all</span></span> ]);</span></span> </span> await</span> classify</span>(</span>"hello friend"</span>);</span></span> await</span> classify</span>(</span>"buy now cheap pills"</span>);</span></span> </span> const</span> {</span> invocations</span> }</span> = await</span> fc.bedrock.</span>getInvocations</span>();</span></span> expect</span>(invocations).</span>toHaveLength</span>(</span>2</span>);</span></span> expect</span>(invocations[</span>0</span>].output).</span>toContain</span>(</span>"ham"</span>);</span></span> expect</span>(invocations[</span>1</span>].output).</span>toContain</span>(</span>"spam"</span>);</span></span> });</span></span> </span> test</span>(</span>"retries on ThrottlingException"</span>,</span> async</span> ()</span> =></span> {</span></span> await</span> fc.bedrock.</span>queueFault</span>({</span></span> errorType:</span> "ThrottlingException"</span>,</span></span> message:</span> "Rate exceeded"</span>,</span></span> httpStatus:</span> 429</span>,</span></span> count:</span> 1</span>,</span> // only the first call faults; the retry succeeds</span></span> });</span></span> </span> await</span> classify</span>(</span>"hello"</span>);</span></span> </span> const</span> {</span> invocations</span> }</span> = await</span> fc.bedrock.</span>getInvocations</span>();</span></span> expect</span>(invocations).</span>toHaveLength</span>(</span>2</span>);</span></span> expect</span>(invocations[</span>0</span>].error).</span>toContain</span>(</span>"ThrottlingException"</span>);</span></span> expect</span>(invocations[</span>1</span>].error).</span>toBeNull</span>();</span></span> });</span></span></code></pre> No tokens burned. No rate limits hit. No test flake. Runs on a plane.</p> The classify</code> function is unchanged from production — it's a real BedrockRuntimeClient</code> calling a real InvokeModelCommand</code>. The only difference is endpoint: "http://localhost:4566"</code> in the SDK config. Your production code never knows it's talking to fakecloud, which is exactly what you want: the tests exercise the same code path that runs in production.</p> Isn't a fake model just a mock?</h2> No, and the distinction is important.</p> A mock replaces the SDK client. A mock knows what method you called and what arguments you passed, and returns whatever you told it to. If your code uses a deprecated field, or sends invalid JSON, or builds the request wrong, the mock doesn't care — it was told to return a value and it returns it.</p> fakecloud is a real HTTP server implementing the real Bedrock wire protocol. Your AWS SDK sends real SigV4-signed requests over real HTTP. If your code builds the request wrong, fakecloud rejects it the same way real AWS would. The only thing that's "fake" is the inference — instead of calling a real model, fakecloud returns the response you configured.</p> And that's not a limitation, it's the point. You don't want a real model in tests. You want a predictable one.</strong> Real models are for production, where you want the best possible output. Tests are for verifying that your code behaves correctly given</em> an output. Those are different problems and they need different tools.</p> When you don't configure anything, fakecloud falls back to a canned response per provider format — Anthropic, Titan, Llama, Cohere, Mistral all get provider-shaped defaults. So even a no-configuration test still gets something realistic back. You only need to configure responses when your code actually branches on content.</p> What this unlocks</h2> Things that were hard or impossible before, that are now just tests:</p> Free CI.</strong> Run your full Bedrock-exercising test suite on every PR, every commit, every dependabot bump. No token budget to worry about.</li> Deterministic snapshots.</strong> The model returns exactly what you configured. Your snapshot tests work again.</li> Offline development.</strong> Write Bedrock code on a plane. Debug retry logic on a train. Iterate without thinking about AWS at all.</li> Error-path testing.</strong> Exercise every catch</code> block in your code. Retry, fallback, circuit-break, degrade-gracefully — all testable, all deterministic.</li> Cross-service integration tests.</strong> Your Lambda calls Bedrock, writes to DynamoDB, and publishes to EventBridge? fakecloud runs all of those for real, in the same process, wired together. One test can exercise the whole flow.</li> </ul> Try it</h2> curl</span> -fsSL</span> https://fakecloud.dev/install.sh</span> \|</span> bash</span></span> fakecloud</span></span></code></pre> Then point any AWS SDK at http://localhost:4566</code> with dummy credentials. The TypeScript, Python, Go, and Rust first-party SDKs all have ergonomic helpers for the Bedrock introspection and configuration endpoints shown above.</p> Repo:</strong> github.com/faiscadev/fakecloud</a></li> Site:</strong> fakecloud.dev</a></li> </ul> If you try it and find a case where fakecloud's Bedrock implementation diverges from real AWS, that's a bug — open an issue</a>. The tests should have caught it.</p> Free, Open-Source LocalStack Alternative for AWS Testing Unknown — Sat, 11 Apr 2026 00:00:00 +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.</p> fakecloud is that alternative.</p> What is fakecloud?</h2> 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.</p> Currently supports 20 AWS services with 1,000+ API operations:</p> S3</strong> — objects, multipart uploads, versioning, lifecycle, notifications</li> Lambda</strong> — real code execution via Docker, 13 runtimes, event source mappings</li> SQS</strong> — FIFO queues, dead-letter queues, long polling</li> SNS</strong> — fan-out to SQS/Lambda/HTTP, filter policies</li> DynamoDB</strong> — tables, transactions, PartiQL, streams, global tables</li> EventBridge</strong> — pattern matching, scheduled rules, API destinations</li> RDS</strong> — PostgreSQL/MySQL/MariaDB via Docker, snapshots, read replicas</li> ElastiCache</strong> — Redis/Valkey via Docker, replication groups, failover</li> SES</strong> — v2 API (97 operations), inbound email pipeline, event destinations</li> Cognito User Pools</strong> — authentication, MFA, user management</li> Kinesis</strong> — data streams, shard iterators, stream retention</li> Step Functions</strong> — ASL interpreter, Lambda/SQS/SNS/DynamoDB integrations</li> CloudWatch Logs</strong> — groups, streams, filtering, subscriptions</li> API Gateway v2</strong> — HTTP APIs with Lambda integration</li> IAM, STS, SSM, Secrets Manager, KMS, CloudFormation</strong></li> </ul> Full service list with operation counts</a></p> LocalStack vs fakecloud</h2> 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.</p> Feature</th> fakecloud</th> LocalStack Community</th></tr></thead> License</td> AGPL-3.0 (free, open-source)</td> Proprietary</td></tr> Auth required</td> No</td> Yes (account + token)</td></tr> Commercial use</td> Free</td> Paid plans only</td></tr> Docker required</td> No (standalone binary)</td> Yes</td></tr> Startup time</td> ~500ms</td> ~3s</td></tr> Idle memory</td> ~10 MiB</td> ~150 MiB</td></tr> Install size</td> ~19 MB binary</td> ~1 GB Docker image</td></tr> AWS services</td> 20</td> 30+</td></tr> Test assertion SDKs</td> TypeScript, Python, Go, Rust</td> Python, Java</td></tr> Cognito User Pools</td> 80 operations</td> Paid only</a></td></tr> SES v2</td> 97 operations</td> Paid only</a></td></tr> SES inbound email</td> Real receipt rule action execution</td> Stored but never executed</a></td></tr> RDS</td> 22 operations, PostgreSQL/MySQL/MariaDB via Docker</td> Paid only</a></td></tr> ElastiCache</td> 44 operations, Redis/Valkey via Docker</td> Paid only</a></td></tr> </tbody></table> LocalStack has more services overall, but many are behind a paywall. fakecloud focuses on implementing fewer services completely, with 100% conformance to AWS behavior.</p> Why we built fakecloud</h2> LocalStack went proprietary.</strong> In March 2026, localstack:latest</code> started requiring authentication. CI pipelines broke. The message was clear: LocalStack Community Edition was no longer community.</p> Correctness matters for testing.</strong> 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.</p> Real infrastructure, not stubs.</strong> 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.</p> Testing tools should be free.</strong> 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.</p> How we verify correctness</h2> fakecloud doesn't claim to be "AWS-compatible" without backing it up:</p> 34,000+ conformance test variants</strong> validated against official AWS Smithy models, covering every operation parameter, boundary condition, and error case</li> 280+ end-to-end tests</strong> using the official AWS SDKs (aws-sdk-rust, boto3, aws-sdk-js)</li> Automated testing against real AWS</strong> — our test suite runs against both fakecloud and actual AWS to verify behavioral parity</li> </ul> When tests fail, we fix the behavior. We don't stub responses or return fake success codes.</p> Getting started</h2> Install and run fakecloud:</p> curl</span> -fsSL</span> https://fakecloud.dev/install.sh</span> \|</span> bash</span></span> fakecloud</span></span></code></pre> Or via Docker:</p> docker</span> run</span> --rm -p</span> 4566:4566 ghcr.io/faiscadev/fakecloud</span></span></code></pre> Point your AWS SDK at http://localhost:4566</code> with dummy credentials:</p> aws</span> --endpoint-url</span> http://localhost:4566 sqs create-queue</span> --queue-name</span> test-queue</span></span></code></pre>Test assertions with fakecloud SDKs</h2> fakecloud exposes introspection endpoints that AWS doesn't provide, so you can assert on side effects in your tests:</p> import</span> { FakeCloud }</span> from</span> "fakecloud"</span>;</span></span> </span> const</span> fc</span> = new</span> FakeCloud</span>(</span>"http://localhost:4566"</span>);</span></span> </span> // After your app sends an email via SES</span></span> const</span> {</span> emails</span> }</span> = await</span> fc.ses.</span>getEmails</span>();</span></span> expect</span>(emails).</span>toHaveLength</span>(</span>1</span>);</span></span> expect</span>(emails[</span>0</span>].destination.toAddresses).</span>toContain</span>(</span>"user@example.com"</span>);</span></span> </span> // After your Lambda processes an event</span></span> const</span> {</span> invocations</span> }</span> = await</span> fc.lambda.</span>getInvocations</span>();</span></span> expect</span>(invocations[</span>0</span>].statusCode).</span>toBe</span>(</span>200</span>);</span></span></code></pre> SDKs available for TypeScript, Python, Go, and Rust.</p> What's not implemented (yet)</h2> 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).</p> We're prioritizing services based on real-world demand. Open an issue</a> if there's a service you need.</p> Roadmap</h2> Coming next:</p> Bedrock</strong> — AI/ML testing (high demand across the ecosystem)</li> Lambda Containers</strong> — practical container support with ECR</li> CloudFront</strong> — CDN configuration testing</li> CloudWatch Metrics</strong> — complete monitoring story alongside Logs</li> Athena</strong> — SQL analytics on S3</li> More RDS engines (Oracle, SQL Server)</li> </ul> Full roadmap</a></p> Other alternatives to LocalStack</h2> Moto</strong> — 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.</p> LocalStack Pro (paid)</strong> — If you need the full service catalog and don't mind paying, LocalStack Pro is mature and feature-complete.</p> Real AWS</strong> — For the highest fidelity, test against real AWS. fakecloud is for fast local iteration; real AWS is for pre-production validation.</p> Try fakecloud</h2> Repo:</strong> github.com/faiscadev/fakecloud</a></li> Site:</strong> fakecloud.dev</a></li> Install:</strong> curl -fsSL https://fakecloud.dev/install.sh \| bash</code></li> </ul> If you find a case where fakecloud behaves differently from AWS, open an issue</a> — that's a bug, and we'll fix it.</p> 700 commits in 6 days: how to trust LLM-generated code Unknown — Fri, 10 Apr 2026 00:00:00 +0000 fakecloud</a> went from first commit to 17 AWS services, 1,000+ tests, and 700 commits in 6 days. Almost all of the code was generated by LLMs.</p> The obvious question: how do you trust any of it?</p> The problem with vibe coding</h2> Andrej Karpathy coined "vibe coding" in early 2025 — the idea of just accepting whatever the LLM gives you without really looking at it. A year later, the results are in: a CodeRabbit study of 470 GitHub repositories</a> found that AI co-authored code contains 1.7x more bugs than human-written code, with logic errors up 75%, security vulnerabilities up 2.74x, and concurrency bugs doubled.</p> That's what happens without guardrails. The answer isn't to stop using LLMs — it's to build the systems that make LLM output trustworthy.</p> The short answer</h2> Tests. Not unit tests that mock everything — real end-to-end tests that spin up the server, make actual AWS SDK calls, and verify the responses. If the LLM generates something that doesn't match real AWS behavior, a test fails. If no test catches it, there should be a test for it.</p> That's the foundation. The rest is process.</p> The workflow</h2> Here's what building a new feature in fakecloud actually looks like:</p> 1. Evaluate.</strong> Start by looking at the current conformance state. What's missing? What's the next highest-value thing to implement? The LLM helps here — it can cross-reference the AWS API models with what's already implemented and suggest what to tackle next.</p> 2. Plan.</strong> This is the most important step, and it's mostly human. The LLM proposes an approach, but there's a lot of back and forth. Multiple alternatives get explored. Architecture decisions get debated. The right technical direction matters more than speed — a bad foundation generates bad code forever. This is what some are calling spec-driven development</a> — writing a real plan with goals, constraints, and implementation notes before any code gets generated.</p> 3. Break it down.</strong> The work gets split into well-scoped pieces. Each piece includes E2E tests — not just relying on the conformance framework, but dedicated tests that exercise real workflows through the AWS SDK.</p> 4. Implement.</strong> The LLM writes the code and the tests, runs them locally, iterates until green. By the time a PR opens, the tests are already passing.</p> 5. CI.</strong> The PR hits CI — clippy, fmt, the full test suite. If something fails, the LLM iterates until it's green. No human intervention needed for mechanical fixes.</p> 6. Code review.</strong> Two layers: an AI code reviewer catches surface issues, then a human review. Addy Osmani put it well</a>: "AI didn't eliminate code review — it made verification mandatory."</p> What the human actually reviews</h2> Not every line the same way.</p> Tests get reviewed exhaustively.</strong> Every line. Every assertion. Does this test actually verify the right behavior? Does it match what real AWS would do? Could it pass while the implementation is wrong? The tests are the source of truth for the project, so they have to be right.</p> Implementation gets scanned.</strong> A top-to-bottom read looking for architectural issues, weird patterns, unnecessary complexity. Sometimes things get sent back for refactoring — DRY violations, odd abstractions, things that don't fit the codebase style.</p> The mental model: if the tests are comprehensive and correct, the implementation is constrained to be correct. It might not be elegant, but it works. Elegance can be fixed later. Correctness can't be faked.</p> This aligns with what Gergely Orosz describes</a> as the shift in engineering — from writing every line to "assessing quality and architectural soundness." The engineer becomes a supervisor and decision-maker, not a typist.</p> Why this only works with real tests</h2> Most codebases test with mocks. The test asserts that function A calls function B with the right arguments. That tells you nothing about whether the actual behavior is correct — it tells you the plumbing is connected.</p> Mocked tests are particularly dangerous with LLM-generated code because the LLM writes both the implementation and the test. If the implementation has a bug, the LLM will happily write a test that asserts the buggy behavior. The mock doesn't care — it returns whatever it's told to. This is likely a contributor to the 75% increase in logic errors found in AI-generated PRs — the tests pass, but they're testing the wrong thing.</p> fakecloud's E2E tests use the official aws-sdk-rust</code> crate. They spin up a real fakecloud server, make real API calls, and verify real responses. If CreateQueue</code> followed by SendMessage</code> followed by ReceiveMessage</code> doesn't return the right message with the right attributes, the test fails. No mocks. No fakes. Real behavior.</p> That's 650+ E2E tests, plus 600+ conformance tests that validate operations against official AWS Smithy API models using checksums. Together, they form a safety net tight enough to let LLMs write code at speed without sacrificing correctness.</p> What tests don't catch</h2> To be clear: this isn't bulletproof. E2E tests are great at catching behavioral bugs, but they're weaker at catching security vulnerabilities, performance issues, and concurrency bugs — exactly the categories where AI-generated code is worst</a> (2.74x more security issues, 8x more excessive I/O operations).</p> That's where the other layers matter. Static analysis (clippy, in Rust's case) catches entire categories of bugs at compile time. AI code reviewers catch patterns that tests miss. The human review catches architectural problems. No single layer is sufficient — it's the combination that makes the system trustworthy.</p> Making a project LLM-friendly</h2> This approach isn't specific to fakecloud. Any project can get here:</p> Start with tests.</strong> If the project doesn't have comprehensive E2E or integration tests, that's the first thing to build — and LLMs are great at helping with that. Build the test infrastructure first, then use it as the guardrail for everything that follows. This is the single highest-leverage investment for LLM-assisted development.</p> Invest in CI.</strong> Linting, formatting, full test suites, automated code review. Every automated check is one less thing that can slip through. If speed goes up, the number of tests should go up proportionally.</p> Steer the architecture.</strong> The LLM is a force multiplier, not an architect. Discuss the plan. Explore alternatives. Push back when the approach doesn't feel right. The human decides the direction; the LLM executes it.</p> Review what matters.</strong> Tests get the most scrutiny. Implementation gets scanned for patterns. Don't try to read every line like you wrote it — that doesn't scale. Trust the tests, verify the tests are right.</p> The real insight</h2> The question isn't "can you trust LLM-generated code?" The answer is obviously no — not by default. The 1.7x bug rate proves it.</p> The real question is: can you build a system where LLM-generated code is continuously verified? Where every PR runs against hundreds of tests before a human ever sees it? Where the test suite is comprehensive enough that "tests pass" is a meaningful signal? Where static analysis, AI review, and human review each catch what the others miss?</p> If yes, then the LLM is just a very fast, very tireless junior developer that needs good guardrails. And 700 commits in 6 days stops being scary — it's just what happens when the guardrails are in place.</p> Why I'm building a free, open-source AWS emulator Unknown — Mon, 06 Apr 2026 00:00:00 +0000 A few days ago, our CI started failing. The culprit: localstack:latest</code> now requires an account and an auth token. Broken builds.</p> 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?</p> I don't trust mocks</h2> I should back up. I care about tests a lot. Enough to become a maintainer of Chai.js</a>. Enough that when I build something, the test infrastructure comes first.</p> But I have a specific opinion about what kind</em> 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.</p> 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.</p> 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.</p> That's what LocalStack used to give us. And that's what I wanted to keep — but free and open source.</p> So I built it</h2> I started fakecloud on April 4th, 2026. Three days later: 13 AWS services, 300+ commits, 1,000+ tests.</p> 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.</p> 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.</p> Correctness is the whole point</h2> 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.</p> What does that mean in practice? If you call CreateQueue</code>, then SendMessage</code>, then ReceiveMessage</code> 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.</p> We currently verify this with 280+ E2E tests that use the official aws-sdk-rust</code> crate and 34,856 auto-generated conformance test variants validated against official AWS Smithy models — covering all 731 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.</p> What's here today</h2> 13 services, 731 API operations, all open source, all free:</p> S3</strong> (74 actions) — objects, multipart uploads, versioning, lifecycle, notifications, encryption</li> SQS</strong> (20 actions) — FIFO queues, dead-letter queues, long polling, batch operations</li> SNS</strong> (34 actions) — fan-out to SQS, HTTP delivery, filter policies, platform applications</li> EventBridge</strong> (57 actions) — pattern matching, scheduled rules, connections, API destinations, endpoints</li> IAM</strong> (128 actions) — users, roles, policies, groups, instance profiles, OIDC/SAML providers</li> STS</strong> (8 actions) — assume role, session tokens, federation</li> SSM</strong> (146 actions) — parameters, documents, commands, maintenance windows, associations, automation, sessions</li> DynamoDB</strong> (57 actions) — tables, items, transactions, PartiQL, backups, global tables, streaming</li> Lambda</strong> (10 actions) — function CRUD, invoke, event source mappings</li> Secrets Manager</strong> (23 actions) — versioning, soft delete, rotation, replication, resource policies</li> CloudWatch Logs</strong> (113 actions) — groups, streams, filtering, deliveries, transformers, anomaly detection</li> KMS</strong> (53 actions) — encryption, aliases, key management, grants, custom key stores</li> CloudFormation</strong> (8 actions) — template parsing, resource provisioning</li> </ul> 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.</p> Try it</h2> curl</span> -fsSL</span> https://fakecloud.dev/install.sh</span> \|</span> bash</span></span> fakecloud</span></span></code></pre> Then point any AWS SDK at http://localhost:4566</code> with dummy credentials. That's it.</p> The code is at github.com/faiscadev/fakecloud</a>. It's AGPL-3.0 — free and open source, including for commercial use.</p> 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</a>. That's a bug, and we'll fix it.</p>

Testing SNS to S3 Triggers Locally in 500ms

Local ECR with real `docker push`: what LocalStack and Moto miss, and what fakecloud ships

Running AWS integration tests with Claude Code, Cursor, and Copilot

What actually works in tests</h2>

Testing Bedrock Guardrails without the AWS bill

Why your Bedrock tests shouldn't call a real LLM (not even a local one)

CDK local testing: full flow with fakecloud and cdklocal

Integration testing AWS in GitHub Actions without mocks

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

floci</h2>
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.</p>

Links</h2>

fakecloud: github.com/faiscadev/fakecloud</a></li>
Moto: github.com/getmoto/moto</a></li>
LocalStack: localstack.cloud</a></li>
fakecloud install options: fakecloud.dev/docs/getting-started</a></li>
fakecloud migration guide: Migrating from LocalStack to fakecloud</a></li> </ul>

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

Migrating from LocalStack to fakecloud in 10 minutes

The one-line summary</h2>
Change the image or the install command. Keep `http://localhost:4566</code> and your dummy credentials. Everything else stays the same.</p>`

A Moto equivalent for Go, Java, Kotlin, and Node.js

Terraform local development for AWS: full flow with fakecloud

How to test Lambda locally: the full guide for 2026

Triggers that actually fire</h2>
This is where "test Lambda locally" usually breaks down. Your Lambda is not invoked by a human calling Invoke — it's triggered by S3, SQS, SNS, EventBridge, DynamoDB Streams, API Gateway, or an event source mapping. fakecloud has those wired up for real.</p>

Links</h2>

Install: `curl -fsSL https://fakecloud.dev/install.sh | bash</code></li>`
`Repo:` `github.com/faiscadev/fakecloud</a></li>`
`Lambda docs: fakecloud.dev/docs/services/lambda</a></li>`
`SDKs: fakecloud.dev/docs/sdks</a></li>`
`Issues: github.com/faiscadev/fakecloud/issues</a></li> </ul>`

People are not reviewing AI-generated code

How to test AWS code written by AI tools

How to test Bedrock code locally, for free, deterministically

Free, Open-Source LocalStack Alternative for AWS Testing

700 commits in 6 days: how to trust LLM-generated code

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

fakecloud

2,591 Operations: How fakecloud Reached 100% AWS API Conformance

fakecloud

2,591 Operations: How fakecloud Reached 100% AWS API Conformance

Testing SNS to S3 Triggers Locally in 500ms

Scenario: The SNS-to-S3 Fanout</h2> In this walkthrough, we will implement a common architectural pattern: an SNS topic that receives a message and triggers an S3 upload via a Lambda function. This tests the full chain of command: SNS -> Lambda -> S3</code>.</p>

Local ECR with real `docker push`: what LocalStack and Moto miss, and what fakecloud ships

Assert on what was pushed</h2> fakecloud exposes an introspection API at /_fakecloud/ecr/...</code> so your test code can check pushed images without parsing Docker output:</p>

Running AWS integration tests with Claude Code, Cursor, and Copilot

Why this matters for agent-assisted dev</h2> AI coding agents are good at writing plausible code and tests. They're bad at knowing when a test passing means something real.</p> Three failure modes with mocks:</p>

What actually works in tests</h2>

Example 1 — Claude Code writes and tests a Lambda</h3> You: "Add a Lambda function that processes SQS messages and writes to DynamoDB."</p> Claude Code writes the function, writes a CDK stack or raw deploy commands, writes an integration test. When it runs the test, fakecloud:</p>

Example 2 — Cursor exercises a Step Function</h3> You: "Write a Step Function that orchestrates order fulfillment (validate payment -> reserve inventory -> send confirmation email)."</p> Cursor writes the ASL, deploys via CDK, runs StartExecution</code> as a test. fakecloud:</p>

Testing Bedrock Guardrails without the AWS bill

What's actually evaluated</h2> fakecloud's guardrail evaluator ships opinionated implementations of each policy type. Concrete checks you can rely on in tests:</p>

Why your Bedrock tests shouldn't call a real LLM (not even a local one)

CDK local testing: full flow with fakecloud and cdklocal

Integration testing AWS in GitHub Actions without mocks

GitHub Actions: install-and-run pattern</h2> The fastest CI setup is to install the binary and background it:</p>

Lambda in GitHub Actions</h2> Lambda needs Docker-in-Docker (fakecloud launches real Lambda runtime containers). On the default ubuntu-latest</code> runner, Docker is already available — you just need to mount the socket:</p>

Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh | bash</code></li>

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

floci</h2> 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.</p>

How to pick</h2> 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:</p>

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

Migrating from LocalStack to fakecloud in 10 minutes

The one-line summary</h2> Change the image or the install command. Keep http://localhost:4566</code> and your dummy credentials. Everything else stays the same.</p>

A Moto equivalent for Go, Java, Kotlin, and Node.js

Terraform local development for AWS: full flow with fakecloud

Links</h2> Install: curl -fsSL https://fakecloud.dev/install.sh | bash</code></li>

How to test Lambda locally: the full guide for 2026

What you need</h2> Docker (fakecloud boots Lambda runtime containers)</li> The AWS CLI, or any AWS SDK</li>

Scenario: The SNS-to-S3 Fanout</h2>
In this walkthrough, we will implement a common architectural pattern: an SNS topic that receives a message and triggers an S3 upload via a Lambda function. This tests the full chain of command: `SNS -> Lambda -> S3</code>.</p>`

floci</h2>
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.</p>

The one-line summary</h2>
Change the image or the install command. Keep `http://localhost:4566</code> and your dummy credentials. Everything else stays the same.</p>`