VPC Peering is a way to privately connect 2 VPCs via the AWS network so they operate as if in the same network – and without going via the public internet.
Important points about VPC Peering – also for exam:
They must not have overlapping CIDRs.
They are NOT transitive – this means you have to connect one-to-one directly,
not via the peering of another VPC.
You must still update the route tables in each VPCs SUBNETS to ensure the EC2s in each VPC subnet can communicate with each other.
You can connect your own AWS account VPCs, and also other account VPCs, and also different regions together using VPC Peering.
You can access or reference the security group of the peered VPC in the other VPC. This is very powerful.
How To Set Up VPC Peering
in AWS Dashboard access:
Virtual Private Cloud -> Peering Connections
Remember to modify the route table of your VPCs
in the source VPC route table:
add route for the CIDR that corresponds to the CIDR of the destination VPC
and then, do the same for the destination VPC roue table (ie vice-versa)
so you have set up a route that runs both ways. This is essential!
VPC Endpoints provide an alternative way for an EC2 instance to connect to another service or instance without going via the public internet.
All AWS services have a public URL – so one way to connect is to go via pubic internet and the public url – but VPC Endpoints provide an alternative way…
We can use VPC Endpoints which operate using AWS PrivateLink.
This is an AWS internal network which you can use instead of going via public internet.
VPC endpoints are redundant and scale horizontally.
They also remove the need for using IGW, NATGW etc to access AWS services from your EC2s.
Remember to check DNS setting resolution for your VPC and also check your route tables so that VPC Endpoints will be able to work correctly.
2 Types of VPC Endpoint
Interface Endpoints – these are powered by Private Link
it supports most AWS services
is charged per hour and per GB of data that passes through the endpoint.
provisions an ENI – private IP address as an entry point – must be attached to a Security Group
It is the preferred method when access is required to AWS services from an on-premises site eg Site to Site VPN or Direct Connect, from a different VPC or different region.
Here you provision a gateway and this must be used as a TARGET in a route table – ie it does NOT use Security Groups
it is only a route table target entry, nothing more!
there are only 2 targets you can use for this – S3 and DynamoDB – important to note!
it is FREE to use.
So which to use?
Gateway Endpoint is usually the question point asked in the exam.
It is free, simple to set up.
VPC Flow Logs
VPC Flow Logs are very useful for analyzing traffic through your interfaces.
There are VPC flow logs, subnet flow logs and ENI elastic network interface flow logs
they can be saved in S3 or cloudwatch logs
they can also capture network traffic info from AWS managed interfaces as well, such as ELB, RDS, ElastiCache, Redshift, NATGW, Transit Gateway etc
you have 2 ways to analyze the flow logs:
using Athena on S3, or
using CloudWatch Logs Insights or set up a CloudWatch Alarm and possibly send an alert message to eg AWS SNS.