Amazon Virtual Private Cloud is a service that
lets you launch AWS resources in a logically isolated virtual network that you define. Neil
Davis teaches this course. He's created many popular AWS courses and he's a great teacher.
This is Neil Davis from Digital cloud training. And this hands on video, you're going to
learn Amazon Virtual Private Cloud VPC. In AWS a VPC is a logically isolated portion
of the cloud into which you can deploy your own resources such as Amazon easy to instances VPC
is quite a complex topic. In this video, I'm going to start right at the beginner level and take you
through to an intermediate or even expert level, you'll learn how to define your own IP
address ranges for a VPC, how to create a VPC and launch resources into it. You'll
learn about routing and VPC security groups, network access control lists, and we'll also cover
VPN connections, direct connects and much more. This video comes from my brand new AWS
Certified Solutions Architect associate goals. So if you're planning to take an AWS certification
exam, this video will be very, very useful for you. But it's good for anybody who wants to learn
about Amazon VPC, and actually practice using it. For those who want to learn even more. There
are some supplementary videos on the digital cloud training YouTube channel, including for
creating a client VPN, and a site to site VPN, both hands on videos, you can find the links to
those videos in the description of this video. And you'll also find the course download as well which
you'll need to complete the hands on exercises in this course. Now I really hope that you enjoy
this video. And let's get straight into it. Hi guys, in this lesson, I'm going to cover
a basic primer on IP addressing. And we are specifically talking about IP version four,
not version six. I'll cover version six, a bit later on in this section. Now, what I want
to do here is assume that you don't have much knowledge of IP addressing at all, if any. And
we're going to start right at the basics. Now it is a really complex subject. So I'm only
going to go as far as what you need to know in order to be competent working with Amazon
VPC. And with IP addressing in general with AWS. Now, there'll be some areas of the subject
matter where you may want to go deeper. And there's lots of resources on the internet for
doing that if you wish to. to kick off the lesson, let's start with what is an IP address. Now,
let's say we have a web server on the internet, and you want to communicate with that web
server. Now the web server is likely to have some kind of network interface and attached to
that network interface will be an IP address. And this is going to be a public IP address. In
this case, because the web server is available via the internet, IP addresses are the addresses
that computers use to communicate with each other. So you've got your computer at home, and you got a
web browser open. And you type in example.com, the address of our web server. Now what happens now
because you put in example.com, but like I said, the computers communicate using IP addresses. So
this is where a domain name system or DNS server comes in. Your computer will speak to a DNS
server. And it's going to ask that DNS server what is the IP address for example.com. Once
your computer has the result, it's then able to connect to the web server using the IP address.
So this is the main name resolution, where you're resolving a name, a nice friendly name that
you can remember easily into an IP address, which is less easy to remember. But it's the way
computers actually communicate with each other. Let's move on to the structure of an IP address.
Now you've very likely seen IP addresses we've already worked with them in this course. So an IP
address might look like this 192 dot 168 dot 0.1. This is known as dotted decimal notation. And
it's a simple way of actually representing an IP address. Now each of these parts between the dots
is actually a binary octet. So that's where things get a little bit more complex. But you do need
to know this. So what is a binary octet? Well, octet means that you have eight values,
and those values can either be a one, or they can be a zero. Those are the only two
options. It's binary. In this small table here, you can see that in this case, we have once eight
ones, all in a line. Now on the left hand side we have what's called the most significant bit
that means that if one In this leftmost place, it's going to have a value of 128. If you have
a one, on the right hand side, that's the least significant bit, and its value is only one. If
you have a zero anywhere, it just means zero. So for example, in this address, the third octet is
a zero. So that means all of the eight bits are zeros. The one means that all seven bits here are
zeros. And we have a one on the right hand side, and that equals this least significant
bit here. On the very left, we have 192. Well, 192 is 128 plus 64. So we have a one
and a one, and the remaining values are zeros. And then for 168, we have a one, so that's 128.
Then we have a one in the third place here, which is 32. And then we have a one in the fifth
place here, which is eight. So we have 128 plus 32 plus eight equals 168. The reason it's
important to understand this binary is when we get to subnetting, with variable
length subnet masks that's coming shortly. So firstly, let's understand that network and host
portions of an IP address. Every IP address has a network ID and a host ID, the free blue boxes
on the left there represent the network ID, this value will be the same for every computer on
this network. The host ID will be unique for every computer on this network. As I said before, every
IP address will have a network and host ID. But how this is configured does vary. Now how do we
know which piece is the network ID and which is the host ID? Well, that's where the subnet mask
comes into play. Where we have 255. In this case, essentially where we have a bit that is a one
that represents the network ID. So here we have eight bits that are one, eight bits that
are one and eight bits that are one so those first free octets are all representing the
network ID. Now the last octet in the orange box here is going to be the host ID. That's why it's
zero. So every bit in the subnet mask that is zero means that's where we have values that can
be assigned a host. And every bit that's a one, those are values that are going to be exactly
the same for every computer on the network. So a subnet mask is an easy way to see which bit
is the network and which portion is the host ID. So let's look at an example. We have our 19216800
network with a subnet mask that looks like this. Now this is 24 bits, a 24 bit subnet mask because
we have eight ones in those first three octets. And that means it's a slash 24 network. It's
another way of representing the subnet mask. And that's the format you'll often work with in
AWS. So on this network, we might have several computers. And we can see that they each have
different host IDs. But that same network ID. In this case, the host IDs are 123456 and the
network ID is 1921680. For all of the hosts on the network. We also have something called classes
with IP addresses. Class A looks like this 10 000 and 255000. Essentially, you have an
eight bit subnet mask. And that means the first assignable address is going to
be a one, you can't ever assign zero as an address for a computer on the network. And
the last assignable address is going to be 254 because you can't use 255, which is what's known
as the broadcast address. Now in AWS, there's also a few other addresses that are reserved with
a class a subnet mask, you can have up to 126 networks. And each of those networks can
have a huge number of hosts 16,777,214. And that's because we have all of these bits here
to play with for the host ID. We then got Class B, which has a 16 bit subnet mask. First assignable
address is 172 16 01 For this example, and the last address would be the 254. Here we
have 16,382 networks, so a lot more networks and the usable addresses per network has
reduced to 65 544. Lastly, we have a class C. This has a 24 bit subnet mask. And as you can see,
the number of networks has now really increased, but we don't have as many addresses Available per
network. So those are the standard classes. Now, there's also something called a private IP
address range, there's a few of these that are reserved for private use. That means not on
the internet internally, within your company, we have 10, triple zero to 10 2552 552-551-7216
00217 230-225-5255. And then 19216800321921680255. These addresses are reserved for use in private
networks. So not internet facing, you can't use these on the public Internet, things now get a
little bit more complicated. Sometimes we want to vary the length of our subnet masks. And we
don't want to stick to those standard classes. So we use something called classless inter domain
routing. And this helps us optimize the IP space. Let's have a look at some examples.
Let's say we have this network here, we have a 24 bit subnet mask, we have eight
house bits, and 254 possible addresses. The first address is dot one. The last is dot
254. Pretty standard so far, we then have a 16 bit subnet mask. So with the same network,
we're using a different subnet martyr, a non standard one in this case, because
192168 is typically a Class C network. With a 16 bits subnet mask, we have 16
host bits, and up to 65,534 addresses. And it looks like this. But what about
a slash 20 subnet mask? Well here, as you can see, we have a blue slash orange box.
And that's because we borrowed some bits from the network ID to share them and use them for
the host ID. That means we now have 12 host bits and 4094 addresses. So sometimes that's a better
configuration for the number of computers you need to have on the network and the number of networks
you actually need. And the addresses for this network would start at 01 and go up to 15.254. So
that's classless inter domain routing or cider. And it's using variable length subnet masks. In
other words, breaking away from the standard and optimizing the amount of networks and hosts
that we have. Now I know that's quite complex, and hopefully it will make more sense as we
go through the section. So that's it for this particular lesson. I hope you got lots of value
from that and I'll see you in the next lesson. Bye guys. In this lesson I'm going to teach you
about the Amazon virtual private cloud or VPC. VPC incorporates several different concepts. And
what we're going to do in this section is go into them in much more detail. So first, we'll start
off with the core knowledge around VPC itself. So within a region, we have our VP C's and they
are always within a region they can't span across regions. A VPC is essentially a logically isolated
portion of the AWS cloud that you can then use to deploy your resources inside it. And that's
different to the public space outside of the VPC where services like Amazon s3 set, this is a
private space and you have full control over how you configure your VPC. Now as you know within a
region, we have availability zones, and you can use those within your VPC by creating subnets and
assigning those subnets to an availability zone. A subnet is always assigned to one availability
zone, it can't span across multiple azs. But you can of course have multiple subnets
in the same AZ we then deploy our resources such as easy two instances into our subnets. Now
there's a thing called the VPC router. You don't really see the VPC router, but it exists, and
we interact with it by configuring route tables. Now the VPC router takes care of all routing for
connections that are going outside of a subnet. If you send data out of a subnet, it's got to go
somewhere else, maybe to another subnet, or maybe out to the internet or some other network.
So the router takes care of making sure the data connection is sent to the right place. Now as
I said, you don't see the VPC router. All you do is see the route tables and they are configuring
the VPC router for you. So we need to specify the destinations and the targets for certain
networks and that's how it then knows where to send those connection attempts. If we
want to access the internet, we also need an internet gateway, the internet gateway is attached
to your VPC, you only ever have one per VPC, the internet gateway is used for sending data
out to the internet. That's egress traffic. And in from the internet that's Ingress traffic.
And we configure our route table with a route to the internet gateway ID, that tells it to send all
traffic that doesn't fit one of the networks in the route table before it to the internet gateway.
Now you can create multiple v PCs within a region, you have a limit of five by default, but you
can request an increase on that amount. Each VPC has a cider block. That's the overall block of
addresses from which you then create the addresses you assign to your subnets. So it's kind of
like a master block of addresses. Each VPC has a different one of these. So in this case, we've got
two v PCs. And they have different cider blocks. As you learned in the last lesson, cider
stands for classless inter domain routing, from the overall cider block, we can then create
the network IDs for our subnets. And they fit within that overall cider block. But they have
a different subnet mask, so that essentially a subset of the overall available addresses and
this is why it's really important to make sure we specify our cider blocks correctly so that we
have enough networks and enough hosts per network. We'll cover that in another lesson. So here we
have two v PCs, each with different cider blocks, and then each with different subnets that come
from those cider blocks. Now we're going to cover a lot of these components within this section,
but I just want to cover them at a high level now. So you know what a VPC is and what subnets are,
you know what an internet gateway is as well. Now, an egress only internet gateway is when you're
using the IP v six protocol. And it allows traffic outbound only, whereas an internet gateway is
for IPv IP version four, and it allows both egress and Ingress traffic. As you know the router
the VPC router takes care of routing connections to the right places. Now appearing connection is
something where you can connect multiple v PCs and have private routing between them. We'll
cover that in detail later on in the section. VPC endpoints allow you to connect using private
IP addresses to public services on AWS. Again, we'll cover that in detail later on. Now, Nat
instances and gateways, we covered these earlier in the course, these are both ways that you
can enable internet connectivity outbound only for your instances in private subnets. The next
two components, the Virtual Private gateway and the customer gateway are both related to creating
virtual private network VPN connections to our company offices or our company data centers.
So that's a virtually private network and encrypted tunnel over the internet. We then have
direct connect, that avoids the internet by using private connections right the way
through to your data center or office and security groups and network ACLs are two
different types of firewall. We'll cover them in a bit more detail in this section. We've
used security groups quite a lot so far. They are what we call a instance level firewall,
because they operate at the level of the network interface attached to our EC two instances.
Then we have the network ACL, that's a subnet level firewall. So it only sees traffic going
in and out of the subnet. So just to summarize, that core knowledge of VPC is a virtual network
dedicated to your AWS account. It's similar to having your own data center inside AWS because
you're able to have full control over what you do with defining your cider blocks, creating your own
subnets, setting up your security, your routing and so on. You have lots and lots of control. It's
logically isolated from other virtual networks in the AWS cloud. And as I mentioned before you get
full control over lots of the configuration items in your VPC. And a VPC is a place where you then
launch your resources such as Amazon 82 instances. When you create a VPC, you must specify your cider
block. So that's the overall block of addresses. Now we'll see how to select the best cider block
for our use case. And another lesson a VPC spans all azs within a region. that essentially means
if there's three or six or whatever number of azs in a region, you can create subnets within
your VPC on all of those azs. But remember, each subnet is always within one AZ it can't span azs
but you create multiple subnets if you want to. In an availability zone, you get full control over
access to your resources inside a VPC as well. By default, you can create five per region. But
you can extend that if you submit a request. A default VPC is created in each region with
a subnet in each availability zone. And that's always a public subnet. So whichever region was
changed to your fine is already a default VPC and it already has a number of public subnets in
it. Now that's it for this lesson. In the next lesson, we'll have a look at how we can work
out a suitable cider block for our use case. In this lesson, we're going to look at what we
need to do to define the cider blocks, we're going to use a few of the rules and guidelines and best
practices. So first with the rules and guidelines. And these come from AWS, the cider block size can
be between a slash 16 and slash 28 subnet mask, it cannot overlap with any existing cider block
that's associated with the VPC. And you cannot increase or decrease the size of an existing
cider block. So you must get it right from the beginning, the first four and last IP address
are not available for use. So you got to account for that when you set the size of your subnets.
Because you want to make sure you have enough addresses for your instances that you deploy. AWS
recommend that you use cider blocks from the RFC 1918 ranges. Remember, these are the private IP
ranges. And that's these addresses. And of course, these give you plenty of scope. So that shouldn't
be a problem. Now let's have a look at an example. So let's say I have a VPC cider block that looks
like this. It's 10 000 with a 16 bit subnet mask. So that means it looks like this 10 000 slash 16.
So that's the overall block of addresses. But now we want to create our subnets. So what we need to
do there is we're going to take some of the bits from the host portion here and assign them to the
network portion. So maybe we're going to have 10 010 slash 24. And that means we borrowed all eight
bits from that third octet for the network ID. So your VPC subnets, will have a longer subnet
mask than the cider block that they come from. Now, in this case, it's a 24 bit subnet
mask. Now what's the next network, the next network is 10 020 slash 24. And then
the next one is 10, zero free, zero slash 24. So each of these subnets is going to have
up to 254 potential hosts. But of course, you have to take away a few from that number.
So take away five from that number. And that's how many addresses you have remaining for your
EC two instances. So as long as you're happy with that number of instances per network,
which is quite a big number still, then this is a good and very simple range to
use. Now let's go through a few additional considerations. You got to ensure you have enough
networks and hosts, you really don't want to mess this up. You only get to set the cider block once
and then you're stuck with it. So make sure you plan correctly. Bigger cider blocks are typically
better gives you more flexibility down the road. Smaller subnets are okay for most use cases
you don't need 1000s of instances per subnet. Consider deploying application tiers per subnet.
So if you have a free tier application, you might have different subnets for each tier. And you
might have it as highly available across multiple availability zones as well with a subnet in each
AZ. So that's a good way of getting that high availability and resilience into your workload.
Now VPC peering, which we're going to cover a bit later, is where you connect your VP C's so that
you can route directly between them using private IP addresses, so you don't go out to the public
Internet. Now it's really essential that you don't have overlapping cider blocks. So in other words,
you can't have the same cider block in two v PCs and connect them with VPC peering. So even if
you're not doing peering now, just remember this because you might need to do it in the future. You
want to make sure your cider blocks don't overlap. And this is across all v PCs and all regions and
all accounts so make sure you get it correct. So in general, just avoid overlapping cider blocks as
much as possible. Make sure you consider this when you're designing your IP address ranges. So let's
go back to an example. Let's say we have 10 000 slash 16. So that's our cider block. And we create
a series of subnets. Now each of these subnets has a 24 bit subnet mask and as you can see were
separating them into public and private subnets in different availability zones, the private subnets
have a private route table, and the public ones have a different route table course the main
route table for the public subnets here will have an internet gateway. And those subnets will also
assign public IP addresses to the instances that are launched in them. So that's a bit of theory
behind it and some practical examples there. I also want to show you a very useful tool that
helps you to plan out your cider blocks and your subnets. I'll attach a link to this tool to
the lesson. Now what we can do with this tool is specify our cider block and see the subnets.
And we can actually, the tool will help us to work out which subnets to use based on the number
of networks we need subnets or the number of hosts per network. So let's stick with the example and
put in 10.0 dot 0.0. And then the subnet mask, we're going to scroll down to slash 16. Now I want
to have subnets with at least 254 hosts. So that would be a standard Class C network. Now let's
have a look what we get. So let's click on Create. And it gives us all the subnets
with a slash 24 bit subnet mask that fit within the cider block. So we've got the
zero subnet here. And then all the way down, we get to the very last subnet,
which is 255. So that's 255 subnets, that we can have. And each of those
subnets can support up to 254 hosts. Of course the VPC will actually reserve a few addresses so you
won't get that many but you'll still get close to 250. So that's a really nice tool to use to help
you to work out what your subnets are going to be within your cider block. And that will also help
you to determine the best cider block as well. Hi guys, in this lesson, I'm going to show you
how to use the VPC wizard. The Wizard helps you to really easily create a VPC without having to do
much manual work at all. In my management console. Let's go down to networking and VPC. On the VPC
dashboard here, I can choose launch VPC wizard, and we then get offered four
different pre configured options. And what I want to do is just go through
what you get with each of these options. So the first one is a VPC with a single public
subnet. Very simple. You get a slash 16 cider block and a slash 24. subnet. And it's a
public subnet. So if you select this option, you can specify your cider block and it's
given you this default, you can specify a name, it's already entered the subnet cider block as
well. You could choose an AZ if you want to, or otherwise, after entering the name, you could
literally just create the VPC and it's going to do all the tasks for you. And that would include
attaching an internet gateway so that you have internet connectivity for your public subnet.
Now let's cancel out of that all let's go back, go to VPC with public and private subnets. So now
you simply get public and private subnets. And you get a network address translation device, so
you get a NAT gateway, so your private instances can access the internet. So again, with this
option, there's not too much to configure, other than the different subnets public and
private. The key difference here is your Nat gateway does need an elastic IP, so you need an
elastic IP allocation ID. Now let's go back again. And this time we're going to go to VPC with
public and private subnets and hardware VPN access. Here you have public subnets, private
subnets. And also a VPN tunnel gets created. Now you need to have a VPN device in your
corporate data center. If we select this option, and let's just give this a name, my VBC. And leave
the defaults on this page, click on Next. And then it's going to ask for the customer gateway IP
and that's the IP address of your VPN device on your side of the network on your corporate
data center. So if you specify those details, when you create this VPC, it's going to make
that connection. Let's just go back, back again. And the last one at the bottom is VPC with a
private subnet only and hardware VPN access the same as the one before except that you
only have a private subnet. So you've got a VPN connection from your corporate data center
to a private subnet on AWS, with no routing going out via the internet from that subnet in
AWS. So those are the four options. I just wanted to quickly show you through them. And in the next
lesson, we'll actually create our own custom VPC. In this lesson, we're going to create a
custom VPC with public and private subnets. Now let's have a look at what we're going to
create So we're going to use the same example cider block we've seen in the section, it's going
to be a 10 000 network with a 16 bit subnet mask, that's the overall block of addresses, then
we're going to create these four subnets. We've got private one a in private one, B, and public
one, a public one, B, and the one a and the one B mean that they're associated with a specific
availability zone. Now for the private subnets will have a private route table for the public
subnets will have this main route table that's created, by default, will attach an internet
gateway to our VPC. And the main route table will have a route via the internet gateway out
to the internet for those public subnets. We also must specify that we want our instances to
pick up a public IP address automatically. So that's the configuration let's head over to the
console and build this out. In the VPC dashboard. I'm going to go to your V PCs, and we just have a
single default VPC. So let's create a new one. In your course download in the code directory, Amazon
VPC, you'll have this file a custom bash VPC, we can simply copy values. So I've got the
name, that's going to go under name tag, let's copy the cider block and put that under
ipv4 cider block. We're not going to do ipv6 at this stage. In this course, we'll leave the
tenancy as default. If you change to dedicated, it's going to put your instances on hardware
that's dedicated to you, and that's going to cost you more money. So definitely leave that as
default. And that's all we need to do to create the VPC. So the VPC is being created. One thing I
like to do is go to actions, edit DNS host names, and enable, that means we will get DNS
hostnames for our EC two instances. The next task is to create our subnets we've got
public subnets and private subnets. So I'm just going to copy these values to my clipboard, we'll
come back Go down to subnets. Create subnets, we need to specify our VPC. So my VPC and then we
can put in the name and the subnet name, choose the availability zone as one a US East one a. And
then the IP B's for cider block, we'll come back, we'll copy this cider block. And we'll paste
that in. Now we could create the subnet there or we can add a new one. And we're just going to
do the same for the next three subnets. So just go through this file and copy the settings for your
additional free subnets. When you finished your page should look like this, you've got public one
a in US East one a, we have a 10 01 cyber block, and then you've got subnet to public one, B,
and that should be in US East one, B, so let's modify that. And 10 zero to private one a should
also be in US East one, a 10, zero free, and then private one B in US East one, b 10 04. So that
all looks good. Let's create all four subnets. And that's the four subnets created. Now for our
public subnets. We want to go to actions here, modify auto assign IP settings, and enable
the auto assignment of public ipv4 addresses. So I've done that for public one, B, let's do
it for public one, a. And those are updated now. So the next thing I want to do is I need to
create a route table for my private subnets. So they're not attached to the main route
table, which is where the public subnets will be. So let's go to route tables. Create
route table, we're going to specify a name, I have that in my clipboard from the file
private RT. For VPC, I'm going to select my VPC. And then we'll create the route table. Once
that's created, go to subnet associations, edit subnet associations, and you want to select
private one B and private one a and save. So now we've done that if we go into subnet associations,
we should see an explicit Association for private one A and B. If we come back up to route
tables, we'll see the other route table here. So this is the main route table or the public route
table if you like. And under subnet associations, there are no explicit subnet associations, but
one a and one B public are associated implicitly. The next thing I need to do is go and create an
internet gateway. So under internet gateways, here let's create an internet gateway. We'll
give it a name. And let's just paste this value in from the file and create internet gateway.
Once it's been created, it needs to be attached and the actions you can attach to VPC, select
the VPC and then attach the internet gateway. Now the last thing we need to do now we have an
internet gateway. We do not route from our main route table. So let's go to the main route table
here. Go to routes, edit routes, add a route, and we'll put in the 0000 slash zero, choose our
internet gateway. And there it is in the list. So now, everything within the cider block
will be routed locally by the VPC router. And everything that's not within that VPC cider
block will go out to the internet via the internet gateway. So let's just save those changes. So
that's it, we've created our custom VPC with public subnets, private subnets to route tables,
and an internet gateway. Now, that's all I need to do for this particular lesson. In the next lesson,
what I'd like to do is launch some instances and just test our configuration and make
sure we have the communication we expect. So we've created our custom VPC and I've just like
to test that now. So we're going to launch some easy two instances, two instances in two different
public subnets and one in a private subnet. And we're actually going to do that via the command
line, it's really useful to know the command line. Now not all exams require you to know the command
line. So for the solutions architect associate, doesn't really matter too much. For the developer,
it does a bit more for certain services, and definitely for the sysops exam. Now, whatever
exam you're doing, or whatever career path you're taking in AWS, it's still a really useful skill
to have. So it's definitely worth learning the command line. So we'll launch some instances
using the command line. And then we'll use those instances just to test connectivity with each
other. There's a couple of things I want to do before we get started there. Firstly, I want to
create a NAT gateway. So I'm in the VPC Management Console. Under Nat gateways, let's create a NAT
gateway, I'm just going to call it my Nat GW, and I need to select a subnet. Now remember, with
Nat gateways, they always go in public subnets. So here, I'm going to choose public one a, and
that I know is within the correct VPC as well. So connectivity is public, we allocate an elastic
IP, and then just create the NAT gateway. Now, of course, it won't work until we update
the route table for our private subnets. So under route tables, let's choose the private
RT. Go to routes, edit routes, add route, and we're gonna specify 000 slash zero. And
this time, it's going to be a NAT gateway. And we'll choose that Nat gateway ID. Now our
private subnets will have access to the internet. And that's important because when our instance
launches, we're going to run some user data. And that's going to connect to the internet to
download some binaries for httpd. Next thing is under security groups, we need a security group.
Let's create a security group. I'm going to call it public that web, give it a description, and
make sure I select my VPC. For outbound rules. By default, it allows all traffic to any destination.
For inbound just for now, we're going to add all traffic from any destination. So this is
very open, don't worry, we're going to lock it down in a subsequent lesson and practice with some
different security group configurations. But for now, let's just open everything up. I'm going to
create my security group, and that's ready to use. There's a file in your course download. And that's
in the code Amazon VPC directory, and it's AWS COI run instances, we need to add some values into
this file. The first thing we need to do for this command is specify an image ID. So the command is
AWS easy to run dash instances. And these are the values that we need to specify. So first, let's
find the AMI ID that we want to use. ami IDs are region specific. So we've got to make sure
that everything we do in this lesson is within the same region. It's also where you created your
custom VPC. So for me, that's North Virginia, hopefully it's the same for you. Let's launch
an instance. Next to the Amazon Linux two ami. Let's grab this ami ID don't take anything in
brackets there, copy that to the clipboard. Come back and paste that in the instance type
we can just type this in, it's just going to be T two dot micro for security group IDs. Let's
go back and find the ID of our security group. I can see my public web access security group.
Let's just copy the security group ID come back and paste that one in. Then we need the subnet ID.
This time I'm back in the VPC Management Console. Let's go to subnets. First I want the public
one a subnet ID. So I'm just going to copy that to my clipboard. Key name is the key pair
that you're using in this specific region. Back in EC two, you can go to key pairs if you don't
remember what it is, and just copy this name. And we can paste that in. Lastly, there's
some user data that we're going to specify. Now this is the user data file. What it does is
runs a web server. And then it creates a couple of variables from the metadata were actually
grabs the subnet ID, and it basically just puts that into a simple web page. So we can see where
the instance is running. In our command here, we just need to specify the name of that file. Now
what you want to do is change to your Amazon VPC directory, where we have all this information. And
this is where the file is. So copy that to your clipboard, make sure you have the file colon slash
slash, and then the name of your file. Let's copy this and make sure it works. Before we fill out
the other two, now, you will have had to run AWS configure, before you do this exercise, you should
have specified an access key ID secret access key. And your region must be the same as the region
where we're trying to deploy our instances now. So mine's all good. Let's paste in this command
and run the command. And that appears successful. And we can see that we have an instance running
in US East one a. And there's quite a bit of information if you just spacebar and go down
the page here. So let's go into EC two and check it's launching back in 82, I can see I have this
instance at the bottom here running. Now I'm just going to label this one as public one a so I know
which one it is. Now the next thing we need to do is to go back over to the VPC Management
Console, take the subnet ID of public one, B and come back to our file. And we're going to use
this one. So what we can do is copy all of this, put it in one be here. And then I'm going to
take this subnet ID, and just override this one here. So we should now be able to launch into
public one B, let's copy this to our clipboard, come back and paste it in. That looks good. If I
refresh the page here, and we have this pending instance, that's the public one be. So I'll just
give that a label so we know which one it is. And then lastly, we're going to launch the
instance in our private subnet. So again, I just need to get the subnet ID for private one
v. So I've copied that to my clipboard, come back, paste that in. And now we have the command. And
this user data should run okay in the private subnet, because we're able to connect out to the
internet via the NAT gateway. So I paste this in, hit enter. There we go, we should have another
instance, back in easy to I can see my pending instance here. So let's call this one private, one
be great. So I have these instances, let's just give a refresh and see where we're at. So a couple
of them are running let's saw by name, that might make things a bit easier. I'm just going to copy
to my clipboard, the public IP for public one a, and paste this into a browser window. And I get
this web page. And it gives me the subnet ID. So that should correspond with the subnet for
public one A. So that's great, we've proved that we can connect from the internet to our EC
two instance. Now the other thing I want to do is connect between my EC two instances back in
the console here, what I'm going to do is connect to public one, I use the EC two instance Connect.
And while that's just connecting, let's come back. Next I want to get the private IP address of my
public one B instance. And that's 10, zero to 25. And let's just change back to the EC two instance
Connect. And I'm going to ping 10 dot 0.2 dot 25. And let's see if that response. So that proves
that we have connectivity to our instance, in the other public subnet public subnet one B. So we
have two way connectivity, the responses coming back as well. So that's great. Lastly, let's
check that we can connect to our private subnet. So let's see what the private IP address is.
It's 10 04148. So let's ping 10.0 dot 4.148. And let's see if that works. And it does so we get
an ICMP response. So that's great that shows that we have that connectivity working. One other thing
we could do from here is see if we can connect to that web page. So we'll use the curl command
and specify 10.0 dot 4.148 and hit Enter. And we get a response here that says this instance
is in the subnet with ID and it gives us the subnet ID. So that's the h1 header for the
HTML web page that we have on that website. So we We can see that we have Port 80. Open as
well, were able to connect to the instance in the private subnet. And we can also infer from that,
that the instance can connect out to the internet because it was able to install that web service.
So that's it for our connectivity testing for now. Now I'm going to leave all of these instances
and the NAT gateway running, because we're going to come back and carry on when we do some
testing with security groups and network ACLs. Guys, security groups and network access control
lists. ACLs are two different types of firewall that we can apply in our AWS environment. So let's
have a look at how they work. So here we have a VPC with two availability zones. And we've got a
couple of public and private subnets. And we've got a few EC two instances that have been launched
into different public subnets and private subnets. So let's see how we can control traffic.
Firstly, we can apply something called a network access control list or network ACL. Now
these get applied at the subnet level. So you can see that they're sitting here at the edge of the
subnet. Now, all traffic that goes into and out of a subnet will go through a network ACL. So you're
essentially filtering traffic as it enters or exits the subnet. So ingress and egress traffic,
a security group is different. A security group actually applies at the instance level of an EC
two instance, actually at the network interface level of the EC two instance. So that means we
can have a security group that is applied to EC two instances in different subnets. So this
is the same security group Security Group A, and it's been applied to instances
in several different subnets. So remember that this is the instance level, that
means it's going to filter traffic going between instances in the same subnet, or across different
subnets, we could then have security group B, that's attached to different instances. So
security groups can be applied to instances in any subnet. Now, what happens here with these security
groups, is the same basic thing as a network ACL. They're looking for traffic that's going
in and out of the security group. So if you send traffic from an instance, in security
group A, to an instance, in security group B, it's going to check that there's a rule to allow
the outbound traffic, and then it's going to check here, the Security Group B is going to check Am I
going to allow the traffic from Security Group A, and you can do that by IP address, or you can
actually do it by the ID of the security group itself, we'll look at all this in detail in the
hands on as well. Now I want to talk to you about stateful versus state less firewalls, because
the security group is a stateful firewall. And a network ACL is a stateless firewall. And it's
really important to understand the difference. So let's look at an example. We have a client
here. So this is a computer that wants to access a service on a web server, and we've got a
firewall in the middle. So what happens is the client is going to connect to the server, the
server is a web server, it's listening on port 80. The Source port is the port that's assigned
to the connection by the computer. And this is what's called a high numbered port is
a port above 1024. And it's dynamically assigned for every connection. So we have
a source port and a destination port. And we have a source and destination IP as well.
Now the return traffic has a source port of Port 80, because that's where the web service port
runs, and the destination port of 65188. And of course the IPS are switched around as well.
So the destination IP will be the client, the source IP will be the web server. Now what
do we need in the firewall rule table to allow this to work? Well, what we need here is we
need a rule for HTTP that allows the source IP 10.1 dot 1.1 to talk to the destination IP
10 dot 2.1 dot 10. And it has to have the source port and the destination port specified. Now of
course, this is a dynamically assigned port. So we don't know what that is ahead of time. So what
you'd most likely have here is any so rather than having the source port specified we'd have the
any specified so any source port is acceptable. And then rather than a specific source IP,
we might have any because it's an internet based connection. So those are things that
we can play around with in our rule tables. But the destination port will always be 80
because that's where the web server runs. So we want to make sure that we don't allow
connections to any ports on the web server. Now that's the traffic coming inbound
to the web server. What about the return traffic going back? Well, in that case, things are
swapped around. So we've got the same protocol, the source IP of the web server, the destination
IP of the client, and the source port of 80, and the destination port of the dynamic port at
the clients. Now again, you'd probably have the destination port, and the destination IP is any,
because you want to allow traffic coming from any client on the internet if you're running a
public web service, but you still might need a rule set for the outbound traffic. And this is
where the difference comes in between stateful and stateless firewalls. So a stateful firewall
will allow the return traffic automatically. Now this is what a security group is, what that
means is with a security group, you only need this roll up the top here, you need a role that
says that you're going to allow the traffic from whatever client on whatever port, but you're going
to allow inbound to Port 80 on your web server. And then the return traffic is automatically
allowed. So you don't have to worry about the return traffic is going to just go out
automatically, it's going to be allowed because the firewall is clever enough to know that that's
part of the connection. And so it just allows that return traffic. Now a state less viable checks
for an allow rule for both connections. Now, this is what a network ACL does. So we have
a network ACL, you need both the inbound rule and the outbound rule. So you need to make
sure that you have the inbound rule for traffic coming in, and the outbound rule for traffic
going back. Even if it's the same connection, it doesn't understand that that's part of the same
connection, it treats them separately. So really important to understand those differences when you
configure your network ACLs. Now let's have a look at a security group. This is what a security group
rule set looks like. So here we have separate rules defined for inbound and outbound traffic,
what we're looking at here is the inbound traffic. Now again, because it's stateful, we don't have to
have a rule for the return traffic. But we still might need an outbound rule for traffic going out
from our instances. So when our instances that are attached to the security group are initiating
connections outbound. so here we can see we have several rules using different protocols. And
we've got the protocol specified the port range, and then the source. And the source in many cases
might be either an IP address or IP address range. Or it can be a security group ID as well. security
groups support allow rules only. So there's no such thing as a deny rule in a security group.
Essentially, there's an implicit deny rule at the end of the rule set. And it's going to check
for an allow, and if there is no allow, then by default, it's just going to deny the traffic. As
I mentioned, a security group can use a source of an IP address an IP address range, or the security
group ID of itself or another security group. Now let's have a look at a best practice configuration
when using security groups. What we have here is a public subnet and a private subnet. And we've got
an internet facing load balancer. So this is going to distribute traffic to our web servers. So we
have a load balancer, we have a web server front end. So this is the one that's actually users are
connecting to from the internet. And then there's an application layer that's going to process data.
And this could have multiple servers. So we have a load balancer. And we need a connections to be
able to come from our clients on the internet through to the application layer, it might then
write to a database. I haven't shown that in this diagram. So let's see how we set this up. Firstly,
we create a security group for the public iob. It allows traffic on port 80 for the web service
from any source on the internet. Now outbound it has because it's going to now create a connection
to the web front end. It has a role that allows outbound access to Port 80. And we've specified
the actual security group ID public easy to. So that's the name of this security group. So
it's only going to allow traffic outbound to the web front end, the web front end allows
traffic only from the public lb on port 80. And then it has a destination for outbound traffic
of another security group called private lb, and a port of 8080. So that's what that particular
application is listening on. The private lb security group will in turn, only allow inbound
traffic from the public EC to security group. And it will only allow outbound traffic to the
private easy to security group. And that's the one which has the application layer in it. So
that's a way that we're locking down access to the different layers of our application,
and ensuring that the application can talk to other components but nothing else can.
So that's the best practice security group configuration. Now let's have a look at network
ACLs. One of the first things you'll notice is we have inbound and outbound rules. Again,
and we have allow and deny rules. So with NaCl, you can have an explicit deny that's different
to security groups. Remember, security groups only support allow rules. Rules are processed
in order. So you can see that they're numbered. So we typically number our rules. And you might
want to say that the next rules that you add in are 202 101. And then 303 101, you could work out
your own process for how you assign those numbers, but just remember that they will be processed
in order. Now, the important facts about that means that once you actually reach a rule that
either allows or denies traffic, the processing stops there. So if we have an allow rule at 100,
that allows the traffic, then even if you had a deny rule, later on in the rule set for that
specific traffic, it's not going to get there, it's going to allow it because it reaches DLL
and processing finishes. So you've got to be very careful with how you set up your rules the order
that you create them in, and just remember that they will be processed in order, and then when
an allow or deny is reached, then that's the end of the processing, it will either allow or deny
the connection. So that's it for the theory. In the next lesson, we're going to do some hands on
and set up our security groups, and network ACLs. Hi, guys, in this lesson, we're going to use
security groups and network ACLs. And we should already have some instances running from earlier
on in this section. So you should have free instances running to in a public subnet, and one
in a private subnet. And what we're going to do is test various configurations of security groups,
and network ACLs. Now the first thing I need to do back in EC two is go to security groups. And I'm
going to create a new security group. So we have the public web. Now we're going to create the
private app. So this security group is going to be called private dash app. I've given it
a description. And let's choose my VPC for the VPC. Now, what will the rule be here? Well,
I'm actually going to delete the outbound rules we've already configured, we've given internet
access to this particular instance before. So we were able to download httpd when we
installed the web service. But for now, I'm going to take out outbound rules, which means
From now on, it won't be able to connect out to the internet for inbound rules, what I want to do
is use HTTP. So let's just scroll down, find HTTP, that's the protocol for the web server. And for
source, what I'm going to do here is type s, G. And I can see my public web access. So I'm doing
the best practice here, what I want to do is make sure that the web server in our app there is only
ever going to allow connections that come from the web servers on the front end the public facing web
servers in this security group. So let's create that security group. Now we need to assign it to
our instance. So let's choose private one, B, go to actions, security, change security groups.
And we're going to remove public web. And we're going to choose private app, click on Add
security group, and then click on Save. Great, so that should be set up correctly. Now, the first
thing I want to do, though, is test the access to the security group on our front end. So what I'm
going to do is go to security groups, choose the public web security group. And under inbound
rules, I'm going to edit the inbound rules. And what I want to do here is change from all traffic.
And again, we're going to choose HTTP only. We're going to remove the any source, and we're going to
specify my IP. So what that will do is it picks up my IP address. And that means that I will
be able to connect over the Internet to this particular web service. Now I'm actually using a
VPN and we're going to change it in a moment. So if you do have access to a VPN, you'll be able
to do this as well. Otherwise, it can be a little bit difficult unless you have multiple public IPs.
But I just want to show you the concept anyway. So let's just save this rule, come back to instances,
take the public IP address. And in a browser, let's just hit Enter. And that looks great.
So I get access to this instance. Now what I'm going to do is I'm just going to go in
and change my VPN here. So I'm connecting to a different service. And that means I've got a
different IP now. So let's just refresh the page. Now you can't see anything happening. But if you
look up in the top browser bar here, we can see we're trying to connect and this is what happens
with security groups. When you can't connect, it kind of just hangs for quite a while
and then eventually it will timeout. So that's definitely working. We're
not able to access the instance now. If I come back to security groups, and what I'd
rather do is choose my public web security group edit inbound rules. And instead,
I'm going to change this to any ipv4, because this is a web service. So we
want anyone on the internet to be able to connect. So let's just save that rule. And back over here,
it failed to connect, let's refresh. And now we're back in again. So that's a good configuration.
Now our web service is allowing only HTTP from the internet. And then it should be able to forward
on to the App Service, because of the security group rules we set up before. So let's test that
layer. Now back in EC two, let's go to instances. And what I want to do here is connect to my
public one instance, over instance, connect. And I'm going to check the private IP address of
my instance in my private subnet. And that's 10 04148. Now I've just noticed one of the things
we have done here, we've got to secure so we've locked ourselves out. Now if you just click on
this note here, it takes you over to an article. And we can see that we actually need Port 22 from
our IP address to be able to access the instance. So let's go back and set this up as a secure
configuration. So going back into security groups, what we need to do is go to public
web, edit inbound rules, add a rule. And this one can be SSH. And what we'll do here
is we're just going to add any internet address because I might be changing my internet
address a couple of times. So otherwise, of course, you could use my IP, or have a range
of addresses that you trust, that will be a more secure configuration. But for now we will be
changing IPS. So I'm happy to have that as open. So let's save those rules. Now let's try
and retry this instance Connect, and we're in. So the way I want to try and test that we can
connect to our AP layer is using curl dash s and then putting in the IP 10 04 dash 148. Let's
hit Enter, and we get a response. So that's great. Now remember, we didn't have an outbound rule
from that security group. So the response traffic is coming back purely because this is a stateful
firewall. So that's it for security groups. Let's move on and have a look at configuring a network
ACL back into VPC Management Console. Let's go to network ACLs. And what we'll see is there are
already network ACLs. So we've got one here for our custom VPC. Now let's go in and have a look
at the configuration. So we have inbound rules, we have a rule number 100, allowing all traffic
inbound. And then at the end, we have a deny rule. So remember, these get processed in order.
So in this case, everything gets allowed because of the allow rule. So the deny rule doesn't get
processed. outbound, we've got exactly the same thing. So let's try something, what I'm going
to do is edit the inbound rules. And I'm going to add a rule. And I'm going to make this one
on one. And what I'm going to do is specify HTTP source is going to be my IP address. So I
know my IP address is this one at the moment. So I put slash 32 for an exact match. And I'm
going to click on deny. So I'm going to deny access from this particular IP address to http.
Now do you think this is going to work? Hopefully, you realize there's an error here, but let's just
save the changes. And we'll go and check it out. Back in easy too. I'm just going to copy the
public IP of my instance, go to a new web page, hit Enter, and I get access. So of course,
that didn't work. Now let's go and see why. Back in the VPC Management Console, let's edit
these rules for the network ACL. Now as you know, rules get processed in order. So we've got a deny
rule here that's after and allow the allow allows everything. So actually, this is not going
to work. Let's change this to 99 sort by rule order. And now we have a specific deny before and
allow. So essentially, it's going to look through the rule set, it's going to see that traffic's
coming in on port 80 from this particular IP, and it's going to deny it. So we never get to
the alarm rule for this particular traffic. So let's save changes. So we'll go and test this
out now. But there's just one thing that you need to understand with security group rules, when
you apply them, they do actually get put into effect pretty much immediately, there can be a
bit more of a delay with a network ACL. So if you find you still have access to your instance, then
it's probably just because you're a bit too fast. So just give it a couple of minutes and try
again. And we should find that we do get denied in a browser window here. Let's paste in our
IP address. And sure enough, it looks like it's hanging. So that's clearly not working. Now what
if I change my IP So this time I can change to somewhere different and very quickly, this time,
the connection did actually change, and it did allow me in. So sometimes the network ACL rules
apply super fast. And sometimes there's a bit of a delay. So it really can vary. So that shows
you how to use a deny rule with a network ACL. Now I'm just going to come back in and clean up
that rule. So I don't want to have any deny rules in my network ACL. So let's just remove that one
out from the inbound rules, and save changes. Now there are a couple of things we can clean up now
to make sure that we don't get any bills. Firstly, let's go to our Nat gateway, these can cost money.
So let's just delete this Nat gateway. And that's gone. And don't forget, you will also need to make
sure that the elastic IP has also been removed from your account back in easy to Now I do want
to keep one public and one private instance. But I can terminate the other public instance. Now
we will actually use the command line for this, I just want to show you another ci command.
Back in our file here, we can specify the values for our DC two instances. So I've just got
one here. So I'm going to put it in inverted commas. Copy this command, and back in my command
line, let's just try and terminate this instance. And when you do that, you'll see that the current
state is shutting down, and the previous state was running. So we now know that our EC two instance
is being terminated. So that's it for now, but do leave those other two instances running because
we will be using them in subsequent lessons. Hello, and welcome to this lesson. There are
quite a few circumstances where we might want to be able to connect machines that were running
in different v PCs together using ipv4 or ipv6. So for instance, we might have two v PCs,
which could be in the same region. It could be in a different region or even a different
account. And we want the easy two instances in those two v PCs to be able to communicate using
private ipv4 addresses or maybe ipv6 addresses. Now a way that we can do that is to use
VPC, peering. VPC peering allows routing for those addresses internally between those v
PCs. And when I say internally, what I mean is, it's not going out to the internet. It's using the
AWS global network to route traffic between the VPC so it never touches the internet. It does
get encrypted when it moves between regions, and it uses private ipv4 and also ipv6 addresses.
So it's a great technology for lots of use cases. Let's have a look at how we can use VPC peering.
So let's say we have a VPC, this is VPC a, and then we have another VPC, VPC B, and we
want to be able to route connections between these two. So we got easy two instances, maybe RDS
databases, even lambda functions, anything that communicates inside a VPC and we want to be able
to connect those resources together using private ipv4 addresses. So what we can do is establish a
VPC peering connection between those two v PCs. So this will enable routing using private ipv4
addresses, or ipv6 addresses. Now, the cider blocks for our VP C's must not overlap. So this
is a very important consideration when you're choosing the cider blocks to use your VP C's.
Because even if they're in different accounts, you might someday want to connect your VP C's
together. And if they have the same cider blocks or cider blocks to overlap with each other, then
that won't work. So you must have cider blocks that don't overlap. Now what if we have another
VPC, VPC and VPC d A fourth one? So they all have their own cider blocks so looks good. We can
definitely set up VPC peering between these. So what we do we establish a VPC peering
connection between BBC a and VPC c between VPC B and VPC D and then with VBC C and BBC D.
So we now have four peering connection sets up. But the problem with VPC peering is it doesn't
support transitive peering. Now what that means is, let's say we have resources and VPC a,
and it has a peering connection with VPC B. VPC B then has a peering connection with VPC
D. So does that mean that bpca can communicate with resources in VPC d? By going via the VPC
B Well, no, it doesn't work. transitive routing doesn't work. So what we actually have to do is
set up two more peering connections. We've now got a peering connection between A and D, and between
B and C. So we've got a full mesh topology. Because VPC peering doesn't support transitive
relationships. We do need this full mesh. So that becomes quite a lot of connections. Now with
these four v PCs, it's not too bad. But you can imagine if you spread this out across a lot more
v PCs, soon this full mesh topology means you've got a huge number of connections to set up and to
manage. So it becomes a bit unwieldy. And there are other solutions, which we're going to look at
later on in the section and in sections to come. Now, as I mentioned before, the VP C's can be in
different accounts, and they can be in different regions as well. Now let's have a look in a bit
more detail about how we set this up. So we've got Region One, and we've got region two. So
in this example, we got two v PCs in different regions could be in the same account or different
accounts, and we want to pair them together. Now they each have their own cider blocks, which are
unique, they're not overlapping, so that's good. And then we've got some subnets. Now these could
be private or public subnets. Because remember, it's the private addresses of the instances that
will be used for the VPC, to VPC communication. And we've got some instances running in these
subnets. Now I'm showing public because we're going to set up a lab very much like this,
it makes it easier for us to connect to our EC two instances if they're in public subnets.
So we create a VPC peering connection. And I'll show you how to do this in the console. Now the
next thing we need to do is set up our security groups. So let's say we want to use the ICMP
protocol to send a ping request from one instance to another, and the other instance back again.
Well, in that case, we have to set up a security group rules as well. And we can use the cider of
the other region. So we can use the cider block as the source and say that anything coming from
that cider block is going to be allowed based on this rule. Now another thing we have to set up for
this to work is the route tables. And what we do is we have a destination route, which
goes to the cider block of the remote VPC. And we specify the peering IDs, when we set up
the peering connection will have a peering ID, and we're going to specify that as a target.
And then we do the reverse on the other side, so that the route table will send any
traffic destined for this cider block to the peering connection, and then it
gets routed across to the correct VPC. Hi, guys, in this lesson, we're going to create
a VPC peering connection between two v PCs in two different accounts. So the configuration is going
to be pretty much what we see on the screen here, we have our management account in our AWS
organization and our production account. And we're going to have a VPC in each using these
cider blocks. And then we're going to create security groups. And we're going to specify these
particular rules. Now, firstly, let's have a look at how we establish the connection, we need to
establish a peering connection between the VP C's, and we can do that in the console. Then we need to
update the route table really important that you have a route to your target. So the route table
for this VPC must specify as a destination the cider block of the other VPC and the pairing
target, and then the reverse is true. Over on the right hand side. Our security group rules
will ensure we can use SSH and ICMP to connect and the way we will test the connectivity
is to ping from one instance to the other using the private IP address and that will show
us that we're using the VPC peering connection and not the internet. Now there is a bit of background
work you need to do before we get started. So unless you want to use the default VPC in your
production account, you should create a new VPC using the same ranges I just showed you. So from
the VPC Management Console, you're going to want to change to DCT production, go to your VP C's and
then create a VPC. Now I've already created mine, and I have the values for you in a file. So just
open the code Amazon VPC, custom VPC dash prod file, and this is the information you need there.
You know how to do this, you've done it earlier on in this section. So just create this VPC and
add the subnets. Add your internet gateway, your private route table, and then we're good
to go. Now we don't need all of this for this particular exercise, but let's just create it
standard as per the VPC in our management account, and then we might use some of these
subnets later on. So let's get started. Now I need a couple of pieces of information.
With my VPC selected in my product count. I'm going to copy this owner ID that's the
account ID and I'm going to put that into my file. Next I need the VPC ID and let's put that
in the file. Now we're going to switch back to the management account. Let's go to peering
connections create peering connection. We need to give it a name. Let's just call it my
peer. Select the local VPC, which is my VPC We can choose another account rather than my
account and copy this account ID. we'll paste that in. We're going to stick to the same region,
but we need the VPC ID on the other end as well. So that's the one that we copied here. So let's
copy that to our clipboard, paste that in and create the peering connection. So it says here
a VPC peering connection, PC x, and then it's going to number my peer has been requested, the
owner of the remote VPC must accept the peering connection. So let's go back and do that. Let's
go to DCC production, go to peering connections, and we can see the request pending acceptance. So
just select it on the left, and then go to actions accept request. And we can accept that one. And
that's done. Now one of the things we're going to need to test is going to be an easy to instance.
So let's launch an easy to instance. But before we actually launch that one, I'm going to create
the security group, the security group is going to be called VPC pair dash prod. And these are
the rules we're going to set up. So let's create a security group. Give it a name. I just put that
in the description as well. Choose the correct VPC and the outbound rule is fine. For now. All
we need is the inbound rules to be set up. The first rule I'm going to set up is ICMP ipv4.
So all ICMP that's going to allow ping requests, and it's going to come from 10.0 dot 0.0 slash 16.
The next row is SSH, you can either do custom TCP and put in the port range, or choose SSH, and it
will do it for you. And same as the one above, we just want to give it the same addresses. So this
should allow inbound connections from the VPC in the other account in the management account using
from any IP address in the entire cider block. So we can save the security group. Now let's
launch an instance that uses that security group. So I'm going to launch an instance,
it's going to be Linux to ami, T to micro, make sure you select your
VPC, I'm going to put it into my public subnet public one a. Let's click on
Next, go through to security group. And we're going to select a security group.
And that's going to be VPC peer prod, click on review and launch and launch. If
you don't have a key pair for this region, which I don't at the stage, then I'm going to
create a new one. I've called it prod dash and V or download that key pair and then launch my
instance. So now let's go back in the city management console to the management account. In
the management account, we need to set up this security group and we're going to assign that
to one of our instances in a public subnet. So in this account, we've got two instances
running, let's go to security groups create a security group. It's called VPC, pair
dash MGMT. I'll put the same in the description, select the correct VPC. And then let's add the
same rules as before. This time, the block is going to be 10.1 dot 0.0 slash 16. So now we have
the same protocol specified so we should be able to connect from the prod VPC to the management
VPC using these protocols as well. So let's create that security group. Go back to instances public
one a actions security, change security groups. And we're going to add in VPC pair dash MGMT.
And the reason I'm not going to remove public web is because we have a role in there allowing access
from the internet to Port 22, which we need for instance, connect. So with those two added, let's
save the security group configuration. And the very last thing that we don't want to forget is
our route tables. So let's go and do that. Now. Back in the VPC console for my management
account, I'm going to go to my main route table, choose routes, edit, add, this one's going to
be 10.1 dot 0.0 slash 16. And it's going to go over a peering connection. We've only got one of
those, and it's called my pair. So let's save that switch across to the DCT production account. We
need to choose the main route table. I didn't label this one. Let's do it now. But I can
see that it's attached to my VPC. So let's go to routes, edit routes, add. And this one
should be for 10.0 dot 0.0 slash 16. And again, we're going to specify peering connection, it's
going to see the same peering connection, and we can save changes. So that's it hopefully it's all
set up. Now we've updated our route tables. We've got these two security groups with rules so that
we should be able to use these protocols based on our private IP addresses. So that's that's the
real test areas to Use private IP addresses to see if we can connect, we can definitely ping via the
public IPs if we've got our security group rules set up correctly, but we want to do it via private
IP is because that shows that rather than going out to an internet gateway, we're sticking within
the private space across the peering connection, back in easy to, let's select the instance ID, and
we want to copy the private IP address, I'm going to just put that into my file here. And coming
back here, let's switch to the management account. Choose the public one a instance, connect
by instance Connect. And let me just try and remember this IP 10 11221. So let's ping 10.1
dot 1.2 to one and hit Enter. And there we go, we get a response. That's across accounts. And
it's also across regions. And it shows we've got this bi directional traffic going between these
two v PCs. The other protocol we enabled was SSH. So let's just make sure that we can create
an SSH connection 10.1 dot 1.2 to one. And we can now I'm not actually going to log in, because
I need my key pair. And I'd need to specify some more details as well. But I just want to see
that the port is open. And that shows that the security groups are set up correctly, as well as
the underlying networking to allow this traffic over private IP addresses. So that's really it
for this lesson. Now, the only other thing you might want to do is you can practice by doing
the same thing and extending this configuration through to your instance in your private subnet.
Use your public subnet instance as a bastion host, you might have to use agent forwarding, and then
make sure you can connect bidirectionally from there as well. So that's just an additional
bit of fun that you might want to have if you want to practice a bit more. So now that
we've finished with this lab, we can actually terminate our instance, in the private subnet.
We didn't use that in this lab unless you carried on with the configuration. But
we will leave the public instance running for now. So let's terminate this instance.
And then you should go over to your production environment as well and terminate your EC two
instance there, and then we're all cleaned up. You'll remember that earlier in the course I
talked about how some AWS services are private in that they run within a VPC like EC two,
whereas other services are public because they have a public endpoint like Amazon
s3, for example. So that means when you connect to Amazon s3, you use a public DNS
name, so connect to it as a public endpoint. Now, what if you wanted to connect an instance to
Amazon s3, but you didn't want to use the public Internet, it might be an instance in a private
subnet. Well, that's where VPC endpoints come in. And there's a few use cases for VPC endpoints
with connecting privately to s3 being one of them. And there are two different types. There's a VPC
interface endpoint and a VPC gateway endpoint, the gateway endpoint is one which we can use
for s3. And the interface endpoint is slightly different is used for other services. So let's
start there. First, let's look at an example using a VPC interface endpoint. So we've got AC
two running in a private subnet. And we don't want this instance to have a public IP. And we
don't want it to be routed out to the internet via a NAT gateway. So we provision an interface
endpoint, which creates an EMI in the subnet. And then the instance can connect via that EMI
to public services, but it's using private IP addresses to connect to them. Now each interface
endpoint can connect to one of many AWS services. And you can connect to an AWS private link powered
service as well. We'll look at that shortly to see what that means. So this is a way that we can
connect our EC two instances to these services using private IP addresses. Now let's look at the
difference between that and a gateway endpoint. So in this case, I want to connect to Amazon
s3 to store data in an s3 bucket. And again, I don't want to have a public IP address. So
an instance in a public subnet, in this case, it is in a private subnet. And I don't want to
provision a NAT gateway, or at least I don't want this traffic to go out to the internet.
So I could provision a s free gateway endpoint. This is slightly different. It uses a route table
entry. So we now have to put a route table entry to point our traffic to the s3 gateway endpoints.
And that uses the prefix list for the s3 and the gateway ID. The instance again connects using a
private IP address to the gateway endpoint. And then from there, it connects to Amazon s3. Now you
can secure this with Im policies so you can apply a policy to the endpoint. And you can also apply
bucket policies. So for example, you can have a bucket policy that limits access to any traffic
that's coming from the gateway endpoint. So you now have a bucket Which will only accept traffic
from instances that are using the s3 gateway endpoint. So let's just recap the differences
with the interface endpoint. You've got an elastic network interface with a private IP with a gateway
endpoint, you have a target in your route table for the gateway. So interface endpoints, we
use DNS entries to redirect traffic, whereas gateway endpoints use the prefix list in the route
table to redirect traffic. Now what services Well, there's quite a few with an interface endpoint API
gateway cloudformation. And cloud watch are just a few examples. Lots of the public services can be
accessed via an interface endpoint. But a gateway endpoint is restricted to Amazon s3 and dynamodb.
Only with an interface endpoint, you use security groups to control traffic, whereas with a gateway
endpoint, you can use VPC endpoint policies. Now lastly, let's look at how we can
use this in a service provider model. So what I mean is we have a consumer VPC and a
service provided VPC. So we've got a couple of subnets in each VPC. And what's happening is the
service provider is creating a service. And that service is behind a network load balancer. And
they want to provide that service to consumers. So what happens as a consumer is you provision
an endpoint, and then you use that endpoint to access the service. So we're actually publishing
a service in one side, and then we're consuming it in the VPC on the left, and using an interface
endpoint to actually consume that service. So that's how it works. And in the next lesson,
we're going to set up a gateway endpoint. Welcome to a nother hands on In this lesson,
we're going to create a VPC endpoint, it's going to be a gateway endpoint.
And we're going to use some policies to see how we can control access to an Amazon s3
buckets. So this is basically the configuration we already have a VPC and a public subnet, and we've
got an instance running in it from earlier on. Now we're going to create an Amazon s3 bucket.
I'm getting ahead of myself a little bit here, because we actually cover s3 in a lot of detail in
the next section. If you're completely unfamiliar with it, and you want to get a primer, you could
flick forward, but we won't be doing too much here, it's gonna be fairly straightforward
stuff. Now when we create our endpoint, a route will be added to our route table. And that
will point to a destination which will resolve to the IP addresses of Amazon s3. Now what happens
is, this is a more specific route than any other route, like the route going out to the internet.
So it should follow this path, which means any connections that go to the AWS s3 endpoints
should be routed via the gateway endpoint, and we'll be able to prove that that's happening,
and that we're not using the public Internet. So we will modify the policy here to do that,
you'll see what I mean shortly. And on the s3 bucket, we'll add a policy. Now bucket policies
are basically just resource based policies. It uses JSON language, just like we do with Iam
policies, but we just use them to control access to our buckets. So we apply them directly
to the bucket, rather than to a principle like an identity based policy. The first thing to
do is to head over and create the VPC endpoint. I'm in my management account in North Virginia. On
the left here, under endpoints, we can create an endpoint. Let's click this button Create endpoint.
And under services, if we put in s3 and search, we get these options, we're going
to choose gateway for Amazon s3. Now we need to specify which route table to
actually update. Now as you can see the route table for our VPC, the custom one is not there.
That's because we need to make sure we specify our custom VPC. Now we can see our route tables.
And I'm going to choose the one that's the main route table. So that's the one associated
with my public subnets. Now the policy by default is full access. So we have a statement
here, that's action, any action star effects allow, and then any resource and any principal.
So it's very open, but you can customize that. So let's just create the endpoint, and it's being
created for us. So here is our endpoint. Now what we want to do is go to route tables and just make
sure that the route table has been updated. So that's this one here, the main route table for
our custom VPC. Under routes, we can now see that we have the destination, and this is going
viral and VPC endpoints. So that's the route to Amazon s3 going via the endpoint. So that's
set up correctly. Another thing we need to do, we're going to run commands against Amazon s3
from our EC two instance. So I need to give it some privileges, I'm going to create a role. So
let's choose Create role here in the Iam service. common use cases is going to be easy to so we're
going to allow EC to to call an AWS service for permissions, just type in s3 and search. And
we're going to give full access. I'm going to copy the name of this policy. And we're going
to use that for the role name as well. So let's just paste that in, create the role.
And now we have a roll that we can assign to our EC two instance. So over in EC two, let's choose
our instance, go to actions, security, modify Iam role, and we're going to choose a role and we
should see it in here. And there it is Amazon s3, full access. So let's save an instance now has the
privileges it needs. Over in the Amazon s3 console which you can find under services and storage,
we're going to create an s3 bucket. So a bucket is just a container into which we add objects objects
or files and videos or whatever you want to add. I'm gonna call mine DCT VPC test, and
it's going to be in North Virginia, I can scroll down, don't need to change anything
else at this point and create this bucket. So now that we have a bucket, we can
add some objects objects, as I say, are just files. This is an object based storage
system. So we can come in and add files, I'm just going to add a couple of JPEG images and
upload. So simple as that we have some files on Amazon s3. Now let's come back to easy to choose
our public one a instance, go to instance connect and connect. Now we haven't specified any policies
yet, but let's just check that we can connect to Amazon s3. So now we should be able to run
commands against s3. Let's try running AWS s3 Ls and hit Enter. And we can see our
buckets, we should be able to run AWS s3 Ls and then s3 colon slash slash and our
bucket name as well. And if we hit enter here, we should see the contents of the bucket. So
at the moment, everything is working great. Now how do we know this is going over the
endpoint rather than going over the internet because we are in a public subnet? Well, let's go
back to our endpoint. With my endpoints selected, I'm going to choose policy. I'm going to copy this
code here in the endpoint policy, choose Custom paste it in. And let's just change the policy
to deny. So this should deny everything. Now if we're going by the internet, this shouldn't
make any difference. But if we're going via the endpoint, then this should block access. So back
in our instance, let's try and rerun that command and we get an Access denied. Let's try and run
the ls command. Again, we get an Access denied. So it's definitely not working back in my
endpoint. I'm just going to change this back again, because I don't really want that to deny
me from access at this point. So let's just go back to full access, click on Save. The next thing
we're going to do is set up our bucket policy. And the bucket policy is going to prevent any access
except from the VPC endpoint. And that's something that comes up in a lot of exam scenarios. So
let's go into our bucket here. Go to permissions. Come down to bucket policy, click Edit, and
I'm going to copy the bucket AR n. Now this is the bucket policy. So it's in your code Amazon
VPC directory bucket policy VPC, what you need to do is take this whole AR n here and just paste
your correct AR n over the top for your bucket. And there's two options here. One is without the
slash star, and one is with. So the one with a slash star means that you can also look at the
objects within the bucket. Now the last thing we need here is the VPC ID. So back at my endpoint
here, I'm going to copy the endpoint ID and then come back and paste that into my policy. So that's
it, this policy should now apply. Now what does it do? Let's have a look. The policy is a deny. So
it's going to deny any principle any s free action on these resources specifically, if the condition
does not equal, this VPC endpoint ID so in other words, if you're not coming from this VPC endpoint
ID you're going to get denied. If you are coming from this VPC The endpoint ID, it doesn't apply.
So let's copy all of this code to our clipboard. And back in the bucket policy editor
here, I'm going to paste it all in and just save these changes. So let's go
back and make sure we haven't broken access. Back in our instance, let's try them to run
the AWS s3 ls command, and we see our buckets, let's check that we can see inside our bucket and
that works correctly. That's good because this instance is coming from the VPC endpoint. So
again, we've proven we're coming via the endpoint. But the other thing we can do is check from
our own computers. And we shouldn't be allowed access. So back in a terminal here, I'm going to
run AWS s3 Ls. And I do see the buckets. But what about if I try to see inside the bucket, so the
full command is AWS s3 lS s3 colon, slash slash, and then your bucket name and hit enter. So
I've got an access is denied. So that proves that I'm not able to access the bucket from my
computer because I'm not coming via the endpoint. Now let's just go back to the console and have a
look at the bucket in the bucket here, you can see that we no longer have permissions to this bucket,
we've actually locked ourselves out because I'm actually coming through the console here,
and the console doesn't come by the end point. So what we need to do is
go back to our 82 instance. Now that is it for this lesson, we have
finished with the easy to instance, and the VPC endpoint with the endpoint, you
can simply select the endpoint, go to actions, and then delete endpoint. And that should
clean up the entry in your route table as well. But you can always just go and check, you
might need to refresh the page. And then it has gone. So once you've done that terminate
your instance. And we've finished for this lesson. Hi, guys, welcome to this lesson. This lesson is
about the AWS client VPN. So it is exactly what it sounds like. This is a way that you can connect
your client computer to the AWS data center to a VPC via a VPN connection. So a virtual private
network connection. So let's say you've got a computer which is Windows or Mac or Linux, you're
able to set up a client connection from there into a VPC. And that means you're then able
to communicate with resources in that VPC. So you might be able to connect to an EC two
instance, directly using private IP addresses. Now, of course, it's a virtual private network. So
that does mean that it's encrypted as well end to end. So let's look at how you set them up. So here
we have a region. in that region, we have a VPC, we have a couple of subnets. Now we create a VPN
endpoints. And the VPN endpoint is associated with subnets. So the client VPN network
interfaces are created in the subnet. And that is the method by which the VPN connection
is then able to communicate with resources in the subnets. Because there is an association between
this network adapter that's provisioned into the subnet, and the VPN endpoint, we then have the
client computer, and that's going to be running some VPN software. The VPN software is not
AWS software. So you need to choose one of the available options. There's lots of free options
in the hands on in the next lesson, we're going to use open VPN, the client software will establish a
connection with the VPN endpoint over SSL TLS. So Port 443, and that's going to be via the internet,
the VPN endpoint will actually perform source network address translation from the cider
block that's associated with the VPN client to the cider block that's associated
with the VPC. And on the client side, if you look in your route table, you can run
a command on Windows, which is route print, and you would then see your route table and you'd
be able to see that you have a destination for the cider block of the VPC and a gateway, which
is pointing at the VPN endpoint. So that's the theory behind how our client VPN works. Again,
this is an encrypted connection over the internet from your computer. So your computer is then
able to communicate using private IP addresses over to your instances in your subnets within your
VPC. So that's how it all works. And in the next lesson, we're going to set this up using a Windows
client on Amazon workspaces and a VPN endpoint. Guys The other type of VPN that we can establish
in AWS is a site to site VPN. So a site to site VPN is where you might connect for instance, a
customer data center or office location into AWS And have a private network established over the
internet. So an encrypted connection, which you can then tunnel through your traffic, and again,
use internal IP addresses private IP addresses. So the setup looks something like this. We've got
an AWS VPC on the left. And then on the right hand side, we've got a corporate data center,
that could be a data center or an office, and you want to connect that into AWS. So AWS
VPN is a managed IPsec VPN. And what we do is we create something called a virtual private gateway,
which is also known as VG W. On the AWS side, the VG W is deployed on the AWS and then a
customer gateway is deployed. On the customer side, when you have those two components, you
can then establish a encrypted VPN connection over the internet. The VPN connection supports
either static routes, or BGP peering and routing. So in our route tables, we can actually
specify a destination for the cider block of the corporate data center, and then point it to
a Virtual Gateway ID. So that's this device here. So that means any traffic going to this IP
range will be sent over the VPN connection. So it's fairly straightforward. And the most
common use case for this is what we see here, it's connecting in data centers, or office
locations, to AWS, so that you can then tunnel your traffic over an encrypted connection using
the internet. It can also be used sometimes as a backup connection for Direct Connect. And we'll
look at that later on in this section. That's all the theory I wanted to cover for now. And what
we'll do in the next lesson is it's going to be practical, we're going to do a hands on lab
where we're going to set up a VPN connection. AWS VPN cloud hub is not actually a service that
you can go and find in the AWS console. What this really is, is a pattern and architectural pattern
that you can use when you utilize the AWS site to site VPN technology. So let's have a look at the
architecture in which you can implement cloud hub. So we've got a VPC. And we've implemented a
virtual private gateway a VG W. And that's obviously deployed on the AWS side. We then
have multiple customer offices, or these could be customer data centers. But they're different
on premises environments that we want to connect using a virtual private network to AWS. Now, the
way that we connect them in a cloud hub topology, is using a hub and spoke model. So in
other words, AWS is the hub, the VPC. And then the spokes go out to each of these
offices. So what we do is we deploy a customer gateway into each of these offices. Each of
these customer gateways has a unique BGP ASN, that's a Border Gateway Protocol autonomous system
number. So BGP is a protocol that you can use for advertising routes to different parts of your
network. And each environment has its own ASN. And that corresponds with the routes that would be
advertised into the network, so the IP prefixes, so you must have a unique BGP ASN for each
office. And then we can establish a VPN connection between each of those customer gateways and
the same Virtual Gateway on the AWS side. Now network traffic can originate from an office
and go to the VPC or the VPC back to an office. But also, it can go between the customer offices
or the customer on premises environments, whether their offices or data centers. So the
customer office here can communicate via the VG W. So this custom office here. So we're using the AWS
site to site VPN to establish a routing topology, which connects multiple customer offices, as well
as the VPC itself. Now, this is using IPsec VPN, the same VPN, as we just looked at in previous
lessons. So that's it. That's VPN cloud hub. As I mentioned, if you go around looking in the
AWS console, you won't find cloud hub. But if you actually do a search online, you'll find some
articles about this architecture, which can give you a bit more insight as to how it's set up. But
basically, we're just connecting multiple customer gateways to a single virtual private gateway.
And then it's up to you to configure your BGP protocol accordingly to advertise the
routes that you want to advertise into the network. So that's it for a quick overview
of cloud hub. I'll see you in the next lesson. We've already talked about virtual private network
connections VPN. Now VPN is typically run over the public Internet That means that we are subject
to the bandwidth constraints and the potential latency issues on the internet, we can't control
the internet, we don't know from minute to minute hour to hour, what's going to happen, we can get
a good service provider. But still, sometimes there's a long way between us and our services
on AWS. And that means somewhere along that path, we could have congestion or latency. So one of the
solutions to that is using direct connect or dx dx means that you have a private connection into
AWS, that means it's not shared, it's not public, it's dedicated to you, it's a connection all
the way into your AWS data center and into your Amazon VPC. So let's have a look at how
we set this up. So let's say we have a VPC, we have a couple of subnets. And then we've got
our corporate data center, or it could be your office. Now in the middle here is something called
a direct connect location. These are different two AWS regions. And there's lots of these around
the world. So there could well be direct connect locations in the data center where your
equipment is, or somewhere nearby in your city. In the Direct Connect location, AWS have a cage
so they have a rack full of their own equipment. And then there's the customer or partner cage.
So either you have a rack with some equipment in that data center, or you leverage an AWS partner.
Now both of these cages will have a router. So we got the Direct Connect endpoint on the AWS cage.
And then in the customer or partner cage, we have the customer or partner router, and you must use
certain types of connectors, a dx port is actually allocated for you. And then what you do is cross
connects between the customer or partner router, and AWS, we then have a customer router, actually
in your data center, and direct connects in AWS. And we can form the Direct Connect connection. So
now, from your customer router, you need to have a physical connection into the customer or partner
cage. So that might be something you need to speak to your local ISP to get that connection
from this point into your data center unless you happen to have all your equipment in a direct
connect location, which can often be the case. Then from there, we have the cross connects into
AWS and then a physical connection all the way in to an AWS region where your VPC is, that's a
physical fiber connection, running at either one, or 10 gigabits per second. Now, 100 gig has
just been released recently for some locations. If you want slower speeds, you can talk to
a partner, and they can give you speeds from 50 megabits per second upwards. So let's have a
look at some of the benefits. You've got private connectivity between AWS and your data center or
office, you get a consistent network experience, you can control the network path, it's not like
on the internet where you just don't know what's happening. That means you can increase the
speed, improve latency, get better bandwidth and throughput for your connection. dx can
be quite expensive for many customers. But for those who transfer a lot of data from their
data center into AWS, it can be cost effective. Now let's go a level deeper. So we've got the
same configuration here. And you can see some of the AWS services that are in the public space at
the bottom of this box set. So how do we provision connectivity across this private line? Well, we
have to create something called a private viff. A Vf is a virtual interface. A private
viff is the way that you connect into your VPC in the same region using a Virtual
Gateway. So there's a virtual private gateway attached your VPC and the private viff will
send data across the DX connection into your VPC is a virtual interface that uses 802 point
one Q, virtual local area networks VLANs and a BGP session as well. Now what
about connecting to the public space, you don't connect to the public AWS services via
a private viff. Instead, you need a public fifth, our public This will allow you to connect to
AWS services in the public space that are in any AWS region. But you can't connect to the
internet via the public fifth. Now what if you want to connect to multiple v PCs in the same
region, when in that case, you have multiple virtual private gateways and multiple private
this to connect to each VPC You can also create something called a hosted Vf, which means you
can share a Vf with another AWS account as well. As I mentioned a bit earlier, you can get lower
speeds from APN partners. So these are partners in the AWS partner network. And those speeds can
then be from 50 to 500 megabits per second 100 gig is also featuring in some select locations,
those are the AWS Direct Connect locations. So that could be where you are might not be probably
won't be on the exam, yet, it's very, very new. Something that is really important for the exam is
to remember that dx connections are not encrypted, you cannot encrypt a dx connection. So there's
no way that you can select a checkbox and enable encryption in transit. It just isn't a feature.
So what do you do if you want to encrypt your traffic? Well, you can then create an IPsec site
to site VPN over the top of the connection. So you have your dx connection, and you're basically
running a VPN over that connection. So now your traffic is private, it's on your private
DNS connection, you've got the latency and bandwidth features. And you're also encrypting
your traffic as well using a VPN tunnel. So that's really important to remember, it
does come up in a lot of exam questions. Now that's it for the core
theory around Direct Connect. And in the next lesson, we're going to look at
another feature called direct connect gateway. Welcome to this lesson. In this lesson, I'm
going to cover AWS Direct Connect gateway. Now the best way to understand the benefits
of direct connect gateway is to have a look at an architecture where we don't use it and how
complex it can get. And then we're going to look at when we use direct connect gateway and
how it can solve some problems. So here's an example architecture where we're not using direct
connect gateway. Now we have multiple regions, and we have an office. And we have multiple
dx locations in different parts of the world. And what we're doing is we're connecting each of
those regions to a dx location that's close to that region and then into a corporate office. And
we're doing the same in the EU central one region at the bottom here, as we are in US West one. So
this company now has multiple locations, where they then have connections into AWS using dx, then
must establish a private viff. And that connects to a single VPC in the same region using a Virtual
Gateway, we do the same in the second region. Now dx is a regional service. So obviously multiple
DNS locations have to be used for this topology, and also requires at regional offices, or long
distance, expensive links. So in other words, these customer routers here have to either be
in one low physical location, one geographic location, and you've got a very long distance
link coming from Europe, or the US, or these are multiple offices in different geographical areas.
So when we want to start connecting our offices to multiple regions, using direct connects, it can
become quite expensive, and quite complex. So now let's look at an architecture where we use direct
connect gateway. So in this case, we have the same two regions, we have a single corporate office
and a single dx location. And so we now only have that connection into our office from one location.
And we have a dx gateway. And then the DX gateway is actually connecting to multiple regions, a
private Vf is associated with the DX gateway. And then the DX gateway is associated with a
Virtual Gateway. In each of the regions, BGP advertises around to all v PCs via the DX gateway.
And the traffic that's going from the DX gateway to these different regions is going over the AWS
backbone, so it's using that consistent network experience of the AWS global network. Now network
traffic can go from the office to either region, so any of the VPC is connected. And of course,
I'm only showing two here. But you can have many, many regions that are connected to a dx gateway.
Now, what you can't do is actually route regional traffic from one region to another via the DX
gateway, it doesn't support that. But you can use it to connect from your corporate office using a
single dx connection into multiple regions around the world. So that's the x gateway. It's a really
useful technology if you're a global company, but you don't have global offices or you want a
single office location to have this consistent network experience into multiple regions around
the world and this is a great technology to use AWS transit gateway is a really awesome service.
It's described by AWS as being a Cloud Router, and it connects v PCs and on premises locations
together using a central hub. So let's have a look at what this means. Now again, what
I want to do is show you a fully meshed architecture without AWS transit gateway to help
you understand the problem we're trying to solve, because when we have lots of VP C's, and on
premises locations, it can get really complex, the peering connections that we set up if we use
VPC peering can become extremely complex. So let's say we have VPC A, B, C, and D again,
and we've established our VPC peering links. And as you know, there's going to be
quite a few peering links here, we've got six peering links that we've got to set up
just for for V PCs. And as you increase the number of VP C's, it gets very complex. So here
we have six VPC peering connections, we then have a corporate office connected via a customer
gateway. So how do we connect the corporate office using a site to site VPN to each of these v
PCs? Well, we need a Virtual Gateway in each VPC, then we need to establish a connection
to the customer gateway from each VPC. And each of those is its own encrypted IPsec VPN.
So there's for site to site VPN connections. And that's not even including redundancy. If you
wanted to add redundancy, you'd need another customer gateway, and double the amount of sts VPN
connections. So it starts getting super complex. Let's now look at the same architecture. But with
transit gateway. In this case, the same for V PCs and a corporate office, we stick transit
gateway in the middle, and it becomes the network transit hub that interconnects the V
PCs and on premises networks. So now we have connections into each of these v PCs, the V
PCs become attached to the transit gateway. And you specify one subnet from each availability
zone, and that enables routing within that availability zone for any other subnets. We then
have the customer data center, we've got the corporate office here with a customer gateway,
and the customer gateway connects in. And that's it. This is now a service, which is allowing us to
connect through this Cloud Router, the central hub to any of these v PCs, tgw. W's can be attached
to VPNs, Direct Connect gateways, third party appliances, and also transit gateways in other
regions and also other accounts. So let's have a look at how it works with the x gateway. So in
this case, rather than using a site to site VPN, our corporate office has a customer router,
and we're connecting into a dx location, and we're using a dx gateway. So now the DX
gateway has a connection to transit gateway. And that's called an association. We then have the
physical connection back to the corporate office from direct connect, and we create something
called a transit van. So this is another type of virtual interface specifically used for Direct
Connect gateways, when are associated to a transit gateway. So transit Vf is only used when you're
attaching a dx gateway to a transit gateway. Now this architecture then supports for
transitive routing between on premises, the transit gateway and all of those
connected v PCs. As you can imagine, when your company gets bigger and starts using
more VP C's in more regions, and you want to have that transitive pairing between them, it
can get so complex, that transit gateway will really solve a lot of challenges. So that's it
for this lesson. I'll see you in the next lesson. Hello, and welcome to this lesson. I'm now going
to talk about using the ipv6 protocol in an Amazon VPC. So remember, I mentioned earlier in the
course that there's two versions of IP, which are used extensively. One of them is ipv4, that's
by far the most commonly used, it's been around for quite a long time. And then there's ipv6. Now,
ipv6 has also been around quite a few years, but it's not being used anywhere near as extensively.
But that needs to change over time because we are running short of ipv4 addresses. So we're going
to have a look at how you can use ipv6 in a V PC. So let's start by looking at the structure of
the IP v4 address. So remember, it's made up of four numbers separated by dots. And those numbers
come from an octet. So that's eight binary bits, which are either one or zero. So an ipv4 address
is 32 bits long. Now let's have a look at how many addresses you get for that you get 4.3 billion
addresses, which sounds like a big number. And it's a big number of its dollars in your bank
account. But when it's addresses that needs to be assigned to all sorts of different devices all
over the world, in a world full of 7 billion people, it's just not anywhere near enough. And
it might have sounded like more than enough, quite a few years ago, but it was became apparent,
even in the 90s, that it was not going to suffice, and it hasn't. So we are close to exhausting these
addresses. And Nat has to be used extensively. So if you're in a company, and your company has 1000s
of computers internally, then those computers will most likely be using ipv4 addresses. And those
will be private addresses. And when they access the internet, they go for a NAT device or some
sort. And that means that a public IP address is used to represent many, many PCs. So that's a
workaround that we have to put in place with ipv4. With ipv6, we don't have to worry about that. So
let's look at the structure of an ipv6 address. So this is the structure of ipv6. It also has
a network part and a node part. But it's 128 bits long. So it's a much, much bigger number.
But also it uses hexadecimal. Whereas ipv4 uses dotted decimal. So that means there's a lot more
potential values that you can use in hexadecimal versus decimal. So that means the amount of
addresses is much, much bigger. And this is the number that's the number of addresses you can
get out of ipv6. And it's absolutely huge. So put it into some kind of perspective. And by the way,
if you look on Google for analogies for the size of the ipv6 address base, there's all sorts of
fantastic analogies, because it really is massive. So one that I like is that you can get 100 ipv6
addresses for every atom on Earth. So that is a huge, huge number, which means we never ever have
to worry about running out of ipv6 addresses. So let's have a look at how we need to set up our
VPC. So we've got a VPC with a couple of subnets, we need to have an ipv4 cider block. And then we
need the individual subnet ranges for our subnets. Now, we also need an ipv6 cider block now, so
we've allocated one to this account. Now, AWS will assign a slash 56 ipv6 address range to the VPC,
then you can create your subnet ranges within that address space. And those become slash 64 subnets.
Now, a slash 64 subnet will allow 18 million trillion addresses. So again, it's an example of
why you really don't need to worry about how many addresses you're going to have for your computers,
because it's just huge. Now, you'll notice there's two numbers highlighted in red at the end of the
IP address. This is a hexadecimal pair, which has values from 00 to FF. And this designates the
individual subnet. So it has to be unique for each subnet. And it means that you're going to
have a possible 256 subnets, with ipv6 blocks in them. And each of those is a slash 64. So each of
those will support 18 million trillion addresses. So lots of flexibility for your VPC. Now let's
look at the route table once we've enabled ipv6, so we now have a local route for the ipv6 cider
block. And we need a route to the internet gateway for everything that's outside of that
range, just like we did for ipv4, we have the colon colon slash zero for ipv6, pointing at the
Internet gateways ID. And that means that anything that's not an ipv6 address in this range will go
to the internet gateway. So we'll make sure that we have that specified in our route table when we
enable ipv6. Now all ipv6 addresses are publicly routable. That means there's no network address
translation. Now, if you want to, you can use something called an egress only internet gateway.
Now the purpose of this is when you want to allow outbound access only using ipv6. So it's kind of
like having a EC two instance in a private subnet with ipv4 and then adding a NAT gateway into a
public subnet. It means that that instance is protected from the internet, no one can access
it directly from the internet, but it does have internet access outbound. So that's what an egress
only internet gateway does. So that's it for the ferry on this topic, and in the next lesson,
we're going to go in and enable ipv6 for our VPC. Hi, guys, in this lesson you're going to learn
about VPC flow logs And then we're also going to set a flow log up to see how it works and
what data actually captures. So VPC flow logs capture information about the IP traffic
going to and from network interfaces. In a VPC, the data is stored using cloud watch, or Amazon
s3. And you can create the flow log at different levels. So at the VPC level, at the subnet
level, or at the interface level, service at the interface level, it's associated with the
ENI, that's attached to an EC two instance, you can capture a lot of traffic, which is really
useful for troubleshooting purposes and security as well. So let's go and create a flow log in
easy to I still have an instance running, if you don't have an instance running, just launch an
instance, just as we have done before, and put it into your public one, a subnet, and it should have
a public IP address. Next, we're going to actually send our data to cloudwatch logs. So in the cloud
watch service, I'm going to go to log groups, create log group, and create myself a log group,
I'm going to call it my subnet logs, I can set a retention setting. For me, let's put five days so
after five days, I don't need that data anymore. And let's create the log group. Next, we need to
create a role. So the flow log service has the permissions it needs in the identity and access
management service, we're going to create a role. So let's create a role. choose Create role, we're
going to choose easy to for now we're going to modify that soon, because that's not actually the
service that's going to be assuming this role, we're going to go straight past policies,
because we're going to add an inline policy. And I'm going to call my role flow logs
cloud watch, I'm gonna remove the description and create this role. Now let's find the
role. And under permissions, we're going to add an inline policy, we're going to go to JSON.
And we have this JSON code here in your code, Amazon VPC directory. And it's VPC flow logs dot
JSON. So all we need to do is copy all of this. As you can see, the service is going to be provided
with the permissions to create a log group, create a log stream, but log events, describe log groups
and describe log streams. So with that copied, let's come back, override all that code, click
on review, give it a name, I'll just call it cloud watch permissions and create the policy.
Now we do need to edit the trust relationship is not actually easy to that's going to assume this
role. So coming back here, the trust policy can be replaced, we can literally just copy this piece
of text here. And we're going to paste it over where it says EC to dot Amazon aws.com. So now the
service that is able to assume this role is VPC flow logs. Let's update that trust policy. That's
it, we're now ready to go and create our flow log. Back in easy two, I've only got one instance
running. So it's going to be easy to identify the network interface, we're going to create the flow
log here at the network interface level. So flick over to flow logs, create flow log, I'll just call
it my flow log. Let's put it for all traffic, and a one minute aggregation. So we get some data
nice and fast. we'll delete it afterwards when we terminate our instance anyway. And we're
going to send a cloud watch logs. So we've got our log group. And let's find our role, which is
starts with flow. So it's flow logs cloud watch. And we're going to leave the default format, and
then just create that flow log. So now let's try a couple of things. We want to send some successful
connections. So let's copy our public IP, go to a new window here and put that in. And we've now
generated some HTTP traffic. I might refresh that a couple of times. And what about sending some
traffic, which we're going to get rejected on that's another thing that we could do. So let's
come back to instances, check out what security group this instance is in. And it's actually got
two. So let's go to the public web one, because I think that's the one that's got some rules
which allow certain protocols from the internet. And yes, we can see the SSH and HTTP rules are
in there. So let's go and edit the inbound rules. And I'm just going to temporarily delete my SSH
rule and save. Now from a command line, I'm simply going to try without any arguments to SSH to that
instance. And that shouldn't work, it should just keep failing because we don't have the security
rules to allow this. So that's basically it just generating a bit of traffic. So what we can do now
is go to cloud watch logs, and see if some data is starting to be sent there. Back in cloud.
Watch logs, I'm going to select my log group. And let's see if we've got a stream. And I
do have a stream that's nice and fast. Now, don't worry if it's not there yet, you might
have to wait a few minutes, and it will turn up. So let's select my log stream and see what data
we have in here. And you can see there's a few entries here, we can see some rejects. And
associated with those is various information, including the elastic network interface,
the source and destination IP addresses, we've got port numbers, we've got protocol
numbers, we've got various bits of information in there that could be useful in whatever
analysis you're doing. If you want to refresh, you can click on resume, and then you should
see some more data coming in over time. So there we go, we've got quite a few more rejects
coming in as well. And just a couple of minutes later, I've refreshed my screen. And we can see
some accepts as well. So there's quite a few, we can see the port number here, Port 80. So those
are successful connections go into our web server. So that's it. There's lots of data there
that you can use for various analysis. And it's really useful to understand the different
types of logs, we've got an AWS, what data is included in them so you know which ones to
use for your troubleshooting or your analysis. So that's it for this lesson. And we have
finished with our EC two instance now, so we can go ahead and delete it. Once you've
terminated your instance, you're all cleaned up
