Control S3 from an EC2 Command Line

Use Linux commands and AWS CLI to manage S3 from an EC2 instance.

Introduction

30 Second Summary

When you manage cloud servers, there's no desktop with icons to click. Everything happens through typed commands in a terminal.

In this project, you will launch a Linux server on AWS, connect to it through your browser, and use the command line to search files, set permissions, and manage cloud storage.

What You'll Build

You type a command, and files from your server upload to cloud storage while the terminal streams back a filtered summary of exactly what landed.

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

  • A live browser-based terminal you connect to in one click, with zero local setup required.
  • The skills to search server logs with grep, locate files with find, and control permissions with chmod on a real cloud server.
  • An S3 bucket you create, fill with files, and manage entirely from the command line, with IAM role credentials keeping everything secure.
  • Secret Mission: Write a bash script that automates backing up a directory to S3 with error handling and timestamped logging.

Are there any prerequisites?

This project assumes you already have an AWS Free Tier account. All work happens in the browser through the AWS Management Console, so you don't need to install anything on your computer.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters. This project bridges two skills that the Solutions Architect exam expects you to have: navigating a Linux command line and managing AWS resources without ever touching the console UI.

Launch Your EC2 Instance

To practice Linux commands, you need a real Linux environment. A local virtual machine would work, but launching an EC2 instance gives you a genuine cloud server that mirrors what you will manage in production.

In this step, you will launch an Amazon Linux 2023 instance and connect to it through your browser using EC2 Instance Connect. No local SSH keys or terminal apps required.

In this step, get ready to:
  • Launch an Amazon Linux 2023 EC2 instance from the AWS Console.
  • Connect to the instance in your browser via EC2 Instance Connect.
  • Confirm the AWS CLI is pre-installed and ready to use.
Launch an Amazon Linux 2023 instance

The EC2 launch wizard walks you through choosing an operating system, instance size, and network settings. You will use the defaults for almost everything.

  • Sign in to the AWS Management Console at https://console.aws.amazon.com.
  • In the search bar at the top, type EC2 and select EC2 from the results.
  • Click Launch instance on the EC2 dashboard.

What is EC2?

Amazon EC2 (Elastic Compute Cloud) is a service that lets you rent virtual servers in the cloud. Each server is called an instance. You choose the operating system, size, and region, and AWS provisions it in seconds.

  • Under Name and tags, enter linux-practice in the Name field.
  • Under Application and OS Images (Amazon Machine Image), confirm Amazon Linux 2023 AMI is already selected. It is the default under Quick Start.
  • Under Instance type, select a Free Tier eligible type. Choose t2.micro if available in your region, or t3.micro if not.
  • Under Key pair (login), select Proceed without a key pair (Not recommended) from the dropdown.

Why no key pair?

EC2 Instance Connect pushes a temporary public key to your instance's metadata each time you connect. The key lasts only 60 seconds. This means you do not need to create, download, or manage SSH key files.

  • Under Network settings, confirm the Allow SSH traffic from checkbox is checked.
  • In the dropdown next to Allow SSH traffic from, select My IP. This restricts SSH access to your current IP address only.
  • Leave all other settings at their defaults.
  • Click Launch instance at the bottom of the page.

You should see a success banner confirming your instance is launching.

What is a security group?

A security group is a virtual firewall for your instance. The rule you just set allows SSH connections (port 22) only from your IP address. All other inbound traffic is blocked by default.

Don't see a Free Tier eligible instance type?

The available Free Tier types depend on your account age and region. Accounts created before July 15, 2025 get 750 hours/month of t2.micro or t3.micro. Newer accounts use a credit-based system with t3.micro eligible. Look for the Free tier eligible label next to the instance type.

If you see no Free Tier label, try switching to a different AWS region using the dropdown in the top-right corner of the console.

Help me find a Free Tier eligible instance type in my region.

Wait for status checks and connect

Your instance needs a minute or two to boot up and pass its health checks. Once both checks pass, you can connect.

  • Click View all instances (or click Instances in the left navigation pane).
  • Wait until the Instance state column shows Running and the Status check column shows 2/2 checks passed. This may take 1-2 minutes. Click the refresh icon if needed.
  • Select the checkbox next to your linux-practice instance.
  • Click the Connect button at the top of the instances table.
  • On the Connect to instance page, select the EC2 Instance Connect tab.
  • Leave the Username as ec2-user (the default for Amazon Linux).
  • Click Connect.

A terminal window opens in your browser. You should see a prompt that looks like [ec2-user@ip-...].

Connection failed or timed out?

The most common cause is a security group misconfiguration. Go back to the EC2 console, select your instance, and click the Security tab. Under Inbound rules, confirm there is a rule for SSH (port 22) with your IP address as the source.

If your IP has changed (common on corporate or mobile networks), edit the security group's inbound rule and update the source to your current IP.

Help me troubleshoot my EC2 Instance Connect connection.

Verify the AWS CLI is pre-installed

Amazon Linux 2023 ships with the AWS CLI already installed. Before you move on, confirm it is working.

Before you run this, what do you expect the output to be? A version number, or an error?

  • Confirm the AWS CLI is installed by running this command:
aws --version

You should see output containing aws-cli/2 followed by a version number. This confirms the CLI is ready to use.

What does this tell you?

The aws --version command prints the installed AWS CLI version. Amazon Linux 2023 comes with AWS CLI version 2 pre-installed, so you do not need to install anything.

Seeing 'command not found'?

This should not happen on Amazon Linux 2023. If you see this error, you may have accidentally selected a different AMI during launch. Go back to the EC2 console, terminate this instance, and relaunch with the Amazon Linux 2023 AMI (the default under Quick Start).

Help me figure out why aws --version is not working on my instance.

Your Linux workstation is live. Next up, you will put it to work by exploring real system files with intermediate Linux commands like grep, find, and pipes.

Explore Linux Commands on Real Files

Your EC2 instance is live and you have a terminal open. That means you have a real Linux server to explore.

Basic commands like ls, cd, and mkdir are a good start, but real AWS administration requires searching through files, chaining commands, and controlling output. This step builds those muscles on actual system files that exist on your instance right now.

In this step, get ready to:
  • Search through log files with grep using flags like -i, -c, -E, and -n.
  • Locate files across the filesystem with find.
  • Chain commands together using pipes and redirection.
Search log files with grep

Your instance has real log files generated when it booted. The file /var/log/cloud-init.log records everything that happened during instance setup. You will search it for patterns using grep and its flags.

  • Search for the word "error" (case-insensitive) and show line numbers by running this command:
grep -in "error" /var/log/cloud-init.log

You should see matching lines printed with their line numbers on the left. If no errors occurred during boot, you may see no output at all.

  • Count how many lines contain "error" (case-insensitive) by running:
grep -ic "error" /var/log/cloud-init.log

This prints a single number representing the count of matching lines.

  • Search for multiple patterns at once using extended regex by running:
grep -E -i "error|warning" /var/log/cloud-init.log

What do these flags do?

  • -i makes the search case-insensitive, so "Error", "ERROR", and "error" all match.
  • -n prepends the line number to each match, helping you locate it in the file.
  • -c prints only the count of matching lines instead of the lines themselves.
  • -E enables extended regex so you can use | to mean "or" between patterns.
  • Chain grep with other commands using a pipe to show just the first 5 case-insensitive matches by running:
cat /var/log/cloud-init.log | grep -i "error" | head -5

What is a pipe?

The | character (pipe) sends the output of one command as input to the next. Here, cat reads the file, grep filters for matches, and head -5 limits you to the first 5 results.

Pipes let you build powerful one-liners by snapping simple commands together like building blocks.

Locate files with find

While grep searches inside files, find locates files themselves based on name, type, or size. Your instance has hundreds of config files scattered across /etc and log data stored under /var.

  • Find all .conf files in /etc by running:
find /etc -name "*.conf" -type f

You should see a list of configuration file paths scroll through your terminal.

  • Find files larger than 1 megabyte under /var by running:
find /var -size +1M -type f
  • Find all directories named "log" on the system by running:
find / -name "log" -type d 2>/dev/null

What does 2>/dev/null do?

Some directories are restricted, so find prints "Permission denied" errors. The 2>/dev/null part redirects those error messages into a black hole so only real results appear.

  • Combine find with wc -l to count how many .conf files exist by running:
find /etc -name "*.conf" -type f | wc -l

You should see a single number. This is how many configuration files exist in /etc on your instance.

Redirect and combine output with pipes

So far you have been viewing output on screen. Redirection lets you save command output to a file. This is essential for creating logs, reports, and scripts that AWS administrators rely on.

  • Write output to a new file using > by running:
echo "First line of my notes" > notes.txt
  • Append a second line without erasing the first by using >>:
echo "Second line added later" >> notes.txt
  • Verify both lines exist by running:
cat notes.txt

You should see both lines printed in order.

What is the difference between > and >>?

> creates a new file (or erases an existing one) and writes the output. >> appends to the end of an existing file without erasing anything.

Using > on a file that already has content will destroy that content. Always use >> when you want to add to a file.

  • Pipe multiple commands together to count directories in /etc by running:
ls -la /etc | grep "^d" | wc -l

This chains three commands: ls -la lists all entries, grep "^d" filters for lines starting with "d" (which marks directories), and wc -l counts those lines.

  • Use tee to write to a file and screen simultaneously by running:
ls -la /etc | grep "^d" | tee dirs.txt | wc -l

You should see the count printed on screen. At the same time, the directory listing was saved to dirs.txt.

  • Confirm the file was created by running:
cat dirs.txt

You should see the filtered directory lines that tee captured.

Why is tee useful?

The tee command copies standard input to both a file and standard output. This lets you save a log of what happened while still piping the data onward to the next command.

You will use this exact pattern in the Secret Mission to log your backup script's progress.

Not seeing any output from grep?

If your grep commands return nothing, your log file might not contain those exact patterns. Try a more general search like grep -c "" /var/log/cloud-init.log to confirm the file exists and has content (this counts all lines).

If you see "No such file or directory", make sure you are typing the path exactly as shown, including the hyphen in cloud-init.log.

Help me troubleshoot my grep and find commands

Before you move on, predict what these two commands will output. Will you get words, numbers, or file paths?

  • Run this grep command to count lines matching "error" or "warning":
grep -c "error\|warning" /var/log/cloud-init.log
  • Run this find command piped to wc:
find /etc -name "*.conf" -type f | wc -l

Both commands print a single number. The first is the count of lines containing "error" or "warning" in the log file. The second is the total number of .conf files in /etc.

You now have practical experience searching files, locating files, and controlling where output goes. Next up, you will learn how file permissions work by hitting a "Permission denied" error on purpose.

Master File Permissions

In the previous step, you searched through real system files using grep and find, and chained commands together with pipes and redirection.

Now you are going to write your first script on this instance. But there is a catch. Linux blocks execution of new files by default. When you try to run your script, it will refuse. Understanding why this happens and how to fix it with chmod is essential because misconfigured permissions are the number one cause of "access denied" errors on EC2 instances.

In this step, get ready to:
  • Create a test script and discover why Linux blocks it from running.
  • Fix permissions with chmod and experiment with different permission levels.
  • Examine file ownership patterns across the system.
Create a test script and try to run it

Scripts are how real administrators automate work on Linux servers. Let's create a simple one and see what happens when you try to execute it.

  • Create a small bash script called backup-test.sh by running this command:
echo '#!/bin/bash' > backup-test.sh && echo 'echo "Script works!"' >> backup-test.sh

What does this command do?

This creates a file called backup-test.sh with two lines inside it.

  • The first echo writes #!/bin/bash to the file using > (which creates or overwrites the file). This line is called a "shebang" and tells Linux which program should run the script.
  • The second echo appends echo "Script works!" to the file using >> (which adds to the end without erasing what is already there).
  • Confirm the file was created by running:
cat backup-test.sh

You should see two lines: #!/bin/bash and echo "Script works!".

Before you run this script, what do you think will happen? Will it print "Script works!" or will something go wrong?

  • Try to execute your new script by running:
./backup-test.sh

You will see an error: bash: ./backup-test.sh: Permission denied.

This is expected. Linux refused to run your script because new files do not get execute permission by default. This is a security feature that prevents malicious files from running automatically.

  • Check the current permissions on your script by running:
ls -la backup-test.sh

You will see something like -rw-r--r-- at the start of the line. Notice there is no x anywhere in the permission string. That missing x is exactly why Linux blocked execution.

How do permission strings work?

The 10-character string (like -rw-r--r--) breaks into four parts:

  • Position 1: file type (- for regular file, d for directory).
  • Positions 2-4: owner permissions (read, write, execute).
  • Positions 5-7: group permissions.
  • Positions 8-10: everyone else's permissions.

Each position is either the letter (r, w, or x) if that permission is granted, or a - if it is not.

Fix permissions with chmod

The chmod command (short for "change mode") lets you control who can read, write, and execute a file. You will use the numeric format where each digit represents a permission level.

  • Grant full permissions to the owner only by running:
chmod 700 backup-test.sh

What does 700 mean?

The three digits represent owner, group, and others. Each digit is a sum of: 4 (read) + 2 (write) + 1 (execute).

  • 7 = 4+2+1 = read + write + execute for the owner.
  • 0 = no permissions for the group.
  • 0 = no permissions for everyone else.

This is the most restrictive way to make a script executable. Only you (the file owner) can read, modify, or run it.

  • Now try running your script again:
./backup-test.sh

You should see Script works! printed to the terminal. The chmod command gave Linux permission to execute the file.

  • Verify the new permissions by running:
ls -la backup-test.sh

You should now see -rwx------ at the start of the line. The rwx confirms the owner has read, write, and execute. The six dashes confirm no one else has any access.

Still seeing Permission denied?

  • Make sure you ran chmod 700 backup-test.sh with the correct filename. A typo in the filename means the permissions were applied to a different (or nonexistent) file.
  • Confirm you are running ./backup-test.sh with the dot-slash prefix. Without ./ the shell looks in system paths, not your current directory.
  • Help me debug this permission issue

Now experiment with other common permission levels to see how the permission string changes.

  • Change to read-only for others by running:
chmod 644 backup-test.sh
  • Check how the permission string changed by running:
ls -la backup-test.sh

You should see -rw-r--r--. The owner can read and write. The group and others can only read. Notice the x is gone again. This is a common permission for config files that should be readable but not executable.

  • Now try a permission that lets everyone execute by running:
chmod 755 backup-test.sh
  • Check the permissions again:
ls -la backup-test.sh

You should see -rwxr-xr-x. The owner can read, write, and execute. Everyone else can read and execute but not modify. This is the standard permission for shared scripts and system utilities.

  • Set the permissions back to 700 (owner-only) for security by running:
chmod 700 backup-test.sh
Examine file ownership on the system

Permissions control what actions are allowed. Ownership controls who those permissions apply to. Every file on Linux has an owner and a group.

  • Examine who owns the system log files by running:
ls -la /var/log/

You will see that most files in this directory are owned by root. System logs are owned by root so that regular users cannot tamper with audit trails or error records.

  • Now check the ownership of your own script by running:
ls -la ~/backup-test.sh

You will see ec2-user listed as both the owner and group. Files you create are owned by your user account. This is why chmod 700 works for you. You are the owner, so the first digit (7) applies to you.

  • Get detailed ownership and permission information using the stat command:
stat backup-test.sh

What does stat show you?

The stat command shows more detail than ls -la. Look for the Access line which shows permissions in both the numeric format (like 0700) and symbolic format (like -rwx------).

It also shows the Uid (user ID) and Gid (group ID) of the file owner. On your instance, ec2-user has UID 1000.

Let's confirm your final setup is correct. What do you expect to see when you run the script one more time?

  • Run your script and check its permissions one final time:
./backup-test.sh && ls -la backup-test.sh

You should see Script works! on the first line, followed by the file listing showing -rwx------ (700 permissions).

Your script runs successfully and only your user account can touch it. This is the same pattern used to secure SSH keys, deployment scripts, and credential files on production servers.

Now that you know how to control file permissions, there is one problem remaining. Your instance still cannot talk to other AWS services. In the next step, you will give it access to S3 by attaching an IAM role.

Give Your Instance AWS Access with an IAM Role

In the previous step, you learned to control who can execute a file on your instance. Now you'll solve a bigger access problem.

Your EC2 instance is a running Linux server, but it exists in isolation. It has no permission to interact with any other AWS service. If you try to list S3 buckets right now, the AWS CLI will refuse because it cannot find any credentials on the machine.

In this step, get ready to:
  • Prove your instance has no AWS permissions by running a command that fails.
  • Create an IAM role that grants S3 access and attach it to your instance.
  • Verify the role is active by checking the instance's assumed identity.
Try to access S3 without permissions

Before you fix the problem, you need to see the problem. Your instance currently has no credentials configured and no IAM role attached. That means any AWS CLI command that talks to another service will fail.

Before you run the next command, what do you think will happen? Will it succeed and list your S3 buckets, or will it fail?

  • In your EC2 Instance Connect terminal, try listing your S3 buckets by running:
aws s3 ls

You will see an error message saying the CLI is unable to locate credentials. This is expected. Your instance has no way to prove its identity to other AWS services yet.

Why not just run aws configure?

You could paste access keys into the instance using aws configure. But that stores long-lived credentials on the machine, which is a security risk. If anyone gains access to the instance, they get your keys.

The AWS best practice is to attach an IAM role instead. The role delivers temporary credentials that rotate automatically. No secrets are ever stored on disk.

Create an IAM role for EC2

An IAM role is a set of permissions that an AWS service can assume. You will create a role that lets your EC2 instance talk to Amazon S3.

  • Open a new browser tab and navigate to the IAM console at https://console.aws.amazon.com/iam/.
  • In the left navigation pane, click Roles.
  • Click Create role.

You are now on the trusted entity selection page.

  • For Trusted entity type, select AWS service.
  • Under Use case, choose EC2.
  • Click Next.

You are now on the permissions page where you choose what your instance can do.

  • In the search box, type AmazonS3FullAccess.
  • Select the checkbox next to AmazonS3FullAccess.
  • Click Next.

Don't see AmazonS3FullAccess in the list?

Make sure you typed the policy name exactly as AmazonS3FullAccess in the search box. The filter is case-sensitive. If you still cannot find it, clear the search and scroll through the list of AWS managed policies.

Help me find the AmazonS3FullAccess policy

You are now on the naming page.

  • In the Role name field, type EC2-S3-Access-Role.
  • Scroll down and click Create role.

You should see a green success banner confirming the role was created.

What is an instance profile?

When you create a role using the IAM console, an instance profile with the same name is automatically created. An instance profile is the container that delivers the role's credentials to your EC2 instance. You do not need to create one separately.

Attach the role to your EC2 instance

The role exists, but your instance does not know about it yet. You need to attach the role to the running instance.

  • Switch to the EC2 console tab in your browser.
  • In the left navigation pane, click Instances.
  • Select the checkbox next to your running instance.
  • Click Actions in the top menu bar.
  • Select Security.
  • Click Modify IAM role.

You are now on the Modify IAM role page.

  • In the IAM role dropdown, select EC2-S3-Access-Role.
  • Click Update IAM role.

You should see a success message confirming the role has been attached. The credentials can take 1-2 minutes to propagate to your instance.

Why does propagation take time?

When you attach a role, AWS delivers temporary credentials to your instance via its metadata service. The instance needs a moment to pick up the new credentials. If your first verification attempt fails, wait another minute and try again.

Now for the moment of truth. Do you think aws sts get-caller-identity will succeed this time, or will you see the same credentials error?

  • Switch back to your EC2 Instance Connect terminal.
  • Verify the role is active by running:
aws sts get-caller-identity

You should see JSON output containing an ARN that includes EC2-S3-Access-Role. This proves your instance is now authorized to act as that role.

Still seeing a credentials error?

Wait 1-2 minutes for the role credentials to propagate, then run the command again. If it still fails, go back to the EC2 console and confirm the role shows as attached under your instance's Security tab.

Also confirm you selected EC2-S3-Access-Role (not a different role) in the Modify IAM role dropdown.

Help me troubleshoot my IAM role attachment

Your instance now has permission to talk to S3. Next up, you will put those permissions to work by creating an S3 bucket and managing files entirely from the command line.

Manage S3 from the Command Line

Your EC2 instance now has permission to interact with AWS services through the IAM role you attached in the last step. This is where your Linux skills and AWS CLI knowledge merge into real cloud operations.

In this step, you'll create an S3 bucket, upload files to it, and filter command output using the same pipes and grep techniques you practiced earlier.

In this step, get ready to:
  • Create an S3 bucket from the command line.
  • Upload files and sync directories to S3.
  • Filter and explore AWS CLI output with Linux pipes, grep, and awk.
Create an S3 bucket

S3 bucket names must be globally unique across all AWS accounts. You'll need to choose a name that nobody else has used.

  • Create your S3 bucket by running this command (replace the bucket name with something unique to you, like your name and today's date):
aws s3 mb s3://[[BUCKET_NAME="your-unique-bucket-name-2026"]]

What does this command do?

The aws s3 mb command stands for "make bucket." It creates a new S3 bucket with the name you provide.

Bucket names must be globally unique because they become part of a public URL. If someone else already has that name, the command will fail.

You should see a message confirming your bucket was created, like make_bucket: your-unique-bucket-name-2026.

  • Verify your bucket exists by listing all your buckets and piping through grep to find yours:
aws s3 ls | grep [[BUCKET_NAME="your-unique-bucket-name-2026"]]

You should see one line of output showing the creation date and your bucket name.

Seeing "BucketAlreadyExists"?

Someone else already has that bucket name. Try a more unique name by adding random numbers or your initials.

If you see "Access Denied" instead, go back to the EC2 console and confirm your IAM role is still attached (Actions > Security > Modify IAM role).

help me fix my S3 bucket creation error

Upload files to your bucket

Now that your bucket exists, you can push files from your EC2 instance into S3 using the CLI.

  • Create a text file and upload it to your bucket by running these commands:
echo "Hello from EC2" > hello.txt
aws s3 cp hello.txt s3://[[BUCKET_NAME="your-unique-bucket-name-2026"]]/

What does this do?

The first line creates a file called hello.txt with the text "Hello from EC2" inside it.

The aws s3 cp command copies a local file to your S3 bucket. The trailing / tells AWS to place the file in the bucket root.

You should see output like upload: ./hello.txt to s3://your-bucket/hello.txt confirming the upload.

  • Now create a directory with multiple files and sync the entire directory to S3 by running:
mkdir project-files
echo "file1" > project-files/a.txt
echo "file2" > project-files/b.txt
aws s3 sync project-files/ s3://[[BUCKET_NAME="your-unique-bucket-name-2026"]]/project-files/

What is the difference between cp and sync?

The aws s3 cp command copies a single file. The aws s3 sync command uploads an entire directory and only transfers files that are new or changed.

Sync is what professionals use for backups and deployments because it skips files that already match, saving time and bandwidth.

  • Verify all your files made it to S3 by listing the bucket contents:
aws s3 ls s3://[[BUCKET_NAME="your-unique-bucket-name-2026"]]/ --recursive

You should see three files listed: hello.txt, project-files/a.txt, and project-files/b.txt.

Only seeing some of your files?

Make sure you included --recursive in the command. Without it, aws s3 ls only shows top-level objects and prefixes.

If you see zero files, double-check that your bucket name in the command matches what you created earlier.

help me see my uploaded files in S3

Filter AWS CLI output with pipes and grep

Listing files is useful, but real cloud operations produce huge amounts of output. This is where piping AWS CLI output through Linux tools like grep and awk becomes essential.

  • Filter your bucket listing to show only .txt files by running:
aws s3 ls s3://[[BUCKET_NAME="your-unique-bucket-name-2026"]]/ --recursive | grep ".txt"

You should see all three files since they all end in .txt. In a real bucket with hundreds of files, this filter would help you find exactly what you need.

  • Extract just the file sizes and names using awk by running:
aws s3 ls s3://[[BUCKET_NAME="your-unique-bucket-name-2026"]]/ --recursive | awk '{print $3, $4}'

How does awk work here?

The aws s3 ls output has four columns: date, time, size, and filename.

The awk '{print $3, $4}' command extracts the third and fourth columns, giving you a clean list of just file sizes and names. This is the same pattern professionals use to build monitoring scripts.

You should see output showing each file's size in bytes followed by its name, without the date and time clutter.

  • Remove hello.txt from your bucket by running:
aws s3 rm s3://[[BUCKET_NAME="your-unique-bucket-name-2026"]]/hello.txt

You should see a delete confirmation message.

Before you run the next command, what do you expect to see when you list the bucket contents now?

  • Verify the file is gone and only your synced directory remains by running:
aws s3 ls s3://[[BUCKET_NAME="your-unique-bucket-name-2026"]]/ --recursive

You should see only project-files/a.txt and project-files/b.txt. The hello.txt file is gone from S3.

  • Finally, confirm your bucket still shows up in your account-wide listing by running:
aws s3 ls | grep [[BUCKET_NAME="your-unique-bucket-name-2026"]]

You should see one line with the creation date and your bucket name.

Not seeing your bucket in the listing?

Double-check that the name you're grepping for matches your actual bucket name exactly. Bucket names are case-sensitive.

Run aws s3 ls without the grep first to see all your buckets, then match the spelling.

help me find my S3 bucket in the CLI output

You just created and managed an S3 bucket entirely from the Linux command line. You uploaded files, synced directories, and filtered AWS output using the same Linux tools (grep, awk, pipes) that power real-world cloud automation scripts.

Next up, you'll combine everything you've learned into a single automated backup script in the Secret Mission.

Secret mission

Write an Automated S3 Backup Script

Real Solutions Architects don't type individual commands one by one. They write scripts that run reliably without supervision. In this mission, you'll combine everything you've learned into a single automated bash script that backs up a directory to S3 with error handling and timestamped logging.

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 EC2 and S3, which are covered by the AWS Free Tier (750 hours of t2.micro/t3.micro compute and 5GB of S3 storage per month for 12 months).

Cost warning

Your EC2 instance consumes Free Tier hours while running. If you leave it running 24/7, it will use about 720 hours per month. That leaves almost no headroom for other instances.

Your S3 bucket stores a small amount of data (well under the 5GB Free Tier limit), but charges accrue if your Free Tier period expires. If you are done practicing, choose Pause or Delete below.

Resources you used:

  • 1x EC2 instance (t2.micro or t3.micro) with attached security group.
  • 1x S3 bucket with uploaded files (project-files/, backup directory, hello.txt).
  • 1x IAM role (EC2-S3-Access-Role) with instance profile (no ongoing cost).

Keep everything running

No action needed. Choose this if you are still actively experimenting with Linux commands or AWS CLI on your instance.

  • Your EC2 instance stays running and accessible via EC2 Instance Connect.
  • Your S3 bucket and its contents remain available.
  • Monitor your Free Tier usage in the AWS Billing console to avoid unexpected charges.

Pause - I'll come back to this later

Stop your EC2 instance to halt compute charges while keeping your files and configuration intact. You can restart it later and reconnect via EC2 Instance Connect.

  • In the EC2 console, select your instance.
  • Click Instance state, then Stop instance.
  • Confirm the stop action.
  • Your instance retains its data (EBS volume) and you can restart it later without charges for compute. EBS storage still applies within Free Tier limits.
  • Your S3 bucket remains untouched at minimal cost.

Delete - I don't want to use this again

Remove all project resources permanently. This cannot be undone.

  • Delete your S3 bucket. In your EC2 Instance Connect session (while still connected), run the following command. Replace the bucket name with your own:
  • aws s3 rb s3://your-unique-bucket-name-2026 --force
  • This deletes all objects in the bucket and then removes the bucket itself.
  • Terminate your EC2 instance. In the EC2 console, select your instance, then click Instance state and choose Terminate instance. Confirm the termination.
  • Delete the IAM role. Open the IAM console and choose Roles in the left navigation pane. Select the checkbox next to EC2-S3-Access-Role and click Delete at the top of the page. Type the role name to confirm, then click Delete. The console automatically detaches the managed policy and removes the instance profile.
  • Delete the security group (optional). In the EC2 console, go to Security Groups in the left navigation. Select the launch-wizard security group you created, click Actions, then Delete security groups. Confirm the deletion. If it says the group is still in use, wait a few minutes for the instance termination to complete.

Nice Work!

Nice Work!

You just built a Linux-powered AWS workstation from scratch. You connected to a live server through your browser, navigated real system files, fixed permission errors, and managed S3 entirely from the command line.

You've learned how to:

  • Launch an EC2 instance and connect via EC2 Instance Connect with zero local setup.
  • Search and manipulate files on a live Linux server using grep, find, chmod, pipes, and redirection.
  • Create an IAM role with least-privilege S3 access, attach it to your instance, and manage buckets and objects entirely from the command line using the AWS CLI.
  • Secret Mission: Write a bash script that automates S3 backups with error handling, timestamped logging, and proper permissions.

Ready to quiz yourself?