Secure an S3 Business Records Vault

Build a private S3 vault with controlled sharing, recovery, and audit evidence.

Introduction

30 Second Summary

A misplaced business record can expose sensitive information or erase proof that an important decision was approved. Reliable storage needs a safe way to share records without weakening their protection.

In this project, you will build a private business-record vault in Amazon S3 with recovery controls and audit evidence. You will issue a time-limited presigned URL that shares a record without making its bucket public.

What You'll Build

Your finished demo proves that one private record can be opened, shared for a limited time, recovered after an overwrite, and traced through an audit history.

By the end of this project, you'll have:

A private records vault where you can open compliance-record.txt while public access remains blocked. Default encryption protects the object in Amazon S3.
A controlled sharing demo where the quick console link expires after five minutes. A deliberate 15-minute presigned URL then opens the same private record.
A recovery workflow that uses S3 Versioning to restore Status: approved after an overwrite. You can then inspect bucket-level management activity in AWS CloudTrail.
Secret Mission: Recover an accidentally deleted compliance-record.txt by finding its delete marker. Remove that marker without re-uploading the file.

Are there any prerequisites?

You only need a Mac with a browser. AWS account creation and multi-factor authentication setup are included.

Before We Start

A secure vault starts with a clear reason for protecting what goes inside it. Before you work with AWS, choose a fictional business record so every security decision connects to the risk of losing or exposing it.

Secure Your AWS Workspace

The business record you chose will eventually live behind your AWS account. The vault is trustworthy only when the workspace identity is protected.

Multi-factor authentication (MFA) adds that protection at sign-in. Cost visibility confirms the workspace stays inside the Free Plan while you build.

In this step, get ready to:

Provision an AWS account with a project workspace.
Register an MFA device for your account.
Inspect the project's Free Plan billing view.

Create your AWS account and project

Sign up for AWS (new) provisions a preconfigured AWS environment organized into projects. Your project opens in the AWS Management Console.

What about the verification hold?

AWS may place a temporary USD $1 verification hold for 3-5 days during signup. Usage charges begin only if you upgrade to a paid plan.

In Safari, open the Sign up for AWS (new) page that you confirmed is available.
Choose Google, Apple, GitHub, Amazon, or email as your sign-in option.
Complete each on-screen verification prompt.
Open the project AWS provisions for you.
Use the same sign-in option if AWS asks you to authenticate again.

You should see the AWS Management Console in Safari. Your project workspace is now live and ready for security controls.

Project did not open?

Confirm that every signup verification prompt is complete.
Sign in with the same option you selected during signup.

Still stuck? Help me troubleshoot the AWS signup and project provisioning flow.

Register an MFA device

An MFA device provides a second proof of identity when you sign in. A supported Mac can use Touch ID.

Google Authenticator provides the app-based path. The extra minute gives every later visit to your vault a second identity check.

Choose Manage projects in the AWS Management Console to open AWS Settings.
Choose Manage security and sign-in.
In Security, choose Register device.
Choose the tab that matches your MFA method.

Touch ID on a supported Mac

Select the built-in authenticator method for Touch ID.
Complete the browser prompt with Touch ID.

Google Authenticator

Choose Authenticator app.
Choose Show QR code.
Scan the QR code in Google Authenticator.
Enter the current code in the Authenticator code field.
Choose Assign MFA.

Return to Security in AWS Settings.
Confirm that Security lists your MFA device as registered.
Keep the registered device on the account after this project.

Your AWS sign-in now has a second identity check. That protection stays with the account beyond this vault project.

MFA device not listed?

Confirm that you completed the browser prompt when using Touch ID.
Enter a fresh Google Authenticator code if the previous code expired.
Return to the registration flow if AWS Settings did not confirm the device.

Need help? Help me finish registering my AWS MFA device.

Confirm Free Plan cost visibility

Billing shows the current project's month-to-date charges plus its forecast. This is a read-only check of your existing coverage.

Before the final check, which security status and plan state do you expect AWS Settings to show?

Switch back to AWS Settings in Safari.
Choose Manage security and sign-in.
Select Security.
Confirm that a registered MFA device is listed.

Security should list the MFA device you registered. This confirms that your second sign-in factor remains active.

Return to AWS Settings.
Select Billing.
Select Cost by project.
Confirm that Free Plan coverage or credits are visible.
Review the current project cost information.
Leave Paid Plan unselected.

You should see Free Plan coverage or credits plus current project cost information. Paid Plan remains unselected.

Free Plan details missing?

Confirm that Cost by project is showing the project provisioned during signup.
Refresh AWS Settings if the billing information is still loading.
Keep Paid Plan unselected while you investigate the missing coverage details.

Need a second pair of eyes? Help me find my Free Plan coverage and current project cost information.

Your AWS workspace now has MFA protection plus visible cost coverage. Next, you will create the private records vault that holds your fictional business record.

Create the Vault and Upload a Record

Your secured AWS workspace is ready for data. The next goal is a real records vault in Amazon S3 that you can inspect from Safari.

A recovery test needs one trusted baseline object before S3 Versioning starts. This step stores that baseline with private encrypted defaults. It then enables recovery for the overwrite test you will run later.

In this step, get ready to:

Create a plain-text fictional record.
Create a protected S3 bucket.
Establish a versioned baseline in the bucket.

Create the fictional record

A plain-text file makes the record easy to inspect in both TextEdit and the browser. Real personal or business data has no place in this practice vault.

Use macOS search to launch TextEdit.
Choose File from the menu bar.
Choose New.
Choose Format from the menu bar.
Choose Make Plain Text.

Keep the record fictional

Use the type of business record you chose earlier as inspiration. Include only invented details so the file is safe to upload during a learning project.

Enter a short fictional record based on the record type you chose earlier.
Add Status: approved on its own line.
Save the document locally as compliance-record.txt in a folder you can find again.
Confirm the saved document shows compliance-record.txt as its filename.
Confirm the document contains Status: approved.

Good work. Your local baseline record is ready for secure storage.

Build the private S3 vault

A bucket is the container that holds your uploaded object. Its security settings apply before the file enters the cloud.

Creating a cloud resource can feel like a billing jump. Creating this bucket has no charge.

Why keep these defaults?

Bucket owner enforced disables access control lists so the bucket owner controls every object.
Block Public Access keeps all four public-access protections enabled.
Server-side encryption with SSE-S3 encrypts new objects using keys managed by Amazon S3.

Switch back to the AWS Management Console in Safari.
Use the console search bar to find Amazon S3.
Select Amazon S3 from the search results.
Choose the displayed AWS Region name in the navigation bar.
Select the AWS Region where your vault should remain.
Record the selected Region here: your selected AWS Region.
Choose General purpose buckets from the left navigation pane.
Choose Create bucket.

Keep the bucket type set to General purpose.
Enter compliance-vault-yourinitials-sixdigits in the Bucket name field.

The form now shows your unique bucket name under the General purpose bucket type.

Confirm Bucket owner enforced remains selected under Object Ownership.
Confirm all four options remain selected under Block Public Access settings for this bucket.

The ownership control remains enforced. All four public-access protections remain selected.

Confirm Server-side encryption with Amazon S3 managed keys (SSE-S3) remains selected under Default encryption.
Choose Create bucket.

Your new bucket should appear in the General purpose buckets list. That is the vault created with its core security safeguards intact.

Bucket name unavailable?

Replace the six-digit suffix with a different six-digit value.
Update your saved bucket name here: compliance-vault-yourinitials-sixdigits.
Choose Create bucket again.

Still blocked? Help me create a unique S3 bucket without changing the required security defaults.

Establish the versioned baseline

Uploading compliance-record.txt before versioning creates the baseline null version. Later recovery tests can compare new versions against this original copy.

Choose compliance-vault-yourinitials-sixdigits from the General purpose buckets list.
Choose the Objects tab.
Choose Upload.
Choose Add files.
Select compliance-record.txt from the local folder where you saved it.
Choose Open in the file picker.
Choose Upload.

The upload status should show success. Your Objects list now contains compliance-record.txt.

Don't see the uploaded record?

Return to the Objects tab for your bucket.
Confirm the upload status completed successfully.
Repeat the upload with the local compliance-record.txt file if the earlier upload did not finish.

Need another pair of eyes? Help me find why compliance-record.txt is missing from my S3 Objects list.

The baseline was intentionally uploaded while versioning was disabled. Enabling versioning now preserves future same-name changes for recovery.

Choose the Properties tab.
Find Bucket Versioning.
Choose Edit.
Choose Enable.
Choose Save changes.
Record the current time here: time you enabled versioning.

S3 can take up to 15 minutes to propagate the first versioning change. The pause is expected while S3 finishes applying the setting.

Leave the bucket unchanged for at least 15 minutes before another upload or deletion.

Before you verify, which two visible details should prove that the baseline record is stored and recovery is ready?

Choose the Objects tab.
Choose compliance-record.txt.
Choose Open.

You'll see the fictional baseline record with Status: approved.

Return to the bucket tab in Safari.
Choose the Properties tab.
Find Bucket Versioning.

You'll see Enabled under Bucket Versioning. Your vault now has a readable baseline plus recovery protection for future changes.

Your protected baseline is stored. Next, you will test how quickly a console-generated share link expires.

Watch a Quick Share Link Expire

Your private Amazon S3 vault now holds compliance-record.txt with its approved baseline content.

The console's Open action creates a convenient sharing link. This step tests whether that link lasts long enough for reliable sharing.

In this step, get ready to:

Generate a console Open link for compliance-record.txt.
Use a Safari Private Window to test the link without your console session.
Refresh the same link after five minutes to test its lifetime.

Open the record in a private window

A presigned URL gives its holder temporary permission to read a private object. A Safari Private Window lets you test the link without relying on your signed-in console session.

Return to the Objects list for your compliance-vault-yourinitials-sixdigits bucket in Amazon S3.
Select compliance-record.txt.
Choose Open.
Copy the full URL from the Smart Search field on the page S3 opened.
Choose File from Safari's top menu bar.
Choose New Private Window.
Paste the copied URL into the Smart Search field.

Before you load the page, consider whether a private object can open without an active console session.

Press Return to load the URL.

The private window shows your fictional record with Status: approved. That is your first sharing proof: the object opens without an AWS console session.

The temporary permission travels in the URL. Your bucket's public-access blocks remain enabled.

Record not opening?

Copy the entire address from Safari's Smart Search field again.
Return to the S3 Objects list if the object page is no longer available.
Choose Open for compliance-record.txt to generate another five-minute URL.

Still stuck? Help me troubleshoot why my S3 Open URL does not load in a Safari Private Window.

Test the same link after five minutes

The console-generated Open URL has a five-minute lifetime. This test includes a five-minute pause while that lifetime runs down.

Wait until five minutes have passed since you chose Open.

Before you refresh, consider whether the same URL can still open the record.

Refresh the page in the Safari Private Window.

This time, you'll see an S3 error page instead of the record. The planned failure proves that the console's quick link has expired.

The object still exists in S3. Your bucket remains private throughout this test.

Record still opening?

Confirm that five minutes have passed since S3 generated the URL.
Refresh the private tab to send a new request.
Avoid choosing Open again because that generates a new five-minute URL.

Need another pair of eyes? Help me verify whether my S3 Open URL has reached the end of its five-minute lifetime.

You caught the exact weakness: the convenient Open link expired after five minutes. Next, you'll create a presigned URL with a lifetime you choose while your bucket remains private.

Share the Record with a Controlled Expiration

The five-minute Amazon S3 console link worked in your Safari Private Window. Its short lifetime made it unreliable for a deliberate handoff.

This step replaces that quick link with an explicit presigned URL that lasts 15 minutes. Your bucket stays private because all four Block Public Access settings remain enabled.

In this step, get ready to:

Generate a 15-minute presigned URL for compliance-record.txt.
Open the record through the URL in your Safari Private Window.
Confirm that all four Block Public Access settings remain enabled.

Create a 15-minute presigned URL

The URL gives whoever receives it temporary access to the record. That access ends when the 15-minute lifetime expires.

Why use a presigned URL?

Public access changes who can reach the bucket. A presigned URL grants time-limited download permission to one private object.

This approach supports a controlled handoff. The bucket's public-access blocks stay in place.

Switch back to the AWS Management Console tab in Safari.
Return to your bucket's Objects list.
Select compliance-record.txt.
Choose Object actions.
Choose Share with a presigned URL.
Set the link lifetime to 15 minutes.
Choose Create presigned URL.

Good progress. The record now has a deliberate 15-minute sharing window.

Test the temporary access

Your Safari Private Window has no AWS console session. Opening the record there proves that the new URL carries the temporary permission.

Before you test the new link, do you expect it to open after the previous five-minute URL expired?

Switch back to the Safari Private Window from earlier.
Paste the copied presigned URL into Safari's address bar.
Press Return to load the URL.

You should see the record open in the private window or download through Safari. The accessible file contains Status: approved.

That test proves the controlled share works. The private window can reach the record without an AWS console session.

Record does not open?

Check that the complete copied URL is in Safari's address bar.
Create a new 15-minute URL if more than 15 minutes have passed.
Confirm that you selected compliance-record.txt when creating the URL.

Still blocked? Help me troubleshoot an S3 presigned URL that does not open my private object in Safari.

Confirm the bucket stays private

A presigned URL carries its own temporary permission. The bucket's public-access controls remain a separate security guardrail.

Before you inspect the permissions, do you expect generating the link to change any public-access setting?

Return to your bucket in the AWS Management Console tab.
Choose the Permissions tab.
Locate the Block Public Access section.
Confirm that all four Block Public Access settings are enabled.

You should see all four settings enabled. This confirms that the URL provides temporary access without making the bucket public.

Is a public-access block disabled?

Pause further sharing until all four settings are enabled.
Review the bucket permissions you configured when creating the vault.

Need help restoring the secure configuration? Help me restore all four S3 Block Public Access settings without deleting my private object.

Your vault can now share one record for a controlled window while its public-access blocks stay enabled. Next, you will recover the approved version from an overwrite using AWS CloudTrail to inspect the bucket activity.

Recover an Overwrite and Audit the Change

The controlled link from the last step proved that your private Amazon S3 record can be shared temporarily.

An accidental same-name upload can replace the record people see. This step proves that your vault can recover the approved copy.

You will also inspect the bucket's management activity in AWS CloudTrail. That evidence records when the activity happened.

In this step, get ready to:

Create a same-name superseded upload.
Prove that the approved copy is still recoverable.
Trace bucket-level management activity in AWS CloudTrail.

Overwrite the approved record

S3 Versioning gives each later upload its own version number. Your baseline record remains the pre-versioning null version.

The full 15-minute propagation wait can feel slow. It protects this test from temporary versioning inconsistencies.

Compare the current time with the versioning enablement time you noted earlier.
Wait until the full 15 minutes have elapsed if needed.
Switch back to compliance-record.txt in TextEdit from earlier.
Find the line containing Status: approved.
Replace it with Status: superseded.
Save compliance-record.txt by pressing Cmd+S.

Your local record now shows Status: superseded. This saved file represents the accidental overwrite you are testing.

Return to the Amazon S3 console from earlier.
Choose your vault bucket.
Choose the Objects tab.
Choose Upload.
Choose Add files.
Select the saved compliance-record.txt file.
Choose Open.
Choose Upload.

You'll see the upload complete for the same object key. The normal Objects view still lists one compliance-record.txt object.

Before you open the object, which status do you expect the current copy to show?

Choose compliance-record.txt from the Objects list.
Choose Open.

You'll see Status: superseded. The same-name upload has replaced the copy that opens by default.

The overwrite is visible

Seeing the superseded content is the planned shortfall. The normal object view now points to the latest upload.

The approved record no longer opens from this view. Recovery begins in the version history.

Still seeing the approved status?

Return to TextEdit from earlier.
Confirm that the local file contains Status: superseded.
Repeat the upload steps with the saved file.

Still stuck? Help me work out why my same-name S3 upload still shows the approved record.

Recover the approved version

The Versions view exposes the preserved copies behind the single object key. Permanently deleting the current superseded version makes the previous approved version current again.

Permanently deleting a version can feel drastic. This time, the selected target is only the superseded upload you just created.

Return to the Objects list for your vault bucket.
Choose compliance-record.txt.
Choose Versions.
Identify the current latest version from the upload you just completed.
Select the current latest Version ID.
Choose Delete.
Enter permanently delete in the confirmation field.
Choose Delete objects.

You'll see that the selected latest version is gone from the Versions view. The older null version remains.

Before you open the object, which status do you expect to be current now?

Return to the normal Objects list.
Choose compliance-record.txt.
Choose Open.

You'll see Status: approved. You have recovered the original record without uploading a replacement.

Still seeing the superseded status?

Return to the Versions view.
Confirm that the latest superseded Version ID is no longer listed.
Select only the latest superseded version if it remains.
Repeat the permanent deletion for that version.

Need help choosing the correct version? Help me identify the superseded S3 version without deleting the approved null version.

Audit the bucket change

CloudTrail Event history lists management events from the last 90 days in one AWS Region. Object uploads are data events, so they do not appear in this view.

Your audit target is the bucket-level management activity. A matching event gives you a time plus identity details tied to the vault.

In the AWS Management Console from earlier, confirm that the top Region selector matches your S3 bucket's Region.
Use the top search bar to search for AWS CloudTrail.
Select AWS CloudTrail from the search results.
Choose Event history.

Before you apply the filter, do you expect this view to show bucket-management events, object uploads, or both?

Choose the Event source filter.
Enter s3.amazonaws.com.

You'll see the history narrow to S3 management events in the selected Region. The object uploads do not appear because this view excludes data events.

Choose a recent management event that references your vault bucket.
Read the event time.
Inspect the identity details.
Inspect Resources referenced for your bucket.

Your approved record is current again. CloudTrail now supplies management evidence tied to the bucket.

No bucket events in the list?

Confirm that CloudTrail uses the same AWS Region as your S3 bucket.
Confirm that the Event source filter contains s3.amazonaws.com.
Choose another recent S3 management event if the first event references a different bucket.

Still cannot find your bucket? Help me troubleshoot an empty CloudTrail Event history filter for my S3 bucket.

Secret mission

Secret Mission: Recover an Accidental Deletion

Delete compliance-record.txt from your versioned vault. Identify its current delete marker in version history. Remove only that marker to bring the approved record back without a replacement upload.

Clean Up Your Resources

Your small Amazon S3 vault should remain within your Free Plan credits. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Cost warning

The text file storage and requests from this project should remain within your Free Plan credits.

Persistent storage and future requests can create charges after Free Plan coverage ends. Your Billing view shows the current project cost.

Resources you used:

Your private S3 bucket compliance-vault-yourinitials-sixdigits with Bucket Versioning enabled.
Your approved compliance-record.txt object stored in the bucket.
Your local compliance-record.txt file saved through TextEdit.

Your five-minute and 15-minute presigned URLs expire automatically. AWS CloudTrail Event history is available automatically for management events, so it needs no project-specific cleanup.

Keep everything running

No action is needed. Choose this if you want to keep the private vault available for future security and recovery practice.

Keep all four Block Public Access settings enabled.
Keep the default SSE-S3 encryption enabled.
Review Cost by project in Billing before adding more records.
Remove future test records once you no longer need them.

Pause - I'll come back to this later

Emptying the bucket permanently removes every stored object version. A local download protects the approved copy you want to keep.

Switch back to the Amazon S3 console from earlier.
Open compliance-vault-yourinitials-sixdigits.
Select compliance-record.txt.
Choose Download As to save the approved cloud copy locally.
Return to the general purpose buckets list.
Select compliance-vault-yourinitials-sixdigits.
Choose Empty.
Enter permanently delete in the confirmation field.
Finish the emptying process.
Confirm that the bucket no longer contains objects or versions.

Good work. Your bucket keeps its security configuration without storing the test record.

Delete - I don't want to use this again

Deleting the vault is permanent. You empty its stored object versions before removing the bucket itself.

Switch back to the Amazon S3 console from earlier.
Select compliance-vault-yourinitials-sixdigits.
Choose Empty.
Enter permanently delete in the confirmation field.
Finish the emptying process.
Select the empty compliance-vault-yourinitials-sixdigits bucket.
Choose Delete.
Enter your bucket's exact name in the confirmation field.
Choose Delete bucket.
Locate your local compliance-record.txt in the folder where TextEdit saved it.
Delete the local compliance-record.txt using your Mac's file controls.

You should no longer see the bucket in the S3 buckets list. That clears the stored cloud data that could generate future S3 charges.

Nice Work!

You did it! You built a private records vault in AWS that protects a business record through controlled access.

You've learned how to:

Secure an AWS workspace with multi-factor authentication. Confirm Free Plan coverage before storing cloud data.
Build a private Amazon S3 vault for compliance-record.txt. Keep Block Public Access enabled. Share the record through an expiring presigned URL.
Use S3 Versioning to reverse a same-name overwrite. Inspect AWS CloudTrail Event history for bucket-level management evidence.
Secret Mission: Recover an accidentally deleted compliance-record.txt by removing its delete marker. Restore the approved record without re-uploading it.

Ready to quiz yourself?