Using Amazon S3 for backups: a small-site guide
A plain guide to using Amazon S3 for backups: what buckets and object storage are, how to lock a bucket down, and simpler options if AWS is overkill.
Amazon S3 is object storage you rent from AWS, and it makes a dependable offsite copy of the files a small site can’t afford to lose: database dumps, uploaded images, and config backups. You upload each file to a private bucket, AWS keeps redundant copies across multiple data centers, and you pay only for what you store. One thing to settle before anything else: an S3 bucket is private by default, and for backups it should stay that way.
What Amazon S3 actually is
S3 is short for Simple Storage Service. It is object storage, which means every file you upload is kept as an object — the file plus some metadata — inside a bucket, which is just a named container. Each object has a unique key (its name) within the bucket. You don’t mount it like a disk drive; you put and get objects through the AWS console, the command line, or a backup app that talks to S3.
The appeal for backups is durability. AWS designs its main storage classes for 99.999999999% (eleven nines) of durability by storing copies across multiple facilities, as described in the Amazon S3 documentation. That copy lives somewhere other than your server, which is the entire point of a backup.
Why people back up to S3
An S3 bucket gives you the offsite copy that a solid backup routine is built around. Two features do most of the work:
- Versioning keeps multiple versions of the same object, so you can restore a file after it is accidentally deleted or overwritten, per S3 Versioning. Without it, uploading a broken backup over a good one loses the good one.
- Lifecycle rules move older objects to cheaper storage classes on a schedule you set, or expire them after a set time, per the AWS guide to managing object lifecycle. Last night’s backup can sit in fast storage while last year’s drifts into cold archive on its own.
Storage classes, from hot to cold
Backups don’t all need instant access, so S3 offers classes that trade retrieval speed for a lower storage cost. AWS specifically lists its infrequent-access classes as suitable for storing backups. Every class in the table below is designed for the same eleven-nines durability; what changes is how fast and how cheaply you can get the data back.
| Storage class | Good backup fit | Retrieval | Keep in mind |
|---|---|---|---|
| S3 Standard | The latest backup you might restore any day | Immediate (milliseconds) | Highest storage cost of the group |
| S3 Standard-IA | Backups you keep but rarely open | Immediate (milliseconds) | Retrieval fee; 30-day minimum |
| S3 Glacier Instant Retrieval | Older archives you still want back at once | Immediate (milliseconds) | Retrieval fee; 90-day minimum |
| S3 Glacier Flexible Retrieval | Long-term copies you can wait on | Minutes to hours (restore first) | 90-day minimum |
| S3 Glacier Deep Archive | Keep-for-years copies you almost never read | Hours (restore first) | 180-day minimum; slowest |
Retrieval fees and minimum storage durations apply to the infrequent-access and archive classes, so match the class to how often you would realistically need a restore. The current details live on the AWS storage classes page.
Setting up a bucket safely
The security defaults are good; the trouble comes from switching them off. Leave Block Public Access turned on. AWS enables it for new buckets and recommends keeping all four settings on, per its guide to blocking public access, and a backup bucket has no reason to ever be public. Turn on versioning so an overwrite or a bad upload is recoverable rather than final. Server-side encryption protects the data at rest and is on by default.
For access, don’t use your root account and don’t share one all-powerful key. Create a dedicated IAM user for your backup tool, give it permission to write to just that one bucket, and store its access keys the way you would store a password — never hard-coded into code you push to a public repo. Hardening the thing being backed up matters too: if it is a WordPress site, work through these steps to secure WordPress so you are not backing up a site that keeps getting compromised.
Simpler options if AWS is overkill
S3 is capable, but it assumes you are comfortable with AWS accounts, IAM permissions, and a bill that scales with usage. If that is not you, simpler routes cover the same need:
- A consumer backup service that bundles storage and scheduling for one predictable fee.
- Your web host’s own backup add-on, as long as it stores copies off the server.
- An external drive paired with a cloud sync folder, for a small personal site.
The rule is the same whatever tool you pick: keep at least one copy off the machine, and confirm you can actually restore it. Our guide to backing up your files properly covers that, and if the problem is a file you have already lost, see how to recover deleted files on Windows.
Start small. One private bucket, versioning on, a single IAM user that can only write to it, and a lifecycle rule that ages old backups into a cheaper class. That covers the offsite copy most small sites are missing, and you can add cross-region replication later if you ever need it.