Please enable JavaScript.
Coggle requires JavaScript to display documents.
VPC - Coggle Diagram
VPC
Direct Connect
Establish private (do not use internet) and dedicated connectivity between AWS and your data center or office
Increase bandwidth throughput and provide a more consistent network experience than internet-based connections (e.g. VPN). 1 Gbps, 10 Gbps, and 100 Gbps connections (for dedicated connection)
2 Type of Connections
locations here
- Dedicated Connection
- physical ethernet connection associated with a single customer. Customers can request a dedicated connection through the AWS Direct Connect console, CLI or API
- made through a 1 Gbps, 10 Gbps, or 100 Gbps Ethernet port dedicated to a single customer
- Hosted Connection
- physical ethernet connection that an AWS Direct Connect Partner provisions on behalf of a customer. Customers request a hosted connection by contacting a partner in the AWS Direct Connect Parter Program, who provision the connection
- sourced from a AWS Direct Connect Partner that has a network link between themselves and AWS
- Port Speed: 50 Mbps, 100 Mbps, 200 Mbps, 300 Mbps, 400 Mbps, 500 Mbps, 1 Gbps, 2 Gbps, 5 Gbps, and 10 Gbps
VPN vs Direct Connect
VPNs allow private communication, but it still traverses the public internet to get the data delivered. While secure, it can be very slow
- Direct Connect:
- Fast
- Secure
- Reliable
- Able to take massive throughput
- New connection takes longer than 1 month to establish
- Useful for:
- High-throughput
- Stable, Reliable and Secure connection
To get redundancy, customers often use 2 direct connections. If you can’t start with two direct connections, you can start with one direct connection and one VPN connection for failover purposes
Transit gateway: A transit hub that can be used to interconnect multiple VPCs and on-premises networks, and as a VPN endpoint for the Amazon side of the Site-to-Site VPN connection.
If you’re using AWS Direct Connect to connect to multiple VPCs through a Direct Connect Gateway, the VPCs that are associated with the direct connect gateway must not have overlapping CIDR blocks
Supports AWS Transit Gateway to connect thousands of VPCs in multiple AWS Regions to your on-premises networks using Direct Connect
AWS does not act as my "first mile" or "last mile" provider to connect my on-premises locations to AWS. You need to work with the local service providers used at your on-premises locations, or work with an AWS Direct Connect Delivery Partner, to connect to AWS Direct Connect locations
IF and GW
Virtual interface (VIF) is necessary to access AWS services, and is either public or private. A public virtual interface enables access to public services, such as Amazon S3. A private virtual interface enables access to your VPC via VGW
- Public VIF – connect to Public AWS Endpoints (S3 buckets, EC2 service, anything AWS ...)
- Private VIF – connect to resources in your VPC (EC2 instances, ALB, ...). VPC Interface Endpoints can be accessed through Private VIF. Gateway types are:
- Direct Connect Gateway (recommended) - allows connections to many VPC and Regions
- Virtual Private Gateway - allows connections to a single VPC in the same Region
- Transit VIF – is a VLAN that transports traffic from a Direct Connect Gateway to one or more Transit Gateways
- Associate up to 3 transit gateways in any AWS Region per transit VIF
Virtual private gateway (VGW) is part of a VPC that provides edge routing for AWS managed VPN connections and AWS Direct Connect connections. You associate an AWS Direct Connect gateway with the virtual private gateway for the VPC
Direct Connect gateway (DXGW) is a globally available resource. You can create the AWS Direct Connect gateway in any Region and access it from all other Regions. Use a DXGW to connect your VPCs associating with either TGW (multiple VPC in the same Region) or VGW. More here
Good to know
- You can have both Private & Transit VIF on the same Direct Connect Connection, provided it is a dedicated connection
- You can only have either VGW (Private VIF) or TGW (Transit VIF) attached to the DXGW, but not both
- For a Private VIF, AWS advertises the VPC CIDR only over the BGP neighbor. AWS can't advertise or suppress specific subnet blocks in the Amazon VPC for a private VIF
- Connect up to 3 Transit Gateways over a single Direct Connect Connection
Encryption
- AWS Direct Connect is not encrypted by default
- Dedicated connections of 10 or 100 Gbps, you can use MAC security (MACsec) as an encryption option
- Connections of 1 Gbps or less, you can create VPN tunnels on top of the connection
-
SiteLink
- Allows you to send data from a Direct Connect location to another bypassing AWS Regions
- Works with 2 DXs connected to 2 different DX Locations
- Data is sent over the fastest path between Direct Connect locations
- Use cases: create private network connections between on-premises data centers by connecting them to Direct Connect locations
VPC Peering
Multiple VPCs
Sometimes you may need to have several VPCs for different environments (e.g. Production Web VPC, Content VPC, Intranet VPC, ...) and it may be necessary to connect these VPCs to each other
Different VPCs for Dev, Test, Staging and Production, you can have need to move data/code between environments
-
-
Peering is in a star / hub-and-spoke configuration, e.g. 1 central VPC peers with N other VPCs
No transitive peering and no edge-to-edge routing trough gw or private connection (VPC A <--peer--> VPC B, A cannot access internet/on-premise via B's S2S VPN, DX, Gateway VPC Endpoint, IGW, NAT)
Peering allows you to connect a VPC with another via a direct network route using private IP addresses
-
-
- Need to use Route Table to point the IP address range of the other VPC
- You must update route tables in each VPC’s subnets to ensure instances can communicate
-
- You can update the inbound or outbound rules for your VPC security groups to reference security groups in the peered VPC:
- The peer VPC can be a VPC in your account, or a VPC in another AWS account. To reference a security group in another AWS account, include the account number in Source or Destination field; for example, 123456789012/sg-1a2b3c4d
- You cannot reference the security group of a peer VPC that's in a different Region. Instead, use the CIDR block of the peer VPC
Basics
- VPC is a virtual data center in the cloud
- Logically isolated part of AWS where you can define your own network
- Provides complete control of virtual network including your own IP address range, subnets, route tables, network access control list, internet gateways (or virtual private gateway) and security groups
1 subnet is always in 1 AZ
What can we do?
-
Configure Route Tables between subnets, the more specific route in a RT is applied (the smaller destination CIDR, aka longest prefix)
-
-
-
-
Default VPC
- user friendly
- All subnet have a route to the internet
- Each EC2 has both public and private IP address
Custom VPC
- Fully customisable
- Takes time to setup
-
Elastic IP address
It is a static public IPv4 address, which is reachable from the internet. If your instance does not have a public IPv4 address, you can associate an Elastic IP address with your instance to enable communication with the internet
Primary purpose is remapping traffic in case of failure. An Elastic IP address is allocated to your AWS account, and is yours until you release it. By using an Elastic IP address:
- mask the failure of an instance or software by rapidly remapping the address to another instance
- specify the Elastic IP address in a DNS record for your domain, so that your domain points to your instance
-
IP addressing:
- assign IPv4 addresses and IPv6 addresses to your VPCs and subnets
- bring your public IPv4 and IPv6 GUA addresses (Global Unicast Addresses) to AWS and allocate them to resources in your VPC, such as EC2 instances, NAT gateways, and NLBs
- you can have VPC: IPv4 only or dual stack (IPv4 and IPv6) but not IPv6 only VPC
- AWS Recommended Internal CIDR:
- 10.0.0.0/8 (10.0.0.0 - 10.255.255.255)
- 172.16.0.0/12 (172.16.0.0 - 172.31.255.255)
- 192.168.0.0/16 (192.168.0.0 - 192.168.255.255)
VPC CIDR blocks
- A VPC must have an IPv4 CIDR block associated with it
- VPC CIDR block size must be between /16 and /28
- You can optionally associate multiple IPv4 CIDR blocks and multiple IPv6 CIDR blocks to your VPC
IP addressing schemas:
- Unicast - IP assigned to single host (1-to-1)
- Multicast - used to deliver data to a group of destinations (1-to-M). Any IP packet sent to a multicast address is delivered to only those hosts that have joined that particular IP Multicast group
- Anycast - multiple servers to share the same IP address, allowing for multiple physical destination servers to be logically identified by a single IP address. In CDN same IP address to multiple edge servers, in DNS same IP address to multiple DNS servers
VPC DNS settings
- DNS resolution
- DNS hostnames - public DNS hostnames for instances based on public IP
VPC Endpoints
Enables you to privately connect your VPC to supported AWS services and VPC services powered by PrivateLink without requiring an IGW, NAT devices, VPN connection or AWS Direct connection
-
3 Types of VPC Endpoints
Interface Endpoint are based on ENI and supports many AWS services. Typically accessed using the public or private DNS name associated with the service (can be accessed from outside the VPC)
Gateway Endpoints are based on virtual devices you provision and support S3 and DynamoDB. Serve as a target for a route in your route table for traffic destined for the service (VPC only)
Gateway Load Balancer Endpoints are based on ENI and are for GLB only. Serve as a target for a route in your route table for traffic destined for the service
Instances in your VPC do not require public IP addresses to communicate with resources in the service
Endpoints are Virtual Devices that are horizontally scaled, redundant and highly available VPC components that allow communication between instances in your VPC and services without imposing availability risks or bandwidth constraints on your traffic
VPC Endpoint Policy
It is a JSON policy document that controls which AWS principals can use the VPC endpoint to access the endpoint service
You cannot attach more than one policy to an endpoint. However, you can modify an endpoint policy at any time
An endpoint policy does not override or replace identity-based policies or resource-based policies. For example, if you're using a S3 endpoint, you can also use S3 bucket policies to control access to buckets from specific endpoints or VPCs
If you do not specify an endpoint policy when you create an endpoint, AWS attaches a default policy that allows full access to the service
-
Not all endpoint services support endpoint policies. If a service does not support endpoint policies, the endpoint allows full access to the service
- In the resource policy you can have the following conditions:
- aws:sourceVpc : VPC ID
- aws:sourceVpce: VPC Endpoint ID
- aws:VpcSourceIp request originates from the specified IP address and it goes through a VPC endpoint
- aws:SourceIp condition doesn’t apply for VPC endpoints, it only works for public IPs
When accessing the endpoint instances use their private IP address, existing connections using public IP address are dropped (ensure that you don’t have critical tasks running when you create or modify an endpoint)
DNS Resolution
- Gateway Endpoint
- DNS resolution must be enabled in the VPC
- Ensure that a route to the service is present in the Route Table:
- Destination: Prefix List for your service
- Target: your VPC endpoint
- Can only be accessed from VPC resources
- Interface Endpoint
- Choose between Private DNS and Public DNS
- Private DNS:
- Must enable DNS Hostnames and DNS Resolution for your VPC
- The public endpoint of a service will resolve to the private Endpoint Interface hostname
- The public endpoint for the service is going to be a CNAME for the private DNS hostnames (regional + one for each AZ) of the service
- Private DNS hostnames (regional + one for each AZ) of the service are A records for the ENIs
- Public DNS:
- You need to use Private DNS hostnames (regional + one for each AZ) of the service to access the VPC Endpoint interface
- Interface can be accessed from Direct Connect and Site-to-Site VPN
How VPC Endpoint works
VPC interface endpoint
- Create a new interface endpoint. Provide the name of the AWS service or endpoint service with which you want private connectivity
- Create a network interface ENI and select the subnet to use the interface endpoint
- From the IP address range of the subnet, a private IP is assigned to the endpoint network interface. This private IP address will be retained until the interface endpoint is removed
- It will also provide you a DNS name per each AZ and a regional name that you can use in your applications
- Using Private Hosted Zone (Route53 Resolver) you can have the AWS service domain name for the VPC interface endpoint be resolvable to the private IPs of the endpoint
- The private IP address ensures that the traffic does not leave the Amazon network without making any changes to the route table
- Interface can be accessed from Direct Connect, Site-to-Site VPN and VPC Peering
VPC gateway endpoint
- You create a VPC gateway endpoint
- You select the VPC route tables for the subnets you enable
- AWS automatically adds new routes to each route table that you select
- The target is the gateway endpoint; the destination will be a prefix list for the associated AWS service.There is no need to explicitly make the instances to use the gateway endpoint to access the gateway services. All instances in the subnets associated with these route tables will automatically use the gateway endpoint
- VPC Endpoint Gateway is only for your VPC resources, cannot be accessed from resources outside your VPN network via VPN, DX, TGW, VPC peer
Interface vs Gateway
-
- Association
- Interface -> Subnet
- Gateway -> VPC
- Cross-region Access
- Interface -> Allowed
- Gateway -> Not Allowed
- Cost
- Interface -> Billed
- Gateway -> Free
- S3 DNS Name
- Interface -> Requires Endpoint Specific
- Gateway -> Use Same S3 DNS Name
- IP Address
- Interface -> Private IP Address (IPv4 / IPv6 assigned to ENI)
- Gateway -> S3 Public IPs
- Route Table
- Interface -> No change
- Gateway -> Requires change
-
NAT Gateways
You can use a NAT device (NAT Gateway vs NAT instance) to allow resources in private subnets to connect to the internet, other VPCs, or on-premises networks. These instances can communicate with services outside the VPC, but they cannot receive unsolicited connection requests.
Key Facts
-
Not associated with SG, IPv4 only traffic
-
-
-
-
-
NAT Instances
- It is deployed in a public subnet with a public IP
- It is not redundant, does not scale automatically
- NAT Gateway is to always be preferred over NAT Instance for non trivial use case
- Must disable Source/Destination Check (EC2 setting), this applies to any instance proxying internet traffic. By default EC2 instance check it must be the source or destination of any traffic it sends or receives
-
If you have resources in multiple AZs and they share a NAT Gateway, in the event the NAT Gateway's AZ is down resources in other AZ lose internet access
To create AZ-indipendent architecture, create a NAT Gateway in each AZ and configure routing to ensure resources use the NAT Gateway in the same AZ
Supports the following protocols: TCP, UDP, and ICMP
If you delete a NAT gateway, the NAT gateway routes remain in a blackhole status until you delete or update the routes
NAT Gateway restriction: any source network that comes from S2S VPN or DX cannot go through the NAT Gateway to the IGW into the public internet. Need to use NAT Instance
Transit Gateway
- Connects VPCs and on-premise network through a central hub
- Simplifies your network and puts and end to complex peering relationship
- Acts as a cloud router, each new connection is only made once
Key Facts
-
Works on a regional basis, but you can have it across multiple regions (You can peer Transit Gateways across regions)
-
-
If a new VPC is created, it is automatically connected to the Transit Gateway and will also be available to every other network that is also connected to the Transit Gateway
-
DNS support enable to allow VPC to resolve public IPv4 DNS hostnames to private IPv4 addresses when queried from instances in another VPC attached to the transit gateway
-
Key Concepts
- Attachments - You can attach the following: VPCs, DX, TGW, VPN and Transit Gateway Connect (SD-WAN)
- Route table - Default route table and can optionally have additional route tables. A route table includes dynamic and static routes that decide the next hop based on the destination IP address of the packet. The target of these routes could be any transit gateway attachment
- Associations - Each attachment is associated with exactly one route table. Each route table can be associated with zero to many attachments
- Route propagation - A VPC, VPN connection, or Direct Connect gateway can dynamically propagate routes to a transit gateway route table
Attachments
- VPC Attachments (VPC)
- specify 1 subnet per AZ
- doesn't support routing between VPCs with identical CIDRs
- doesn't support subnet in Local Zone (go trough parent AZ instead)
- doesn't support IPV6 only subnet
- support both static and dynamic routing
- VPN Attachments (VPN)
- you must specify the customer gateway
- support both static and dynamic routing
- for static VPNs, add the static routes to the transit gateway route table
- if customer gateway is behind NAT, then specify NAT public IP
- Direct Connect Gateway Attachments
- attach to a Direct Connect gateway using a transit virtual interface
- configure attachment from DX console Direct Connect gateway > Gateway association > Associate gateway > your Transit Gateway
- Peering Attachments (Peering Connection)
- peer both intra-Region and inter-Region transit gateways
- same or different account
- support IPv4 and IPv6 traffic
- static routing only
- (Transit Gateway) Connect attachments
- connect with third-party virtual appliances (such as SD-WAN appliances) running in a VPC
- supports the Generic Routing Encapsulation (GRE) and BGP
- from the Connect attachment you create one/more GRE tunnels (aka Transit Gateway Connect peers) to connect with 3P appliances
Use Case:
- Egress Traffic Inspection:
- If FW vendor doesn’t support automation for failure detection, or if you need horizontal scaling
- Create VPN attachment to the FW appliances leveraging BGP to exchanges routes ( you have a VPN between TGW and FW appliances)
Network ACL
- The first defence line
- It is an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets
- You might set up a Network ACL with rules similar to SG in order to add another layer of security to your VPC
Default Network ACL your VPC automatically comes with a default network ACL and by default allows all outbound and inbound traffic. You cannot delete the default Network ACL, but you are able to add and remove your own rules from the default Network ACL. However, each Network ACL also includes a rule whose rule number is an asterisk. This rule ensures that if a packet doesn't match any of the other numbered rules, it's denied. You can't modify or remove this rule.
Custom Network ACL includes a rule whose rule number is an asterisk. This rule ensures that if a packet doesn't match any of the other numbered rules, it's denied. You can't modify or remove this rule.
100 HTTPS(443) 0.0.0.0/0 Allow
200 SSH(22) 0.0.0.0/0 Allow
* All Traffic Deny
Subnet Association each subnet in your VPC must be associated with a Network ACL. If you don't explicitly associate a subnet with a Network ACL, the subnet is automatically associated with the default Network ACL
Block IP Addresses Block IP addresses using Network ACLs, not SG
Key Facts
NACL contains a numbered list of rules that are evaluated in order starting with the lowest numbered rule
Stateless responses to allowed inbound requests are subject to the rules for outbound traffic (and vice versa)
Network ACL relationship to subnet is Many-to-1 (a subnet can only have a NACL, a NACL can be associated to many subnets). When you associate a network ACL with a subnet, the previous association is removed
-
AWS PrivateLink
You do not need to use an internet gateway, NAT device, AWS Direct Connect connection, or AWS Site-to-Site VPN connection to communicate with the service
You can host your own AWS PrivateLink powered service, known as an VPC endpoint service, and share it with other AWS customers. This requires a Network Load Balancer in the service VPC and and ENI on the customer VPC
The best way to expose a service VPC to tens, hundreds or thousands of customer VPCs
Establishes private connectivity between:
- VPC and supported AWS services
- VPC and services hosted by other AWS accounts
- VPC and supported AWS Marketplace services
-
VPC Endpoint Services
- Service Provider: create an Endpoint service. Create application in VPC and configure it as an AWS PrivateLink-powered service (referred to as an endpoint service)
- Consumers: create and Endpoint. Create a connection from their VPC to Provider endpoint service using an interface VPC endpoint or a Gateway Load Balancer endpoint, depending on the type of service
-
Security Groups
Virtual firewall for AWS resources (e.g. EC2 instance, RDS DB Instance, ...). By default everything is blocked
Stateful
If you send a request from your instance, the response traffic for that request is allowed to flow in regardless of the inbound SG rules
Responses to allowed inbound traffic are allowed to flow out, regardless of SG outbound rules
-
Default SG: your VPC includes a default security group. You can't delete default SG, however, you can change default SG's rules. Default rules:
- Allows inbound traffic from all resources that are assigned to this SG
- Allows all outbound traffic
-
VPN CloudHub
-
It operates over the public internet, but all traffic between the customer gateway and the AWS VPN Hub is encrypted
-
If you have multiple sites, each with its own VPN connection, you can use AWS CloudHub to connect those sites together.
A <--VPN--> VPC <--VPN--> B, site A communicates directly with site B through the VPC hosting the VPN CloudHub
-
Subnet
Subnet Types
Public subnet: The subnet has a direct route to an internet gateway. Resources in a public subnet can access the public internet.
Private subnet: The subnet does not have a direct route to an internet gateway. Resources in a private subnet require a NAT device to access the public internet.
VPN-only subnet: The subnet has a route to a Site-to-Site VPN connection through a virtual private gateway. The subnet does not have a route to an internet gateway.
-
Setting
Auto-assign IP settings: Enables you to configure the auto-assign IP settings to automatically request a public IPv4 or IPv6 address for a new network interface in this subnet
Resource-based Name (RBN) settings: Enables you to specify the hostname type for EC2 instances in this subnet and configure how DNS A and AAAA record queries are handled:
- Resource name -> Hostname based on Instance ID
- IP name -> Hostname based on private IP
Sizing
If you create more than one subnet in a VPC, the CIDR blocks of the subnets cannot overlap
5 IPs not available - the first four IP addresses and the last IP address in each subnet CIDR block are not available for your use, and they cannot be assigned to a resource. Example for subnet 10.0.0.0/24:
- 10.0.0.0: network address
- 10.0.0.1: reserved by AWS for VPC router
- 10.0.0.2: reserved by AWS for DNS
- 10.0.0.3: reserved by AWS for future use
- 10.0.0.255: network broadcast (AWS does not support broadcast in a VPC therefor this is reserved)
-
IPv6 sizing:
- The size of the IPv6 CIDR block is fixed (/56)
- The range of IPv6 addresses is automatically allocated from Amazon’s pool of IPv6 addresses (you cannot select the range yourself)
- The size of the IPv6 CIDR block is fixed (/64)
-
VPC Prefix List
- A collection of CIDR blocks that can be used to configure VPC Security Groups, VPC Route Tables, and AWS Transit Gateway route tables
- Can be shared with other AWS accounts using Resource Access Manager (RAM)
- Customer-managed prefix lists sets of IP address ranges that you define and manage. You can share your prefix list with other AWS accounts, enabling those accounts to reference the prefix list in their own resources
- AWS-managed prefix lists sets of IP address ranges for AWS services. You cannot create, modify, share, or delete an AWS-managed prefix list
- Prefix Lists are regional objects, so create them in the Region where you intend to use them
- Each Prefix List can either contain IPv4 or IPv6 entries, but not both
- When you create a Prefix List, you must specify the maximum number of entries that the Prefix List can support. You cannot modify the maximum number of entries later
Client VPN
- Connect from your computer using OpenVPN client to your private network in AWS and on-premises
- A Client VPN ENI is created in the subnet where you associate the Client VPN
- Source network address translation (SNAT) is then applied and source IP address is translated to the Client VPN ENI IP address
- Client VPN is compatible with VPC peering
- Client > Client VPN ENI (VPC-A) > VPC-B (peered)
- Access On-Premises resources through AWS with Client VPN
- Client > Client VPN ENI (VPC-A) > S2S VPN > On-Premise
- Internet Access
- Client > Client VPN ENI (public subnet) > IGW > Internet
- Client > Client VPN ENI (private subnet) > NAT Gateway (public subnet) > IGW > Internet
- Transit Gateway
- Client > Client VPN ENI (private subnet) > Transit Gateway > VPC(s)/DX/VPN
- Max 10Mbps per client connection
- Max 1 subnet per AZ
- Client CIDR cannot overlap to with CIDR of associated subnets (VPC and on-premise)
- Cannot change client CIDR after endpoint is created