S3Proxy - S3-Compatible Object Storage Gateway

This is a repackaged open source software product wherein additional charges apply for cloudimg support services.

## Overview

S3Proxy is an open source Java application (Apache License 2.0) that implements the Amazon S3 API and proxies requests to a configurable storage backend. This cloudimg AMI configures the local filesystem backend so that a single EC2 instance and its dedicated EBS data volume become a fully functional S3-compatible object storage endpoint: point any S3 SDK, the AWS CLI, boto3, s3cmd, rclone, restic, or Veeam at it and read and write buckets and objects exactly as you would against Amazon S3, entirely within your own AWS account.

The gateway ships fully installed and reverse-proxied behind nginx with TLS. A working, authenticated S3 endpoint is operational within minutes of launch, with no manual package installation, no dependency troubleshooting, and no proxy configuration required.

## What Is Included

• Pinned upstream S3Proxy release jar (sha256-verified), installed under /opt/s3proxy and run as a dedicated s3proxy system user
• A systemd unit that binds the S3 gateway to loopback only, so the engine is never directly internet-exposed
• An nginx TLS reverse proxy on port 443 that terminates a per-instance self-signed certificate and forwards SigV4-signed requests to the gateway, plus an unauthenticated /healthz endpoint for load-balancer health checks
• A dedicated EBS data volume mounted at /var/lib/s3proxy for bucket and object storage
• Per-instance S3 credentials generated automatically on first boot

## Why This AMI Over a Manual Install

Unlike a bare deployment, this image never exposes an open, anonymous endpoint. S3Proxy can run with authorization disabled, but this appliance requires AWS Signature Version 4 on every request. A unique access key and secret key are generated on each instance's first boot, written to a root-only file (mode 0600), so requests are authenticated from the very first API call. The gateway binds only to loopback and is fronted by nginx over TLS, while bucket and object data lives on a dedicated data volume and systemd manages the service for automatic restarts and clean logging.

## Architecture

The request flow is straightforward:

1. An S3 client sends a SigV4-signed request to the instance on port 443

2. nginx terminates TLS and validates the connection

3. nginx forwards the request to S3Proxy on loopback (127.0.0.1)

4. S3Proxy authenticates the signature and reads or writes objects on the EBS data volume at /var/lib/s3proxy

This layered design means the S3 engine is never directly reachable from the network, and TLS protects data in transit.

## Security Practices

• Loopback-bound gateway: the S3 engine binds to 127.0.0.1 only. All external access flows through nginx over TLS.
• Per-instance credentials on first boot: a one-shot service generates a random access key and secret key and writes them into the config and into /root/s3proxy-info.txt with mode 0600. No credentials are baked into the image.
• SigV4 required, no anonymous mode: every request must be AWS Signature Version 4 or Version 2 signed. Unsigned and wrong-key requests are rejected with HTTP 403.
• Default security group opens SSH only: ports 80 and 443 are served by nginx but are not reachable until you explicitly open them in your security group.
• TLS in transit: nginx terminates a per-instance self-signed certificate; front the endpoint with your own domain and CA certificate for production.

## Use Cases

• Nightly backup target for databases and applications: point a restic or Veeam backup agent at this local S3 endpoint, avoiding per-request charges and keeping backup data within the same VPC.
• On-instance object store for CI/CD and integration tests: stand up an S3-compatible store for a test suite that exercises S3 SDK calls without provisioning a real Amazon S3 bucket, and tear it down when the pipeline finishes.
• Drop-in object store for rclone, restic, and Veeam: existing S3 client configurations and libraries work unchanged with a single endpoint-url override and path-style addressing enabled.

## Getting Started

1. Launch the AMI and SSH in as the default login user for your OS variant.

2. Read your unique access key and secret key from /root/s3proxy-info.txt.

3. Point any S3 client at the endpoint, for example: aws s3 ls --endpoint-url https:// --no-verify-ssl

4. Open port 443 in your security group to the CIDR ranges that need access.

5. For production, replace the self-signed certificate with your own domain and CA-signed certificate in nginx.

For a guided setup, production TLS review, or sizing review, contact cloudimg support at support@cloudimg.co.uk or via live chat.

## About S3Proxy

S3Proxy is an open source project distributed under the Apache License 2.0.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.