# Runpod S3 storage: a network-volume API, with specific limits

Use Runpod’s S3-compatible API for network-volume files, with the correct data-centre endpoint and explicit checks for unsupported Amazon S3 features.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/gpu-cloud-s3-model-cache-storage/
Language: en

Runpod's S3-compatible API provides access to files on a network volume without starting a Pod. It is an interface to that volume, not a promise of the entire Amazon S3 feature set. A client needs the appropriate endpoint, data centre, volume ID and credentials.

## Map the volume and file paths

The documentation treats the network volume as a bucket and object names as paths on that volume. Uploading through the API and reading from an attached Pod can therefore use the same data.

Keep the laptop directory, object address and in-Pod path distinct in the runbook. Record source folder, volume ID, destination directory and the path the application expects after attachment. A familiar storage client does not remove the need for that mapping.

## Use the current location endpoint

The S3 client must receive the network volume's endpoint and the appropriate data-centre value for its region argument. A default Amazon endpoint would address a different service.

The volume has its own placement and lifecycle. Another volume in a different data centre does not become a synchronized copy. Before moving compute, decide whether a compatible Pod will use the existing resource or whether data needs an explicit transfer.

## Check the supported operations

| Operation | Documented Runpod behaviour |
| --- | --- |
| Read and upload files | Supported API operations |
| Create the volume | Runpod console rather than CreateBucket |
| Delete the volume | Separate resource management |
| Versioning | Not supported by this API |
| Presigned URLs | Not supported in the operation table |

A client may call ACL, metadata or other operations automatically. Check its actual requirements, not just a successful single-file read. Test required writes and error handling on a small set before committing a large upload.

## Prepare data before renting compute

A team can create a volume, upload a control file and download it again before deploying a GPU Pod. Then transfer the main input set, preserve integrity information and confirm the expected path after attachment.

This separates preparation from the compute session but does not remove volume charges or guarantee GPU availability. For valuable data, keep an independent verified backup, especially when a familiar versioning capability is absent.

Preserve volume ID, location, required operations and a key-management procedure without exposing live secrets in notebooks or reports. For larger transfers, use a supported client mechanism and confirm completion. Pod deletion does not finish this independent storage resource's lifecycle.

## Turn the check into a practical next step

S3 compatibility means a documented operation set, not every Amazon S3 feature. Verify the client’s actual calls before loading a large working dataset.

For the documented details, consult the [primary documentation](https://docs.runpod.io/storage/s3-api); [configuration reference](https://docs.runpod.io/storage/network-volumes). Continue with [runpod network volume persistence](/journal/runpod-network-volume-persistence/) and [cloud gpu resource cleanup audit](/journal/cloud-gpu-resource-cleanup-audit/).