IAM, CLI, and S3 Static Website
Set up IAM, configure the AWS CLI, and deploy a static website on S3.
Introduction
30 Second Summary
Every time you visit a website, stream a video, or check your email, you are relying on cloud infrastructure that someone set up and secured. The difference between a professional cloud setup and a risky one comes down to who has access, how they prove their identity, and what they are allowed to do.
In this project, you will secure an AWS account from scratch by creating a dedicated user with limited permissions, connect your terminal to AWS, and deploy a live website that anyone can visit in their browser.
What You'll Build
A fully secured AWS environment with identity management, command-line access, and a static website hosted on S3.
By the end of this project, you'll have:
- An IAM user with a custom policy granting only S3 permissions, following the principle of least privilege.
- A configured AWS CLI profile connected to your IAM user, ready to manage resources from your terminal.
- A live static website hosted on Amazon S3 that you can open in any browser.
- Secret Mission: Deploy an updated multi-page website entirely from the CLI without touching the AWS Console.
Are there any prerequisites?
You need an AWS account (Free Tier), Node.js installed on your machine, and Cursor installed. If you created your AWS account after July 15, 2025, you have up to $200 in free credits to cover everything in this project.
Install the AWS CLI
The AWS CLI is your direct line to AWS services from the terminal. Instead of clicking through the AWS Management Console for every action, the CLI lets you type commands that create, manage, and monitor resources in seconds.
In this step, you will install the AWS CLI v2 on your Windows machine and confirm it works in your Cursor terminal.
In this step, get ready to:
- Install the AWS CLI v2 using the official MSI installer.
- Verify the installation in a standard command prompt.
- Confirm the CLI runs in your Cursor terminal.
Download and install the AWS CLI v2 for Windows
The AWS CLI v2 installer is a standard Windows MSI package hosted by AWS. You will download it, run the installer, then verify that the aws command is available in your terminal.
- Open your web browser and navigate to the AWS CLI installer URL:
- https://awscli.amazonaws.com/AWSCLIV2.msi
- The download starts automatically. Once it finishes, double-click the downloaded AWSCLIV2.msi file to launch the installer.
- Windows will ask for admin permission to install the software. Click Yes to allow it.
- Follow the on-screen prompts and accept the defaults on each screen. Click Next through the wizard, then click Install.
- Once the installer finishes, click Finish to close it.
Why a NEW command prompt?
The installer adds the aws command to your system PATH. Any command prompt that was already open before the install will not pick up the new PATH. You need to open a fresh one.
- Open a new Command Prompt by pressing the Windows key, typing cmd, and pressing Enter.
- Verify the installation by running this command:
aws --version
Check what your terminal shows and pick the matching tab below.
✔️ I see aws-cli/2.x.x
Your output looks something like this:
aws-cli/2.27.41 Python/3.11.6 Windows/10 exe/AMD64 prompt/off
The exact version numbers may differ. As long as the output starts with aws-cli/2. you are good to go.
ⓧ I see aws-cli/1.x.x
You have an older version (v1) of the AWS CLI installed. The v2 MSI installer should have replaced it, but your system may still be finding the old version first.
- Close the Command Prompt.
- Open Programs and Features from the Control Panel.
- Find any entry named AWS Command Line Interface with version 1.x and click Uninstall.
- Re-run the AWSCLIV2.msi installer you downloaded earlier.
- Open a brand new Command Prompt and run aws --version again. You should now see aws-cli/2. at the start.
ⓧ 'aws' is not recognized
This means your system cannot find the aws command. The most common cause is using a Command Prompt that was open before the install.
- Close the current Command Prompt completely.
- Press the Windows key, type cmd, and press Enter to open a fresh one.
- Run aws --version again.
If it still does not work, the installer may not have completed successfully. Re-run the AWSCLIV2.msi file and follow the prompts again, then open a new Command Prompt and retry.
Understand what you just installed
What is the AWS CLI?
The AWS CLI lets you control AWS services from your terminal instead of clicking through the console. Every action you can perform in the AWS Management Console has an equivalent CLI command.
In production, engineers use the CLI and scripts rather than the console because commands are repeatable, scriptable, and faster. You can paste a command into a script and run it a thousand times without clicking a single button.
Verify your Cursor terminal works with the CLI
You will run all future commands from inside Cursor. Confirming the CLI works there now saves you from surprises later.
- Press the Windows key, type Cursor, and press Enter to open Cursor.
- Open a new terminal inside Cursor by pressing Ctrl+` (that is the backtick key, usually above Tab).
- Confirm the CLI works in Cursor by running this command:
aws --version
You should see the same aws-cli/2.x.x output you saw in the standard Command Prompt.
Not seeing the version in Cursor?
- Make sure you opened Cursor after the CLI installation finished. If Cursor was already open, close it completely and reopen it so it picks up the updated PATH.
- Check that the terminal in Cursor is set to Command Prompt or PowerShell (not Git Bash). Click the dropdown arrow next to the + icon in the terminal panel to switch.
Help me troubleshoot why aws --version is not working in my Cursor terminal
Your CLI is installed and ready. Next up, you will use it to create a secure IAM user with carefully scoped permissions.
Create an IAM User with Least-Privilege Permissions
Your AWS CLI is installed and ready to go. Now you need to give it credentials so it can authenticate with your AWS account.
Right now, the only way into your account is through the root user. The root user has unlimited power over everything, including billing and account deletion. In this step, you will create a separate IAM user with carefully scoped permissions specifically for CLI access.
In this step, get ready to:
- Understand why root user access is dangerous for daily use.
- Create a custom IAM policy that only allows S3 actions.
- Create an IAM user and generate access keys for CLI authentication.
Understand root user vs IAM user
Every AWS account starts with a single root user. This root user has complete, unrestricted access to every service and every setting in your account. That makes it extremely risky for daily work.
- Open your browser and navigate to https://console.aws.amazon.com/.
- Sign in with your root user credentials (the email and password you used when you created your AWS account).
Why not just use the root user for everything?
AWS best practice is to never use the root user for daily tasks. If your root credentials were ever leaked, an attacker could delete your entire account, spin up expensive resources, or access billing information.
Instead, you create IAM users with only the specific permissions they need. This is called least privilege. If that user's credentials are compromised, the blast radius is limited to only what the policy allows.
- In the search bar at the top of the AWS Console, type IAM.
- Click on IAM in the search results to open the IAM console.
What is IAM?
IAM stands for Identity and Access Management. It is the AWS service that controls who can do what in your account. You use it to create users, groups, and policies that define permissions.
Create a custom IAM policy for S3 access
Before creating a user, you need to define what that user is allowed to do. In AWS, permissions are defined in documents called policies. You will create a policy that grants full access to S3 but nothing else.
- In the IAM console left panel, click Policies.
- Click Create policy.
- At the top of the policy editor, click the JSON tab to switch to the JSON editor.
- Delete any existing content in the editor and paste the following policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3FullAccess",
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
]
}
What does this policy do?
- Version tells AWS which policy language version to use. 2012-10-17 is the latest version.
- Action: s3:* means "allow every S3 action" (creating buckets, uploading files, deleting objects, etc.).
- Resource: * means these actions apply to all S3 resources.
- This policy allows all S3 actions but nothing else. No EC2, no billing, no IAM changes.
- Click Next.
- In the Policy name field, enter NextWorkS3FullAccess.
- In the Description field, enter Grants full access to S3 for the NextWork learning project.
- Click Create policy.
You should see a green success banner confirming that the policy NextWorkS3FullAccess has been created.
Don't see the success banner?
- If you see a JSON syntax error, double-check that every brace, bracket, and comma matches the code block above exactly.
- Make sure you are in the JSON tab, not the Visual editor.
- help me fix a JSON syntax error in my IAM policy
Create an IAM user and attach the policy
Now you will create the IAM user that your AWS CLI will authenticate as. This user will have no console access. Its only purpose is to run CLI commands with the permissions you just defined.
- In the IAM console left panel, click Users.
- Click Create user.
- In the User name field, enter nextwork-cli-user.
- Do NOT check the Provide user access to the AWS Management Console checkbox. This user is for CLI only.
- Click Next.
- Select Attach policies directly.
- In the search box, type NextWorkS3FullAccess.
- Check the box next to NextWorkS3FullAccess.
- Click Next.
- Click Create user.
Your user is created. Now you need to generate access keys so the AWS CLI can authenticate as this user.
- Click on nextwork-cli-user in the Users list to open the user's detail page.
- Click the Security credentials tab.
- Scroll down to the Access keys section.
- Click Create access key.
- Select Command Line Interface (CLI) as the use case.
- Check the confirmation checkbox at the bottom of the page.
- Click Next.
- Click Create access key.
Save both keys right now
You will see your Access key ID and Secret access key on this page. Copy both values and save them somewhere safe (a password manager, a secure note, or a text file only you can access).
You will never be able to see the secret access key again after you leave this page. If you lose it, you will need to delete the key and create a new one.
- Copy the Access key ID and paste it into a secure location.
- Copy the Secret access key and paste it into the same secure location.
- Click Done.
What just happened?
You created an IAM user called nextwork-cli-user that can only perform S3 actions. It cannot access the AWS Console, modify billing, launch EC2 instances, or change IAM settings.
The access key pair (Access Key ID + Secret Access Key) works like a username and password for the CLI. In the next step, you will feed these credentials to the aws configure command.
Accidentally closed the page without saving your keys?
- Go back to the Security credentials tab of your nextwork-cli-user.
- Under Access keys, click Actions and then Delete on the existing key.
- Click Create access key again and save both values this time.
- help me regenerate my IAM access keys
Your IAM user is locked and loaded with the right permissions. Next up, you will connect the AWS CLI to this user so every command you run authenticates as nextwork-cli-user instead of root.
Configure the AWS CLI
You now have an IAM user with its own access keys. The next step is connecting your AWS CLI to that user so every command you run authenticates with the right permissions.
Without this configuration, the CLI has no idea who you are. Running aws configure stores your credentials locally so the CLI can sign requests on your behalf.
In this step, get ready to:
- Configure the AWS CLI with your IAM user credentials.
- Test the CLI connection by listing S3 buckets.
- Understand how the CLI authenticates every command you run.
Run the configure command
The aws configure command walks you through four prompts. It saves your answers into two files on your machine so the CLI can authenticate automatically every time you run a command.
- Switch back to your Cursor terminal and run the configure command:
aws configure
- The CLI will ask you four questions one at a time. Enter the following values when prompted:
- AWS Access Key ID: paste the access key ID you saved in the previous step.
- AWS Secret Access Key: paste the secret access key you saved in the previous step.
- Default region name: type us-east-1 and press Enter.
- Default output format: type json and press Enter.
What does this command do?
The aws configure command creates two files in your %UserProfile%\.aws\ folder.
- credentials stores your Access Key ID and Secret Access Key.
- config stores your default region and output format.
Every future aws command reads these files automatically. You will not need to paste your keys again.
Your secret key is shown in plain text
The terminal displays your Secret Access Key as you type or paste it. Do not screenshot your terminal right now. Make sure nobody is looking over your shoulder or screen-sharing while you enter credentials.
Test your CLI connection
The fastest way to confirm everything is working is to run a simple S3 command. Since you have not created any buckets yet, a successful response is simply no output at all.
- Verify your CLI is connected by running this command:
aws s3 ls
What should I see?
If the command returns with no output and no error, your CLI is connected. An empty result means you have no S3 buckets yet, which is expected at this point.
If you see an error message, something went wrong with the configuration. Check the troubleshooting callout below.
Seeing an error after running aws s3 ls?
- If you see Unable to locate credentials: the aws configure step did not save properly. Run aws configure again and re-enter all four values.
- If you see Access Denied: double-check that you pasted the correct Access Key ID and Secret Access Key from the previous step. A single extra space or missing character will cause this.
- If you closed and reopened your terminal between steps, the credentials file should still be there. Run aws configure one more time to re-enter them.
Help me troubleshoot my AWS CLI connection error
Understand what just happened
How does the CLI know who you are?
Every aws command you run now authenticates as your nextwork-cli-user IAM user. It is NOT running as root.
This means the CLI can only do what your NextWorkS3FullAccess policy allows. S3 commands work. If you tried something like aws ec2 describe-instances, it would fail with an Access Denied error because your policy does not grant EC2 permissions.
This is the principle of least privilege in action. Your user can only touch the services it needs.
Your CLI is now securely connected to AWS. Next up, you will create an S3 bucket and deploy a real website to it.
Create an S3 Bucket and Upload Your Website
Your CLI is connected and every command now authenticates as your nextwork-cli-user IAM user. That means you can only perform S3 actions, nothing else.
Now let's put those permissions to work. In this step, you'll create an S3 bucket (a container for files in the cloud), write a simple HTML page, and upload it to your bucket using the CLI.
In this step, get ready to:
- Create a local HTML page for your website.
- Create an S3 bucket using the AWS CLI.
- Upload your HTML file to the bucket.
Create a simple HTML page
Before you can host a website on S3, you need something to host. You'll create a simple HTML page that displays a greeting and the skills you've learned so far.
- In your Cursor terminal, move to your Desktop by running this command:
cd ~/Desktop
- Create your project folder and move into it by running these commands:
mkdir aws-project
cd aws-project
- Open this folder in Cursor so your files and terminal are in the same place.
- Click File in the top menu bar.
- Click Open Folder.
- Navigate to your Desktop, select the aws-project folder, then click Select Folder.
- If Cursor asks whether you trust the authors, click Yes, I trust the authors.
- Create a new file by pressing Ctrl+N (Windows) or Cmd+N (macOS).
- Save it immediately with Ctrl+S (Windows) or Cmd+S (macOS) and name it index.html.
- Paste the following HTML into index.html:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>My First AWS Website</title>
<style>
body {
font-family: Arial, sans-serif;
max-width: 800px;
margin: 50px auto;
padding: 20px;
background-color: #f0f8ff;
text-align: center;
}
h1 { color: #232f3e; }
p { color: #555; font-size: 1.2em; }
.highlight { color: #ff9900; font-weight: bold; }
</style>
</head>
<body>
<h1>Hello from AWS S3!</h1>
<p>This website is hosted on <span class="highlight">Amazon S3</span>.</p>
<p>I deployed it using the AWS CLI from my terminal.</p>
<p>Skills learned: IAM, AWS CLI, S3 Static Hosting</p>
</body>
</html>
What does this code do?
This is a standard HTML page with some inline CSS styling. Here's what each section does:
- The <style> block sets a centered layout with a maximum width of 800px, a light blue background, and clean typography.
- The <body> contains a heading, three paragraphs of text, and a highlighted span that will appear in orange to call out "Amazon S3".
- The .highlight class applies AWS's signature orange color to make the S3 mention stand out.
- Save index.html with Ctrl+S (Windows) or Cmd+S (macOS).
- Confirm the file exists by running this in your Cursor terminal:
ls
You should see index.html listed in the output.
Don't see index.html in the output?
- Make sure you saved the file (Ctrl+S / Cmd+S). A dot next to the filename in the tab means unsaved changes.
- Check that your terminal is in the aws-project folder. If not, run cd ~/Desktop/aws-project to get back.
- Make sure you named the file exactly index.html (all lowercase, no spaces).
Still stuck? Help me troubleshoot why my index.html file isn't appearing in my project folder.
✔️ Awesome, I've got everything!
Great. Make sure index.html is saved and move on to creating your S3 bucket.
ⓧ I'd like to double check the full code
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>My First AWS Website</title>
<style>
body {
font-family: Arial, sans-serif;
max-width: 800px;
margin: 50px auto;
padding: 20px;
background-color: #f0f8ff;
text-align: center;
}
h1 { color: #232f3e; }
p { color: #555; font-size: 1.2em; }
.highlight { color: #ff9900; font-weight: bold; }
</style>
</head>
<body>
<h1>Hello from AWS S3!</h1>
<p>This website is hosted on <span class="highlight">Amazon S3</span>.</p>
<p>I deployed it using the AWS CLI from my terminal.</p>
<p>Skills learned: IAM, AWS CLI, S3 Static Hosting</p>
</body>
</html>
Create an S3 bucket using the CLI
An S3 bucket is a container that holds your files (called "objects") in the cloud. Every bucket name must be globally unique across all AWS accounts, so you'll include your name to avoid collisions.
- Create your S3 bucket by running this command:
aws s3 mb s3://[[BUCKET_NAME="nextwork-website-yourname"]] --region us-east-1
- Replace yourname with your actual name or a unique identifier. Bucket names must be lowercase and can only contain letters, numbers, and hyphens.
What does this command do?
- aws s3 mb stands for "make bucket". It creates a new S3 bucket.
- s3:// is the protocol prefix for S3 resources, similar to how https:// works for websites.
- --region us-east-1 tells AWS which data center to create the bucket in. This matches the default region you set during aws configure.
- Verify your bucket was created by running:
aws s3 ls
You should see your bucket name listed in the output along with its creation date.
Getting a BucketAlreadyExists error?
S3 bucket names are globally unique across ALL AWS accounts worldwide. If someone else already has that name, you need to pick a different one.
- Try adding numbers to the end (e.g., nextwork-website-jane-42).
- Use your full name instead of just your first name.
- Make sure you only use lowercase letters, numbers, and hyphens. No underscores or uppercase.
Need more help? Help me pick a unique S3 bucket name that follows the naming rules.
Upload your HTML file to the bucket
Your bucket is empty right now. Let's upload index.html so your website has something to serve.
- Upload your HTML file to the bucket by running this command:
aws s3 cp index.html s3://[[BUCKET_NAME="nextwork-website-yourname"]]/index.html
What does this command do?
- aws s3 cp copies a file. It works like the regular cp command but between your computer and S3.
- The first argument (index.html) is the local file to upload.
- The second argument (s3://bucket-name/index.html) is the destination path inside your bucket.
- Verify the file was uploaded by listing your bucket contents:
aws s3 ls s3://[[BUCKET_NAME="nextwork-website-yourname"]]/
You should see index.html listed with its file size and upload timestamp.
Don't see your file in the bucket?
- Make sure your terminal is in the aws-project folder where index.html lives. Run ls to confirm the file is in your current directory.
- Check that your bucket name in the command matches the exact name you created. Even one typo will cause a "NoSuchBucket" error.
- If you see "Access Denied", your IAM policy may not be attached correctly. Return to the IAM console and confirm NextWorkS3FullAccess is attached to nextwork-cli-user.
Still stuck? Help me figure out why my aws s3 cp upload failed.
Your website file is now stored in the cloud. Next up, you'll enable static website hosting on your bucket and make it publicly accessible so anyone can visit your site in a browser.
Enable Static Website Hosting and Make It Public
Your bucket has an HTML file inside it, but right now nobody can see it. S3 buckets are private by default, which means your website files are locked away from the internet.
In this step, you will flip three switches that turn your private bucket into a live website anyone can visit. You will enable static website hosting, remove the public access block, and add a bucket policy that grants read access to the world.
In this step, get ready to:
- Enable static website hosting on your bucket.
- Disable Block Public Access settings.
- Add a bucket policy that allows public read access.
Enable static website hosting on your bucket
By default, S3 just stores files. It does not serve them as web pages. Enabling static website hosting tells S3 to act like a web server and respond to browser requests with your HTML files.
- In the AWS Console, search for S3 in the top search bar and open the S3 service.
- In the left navigation pane, choose General purpose buckets.
- Click on your bucket name in the list.
- Click the Properties tab.
- Scroll down to Static website hosting and click Edit.
- Select Use this bucket to host a website.
- Under Static website hosting, select Enable.
- In the Index document field, type index.html.
- Click Save changes.
- After saving, scroll back down to Static website hosting and note the Bucket website endpoint URL shown. Copy it somewhere safe.
What is the website endpoint?
This is the public URL where your website will live. It follows the format http://bucket-name.s3-website-region.amazonaws.com. For your bucket in us-east-1, it looks something like http://nextwork-website-yourname.s3-website-us-east-1.amazonaws.com.
You cannot visit this URL yet because your bucket is still private. The next two substeps will fix that.
Disable Block Public Access
S3 has a safety feature called Block Public Access that prevents you from accidentally exposing files to the internet. For a public website, you need to turn this off so that visitors can actually reach your pages.
- While still viewing your bucket, click the Permissions tab.
- Under Block public access (bucket settings), click Edit.
- Uncheck Block all public access.
- Click Save changes.
- A confirmation dialog appears. Type confirm in the text field and click Confirm.
Why does AWS make me confirm?
Making a bucket public is a significant security action. AWS adds this confirmation step to make sure you are intentionally opening access, not doing it by accident.
For this learning project, public access is exactly what you want. In production, you would typically use CloudFront with HTTPS instead of directly exposing an S3 bucket.
Add a bucket policy for public read access
Disabling Block Public Access removed the guardrail, but it did not actually grant anyone permission to read your files. You still need a bucket policy that explicitly says "anyone can download objects from this bucket."
- Still in the Permissions tab, scroll down to Bucket policy and click Edit.
- Paste the following policy into the editor, replacing the bucket name with your own:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadGetObject",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::[[BUCKET_NAME="nextwork-website-yourname"]]/*"
}
]
}
What does this policy do?
This policy uses the same JSON policy language as the IAM policy you created earlier. Here is what each field means:
- Principal set to "*" means "anyone on the internet."
- Action set to "s3:GetObject" means they can only download (read) files. They cannot upload or delete anything.
- Resource ending in /* means all objects inside the bucket.
- Click Save changes.
- Open a new browser tab and paste in the Bucket website endpoint URL you copied earlier.
You should see your website live, with the heading "Hello from AWS S3!" and your orange-highlighted text.
Don't see your website?
- Make sure you are using the Bucket website endpoint URL (starts with http:// and contains s3-website), not the regular S3 object URL.
- If you see "403 Forbidden", double-check that Block Public Access is fully unchecked and that your bucket policy has the correct bucket name in the Resource field.
- If you see "404 Not Found", check that your Index document field says index.html (case-sensitive) and matches the file name you uploaded.
Still stuck? Help me debug why my S3 static website is not loading.
Secret mission
Deploy a Multi-Page Site from the CLI Only
You configured static website hosting using the AWS Console. Can you do the same thing entirely from your terminal, and add multiple pages to your site while you're at it?
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 runs entirely within your AWS Free Tier credits, so there are no ongoing costs to worry about.
Resources you used:
- S3 bucket (nextwork-website-yourname) with HTML files.
- IAM user (nextwork-cli-user) with access keys.
- IAM policy (NextWorkS3FullAccess).
- AWS CLI credentials stored locally in %UserProfile%\.aws\.
Keep everything running
No action needed. Choose this if you are still actively building or plan to extend this project soon.
- Your S3 website remains live at its endpoint URL.
- Storage cost is fractions of a cent per month, well within your Free Tier credits.
- Your IAM user and policy remain active for future CLI use.
Pause - I'll come back to this later
Deactivate your access key to prevent anyone from using it while you are away. Your resources stay intact so you can pick up where you left off.
- In the AWS Console, search for IAM and open it.
- In the left navigation pane, choose Users.
- Click nextwork-cli-user.
- Go to the Security credentials tab.
- Under Access keys, click Actions next to your key, then choose Deactivate.
- When you return, reactivate the key from the same menu.
Delete - I don't want to use this again
Remove all project resources and start fresh. This cannot be undone.
Delete the S3 bucket and all its contents
- In your Cursor terminal, delete the bucket and everything inside it by running this command:
aws s3 rb s3://[[BUCKET_NAME="nextwork-website-yourname"]] --force
You should see output listing each deleted file, followed by a confirmation that the bucket was removed.
Delete the IAM user
- In the AWS Console, search for IAM and open it.
- In the left navigation pane, choose Users.
- Select the checkbox next to nextwork-cli-user.
- At the top of the page, choose Delete.
- In the confirmation dialog, type nextwork-cli-user to confirm, then choose Delete.
Delete the IAM policy
- In the IAM left navigation pane, choose Policies.
- Search for NextWorkS3FullAccess and select it.
- Choose Actions, then Delete.
- Confirm the deletion when prompted.
Remove local AWS credentials
- In your Cursor terminal, remove the stored credentials by running this command:
Remove-Item -Recurse -Force "$env:USERPROFILE\.aws"
This deletes the credentials and config files that store your access keys locally.
Delete local project files
- Delete the folder containing your index.html, about.html, and error.html files from your computer.
That's a Wrap!
That's a Wrap!
Nice work! You just built a secure AWS foundation from the ground up and deployed a live website that anyone can visit.
You've learned how to:
- Create an IAM user with a custom least-privilege policy that grants only S3 permissions, keeping your root account safe.
- Install and configure the AWS CLI v2, connecting it to your IAM user so every command authenticates with scoped credentials.
- Deploy a live static website on S3 with public access configured through bucket policies.
- Secret Mission: Deployed a multi-page site entirely from the command line using aws s3 website and aws s3 sync.
Ready to quiz yourself?