S3 Integration with Spring Boot

S3 integration in Spring Boot comes down to one architectural decision: does your server proxy the file bytes through itself, or does it generate a presigned URL and let the client upload or download directly?

Presigned URLs — the right default

• A presigned URL is a time-limited S3 URL that grants the holder permission to read or write a specific object — your server generates it with S3Presigner.presignPutObject() and returns it to the client, which then uploads directly to S3
• This is the correct approach for uploads because the file never passes through your server — which means your server doesn't consume bandwidth, memory, or connection slots for large uploads; S3 handles the inbound data transfer directly

Direct upload via the server — when necessary

• If you need to validate, transform, or virus-scan the file before storing it, the server must receive the bytes — use S3Client.putObject(PutObjectRequest, RequestBody.fromInputStream(stream, length)) with a streaming approach to avoid loading the entire file into memory
• Set Content-Type and ContentDisposition on the PutObjectRequest so S3 serves the file with the correct headers when downloaded

Using Spring Cloud AWS

• spring-cloud-aws-starter-s3 provides S3Template which wraps the SDK client with Spring idioms — s3Template.upload(bucket, key, inputStream) for uploads, s3Template.download(bucket, key) returns a Resource
• Inject S3Template as a bean; Spring Cloud AWS handles credential resolution from the IAM task role automatically in ECS

Access control

• Never make buckets public; use presigned URLs for time-limited access; for long-term sharing, generate CloudFront signed URLs through a distribution in front of S3
• Enable S3 bucket versioning for user-uploaded data so accidental overwrites can be recovered; enable server-side encryption (SSE-S3 or SSE-KMS) for compliance