VPC Endpoints

Connect your VPC to other AWS services directly, no internet needed!

Introduction

⚡️ 30 second Summary

Welcome to your 🏁 FINAL 🏁 AWS networking project!

In this last project, you learnt how to use your VPC to access other AWS services, specifically S3.

That was pretty cool - with direct access to your EC2 instance, you could use AWS CLI commands to see what objects are in your S3 bucket and even upload files!

Buttt there's just one thing... with this setup, your EC2 instance is accessing your S3 bucket through the public internet.

🤔 How is that a problem? When traffic is going through the internet, there is a higher risk of external threats and attacks looking at your data!

For example, attackers can expose your EC2 instance's keys to your AWS account if they manage to break into the traffic between your instance and S3 bucket. Yikes, that's not great for security!

😰 But we need resources to talk to each other to build things on AWS!

You're right, so how could we solve this problem and let our VPC communicate with other AWS services in a safer way?

🥁 Introducing... VPC endpoints!

VPC endpoints gives your VPC private, direct access to other AWS services like S3, so traffic doesn't need to go through the internet.

Just like how internet gateways are like your VPC's door to the internet, you can think of VPC endpoints as private doors to specific AWS services.

Get ready to:

🚪 Use VPC endpoints to directly access your S3 bucket from your VPC.
🔐 Test your endpoint setup using an S3 security tool called bucket policies!

If you haven't done the previous project in our networking series, Access S3 from a VPC, we'd highly recommend doing that first. This project starts right where the previous one leaves off.

Want a complete demo of how to do this project, from start to finish? Check out our 🎬 walkthrough with Natasha 🎬

If you're up for a bit of a challenge, quiz yourself on the key concepts up ahead in this project.

This project is part of a series:

Before we start Step #1...

Before we get started, it's important that you know what we're trying to do today.

Set up your Architecture

LET's GOOOOOO!! Set up the foundations of today's project - a VPC, EC2 instance and S3 bucket are coming right up.

In this step, get ready to:

Create a VPC from scratch!
Launch an EC2 instance, which you'll connect to using EC2 Instance Connect later.
Set up an S3 bucket.

☁️ Create Your VPC

Starting off STRONG with your VPC - let's set it up in just two minutes ⚡️

Head to your VPC console - search for VPC at the search bar at top of your page.
From the left hand navigation bar, select Your VPCs.
Select Create VPC.
Select VPC and more.
Under Name tag auto-generation, enter NextWork
The VPC's IPv4 CIDR block is already pre-filled to 10.0.0.0/16 - we'll use this default CIDR block!

For IPv6 CIDR block, we'll leave in the default option of No IPv6 CIDR block.
For Tenancy, we'll keep the selection of Default.
For Number of Availability Zones (AZs), we'll use just 1 Availability Zone.
Make sure the Number of public subnets chosen is 1.
For Number of private subnets, we'll keep thing simple today and go with 0 private subnets.
For the NAT gateways ($) option, make sure you've selected None. As the dollar sign suggests, NAT gateways cost money!
For the VPC endpoints option, select None.

What are VPC endpoints?

Ooo, the main character of today's project!

Normally, to access some AWS services like S3 from your VPC, your traffic would go out to the public internet.

But, VPC endpoints let you connect your VPC privately to AWS services without using the public internet. This means your data stays within the AWS network, which can improve security and reduce data transfer costs.

We're selecting None here, so we can learn to set one up manually later! 👀

You can leave the DNS options checked.

Select Create VPC.

💻 Launch an instance in your VPC

Wooohooo, now it's time to launch an EC2 instance into your architecture!

Head to the EC2 console - search for EC2 in the search bar at the top of screen.
Select Instances at the left hand navigation bar.
Select Launch instances.
Since your first EC2 instance will be launched in your first VPC, let's name it Instance - NextWork VPC Project

For the Amazon Machine Image, select Amazon Linux 2023 AMI.
For the Instance type, select t2.micro.
For the Key pair (login) panel, select Proceed without a key pair (not recommended).
At the Network settings panel, select Edit at the right hand corner.
Under VPC, select NextWork-vpc.
Under Subnet, select your VPC's public subnet.
Keep the Auto-assign public IP setting to... do you remember whether our EC2 instance needs a public IP address?

Hmmm, I can't seem to remember. What is it?

We're using EC2 Instance Connect after this to connect with our EC2 instance!

EC2 Instance Connect requires instances to be in a public subnet AND have a public IPv4 address!

💡 What is EC2 Instance Connect?

EC2 Instance Connect is an EC2 service designed to help you get direct access to your EC2 instance!

Once you get direct access to your EC2 instance, you're going into the instance's terminal. This lets you do some advanced work like installing software into your EC2 instance or accessing another AWS service!

Select Enable.

For the Firewall (security groups) setting, choose Create security group.
Name your security group SG - NextWork VPC Project
That's it! No security group rules to add.

Didn't we use to add other security group rules?

By default, this new security group allows all inbound SSH traffic. That's all we need to use EC2 Instance Connect later.

We used to add an inbound rule to allow ICMP traffic - but we won't need it if we aren't running any ping tests!

Select Launch instance.

🪣 Launch a bucket in Amazon S3

Before we connect with our EC2 instance, let's set up a bucket in Amazon S3 🪄

After creating this bucket, we'll access it from our EC2 instance and do things like checking what objects are in the bucket.

Search for S3 at the search bar at the top of your console.

Make sure you're in the same Region as your NextWork VPC!
Select Create bucket.

Let's set up your bucket! Keep the Bucket type as General purpose.
Your bucket name should be nextwork-vpc-project-enter your name here
- Don't forget to replace yourname with your first name! S3 bucket names need to be globally unique.
We'll leave all other default settings, go straight to Create bucket.

Nice! Bucket created 😎 😎

We'll finish set up by uploading two files into your shiny new bucket.

This can be any two files in your local computer!

Click into your bucket.
Select Upload.

Select Add files in the Files and folders panel.

Select two files in your local computer to upload.

Not sure what to upload? You can download and use these images instead! 👇

Right click on each link, select Save link as... and select Save.

Your files should show up in your Files and folders panel once they're uploaded!

Select Upload at the bottom of the page.

Connect to Your EC2 Instance

This project is all about VPC endpoint connections, so before we create that endpoint... let's see what things are like without endpoint connections in place.

In this step, we're gonna connect to your EC2 instance and try access S3 through the public internet!

In this step, get ready to:

Connect directly to your EC2 instance.

Head to your EC2 console and the Instances page.
Select the checkbox next to Instance - NextWork VPC 1.
Select Connect.
In the EC2 Instance Connect set up page, select Connect again.
Yay! Successfully connected.

For your first command, try running aws s3 ls, which is a command used to list the S3 buckets in your account (yup, ls stands for list!).

Wait, you can view S3 buckets from an instance's terminal?!

Yes, you can! From an EC2 instance's terminal, you can run all kinds of commands to interact with AWS services. Listing all the S3 buckets you have access to is just the tip of the iceberg!

💡 How does that work?

There is a special software called the AWS CLI (Command Line Interface) that you install and run on your computer to control AWS services directly from the command line i.e. your terminal! You can install this in your local computer too, and all EC2 instances come with it already installed.

Extra for Experts: As you advance in your cloud engineering career, you'll find that the AWS CLI often becomes your go-to tool. Engineers use the CLI to automate tasks and manage AWS resources efficiently using scripts, making it essential for managing your cloud environment in an efficient way.

While the AWS Management Console is fantastic for learning and having a visual guide, the CLI provides the speed and versatility that professionals need for complex tasks.

Hmmm, doesn't look like a success. We need to provide credentials.

What are credentials?

Credentials in AWS are like keys that let you access and manage AWS services securely. Without credentials, you won't have the permission to do things like viewing your S3 bucket list.

💡 Do I have credentials?

When you log into your AWS Management Console, you're already authenticated using your AWS user's details.

Running commands from an EC2 instance is a different story! You can think of your EC2 instance as another user that needs its own username and password (i.e. credentials) to get access to your AWS account.

Your account by default doesn't have credentials set up for running commands from an EC2 instance. You'll need to manually set these up to securely access and manage AWS services from your instance.

Run aws configure
The terminal is now asking us for an Access Key ID!

What is an access key ID? Do I have one?

An access key ID is a part of a credential!

Your credentials are made up of a username and password; think of the access key ID as the username.

You don't automatically have one, but you can create access keys IDs through AWS IAM.

💡 What's the difference between access keys and key pairs?

You might remember key pairs from launching EC2 instances!

Key pairs are used specifically for logging into your EC2 instances through SSH.
Access keys, which are what we're learning about now, are credentials for your applications and other servers to log into AWS and talk to your AWS services/resources.

Create Access Keys

Challenge accepted! Your EC2 instance needs credentials to access your AWS services, so let's set up access keys right away 🏃‍♀️

In this step, get ready to:

Give your EC2 instance access to your AWS environment.

Search for Access keys in the search bar.
Aha! So it's the IAM console that helps us set this up. Select IAM.

Search for Access keys again in the IAM console's left hand navigation panel.

Choose the search result for managing an access key for your IAM Admin account.

On the first set up page, select Command Line Interface (CLI).
Select the checkbox that says I understand the above recommendation and want to proceed to create an access key.
Select Create access key.

What is the yellow warning banner saying?

In this project we're creating access keys and manually applying them in our EC2 instance, but typically the recommended way is to create an IAM role with the necessary permissions and then attaching that role to your EC2 instance.

Your EC2 instance would inherit the permissions from the role, and this is best practice as you can easily attach and detach EC2 instances from roles to give and take away their credentials.

We aren't using this method so that we can learn about access keys, but roles are usually a better alternative for security.

💡 Extra for Experts: What do the other options mean?

Let's break 'em down!

Choose Local code if you're building an application in your local computer, and need the access key to connect your app with AWS services.
Choose Application running on an AWS compute service if you're building an application that's running on an AWS compute service like EC2 or Lambda, and need the access key to connect your app with AWS services.
Choose Third-party service if you're running an application from an external company (i.e. it wasn't built by yourself or AWS), but requires access to your AWS environment. For example, Crowdstrike is a third party security service that requires access to your AWS environment to protect them in real time!
Choose Application running outside AWS if you're running an application built by yourself but hosted on a physical server or another cloud platform, and you need to integrate it with AWS services.

Select Next.
For the Description tag value, we'll write Access key created to access an S3 bucket from an EC2 Instance. NextWork VPC Project.

Select Create access key.
OOoo this is important! STAY ON THIS PAGE ✋

You've just created your access key, well done.

This is the only time that your secret access key can be viewed or downloaded. You cannot recover it later. However, you can create a new access key any time.

What is the secret access key?

The secret access key is like the password that pairs with your access key ID (your username). You need both to access AWS services.

Secret is a key word here - anyone who has it can access your AWS account, so we need to keep this away from anyone else!

Select Download .csv file near the bottom of the page.

Note

PLEASE don't forget to delete your access key and the .csv file at the END of your session!

If you don't finish this project today, it's better to delete your access key and create a new one tomorrow, than to keep the same access key for a longer period of time.

Connect to your S3 bucket

Access keys created 💻 🔑 ☁️

Shall we try use our EC2 instance to access your S3 bucket now? (Yes!!) 👀

In this step, get ready to:

Head back to your EC2 instance.
Get your EC2 instance to access your S3 bucket.

Now back to your EC2 Instance Connect tab!
Are you ready to enter your Access keys details now?
Open the AccessKeys.csv file you've downloaded.
Copy the Access key ID.
Paste this into your EC2 instance's terminal, and press Enter on your keyboard.

Let's do the same for the AWS Secret Access Key!
Copy the key from your .csv file, and paste it in the terminal. Press Enter.
Next, for your Default region name, open your Region dropdown on the top right hand corner of your AWS console.
Copy your Region's code name. For example, us-west-2.

Paste that in your EC2 instance's terminal. Press Enter on your keyboard.
We don't have a default output format, so we can leave that empty. Press Enter.

What is a default output format?

In just a second, you'll be running a few CLI commands in your EC2 instance's terminal to use Amazon S3. The default output format is how the results of your will display!

Options for your output format options are...

json, which is the default if you're not using another option.
text for plain text.
table for an formatted table.
yaml, which is a format for writing data in a way that is easy for people to read and write.

💡 What is JSON?

Amaaaazing question! JSON is a format for storing and exchanging data that is easy to understand for both humans and computers.

You'll get to use JSON and see it in action in a second 😎

Nice! Set up is done.

Let's try running the aws s3 ls command again to see a list of your account's S3 buckets.

YOOOOOO look at that! Do you see a list of your buckets? You might have a shorter list than the one in this screenshot, but the only line to look out for is vpc-project-enter your name here.

Next, let's run the command aws s3 ls s3://nextwork-vpc-project-enter your name here. Make sure to replace with your actual bucket name!
Based on the command, and what you've learnt about aws s3 ls, can you guess what this command does?
Nice - we can even see the objects that are inside your bucket.

Did you know you could upload files using AWS CLI too?!

Run sudo touch /tmp/nextwork.txt to create a blank .txt file in your EC2 instance.

What does this command say?

Let's break it down!

sudo stands for "superuser do" and it's used when you're running a command that typicaly needs elevated user permissions, like installing software or creating new files.
touch is a standard command used to create an empty file if it doesn't exist. If it does exist, this command will update the file's timestamp (i.e. the last time it was accessed) instead.
/tmp/ is a common directory path (you can think of a directory path as layers and layers of folders) typically used for temporary files.
nextwork.txt is the name of the empty file you're creating!

Next, run aws s3 cp /tmp/nextwork.txt s3://nextwork-vpc-project-enter your name here to upload that file into your bucket.

What does this command say?

Let's break it down!

aws s3 c: is the command to copy files.
/tmp/nextwork.txt is the source file path. It's saying that the file to copy is nextwork.txt, which exists inside a folder called tmp.
s3://nextwork-vpc-project-enter your name here` is the destination path. It's saying that the file should be copied to the S3 bucket vpc-project-yourname!

Finally, run aws s3 ls s3://nextwork-vpc-project-enter your name here again - what objects are listed in your bucket now?

What is the 0 next to nextwork.txt?

The numbers next to each file name is the size fo that file! Since nextwork.txt is an empty file with no data, it has 0 bytes.

Switch tabs back to your S3 console.
Refresh the Objects tab for your S3 bucket.
Do you see your new file there? 👀

Super cool 😎 A file you've created in your EC2 instance now lives in your S3 bucket too!

Create an endpoint

Wooooohoo! Your EC2 instance definitely has access to your bucket - your access key worked 👏

Buttt your instance is connected to your bucket through the public internet.

This isn't the most secure way to communicate - external threats and attacks can easily intercept your commands and get access to your AWS environment or sensitive data.

🥁 Yup... it's time we bring in VPC endpoints!

In this step, get ready to:

Set up a way for your VPC and S3 to communicate direclty.

In a new tab, head back to your VPC console.
Select Endpoints from the left hand navigation panel.

Select Create endpoint.

What's an endpoint?

Woohoo! We've been teasing about endpoints for a couple of projects, and it's great that we're finally creating one now!

An endpoint in AWS is a service that allows private connections between your VPC and other AWS services without needing the traffic to go over the internet.

💡 I thought all of my resources get launched inside my VPC, so how are some connections through the internet?

Not all AWS resources get launched inside your VPC! While your EC2 instances live within your VPC, S3 buckets and some other AWS services exist outside your VPC because they're designed to be highly available and accessible from anywhere.

For example, the commands you're putting through AWS CLI now will be communicated to your S3 bucket through the public internet.

That's why VPC endpoints exist to create a private connection between your VPC and AWS services. Having a VPC endpoint means your instances can now access services like S3 directly without routing through the public internet, which makes sure your data stays within the AWS network for security.

For the Name tag, let's use NextWork VPC Endpoint
Keep the Service category as AWS services.

In the Services panel, search for S3.
Select the filter result that just ends with s3.

Select the row with the Type set to Gateway.

What's does Gateway mean?

A Gateway is a type of endpoint used specifically for Amazon S3 and DynamoDB (DynamoDB is an AWS database service).

Gateways work by simply adding a route to your VPC route table that directs traffic bound for S3 or DynamoDB to head straight for the Gateway instead of the internet.

Extra for Experts: As AWS evolved and more companies started using it for diverse and complex tasks, there was a need for more detailed control over how data moves within AWS networks. Gateway endpoints they could manage traffic but didn’t offer detailed settings - this led to AWS creating Interface endpoints, which offer more security settings.

Next, at the VPC panel, select NextWork-vpc.
We'll leave the remaining default values and select Create endpoint.

Nice! Endpoint created 🤩

Select the checkbox next to your endpoint's name.

Create a super secure bucket policy

Gooood work, you've just set up a VPC endpoint.

You might be wondering:

- How do I know that my endpoint is truly providing direct access to S3?

- How can I confirm that my VPC isn't still communicating with S3 through the public internet?

To answer these questions, we'll validate our endpoint connection by doing something a lil wild 🐲

We're going to block off your S3 bucket from ALL traffic... except traffic coming from the endpoint.

It's the ultimate test - if your endpoint was truly set up properly, then your EC2 instance should still be able to access S3. Otherwise, your instance's access is blocked!

In this step, get ready to:

Limit your S3 bucket access's to only traffic from your endpoint.

In your S3 bucket, we're going to kick things up a notch and make access super secure.

Let's say we want to make this bucket completely private to ALL access... except access through the VPC endpoint you've set up.

In the S3 console, select Buckets from the left hand navigation panel.
Click into your bucket vpc-project-enter your name here.
Select the Permissions tab.

Scroll to the Bucket policy panel, and select Edit.

What's a bucket policy?

A bucket policy is a type of IAM policy designed for setting access permissions to an S3 bucket. Using bucket policies, you get to decide who can access the bucket and what actions they can perform with it.

Add the below bucket policy to the policy editor.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::[[BUCKETNAME="your-bucket-name"]]",
        "arn:aws:s3:::[[BUCKETNAME="your-bucket-name"]]/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpce": "[[VPCE="endpoint ID"]]"
        }
      }
    }
  ]
}

Don't forget to replace:

BOTH instances of arn:aws:s3:::your-bucket-name with your actual bucket ARN.
- Handy tip: you can find your Bucket ARN right above the Policy window

endpoint ID with your VPC endpoint's ID.
- To find this ID, you'll have to switch back to your Endpoints tab and copy your endpoint's ID. Make sure it starts with vpce-

After replacing the default values with your resources' ARN or ID, double check that you haven't deleted the quote marks around any of your statements. Also check that you still have /* at the second Resource line!

What does this policy do?

This policy denies all actions (s3:*) on your S3 bucket and its objects to everyone (Principal: "*")... unless the access is from the VPC endpoint with the ID defined in aws:sourceVpce.

In other words, only traffic coming from your VPC endpoint can get any access to your S3 bucket!

Select Save changes.

Ran into this error?

This means you haven't replaced all the placeholder values with your resources' ARN or ID yet!

If you're still stuck, take a screenshot of your bucket policy and share it with the NextWork community - we can solve this together.

Woah! Once you've saved your changes, panels have turned red all across the screen.

Why am I denied access?!

Don't forget what your policy does 👀

Your policy denies all actions unless they come from your VPC endpoint. This means any attempt to access your bucket from other sources, including the AWS Management Console, is blocked!

Access your S3 bucket again!

Its the moment of truth!

Now that your S3 bucket's access is only limited to your endpoint, can your EC2 instance still access your bucket?

✅ If it can, you've set up your endpoint connection perfectly.

❌ If it can't, something's gone wrong with our VPC endpoint set up...

In this step, get ready to:

Test your VPC endpoint set up.
Troubleshoot a connectivity issue.

Head back to EC2 Instance Connect.
Try running aws s3 ls s3://nextwork-vpc-project-enter your name here again.
Ah! Access denied. It looks like the bucket policy had stopped us.

Wait a second... why is our EC2 instance also denied access?

We're supposed to get exclusive access to this S3 bucket... after all, the policy denies everyone except traffic through the endpoint!

We did set up an endpoint already between your VPC and your S3, didn't we?

Troubleshoot this error by heading to your VPC console.

Pause and have a think - where do you think you can investigate this?

Up till now, you've learnt about internet gateways, subnets, route tables, IPv4 addressing and security groups...

Which of these would you need to configure for Instance - NextWork VPC 2 to receive ICMP traffic?

Hmmm! 🤔 🤔 🤔

Select Subnets from the left hand navigation panel.
Select your public subnet, which starts with NextWork-subnet-public1.
Select the Route table tab.
Aha! Mystery solved.

How is it mystery solved?!

We'll ask another question back to ya - using this route table, how would traffic from your EC2 instance get access to your S3 bucket?

The route table is the GPS / traffic controller directing traffic from your EC2 instances.

If your route table doesn't have a route that directs traffic bound for S3 to your VPC endpoint, traffic from your EC2 instance is actually trying to get to your S3 bucket through the public internet instead.

Let's make sure your public subnet has a route to your endpoint.
Select Endpoints from the left hand navigation panel.
Select the checkbox next to your endpoint, and select Route tables.
Select Manage route tables.

Select the checkbox next to your public route table.
Select Modify route tables.

Head back to the Subnets page.
Select the refresh button next to the Actions dropdown.
Check the Route table tab for your public subnet again.

Nice! there's a route to the VPC endpoint now.

Access your S3 bucket (one last time)!

Surelyyyy our VPC endpoint set up is perfect now!

To validate your work, let's get your EC2 instance to interact with your S3 bucket one last time.

In this step, get ready to:

Test your VPC endpoint set up (again).
Restrict your VPC's acccess to your AWS environment.

Back in your EC2 Instance Connect tab, run aws s3 ls s3://nextwork-vpc-project-enter your name here again.
WOOOHOOOO! We're back.

Congrats on making a successful VPC endpoint connection!

Did you know VPC endpoints can be configured using policies too?!

We'll do a simple configuration - switch to your Endpoints tab.
Select the checkbox next to your policy.
Select the Policy tab.
Ooo! By default, your VPC endpoint allows access to all AWS services.
Select Edit policy.
Change the line "Effect": "Allow" to "Effect": "Deny"!

Click Save.
Switch back to your EC2 Instance Connect tab.
Run aws s3 ls s3://nextwork-vpc-project-enter your name here - what do you see now?
Wow! The endpoint policy now stops us from accessing our S3 bucket.

Why would I use policies to configure a VPC endpoint?

This is a great tool to quickly block off access if you suspect attackers are using your endpoint to access your resources! Instantly switch the effect to Deny, and your Gateway is closed.

You could also use VPC endpoint policies to be even more granular with the way you give away access to your AWS services. For example, you can write a policy that gives your endpoint read access only to S3 buckets, so the permission to upload objects is denied.

Switch tabs back to your Endpoints page.

Select Edit Policy.
Change the policy back to "Effect": "Allow" - this will be important when it comes to deleting your resources later!
Select Save changes.

Delete Your Resources

Important

Deleting resources that are not actively being used stops you getting charged and is a best practice. Not deleting your resources will result in charges to your account.

Before you read the steps on deleting your resources, do you think you can challenge yourself to try delete everything in this project without any guidance?

Keeping track of your resources, and deleting them at the end, is absolutely a skill that will help you reduce waste in your account.

🪣 Delete Your S3 Buckets

Head to your S3 console.
Select the Buckets page.
Select your nextwork-vpc-project-enter your name here, and select Delete.
Enter your bucket name, and select Delete bucket.
Oh no!

Deleting your bucket from the console is not possible - don't forget, your S3 bucket policy literally denies everyone else (except traffic from the VPC endpoint) access to the bucket.
Our only option is to delete our bucket through the EC2 instance!
Switch tabs to your instance's terminal.
Run the command aws s3 rb s3://nextwork-vpc-project-enter your name here.

What does this command do?

rb is a command that deletes your bucket!

This means rb s3://nextwork-vpc-project-enter your name here is used to delete your S3 bucket nextwork-vpc-project-enter your name here.

Nope! The delete failed - we need to make sure our bucket is empty first 🙈
To delete everything in your bucket, run the command aws s3 rm s3://nextwork-vpc-project-enter your name here --recursive

What does this command do?

rm stands for "remove" and is used to remove things inside your bucket.
--recursive means the remove command should include all objects and subdirectories inside your bucket. This is a super helpful command to run before delete a non-empty bucket.

Run the command aws s3 rb s3://nextwork-vpc-project-enter your name here again.

Wooohoo! That's your S3 bucket successfully removed.
Let's check it's gone by running aws s3 ls one last time - does your bucket still show in the list of results?

💻 Delete your EC2 Instance

Head back to the Instances page of your EC2 console.
Select the checkboxes next to Instance - NextWork VPC Endpoint.
Select Instance state, then select Terminate Instance.
Select Terminate.

🚪 Delete your VPC Endpoint

Head back to the Endpoints page of your VPC console.
Select the checkbox next to your endpoint.
Select the Actions dropdown.
Select Delete VPC endpoints.

☁️ Delete your VPCs

Select Your VPCs from your left hand navigation panel.
Select NextWork-vpc, then Actions, and Delete VPC.

Type delete in the text box and click Delete.
Note: if you get stopped from deleting your VPC because network interfaces are still attached to your VPC - delete all the attached network interfaces first!

Other network components should be automatically deleted with your VPC, but it's always a good idea to check anyway.

Don't forget to refresh each page before checking if these resources are still in your account:

Subnets
Route tables
Internet gateways
Network ACLs
Security groups

One last thing...

Can you remmeber one last resource that we created in this project?

Do you remember one more thing to delete?!

🔑 Delete Your IAM Access Keys

Head to your IAM console.
Select Users.
Select your Security credentials tab.
Scroll down to your Access keys panel and select the Actions drop down.
Select Delete.
At the popup panel, select Deactivate, and enter your access key ID into the text field.
Select Delete.
Last but definitely not least - don't forget to delete the local access key .csv file saved on your local computer!

Nice Work!

THAT'S NETWORKING PROJECT NINE...

... AND THE ENTIRE NETWORKING SERIES...

DONE!!!!! 🥳

Ready to quiz yourself? You got this! 💪

Today you've learnt how to:

🚪 Set up a VPC endpoint: You created a VPC endpoint that enables secure, direct access from your VPC to S3. The type of endpoint you set up was an S3 Gateway.

🪣 Manage permissions with bucket policies: You set up a strict bucket policy that blocks off all access to your bucket, except for access from your VPC endpoint.

👩‍🔧 Resolve VPC endpoint issues: You resolved connectivity issues by adding a route that directs S3-bound traffic from your public subnet to your S3 Gateway endpoint!

It's wild that all these learnings are packed in one project, and a special kudos to you for completing the entire networking series!

We'll see you in the next project 👊

p.s. Does it say "Still tasks to complete!" at the bottom of the screen?

This means you still have screenshots left to upload, or questions left to answer!

Press Ctrl+F (Windows) or Command+F (Mac) on your keyboard.
Search for the text Return to later.
Jump straight to your incomplete tasks!
🙋‍♀️ Still stuck? Ask the community!