So now let's talk about VPC endpoints.
The idea is that you have services on AWS, for example,
such as DynamoDB and they are accessible publicly.
So that means that your whole infrastructure
through your NAT gateway and then your internet gateway
or just directly
through your internet gateway does access DynamoDB.
But all this traffic goes through the public internet
and you may have other services such as CloudWatch
and Amazon S3 that you also wanna access
without going through the internet.
You wanna access them privately.
So the idea is that you're going to use VPC endpoints
so that your instances don't have to go
through the public internet,
they can just go directly
through the private AWS network to these services.
So let's consider this architecture that we know already,
so we have public subnets with a NAT gateway
and it's EC2 instance, a private subnet,
and then we're going to have an internet gateway
so that we know we can access the Amazon SNS service
for example, through different ways.
So if we look at the private subnet
and the EC2 instance in it,
to access the Amazon SNS service,
the EC2 instance can go through the NAT gateway
which then goes to the internet gateway
and then accesses publicly the Amazon SNS service
and this is the same
for the EC2 instance in the public subnet,
it goes directly through the internet gateway
to the Amazon SNS service.
And this option is fine
but it costs just a lot of money because, well,
we have to go through NAT gateway, which has a cost,
and then we have to go through the internet gateway
which doesn't have a cost
but still there is obviously many hops
and it's not very efficient.
So instead, I'm just representing
the same Amazon SNS service,
but somewhere else on the diagram,
we can use a VPC endpoint.
And the idea is that the VPC endpoint is deployed
within your VPC and by doing some networking,
we can actually make the EC2 instance
in the private subnet go through the VPC endpoint
directly into the Amazon SNS service
and the network has never left AWS, which is really good.
So, every AWS service is publicly exposed,
it has public a URL,
and if you use VPC endpoints, they are powered
by something called AWS PrivateLink because you
access these services privately.
Then you can connect to any of these services
by AWS using a private network
instead of going over the public internet.
These VPC endpoints are redundant and they scale
horizontally, and they're going to remove the need
for an internet gateway or a NAT gateway
to access AWS services,
thus simplifying your network infrastructure by a lot.
So in case of issues, you need to check the DNS
settings resolution in your VPC and your route tables.
So this is the general idea behind the VPC endpoints now,
we have two types of VPC endpoints.
We have the Interface Endpoints
and these are powered by PrivateLink
and we have the Gateway Endpoints.
So the Interface Endpoints provision an ENI,
so it's a private IP address in your VPC
and this ENI is an entry point to your private AWS service.
And so for this, we must attach a security group
because there is an ENI and it supports most AWS services
if not all, and there's a cost to it, it's a cost
per hour and it's a cost per gigabyte of data processed.
So here we go, we have an EC2 instance
and a private subnet and thanks to a PrivateLink
VPC endpoint of type interface
then we can access through the ENI to the service.
And this works for every single service out there.
Now we have the Gateway Endpoint and they're special.
They provision what's called a gateway
and this has to be used as a target in a route table.
So this does not leverage IP addresses,
this is not a leverage security groups,
it's just a target in a route table
and you need to remember that.
And there are only two targets for a Gateway Endpoint,
it is Amazon S3 and DynamoDB, but the advantage
that this is free and this scales automatically
because it's only a route table access.
So, it's only for Amazon S3 and DynamoDB, remember this.
And in this instance,
we provide a VPC endpoint of type gateway
and we have access to Amazon S3 or DynamoDB.
So the question you may ask me is, hey,
if the Interface Endpoint supports everything
and the Gateway Endpoint supports Amazon S3 and DynamoDB,
should I use the Gateway
or the Interface Endpoint for Amazon S3 or DynamoDB?
Well, we have indeed two ways
of accessing Amazon S3, right?
Either with the Gateway Endpoint
or with an Interface Endpoint.
And at the exam, the Gateway is most likely going to
be the preferred solution at the exam, why?
Well, because we just have to modify a route table.
So, and your apps can access Amazon S3 free of charge,
so the cost is free for a Gateway, it scales more,
and for the Interface Endpoint,
you have a cost associated with it.
The only time where an Interface Endpoint may be preferable
over a Gateway Endpoint is
if you require access from on-premises, for example
you want private access from your on-premise data center
and we haven't seen it yet, but we can connect it
through something called site to site VPN or direct connect
or it's maybe preferable if you want to connect
from another VPC through this Interface Endpoint.
So these are advanced use cases, right?
And this is what is represented on this graph.
But most of the time
the Gateway Endpoint is going to be preferred
for Amazon S3.
Okay, that's it for this lecture,
I hope you liked it and I will see you in the next lecture.