Moto

Visit Website

Introduction

Moto is a library that lets your tests easily mock out AWS services. The README’s example shows the idea: wrap a test that uses boto3 with the @mock_aws decorator, and every AWS call inside it, such as creating an S3 bucket and putting an object, goes to Moto’s in-memory implementation instead of AWS.

The mock keeps state, so a bucket created at the start of the test exists when you read from it later, objects have content, and IAM, DynamoDB tables, SQS queues and many other resources behave much like the real service. Each test starts with a clean, virtual AWS account. The project maintains an implementation coverage list that shows which services and API calls are supported.

Moto works as a decorator or context manager inside Python tests, and as a pytest fixture pattern. It also has a server mode: moto_server runs a local HTTP endpoint that mimics AWS, so code in any language with an AWS SDK can point at it by changing the endpoint URL. That makes it usable in polyglot integration tests and in Docker Compose setups.

Installation uses extras to keep dependencies small, for example pip install 'moto[s3,dynamodb]' or moto[all]. Moto has about 8,700 GitHub stars and released 5.2.5 in October 2026, with commits continuing in November 2026.

Moto’s limits are important to understand. It reimplements AWS behaviour, so coverage is not complete and edge cases, permissions, eventual consistency and newer features may differ from AWS. Tests that pass with Moto can still fail in the real cloud, so teams usually combine it with a smaller set of tests against real AWS accounts.

In the quality loop, Moto belongs at the unit and integration stages, where it keeps AWS-dependent code fast, free and deterministic to test, without credentials or network access.

The source code is at getmoto/moto on GitHub under the Apache-2.0 licence, with about 8,700 stars; the most recent commit was on 10 November 2026.

Teams often get the most from Moto by layering it with other approaches. Pure unit tests can stub individual boto3 calls, Moto covers the bulk of integration-style tests where several AWS resources interact, and a small number of tests run against a real sandbox account to catch behaviour Moto cannot reproduce, such as IAM policy enforcement or service limits. Keeping fixtures that create common resources, such as buckets, tables and queues, makes tests short and consistent.

Features

1. @mock_aws decorator: Mock all supported AWS services in a test.
2. Stateful mocks: Resources persist within a test like a real account.
3. Broad service coverage: S3, DynamoDB, SQS, SNS, IAM, Lambda, EC2 and many more (see coverage list).
4. Server mode: Standalone HTTP endpoint for any language’s SDK.
5. Context managers: Scope mocks to blocks of code.
6. pytest friendly: Easy fixtures for clean AWS state.
7. Extras: Install only the services you need.
8. No credentials: Tests run offline without AWS access.
9. Docker image: Run the server in containers.
10. Coverage docs: Published list of implemented endpoints.

Pros

1. Fast, free AWS tests: No cloud costs or network calls.
2. Deterministic: Clean state per test.
3. Free to use: Open source under the Apache-2.0 licence, so the core tool costs nothing to use.
4. Actively maintained: The repository had commits as recent as 10 November 2026.
5. Community: About 8,700 GitHub stars.

Cons

1. Not real AWS: Behaviour can differ, especially for edge cases and new features.
2. Partial coverage: Not every service or API is implemented.
3. Python-first: Other languages must use server mode.

Usage and Links (Example)

import boto3
from moto import mock_aws

@mock_aws
def test_upload_report():
    s3 = boto3.client("s3", region_name="us-east-1")
    s3.create_bucket(Bucket="reports")
    s3.put_object(Bucket="reports", Key="daily.csv", Body=b"ok")
    body = s3.get_object(Bucket="reports", Key="daily.csv")["Body"].read()
    assert body == b"ok"

Server mode for other languages:

pip install 'moto[server]'
moto_server -p 5000
# point the SDK endpoint at http://localhost:5000

Practical tips:

1. Create clients inside the mocked scope, or set fake credentials as environment variables, to avoid accidental real AWS calls.
2. Check the implementation coverage list before relying on a service.
3. Keep a small suite of tests against a real sandbox AWS account for behaviour Moto cannot reproduce.

Resources:

• Moto website
• GitHub repository

Pricing

Moto is free and open source under the Apache-2.0 licence.

Recommended for?

1. Python teams testing code that uses AWS.
2. Polyglot integration tests via server mode.
3. Not a fit as the only check for complex AWS behaviour.

Conclusion

Moto is the standard way to test AWS-dependent Python code quickly and offline. Its stateful mocks and server mode cover a large share of everyday AWS usage.

Use it for fast feedback, and keep a few real-cloud tests for the behaviour it cannot reproduce.

On CheckOps, Moto is filed under the Integration testing and Unit testing stages. Related tools listed here include Testcontainers, WireMock, responses, VCR.py, pytest and Hoverfly. Before choosing, compare them on licence, supported languages and platforms, hosting model, and how well each fits your existing CI pipeline. Facts on this page were checked against the official website, documentation and repository on 11 November 2026; statements the vendor makes about its own product are marked as vendor claims.