There are two main ways of connecting on-premises sites to AWS Cloud VPCs:
Customer Gateway – via a dedicated private network.
Direct Connect – via a private dedicated network link
Customer Gateway to VPN Gateway
This is used to connect an on-premises site to an AWS VPC.
this is via public internet using an encrypted VPN connection over the internet.
So we need a VGW on the AWS side, connected to the relevant VPC we want to link to.
VGW is Virtual Private Gateway or “VPN Concentrator” device.
If desired, you can customize the ASN Autonomous System Number for the VGW
The CGW or Customer Gateway on the on-premises side can be software-based or alternatively an actual physical gateway device.
For the CGW: which IP, then if public then you would use your internet routable ip address for your CGW, but – it can have a private ip ie a NAT-enabled… then you would use the public ip of the NAT device/NAT router/gateway.
Also – important exam Q:
you MUST enable Route Propagation for the VPN in the route table of your relevant subnets in the VPC you are wanting to connect to via the link.
plus, if you need to ping your EC2s from on-premises, then you must enable ICMP on the inbound traffic of your security groups – important!
AWS VPN CloudHub Direct Connect DX
Direct Connect DX provides a dedicated PRIVATE connection from your on-premises site to your VPC
you need to use a VPG virtual private gateway on your VPC
You can access public resources eg S3 and private eg EC2 on the same connection.
DX supports ipv4 and ipv6.
Use cases for Direct Connect:
to increase bandwidth, eg when working with large data sets – lowers costs.
to provide more consistency in network experience – eg for applications that use realtime datafeeds.
for hybrid environments – ie on-premises IT and cloud combinations
To set up:
You use a Direct Connect Endpoint at AWS
then you set up a customer router with a firewall on your on-premises site
Types of DX Direct Connect Connection Types:
Dedicated Connection or Hosted Connection.
It takes about 1 month or more to set up the Direct Connect link.
if you want a connection set up quickly ie faster than 1 month, then DX is NOT suitable! – unless there is already a DX link present at the site.
1,10,100 Gbps capacity possible, request to AWS, then it is completed by DX partners.
you get a dedicated physical ethernet port
takes 1 month+
50mbps, 500 Mbps, to 10Gpbs
takes 1 month+
request made via DX partners.
capacity can be added/removed on demand
Note: data is NOT encrypted, but it is a private link.
But a DX link plus a VPN running on top of the link provides for an IPsec-encrypted private connection
this is good for extra security, but more complicated overhead to set up.
this is where you have 2 direct connect locations, one connection for multiple locations. This is good for critical workloads
But – for max resiliency locations you must create TWO connection devices at each site, to provide for redundancy.
Site to Site VPN Connection used as a backup.
if the DX direct connect fails, then you can run a backup DX connection (expensive) or alternatively a site to site VPN CONNECTION.
Remember this for exam!
Also exam Q:
How to enable services in one VPC to access another VPC:
Two possible ways:
1. go via public internet
but managing the access is hard
2. VPC Peering –
you have to create many peering relations if there are multiple VPCs… can be complicated
and it opens up the whole VPC network to another – risky.
whereas you really only want to open up access for one or a few specific services…
so an alternative option is to use AWS PrivateLink – VPC endpoint Services
AWS PrivateLink – VPC Endpoint Services
Advantage: this is secure and scaleable, and can be used to create access for 1000s of VPCs if needed.
And – it does not require any VPC peering, internet gateways, NAT or route table config.
So, we conceive of it as follows:
we have a Service VPC with our application service running in it
and we have a Customer VPC which has instances or other services which want to access the app service in the Service VPC:
You need a Network Load Balancer for the applic service in the Service VPC
and on the customer VPC side we create an ENI Elastic Network Interface, and this connects privately from ENI to the NLB
AWS Classic Link
AWS Classic Link – this is deprecated but can still come up in the exam…
This is a legacy of the system that existed for AWS before the separation of accounts with VPCs in AWS – all EC2s ran in one network.
Classic Link enables you to connect EC2 Classic Instances to a VPC in your account.
It enables private ipv4 communication.
for this you must create a security group
prior to this you had to use an ENI and public ipv4 – this is now no longer the case if you use Classic Link.
Could come up as a distractor in the exam
AWS Transit Gateway
This is an alternative to VPC Peering. Simpler, and it allows for transitive VPC connections, as they all connect via the same Transit Gateway
can be regional and cross-regional, cross-account, via RAM Resource Access Manager
you can also peer transit gateways across regions
the route tables are used to finely tune or narrow down which VPCs can talk to which other VPCs according to requirements.
It also works with DX Direct Connext Gateway/VPN connections
and supports IP Multicast (not supported by any other AWS service – know this for the exam!)
Another use case for TG;
to increase your bandwidth using ECMP – Equal-cost multi-path routing
connecting multiple VPCs to the TG means you get more total bandwidth available. Of course this also costs more.
VPC Traffic Mirroring
This is a way to do a non-intrusive analysis of our VPC traffic, by routing a copy or mirror of the traffic to security appliances that we run…
so, to do this, we capture the traffic, from source ENI/s, and to targets – ENI/s or network load balancer NLB:
so effectively we are mirroring or sending a copy of our traffic to our NLB..
to do this source and target addresses must be in the same VPC – or different VPCs provided they are using VPC Peering between each other.
NOTE that IPv4 can NEVER be disabled in VPCs or subnets on AWS.
but you can enable ipV6 to operate in “dual stack mode”.
All your EC2 instances will get at least a private internal ipv4 and a public ipv6.
They can communicate using either of these to and from the internet via the internet gateway.
This means that if you can’t launch a new EC2 in your subnet, then this may be because there are no ipv4s free left in your subnet.
The solution for this is to create a new ipv4 CIDR in your subnet.
Even if you are using ipv6 for your instances this means you must have ipv4 addresses left in your created range in order to create any EC2s!
Egress-only Internet Gateway (ipv6)
this is used only for ipv6
They are similar to a NAT GW but for ipv6
They allow EC2s in your VPC to make outbound connections over ipv6 while preventing incoming traffic from the internet initiating an ipv6 connection to your EC2s.
Note you MUST UPDATE THE ROUTE TABLES for PRIVATE SUBNETS FOR THIS (not for public subnets)