Using proxymock with AWS Services

A recorded AWS interaction is useful test input. It is not a local implementation of AWS. With proxymock, you can record the requests your application makes to supported AWS endpoints and answer matching calls from those recordings while developing locally.

Start with one read-only application path, such as listing objects through the S3 API. Record that path against a test account, then verify that the same application code receives the expected response from the mock. This gives you a concrete boundary to test before adding writes or asynchronous workflows.

What an AWS mock can prove

A recorded response lets you test parsing, application decisions, and error handling for the cases you captured. You can also build explicit failure cases to check how the caller handles an error or a slow dependency. The service virtualization versus mocking guide explains how these test boundaries differ.

It does not prove that IAM policies permit the operation, that AWS accepts the current signature, or that a sequence of writes produces the correct state. A captured S3 response does not implement bucket storage. A captured SQS response does not reproduce the queue’s delivery and visibility semantics. Keep integration tests against disposable AWS resources for behavior owned by AWS.

Record one application workflow

Install and initialize proxymock using the installation instructions. You need a configured API key and an application that can reach the test AWS service. Recording sends real requests, so use test data and credentials scoped to the operations you intend to exercise.

For a Python application whose entry point is app.py, start a recording in a dedicated directory:

proxymock record --out ./aws-recording -- python app.py

Replace python app.py with your application’s normal startup command. Exercise the selected read-only path, then stop the recording. Follow the language configuration guide for SDK proxy and certificate settings. A successful application call is not proof that it was captured: inspect the recorded request and response before continuing.

proxymock web --in ./aws-recording

Open the local address printed by the command. Confirm the AWS host, operation, request body, and response are present. Some SDKs do not honor the same proxy environment variables as ordinary HTTP clients, so resolve missing traffic before treating the recording as a usable mock.

Run against the recording

Restart the application with the recording as mock input:

proxymock mock --in ./aws-recording --no-passthrough -- python app.py

Exercise the same application path and inspect mock matches. The --no-passthrough flag prevents unmatched requests routed through the mock proxy from reaching the real service. Direct connections that bypass the proxy still require separate network controls if the test must be fully isolated.

A newly generated object key or request field can change matching. Investigate the mismatch and tune the fixture deliberately; do not remove meaningful request checks just to make the test pass. The traffic replay tutorial shows how to inspect results rather than rely on a successful command exit alone.

AWS-specific checks to keep

AWS request signing includes values that change over time. The Signature Version 4 documentation describes how AWS authenticates signed requests. A local mock response is not evidence that AWS would accept the same request today.

For DynamoDB, inspect the operation carried in X-Amz-Target as well as the request body. For other services, use their actual method, path, query parameters, and headers. Review credentials, security tokens, account identifiers, and customer data before sharing a recording.

Throttling and error fixtures test the caller’s response to those conditions. They do not automatically model an AWS account’s quota consumption. Likewise, a mock cannot establish cross-service behavior such as an S3 event triggering Lambda or an SQS consumer processing a message exactly as it would in the deployed system.

Keep the mock current

Re-record when the application changes its AWS calls or when an integration test shows that the fixture no longer reflects the dependency. Keep the capture date and the workflow it covers alongside the recording. Use the proxymock local workflow to repeat the capture, inspect, and mock cycle for each additional path.