Editorial illustration.
Originally published 16 June 2023; rewritten and reviewed on 15 October 2026.
A file reaches S3 successfully, but the application cannot explain who owns it or whether it should be downloadable. The upload operation is simpler when the object key, metadata and access rules are decided first.
Let the application choose the key
Validate the user’s permission to create the document and assign a controlled object key. Keep the original filename as metadata where needed; do not let it choose an arbitrary destination or overwrite another user’s object.
A C# AWS SDK outline using a configured S3 client is:
await using var input = File.OpenRead(authorisedFilePath);
var request = new PutObjectRequest
{
BucketName = bucketName,
Key = objectKey,
InputStream = input,
ContentType = approvedContentType
};
await s3.PutObjectAsync(request, cancellationToken);
The caller supplies validated values and an appropriately scoped identity through the environment. The example is a core operation, not a complete upload-validation endpoint.
Keep storage and delivery separate
An uploaded object should not become public merely because the application wants to show a download button. Choose private retrieval, a narrowly scoped presigned URL or an intended CDN path according to the product’s access requirements.
Confirm content type, encryption and retention settings for the bucket and workload. Do not put credentials in source code or add a public ACL as a blanket fix for an access error.
Reconcile application records
Store the object key with the business record and decide how to recover if either the database write or storage operation fails. Test retry behaviour so a repeated request does not leave unexplained duplicate objects.
The meaningful success condition is an authorised document whose location and lifecycle are recorded. “S3 returned successfully” is one checkpoint inside that workflow.