Bridge On-Prem Storage with S3 Gateway

Deploy an S3 File Gateway on EC2 and mount it as a local NFS drive.

Introduction

30 Second Summary

Every business has files stored on local servers. Moving those files to the cloud sounds great for durability and cost savings, but nobody wants to retrain their team on a completely new way to save and access documents.

In this project, you will deploy an AWS Storage Gateway that bridges local file storage with Amazon S3. You'll create an NFS file share on an S3 File Gateway running on EC2, then transfer files from a simulated on-premises client into your S3 bucket.

What You'll Build

Picture copying a file to what looks like a regular folder on a Linux server, then refreshing your S3 console and seeing that same file sitting in your bucket as a cloud object.

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

A running S3 File Gateway on EC2, activated and linked to your AWS account with dedicated cache storage buffering your most-accessed files for fast reads.
An NFS file share that turns your S3 bucket into what looks and feels like a mounted local directory on a Linux server.
A complete hybrid storage pipeline where you copy files to a local mount point on a simulated on-premises client and watch them appear as objects in your S3 bucket moments later.
Secret Mission: Add an S3 lifecycle policy to automatically tier aging data into cheaper storage classes like S3 Standard-IA and S3 Glacier.

Do I need any prior AWS experience?

This project assumes you have an AWS account and basic familiarity with EC2 and S3. The gateway runs on an m5.xlarge instance, which is not free-tier eligible, so plan for approximately $0.25-$0.50 in charges if you clean up within an hour.

Before We Start

Before diving into the AWS console, 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.

Set Up the S3 Bucket and Launch the Gateway Instance

Before you can bridge local storage to the cloud, you need two things: a destination bucket in S3 where your files will land, and a gateway appliance that translates between file protocols and object storage.

In this step, you will create an S3 bucket configured for Storage Gateway compatibility, then launch an EC2 instance running the gateway appliance with cache storage attached.

In this step, get ready to:

Create an S3 bucket with ACLs enabled for Storage Gateway compatibility.
Launch an m5.xlarge EC2 instance running the Storage Gateway AMI with 150 GiB of cache storage.
Begin the gateway setup process in the Storage Gateway console.

Create an S3 bucket with ACLs enabled

Your S3 bucket is the final destination for every file that flows through the gateway. Storage Gateway's default NFS file share configuration requires Access Control Lists (ACLs) to be enabled on the bucket.

Sign in to the AWS Management Console.
Use the search bar at the top to search for S3 and open the S3 console.
Click Create bucket.
Enter a unique bucket name such as nextwork-gateway- followed by your initials. Note your bucket name here: your-unique-bucket-name.
Leave the AWS Region set to your preferred region. Remember this region because your EC2 instances must be in the same one.
Scroll down to Object Ownership.
Select ACLs enabled.
Choose Bucket owner preferred.

Why enable ACLs?

New S3 buckets default to Bucket owner enforced, which disables ACLs entirely. Storage Gateway's default NFS file share configuration uses a "Guess MIME type" setting that requires ACLs to be turned on.

If you leave ACLs disabled, the file share you create later will remain stuck in an "Unavailable" state indefinitely. Enabling ACLs now prevents that issue.

Leave all other settings as their defaults.
Click Create bucket at the bottom of the page.

Your new bucket appears in the S3 bucket list.

Seeing a 'Bucket name already exists' error?

S3 bucket names are globally unique across all AWS accounts. Try adding extra characters to your bucket name, such as a date or random numbers.

help me fix my S3 bucket name error

Start creating the gateway and launch the EC2 instance

The S3 File Gateway runs as a virtual appliance on an EC2 instance. AWS provides a pre-built AMI (Amazon Machine Image) for it, so you do not need to install anything manually.

Use the search bar at the top of the console to search for Storage Gateway and open the Storage Gateway console.
Click Create gateway.
For Gateway name, enter a name such as nextwork-file-gateway.
For Gateway time zone, select the time zone for your location.
Under Gateway options, select Amazon S3 File Gateway as the Gateway type.
Under Platform options, select Amazon EC2 as the Host platform.
Click Launch instance.

What does Launch instance do?

Clicking Launch instance opens a new tab with the EC2 launch wizard. The Storage Gateway AMI is already pre-selected for you, so the instance will run the gateway software automatically.

Keep the Storage Gateway console tab open. You will return to it after the instance is running.

In the EC2 launch wizard that just opened, configure the instance settings.

In the Instance type section, select m5.xlarge.
Under Key pair (login), select an existing key pair or click Create new key pair to create one.
Under Network settings, click Edit.
Set Auto-assign public IP to Enable.
Under Firewall (security groups), select Create security group.
Enter gateway-sg as the Security group name.
Under Inbound security group rules, set Type to Custom TCP.
Set Port range to 80.

Set Source type to My IP.

Why port 80?

The gateway requires TCP port 80 to be open for a one-time HTTP activation step. After activation is complete, you can close this port. Opening only the ports you need, when you need them, follows the principle of least privilege.

Scroll down to Configure storage.
Click Add new volume.
Set the volume size to 150 GiB and the type to gp3.

Why 150 GiB of cache storage?

The gateway uses this EBS volume as a local cache to buffer frequently accessed data. This gives your "on-premises" client low-latency reads without fetching from S3 every time.

150 GiB is the minimum cache size required by AWS for the gateway to function properly.

Click Launch instance at the bottom of the page.

The EC2 console confirms that your instance is launching.

Why m5.xlarge?

AWS recommends m5.xlarge as the minimum instance type that meets the hardware requirements for the gateway to function properly. It provides 4 vCPUs and 16 GiB of memory. Smaller instances may cause the gateway to fail or perform unreliably.

Launch failed or instance not starting?

Make sure you selected m5.xlarge (not a smaller type) and that the Storage Gateway AMI is still selected at the top of the wizard. If you see a capacity error, try a different Availability Zone within the same region.

help me troubleshoot my EC2 instance launch failure for Storage Gateway

Verify the gateway instance and return to Storage Gateway

The instance needs to pass both its system status checks and instance status checks before you can activate the gateway. This typically takes one to two minutes.

In the EC2 console, click Instances in the left navigation pane.
Find your gateway instance in the list.
Wait until the Instance state column shows Running and the Status check column shows green check marks.
Click on your instance to open its details.
In the Instance summary section, copy the Public IPv4 address and paste it here: your gateway's public IP address.

What do you think will happen when you paste this IP address into the Storage Gateway setup wizard? Take a moment to consider before moving on.

Switch back to the Storage Gateway console tab you left open earlier.
Select the Confirm set up gateway checkbox.
Click Next to proceed to the connection setup page.

You should now see the Connect to AWS page in the Storage Gateway console. This confirms the setup phase is complete.

Instance stuck in Pending state?

Status checks can take a few minutes. Refresh the EC2 console page and wait for both checks to complete. If the instance stays in Pending for more than five minutes, check the Monitoring tab for any system-level errors.

help me troubleshoot my Storage Gateway EC2 instance that is stuck in Pending state

Your S3 bucket is ready and the gateway instance is running. Next up, you will activate the gateway and link it to your AWS account so it can start serving files.

Activate and Configure the File Gateway

Your S3 bucket is ready and the gateway instance is running with green status checks. But the Storage Gateway service in your AWS account has no connection to that EC2 instance yet.

Activation is the handshake that links the gateway appliance to your account. Once activated, you'll allocate the 150 GiB EBS volume as cache storage, which buffers frequently accessed data close to the gateway for low-latency reads.

In this step, get ready to:

Activate the S3 File Gateway by connecting it to your AWS account.
Allocate the 150 GiB disk as cache storage and configure CloudWatch monitoring.
Verify the gateway shows Running status in the console.

Connect the gateway to your AWS account

You should be on the Connect to AWS page in the Storage Gateway console. This is where you tell the gateway how to reach AWS services and provide the IP address so AWS can locate your gateway appliance.

Under Endpoint type for service access, select Publicly accessible.
Under Gateway connection options, select IP address.
Paste the gateway EC2 instance's public IP address into the IP address field.
Click Next.

What does Publicly accessible mean?

This tells the gateway to communicate with AWS services over the public internet. The alternative, VPC hosted, routes traffic through a VPC endpoint for private connectivity.

For this project, the public endpoint is simpler since your gateway already has a public IP address assigned.

The Review and activate page loads, showing a summary of your gateway's connection details.

Activate the gateway and allocate cache storage

Activating the gateway registers it with the Storage Gateway service in your AWS account. After activation, you'll configure the 150 GiB disk you attached earlier as cache storage.

Review the gateway details displayed on the Review and activate page.
Click Next to activate the gateway.

The Configure gateway page loads. This is where you assign the EBS volume you attached during instance launch as cache storage and set up monitoring.

In the Configure storage section, use the dropdown next to the 150 GiB disk to allocate it as Cache.
Under CloudWatch log group, select Create a new log group.
Under CloudWatch alarms, select No alarm.
Click Configure.

What does cache storage do?

The cache stores copies of recently accessed files on the gateway's local EBS disk. When a client reads a file from the file share, the gateway checks the cache first.

If the file is cached, the read is served locally instead of fetching it from S3. This gives you low-latency access to your most frequently used data.

Before you check the gateway's status, what do you expect to see on the Gateway overview page?

Search for your gateway on the Gateway overview page in the Storage Gateway console.

Your gateway should appear with status Running. You should also see the 150 GiB disk listed as Cache storage in the gateway details.

Gateway not showing Running status?

Check that you pasted the correct public IP address during the connection step. If the IP was wrong, the activation would have failed.
Make sure the gateway instance's security group still allows inbound TCP port 80 from your IP address. The gateway needs this port open during activation.
Wait a moment and refresh the page. The gateway may take a few seconds to register after clicking Configure.

My Storage Gateway is not showing Running status after activation. What could be wrong?

Your gateway is activated and its cache is ready to buffer data. Next up, you'll create an NFS file share that connects this gateway to your S3 bucket and launch a client instance to test it.

Create the NFS File Share and Launch a Client Instance

Your gateway is activated, linked to your AWS account, and its cache disk is ready. The next piece is giving the gateway something to serve.

Right now, the gateway is running but has no connection to your S3 bucket. Creating an NFS file share bridges that gap. It exposes your S3 bucket as a mountable directory over the NFS protocol, so any machine on the network can read and write to it like a local folder. You'll also launch a second EC2 instance to act as your simulated on-premises client.

In this step, get ready to:

Create an NFS file share that connects your gateway to the S3 bucket.
Launch a client EC2 instance to simulate an on-premises server.
Note the mount command and gateway private IP for the next step.

Create the NFS file share

An NFS file share tells the gateway which S3 bucket to back and exposes it as a directory over the NFS protocol. Any machine that mounts this share reads and writes directly to S3 without knowing it.

In the Storage Gateway console, click File shares in the left navigation pane.
Click Create file share.
Select your gateway from the dropdown.
Set the file share protocol to NFS.
Select your S3 bucket from the dropdown.
Under Default configuration, review the settings. The defaults use server-side encryption with S3 managed keys (SSE-S3) and S3 Standard storage class.
Click Create file share.

Your file share appears in the File shares list. Its status may initially show Creating before changing to Available. This can take a minute or two.

What about the IAM role?

The gateway automatically creates an IAM role with the permissions it needs to access your S3 bucket. You don't need to create one manually.

This role grants the gateway read and write access to the specific bucket you selected. It follows the principle of least privilege, scoping permissions to just what the file share needs.

File share stuck in Creating?

If the status stays on Creating for more than five minutes, check that your S3 bucket was created with ACLs enabled (Object Ownership set to Bucket owner preferred). If ACLs are turned off, the file share cannot access the S3 bucket and remains in the Unavailable state indefinitely.

To fix this, go to your S3 bucket, select the Permissions tab, click Edit under Object Ownership, and switch to Bucket owner preferred.

Need more help? Why is my Storage Gateway file share stuck in Creating or Unavailable?

Launch a client EC2 instance

While the file share finishes setting up, you can launch the client instance. This machine simulates an on-premises server that will connect to the gateway over NFS and write files that end up in S3.

The client must be in the same VPC and subnet as the gateway so the two instances can communicate over private IP addresses. Before launching, check which VPC and subnet the gateway uses.

Switch to the EC2 console.
Select your gateway instance and note the VPC ID and Subnet ID shown in the Networking tab.
Click Launch instances.
Enter a name for your instance, such as StorageGateway-Client.
Under Application and OS Images, confirm Amazon Linux 2023 is selected as the AMI.
Under Instance type, select t2.micro.
Under Key pair, create a new key pair or select an existing one for SSH access.

Now configure the networking to match the gateway.

Under Network settings, click Edit.
Confirm the VPC and Subnet match the values you noted from the gateway instance.
Under Firewall (security groups), select Create security group.
Add an inbound rule allowing SSH (TCP port 22) from My IP.
Click Launch instance.

The instance takes about a minute to start. Wait until its status shows Running with green status checks in the EC2 console.

Why the same VPC and subnet?

NFS traffic between the client and the gateway travels over private IP addresses. Both instances must be in the same VPC and subnet so they can reach each other without routing through the public internet.

In a real hybrid environment, an on-premises server would connect to the gateway through a VPN or AWS Direct Connect. For this project, placing both instances in the same subnet simulates that private network link.

Instance not starting?

If the instance stays in Pending state for more than two minutes, refresh the EC2 instances page. If it moved to Terminated, check that you selected t2.micro as the instance type and that the subnet you chose has available IP addresses.

Need more help? My EC2 instance is not starting or went to Terminated state. What should I check?

Note the mount command and gateway private IP

The file share details page shows the exact mount command you'll need to connect your client to the gateway. You also need the gateway's private IP address. Grab both now so they're ready for the next step.

Return to the Storage Gateway console and click File shares in the left navigation pane.
Confirm the file share status shows Available.
Click on the file share to open its details page.
Under On Linux, find the mount command. Copy it and save it somewhere you can access in the next step.

What does the mount command look like?

The mount command follows this format: sudo mount -t nfs -o nolock,hard <gateway-private-ip>:/<bucket-name> /mnt/nfs/s3. The console fills in the gateway IP and bucket name for you.

The nolock option disables file locking (not supported by the gateway). The hard option tells the client to keep retrying if the gateway is temporarily unreachable.

Switch to the EC2 console.
Select your gateway instance.
In the Details tab, find the Private IPv4 address and record it here: your gateway's private IP

Before you move on, what two statuses do you expect to see: one for the file share in the Storage Gateway console, and one for the client instance in the EC2 console?

The file share should show Available in the Storage Gateway console under File shares. The client instance should show Running with green status checks in the EC2 console.

Your file share is live and your client machine is running. Next up, you'll connect them by mounting the NFS share on the client and watching files flow through the gateway into S3.

Mount the File Share and Transfer Files

In the previous step, you created an NFS file share connected to your S3 bucket and launched a client instance to act as your simulated on-premises server.

Now it is time to connect the two. Your client instance needs to mount the gateway's file share so that files copied to a local directory flow through to S3. There is one catch: the gateway's security group currently only allows port 80 for activation traffic. NFS requires several additional ports, so your first mount attempt is going to fail. Diagnosing and fixing that blocked-port issue is a real-world skill you will use whenever you work with security groups.

In this step, get ready to:

Connect to the client instance and attempt the NFS mount.
Diagnose and fix a blocked-port issue in the gateway's security group.
Transfer test files and verify they appear as objects in your S3 bucket.

Connect to the client and attempt the NFS mount

To mount the NFS file share, you first need to SSH into the client EC2 instance, install the NFS client utilities, and then run the mount command you noted from the file share details page.

SSH into your client EC2 instance by running this command:

ssh -i [[PEMPATH="path to your .pem key file"]] ec2-user@[[CLIENT_PUBLIC_IP="your client instance's public IPv4 address"]]

Can't connect via SSH?

Make sure you are using the key pair you assigned to the client instance, not the gateway instance (unless they share the same key pair).

Check that the client's security group allows inbound SSH (TCP port 22) from your current IP address.

Why can't I SSH into my EC2 instance?

Install the NFS client utilities by running this command:

sudo dnf install -y nfs-utils

You will see dnf download and install the nfs-utils package. The output ends with Complete! when it finishes.

Create a mount point directory by running this command:

sudo mkdir -p /mnt/nfs/s3

Before you run the mount command, think about this: the gateway's security group currently only allows inbound TCP port 80. Do you think the NFS mount will succeed, or will something go wrong?

Attempt to mount the NFS file share by running this command:

sudo mount -t nfs -o nolock,hard [[GATEWAY_PRIVATE_IP="your gateway's private IP address"]]:/[[BUCKET_NAME="your S3 bucket name"]] /mnt/nfs/s3

Where do I get these values?

The gateway's private IP address is visible in the EC2 console when you select the gateway instance. The bucket name is shown in the mount command displayed on the file share's details page in the Storage Gateway console under On Linux.

The command hangs and nothing happens. This is expected. The gateway's security group only allows TCP port 80 for activation. NFS requires ports 2049, 111, and 20048, and all of them are currently blocked.

Press Ctrl+C to cancel the hanging mount command.

Why did the mount hang?

When you launched the gateway instance, you only opened TCP port 80 for activation. That was the right call at the time because the gateway did not need NFS ports yet.

NFS traffic requires three port groups: TCP/UDP 2049 for NFS itself, TCP/UDP 111 for the RPC portmapper, and TCP/UDP 20048 for the NFS mount daemon. Without these ports open, the client's mount request never reaches the gateway.

Open NFS ports in the gateway security group

The fix is straightforward: add inbound rules to the gateway's security group for the six port and protocol combinations that NFS needs.

Switch to the EC2 console in your browser.
Click Instances in the left navigation pane.
Select your gateway instance.
In the instance details below, click the link under Security groups to open the gateway's security group.
Click the Inbound rules tab, then click Edit inbound rules.

You need to add six new rules. For each rule, click Add rule and configure it as follows:

Type: Custom TCP, Port range: 2049.
Type: Custom UDP, Port range: 2049.
Type: Custom TCP, Port range: 111.
Type: Custom UDP, Port range: 111.
Type: Custom TCP, Port range: 20048.
Type: Custom UDP, Port range: 20048.

For the Source of each new rule, select Custom and enter the client instance's private IP address with a /32 suffix.
Click Save rules.

The Inbound rules tab now shows seven rules: the original port 80 rule plus your six new NFS rules.

Why not open these ports from the start?

In production, the principle of least privilege means you open only the ports you need, when you need them. During gateway activation, only port 80 was required. NFS ports became necessary only after you created a file share and needed a client to connect.

This also demonstrates that security groups are the first thing to check whenever a network connection times out between AWS resources.

Rules not saving?

Make sure each rule has a valid Source value. The client's private IP must include the /32 CIDR suffix (for example, 10.0.1.45/32).

Confirm you are editing the gateway's security group, not the client's.

Help me fix my security group rules for NFS.

Retry the mount and transfer files to S3

With the NFS ports now open, the gateway can accept mount requests from your client. Switch back to your SSH session on the client instance.

Retry the mount command:

sudo mount -t nfs -o nolock,hard [[GATEWAY_PRIVATE_IP="your gateway's private IP address"]]:/[[BUCKET_NAME="your S3 bucket name"]] /mnt/nfs/s3

This time the command returns to the prompt with no output. That silence means success. The /mnt/nfs/s3 directory is now connected to your S3 bucket through the gateway.

Mount still hanging?

Double-check that all six inbound rules were saved on the gateway's security group. Verify the gateway's private IP address matches the one you are using in the mount command.

Make sure both instances are in the same VPC and subnet. If they are in different subnets, ensure the subnet route tables allow traffic between them.

Help me troubleshoot my NFS mount.

Create your first test file by running this command:

echo "hybrid storage test" | sudo tee /mnt/nfs/s3/testfile1.txt

You will see hybrid storage test echoed back in the terminal. The file has been written to the NFS mount.

Create a second test file by running this command:

echo "second file" | sudo tee /mnt/nfs/s3/testfile2.txt

You will see second file echoed back.

What do these commands do?

The echo command outputs text, and sudo tee writes that text to a file. Because /mnt/nfs/s3 is an NFS mount backed by the gateway, these files are not stored locally on the client. They flow through the gateway's cache and get uploaded to your S3 bucket as objects.

Before you check S3, take a guess: do you think your files have already made it to the bucket?

Confirm the files exist on the mount by running:

ls -la /mnt/nfs/s3/

You should see testfile1.txt and testfile2.txt listed in the output.

Switch to the S3 console in your browser.
Click on your bucket name to open it.
Confirm that testfile1.txt and testfile2.txt appear as objects in the bucket.

Files not showing up yet?

The gateway uploads files asynchronously. It caches them locally first, then pushes them to S3 in the background. Small files typically appear within seconds to a couple of minutes. Click the refresh button in the S3 console and wait a moment if you do not see them immediately.

You just proved that a file written to a local mount point on the client flows through the S3 File Gateway and lands in your S3 bucket as an object. This is the core of hybrid cloud storage: local file protocols on the front, object storage on the back.

Secret mission

Add an S3 Lifecycle Policy to Auto-Tier Stored Files

Your hybrid storage bridge moves files from a local mount into S3. In production, that data piles up and storage costs climb. In this mission, you'll add an S3 lifecycle policy that automatically transitions aging files through progressively cheaper storage classes, cutting costs without lifting a finger.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses an m5.xlarge EC2 instance that is not free-tier eligible, so leaving it running will incur ongoing charges.

Cost warning

The m5.xlarge gateway instance costs approximately $0.192 per hour. That adds up to roughly $4.61 per day if left running.

If you are done with this project, choose Delete below to avoid unexpected charges. The total cost for a single session is approximately $0.25 to $0.50 if you clean up within one hour.

Resources you used:

S3 File Gateway and NFS file share in the Storage Gateway console.
Gateway EC2 instance (m5.xlarge) with 150 GiB cache and 80 GiB root EBS volumes attached.
Client EC2 instance (t2.micro), free-tier eligible.
S3 bucket with test objects and lifecycle rule.
Two security groups (gateway and client).
IAM role auto-created by Storage Gateway for S3 access.
CloudWatch log group for gateway monitoring.
Key pair(s) if you created new ones for this project.

Keep everything running

No action needed. Choose this if you are still actively building or experimenting with your Storage Gateway setup.

Ongoing costs

The m5.xlarge gateway instance costs approximately $0.192 per hour. The 150 GiB and 80 GiB EBS volumes also incur storage charges. Monitor your billing dashboard closely if you choose to keep resources running.

Pause - I'll come back to this later

Stop both EC2 instances to pause compute charges. EBS volume charges will continue while the instances are stopped.

In the EC2 console, select both the gateway and client instances.
Click Instance state, then Stop instance.
Confirm by clicking Stop.

EBS charges continue while stopped

Stopping the instances pauses compute charges, but the attached EBS volumes (150 GiB cache + 80 GiB root for the gateway, plus the client's root volume) continue to incur storage charges. When you are ready to resume, start both instances and re-activate the gateway.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow these steps in order, since some resources depend on others.

In the Storage Gateway console, go to File shares in the left navigation pane. Select your NFS file share and click Actions, then Delete file share. Confirm the deletion.
In the Storage Gateway console, go to Gateways. Select your gateway and click Actions, then Delete gateway. Confirm the deletion.
In the EC2 console, select both the gateway (m5.xlarge) and client (t2.micro) instances. Click Instance state, then Terminate instance. Confirm the termination. The attached EBS volumes are deleted automatically when the instances terminate.
In the S3 console, select your bucket. Click Empty to remove all objects, then type permanently delete to confirm. After the bucket is empty, click Delete and enter the bucket name to confirm.
In the EC2 console, go to Security Groups under Network & Security. Select the gateway and client security groups you created. Click Actions, then Delete security groups. Confirm the deletion.
In the EC2 console, go to Key Pairs under Network & Security. If you created a key pair specifically for this project, select it and click Actions, then Delete.
In the IAM console, go to Roles. Search for the role that Storage Gateway created for S3 access. Select it and click Delete. Enter the role name to confirm.
In the CloudWatch console, go to Log groups under Logs. Select the log group you created for the gateway. Click Actions, then Delete log group(s). Confirm the deletion.

Nice Work!

You just built a hybrid cloud storage bridge using AWS Storage Gateway. Files written to a local mount point on your client instance now flow through an S3 File Gateway and land as objects in your S3 bucket.

You've learned how to:

Deployed and activated an S3 File Gateway on an EC2 instance with 150 GiB of cache storage, linking the gateway appliance to your AWS account.
Created an NFS file share backed by your S3 bucket, then mounted it on a simulated on-premises Linux client and transferred files that appeared as objects in S3.
Diagnosed and fixed an NFS connectivity issue by adding security group rules for ports 2049, 111, and 20048, learning to open only the ports you need, when you need them.
Secret Mission: Configured an S3 lifecycle policy to automatically transition aging data from S3 Standard to S3 Standard-IA after 30 days and S3 Glacier Flexible Retrieval after 90 days.

Ready to quiz yourself?