Difference between VPN and Direct Connect Hardware VPN
- VPN is associated with Virtual Private Gateway, not with your VPC. What you can do is to detach the VPG and can reattach it to another VPC. VPN Billing
- Pay for the connection hours
- Pay for data transfer
- Depends where is the Customer Gateway. If it is in your DC, data transfer charge is standard Internet data transfer
- If you are using via Direct Connect public VIF, you are charged by Direct Connect rates
- Another VPC in the same region via EIP - local region charges
- Another VPC in another AWS region - remote region data transfer charges
- Connections over a DX are not encrypted. Workaround is that you would create a public VIF to access endpoints. Another service is VPN endpoints within AWS public zone. You can create a VPN running over the top of DX connection.
- Private VIF: connects you to a virtual private cloud (VPC) but not to the VPC+2 DNS server and not the VPC endpoint for AWS S3.
- They are per region only. They are one to one connection. Single VLAN on your network and VPC. Public VIF
- Public VIF connects you to public AWS services and located within the associated region. Anyone else using AWS public IPs and managed VPN public IPs (+VPN endpoints)
- Global resource to create private VIFs which are associated with this DirectConnect Gateway. And then you can associate on premises gateways or AWS private gateways with DirectConnect Gateway. It advertises all the networks with BGP. This reduces the admin overhead. It’s not a transitive device.
- There is a port charge for this connection. Charged for traffic data transfer out, it’s a lot lower than internet connection.
- There is a significant installation time as well.
- VPN can serve as a backup for DirectConnect connection.
- Transitive routing service, as known as full mesh.
- Create a Transit Gateway within a region and connect to different VPCs with VPC attachment and to your onpremises router with VPN attachment. It’s capable of routing in a transitive way.
- Transit Gateway can be shared within Resource Access as well.
1G/10G dedicated connections
- Let’s say within your account, you created a 1G or 10G Direct Connect connection. On that connection, you are going to create a virtual interface. You will also choose a VLAN. You can create multiple of those for specific VPCs. You can also share these across accounts. There is also an option to enter another AWS account number on that connection. It will become a hosted virtual interface. Within partner hosted connections: VLAN ID is chosen for you by the partner
- Within each Direct Connect location, AWS has 2 redundant routers. Moving a connection to another account is done by raising a support case
- You can delete and re-create VIFs if you want to move it to another VGW to connect to your VPC
BGP (Border Gateway Protocol)
- BGP neighbors exchange routing information - prefixes. More specific prefixes are preferred
- BGP uses Autonomous System Numbers - ASNs. iBGP - between peers in the same AS. eBGP - between peers in different AS (when in the case you have a connection between AWS and your DC)
- AS_PATH - measure of network distance: not the same as traceroute. This represents the whole network
- ASN numbers can change per public/private VIFs for particular connections within BGP
- Suppose you have 3 different regions us-west-1, us-east-1 and eu-west-1 with ASNs 7224, 7224 and 9800 with a Corporate Backbone Network with ASN = 65000. When you try to connect from us-west-1 to us-east-1, the announcement will be rejected because it will understand as if it was coming from the same region with same ASN. You can use the functionality of AS overwrite facing the region you want to connect from. If you want to connect from eu-west-1 to us-west-2, it is ok, ASN will be announced and since the number is different, it’s accepted. However, the other way around, when us-west-2 announces from ASN 7224, in to eu-west-1… You will find it’s rejected because 7224 is used internally for Direct Connect. You can actually put a specific CIDR address route in your VPC inside your IGW route table to tell if I have traffic for that specific CIDR block, send it to the VGW!
1) Local routes to the VPC
2) Longest prefix match first (/24 is more specific to /16)
3) Static route table entries preferred over dynamic
4) Dynamic routes
5) Prefer Direct Connect BGP routes
6) Shorter AS path
7) Considered equivalent, and will balance traffic per flow
8) VPN static routes
9) BGP routes from VPN
10) Shorter AS path
AWS VPN CloudHub
- Way to connect multiple remote networks all into the same VGW. Exchanging routes via VGW. It gives you access to the VPC. You can also use same AS numbers but custom config required. Instead of connecting multiple remote offices, you can also connect another VPC in another region together with other locations. You can achieve this building software VPN instances. You can also connect a private DX VIF as well
- Moving 2 software VPN instances to a hub environment. Creating a VPC and putting these 2 instance in it acting as a Customer Gateway. VPN over Public VIF on Direct Connect is done with Virtual Routing and Forwarding!!!
- State is stored on my server so scaling horizontally does not work that well Solution
- In order to scale horizontally and not have a user locked into a server, I need to move state off of my server into a KVS. Moving session data into DynamoDB or ElastiCache allows my application to be stateless. This lets you use a scale out pattern without having to worry about inheritance or loss of state information
Virtual Private Gateway
- If you wanna connect your on-premises to AWS, you need to create a virtual private gateway. It’s a logical, fully redundant distributed router that sits at the edge of your VPC. VGW can terminate IPSec VPN. AWS is partnered with 3rd party colocation companies such as Equinix etc. for a Direct Connect location (physical DC). The customer picks the Direct Connect site and then the connection link; 1Gbps or 10Gbps which will generate the quote. Once the physical connection is done, you need to configure the logical/sub interfaces. In AWS, there are 2 different types, virtual interfaces, VIFs. Private VIF and Public VIF are both configured as separate .1q VLAN tag across Direct Connect.
Direct Connect Gateway
- You can connect your on prem with this gateway to the other regions of your AWS services. You can think of this as a redundant peering point, distributed VRF. It’s only used for VPC attachment, no public connectivity.
Direct Connect Billing
- Physical Connection: $0.30/port hour for 1G and $2.25/port hour for 10G. Data Transfer Out: per GB regardless of the service type, depends on the region etc. No charge for ingress data. Source/Destination of the data is important.
Hybrid DNS Architectures By default, there is a VPC resolver and DNS configured.
–picture to be inserted here–
- If the client on premises wants to reach out to two.myvpc.com, it gets to the DC mydc.com first and since it’s not resolvable publicly, we need to create a conditional forwarding rule that forwards the requests to the VPC. However, VPC resolver is not reachable other than local VPC resources. To get around this, Unbound DNS can be implemented in the VPC running conditional forwarders.
- New services: Route 53 Resolver Endpoints: you will be able to place resolvers to your endpoints that are reachable over Direct Connect. You can place multiple on different AZs as primary, secondary and tertiary.
- If you need to connect to your VPCs via DirectConnect, you’ll need to have virtual gateways attached to Private Virtual Interfaces. For services such as S3 and DynamoDB, you need to have public virtual interface as these services need to be accessible publicly and they are region independent