I recently worked through a hands-on Amazon S3 practical series covering the features I would actually expect to use while working with AWS storage.
Instead of only documenting definitions, this post focuses on what I configured, the commands I used, how I verified the behavior, and what I observed when something went wrong.
For the concepts behind these practicals, I have already covered S3 in two detailed sessions: Session 1: AWS S3 Deep Dive — Objects, Encryption, Bucket Policies & Everything In Between Session 2: AWS S3 — Versioning, Static Hosting, CORS, Object Lock & More This post is the practical companion to those two sessions.
The concepts are covered there; here I focus on actually building, testing, verifying, and troubleshooting the S3 features.
The labs covered: S3 bucket configuration and lifecycle management Bucket policies with IAM, EC2 and HTTPS-only access SSE-KMS encryption with CloudTrail verification Pre-signed URLs AWS CLI S3 Versioning and version recovery Static website hosting S3 CORS S3 Object Lock Note: This is a practical write-up, so I have intentionally kept the focus on implementation and verification rather than turning it into a generic S3 theory article.
1.
S3 Bucket Configuration and Lifecycle Management Objective Create an S3 bucket with a secure baseline and configure a lifecycle rule that automatically transitions objects to lower-cost storage classes over time.
Configuration For the lab: Block Public Access remained enabled.
Bucket Versioning was enabled.
Lifecycle rule: The rule applied to all objects.
Current objects transition to: Standard-IA after 30 days Glacier Flexible Retrieval after 90 days The lifecycle flow was: Result The lifecycle rule was successfully created and enabled, and the S3 console confirmed the configured transition periods.
What this demonstrates Instead of manually moving old objects, S3 Lifecycle can automatically transition objects between storage classes based on age and the rules we define.
2.
S3 Bucket Policy — IAM Read, EC2 Upload and HTTPS-only Access Objective Configure a bucket policy that: Allows a specific IAM user to read objects.
Allows an EC2 role to upload objects.
Denies S3 access when the request is not using HTTPS.
Resources Policy design The policy contained three logical statements: The important security condition was: This denies requests that are not using HTTPS.
Verification The IAM user successfully downloaded an object from S3 using AWS CLI.
An EC2 instance was launched with attached, and the role was verified from the instance.
The EC2 instance was then able to upload an object to S3.
Result Both permission paths worked as intended: IAM user → object read EC2 role → object upload Non-HTTPS access → explicitly denied Practical takeaway A useful S3 security pattern is to combine: identity-based permissions, resource-based bucket policies, and explicit security-condition denies.
3.
SSE-KMS Encryption with CloudTrail Verification Objective Configure S3 default encryption using a customer-managed KMS key and verify the resulting cryptographic operations through CloudTrail.
KMS configuration The lab used: Configure S3 encryption The bucket: was configured for server-side encryption using the customer-managed KMS key.
Verification After uploading and downloading an object, I checked CloudTrail Event History.
The relevant KMS operations were: appeared during the encryption flow, while events were associated with accessing encrypted data.
Troubleshooting Initially, the expected cryptographic events were not obvious in CloudTrail.
Instead of relying only on the initial event list, I changed the lookup to search by Event name.
That exposed the expected: events.
Result SSE-KMS was successfully configured and the related KMS operations were visible through CloudTrail.
Practical takeaway Encryption configuration alone is not always enough when troubleshooting.
CloudTrail can provide the audit trail needed to understand which AWS services and cryptographic operations were involved.
4.
S3 Pre-signed URL Objective Keep an S3 object private while providing temporary access through a pre-signed URL.
Object The object itself remained private.
No public permissions were added.
Generate the URL seconds = 5 minutes.
Test I opened the generated URL in an Incognito browser window.
The private object was accessible successfully.
After the five-minute validity period expired, I refreshed the same URL.
S3 returned: Result The test demonstrated the main behavior of a pre-signed URL: Practical takeaway A pre-signed URL is useful when an application needs to provide temporary access to a private S3 object without making the object itself public.
5.
AWS CLI Objective Use to synchronize a local directory with S3 and verify that only changed files are uploaded during a subsequent sync.
Create the test directory Initial sync Then verify: The first synchronization uploaded both files.
Modify one file Run sync again: This time, only was uploaded.
Result The practical demonstrated the differential behavior of: Unchanged content did not need to be uploaded again.
Practical takeaway This is useful for scripts, backups and deployment workflows where repeatedly uploading an entire directory would be unnecessary.
6.
S3 Versioning and Version Recovery Objective Enable Versioning, upload the same object key multiple times, identify the generated Version IDs, retrieve an older version, and remove the current version to demonstrate recovery.
Enable Versioning Versioning was enabled on: Create multiple versions The same object key was reused: Version 1: Version 2: Version 3: List versions The practical produced multiple retained versions for the same object key.
The latest version was marked as current, while previous versions remained available.
Retrieve an older version Then: The historical content was: Delete the current version A specific Version ID was deleted: Then the versions were listed again: The previous version became the latest available version.
Troubleshooting The version listing output opened in the terminal's viewer.
To return to the shell: There was also an initial retrieval mistake where: failed because the file had not yet been created.
After running successfully, the historical content could be read.
Result This lab demonstrated that Versioning can preserve historical object states and allow an older version to be retrieved even after a newer version becomes current.
7.
S3 Static Website Hosting Objective Host a simple static website directly from an S3 bucket and configure a custom error page.
Bucket For this lab, Block Public Access was disabled because the website content needed to be publicly readable through the S3 website endpoint.
Website configuration Static website hosting was enabled with: Verification The S3 region-specific website endpoint was opened in a browser.
The website loaded successfully.
A non-existent page was then requested to trigger the configured error document.
The custom 404 page was returned successfully.
Result Both paths were verified: Practical takeaway S3 website hosting is useful for simple static content, although real production architectures may place additional services such as CloudFront in front of the content.
8.
S3 CORS Objective Demonstrate a browser cross-origin request failure and then allow the request using an S3 CORS configuration.
This was one of the more useful troubleshooting labs because the browser behavior made the difference between S3 access and browser CORS permission very visible.
Resources The webpage was hosted from one S3 website origin and attempted to fetch the image from another S3 origin.
Test before CORS The webpage attempted a JavaScript request for .
The browser blocked the response because the required: header was not present.
The browser console showed the CORS failure.
Configure CORS For the practical, the object bucket was configured with: Test again A fresh pre-signed URL was generated and the browser test was r