Amazon S3 object storage
Where files should live once an application has more than a handful of them — and never on the web server’s own disk.
Object storage
Chosen per project
Maintainable handover
Storing user uploads on the application server is the most common avoidable mistake in a growing system. It ties the files to one machine, makes scaling out awkward and turns a disk failure into data loss.
Object storage fixes all three, and adds things that are hard to build yourself: versioning, lifecycle rules that move old files to cheaper tiers, and time-limited signed URLs so private documents can be shared without being made public.
What we build with Amazon S3
Document and image uploads in any web or mobile application
Database and application backups held off the server
Static assets served through a CDN
Data exports and long-term archives
Where it fits — and where it does not
Good fit when
Any file an application receives from a user
Content that must survive the machine that created it
Archives where storage cost matters more than access speed
Consider something else when
Data that needs to be queried — that is a database job
Very low-latency random access within a file
How a file gets in and out safely
The application never proxies the bytes, and the bucket is never public.
Request a slot
App checks permission, returns a signed upload URL.
Direct upload
Browser sends the file straight to S3.
Record and scan
App stores the key, validates type and size.
Signed retrieval
Downloads use short-lived URLs, expiring on their own.
How we work with Amazon S3
Private by default
Public access blocked at the account level; files reached through signed URLs or a CDN, never by making the bucket open.
Lifecycle rules
Old versions and stale exports moved to cheaper storage classes or expired, so cost does not grow forever.
Versioning where it matters
Turned on for anything a user could overwrite or delete by mistake.
Encryption and logging
Server-side encryption on, access logging on, so who read what is answerable.
Our typical Amazon S3 setup
| Concern | What we use |
|---|---|
| Access | Block Public Access on; IAM policies scoped to a prefix |
| Sharing | Pre-signed URLs with short expiry, or CloudFront with signed cookies |
| Classes | Standard for live files, Infrequent Access or Glacier for archives |
| Protection | Versioning plus lifecycle expiry of old versions |
| Audit | Server access logging or CloudTrail data events |
Frequently asked questions
Yes, and it is usually best done through CloudFront in front of a private bucket. That gives you caching and a proper cache-control policy rather than serving directly from storage.
Block Public Access is enabled at account level, so an individual bucket cannot be made public by accident. Sharing is done through signed URLs instead.
It is a good one, particularly with versioning and a lifecycle rule to Glacier. Backups are only worth having if they are restored from occasionally, which we would set up as a routine.
Services built with Amazon S3
Cloud Solutions
Hosting designed around what your application actually needs, with the monitoring and backups that make it safe to rely on.
Web Application Development
Applications that run in the browser, handle real workloads and hold up when several departments depend on them at once.
Custom Software Development
Software shaped around the way your business already works, instead of a packaged product you have to reorganise around.
Software Maintenance
Keeping working systems working — including ones built by somebody else.
Tell us what you are trying to build
Describe the problem in plain language and we will tell you what it would take to solve it — the approach, the moving parts and the sensible order to build them in. No obligation either way.