Build a recoverable document vault

Overview

A campus club stores event documents and occasionally overwrites or deletes a file. Build a private document vault, reproduce both failures with synthetic files, and demonstrate recovery. The deliverable is a working recovery exercise and a short engineering report, not a public file-sharing application.

Architecture

The learner uses an authenticated AWS console session. IAM permissions control access to the private S3 bucket; versioning preserves older object versions. Do not grant anonymous access.

Choose S3 for documents stored as independent objects. Versioning helps recover from accidental overwrites and delete markers, but it is not an isolated backup: a principal allowed to delete versions can permanently remove them. Explain this limitation in your report.

Prerequisites

• An AWS learning account with permission to create and delete a dedicated S3 bucket and manage its objects and versioning.
• Three small synthetic text documents; do not upload student records or real personal information.
• Permission to incur S3 storage and request charges. Use one region and a unique project-only bucket.

Steps

1. Build and test the foundation

Complete the S3 recovery lab. Follow its setup, versioning, and recovery instructions. Save screenshots of the private bucket settings, version IDs, and successful recovery before performing its cleanup.

2. Extend the exercise to an overwrite

Create a fresh dedicated bucket with the same private settings and versioning enabled. Wait 15 minutes after first enabling versioning before writing objects, as recommended by AWS. Upload a text file named event-plan.txt containing Venue: Room A. Edit your local file to contain Venue: Room B and upload it to the same object key.

Open the bucket's Objects tab and enable Show versions. You should see two versions of event-plan.txt. Open or download each version and check its contents. Record which version is current.

3. Restore the earlier content

Download the older version containing Venue: Room A. Upload those downloaded contents as event-plan.txt again. With versioning enabled, this creates a new current version and retains the intervening history. Download the current object and verify that it says Venue: Room A.

4. Compare deletion and permanent deletion

Use a separate disposable object to repeat the delete-marker exercise from the recovery lab. Explain why removing its delete marker restores access. In your report, distinguish this from deleting a specific version, which permanently removes that version. Never test permanent deletion on valuable data.

5. Present your project

Create a repository containing your own architecture diagram, an explanation of IAM access, redacted recovery evidence, and the verification table below. Record a short demonstration explaining the failure and recovery. Do not commit AWS credentials or personal data.

Verification

Explain why versioning alone would not protect against an administrator permanently deleting all versions. Propose one additional production control and discuss its cost or complexity.

Cost and cleanup

S3 charges depend on region, storage volume, requests, and retained versions. This project uses only small files for a short session; do not assume that your account qualifies for free usage.

Empty the dedicated project bucket, including all versions and delete markers, then delete the bucket. Repeat for any separate bucket created during the prerequisite lab. Check the S3 console to verify that each project bucket is gone. Remove only project-specific IAM resources you created; do not delete shared roles or policies.

Review billing after cleanup; usage reporting can lag. Keep your report and redacted evidence locally rather than leaving resources running for a demonstration.

References

• AWS: Using S3 Versioning
• AWS: Enabling versioning and propagation time
• AWS: Working with delete markers
• AWS: Emptying a bucket
• AWS: S3 pricing