S3Proxy

Launch the image from the Azure Marketplace listing. Choose your resource group, region, size (Standard_B2s or larger) and SSH key. Attach the offer's data disk, and open ports 22 and 443 in the network security group. The equivalent Azure CLI commands are:

RG="s3proxy-prod"; LOCATION="eastus"; VM_NAME="s3proxy1" IMAGE_URN="sac1647283583153:s3proxy-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:s3proxy-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --public-ip-sku Standard
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 443 --priority 1001
az vm open-port --resource-group "$RG" --name "$VM_NAME" --port 22 --priority 1002

On first boot the VM generates a unique access key and secret key and writes them to a root-only file. SSH in as azureuser and read them:

sudo cat /root/s3proxy-info.txt

The file contains S3PROXY_ACCESS_KEY, S3PROXY_SECRET_KEY and S3PROXY_ENDPOINT_URL (the HTTPS endpoint using this VM's public IP). These keys are unique to this VM and were not baked into the image. Keep this file secret.

Confirm the gateway, the Java runtime and the network listeners. S3Proxy binds to loopback (127.0.0.1:8080); nginx binds the public HTTPS endpoint on 0.0.0.0:443:

systemctl is-active s3proxy.service nginx.service java -version ss -tlnH | grep -E ':8080|:443'

The AWS CLI ships in the image. Because the endpoint is an IP address with a self-signed certificate, use --endpoint-url and --no-verify-ssl. The following block reads this VM's own keys and runs a full round trip against the local endpoint. It creates a bucket, uploads an object, lists it, then downloads it and prints its contents.

export
AWS_ACCESS_KEY_ID=$(sudo grep '^S3PROXY_ACCESS_KEY=' /root/s3proxy-info.txt | cut -d= -f2-)
export
AWS_SECRET_ACCESS_KEY=$(sudo grep '^S3PROXY_SECRET_KEY=' /root/s3proxy-info.txt | cut -d= -f2-)
export AWS_DEFAULT_REGION=us-east-1 echo "hello from sac" > /tmp/demo.txt aws --no-verify-ssl --endpoint-url https://127.0.0.1/ s3 mb s3://demo-bucket aws --no-verify-ssl --endpoint-url https://127.0.0.1/ s3 cp /tmp/demo.txt s3://demo-bucket/demo.txt aws --no-verify-ssl --endpoint-url https://127.0.0.1/ s3 ls s3://demo-bucket/ aws --no-verify-ssl --endpoint-url https://127.0.0.1/ s3 cp s3://demo-bucket/demo.txt - aws --no-verify-ssl --endpoint-url https://127.0.0.1/ s3 rb s3://demo-bucket --force

There is no anonymous access. An unsigned request is rejected with HTTP 403, and a request signed with the wrong secret key is rejected with SignatureDoesNotMatch:

curl -ks -o /dev/null -w 'unsigned request: HTTP %{http_code}\n' https://127.0.0.1/
AK=$(sudo grep '^S3PROXY_ACCESS_KEY=' /root/s3proxy-info.txt | cut -d= -f2-) AWS_ACCESS_KEY_ID=$AK AWS_SECRET_ACCESS_KEY=wrong-secret AWS_DEFAULT_REGION=us-east-1 \
  aws --no-verify-ssl --endpoint-url https://127.0.0.1/ s3 ls >/dev/null 2>&1 \
  && echo 'UNEXPECTED: wrong key accepted' \
  || echo 'wrong key rejected (expected, SignatureDoesNotMatch)'

The credentials file is root-only (0600), s3proxy.authorization is aws-v2-or-v4, and bucket and object data lives on the dedicated data disk mounted at /var/lib/s3proxy:

sudo stat -c '%n %a %U:%G' /root/s3proxy-info.txt
sudo grep '^s3proxy.authorization=' /etc/s3proxy/s3proxy.conf df -h /var/lib/s3proxy | tail -1

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for S3Proxy. Select the SecureAnyCloud listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger as a balanced default. Choose your EC2 key pair under Key pair (login). Under Network settings select your VPC and subnet, and create or select a security group that allows inbound port 22 from your management network. To let S3 clients reach the endpoint from other machines, additionally open inbound TCP 443 restricted to your application or client subnets, and optionally 80 for the health probe. Leave the root volume at the default size or larger.

Select Launch instance. First-boot initialization, which generates the per-instance key pair and TLS certificate, takes only a few seconds after the instance state becomes Running and the status checks pass.

The following block launches an instance from the SecureAnyCloud S3Proxy Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens port 22 from your management network.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":30,"VolumeType":"gp3"}}' \
  --metadata-options 'HttpTokens=required,HttpEndpoint=enabled' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=s3proxy}]'

The AMI also carries a second 30 GiB volume definition for /var/lib/s3proxy. It is attached automatically from the AMI's block device mapping.

Connect to the instance with SSH as the default login user for the operating system variant you launched. The login user differs by variant:

Operating system variant SSH login user

Ubuntu 24.04 LTS ubuntu

ssh -i /path/to/your-key.pem ubuntu@<instance-public-ip>

S3Proxy runs under systemd as s3proxy.service, with nginx fronting it. Confirm both are active:

systemctl is-active s3proxy nginx

Expected output:

active active

The gateway is bound to loopback only, while nginx owns the public TLS port. You can see the split with ss:

sudo ss -tlnp | grep -E ':8080|:443'

You will see S3Proxy listening on 127.0.0.1:8080 (shown as [::ffff:127.0.0.1]:8080) and nginx listening on 0.0.0.0:443. The unauthenticated health endpoint answers over TLS:

curl -ks -o /dev/null -w '%{http_code}\n' https://127.0.0.1/healthz

It returns 200.

The S3 credentials are generated uniquely on first boot and written to a root-only file. Read them with sudo:

sudo cat /root/s3proxy-info.txt

The file contains S3PROXY_ACCESS_KEY, S3PROXY_SECRET_KEY and S3PROXY_ENDPOINT_URL. Store the secret key somewhere safe. It is the only credential that authenticates requests to your endpoint.

There is no anonymous access. An unsigned request is rejected with 403:

curl -ks -o /dev/null -w '%{http_code}\n' https://127.0.0.1/

It returns 403, confirming that every request must be SigV4-signed with your per-instance key pair.

From the instance, export your per-instance key pair and run a full create-bucket, upload, list and read-back cycle against the endpoint. The certificate is self-signed per instance, so pass --no-verify-ssl (or trust the certificate). S3Proxy uses path-style addressing because the endpoint is an IP address.

export
AWS_ACCESS_KEY_ID=$(sudo grep '^S3PROXY_ACCESS_KEY=' /root/s3proxy-info.txt | cut -d= -f2-)
export
AWS_SECRET_ACCESS_KEY=$(sudo grep '^S3PROXY_SECRET_KEY=' /root/s3proxy-info.txt | cut -d= -f2-)
export AWS_DEFAULT_REGION=us-east-1 aws --no-verify-ssl --endpoint-url https://127.0.0.1/ s3 mb s3://my-first-bucket echo "hello from s3proxy" > /tmp/hello.txt aws --no-verify-ssl --endpoint-url https://127.0.0.1/ s3 cp /tmp/hello.txt s3://my-first-bucket/ aws --no-verify-ssl --endpoint-url https://127.0.0.1/ s3 ls s3://my-first-bucket/ aws --no-verify-ssl --endpoint-url https://127.0.0.1/ s3 cp s3://my-first-bucket/hello.txt - aws --no-verify-ssl --endpoint-url https://127.0.0.1/ s3 rb s3://my-first-bucket --force

The commands above read your per-instance key pair straight from /root/s3proxy-info.txt, so you can copy and paste them on the instance. The object round trips through the gateway and is stored on the data volume under /var/lib/s3proxy/data.

From any machine that can reach the instance on port 443, point the AWS CLI (or boto3, s3cmd, rclone or restic) at https://<instance-public-ip>/ with the same per-instance key pair. Because the certificate is self-signed, either trust /etc/nginx/tls/s3proxy.crt on the client or pass the tool's insecure flag while testing:

export AWS_ACCESS_KEY_ID=<your-access-key>
export AWS_SECRET_ACCESS_KEY=<your-secret-key>
export AWS_DEFAULT_REGION=us-east-1 aws --no-verify-ssl --endpoint-url https://<instance-public-ip>/ s3 ls

In boto3, pass endpoint_url='https://<instance-public-ip>/', aws_access_key_id, aws_secret_access_key, and config=boto3.session.Config(s3={'addressing_style': 'path'}). For production, front the appliance with your own domain and a CA-signed certificate.

Every request on port 443 is SigV4-authenticated, but network isolation is still your first line of defense. The shipped default security group opens only port 22, so port 443 (and 80) are not reachable from off the instance until you open them deliberately. When you do:

• Open 443 only to the application or client subnets that need to read and write objects. Restrict it to known CIDR ranges rather than 0.0.0.0/0.
• Optionally open 80 only where a load balancer needs the unauthenticated /healthz probe. All other port 80 traffic is redirected to HTTPS.
• Keep port 22 restricted to your management network.

Because the secret key is transmitted only inside a SigV4 signature and TLS protects the transport, keys never cross the wire in plaintext. Rotate the key pair at any time by editing s3proxy.identity and s3proxy.credential in /etc/s3proxy/s3proxy.conf and running sudo systemctl restart s3proxy.

Keep the operating system patched with the standard package manager, for example sudo apt-get update && sudo apt-get -y upgrade on Ubuntu, and reboot when a new kernel is installed.

Bucket and object data persists on the dedicated EBS volume at /var/lib/s3proxy across reboots; take regular EBS snapshots of that volume for backups. Review the nginx access and error logs under /var/log/nginx/ for client activity. The S3Proxy service logs are available with sudo journalctl -u s3proxy.