Build a Multi-AZ Shared File System

Mount one EFS file system on two EC2 instances across Availability Zones.

Introduction

30 Second Summary

Think about how teams share files on a network drive at work. Everyone accesses the same folder from their own computer, and changes show up instantly for everyone else.

In this project, you will create a shared file system using Amazon EFS and mount it on two EC2 instances in different Availability Zones. You'll write a file on one instance and read it from the other, proving shared access works in real time.

What You'll Build

A Regional EFS file system mounted simultaneously on two Amazon Linux EC2 instances in different Availability Zones, with encryption at rest and in transit, lifecycle policies, and a security group configured for NFS access.

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

A working EFS file system mounted on two EC2 instances that share files across Availability Zones in real time.
A security group configured for NFS traffic, restricting file system access to only your instances.
Hands-on experience with encryption, performance modes, throughput modes, and lifecycle policies for cost optimization.
Secret Mission: Create a One Zone EFS file system and document the Regional vs One Zone tradeoffs for exam preparation.

Are there any prerequisites?

You need an AWS account with console access and basic familiarity with launching EC2 instances and configuring security groups. You will also need an SSH client for connecting to Linux instances from your local machine.

Launch Two EC2 Instances in Different Availability Zones

To prove that Amazon EFS provides shared file access across multiple servers, you need at least two EC2 instances in different Availability Zones. If both instances can read and write the same files, you know EFS is working as a truly shared file system.

In this step, you will launch two Amazon Linux 2023 instances in your default VPC. Each instance goes into a different Availability Zone, setting up the multi-AZ architecture you will need to test EFS.

In this step, get ready to:

Launch EFS-Instance-A in Availability Zone A.
Launch EFS-Instance-B in Availability Zone B.
Verify both instances are running in different Availability Zones within the same VPC.

Launch your first EC2 instance

Your first instance will live in one Availability Zone. You will name it EFS-Instance-A so you can easily identify which AZ it belongs to later.

Sign in to the AWS Management Console.
In the search bar at the top, type EC2 and select EC2 from the results.
Click Launch instance.
Under Name and tags, enter EFS-Instance-A.
Under Application and OS Images (Amazon Machine Image), confirm that Amazon Linux 2023 AMI is selected. This is the default.
Under Instance type, select t2.micro (or t3.micro if t2.micro is unavailable in your region). Both are free tier eligible.
Under Key pair (login), select an existing key pair or click Create new key pair.

Creating a new key pair?

If you create a new key pair, give it a name like efs-lab-key. Leave the key pair type as RSA and the file format as .pem (for macOS/Linux) or .ppk (for Windows with PuTTY).

The key file downloads automatically. Save it somewhere you can find it later. You will need this file to SSH into your instances.

Now you need to place this instance in a specific Availability Zone.

Under Network settings, click Edit.
Confirm that the VPC is set to your default VPC.
In the Subnet dropdown, select a subnet that ends in a (for example, us-east-1a or ap-southeast-2a). This places your instance in Availability Zone A of your region.
Under Firewall (security groups), select Select existing security group and choose your default security group. This allows SSH access.
Leave all other settings as default.
Click Launch instance.

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

Why a specific Availability Zone?

Each AWS region has multiple Availability Zones, which are physically separate data centers. By placing your two instances in different AZs, you simulate a real production setup where servers run across fault-isolated locations.

EFS creates a mount target in each AZ so every instance gets low-latency access to the shared file system. This is a key differentiator from EBS, which is locked to a single AZ.

Launch your second EC2 instance

Your second instance follows the same process, but you will place it in a different Availability Zone. This is the instance that will prove shared access works across AZs.

Go back to the EC2 dashboard and click Launch instance again.
Under Name and tags, enter EFS-Instance-B.
Select the same AMI: Amazon Linux 2023 AMI.
Select the same instance type: t2.micro (or t3.micro).
Under Key pair (login), select the same key pair you used for EFS-Instance-A.
Under Network settings, click Edit.
Confirm the VPC is the same default VPC you used for Instance A.
In the Subnet dropdown, select a subnet that ends in b (for example, us-east-1b or ap-southeast-2b). This places your instance in Availability Zone B.
Under Firewall (security groups), select Select existing security group and choose the same default security group.
Click Launch instance.

Use the same key pair for both instances

Using the same key pair means you only need one .pem file to SSH into both instances. This simplifies your workflow when switching between them to test shared file access.

Verify both instances are running

In the EC2 dashboard, click Instances in the left sidebar.
Wait until both EFS-Instance-A and EFS-Instance-B show Running in the Instance state column. This may take 1-2 minutes.
Click on EFS-Instance-A and check the Availability Zone in the Networking tab. Confirm it ends in a.
Click on EFS-Instance-B and confirm its Availability Zone ends in b.
Confirm both instances are in the same VPC by checking the VPC ID in each instance's Networking tab. The VPC IDs should match.

Instance stuck in Pending state?

If an instance stays in Pending for more than 2 minutes, try refreshing the instances list by clicking the refresh icon in the top right of the instances table.

If you see an error about instance limits, your account may have reached its t2.micro limit. Try using t3.micro instead, or terminate any unused instances in your account first.

Need more help? Help me troubleshoot my EC2 instance launch.

Your two instances are running in different Availability Zones within the same VPC. Next up, you will create a security group that controls which resources can talk to your EFS file system over the NFS protocol.

Create a Security Group for EFS and Configure NFS Access

Your two EC2 instances are up and running in different Availability Zones. Now you need to set up the network rules that will allow them to talk to your EFS file system.

EFS uses the NFS protocol (Network File System) to serve files over the network. NFS communicates on TCP port 2049. By default, security groups block all inbound traffic, so you need to explicitly allow this port before your instances can mount the file system.

In this step, get ready to:

Create a security group named EFS-SG with a self-referencing NFS inbound rule.
Attach EFS-SG to both EC2 instances as an additional security group.
Verify both instances have the correct security group configuration.

Create the EFS-SG security group

The standard security pattern for EFS is to create a dedicated security group that references itself as the traffic source. This means only resources that belong to this same security group can send NFS traffic to each other.

In the AWS Management Console, type EC2 in the top search bar and select EC2.
In the left sidebar, scroll down to the Network & Security section and click Security Groups.
Click Create security group in the top right corner.
Enter EFS-SG in the Security group name field.
Enter Allow NFS traffic for EFS in the Description field.
In the VPC dropdown, select the same default VPC that your EC2 instances are in.

Now add the inbound rule that allows NFS traffic.

In the Inbound rules section, click Add rule.
Set the Type dropdown to NFS. This automatically sets the protocol to TCP and the port to 2049.
In the Source field, click the search box and start typing EFS-SG. Select the EFS-SG security group you are currently creating (it will appear in the dropdown even before saving).
Remove any rules in the Outbound rules section. Leave the default rule that allows all outbound traffic.
Click Create security group.

You should see a success banner confirming that EFS-SG was created.

What is a self-referencing security group?

When you set the source of EFS-SG's inbound rule to EFS-SG itself, you're saying: "Only resources that have this same security group attached can send NFS traffic on port 2049."

This is the standard pattern for EFS. You'll attach EFS-SG to both your EC2 instances AND the EFS mount targets later. That way, your instances and EFS can communicate, but nothing else on the network can access your file system.

Can't find EFS-SG in the Source dropdown?

Make sure you typed the security group name in the Security group name field above before trying to reference it in the inbound rule. AWS needs the name to exist first.

Also confirm you selected the correct VPC. The security group only appears in the Source dropdown if it belongs to the same VPC.

help me find my security group in the Source dropdown

Attach EFS-SG to both EC2 instances

Your instances currently have only their original security group (which allows SSH access). You need to add EFS-SG as an additional security group on both instances so they become members of the self-referencing group.

In the EC2 console left sidebar, click Instances.
Select EFS-Instance-A by clicking its checkbox.
Click Actions in the top menu bar.
Select Security, then Change security groups.
In the search box under Associated security groups, type EFS-SG and select it from the results.
Click Add security group. You should now see both the original security group and EFS-SG listed.
Click Save.

Now repeat the same process for the second instance.

Go back to the Instances list and select EFS-Instance-B.
Click Actions, then Security, then Change security groups.
Search for EFS-SG, select it, and click Add security group.
Click Save.

Why attach the same security group to both instances AND EFS?

In the next step, you'll create EFS mount targets and assign them EFS-SG. The mount target's inbound rule says "allow NFS from EFS-SG." For your EC2 instances to match that rule, they must also belong to EFS-SG.

This is a common SAA-C03 exam pattern. The self-referencing security group ensures that only resources you explicitly grant membership can communicate over NFS.

Verify the security group configuration

In the Instances list, click on EFS-Instance-A to open its details.
Click the Security tab at the bottom of the page.
Confirm you see two security groups listed: your original SSH security group and EFS-SG.
Repeat the same check for EFS-Instance-B. It should also show both security groups.

Navigate back to Security Groups in the left sidebar.
Click on EFS-SG to view its details.
Click the Inbound rules tab and confirm the rule shows Type: NFS, Protocol: TCP, Port range: 2049, Source: the security group ID of EFS-SG itself.

Only see one security group on an instance?

Make sure you clicked Add security group after selecting EFS-SG. Simply searching for it is not enough. The security group must appear in the list above the search box before you click Save.

If you accidentally removed the original security group, add it back using the same process. Your instances need both groups: the original for SSH access and EFS-SG for NFS access.

help me fix my security group configuration

Your network security is locked in. Both instances are now members of the EFS-SG group, which means they'll be authorized to communicate with EFS mount targets that use the same group. Next up, you'll create the EFS file system itself and assign this security group to its mount targets.

Create a Regional EFS File System with Encryption at Rest

Your networking layer is ready. Both EC2 instances have the EFS-SG security group attached, and that security group allows NFS traffic between members. Now it is time to create the actual file system they will share.

Amazon EFS provides shared file storage that multiple EC2 instances can access simultaneously over the NFS protocol. In this step, you will create a Regional file system with encryption at rest enabled and connect it to your VPC through mount targets in each Availability Zone.

In this step, get ready to:

Create a Regional EFS file system with encryption at rest.
Configure performance and throughput modes for the file system.
Assign the EFS-SG security group to mount targets in each Availability Zone.

Open the EFS console and start creating a file system

EFS offers a Quick Create option, but you will use the Customize path instead. This gives you control over encryption, performance mode, throughput mode, and network settings.

In the AWS Management Console, search for and open the EFS service.
Click Create file system.
In the dialog that appears, click Customize instead of the Quick Create button.

You are now on the General settings page. Configure the following options:

Enter SAA-C03-EFS-Lab in the Name field.
Under File system type, select Regional. This stores your data redundantly across multiple Availability Zones.
Check the box for Enable encryption of data at rest. Leave the KMS key set to the default aws/elasticfilesystem key.
Under Throughput mode, confirm Elastic is selected. This auto-scales throughput based on your workload.
Under Performance mode, confirm General Purpose is selected. This provides sub-millisecond read latency for most workloads.
Click Next to proceed to the Network settings.

What is encryption at rest?

Encryption at rest means all data written to the file system is automatically encrypted before being stored on disk. EFS uses an AWS-managed KMS key to handle this transparently.

This setting cannot be changed after creation. The SAA-C03 exam tests this fact. If a question mentions encryption at rest for EFS, the answer always involves enabling it at creation time.

Why General Purpose over Max I/O?

General Purpose is the recommended mode for latency-sensitive workloads like web serving, CMS, and home directories. Max I/O supports thousands of concurrent connections for big data and media processing, but with slightly higher latency.

You cannot change the performance mode after creation. The exam frequently tests this constraint.

Configure mount targets with the EFS security group

Mount targets are the network endpoints that EC2 instances use to connect to your file system. EFS creates one mount target per Availability Zone. Each mount target needs the correct security group to allow NFS traffic from your instances.

On the Network page, confirm the VPC is set to your default VPC (the same VPC your EC2 instances are in).
For each mount target listed (one per Availability Zone), click the X next to the default security group to remove it.
In the Security groups dropdown for each mount target, select EFS-SG.
Repeat this for every mount target in the list. Each one must have only EFS-SG assigned.
Click Next.

Why replace the default security group?

The default security group allows all outbound traffic and all inbound traffic from members of itself. Replacing it with EFS-SG ensures only your EC2 instances (which also have EFS-SG attached) can reach the file system on port 2049. This is the least-privilege pattern the SAA-C03 exam expects.

Complete creation and note your file system ID

On the File system policy page, leave the defaults and click Next.
On the Review and create page, verify your settings: Regional type, encryption at rest enabled, Elastic throughput, General Purpose performance, and EFS-SG on all mount targets.
Click Create.
Wait for the file system status to change from Creating to Available. This typically takes 30-60 seconds.
Note your File system ID (it starts with fs- followed by a string of characters). You will need this ID to mount the file system in the next step.

Check your mount targets too

Click on your file system name, then select the Network tab. Verify that each mount target shows Available status and has EFS-SG listed as its security group. Mount targets need about 60 seconds for DNS propagation after creation.

File system stuck in Creating?

If your file system stays in the Creating state for more than two minutes, refresh the page. If it shows an error, confirm that the VPC you selected has subnets in multiple Availability Zones and that the EFS-SG security group exists in that same VPC.

Help me troubleshoot my EFS file system creation

Your shared file system is live and connected to your VPC through mount targets in each Availability Zone. Next, you will SSH into both EC2 instances and mount this file system to prove that two instances in different AZs can read and write the same files in real time.

Mount EFS on Both Instances and Prove Shared Access

Your EFS file system is created and the networking is configured. Now comes the real test: mounting the shared file system on both EC2 instances and proving that a file written on one instance appears instantly on the other.

You will use the EFS mount helper to connect each instance to the file system with encryption in transit enabled. The -o tls flag secures data as it travels over the network using TLS 1.2. This is a separate layer from the encryption at rest you already enabled.

In this step, get ready to:

Install the EFS mount helper and mount the file system on Instance A with encryption in transit.
Mount the same file system on Instance B and read a file created on Instance A.
Confirm bi-directional shared access works across Availability Zones.

Install the EFS mount helper and mount on Instance A

The EFS mount helper is a utility that simplifies mounting EFS file systems. It handles NFS connections and TLS encryption under the hood using stunnel.

Open a terminal window and SSH into EFS-Instance-A by running this command:

ssh -i [[PEMPATH="path to your .pem key file"]] ec2-user@[[EC2A_PUBLIC_IP="EFS-Instance-A public IPv4 address"]]

Find your public IP

In the EC2 console, select EFS-Instance-A and find the Public IPv4 address in the instance details panel.

Connection timed out?

Make sure your EC2 instance's original security group allows inbound SSH (port 22) from your IP address. Also confirm the instance is in a Running state.

Help me troubleshoot my SSH connection to EC2

Once connected, install the EFS mount helper by running:

sudo yum install -y amazon-efs-utils

What is amazon-efs-utils?

This package provides the mount.efs command, which handles NFS connections and TLS encryption automatically. Without it, you would need to configure stunnel and NFS mount options manually.

You should see output ending with "Complete!" confirming the installation succeeded.
Create the mount point directory by running:

sudo mkdir /mnt/efs

Now mount the EFS file system with encryption in transit enabled. The -o tls flag tells the mount helper to create a TLS 1.2 tunnel for all data in transit.

Mount your EFS file system by running:

sudo mount -t efs -o tls [[EFS_ID="your EFS file system ID (e.g. fs-01234abcdef)"]]:/ /mnt/efs

What does this command do?

mount -t efs tells Linux to use the EFS mount helper instead of standard NFS tools.

-o tls enables encryption in transit. The mount helper launches stunnel behind the scenes to wrap all NFS traffic in a TLS 1.2 tunnel over port 2049.

The :/ after the file system ID means you are mounting the root of the file system.

Find your file system ID

In the EFS console, select your SAA-C03-EFS-Lab file system. The file system ID (starting with fs-) is shown at the top of the details page.

The mount command may take a few seconds to complete. If it returns with no error, the mount was successful.
Create a test file on the shared file system by running:

sudo bash -c 'echo "Hello from Instance A" > /mnt/efs/shared-test.txt'

Verify the file was created by running:

cat /mnt/efs/shared-test.txt

You should see Hello from Instance A printed in your terminal. This file now lives on EFS, not on the local disk.

Mount command failed?

If you see "Connection timed out" or "mount.nfs: Connection reset by peer", check that the EFS-SG security group is attached to both the EFS mount targets AND your EC2 instance. The self-referencing inbound rule on port 2049 only works if both sides share the same security group.

Also wait at least 60 seconds after EFS file system creation for DNS propagation to complete.

Help me troubleshoot my EFS mount failure

Mount on Instance B and read the shared file

Now for the real test. If EFS is truly shared storage, Instance B in a completely different Availability Zone should be able to read the file you just created on Instance A.

Open a new terminal window (keep your Instance A session open).
SSH into EFS-Instance-B by running:

ssh -i [[PEMPATH="path to your .pem key file"]] ec2-user@[[EC2B_PUBLIC_IP="EFS-Instance-B public IPv4 address"]]

Install the EFS mount helper, create the mount point, and mount the file system by running these three commands:

sudo yum install -y amazon-efs-utils
sudo mkdir /mnt/efs
sudo mount -t efs -o tls [[EFS_ID="your EFS file system ID (e.g. fs-01234abcdef)"]]:/ /mnt/efs

Why the same commands?

Each EC2 instance needs its own mount helper installed and its own mount point directory. The file system ID is the same because both instances are connecting to the same EFS file system through their respective AZ's mount target.

Wait for all three commands to finish. You should see "Complete!" after the install and no errors from the mount.
Read the file that Instance A created by running:

cat /mnt/efs/shared-test.txt

You should see Hello from Instance A in the output. This file was written by a completely different EC2 instance in a different Availability Zone. Both instances are reading from the same underlying storage.

Now write a file from Instance B by running:

sudo bash -c 'echo "Hello from Instance B" > /mnt/efs/instance-b-file.txt'

Verify the file exists by running:

ls /mnt/efs/

You should see both shared-test.txt and instance-b-file.txt listed in the output.

Confirm bi-directional access from Instance A

Shared storage must work in both directions. Instance A should be able to read files that Instance B created, not just the other way around.

Switch back to your Instance A terminal window.
Read the file that Instance B just created by running:

cat /mnt/efs/instance-b-file.txt

You should see Hello from Instance B in the output. This confirms bi-directional shared access across Availability Zones.

Check the file system mount information by running this command on Instance A:

df -h /mnt/efs

What does df -h show?

The df -h command displays disk usage in human-readable format. For EFS, you will see a very large total size (8.0E or similar). This is because EFS does not require you to pre-provision capacity. It scales automatically and you pay only for what you store.

Run the same command on Instance B to confirm both instances see the same file system information:

df -h /mnt/efs

Both instances report the same file system size and mount point, confirming they are connected to the same underlying EFS storage.

Why does this matter for the SAA-C03 exam?

You just demonstrated the core feature that differentiates EFS from EBS. EFS supports concurrent access from multiple instances across multiple AZs using the NFS protocol. EBS volumes attach to a single instance as block storage.

Exam questions often describe a scenario with multiple EC2 instances needing shared file access. The answer is almost always EFS. If the scenario mentions Windows, the answer is FSx for Windows File Server instead, because EFS only supports Linux.

You have a fully working shared file system with encrypted connections. Next, you will explore the performance, throughput, and storage class settings that the SAA-C03 exam tests heavily.

Explore Performance Modes, Throughput Modes, and Storage Classes

You just proved that two EC2 instances in different Availability Zones can read and write to the same file system in real time.

Now it's time to understand the settings that control how your EFS file system performs and how much it costs. The SAA-C03 exam heavily tests your ability to choose the right performance mode, throughput mode, and storage class for a given workload.

In this step, you will explore your file system's configuration in the console and set up lifecycle policies that automatically move infrequently accessed files to cheaper storage classes.

In this step, get ready to:

Review performance modes (General Purpose vs Max I/O) and understand when to use each.
Examine throughput modes (Elastic, Provisioned, Bursting) and their billing implications.
Configure lifecycle policies to transition files between storage classes for cost optimization.

Review performance modes in the EFS console

EFS offers two performance modes that determine latency and concurrency characteristics. This is a setting you lock in at creation time and cannot change later.

Open the EFS console in your AWS Management Console.
Click on your file system SAA-C03-EFS-Lab to open its details page.
In the General section, locate the Performance mode field.
Confirm it shows General Purpose.

What are the two performance modes?

General Purpose provides sub-millisecond read latency and single-digit millisecond write latency. It is ideal for latency-sensitive workloads like web serving, content management systems, and home directories.

Max I/O supports thousands of concurrent compute instances accessing the file system simultaneously. It is designed for big data analytics and media processing workloads, but comes with slightly higher latency.

You cannot change the performance mode after creation. The exam tests this constraint frequently.

Examine throughput modes and their billing models

Unlike performance modes, throughput modes can be switched after creation. Each mode has a different billing model that the exam expects you to match to workload patterns.

On the same file system details page, locate the Throughput mode field in the General section.
Confirm it shows Elastic.

What are the three throughput modes?

Elastic (the default) automatically scales throughput up and down based on your workload. You only pay for what you use, making it the recommended choice for most workloads.

Provisioned lets you configure a fixed throughput level. You are billed for the provisioned amount whether you use it or not. Use this for predictable, consistently high-throughput workloads.

Bursting scales throughput with the size of your file system using burst credits. Larger file systems get more baseline throughput and accumulate credits faster.

You can switch between throughput modes after creation. This is a key difference from performance modes, which are locked at creation.

Configure lifecycle policies for cost optimization

EFS storage classes let you dramatically reduce costs by moving infrequently accessed files to cheaper tiers. Lifecycle policies automate this transition based on how recently a file was accessed.

On your file system's details page, click the Lifecycle management section (or scroll down to find it).
Click Edit to modify the lifecycle policy.
Set Transition into IA to 30 days since last access.
Set Transition into Archive to 90 days since last access.
Click Save changes.

Your lifecycle policy is now active. Files that haven't been accessed for 30 days will automatically move to Infrequent Access, and files untouched for 90 days will move to Archive.

What are the EFS storage classes and their pricing?

Standard provides SSD-backed storage with sub-millisecond latency. It costs roughly $0.30/GB-month in us-east-1.

Infrequent Access (IA) is up to 95% cheaper than Standard, at roughly $0.016/GB-month. It charges a small per-access fee when files are read.

Archive is the cheapest tier at $0.008/GB-month in us-east-1. It is up to 50% cheaper than IA and designed for data accessed only a few times per year.

The exam frequently tests your ability to pick the right storage class for a given access pattern and match it with the correct lifecycle policy.

Don't see the Lifecycle management section?

Make sure you are on the file system's detail page, not the EFS dashboard. Click the file system ID or name to navigate into the detail view.

If you don't see an Edit button, check that you are signed in with a user that has EFS write permissions.

Help me find the lifecycle management settings for my EFS file system.

You now understand the three configuration dimensions that the SAA-C03 exam tests for EFS: performance modes, throughput modes, and storage classes with lifecycle policies. Next up, you will compare EFS directly against EBS from the command line to solidify the differences the exam loves to test.

Compare EFS vs EBS and Review Exam-Critical Differences

In the previous step, you configured performance modes, throughput modes, and lifecycle policies for your EFS file system.

Now it's time to put everything together by comparing EFS and EBS side by side.

The SAA-C03 exam loves asking you to pick the right storage service for a given workload. You already have both EBS and EFS visible on your instance, so you can see the difference firsthand rather than just memorizing a comparison table.

In this step, get ready to:

View EBS and EFS storage side by side on your EC2 instance using Linux commands.
Review the exam-critical differences between EFS and EBS.
Check EFS metered size to understand its pay-per-use pricing model.

View EBS and EFS storage on your instance

Your EC2 instance has two types of storage attached right now. The EBS root volume is a block device that came with the instance. The EFS file system is a network mount you added manually.

SSH into EFS-Instance-A (the same way you connected in the previous step).
View the block devices attached to your instance by running this command:

lsblk

What does this command do?

lsblk lists all block devices (physical and virtual disks) attached to your instance. You'll see the EBS root volume (usually named xvda or nvme0n1) with its partitions.

Notice that EFS does NOT appear here. That's because EFS is a network file system (NFS), not a block device. This is the fundamental difference the exam tests.

Now view all mounted file systems (including both EBS and EFS) by running:

df -h

You should see both your EBS root volume (mounted at /) and your EFS file system (mounted at /mnt/efs).

What should I see?

The EBS volume shows a fixed size (8 GB for the default root volume). The EFS mount shows 8.0E (8 exabytes) as the total size because EFS scales automatically with no fixed capacity limit.

This visual difference is a great way to remember the exam point. EBS has a provisioned fixed size. EFS has effectively unlimited capacity that grows and shrinks automatically.

Don't see /mnt/efs in the output?

If EFS doesn't appear in df -h, your mount may have dropped. Re-run the mount command from Step 4 to reconnect it.

help me troubleshoot why my EFS mount is not showing in df -h output

Review the exam-critical EFS vs EBS comparison

You just saw the difference between block storage and network file storage on a live instance. Here's a summary of the key comparison points the SAA-C03 exam tests.

EFS vs EBS: what the exam tests

Protocol: EFS uses the NFS protocol (NFSv4.0 and NFSv4.1). It works only with Linux. EBS is block storage that works with any OS.
Access: EFS is accessible from thousands of instances simultaneously across multiple Availability Zones. EBS attaches to one instance at a time (unless using Multi-Attach with io1/io2 volumes in the same AZ).
Scaling: EFS scales automatically with no pre-provisioning. EBS requires you to provision a fixed volume size upfront.
Pricing: EFS charges per GB stored (pay only for what you use). EBS charges per GB provisioned (pay for the full volume size whether it's full or empty).
Windows support: EFS does NOT support Windows. For shared Windows file storage, use FSx for Windows File Server. The exam uses this as a common distractor.

You verified each of these points during this project. EFS was mounted from two instances in different AZs. The df -h output showed EFS with unlimited capacity while EBS had a fixed 8 GB volume.

What about EBS Multi-Attach?

EBS Multi-Attach lets you attach an io1 or io2 volume to multiple instances, but only within the same Availability Zone. EFS works across AZs. The exam often uses Multi-Attach as a distractor when the question requires cross-AZ shared storage.

Check EFS metered size in the console

EFS only charges for data you actually store. Let's verify this by checking the metered size in the console.

Go back to the AWS Management Console.
Navigate to the EFS console.
Click on your file system SAA-C03-EFS-Lab.
Look for the Metered size value on the file system details page.

The metered size shows only the few bytes your test files occupy. This is what AWS bills you for.

Why does metered size matter for the exam?

A common SAA-C03 question pattern asks which storage service minimizes costs for workloads with unpredictable data growth. EFS is the answer because you pay only for stored data. With EBS, you pay for the full provisioned volume even if it's mostly empty.

Combined with lifecycle policies (moving cold data to IA at $0.016/GB-month or Archive at $0.008/GB-month), EFS provides automatic cost optimization without manual intervention.

Secret mission

Create a One Zone EFS File System and Document Regional vs One Zone Tradeoffs

You've mastered Regional EFS file systems. Now explore the cost-optimized alternative: One Zone file systems. Create one, mount it, and build an exam-ready cheat sheet comparing both architectures for the SAA-C03 exam.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. EC2 instances are free tier eligible (t2.micro/t3.micro), and EFS provides 5 GB of Standard storage free for 12 months on legacy accounts.

Cost warning

If your AWS free tier has expired, leaving EC2 instances running will incur hourly charges. EFS charges only for data stored (pennies for small test files), but EC2 compute adds up quickly.

If you are done experimenting, choose the Delete option below to bring your costs to $0.

Resources you used:

2 EC2 instances (EFS-Instance-A and EFS-Instance-B) in different Availability Zones.
1 Regional EFS file system (SAA-C03-EFS-Lab) with encryption at rest.
1 Security group (EFS-SG) allowing NFS traffic on port 2049.
1 Key pair for SSH access.

Keep everything running

No action needed. Choose this if you are still actively experimenting with EFS or plan to continue within the next hour.

Your EC2 instances will continue running and consuming free tier hours (or incurring charges if free tier is exhausted).
Your EFS file system will remain mounted and accessible.
EFS charges only for stored data, so a few test files cost fractions of a cent.

Pause - I'll come back to this later

Stop your EC2 instances to eliminate compute charges while keeping your EFS file system intact for later.

In the EC2 console, select both instances, then choose **Instance state** > **Stop instance**.
Your EFS file system will remain available. When you restart the instances later, you will need to remount EFS using the same mount commands.
Stopped instances do not incur compute charges, but their EBS root volumes still cost a small amount.

Delete - I don't want to use this again

Remove all project resources to bring your costs to $0.

SSH into each running instance and unmount EFS first by running: sudo umount /mnt/efs.
In the EC2 console, select both instances, then choose **Instance state** > **Terminate instance**.
In the EFS console, select your SAA-C03-EFS-Lab file system and click **Delete**. Type the file system ID to confirm deletion.
In the VPC or EC2 console under **Security Groups**, find EFS-SG and delete it.
Optionally delete the key pair in the EC2 console under **Key Pairs** if you no longer need it.

Nice Work!

You just built and explored a production-grade shared file system on AWS using Amazon EFS. You now have hands-on intuition for the storage decision questions that appear across all four SAA-C03 exam domains.

You've learned how to:

Create a Regional EFS file system with encryption at rest and mount it on two EC2 instances in different Availability Zones, proving shared file access works in real time.
Configure NFS security groups, encryption in transit via TLS, and lifecycle policies for automatic cost optimization across Standard, IA, and Archive storage classes.
Compare EFS vs EBS across pricing, performance, and multi-instance access patterns to build exam-ready decision-making skills.
Secret Mission: Created a One Zone file system and documented the Regional vs One Zone tradeoffs for SAA-C03 exam preparation.

Ready to quiz yourself?