Transcript
This transcript was autogenerated. To make changes, submit a PR.
Hello everyone, thanks for joining the session.
AWS AWS AWS Networking simplified a
comprehensive tour key features my goal today is
of course to cover some of the key components on networking.
Because time is limited, I won't be able to cover all the
network components, but I will try to focus on the core
networking component. So just to set expectation for
the talk today, we are not going to go in depth into application
architecture. We're mostly going to be talking about how can you
understand some of the core networking fundamentals and some
of the features that you can use for your organization or your
personal use. To use the best of AWS. So quick
Introduction my name is Samuel Barufi. I am a senior solutions
architect here with AWS and I focus on supporting
global financial services customers on their cloud journey.
So without further ado, let's get started.
Quick agenda. We're going to quickly talk about global infrastructure
on AWS, some of the components, then we're going
to dive deep into VPC. We're going to talk about VPC
security. After that you're going to actually go to the meat
of the presentation talking about empowering endpoints,
gateways and global connectivity. What are the things you can
use to really extend the capabilities of your AWS
network and also potentially into
your hybrid cloud? And to finalize, we're going to talk
about a new service that was introduced last year,
which is very exciting to simplify service to service connectivity.
This is the one that will talk most about application connectivity
and we're going to end the presentation talking about some of the tools
that can help you operationalize your network, such as how
can you have visibility into tour traffic and how can you monitor your traffic.
So let's quickly talk about global infrastructure on AWS.
So the global infrastructure on AWS is a forever growing
footprint as of today, and this is very important.
This might change in a couple of days, weeks and months.
We have launch and available for you as a
customer to consume 32 different regions across
the globe. AWS you can see on this screen with a total of
102 availability zones and more than 450
points of presence for cloudfront distribution. The latest
region that was made available a couple weeks ago was
Israel. So how does
AWS backbone infrastructure treats fault
tolerance? So it's really important to understand that all regions
are compromised of multiple availability zones for high
availability and scalability. So if you look on this
slide, you have a region within a region, you have
multiple availability zones that are interconnected.
So each region has two independent, fully redundant
transit centers. So that's where the traffic goes.
The transit center connects your region and the AZ
that the region are part of to the bigger AWS
ecosystem network. And each availability zone is highly redundant,
connected to each other within the region. And then
within each availability zone you might have one or more data centers
that has independent power, networking and connectivity capacity.
The data center this is a completely abstract scenario,
but this is just to paint the picture on how, when you actually get
to the real data center, how we are abstracting that for
you as a customer. So now that
we know about the regions, the global infrastructure,
let's talk about the first component, which is Amazon
Virtual private cloud, also known as VPC.
So when you're building a VPC, VPC is the original construct.
So you go to a region, in this example, go to region us east one,
and then you create a VPC. VPC stands for virtual private cloud.
It's your own private cloud. Nobody else has access other than
you and your account within the VPC you
are actually going to be, because VPC is a regional construct,
you are going to choose different availability zones that your VPC are
going to be spanning across. So in this case, just for demonstration,
there are two availability zones, and you see that each availability zone,
we have a specific id for your account.
Then once you have the vpcs and you have the
specific availability zones, you can create subnets within
those availability zones and you can have public subnets
and private subnets. Public subnets means you can actually have
connectivity, both ingress and egress to
the outside world. Private subnets means likely
you are not going to have access to inbound connectivity from
the Internet. So if you have a database, you might want to put that
there. Once you deploy a specific
resource, like in this picture on the public subnet, of course
that resource. Let's talk about EC two. Elastic cloud
compute, which is the virtual machine instance that you have on the cloud,
is actually going to be hosted on a specific data center, on a specific rack
on a specific host. But that is completely abstract
from you, so you don't need to worry about it. You just know that that
EC two is now running on a specific subnet and that subnet is
part of a specific availability zone. And then of course you're
going to have an elastic network interface that connects the EC two
to the network on the subnet and on the VPC.
Now when we talk about an important aspect of networking,
which is IP addressing, let's start with IPV four. How does
that work? So I'm going back to the scenario, or you have a VPC with
two availability zones and two public subnets and two private
subnets. The first thing you need to do is associated
a cider rank. So an IP address block to the VPC.
This case 100 zero is like 16.
Now you go and you slice that big subnet from
the VPC and you decide smaller subnets that
are part of that big VPC subnet into
your small subnet. So public subnet you're
going to have a slash 24 and then the private subnet you're going to have
a slash 24. If you're not familiar with subnets
on IP addresses, the slash after that just
mean the amount of bits that you're going to have available to actually consume
within the subnet. So every single cider
block that you see on the subnets are part of the bigger VPC
cider block. Then when you create
specific resources, in this case demonstrating
on the public subnet, on both public subnets you're
going to have a resource and you're going to have what we call EnI elastic
network interface. That Eni will get an IP
that is part of that specific subnet. So in the first example
on the left, 100 138 is the IP address that
your ECQ has been received. And on the other side 100
200, you can have multiple IP address
in an ENI. And there is some limits that we're not going to talk today,
but you can also have two different enis on an ECQ and they can have
different private IP address. So software we are talking
about private IP address. Another aspect that
is important is vpcs can have secondary cider
blocks. So in this case, let's say we have consumed
most of the first cider block. Because VPC cider
blocks, the primary cider blocks cannot be changed.
You can only add new, so you can have secondary cider
blocks into your VPC. So we've added a new one. And when
you look here, it's interesting to know that when you create subnets
you have IP addresses that are reserved. So the way it
works is the first IP address is also going
to be the network address. So we're not going to be able to use the
first zero network address. The second one will always
be your gateway, the VPC router gateway.
The two and three are reserved. Maybe AWS
will use that for other capabilities in the future. So AWs
reserves that it cannot be consumed by your resources. And the
two five five is always the network broadcast. And it doesn't
matter. Each subnet will follow the same aspect because each
subnet requires these five IP address to be reserved,
and each one will have a specific purpose. Now,
when we talked about public IP address, you can
have public IP address associated, and when I mean public IP
address, I'm talking about IP addresses that are routable on
the Internet different than the IP address we've talked so far. So we
see here on this slide, you have an IP address that have been associated to
an EC two. You can also have elastic
IP addresses where you can reserve a specific IP address
for your account, and the difference is on the public subnet
on the left side. If you're just requesting an IP address on
your instance, but you don't have an elastic IP address association,
it just means that if the instance is terminated,
you are not guaranteed to keep the same IP address.
If you create another instance or you restart that instance,
maybe the IP address might change. But if you have an elastic
IP address, that IP address is reserved for your account and
you can always associate to a specific EC two instance
or change in the future. So highly recommend that we use elastic
IP address. And like I said here,
you can just move okay, I want the IP address this time to be on
this interface. If in the future you want that to be associated to
another elastic network interface, you can definitely do it.
So now let's talk about I-P-V six addressing. So as
we know, I-P-V four s, especially public ipv
four s are very limited, and I-P-V six have been kind
of comes in to provide that solution for
the limit amount of ips we have available. So AWS
is highly supported and provides a lot of recommendations
for customers. To use ipv six, you can run I-P-V
six and I-P-V four s at the same time, also known as global.
So in this scenario we're just going to look how you can add ipv six
into this architecture. So you can go on
your VPC and associated an ipv
six block, which is a 56.
Because now instead of only having 32 bits for your subnet as
I-P-V four have, you have 128. And instead
of just being numeric, it's actually hexadeximal.
So you have many many more IP address. So associate to
your VPC, you'll then associate it to the subnet,
you do these lights again to the subnet,
and then what you can actually do, you can see that some
subnets can only have ipv four address,
some subnets might have both. In this case, you want a
private subnet to actually have an ipv six address,
but the other subnet to not have there might be use cases why
you want to do that. Then when you create an instance you can actually,
if you see here on the left side, the instance can also
receive an ipv six
address that is local to tour subnet and
the same reserved IP addresses that we talked on
I-P-V four are also valid for ipv six. You can
see here the demonstration that will be reserved from
the specific 32 will be reserved.
64 is the VPC router and you can see the example on
the right here.
So continuing here, how does intravpc routing works?
So within the VPC itself, right,
intravPC means just within that single VPC. In this
case, every time you add a specific
subnet to your VPC, by default the route
table that you're going to be associated, that is showing here on the screen is
going to create a local target, meaning it doesn't need to route any traffic,
it's already know because it's within the VPC and
you're going to point all those subnets into this routing table.
So if you need to talk from subnet one to private subnet one,
assuming you have specific security permissions to
do that, route wise you are fine.
Network wise you are fine. Now let's talk about some
of the VPC security components, which is important, right? We talked
about the network layer. Let's talk about what the security network
features of VPC are made available.
So by default security groups are attached to resources
like Ectus and it's very important way for you to decide
what it's allowed for inbound and outbound.
So by default the default security groups will always
be that no traffic from outside, no traffic
will be able to come into resource, but always traffic will be
able to go out of the resource. So that is the default group
rule for a security group. When you
want to provide a web server example, let's say you have an EC two
that is part of a subnet and you want to have maybe
internal or external, whatever that may be, you want to provide
access from a specific port. In this case we are
allowing TCP port 80, which is the HTTP port. And when
you see the source, zero zero means
everybody. Unless you know what you're doing, you should always
avoid to do zero zero because everyone,
even if you have a public, especially when you have a public IP address associated
to that security group, it means everyone will have access to that.
So be careful when you do that. But then you
can also have reference other groups in your
security groups. And this is something not a lot of people are familiar, but it's
a very nice way. So here, let's assume you have a EC
two instance that is a web server and you have a database
that EC two instance that is a database. Each EC two has a
different security group. So we have a web server security group and you have a
database security group. Let's assume you want to
give access from the web server EC two to
actually communicate with the database EC
two. Sorry, yeah, exactly. With the database EC two,
what you do here, instead of actually allowing
from everything, and you could potentially just put
the private IP address of the database security group. But then
if the IP address change or if increase more instances,
it's hard to maintain. What you can do is aws the source.
So if you look on the right here where it says database security group inbound
rules, you are saying please allow the port three three
six on the protocol on the TCP protocol from the
source security group web server. So whatever
resources have this security group associated to will
actually have access to talk to your database. So instead
of putting IP addresses, you can put security groups,
references. And this is very, very helpful.
Another example is self referencing rules.
So let's say you have multiple resources,
ecqs that are using the same security group, and you
actually want to give access across these resources for
them to talk to each other. You can actually do a self reference on
the same group and decide what is the inbound port that
is allowed. So in this case, you just put port
80 and every single resource within this
security group will be able to consume port 80 across
this security group resources.
One thing that is important to be aware with security groups,
it means they are stateful. You only need
to open the port that you require access.
You don't need to think about the port that is coming back.
And the reason why I'm talking about that is you also have another aspect
of security on your network that is talked about network
access control, also known as necklace NeCOs.
Instead of actually being associated to a resource like an
EC two, they are associated at a specific subnet
and different than security groups.
Necos network access control lists are stateless,
meaning if you're allowing something to be accessed,
you need to think about the traffic both ways.
So there is something called the thermal ports. So if you're allowing something
to go on port 80, you need to allow the thermal ports to be
outbound as well. Just a small gotcha that I want you
to know. But with knuckles, you can actually have inbound
and outbound rooms similar to the security groups that
are going to be evaluated at the subnet
level. So you can actually both security groups and
network access control lists work at the same
time simultaneously. One is at the resource level and one is at
the subnet level. So be careful when you're using
necklace. You just want to make sure you know what you're doing.
So we talked about VPCs, VPC securities. Let's just
get a little bit more advanced here on peering
endpoints, gateways and global connectivity.
So first we are going to talk about net Gateway and Internet
gateway. What are the differences between them? So going back to
the example where you have a VPC and you have a VPC
with duoistack, so you have ipv four and a pv
six. Every time you want to have any instance
to communicate to the outside, you need to deploy an Internet
gateway. The Internet gateway is just a resource that easily
you create and you associate to a VPC. So in this case we have an
Internet gateway, it's associated to the VPC.
Then you just have a routing table that
says everything that it needs to go, everything that is not specific.
So zero, zero or column column zero for ipv
six, forward that traffic to the Internet gateway. So everything
that needs to go outside will go to the right Internet
gateway route. So in these cases,
because you have IP addresses that are public,
in this case you have ipv six on the left,
private Subnet will go through the Internet gateway.
Now you can also have net gateway and NATS
stands for network address translations. Net are
specific for ipv six, sorry, ipv four,
mostly ipv four. What net does is allows private
subnets that don't have public IP address to
have outbound. So traffic going out,
connectivity to the ward. So if you look here,
this is the configuration we currently have, right?
And you have deployed. Net gateway. So the net gateway you deploy in a public
subnet because the net gateway needs to have a public IP address
to communicate with the Internet gateway. What you
can do is on your private subnet, you can say everything
that needs to go out to the Internet instead of talking
to the Internet gateway because it cannot talk to the Internet gateway because
the resources on the private subnet do not have public IP
address. I want you to forward the traffic to the Nat gateway
and you deploy Nat gateway across subnets into different availability
zones for redundancy reasons.
And once the traffic goes to the NaT gateway, Nat gateway,
because it has a public IP address, will send the traffic to the Internet gateway.
So in this case, the private subnets are only able to go
outbound, connectivity because the private subnets here
on the right don't have a public IP address. They don't have the
ability to actually receive inbound traffic, which is good
because you want to have security. Let's say you have a database,
you don't want the database to have a public IP address.
So another scenario here, another type of Internet gateway,
and this is very specific, it's called the egress only Internet gateway
because on IPV six we are not doing that. And you can
see that on my left, Private subnet,
I have an IPV six address. If I only
want that IPV six to be able to send traffic outbound.
So egress rather than inbound, I can create an egress only
and then I can associate it into this private subnet.
I can associate it a routing table that says if you need to go out,
use the egress only Internet gateway. What this will
do is block the ability of this IPV
six to receive traffic from the Internet. So you can only initiate traffic
to the Internet, but not traffic coming from the Internet to your
IPV six. This is a very recommended way once you
want to have IPV six on your private subnets and
you can just associate it. So in this case the full solution will
kind of be this, right, you have some subnets, in this
case the public subnets will talk directly to the Internet gateway,
but then you have some subnets in case the private subnets that
in the IPV six will talk to the egress only Internet gateway.
And I-P-V four will talk to the net gateway specifically. So you
can use a combination of these tools to achieve the specific use
case you are trying to do. Now, we talked
about peering and then we talked about
net gateways and Internet gateways. Let's talk about peer
with transit gateway endpoints and other types
of empowering. So let's talk first about VPC
empowering. Let's assume you have a scenario, you have two vpcs,
right? And those vpcs need to talk to each other. So you
have maybe resources that are across vpcs and you want to connect
them together. You can use what we call the VPC peering connection. You literally
just choose a specific VPC and the other VPC, you link them
together, always a one to one relationship.
And then on your routing table on both sides you
specify the IPV four or IPV
six and I-P-V six address that is on the other side
and how you can get there. So in this case, if you want to go
from the VPC on the right and you
want to access the VPC on the left. The IPV
four on the VPC on the left is 100, zero is like
16. And how you get there is going through the peering connection.
In this case it's PCX 1234 address.
So very simple. There is no additional cost, only the
data transfer cost that is associated with VPC peering.
Now there is a challenge with VPC peering. Let's assume you
have one, two, three tour, five vpcs
created. And let's assume each VPC needs to be able to talk to each
other. Now you're getting to the sense that because VPC peerings
are one to one relationship and they cannot hop
over, you need to create. So if you have each VPC,
in this case you need to have four empowering connections attached
to it. That becomes really hard when you have a lot of vpcs
and really hard to maintain. And that's why AWS released
a service called Transit Gateway instead of having that complexity
network of multiple peers. What you
can do, you can create a specific AWS transit gateway
on a specific region. So we're talking about a regional construct here.
And then you can create a single attachment for each
VPC. So you have attachment one goes to VPC
one, attachment three goes to VPC three within a single region.
Then you have different routing tables on the AWS transit
gateway saying that, okay, if VPC one wants to
talk to VPC four, the way it's guest to that traffic is
going by attach number four, or if it wants to talk to VPC
five, it goes to attach number five and so forth. So you can
see here where you can have a centralized routing table that
can aggregate everything together and you can exponentially add
more vpcs and it's just going to be an entry
on your routing table and an attachment. You don't need to have multiple
managements of VPC peering, AWS you had with the VPC example
before. Now, the cool thing about transit
is it also supports multiregion, which is very exciting.
So in the example here, let's assume you have,
let's say you have four regions, you have region one, region two,
region three and region four, and you have a couple of vpcs within the
region and you already have maybe transit gateway deployed within
the region. How about if maybe for a multi
region architecture or maybe Dr. Purpose,
the resources across regions needs to talk to each other. It's not
that hard. With transit gateway, you can create transit
gateway peering attachments, so you can have different transit gateways
across the region that are peered with each other. And then in this scenario
and this diagram that I'm showing, you are actually able to consume across
different regions.
So kind of moving into another aspect is
every time you need to consume. So let's say you have, in this example,
you have this EC two that is sitting on the private subnet.
If I need to access services, AWS services
API, let's say I want to talk to a specific kms
key API. The way it works is by default is you are
going to have an Internet gateway in your VPC because this is
a private resource you need, not gateway. And the traffic
will go as follow. We're going to have the routing tables.
The routing tables will tell, okay, if you want to talk to anything in the
Internet, go through not gateway, not where to go through Internet
gateway, then go through the Internet and then talk to
the public API of these services, let's say the public
API of kms. This is okay and this is the default behavior.
The challenge here is you're sending traffic over the Internet even
though these API calls are encrypted in transit,
it's going through the Internet. There are occasions you do not want to
use the Internet. How can you do that? Well, you can
use something called the VPC endpoints. So what
the VPC endpoints is in the same scenario, you have some services here
that you want to consume. In this example here, some list.
Now what you can do, you can create an interface. There are two types.
First, we're going to talk about the interface endpoint. When you create an interface
endpoint, you choose what service that interface is going to
be able to allow consumption for you.
So let's say this is KMs what the interface
endpoint will do. You create a specific elastic network interface
within your subnet and you can associate your interface
endpoint through multiple subnets. And let's
give the example. You want to go to kms again, but you don't want to
use the Internet. You want to use the AWS backbone
connectivity that never touches the Internet. With interface
endpoint, every time you have a resource that wants to talk
to a specific API or a specific resource on
AWS, you go directly. So the error that you see here
is using the AWS backbone connectivity,
you're not going through the Internet. And in this case here, you don't even
need a net gateway or an Internet gateway because let's assume this
EC two does not require Internet connectivity.
It just requires some API services. On AWS
connectivity, like talking to kms or maybe grabbing
a file from S three. You don't need to do that.
So the solution behind the scenes using private link,
which we will talk in a moment, what private link does, but it's pretty much
doing a magic every time you call a AWS API,
there will be a DNS and you automatically resolve the DNS
into a private IP address rather than resolving it to a public
IP address. But there is
a second type of endpoint that is called the VPC gateway
endpoint. The VPC gateway endpoint only supports
two services, s three and DynamDB.
And the main difference is instead of being an interface endpoint,
meaning creating an elastic network interface on your subnet,
it's deployed at a gateway level of your subnet. So if
you need to talk to S three and Dynamo, you actually have a routing table.
The routing table send the traffic direct, your gateway endpoint and then
the gateway endpoint to talk to S three. There are some pros and
cons on using one another. Interface endpoints has vast
support of services, but there is a cost associated gateway endpoints
have just limited two services and there is no cost associated.
So your miles might vary
depending on your use case. So the
cool thing is you can also create specific endpoint
policies. So on your VPC endpoints you can create a policy to
secure what type of connectivity you want to allow.
This is also known as a resource policy, in this
case VPC endpoint policy. It's following
the same JSON policy, AWS tour identity,
IAM policy. In this example I'm restricting
only once I created an endpoint. And with this
specific JSON policy. What I'm saying is this
allows for any actions, any resources, but only
if the role that is trying to invoke
this specific endpoint is the role that is associating
here. But you can have very fine granular details on how
you actually decide this. So it's just hopefully
you can arm your tool set of more things
that you can do to secure your environment.
Now, private link, right? So private link is the technology that
runs on top of the VPC interface endpoint. The cool thing about private
link is you can create specific solutions for your
like using the same backbone network private connectivity of AWS
if you have consumers that want know consume
services from you. So let's say you are a company, a SaaS company,
whatever it is that you are providing a service and tour customers
which are the vpcs on the left. Once you consume your
service into a private way within AWS,
but you have your account and they have their own account and you have different
vpcs. What you can do is you can create a private link
service which deploys an interface endpoint on the consumer
vpcs, similar as we've seen, the endpoint VPC interface
that I just talked about it. And then you can deploy your application and
the way you do, you just deploy a network cloud balancer and you put your
application behind the network load balancer. So when
the consumer VPC is talking to your application, you actually
be using the interface endpoints and using the private backbone of AWS
to talk to your application. So hopefully you can use this to
really provide better private connectivity for
your customers. So now we're
going to talk. There is one more thing that I'm going to
talk about. It is once you have a global connectivity,
maybe hybrid cloud, what are the options available for you to consume?
So let's talk about hybrid connectivity and DNS. So first we are
going to talk about direct Connect site to site client VPN
and then browse 53. Let's start with direct connect.
Direct Connect allows you to connect your data centers or
offices by literally having a direct cable
connecting you and AWS. So you have a region on AWS and
you have your data center. Then you choose a specific direct location.
There are partners direct connect locations and there are AWS direct
connect locations. There is literally a cable, a fiber
cable, a private fiber cable that will be connected between your customer
router on your data center and the direct connect router.
Then you have resources on your region
and you can actually access privately from
your data center going through the private cable that you run into
direct connect. And then direct connect will connect your specific AWS
account. This is very commonly used when you have a hybrid connectivity
for your specific. And you know,
here you have a direct connect gateway and you
can also with direct Connect gateway you can use one
thing here. What this picture is saying. Like you can have different types of
direct connect. One type of direct connect is just allowing your
data center or corporate office to access a specific
AWS APIs in a private scenario. But you can also
have a direct connect gateway that allows the traffic from
your on premise data centers to connect to the
resources that exist on your AWS
account. So you can see here how this gets
together, right? Like it kind of connects them together. And then
in this case, if you want to encrypt, you can actually put a
VPN on top of that. Because by default the traffic between your data
center and the reconnect, even though they are private, they are not encrypted
by default. So you can put a Ipsec VPN which
this is showing for you that you can achieve.
But now if you don't have a lot of resources
and you don't have a lot of time and you don't require a lot of
bandwidth, you can just use a site to site
VPN. With site to site VPC you have your on premise network, you have
your own router. Then you create a virtual private cloud. On the
cloud you create an iPsec VPN which is using the Internet.
So rather than have a private connectivity, even though it's secure and
encrypt, is actually using the Internet as a way to talk
to your resources. So how
would use. You can actually now put together everything
that I just talked about with transit. So you can have a transgender that has
VPC attachments and then you can have VPAN connectivity
across multiple on premise networks. Let's say you have multiple
private branches or data centers. Instead of having to
connect to each VPC, you can have the transit gateway being the
centralization. So apologies. So the
transit gate will not only solve your problem internally
within AWS, but also for your hybrid cloud.
Now there is another type of VPN which is very specific. It's called the
client VPN. Let's assume you have developers that
want to have access, private access to tour
AWS network running on their laptop. So maybe
they are working remote and you want to provide them the ability to consume
resources that are available within your AWS.
So you deployed a service called the client VPC endpoint.
You can install a software on developers
client laptop and they're going to connect to the client VPN endpoint
and then they're going to have access to tour VPC endpoint. In this case
the ten 10 is 60. I'm just going to take
up a sip of water.
So this is a way you can achieve that. So it's fully managed,
you don't need to do anything. It supports splitting.
So it means that if you only want to send traffic
for the IP address from specific subnets or the whole VPC,
you can support that. Or you can send all the traffic,
even Internet traffic to your account. And you
can also do client authentication using active directory or other types
of federation. And in dance you provide
client to client connectivity. Even like you can actually talk to
each other if you deem necessary.
So how do we bring all together? So in this case we have a
region multiple VPC and you have maybe a couple of data centers.
So here you have a nag gateway. We talked about the Internet
gateway egress only. For IPV six you have
transit gateway connecting different maybe vpcs.
Or you can choose to have a VPC peering endpoint.
You can have specific endpoints if you are consuming specific services,
but then you can have direct connect from your on
premise branch or maybe data center. You can
also have direct connect gateway if you want to access those resources.
Or you can choose to have a VPN site to site connectivity.
So I know this is a lot, but this is to show you that the
capabilities and choices are here for you to choose.
One thing I want to talk about it is DNS quickly. So Amazon route
53 is the DNS service on AWS
and Amazon Route 53 resolver allows
domain name resolutions to be done internally,
kind of super transparently. So all the Amazon provide
dnss, which is the VPC plus two are done
automatically if you choose when you're deploying your architecture.
So you can support DNS host names, you can have private host names.
So when you create an EC two you can have this private hostname.
The reason why your VPC know how to resolve
this is because route 53, so these specific
DNS can be resolved to a specific IP address because
the route 53 resolver for VPC
is available. You can also support resource based private
VPC. So in this case it's using the resource based IP address,
not the DNS with the IP address itself.
You can also resolve public DNS names and
it's as simple as on the VPC you can just decide if you have DNS
host names and DNS resolution enabled. By default those
are enabled. So let's talk about the simplified.
So we talked about a lot of things that are not very specific to
application, but I just want to present to you again to
have that on your toolbox is a service that can simplify server
to service connectivity. The name of this service
is VPC lattice VPC lattice allows
you to have a service mesh for cross
account cross VPC connections without having to managing
peers transit gateways or like being worrying
about overlapping cider ranges with IP address or maybe ipv
six address. It supports a consistent number
of services, compute services like eks, EC two
lambda and elastic compute service elastic container service.
Sorry. By default it works at a layer seven
protocol so you know how to do proper HTTP
routing and so forth. And there is a lot of security being
made available for you so you can centralize the control of your inbound
and outbound traffic for internal communication.
How does that work? Right, so let's say you have two
vpcs and you have a VPC where that VPC,
you have a service that is the parking service and
then you have another VPC that runs. It could be cross account
or it cloud be in the same account and you actually don't want to
create a VPC peering connectivity. You don't want to create a net a
transit gateway, you don't want to create the routings. You just literally want
to give the parking service access to the billing service.
What you can do, you can easily have the VPC lattice
service network deployed across these two VPC and connect
the instance to the VPC lattice service network
that will allow simple cross VPC connectivity without
needing to manage anything that I just talked about previously.
So this is kind of literally a
mindset change on how you can architect your solutions.
Let me give you more examples. Let's say you
want to have different HTTP APIs
and you want to decide specific path basis rules.
So let's say you have a service, again that is a billing service and you
have resources on the VPC and you want to send that
depending on the path you go. So let's say you go with API parking,
you want to send that to a specific VPC that have its own resources
that are managing the parking. Or when you go to API
inventory, you want to send to another VPC. You don't need to
do anything other than creating the routing rules on
the VPC lattice service network. So every time
the service billing will go and talk to API inventory,
the VPC Lida service network will know what to forward
to, in this case the VPC tree.
Another example is granular
ways to secure access to service to service. So you
can actually specify who are
the consumers. In this case the billing. You can say
like you can have multiple services on your service network and
you can decide for example the billing service can only talk to
the parking service, it shouldn't be able to talk to the
inventory. You can create those rules and you can
have a lot of specific rules configured on the VPC lattice
service network saying the billing service only
talks to the parking, not through the inventory. And you can have very complex
and fine grained permissions to achieve what we call
zero trust. So another
thing here that I want to show is to kind of end the presentation is
how can you achieve traffic visibility and monitoring.
So first is VPC flow log. VPC flow logs.
Here you just have an example. Provides all
the VPC data like the traffic. If you enable
the traffic that is going on, your VPC can be logged
on a very specific format so you can have the version, the account
where it's going, what is the IP address, what is the region, what is the
availability, so on and so forth. And then you can actually query
that can be saved on Cloudwatch or can be saved on s three and
you can actually query to see specific. In this example,
it's like, hey, can I tell the connectivity between
these two address, how much bytes have been transferred on this specific
time frame? So you can do that with VPC follow ups.
Highly recommend everyone to enable VPC follow ups because that gives
you the security and ability to inspect what type of
network connectivity have been enabled on your account.
Another interesting feature that you can enable on VPC
is called the traffic mirroring. So traffic mirroring is really important if
you want to do like traffic inspection or any type of security
real time capability, but you don't want to impact the performance
of your current architecture. So what you can do, you can literally
go and enable. In this case, there is no traffic enabled, but you
can enable now a traffic. And once
you enable, so you click to enable the traffic.
What did you do? Every single packet that has been sent
tour specific VPC work properly. But once you enable
VPC traffic mirroring, you can create a monitoring instance. So you can create
your own traffic analyzer using open source traffic analysis
or using AWS traffic mirroring partners.
Every single packet that is sent to your VPC will be replicated
and mirrored into that specific ENi. And then
you can create a lot of specific security inspections in
real time. And that concludes my presentation.
I hope you were able to learn some of the key components. I know
there was a lot that I covered and I kind of went little bit quickly.
If you have any questions, feel free to connect with me on LinkedIn.
My name is Samuel Baruffi. I appreciate your time, thank you so
much and bye.