Break and Secure an AWS S3 Bucket

Expose, then lock down an S3 bucket using IAM and security best practices.

Introduction

30 Second Summary

Data breaches from misconfigured cloud storage are one of the most common security incidents in the industry. Someone forgets to check a box, and suddenly sensitive files are visible to anyone with a browser.

In this project, you will intentionally expose an S3 bucket to the public internet with harmless dummy data, witness the vulnerability firsthand, then systematically lock it down using the same techniques cloud security engineers use in production.

What You'll Build

A controlled security lab in your own AWS account where you break and fix an S3 bucket's security configuration, then set up audit logging to catch this kind of mistake in the future.

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

  • An S3 bucket secured with all four Block Public Access settings enabled.
  • A custom least-privilege IAM policy scoped to a single bucket, proving you can restrict access to exactly what's needed.
  • Server access logging configured with a dedicated logging bucket for audit trails and future breach detection.
  • Secret Mission: a Python script that scans your entire AWS account for publicly accessible S3 buckets.

Are there any prerequisites?

You need an AWS account to complete this project. If you don't have one yet, you can create a free account at aws.amazon.com. The project uses only free-tier-eligible resources.

Install and Configure the AWS CLI

The AWS CLI is your command-line interface to Amazon Web Services. It lets you manage cloud resources directly from your terminal, without clicking through the console for every action.

In this step, you will install the AWS CLI v2 on your Windows machine and connect it to your AWS account using access keys. This gives you the power to verify and modify security settings from the command line throughout this project.

In this step, get ready to:
  • Install the AWS CLI v2 on your Windows machine.
  • Configure the CLI with your AWS credentials.
  • Verify your credentials are working.
Install the AWS CLI v2

The AWS CLI v2 is the current version of the command-line tool. It supports all modern AWS services and is the version you will use throughout this project.

  • Press the Windows key to open your search bar.
  • Type cmd and press Enter to open Command Prompt.
  • Check if the AWS CLI is already installed by running this command:
aws --version

✔️ I see aws-cli/2.x.x

You already have AWS CLI v2 installed. You should see output similar to:

aws-cli/2.27.41 Python/3.11.6 Windows/10 exe/AMD64 prompt/off

Skip ahead to the next substep to configure your credentials.

ⓧ I see aws-cli/1.x.x

You have an older version of the AWS CLI installed. Version 1 is missing features you need for this project. You will install version 2 alongside it.

  • Download the AWS CLI v2 installer by opening this link in your browser:
  • https://awscli.amazonaws.com/AWSCLIV2.msi
  • Run the downloaded AWSCLIV2.msi file.
  • Follow the installer prompts. Accept the default settings and click Next through each screen until the installation completes.
  • Close your current Command Prompt window and open a new one (the new window picks up the updated PATH).
  • Run aws --version again. You should now see aws-cli/2.x.x in the output.

Still seeing version 1?

Close all Command Prompt windows and open a fresh one. The installer updates your system PATH, but existing windows keep the old PATH until they are restarted.

help me fix my AWS CLI version

ⓧ Command not found

The AWS CLI is not installed on your machine yet. You will see a message like:

'aws' is not recognized as an internal or external command,
operable program or batch file.
  • Download the AWS CLI v2 installer by opening this link in your browser:
  • https://awscli.amazonaws.com/AWSCLIV2.msi
  • Run the downloaded AWSCLIV2.msi file.
  • Follow the installer prompts. Accept the default settings and click Next through each screen until the installation completes.
  • Close your current Command Prompt window and open a new one (the new window picks up the PATH change).
  • Run aws --version again. You should now see output like aws-cli/2.27.41 Python/3.11.6 Windows/10 exe/AMD64 prompt/off.

Still getting command not recognized?

Make sure you opened a brand new Command Prompt window after the install finished. If the issue persists, try restarting your computer so Windows fully refreshes its PATH environment variable.

help me troubleshoot my AWS CLI installation

Configure your AWS credentials

The AWS CLI needs credentials to connect to your AWS account. You will use an Access Key ID and Secret Access Key, which act like a username and password for programmatic access.

Where do I get my access keys?

Access keys are created in the IAM console. If you do not already have a set of access keys, follow these steps to create them.

  • Open the IAM console at https://console.aws.amazon.com/iam/.
  • In the left navigation pane, click Users and select your username.
  • Click the Security credentials tab.
  • Under Access keys, click Create access key.
  • Select Command Line Interface (CLI) as the use case, acknowledge the recommendation, and click Next.
  • Click Create access key. Copy both the Access Key ID and Secret Access Key immediately. You will not be able to see the Secret Access Key again after you leave this page.
  • Back in your Command Prompt, start the configuration wizard by running this command:
aws configure

The CLI will prompt you for four values. Enter them one at a time:

  • For AWS Access Key ID: paste your Access Key ID.
  • For AWS Secret Access Key: paste your Secret Access Key.
  • For Default region name: type us-east-1.
  • For Default output format: type json.

What do these fields mean?

The Access Key ID and Secret Access Key authenticate your CLI to your AWS account. They prove that commands you run are authorized.

The default region tells AWS which data center to use when you do not specify one. The output format controls how results are displayed in your terminal.

Keep your Secret Access Key private

Never share your Secret Access Key or commit it to version control. Treat it like a password. If you suspect it has been exposed, delete the key immediately in the IAM console and create a new one.

Verify your credentials

Now that the CLI is configured, you need to confirm it can actually reach your AWS account. A quick identity check will prove the connection is working.

  • Verify your credentials are working by running this command:
aws sts get-caller-identity

You should see a JSON response containing three fields: your UserId, your Account number (12 digits), and your Arn.

{
    "UserId": "AIDASAMPLEUSERID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/YourUserName"
}

What does this output mean?

This command asks AWS "who am I?" and returns the identity tied to your access keys. The Account field is your 12-digit AWS account ID. The Arn is the full Amazon Resource Name for your IAM user.

If you see these three fields, your CLI is authenticated and ready to go.

Seeing an error instead?

If you see a message about invalid credentials or expired tokens, double-check that you pasted the Access Key ID and Secret Access Key correctly during aws configure. Run aws configure again to re-enter them.

If you see a connection timeout, check your internet connection and ensure no firewall is blocking outbound HTTPS traffic.

help me fix my AWS CLI credentials

Your CLI is installed, configured, and authenticated. Next up, you will create an S3 bucket and intentionally expose it to the public to see firsthand how security misconfigurations lead to data breaches.

Create a Bucket and Expose It to the Public

Your AWS CLI is configured and ready. Now it's time to step into the shoes of someone who accidentally creates a major security vulnerability.

In this step, you'll create an S3 bucket and deliberately expose it to the public internet. You'll see firsthand how a single misconfiguration makes private data readable by anyone in the world.

In this step, get ready to:
  • Create an S3 bucket with Block Public Access disabled.
  • Upload a dummy sensitive file and apply a public read bucket policy.
  • Verify that anyone can access your file without authentication.
Create a bucket and upload a dummy file

Every object in S3 lives inside a bucket. You'll create one now and deliberately turn off the safety feature that prevents public access.

  • Switch to the AWS Management Console in your browser.
  • In the search bar at the top, type S3 and select S3 from the results.
  • In the left navigation pane, click General purpose buckets.
  • Click Create bucket.
  • In the Bucket name field, enter a unique name like yourname-security-lab (replace "yourname" with your actual name, all lowercase).
  • Scroll down to the Block Public Access settings for this bucket section.
  • Uncheck Block all public access.
  • Check the acknowledgment box that appears below, confirming you understand this bucket can become public.
  • Scroll to the bottom and click Create bucket.

What is Block Public Access?

Block Public Access is a safety feature that prevents S3 buckets from being exposed to the internet. AWS enables it by default on all new buckets since April 2023.

It has four individual settings: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets. By unchecking the main checkbox, you disable all four at once.

Now you need a file to upload. You'll create a dummy file that simulates sensitive data.

  • Switch back to your Command Prompt.
  • Create a dummy sensitive file on your Desktop by running these commands:
cd %UserProfile%\Desktop
echo FAKE_API_KEY=abc123 > sensitive-data.txt
  • Confirm the file exists by running:
dir sensitive-data.txt

You should see sensitive-data.txt listed in the output.

  • Switch back to the S3 Console in your browser.
  • Click on your bucket name to open it.
  • On the Objects tab, click Upload.
  • Click Add files.
  • Navigate to your Desktop, select sensitive-data.txt, and click Open.
  • Click Upload.

You should see a success message. Click Close to return to your bucket.

Don't see your bucket?

Make sure the region displayed in the top navigation bar matches the region you selected during bucket creation (e.g. us-east-1). S3 buckets only appear in the region where they were created.

help me find my S3 bucket in the console

Add a public read bucket policy

Your bucket exists but it's still not truly public. You need to add a bucket policy that explicitly grants read access to everyone on the internet.

  • In your bucket, click the Permissions tab.
  • Scroll down to Bucket policy and click Edit.
  • Paste the following policy into the editor:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::[[BUCKET_NAME="yourname-security-lab"]]/*"
            ]
        }
    ]
}

What does this policy do?

This is a standard IAM policy document. Here's what each field means:

  • "Principal": "*" means anyone in the world, authenticated or not.
  • "Action": ["s3:GetObject"] allows downloading any object in the bucket.
  • "Resource" points to every object inside your specific bucket (the /* at the end means all objects).

Together, this grants unauthenticated read access to every file in your bucket.

  • Make sure you replace the bucket name in the Resource field with your actual bucket name.
  • Click Save changes.

This policy is intentionally dangerous

You're applying the exact misconfiguration that has caused major data breaches in the real world. This is safe because your bucket only contains fake data and you'll lock it down in the next step.

Seeing a "Policy has invalid resource" error?

Confirm that the bucket name in the Resource field matches your actual bucket name exactly. The format must be arn:aws:s3:::your-bucket-name/* with no typos.

If you see an error about Block Public Access preventing the policy, go back to the Permissions tab, scroll to Block public access (bucket settings), click Edit, and uncheck Block all public access.

help me fix my S3 bucket policy error

Verify the exposure in your browser

Time to prove this misconfiguration is real. You'll access your "sensitive" file as an unauthenticated user.

  • Open a new browser tab.
  • Navigate to the following URL (replace the bucket name with yours):
https://[[BUCKET_NAME="yourname-security-lab"]].s3.amazonaws.com/sensitive-data.txt

You should see the text FAKE_API_KEY=abc123 displayed directly in your browser. No login, no authentication required.

Why this matters

This is exactly how real data breaches happen. A developer or admin accidentally leaves a bucket public with real credentials, customer data, or proprietary information inside. Anyone who guesses or discovers the URL can read everything.

The Capital One breach exposed over 100 million customer records through a misconfigured S3 bucket. You just recreated that same misconfiguration in a safe, controlled environment.

Seeing Access Denied instead?

Make sure you saved the bucket policy without errors. Return to your bucket's Permissions tab and confirm the policy is visible under Bucket policy.

Double check that the bucket name in the URL matches your actual bucket name exactly (all lowercase, with hyphens).

Confirm you unchecked Block all public access during bucket creation. If it's still enabled, the policy won't take effect.

help me troubleshoot why my S3 file isn't publicly accessible

You've just witnessed firsthand how a single misconfiguration exposes data to the entire internet. In the next step, you'll lock this bucket down using the same techniques cloud security engineers use in production.

Lock Down the Bucket

You just proved that a single misconfigured bucket policy can expose sensitive data to anyone with a browser. That is the exact pattern behind most real-world S3 data breaches.

Now it is time to fix the damage. You will enable S3 Block Public Access, which acts as a master override that blocks all public access to a bucket regardless of individual policies or ACLs.

In this step, get ready to:
  • Enable all four Block Public Access settings on your bucket.
  • Verify the bucket is no longer publicly accessible from your browser.
  • Confirm the settings from the AWS CLI.
Enable Block Public Access in the S3 Console

Block Public Access is an account-level and bucket-level safety mechanism with four settings that override any policies or ACLs that would otherwise allow public access.

  • Return to the S3 Console in your browser.
  • Click on your bucket name (yourname-security-lab).
  • Click the Permissions tab.
  • Scroll down to Block public access (bucket settings).
  • Click Edit.
  • Check the Block all public access checkbox.
  • Click Save changes.
  • Type confirm in the confirmation dialog and click Confirm.

What are the four settings?

Checking Block all public access enables all four of these settings at once:

  • BlockPublicAcls prevents new public ACLs from being applied.
  • IgnorePublicAcls ignores any existing public ACLs on the bucket.
  • BlockPublicPolicy rejects new bucket policies that grant public access.
  • RestrictPublicBuckets restricts access to a bucket with a public policy to only AWS service principals and authorized users.
Verify the lockdown and delete the bucket policy

With Block Public Access enabled, your file should now be unreachable from the internet.

  • Switch back to the browser tab where you viewed sensitive-data.txt in the previous step.
  • Refresh the page.

You should now see an Access Denied XML error instead of your file contents. The bucket is no longer publicly accessible.

The overly-permissive bucket policy from Step 2 is now dead weight. Let's clean it up.

  • Switch back to the S3 Console tab.
  • Make sure you are still on the Permissions tab of your bucket.
  • Scroll down to Bucket policy.
  • Click Delete.
  • Type delete in the confirmation dialog and click Delete to confirm.

Why delete the policy if Block Public Access already stops it?

Block Public Access overrides the policy, but the policy is still sitting there. If someone later disables Block Public Access for a legitimate reason, the old public-read policy would immediately re-expose your data. Deleting it removes that risk entirely.

Still seeing your file contents in the browser?

Make sure you saved the Block Public Access changes and typed confirm in the dialog. Check for a green success banner at the top of the S3 Console.

If you still see the file, try a hard refresh (Ctrl+Shift+R on Windows) to clear your browser cache.

help me troubleshoot why my S3 bucket is still publicly accessible after enabling Block Public Access

Confirm the block settings from the CLI

The console shows the settings visually, but the CLI gives you a definitive programmatic check that you can script and automate.

  • Verify that all four Block Public Access settings are active by running this command in your Command Prompt:
aws s3api get-public-access-block --bucket [[BUCKET_NAME="yourname-security-lab"]]

You should see output like this, with all four fields set to true:

{
    "PublicAccessBlockConfiguration": {
        "BlockPublicAcls": true,
        "IgnorePublicAcls": true,
        "BlockPublicPolicy": true,
        "RestrictPublicBuckets": true
    }
}

What does this output tell you?

Each field maps to one of the four protections you just enabled. When all four are true, nothing can make this bucket public through ACLs or bucket policies. This is the gold standard configuration for any S3 bucket that should not be publicly accessible.

Seeing an access denied error from the CLI?

Make sure your bucket name is spelled exactly as it appears in the S3 Console. Bucket names are case-sensitive and globally unique.

If you see a credentials error, verify your CLI is configured by running aws sts get-caller-identity. If that fails, re-run aws configure with your access keys.

help me fix an access denied error when running aws s3api get-public-access-block

Your bucket is locked down. No one can access your data from the public internet anymore. Next up, you will apply a least-privilege IAM policy so that only the right people can access the bucket through the right channels.

Apply a Least-Privilege IAM Policy

Your bucket is now locked to the public. But your own AWS account still has full administrator access to every object in it.

In real environments, not every team member needs full access. The Principle of Least Privilege says each user should only get the exact permissions they need. In this step, you will create a restricted IAM user that can read your bucket but cannot delete anything from it.

In this step, get ready to:
  • Create a custom IAM policy scoped to your single bucket.
  • Create an IAM user with only read access.
  • Test that the user can list objects but cannot delete them.
Create a custom IAM policy

An IAM policy is a JSON document that defines exactly which AWS actions are allowed on which resources. You will write one that permits only reading from your specific bucket.

  • In the AWS Management Console, search for IAM in the top search bar and open the IAM service.
  • In the left navigation pane, choose Policies.
  • Choose Create policy.
  • In the Policy editor section, choose the JSON option.
  • Delete any placeholder text in the editor and paste the following policy:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::[[BUCKET_NAME="yourname-security-lab"]]/*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::[[BUCKET_NAME="yourname-security-lab"]]"
        }
    ]
}

What does this policy do?

This policy has two statements, each granting one specific permission:

  • s3:GetObject allows downloading objects from the bucket. The /* at the end of the Resource means all objects inside the bucket.
  • s3:ListBucket allows listing the bucket contents. The Resource points to the bucket itself (no /*).

Anything not explicitly listed here (like deleting or uploading) is denied by default. That is least privilege in action.

  • Choose Next.
  • On the Review and create page, type S3ReadOnlySecurityLab in the Policy name field.
  • Choose Create policy.

You should see a green banner confirming your policy was created successfully.

Seeing a validation error?

  • Make sure you replaced the bucket name placeholder with your actual bucket name (the same one you created in Step 2).
  • Check that the JSON has matching braces and brackets. A missing comma between the two Statement objects is a common mistake.
  • Verify you selected the JSON option, not the Visual editor.

Help me fix my IAM policy JSON

Create an IAM user and configure a CLI profile

Now you will create a separate IAM user that only has the restricted policy. This simulates a team member with limited access.

  • In the IAM console left navigation pane, choose Users.
  • Choose Create user.
  • For User name, type security-lab-reader.
  • Do not enable console access. Choose Next.
  • On the Set permissions page, choose Attach policies directly.
  • In the search box, type S3ReadOnlySecurityLab and select the checkbox next to it.
  • Choose Next, then choose Create user.

Now you need to generate access keys so this user can authenticate via the CLI.

  • Click on the user name security-lab-reader to open the user details page.
  • Select the Security credentials tab.
  • Under Access keys, choose Create access key.
  • On the Access key best practices & alternatives page, select Command Line Interface (CLI) as the use case.
  • Check the confirmation box at the bottom, then choose Next.
  • Choose Create access key.
  • Copy the Access key ID and Secret access key to a safe place. You will not be able to see the secret key again after leaving this page.

Why create access keys?

Access keys let the AWS CLI authenticate as a specific IAM user. Each key pair (Access Key ID + Secret Access Key) acts like a username and password for programmatic access.

You will configure a named CLI profile that uses these keys, so you can switch between your admin account and this restricted user.

  • Configure a second CLI profile by running this command:
aws configure --profile security-lab-reader
  • When prompted, enter the Access Key ID you just copied.
  • Enter the Secret Access Key you just copied.
  • Enter us-east-1 for the default region.
  • Enter json for the default output format.

What is a CLI profile?

A CLI profile stores a set of credentials under a name. When you add --profile security-lab-reader to any AWS CLI command, it uses the restricted user's credentials instead of your default admin credentials.

Command not recognized?

  • Make sure you opened a new Command Prompt window after installing the AWS CLI in Step 1.
  • Run aws --version to confirm the CLI is installed.

Help me configure my AWS CLI profile

Test the restricted access

Time to prove that your policy actually works. You will run two commands as the restricted user. One should succeed and one should fail.

  • List the bucket contents as the restricted user by running this command:
aws s3 ls s3://[[BUCKET_NAME="yourname-security-lab"]] --profile security-lab-reader

You should see sensitive-data.txt listed in the output. This confirms the s3:ListBucket permission works.

  • Now try to delete a file as the restricted user by running this command:
aws s3 rm s3://[[BUCKET_NAME="yourname-security-lab"]]/sensitive-data.txt --profile security-lab-reader

This command should fail with an Access Denied error. Your policy only allows reading, not deleting.

Why does the delete fail?

The S3ReadOnlySecurityLab policy only grants s3:GetObject and s3:ListBucket. The delete operation requires s3:DeleteObject, which is not in the policy.

In IAM, any action not explicitly allowed is denied by default. This is how least privilege prevents accidental or malicious data loss.

List command also failing?

  • Double-check that you typed the bucket name correctly in the command.
  • Verify you attached the S3ReadOnlySecurityLab policy to the security-lab-reader user. In the IAM console, click the user name and check the Permissions tab.
  • Make sure the bucket name in your policy matches your actual bucket name exactly.

Help me fix my least-privilege test

You have just proven that least privilege works. Your restricted user can see what is in the bucket but cannot modify or delete anything. Next up, you will add server access logging so you can detect and audit any future access attempts.

Enable Server Access Logging

In the last step, you proved that least-privilege access control works. Your bucket is locked down and only specific actions are allowed through a scoped IAM policy.

Locking a bucket down is only half the story. If someone tries to access your data (or if your future self accidentally misconfigures something), you need a record of what happened. That is what server access logging provides. In this step, you will configure your bucket to record every request made against it into a separate logging bucket.

In this step, get ready to:
  • Create a dedicated logging bucket to receive access logs.
  • Enable server access logging on your main bucket.
  • Verify the logging configuration via the AWS CLI.
Create a dedicated logging bucket

Access logs need a destination. You will create a second S3 bucket dedicated to storing log files from your main bucket. This keeps your logs separate from your application data.

  • Return to the S3 Console.
  • In the left navigation pane, click General purpose buckets.
  • Click Create bucket.
  • For Bucket name, enter yourname-security-lab-logs (replace yourname with the same name you used for your first bucket).
  • Leave all other settings at their defaults. This means Block all public access stays checked.
  • Click Create bucket.

Why a separate bucket for logs?

Storing logs in a separate bucket keeps your application data clean and makes it easier to apply different retention policies or access controls to log files.

It also prevents a situation where logging activity generates more logs in an infinite loop.

You should see your new log bucket appear in the bucket list alongside your original yourname-security-lab bucket.

Bucket name already taken?

S3 bucket names must be globally unique. If the name is taken, try adding a number or extra word (e.g., yourname-security-lab-logs-01). Just remember the name you chose for the next substep.

Help me troubleshoot my S3 logging bucket creation error

Enable server access logging on your main bucket

Now that your log bucket exists, you will tell S3 to start writing access logs from your main bucket into it.

  • In the S3 Console bucket list, click on your main bucket name (yourname-security-lab).
  • Click the Properties tab.
  • Scroll down to the Server access logging section.
  • Click Edit.
  • Select Enable.
  • For the Target bucket field, choose your log bucket (yourname-security-lab-logs).
  • For Target prefix, enter access-logs/.
  • Click Save changes.

What does the console do behind the scenes?

When you enable logging through the console, AWS automatically updates the log bucket's policy to grant s3:PutObject permission to the logging service principal (logging.s3.amazonaws.com). You do not need to add this policy manually.

The access-logs/ prefix organizes all log files under a specific folder-like path inside the log bucket, making them easy to find.

Don't see your log bucket in the dropdown?

The destination bucket must be in the same AWS Region as the source bucket. Make sure you created both buckets in the same region (e.g., us-east-1).

Help me figure out why my logging bucket is not showing up

Verify the logging configuration from the CLI

Logs can take up to a couple of hours to appear in the destination bucket. Instead of waiting, you can verify the logging configuration is active right now using the CLI.

  • Generate a log entry by listing your bucket contents with this command:
aws s3 ls s3://[[BUCKET_NAME="yourname-security-lab"]]
  • Verify the logging configuration is in place by running:
aws s3api get-bucket-logging --bucket [[BUCKET_NAME="yourname-security-lab"]]

You should see JSON output showing your logging configuration with the TargetBucket and TargetPrefix fields:

{
    "LoggingEnabled": {
        "TargetBucket": "yourname-security-lab-logs",
        "TargetPrefix": "access-logs/"
    }
}

When will actual logs appear?

S3 server access logs are delivered on a best-effort basis. It can take up to a couple of hours for log files to appear in your log bucket. The important thing is that the configuration is active. Every request to your bucket from this point forward is being recorded.

Seeing an empty response?

If you see an empty JSON object ({}) or no LoggingEnabled field, the logging was not saved correctly. Go back to the S3 Console, open your main bucket's Properties tab, and check the Server access logging section to confirm it shows as enabled.

Help me troubleshoot my empty get-bucket-logging response

Your bucket now has a complete audit trail. Every request made against it is being logged. Next up, you will take on a bonus challenge to build an automated scanner that checks for public bucket misconfigurations across your entire AWS account.

Secret mission

Build a Python S3 Security Scanner

Cloud security engineers don't manually check every bucket in an AWS account. They write automated scanners that do it for them. In this mission, you'll build a Python script that audits your entire account for public S3 buckets.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses minimal S3 storage (a few kilobytes) and a single IAM user, so ongoing costs are effectively $0.

Resources you used:

  • S3 bucket: yourname-security-lab (contains sensitive-data.txt).
  • S3 bucket: yourname-security-lab-logs (receives access logs).
  • IAM user: security-lab-reader (with access keys).
  • IAM policy: S3ReadOnlySecurityLab.
  • AWS CLI profile: security-lab-reader (stored in %UserProfile%\.aws\credentials).
  • Local files: s3_scanner.py and the Python virtual environment (Secret Mission only).

Keep everything running

No action needed. Choose this if you are still actively building or want to keep this lab as a reference for future cloud security work.

  • Your two S3 buckets store only a few kilobytes of data. Storage costs will be fractions of a penny per month.
  • The IAM user security-lab-reader has read-only access to a single bucket. As a best practice, deactivate its access keys in the IAM Console if you are not actively using them.
  • The AWS CLI and Python remain installed on your machine, ready for future projects.

Pause - I'll come back to this later

Deactivate the IAM access keys to reduce your security surface while keeping all resources in place.

  • Open the IAM Console and select Users in the left navigation pane.
  • Select security-lab-reader.
  • Go to the Security credentials tab.
  • Under Access keys, choose the Actions dropdown next to the active key, then select Deactivate.
  • Your S3 buckets, IAM user, and local files remain untouched and ready when you return.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each group below in order.

Delete both S3 buckets
  • Open Command Prompt and delete the main bucket (this empties and removes it in one step) by running:
aws s3 rb s3://[[BUCKET_NAME="yourname-security-lab"]] --force
  • Delete the logging bucket by running:
aws s3 rb s3://[[LOGS_BUCKET_NAME="yourname-security-lab-logs"]] --force
Delete the IAM user and policy
  • Open the IAM Console at https://console.aws.amazon.com/iam/.
  • In the left navigation pane, select Users.
  • Select security-lab-reader to open the user details page.
  • Go to the Security credentials tab. Under Access keys, choose Actions and then Deactivate. Confirm in the dialog.
  • Return to the Users list. Select the checkbox next to security-lab-reader, then choose Delete at the top of the page.
  • Type the user name to confirm, then choose Delete.
  • In the left navigation pane, select Policies.
  • Search for S3ReadOnlySecurityLab and select the radio button next to it.
  • Choose Actions, then Delete. Type the policy name to confirm and choose Delete.
Remove the CLI profile
  • Open the file %UserProfile%\.aws\credentials in a text editor (e.g. Notepad).
  • Find the [security-lab-reader] section and delete it along with the aws_access_key_id and aws_secret_access_key lines beneath it.
  • Save and close the file.
  • Repeat for %UserProfile%\.aws\config if it contains a [profile security-lab-reader] section.
Delete local files (Secret Mission only)
  • If you completed the Secret Mission, delete the Python virtual environment folder and the scanner script.
  • In Command Prompt, navigate to the folder containing s3_scanner.py and run:
rmdir /s /q venv
del s3_scanner.py

Nice Work!

Nice Work!

You've just built a hands-on security lab that demonstrates how S3 misconfigurations happen and how to systematically prevent them.

You've learned how to:

  • Exposed an S3 bucket to the public internet, witnessed the data breach firsthand, then locked it down using all four Block Public Access settings.
  • Applied a least-privilege IAM policy scoped to a single bucket, proving the Principle of Least Privilege in action.
  • Enabled server access logging to create an audit trail for detecting future unauthorized access.
  • Secret Mission: Built a Python security scanner that audits your entire AWS account for public S3 buckets.

Ready to quiz yourself?