Mount and Troubleshoot AWS Storage

Launch a Linux server, capture TCP handshakes, and mount EFS storage.

Introduction

30 Second Summary

When something breaks in the cloud, engineers need two skills. They need to get into the server, and they need to figure out what went wrong.

In this project, you will launch a Linux server on AWS, capture live network traffic to understand how connections work, and attach shared cloud storage after diagnosing and fixing a real networking problem.

What You'll Build

Picture yourself in a technical interview, pulling up a packet capture from your own server and walking the interviewer through each network layer. Then you describe exactly how you diagnosed and fixed a blocked port.

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

A running Linux server in the cloud that you SSH into and navigate, inspecting files, services, and logs with commands like ls, cd, cat, systemctl, and journalctl.
Live packet captures showing a TCP 3-way handshake (SYN, SYN-ACK, ACK) and DNS resolution traced with dig, mapped to all 7 layers of the OSI model.
A working Amazon EFS file system mounted on your server, after diagnosing and fixing a security group blocking NFS traffic on port 2049.
Secret Mission: Launch a second server and prove two machines can share the same storage simultaneously.

Do I need any prerequisites?

You need an active AWS account to complete this project. All work happens through the AWS Console and an SSH connection to your server, so no additional software is required on your local machine.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters. This step is your chance to commit to the goal before any hands-on work begins.

Launch and Connect to Your Linux Server

Step 1: Launch and Connect to Your Linux Server

Every task in the ADC Engineer role starts with a Linux server. Whether you're checking logs, tracing network issues, or mounting storage, you need a running machine to work on first.

In this step, you'll launch an EC2 instance running Amazon Linux 2023, create a key pair for secure access, and connect to it over SSH. By the end, you'll have a live terminal session on a real server in the cloud.

In this step, get ready to:

Launch an EC2 instance running Amazon Linux 2023.
Download a key pair and connect to your instance via SSH.
Verify your connection with basic Linux commands.

Launch an EC2 instance in the AWS Console

The AWS Management Console is where you create and manage all your cloud resources. You'll use it to spin up a virtual Linux server in minutes.

Open the AWS Management Console at console.aws.amazon.com and sign in to your AWS account.
In the search bar at the top, type EC2 and select EC2 from the results.
Click Launch instance.
Under Name and tags, enter linux-lab in the Name field.
Under Application and OS Images (Amazon Machine Image), confirm Amazon Linux 2023 AMI is selected. It should be the default option and marked Free tier eligible.

What is an AMI?

An AMI (Amazon Machine Image) is a template that contains the operating system and software for your server. Amazon Linux 2023 is AWS's own Linux distribution, optimized for cloud workloads.

Under Instance type, select an instance type marked Free tier eligible. This is typically t2.micro for accounts created before July 2025, or t3.micro for newer accounts.
Under Key pair (login), click Create new key pair.
Enter linux-lab-key as the Key pair name.
Select .pem as the Private key file format.
Click Create key pair. The linux-lab-key.pem file downloads to your computer automatically. Remember where it saves (usually your Downloads folder).

What is a key pair?

A key pair is how you prove your identity when connecting to your server via SSH. The .pem file you just downloaded is your private key. Anyone who has this file can access your server, so keep it safe and never share it.

Under Network settings, keep the defaults. The wizard selects your default VPC and creates a security group that allows SSH connections on port 22 from anywhere.
Click Launch instance.
Click the instance ID link in the success notification to go to your instance details.
Wait for the Instance state column to show Running. This takes about 30 seconds.

Your EC2 instance is now live. Find the Public IPv4 address in the instance details panel at the bottom of the page. Record it here:

Record your instance's public IP address: your instance public IPv4 address.

Connect to your instance via SSH

Your instance is running in the cloud, but you need a way to control it from your local machine. SSH is a protocol that gives you a secure terminal session on a remote server.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Terminal (macOS) or PowerShell (Windows) and press Enter to open it.

Before you can use your key file, you need to set the right permissions on it. The steps differ by operating system.

macOS

Navigate to your Downloads folder and lock down your key file permissions by running these commands:

cd ~/Downloads
chmod 400 linux-lab-key.pem

What does chmod 400 do?

The chmod 400 command sets the file to read-only for you and removes all access for everyone else. SSH refuses to use a key file that other users on your system can read. This same command works on Linux.

Windows

Navigate to your Downloads folder by running this command:

cd $HOME\Downloads

Windows OpenSSH checks key file permissions differently. Set the correct permissions by running these commands:

icacls.exe .\linux-lab-key.pem /reset
icacls.exe .\linux-lab-key.pem /GRANT:R "$($env:USERNAME):(R)"
icacls.exe .\linux-lab-key.pem /inheritance:r

What do these commands do?

These three commands reset the file's permissions, grant read-only access to your Windows user account, and remove all inherited permissions from other users. This is the Windows equivalent of chmod 400 on macOS.

Connect to your instance by running this command:

ssh -i linux-lab-key.pem ec2-user@[[EC2_PUBLIC_IP="your instance public IPv4 address"]]

What does this command do?

The ssh command opens a secure connection to your server. The -i flag tells SSH which private key file to use for authentication. The ec2-user part is the default username on Amazon Linux 2023 instances.

SSH will ask if you want to continue connecting to an unknown host. Type yes and press Enter.

You should see the Amazon Linux banner and a command prompt ending in $. You're now controlling a real Linux server in the cloud from your local terminal.

Can't connect to your instance?

Make sure your instance state is Running in the EC2 console. A pending instance won't accept connections yet.
Double-check that the IP address in your SSH command matches the Public IPv4 address shown in the instance details.
If you see a permissions error about your key file, re-run the permissions command from the tab above (chmod 400 on macOS, or the icacls commands on Windows).
If the connection times out, check that your security group allows inbound SSH on port 22. Go to your instance in the EC2 console, click the Security tab, and confirm an inbound rule for SSH exists.

Still stuck? Help me troubleshoot my SSH connection to EC2.

Verify your connection

You're logged into a remote server, but how do you confirm the server knows who you are? Before running the next command, take a guess: what username do you think the server sees?

Find out by running this command:

whoami

The output is ec2-user. This is the default user account on Amazon Linux 2023 instances.

Run one more command to see your server's internal hostname:

hostname

The hostname is an internal name AWS assigns to your instance. Both commands confirm you're connected to a real Linux server running in the cloud.

You've got a live Linux server running in the cloud and an active SSH session. Next up, you'll explore this server from the inside, practicing the commands that ADC Engineer interviewers love to ask about.

Explore Your Linux Server

Your server is running and you've confirmed your SSH connection works. Now it's time to get comfortable navigating it.

ADC Engineer interviews ask for your favorite Linux commands and why you like them. Memorized answers fall apart under follow-up questions. In this step, you'll build hands-on experience navigating a real server so your answers come from actual use.

In this step, get ready to:

Navigate the filesystem and inspect file permissions.
Check running services and system state.
Read system logs and install networking tools.

Navigate the filesystem and inspect permissions

Every Linux server follows a standard filesystem layout. Let's explore yours by running a few foundational commands.

Check your current location on the server by running:

pwd

You'll see /home/ec2-user printed to the terminal. This is your home directory on the server.

List every directory at the root of the filesystem by running:

ls -la /

What are these directories?

You'll see folders like /etc (system configuration files), /var (logs and variable data), /home (user home directories), and /mnt (mount points for storage).

You'll mount shared storage to /mnt later in this project.

Move into the logs directory and list its contents by running:

cd /var/log
ls -la

How do I read file permissions?

Each line starts with a string like rwxr-xr-x. The first three characters are the owner's permissions (read, write, execute). The next three are the group's permissions. The last three are everyone else's permissions.

A dash - means that permission is denied. So rw-r--r-- means the owner can read and write, but everyone else can only read.

Confirm which operating system your server runs by running:

cat /etc/os-release

You'll see Amazon Linux 2023 listed in the output. This confirms the AMI you selected during launch.

Check running services and system state

Beyond the filesystem, you need to know what's running on your server and what resources are available.

List all active services by running:

systemctl list-units --type=service --state=running

What does this command show?

The systemctl command manages systemd services on your server. You'll see a list of every service currently running.

Look for sshd.service in the list. That's the SSH daemon keeping your remote connection alive right now.

Check how much disk space is available by running:

df -h

The -h flag makes the output human-readable (GB instead of raw bytes). You'll see your root volume and how much space is used.

Check available memory by running:

free -h

View your server's network interfaces and IP addresses by running:

ip addr

Find the line starting with inet under the ens5 interface (not the 127.0.0.1 loopback address). This is your instance's private IP. Record it here: your instance's private IP address. You'll reference this when troubleshooting later.

Extra for Experts: How do these compare to Windows?

On a Windows server, you'd use dir and cd to navigate, but the filesystem structure is completely different (C:\Windows, C:\Users).

For services, Windows uses Get-Service in PowerShell. For network info, the equivalent is ipconfig.

Read system logs and install networking tools

Log analysis is a daily task for ADC engineers. Let's read your server's logs, then install the tools you'll need in the next step.

View recent SSH service logs by running:

journalctl -u sshd --no-pager -n 10

What should I see?

You'll see log entries for SSH events on your server, including your own login. Look for entries that mention your source IP address. This is the same kind of log analysis ADC engineers do when investigating access issues.

Install the networking tools you'll use in the next step by running:

sudo yum install -y tcpdump bind-utils

What did you just install?

You installed two packages. tcpdump captures live network packets so you can see traffic on the wire. bind-utils provides the dig command for DNS lookups.

You'll use both of these to trace a request through the network in the next step.

Seeing an error during install?

Make sure you included sudo at the start of the command. Package installs require root permissions.

If you see a network timeout, wait a moment and try the command again. Your instance may need a few seconds to reach the package repository.

help me troubleshoot the yum install error on my Amazon Linux 2023 EC2 instance

Before you run the next command, think about what you expect to see in the SSH service logs. What events have happened during this step?

Verify your setup by running a focused log check:

journalctl -u sshd --no-pager -n 5

You should see your own SSH login event in the output, including the IP address you connected from. If you see it, your server is set up and ready.

You've got a solid foundation of Linux commands under your belt. Next up, you'll use your newly installed tools to trace a live network request through every layer of the OSI model.

Trace a Request Through the Network

The ADC Engineer interview will test your understanding of networking fundamentals. Two questions come up consistently: "Describe a TCP 3-way handshake" and "What happens when someone types amazon.com into a browser?"

Instead of memorizing textbook answers, you'll watch each process happen live on your server. You'll trace a DNS lookup, capture real TCP packets, and map everything to the OSI model.

In this step, get ready to:

Trace a DNS lookup with dig and map it to OSI layers.
Capture a live TCP 3-way handshake with tcpdump.
Inspect listening ports and walk through the full OSI stack with a real HTTPS request.

Trace a DNS lookup with dig

When you type a domain name like amazon.com into a browser, your computer doesn't know where to send the request. It first needs an IP address. DNS is the system that translates human-readable domain names into IP addresses.

Trace how DNS resolves amazon.com by running this command:

dig amazon.com

You should see several sections of output, including a QUESTION SECTION and an ANSWER SECTION with one or more IP addresses listed.

What does this output show?

The QUESTION SECTION shows what your server asked: "What is the IP address for amazon.com?"
The ANSWER SECTION shows the resolved IP address(es) that came back from the DNS server.
The Query time at the bottom shows how long the lookup took in milliseconds.
This is OSI Layer 7 (the Application layer, where the DNS protocol operates) triggering work at Layer 3 (the Network layer, where IP routing happens) to reach the DNS server.

Why does this matter in an interview?

When an interviewer asks "what happens when you type amazon.com?", this DNS lookup is the very first step. The domain name gets resolved to an IP address before any connection can begin. On Windows, the equivalent command is nslookup.

Capture a live TCP 3-way handshake

DNS gave you an IP address. Now your server needs to establish a connection to that address before it can send any data. TCP does this with a 3-way handshake: three packets exchanged between your server and the remote server to agree on a connection.

You'll use two SSH sessions for this. One session will run tcpdump to listen for packets, and a second session will generate the traffic.

In your current SSH session, start a packet capture by running this command:

sudo tcpdump -i any -c 10 port 80 -nn

What does this command do?

-i any captures packets on all network interfaces.
-c 10 stops the capture automatically after 10 packets.
port 80 filters to only HTTP traffic.
-nn displays raw IP addresses and port numbers instead of resolving hostnames.

Your terminal is now paused, waiting for packets. It will stay like this until traffic arrives.

Open a new terminal window on your local machine.
Connect to your server again with the same ssh command you used in Step 1:

ssh -i [[PEMPATH="path to your .pem file"]] ec2-user@[[EC2_PUBLIC_IP="your instance public IP"]]

Before you generate traffic, think about what tcpdump will capture. How does TCP establish a connection between two computers? What packets do you expect to see at the very start?

In your second SSH session, generate HTTP traffic by running this command:

curl -o /dev/null http://example.com

Switch back to your first SSH session.

The tcpdump capture has finished and printed 10 packets to your screen. Look at the first three packets in the output. You should see three distinct flags:

Flags [S] on the first packet. This is the SYN. Your server is saying "I want to connect."
Flags [S.] on the second packet. This is the SYN-ACK. The remote server is saying "OK, I acknowledge your request."
Flags [.] on the third packet. This is the ACK. Your server confirms the connection is established.

That is the TCP 3-way handshake. You just watched it happen at OSI Layer 4 (the Transport layer). After those three packets, you'll see the HTTP GET request, which is Layer 7 (the Application layer).

Don't see Flags [S] in the output?

Make sure you ran the curl command in your second SSH session, not the first. The first session was blocked by tcpdump.
If tcpdump exited before you ran curl, other background traffic may have used up all 10 packet slots. Run the tcpdump command again in the first session and quickly switch to the second session to run curl.
help me find the TCP 3-way handshake in my tcpdump output

Inspect listening ports and active connections

You've seen how connections are established. Now look at what your server is currently listening for and who is connected to it.

View all listening TCP ports on your server by running:

ss -tlnp

You should see port 22 listed with sshd as the process. That's the SSH service that lets you connect to this server.

View your active TCP connections by running:

ss -tn

You should see your own SSH session listed as an established connection. This is Layer 4 visibility into what's happening on your server right now.

What do these flags mean?

-t shows TCP sockets only.
-l limits the output to listening sockets (ports waiting for incoming connections).
-n displays port numbers instead of service names.
-p shows which process owns each socket.

Now make one more request. Before you run this next command, think about which OSI layers an HTTPS request touches. How many layers do you think are involved?

Make an HTTPS request and view the response headers by running:

curl -I https://amazon.com

You should see response headers including an HTTP status code. That single request just traveled through every layer of the OSI model.

How does one request touch all 7 OSI layers?

Walk through the full stack your request just traveled:

Layer 7 (Application) — your HTTPS request using the HTTP protocol.
Layer 6 (Presentation) — TLS encryption scrambles the data so only the destination can read it.
Layer 5 (Session) — the TLS session is established and maintained for the duration of the connection.
Layer 4 (Transport) — TCP segments the data and manages reliable delivery (the 3-way handshake you just captured).
Layer 3 (Network) — IP routes each packet from your server to amazon.com's server using IP addresses.
Layer 2 (Data Link) — frames the packets for the local network segment.
Layer 1 (Physical) — the actual electrical or optical signals traveling over the physical (or cloud) network.

Seeing 'connection refused' or no output?

Make sure you included the -I flag (capital letter I). This tells curl to fetch only the headers, not the full page.
If you see a redirect response (status 301 or 302), that's normal. The server is redirecting you to www.amazon.com. The response itself proves the full OSI stack worked.
help me troubleshoot the curl -I https://amazon.com command on my EC2 instance

You've seen DNS, TCP, and the full OSI model in action on a real server. Next up, you'll create shared storage with Amazon EFS and hit a real networking problem to diagnose.

Create Shared Storage with Amazon EFS

In the last step, you traced live network traffic across the OSI model. You watched DNS resolution happen, captured a TCP handshake packet by packet, and mapped each tool to its layer. Now it's time to put your server to real use.

The ADC Engineer role operates Amazon EFS every day. EFS is shared storage that multiple servers can access at the same time. In this step, you'll create an EFS file system and mount it on your server.

In this step, get ready to:

Create an EFS file system in the AWS Console.
Install the EFS mount helper on your server.
Attempt to mount the file system on your server.

Create an EFS file system in the AWS Console

Your server needs shared storage that other servers can also connect to. Amazon EFS provides exactly this through NFS (Network File System), a protocol that Linux understands natively.

Return to the AWS Management Console in your browser.
Type EFS in the search bar at the top of the page.
Click Elastic File System in the search results.

What is Amazon EFS?

Amazon EFS (Elastic File System) is shared network storage. Unlike an EBS volume that attaches to a single server, EFS lets multiple servers read and write the same files at the same time.

EFS uses NFS, a Linux-native protocol that runs on TCP port 2049. This makes it directly relevant to the ADC Storage Services role, where you'll operate EFS daily.

Click Create file system.
Enter shared-storage in the Name field.
Confirm the Virtual Private Cloud (VPC) dropdown shows your default VPC. This is the same VPC your EC2 instance is running in.
Click Create.

Your file system appears in the list. Find the File system ID column. It starts with fs-. Record it here because you'll need it to mount the file system:

fs-0abc123def456

Wait 90 seconds before mounting

AWS recommends waiting 90 seconds after creating a file system before you try to mount it. This gives the mount target DNS records time to propagate across the region. You'll install the mount helper next, which is a good way to fill that time.

Install the EFS mount helper

Your server needs a client package to communicate with EFS. The amazon-efs-utils package provides a mount helper that simplifies connecting to EFS file systems.

Switch back to your SSH session on the linux-lab instance.
Install the EFS utilities by running this command:

sudo yum install -y amazon-efs-utils

Look for Complete! at the end of the output to confirm the install succeeded.
Create a directory that will serve as the mount point by running:

sudo mkdir /mnt/efs

Confirm the directory exists by running:

ls /mnt

You should see efs listed in the output.

Install failing?

Make sure you included sudo at the start of the command. Package installs require root permissions.
If you see a "No package available" error, double-check that you typed amazon-efs-utils with hyphens, not underscores.

help me troubleshoot the amazon-efs-utils install on my Amazon Linux 2023 EC2 instance

Attempt to mount the file system

Everything is in place. Your EFS file system exists in the cloud, the mount helper is installed on your server, and your mount point directory is ready.

Mount your EFS file system by running this command:

Before you run it, take a moment to predict. Do you think the mount will succeed on the first try?

sudo mount -t efs [[EFS_ID="fs-0abc123def456"]]:/ /mnt/efs

The command hangs. Your server is sending a connection request to the EFS mount target on NFS port 2049, but it gets no response.

Wait for it to time out (this takes 1-2 minutes) or press Ctrl+C to cancel early. You'll see mount.nfs4: Connection timed out.

This timeout is expected

The mount failed because something in the network is blocking traffic between your server and the EFS mount target. You now have a real troubleshooting scenario on your hands.

Do not try to fix this yet. In the next step, you'll apply a structured troubleshooting process to diagnose the exact root cause, the same methodology that AWS interviewers want to hear about.

Seeing a different error?

If you see "No such file or directory", make sure the /mnt/efs directory exists. Run ls /mnt to check.
If you see "Failed to resolve", double-check that you used your actual file system ID (starting with fs-) and that you waited at least 90 seconds after creating the file system.

help me troubleshoot my EFS mount command on Amazon Linux 2023

You've hit a real networking problem. In the next step, you'll work backwards from this error through the network layers to find and fix the root cause.

Troubleshoot and Fix the Mount Failure

Your mount command timed out in the last step. Something is blocking the connection between your server and the EFS file system, but the command gave you nothing to go on.

In this step, you'll apply a structured troubleshooting process to find the root cause. You'll start from the error, identify what network layer it occurred at, and work backwards through the stack.

This is exactly the kind of troubleshooting methodology that AWS interviewers want to hear about.

In this step, get ready to:

Diagnose the mount failure by working backwards from the error through network layers.
Fix the root cause and successfully mount the EFS file system.
Write and read data on the shared storage to confirm everything works.

Diagnose the problem by working backwards from the error

The mount timed out with no error message. Your server sent a connection request and got nothing back. This is a classic Layer 4 (Transport layer) symptom.

EFS uses NFS (Network File System), which runs on TCP port 2049. Something is preventing your server from reaching that port on the EFS mount target.

In your SSH session, confirm there are no NFS connections by running:

ss -tn

You'll see your active SSH connection on port 22, but nothing on port 2049. That confirms your server never established a connection to the EFS mount target.

The connection is failing at the infrastructure level. Time to investigate the mount target's security group in the AWS Console.

Switch to your browser and return to the AWS Console.
Search for EFS in the services search bar and open the Amazon EFS console.
Click on your shared-storage file system.
Click the Network tab.
Find the mount target entry and click its Security group ID link.
Click the Inbound rules tab.

Look at the inbound rules. The default VPC security group only allows inbound traffic from itself. Its own security group ID is listed as the source.

What went wrong?

The EFS mount target uses the default VPC security group. Your EC2 instance uses a different security group, the one the launch wizard created when you launched the instance (with SSH access on port 22).

Because these are different security groups, NFS traffic from your instance on port 2049 is not allowed through to the mount target. That is why the mount command hung and eventually timed out.

Fix the security group and retry the mount

Now that you know the root cause, the fix is straightforward. You need to add an inbound rule to the mount target's security group that allows NFS traffic on port 2049 from your EC2 instance's security group.

First, you need to find your EC2 instance's security group ID so you can use it as the source.

Open the EC2 console in a new browser tab.
Click Instances in the left sidebar.
Click on your linux-lab instance.
Click the Security tab and note the Security group ID (it starts with sg-): your EC2 security group ID.

With your EC2 security group ID noted, you are ready to update the mount target's security group.

Switch back to the browser tab with the mount target's security group.
Click Edit inbound rules.
Click Add rule.
Set Type to NFS. This auto-fills the protocol as TCP and the port as 2049.
In the Source field, search for and select the security group ID of your EC2 instance (your EC2 security group ID).
Click Save rules.

What did you just change?

You told the mount target's security group to accept incoming NFS traffic on TCP port 2049, but only when it comes from your EC2 instance's security group. Security groups filter traffic based on source, protocol, and port.

Before this change, the mount target only accepted traffic from its own security group. Your EC2 instance belonged to a different one, so every NFS connection attempt was silently dropped.

Before you retry the mount, do you think it will succeed this time? What changed between now and your last attempt?

Switch back to your SSH session and retry the mount by running:

sudo mount -t efs [[EFS_FS_ID="fs-0abc123def456"]]:/ /mnt/efs

This time the command completes without hanging. The security group now allows NFS traffic through, so TCP can establish a connection on port 2049.

Mount still timing out?

Double check that the inbound rule's Source is your EC2 instance's security group ID, not a CIDR block or a different security group.
Make sure the rule's Type is set to NFS (TCP port 2049), not a custom TCP rule with a different port number.
Confirm that the rule was saved. Click Inbound rules on the security group page and verify the new NFS rule appears in the list.

Help me troubleshoot my EFS mount failure after updating the security group.

Write and read data on your shared storage

The file system is mounted. Time to prove it works by writing and reading real data.

Create a file on the mounted storage by running:

sudo bash -c 'echo "Hello from server 1" > /mnt/efs/hello.txt'

Why use sudo bash -c here?

The EFS mount point is owned by root, so you need elevated permissions to write to it. Wrapping the entire command in sudo bash -c '...' ensures the redirect (>) also runs with root permissions.

Read the file back by running:

cat /mnt/efs/hello.txt

You should see Hello from server 1 printed to the terminal. This data is stored on the EFS file system, not on your server's local disk.

Before you run the next command, what do you expect to see when you check your server's mounted file systems?

Verify the mount is listed by running:

df -h | grep efs

You should see your EFS file system listed as mounted at /mnt/efs with a very large total capacity displayed. EFS is elastic, so it reports a large available size even though you are only using a few bytes.

What did you just prove?

You diagnosed a real networking problem using a structured process. You started from the symptom (mount timeout), identified the network layer (Layer 4, TCP), and worked backwards through the infrastructure to find the root cause (security group blocking port 2049).

You can now walk an interviewer through each step and explain your reasoning, because you did it yourself.

Don't see EFS in the output?

If df -h | grep efs returns nothing, the mount may not have completed successfully. Run df -h without the filter to see all mounted file systems and look for your EFS entry.
If the EFS entry is missing entirely, retry the mount command from the previous substep and watch for any error messages this time.

Help me verify that my EFS file system is mounted correctly.

Your EFS file system is mounted and working. In the Secret Mission, you'll put shared storage to the real test by mounting it on a second server and proving both machines can read and write to the same files.

Secret mission

Share Storage Between Two Servers

You've mounted shared storage on one server. Now prove it actually works as shared storage. Launch a second server, mount the same file system, and show that files written on one machine appear on the other instantly.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses free-tier eligible EC2 instances and an Amazon EFS file system, both of which can accumulate charges if your free tier has expired.

Cost warning

If your AWS free tier has expired, each EC2 instance costs approximately $0.01/hour and EFS Standard storage costs $0.30/GB-month in us-east-1. If you are not planning to continue practicing, delete your resources to avoid unexpected charges.

Resources you used:

EC2 instances: linux-lab and, if you completed the Secret Mission, your second instance.
EFS file system: shared-storage with its mount targets.
Security groups: the launch wizard security group(s) created for your EC2 instances, plus the NFS inbound rules you added to the mount target security group.
Key pair: the AWS key pair and the .pem file on your local machine.

Keep everything running

No action needed. Choose this if you are still actively practicing Linux commands or networking on your servers.

Your EC2 instances will continue running and your EFS file system will remain mounted.
Both EC2 and EFS are free-tier eligible, but charges apply once your free tier window expires.
The key pair and security groups do not incur any cost.

Pause - I'll come back to this later

Stop your EC2 instances to pause compute charges. Your files and configuration stay intact so you can resume later.

In the EC2 console, select your linux-lab instance.
Click Instance state, then Stop instance.
Click Stop when prompted for confirmation.
Repeat for your second instance if you completed the Secret Mission.
Stopped instances do not incur compute charges, but EBS storage charges continue at minimal cost.
EFS charges continue for stored data, though your usage is well within the 5 GB free tier allowance.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow these steps in order.

In the EC2 console, select your linux-lab instance.
Click Instance state, then Terminate (delete) instance.
Click Terminate (delete) when prompted for confirmation.
Repeat for your second instance if you completed the Secret Mission.
Open the Amazon EFS console.
Select your shared-storage file system, then click Actions and Delete file system.
Enter the file system ID when prompted and click Delete File System to confirm. The console automatically deletes the associated mount targets for you.
Back in the EC2 console, go to Security Groups under Network & Security in the left sidebar.
Delete any launch wizard security groups that were created for your EC2 instances during this project.
Remove the NFS inbound rules (port 2049) you added to the default VPC security group. Do not delete the default security group itself.
Go to Key Pairs under Network & Security.
Select your key pair, click Actions, then Delete. Enter Delete in the confirmation field and click Delete.
Delete the .pem file from your local machine.

Nice Work!

Nice work! You just launched a Linux server in the cloud, operated it with real commands, and diagnosed a networking problem the same way an ADC engineer would on the job.

You've learned how to:

Launched a Linux server on Amazon EC2, connected via SSH, and navigated the filesystem with commands like ls, cd, cat, systemctl, journalctl, df, free, and ip addr.
Traced DNS resolution with dig and captured a live TCP 3-way handshake with tcpdump, mapping real network activity to all 7 layers of the OSI model.
Diagnosed and fixed a real Amazon EFS mount failure by working backwards from a timeout error to discover a security group blocking NFS traffic on port 2049.
Secret Mission: Completed an optional challenge to push your skills further.

Ready to quiz yourself?