VPC Peering

Worlds collide - let's get TWO VPCs to talk to each other!

Introduction

⚡️ 30 second Summary

Welcome to your sixth AWS networking project!

In your first five networking projects, you've created:

☁️ An Amazon VPC (amazing!)
🥅 A public subnet (woohoo!)
🚪 An internet gateway (go you!)
🚏 A route table (so good!)
👮‍♀️ A security group (say whaaat!)
📋 A Network ACL, aka Network Access Control List (super cool!)
🚷 A private subnet (no way!)
🚧 A private route table (you superstar!)
🚔 A private network ACL (hot damn!)
💻 EC2 instances in your public and private subnets (huuuuuuuge!)
🧪 Connectivity tests to validate your VPC set up (let's GOOO!)

If you haven't done the previous project in our networking series, Testing VPC Connectivity, we'd highly recommend doing that first to learn the concepts in depth.

In this project, VPC Peering we're going to level up by setting up VPC Peering - we're going to play with TWO VPCs instead of one!

The best part? You still get to revise everything you've learnt from the previous project (but in a new scenario)... you'll see what this means in a minute!

In this project,get ready to:

☁️ Set up multiple VPCs.
🌉 Create a VPC peering connection - i.e. get two VPCs to talk to each other!
👩‍🔬 Test VPC peering with connectivity tests.

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 VPCs in Minutes

Now that we've learnt about the VPC wizard from our previous projects, let's use it to set up TWO VPCs in minutes.

In this step, get ready to:

Create two VPCs from scratch!
Use the visual VPC resource map to create your VPCs supa fast 😎⚡️

Log in to your AWS Account with your IAM Admin User.
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.
We previously stuck to creating a VPC only, but this time let's select VPC and more.

Create VPC 1

Under Name tag auto-generation, enter NextWork-1
The VPC's IPv4 CIDR block is already pre-filled to 10.0.0.0/16 - change that to 10.1.0.0/16

Why are we updating the CIDR block?

Purely to make it easier to remember later! Since we're setting up 3 VPCs, it's easier to remember their CIDR blocks if their ranges match their names 😉

For example, 10.1.0.0/16 for VPC 1, then 10.2.0.0/16 for VPC 2, and so on...

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.

What does tenancy mean?

Tenancy in AWS refers to the type of hardware your instances run on. Yup, hardware. After all, the EC2 instances you'll launch into your VPC are hosted in a data centre in your chosen Availability Zone!

You have two options:

Default: Your instances share hardware with other AWS customers. This is the standard option and is cost-effective because you’re sharing resources.
Dedicated: Your instances run on hardware that's dedicated to you only. For example, imagine a healthcare company that needs to ensure the highest level of security for patient data. They might choose dedicated tenancy to make sure their servers are completely isolated from other customers, helping them meet compliance standards and keep sensitive information secure. Dedicated does come at a higher cost!

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.
We updated our subnets' CIDR blocks in previous projects, but we don't need defined subnets for this one. Let's skip the Customize subnets CIDR for this project.

Next, for the NAT gateways ($) option, make sure you've selected None. As the dollar sign suggests, NAT gateways cost money!

What are NAT gateways, how are they different from internet gateways?

NAT (Network Address Translation) gateways let instances in private subnets access the internet for updates and patches, while blocking inbound traffic.

For example, a private database in a private subnet might need to download security updates. By using a NAT gateway, the server can access these updates securely while remaining protected from external threats!

On the other hand, internet gateways let instances in public subnets communicate with the internet both ways i.e. both inbound and outbound traffic.

Next, for the VPC endpoints option, select None.

What are VPC endpoints?

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.

That's your teaser on VPC endpoints, we will get into them in detail in the next project! 👀

You can leave the DNS options checked.

Select Create VPC.

Select View VPC.
Select the Resource map tab - nice, all of these resources have been set up for you in a flash!

Set up VPC 2

We're going to set up another VPC with slightly different settings - pay close attention!

Select Create VPC.
Select VPC and more.
Under Name tag auto-generation, enter NextWork-2
The VPC's IPv4 CIDR block should be unique! Make sure the CIDR block is NOT 10.1.0.0/16 - it should be 10.2.0.0/16

Why do they need to be unique?

Each VPC must have a unique IPv4 CIDR block so the IP addresses of their resources don't overlap. Having overlapping IP addresses could cause routing conflicts and connectivity issues!

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 go with 0 for today's project. Let's keep it simple with just a single subnet!
For the NAT gateways ($) option, select None.
For the VPC endpoints option, select None.
You can leave the DNS options checked.
Select Create VPC.

Create a Peering Connection

Wooo now that you have two VPCs ready to go, let's bridge them together with a peering connection.

In this step, get ready to:

Set up a connection link between your VPCs.

Still in the VPC console, click on Peering connections on the left hand navigation panel.

What is a peering connection?

A VPC peering connection is a direct connection between two VPCs.

A peering connection lets VPCs and their resources route traffic between them using their private IP addresses. This means data can now be transferred between VPCs without going through the public internet.

Without a peering connection, data transfers between VPCs would use resources' public address - meaning VPCs have to communicate over the public internet.

Click on Create peering connection in the right hand corner.

Name your Peering connection name as VPC 1 <> VPC 2
Select NextWork-1-VPC for your VPC ID (Requester).

What does Requester mean?

In VPC peering, the Requester is the VPC that initiates a peering connection. As the requester, they will be sending the other VPC an invitation to connect!

Under Select another VPC to peer with, make sure My Account is selected.

Wow, I can peer with other Accounts?

Yup, VPC peering can occur between VPCs in different AWS accounts!

This flexibility lets businesses collaborate securely by sharing resources across accounts without exposing them to the public internet.

You can also try this option in a project by peering with a friend or setting up a separate AWS account!

For Region, select This Region.
For VPC ID (Accepter), select NextWork-2-VPC

What does Accepter mean?

In VPC peering, the Accepter is the VPC that receives a peering connection request! The Accepter can either accept or decline the invitation. This means the peering connection isn't actually made until the other VPC also agrees to it!

Click on Create peering connection.
Your newly created peering connection isn't finished yet! The green success bar says the peering connection has been requested.

On the next screen, select Actions and then select Accept request... Get ready to take a screenshot!

Why did I have to accept a request?

You set up the VPC peering connection as VPC 1 (the Requestor), but don't forget that the Accepter needs to approve of it too!

By clicking Accept request, you were accepting the connection as VPC 2.

Click on Accept request again on the pop up panel.
Click on Modify my route tables now on the top right corner.

Update Route Tables

With a peering connection all set up ✅, now it's time for traffic in your VPCs to learn how to use it.

In this step, get ready to:

Set up a way for traffic coming from VPC 1 to get to VPC 2.
Set up a way for traffic coming from VPC 2 to get to VPC 1.

Update VPC 1's route table

Select the checkbox next to VPC 1's route table i.e. called NextWork-1-rtb-public.
Scroll down and click on the Routes tab.
Click Edit routes.
Let's add a new route!

Why do I need to add a new route?

Even if your peering connection has been accepted, traffic in VPC 1 won't know how to get to resources in VPC 2 without a route in your route table! You need to set up a route that directs traffic bound for VPC 2 to the peering connection you've set up.

Add a new route to VPC 2 by entering the CIDR block 10.1.0.0/16 as our Destination.
Under Target, select Peering Connection.
Select VPC 1 <> VPC 2.

Click Save changes.
Oops! We've hit an error.

What does this error message mean?

The message says the destination you've put in has the same CIDR block as VPC 1's own CIDR block!

Whoops that was a typo - VPC 2's CIDR block is actually 10.2.0.0/16.

This is a key learning to take away: route tables cannot differentiate between local and remote destinations if they share the same CIDR block.

Imagine if we didn't set up VPC 2 with its own unique CIDR block in the previous step! We'd get into trouble here.

Let's fix that typo now! Select Back.
Update your new route's Destination to 10.2.0.0/16
Click Save changes again.
Confirm that the new route appears in VPC 1's Routes tab now!

Update VPC 2's route table

Challenge yourself - do you think you can set up the equivalent route in VPC 2's route table?

If you get stuck, use the same instructions above but make sure:

The route table you're updating is NextWork-2-rtb-public.
The Destination is the CIDR block 10.1.0.0/16

Launch EC2 Instances

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

In this step, get ready to:

Launch an EC2 instance in each VPC, so we can use them to test your VPC peering connection later.

Launch an instance in VPC 1

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 1
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).

Why aren't we setting up a key pair? Wasn't this step important in the last few projects?

In previous projects, setting up a key pair was a key step for learning how SSH and directly accessing an EC2 instance works.

However, we've also learnt that with EC2 Instance Connect, AWS actually manages a key pair for us! We don't need to manage key pairs ourselves. Since we've already learnt how to set up key pairs twice in the last two projects, we don't need to do it again this time.

At the Network settings panel, select Edit at the right hand corner.

Why are we editing the Network settings?

By default, all resources are launched into the default VPC that AWS has set up for your account. We need to tell AWS that we actually want to launch this instance in NextWork-vpc-1!

Under VPC, select NextWork-vpc-1.
Under Subnet, select your VPC's public subnet.
Keep the Auto-assign public IP setting to Disable.
For the Firewall (security groups) setting, Amazon VPC already created a security group for your VPC - let's use that!
Choose Select existing security group.
Select the default security group for your VPC.

Select Launch instance.

Launch an instance in VPC 2

You know the drill - do you think you can set up an EC2 instance in VPC 2?

If you get stuck, use the same instructions above but make sure:

The Name is Instance - NextWork VPC 2
The VPC is NextWork-2-vpc.

Connect to Instance 1

To test our VPC peering connection, we'll need to get one of our EC2 instances to try talk to the other.

In this step, get ready to:

Use EC2 Instance Connect to connect to your first EC2 instance.
Fix a connection error!

Still in your EC2 console, select the checkbox next to Instance - NextWork VPC 1.
Select Connect.

Woah! An error - why can't I use EC2 Instance Connect?

Check out the error message: "No public IPv4 address assigned. With no public IPv4 address, you can't use EC2 Instance Connect."

Can you tell which part of our EC2 instance set up caused this error?

Yup, keeping Disable for the Auto-assign IP address option in our EC2 instance's network settings caused this error!

That's a key learning to take away: If you want to connect to your instance over EC2 Instance Connect, then your instance must have a public IP address and be in a public subnet. This is because using EC2 Instance Connect connects to your server over the internet by default.

Verify this by heading back to the Instances page in your EC2 console, and checking the Public IPv4 address field... it's empty!

On your EC2 console's left hand navigation panel, select Elastic IPs.

What are Elastic IPs?

Elastic IPs are static IPv4 addresses that get allocated to your AWS account, and is yours to delegate to an EC2 instance.

An Elastic IP being static is a key word here! EC2 instances by default have dynamic IPs, which means their Public IPv4 addresses change every time they're restarted. Having an Elastic IP is like having a permanent address in a city, instead of having to move from location to location every time your instance restarts.

💡 Why would someone use Elastic IPs?

Elastic IPs are very popular tools for making sure an application stays available on the internet. Usually, an IP address change means a website's DNS record (i.e. the map that directs users visiting their domain to the right application/server) needs to be updated.

DNS updates take time to propogate across the internet - it can take hours and even days! So without an Elastic IP, a website would be down for its users if an EC2 instance restarts and the engineers have to change a DNS record. With an Elastic IP, the IP address associated with the EC2 instance is always constant - no DNS updates needed!

💡 Why am I using an Elastic IP?

Elastic IPs are also a great way to assign an instance a public IPv4 address after launching it! That's how we're using it in this step.

Select Allocate Elastic IP addresses.

Leave all default options.

Woah, what does the Public IPv4 address pool setting do?

This setting is asking you to choose the source of the Elastic IP address. Since IPv4 addresses are unique on the internet, the IPv4 address you are allocated has to come from somewhere and can't overlap with other existing IPv4 addresses!

The default setting is Amazon's pool of IPv4 addresses. Think of this as a public pool of all IPv4 addresses that Amazon has saved to allocate to AWS accounts, so you won't need to find one yourself.

If you have your own pool of IP addresses, you can also set those up in your AWS account and allocate an IPv4 address from there instead (this is called Bring Your Own IP, or BYOIP).

Select Allocate.
Refresh your page, then select the new IP address you've set up.
Select the Actions dropdown, then select Associate Elastic IP address.
Under Instance, select Instance - NextWork VPC 1.

Click Associate.

What about the Private IP address field? What does that do?

This setting isn't quite relevant to us since your EC2 Instance only has one private IP address, but it becomes very important if an EC2 instance has multiple private IPs.

💡 An EC2 instance can have multiple private IPs?

Absolutely! A single EC2 instance can have multiple private IP addresses.

This setup is just like how your personal computer can have different user accounts, each with its own settings and applications.

Here, having different IP addresses means the same server can have different network identities to host multiple applications at the same time! It’s an awesome way to maximize the use of a single EC2 instance while keeping applications separated with their own security and networking rules.

Awesome! Your EC2 Instance should have a public IP address now.
To check this, select Instances from the left hand navigation panel.
Select the checkbox next to Instance - NextWork VPC 1.
Do you see a Public IPv4 address for your EC2 instance now?

Woohoo! Good to see that the Elastic IP address we've set up is now associated with our EC2 instance.

Connect to Instance 1 (round two!)

Phew looks like the IP address should be all resolved now... let's try connecting to your EC2 instance again!

In this step, get ready to:

Use EC2 Instance Connect to connect to Instance 1 (one more time)!
Fix (another) error.

Select Connect.
In the EC2 Instance Connect set up page, select Connect again.
Oh no! We've failed to connect to our instance?!

Do you remember the reason for this from your previous project? The troubleshooting steps are the same as last time!

You can challenge yourself to troubleshoot this on your own this time, orrrr read ahead for the instructions. 👇

Head back to your VPC console.
Select Subnets from the left hand navigation panel.
Select the checkbox next to NextWork-1-subnet-public1...
Investigate Instance 1's Route table.

Now check the Network ACL - what do you see?

Note

Everything looks good! Our Network ACL allows all traffic in and out, and our route table is correctly setting up a route to the Internet Gateway.

Hmmm that leaves one more thing to investigate...
Copy the VPC ID of NextWork-1-vpc: Your VPC-1 ID.

Head into the Security groups page from the left hand navigation panel.
Woah it's a bunch of nameless security groups!
To find the VPC 1's default security group, let's use the handy search bar.
Click into the search bar, and paste the ID (Your VPC-1 ID) you copied into the search bar. Make sure there aren't any empty spaces before your text.
Select the filter!

Nice, that narrowed it nicely for us. Select the checkbox next to VPC 1's default security group.
Select the Inbound rules tab.

Aha! Mystery solved.

Mystery solved?! How are our inbound rules the cause of our connectivity issue?

The answer lies in the Source of your security group's inbound rules.

We're trying to access Instance - NextWork VPC 1 using SSH through EC2 Instance Connect, which is trying to connect to your instance over the internet.

Your default security group only allows inbound traffic from within the VPC, so traffic from the internet is being cut off!

That's a key learning to take away: The default security group for a new VPC does not allow incoming traffic from outside of the VPC.

You have to allow inbound SSH traffic on port 22 yourself!

In the Inbound rules tab, select Edit inbound rules.
Select Add rule.
For your new rule, configure the Type as SSH.
Then, under Source type, select Anywhere-IPv4.
Select Save rules.

With that modified, refresh your EC2 console's Instances page.
Select your Instance-NextWork VPC 1 and select Connect again.
Select Connect in the EC2 Instance Connect setup page.
Phew! Success.

Test VPC Peering

Awesome, we've figured out how to connect with VPC 1's Instance!

Let's see if we can connect with VPC 2's instance from here.

In this step, get ready to:

Get Instance 1 to send test messages to Instance 2.
Solve connection errors until Instance 2 is able to send messages back.

Leave open the EC2 Instance Connect tab, but head back to your EC2 console in a new tab.
Select Instance - NextWork VPC 2.
Copy the Instance - NextWork VPC 2's Private IPv4 address: Your VPC-2 address

Switch back to the EC2 Instance Connect tab.
Run ping Your VPC-2 address in the terminal.
- Your final result should look similar to something like ping 10.0.1.227
- Don't know where to enter this prompt? Look for the $ sign at the bottom line of the black window, and type in your command after the $ sign.

What does ping mean?

Ping is a common computer network tool used to check whether your computer can communicate with another computer or device on a network.

Think of it like sending a tiny message that says "hello, are you there?" to another computer, or like checking if someone's home by ringing their doorbell.

When you "ping" a specific IP address, your server (in this case, Instance - NextWork VPC 1) sends a small packet of data to the target server (Instance - NextWork VPC 2), asking for a response. Ping will tell you whether you get a response back and how long it took to get a response.

If you receive a response quickly, it means the connection between your computer and the other computer is good. If it takes a long time or you get no response, there might be a problem with the connection!

You should see a response similar to this:

What does this response mean? Is it a good response?

This single line indicates that your Instance - NextWork VPC 1 has sent out a ping message... and that's about it.

Usually, when you ping another computer successfully, you should see several replies back instantly. Each reply tells you how long it took for the message to go to the Instance - NextWork VPC 2 and come back.

If you don't get any replies (that's our situation right now), or if the replies stop suddenly, it's usually a sign that there's a problem with the connection.

💡 Why is there a problem with the connection between my servers?

One common reason for these issues is that the target server (Instance - NextWork VPC 2) or its network might be blocking the type of messages used in ping, which are known as ICMP (Internet Control Message Protocol) traffic.

Blocking ICMP traffic is often done to prevent network attacks, like attackers can overwhelming a server with ping messages so it can't respond to real users wanting to use your application. Fair enough that ICMP traffic is blocked by default!

To resolve this connectivity error, let's investigate whether Instance - NextWork VPC 2 is allowing inbound ICMP traffic.

🧠 Hint: you've done the exact same troubleshooting in the previous project!

Challenge yourself - can you solve this now without any guidance? Orrrr if you'd prefer, let's do this step by step together with the instructions below.

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

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

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

Hmmm! 🤔 🤔 🤔

▶️ Alright, resuming now!

Leave open the EC2 Instance Connect tab, but head back to your VPC console in a new tab.
In the VPC console, select the Subnets page.
Select VPC 2's subnet i.e. NextWork-2-subnet-public1-...
Let's investigate the Route tables and Network ACL tabs for your public subnet.
The network ACL allows all types of inbound traffic from anywhere! So this looks perfectly fine.
Before we finish, let's check the security groups!
Copy the VPC ID of VPC 2: Your VPC-2 ID

Select Security groups from the left hand navigation panel.
Paste the VPC ID (paste your VPC2 ID) in the search bar, and select the suggested filter.
Check your security group's Inbound rules tab - does this security group allow ICMP traffic from sources outside of VPC 2? (Nope!)
Aha! Mystery solved.

Let's fix this by letting inbound ICMP traffic from VPC 1.

Select Edit inbound rules.
Select Add new rule.
Change the Type to All ICMP - IPv4.

What is ICMP - IPv4?

When you set a rule for All ICMP - IPv4, you're allowing all types of ICMP messages for IPv4 addresses. This covers a wide range of operational messages that are essential for diagnosing network connectivity issues, ping requests and responses are just one type of ICMP messages.

You might notice that ICMP is not limited to IPv4; there is also ICMP for IPv6 , which functions similarly but is tailored specifically for IPv6 networks.

Set the Source to traffic coming from VPC 1 - 10.1.0.0/16
Select Save rules.

All updated!

Revisit the EC2 Instance Connect tab that's connected to Instance - NextWork VPC 1.
Enter ping Your VPC-2 address.
Woah! Lots of new lines coming through in the terminal.

What do these new lines mean?

The multiple new lines appearing in your terminal are a sign of successful communication between the two EC2 instances - wohoooo!

Each line represents a reply from the ping command you sent. This means that the ICMP (Internet Control Message Protocol) traffic is now successfully reaching Instance - NextWork VPC 2, thanks to the adjustments you made in the network ACLs and Security Groups. Nice!

Extra for Experts: Curious about what each part of the ping message means? The output typically shows several pieces of information:

Time: Each line includes the time in milliseconds it took for the ping message to travel from your server to the target and back. This is a measure of the latency or delay in the network communication.
TTL (Time to Live): This value indicates the lifespan of the packet as it travels; it decreases by one for each router it passes through. Once TTL reaches zero, the data packet containing the ping message is automatically dropped from the network.
Sequence number: This helps in identifying each ping request and matching it to its corresponding reply, ensuring that the responses correspond to the specific requests sent.

Congratulations! You've set up a peering architecture that connects VPC 1 to VPC 2 AND validated it with ping - too cool 😎☁️🌉

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 diving into the steps for deleting your resources, why not challenge yourself to delete everything in this project on your own?

Delete your EC2 Instances

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

Delete your Elastic IP address

Select Elastic IPs from the left hand navigation panel.
Select the IP address you've created.
Select Actions, then Release Elastic IP addresses.
Select Release.

What does it mean to release an Elastic IP address?

When you release an Elastic IP address, that address returns to Amazon's pool of IPv4 address and will eventually get reallocated to another AWS user!

Delete VPC Peering Connections

Head back to your VPC console.
Select Peering connections from your left hand navigation panel.
Select the VPC 1 <> VPC 2 peering connection.
Select Actions, then Delete peering connection.

Select the checkbox to Delete related route table entries.
Type delete in the text box and click Delete.

Delete your VPCs

Select Your VPCs from your left hand navigation panel.
Select NextWork-1-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!

What is a network interface?

Network interfaces get created automatically when you launch an EC2 instance. Think of them as a component that attaches to an EC2 instance on one end and your VPC on another - so that your EC2 instance is connected to your network and can send and receive data! Network interfaces are usually deleted automatically with your EC2 instance, but on some occassions it'd be faster to delete them manually.

Select NextWork-2-vpc, then Actions, and Delete VPC.
Type delete in the text box and click Delete.

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

Subnets
Route tables
Internet gateways
Network ACLs
Security groups

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

Nice Work!

THAT'S NETWORKING PROJECT SIX...

DONE!!!!! 🥳

Today you've learnt how to:

🌉 Create a VPC peering connection: You established a VPC peering connection setween two VPCs, enabling secure and direct communication while bypassing the public internet. This connection ensures private and efficient data transfer between the VPCs.
🚏 Update route tables for optimized traffic flow: You updated the route tables within your VPCs to route traffic through your peering connection.
💻 Launch and test EC2 instances in peered VPCs: You launched EC2 instances within each of your peered VPCs, and connectivity was tested to confirm that everything is functioning as expected.

Ready to quiz yourself? You got this! 💪

It's wild that all these learnings are packed in one project.

Great work and we'll see you in the next one.

Keep it up in the next project of our networking series - VPC Monitoring with Flow Logs!

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!