Virtual Private Cloud (VPC) Basics Flashcards
VPC Subnets
Are what services run from, inside a VPCs, and then how you add structure, functionality and resilience to VPCs.
With AWS Diagrams:
-Blue = Private Subnets
-Green = Public Subnets
-Subnet start off, entirely Private, and they take some configuration to make them Public.
-Is AZ Resilient
-A subnetwork of a VPC - within a particular AZ = If that AZ fails, then the subnet itself, fails.
-1 Subnet => 1 AZ - 1 AZ => 0+Subnets = There can be many subnets within an AZ but there can’t be many AZs in a subnet.
-IPv4 CIDR is a subnet of the VPC CIDR
-Cannot overlap with other subnets
-Optional IPv6 CIDR (as long as this is enabled) (/64 subset of the /56 VPC - space for 256)
-Can by default, communicate with other subnets in the VPC
Subnet IP Addressing
-There are Reserved IP addresses (5 in total)
-10.16.16.0/20 (10.16.16.0 => 10.16.31.255)
-The first Network Address (10.16.16.0)
-“Network+1” (10.16.16.1) - Used by the VPC Router, a logical network device, which moves data between subnets, in & out of the VPC, if it’s configured to allow that.
-“Network+2” (10.16.16.2) - Reserved for DNS
-“Network+3” (10.16.16.3) - Reserved for future use
-Broadcast Address 10.16.31.255 (Last IP in Subnet)
If the subnet has 16 IPs in total, it means it only has 11 usable IPs.
-A VPC has a configuration object applied to it called “DHCP Options Set”
Dynamic Host Configuration Proccess (DHCP) = It’s how computing devices receive IPs automatically.
–It controls things like DNS service, NTP service, NetBIOS service and a few other.
-If you want to change the settings, you need to create a new one and then change the VPC allocation to this new one.
One every Subnet, you can also define 2 important IP allocation options:
-Auto Assign Public IPv4 = Controls if resources on a subnet, are allocated a public IPv4 address, in addition to their private subnet address automatically.
-Auto Assign IPv6 = Controls if resources on a subnet, are allocated a public IPv6 address. For that to work both the VPC and the Subnet need an allocation.
Both of these options are defined at a VPC level.
VPC Routing - VPC Router
-Is a high available device, present in EVERY VPC.
-It runs in every AZ - Highly available
-Has a network interface in every subnet in your VPC - “network+1” address.
-Routes traffic between subnets in the VPC.
-It’s controlled by “route tables” each subnet has one.
Routes tables that’s associated with a subnet, defines what the VPC Router will do, when data leaves that subnet.
-A VPC has a main route table - subnet default.
If you don’t associate a route table with a subnet, it uses the main table. (can only have 1)
A route table is just a list of routes.
When traffic leaves the subnet, the VPC Router views at the destination address of all IP packets. When it has that address, it looks at the route table, and identifies all the routes which match that destination address, and it does that by checking the destination field of a route.
–10.16.0.0/16 (What traffic do I match)
–Higher the prefix = Higher priority. (If multiple addresses match)
–“Local” means the destination is in the VPC. (Where to send)
For the exam:
-Route tables are attahced to 0 or more subnets
-A subnet has to have a route table. (main or custom)
-A route table controls what happens to data as it leaves the subnet/s, that the route table is associated with.
-local matches the VPC’s CIDR range.
Internet Gateway (IGW)
-Is a region resilient gateway attached to a VPC.
-A VPC can have 0 or 1 IGW, 1 IGW = 0 or 1 VPC.
-Runs from the border of the VPC in the AWS Public Zone.
-It’s what allows services inside the VPC, which are allocated with a Public IPv4 address/s or IPv6 address/s, to be reached from the Internet and to connect the AWS Public Zone or the Internet. (Gateways traffic between the VPC and the Internet or AWS Public Zone (S3..SQS..SNS..ect))
-It’s a managed gateway - AWS handles performance
Using an IGW
- Create IGW
- Attach IGW to VPC
- Create a custom Route Table
- Associate Route Table
- Add Default Routes to the Route Table, with the target IGW
- We configure the subnet to allocate IPv4 addresses and optionally IPv6, by default.
Then the subnet is classified as a “Public Subnet”. Any services inside that subnet, with public IP addresses, can communicate with the Internet, vice versa, and with the AWS Public Zone.
IPv4 Addresses with a IGW
IPv4 Instance »_space; IGW »_space; Linux Update Server
10.16.16.20 »_space; 10.16.16.20 > 43.250.192.20
»_space; 1.3.3.7
Packet
Source: 10.16.16.20
Destination: 1.3.3.7
»»» Source: 43.250.192.20 »_space;»» Arrives
Destination: 1.3.3.7
-An instance is not configured with a Public IPv4. **
-At NO POINT the O.S of the instance, is aware or the IPv4 address. (Just a private one)
-A record is created within the IGW, it links the instace Private IP to it’s allocated Public IP. **
-For IPv6 ALL addresses, that AWS uses, are natively publicly routable. (In this case the O.S of the instance knows)
Bastion Host / Jumpbox
-Bastion Host = Jumpbox
-Is an instance in a public subnet
-They use to allow incoming management connections arrive there.
-Then access internal VPC resource.
-Often the only way IN to a VPC.
-You can configure these, to only accepts connections from certain IP addresses, to authenticate with SSH or to integrate with on-premises identities servers.
-The ONLY entry point to a highly secure VPC.
Stateful vs Stateless Firewalls
-Every “Connection” has two parts - REQUEST (initiation) and RESPONSE **
How does this happens:
- The client picks a temporary (ephemeral) source port, 1024-65535. (Depends on OS)
- The client “Bob’s Laptop” initiates a connection to the Server on a well-known destination port HTTPS tcp/443.
Client Perspective = REQUEST is OUTBOUND
Sever Perspective = REQUEST is INBOUND
- The server responds using source port of tcp/443 and the destination ephemeral port picked by the client.
Stateless Firewalls
-You need 2 RULES (1 IN & 1 OUT) per connection. (Inbound application) (Outbound updates)
-For a Server, it needs 2 RULES per connection.
-The request component, It’s always going to be to a well-known port. If you are managing the firewall for the Server, you’ll need to allow connections to TCP port-443, the response it always uses a random ephemeral port.
Because the firewall it’s Stateless, it has no way of knowing, which specific port it’s used for the response. So you’ll often have to allow, the whole range of ephemeral ports to any destination.
Stateful Firewalls
-Is integillent enough to identify the REQUEST and RESPONSE components of a connection as being related.
-Only have to allow the REQUEST (INBOUND or OUTBOUND), means the RESPONSE (INBOUND or OUTBOUND) is automatically allowed.
-Stateful lowers the admin overhead.
Network Access Control Lists (NACLs)
Is a traditional firewall available inside AWS VPCs.
-They are Stateless, both the REQUEST and RESPONSE parts of every communication need individual rules = 1 x INBOUND & 1 x OUTBOUND.
-NACLs filter traffic crossing the SUBNET boundary INBOUND or OUTBOUND.
-Connections within a subnet aren’t impacted by NACLs
-NACLs contain rules grouped into INBOUND or OUTBOUND. (ENTERING or LEAVING the subnet)
-Rules match the DST IP/Range. DST port and Protocol and ALLOW or DENY based on that match.
-Rules are processed in ORDER, lowest rule number first. Once a match occurs, processing STOPS. Is an implicit DENY of nothing else matches.
-Rule-pairs (for example = app port & ephemeral) are needed on each NACL for each communcation type which occurs 1) within a VPC, 2) TO a VPC or 3) FROM a VPC.
When a VPC is created, it creates a Default NACL
-These contain INBOUND & OUTBOUND rules, which have the implicit deny (*) and an ALLOW ALL rule.
-The result - all traffic is ALLOWED, the NACL has no effect.
Custom NACL
-Can be created for a specific VPC and initially associated with NO subnets.
-They only have 1 INBOUND rule the implicit (*) DENY.
-They only have 1 OUTBOUND rule the implicit (*) DENY.
-The result - ALL traffic is DENIED.
KEY POINTS of NACLs
-STATELESS - REQUEST and RESPONSE seen as different.
-Only impacts data crossing subnet boundary
-NACLs can EXPLICITLY ALLOW and DENY.
-Only allow you to use IPs/CIDR, Ports & protocols - no logical resources. (NACLs are not aware of logical resources)
-NACLs cannot be assinged to AWS resources - ONLY SUBNETS.
-Use together with SG to add explicit DENY. (Bad IPs/Networks)
-Use SG to allow traffic and NACLs to deny traffic.
-Each subnet can have one NACL. (Default or Custom)
-A NACL can be associated with MANY Subnets.
Security Groups (SG)
These are the second type of security filtering feature commonly used in AWS.
-They are Stateful - detect response traffic automatically
-Allowed (IN or OUT) request = allowed response
-NO EXPLICIT DENY - only ALLOW or implicit DENY (If you don’t explicitly allow traffic, you are implicitly denying it)
-Can’t be used to block specific “bad actors”.
-It supports IP/CIDR rules and referring logical resources. These includes other SG and ITSELF.
-SG are not attached to instances, they are attached to specific Elastic Network Interfaces. (ENI’s) (Even if the UI shows it this way)
-SG is associated with the primary ENI of the instance.
-Applies to all traffic entering or leaving the ENI.
-An allow rule (IN tcp/443) cannot be overridden.
(SG) Logical References
SG are capable of reffering to Logical Resources.
-We could allow another SG to entering another SG.
-An SG reference applies to anything which has the SG attached.
This means we don’t have to worry about IP’s/CIDR, and it also scales very well.
-Any new instances which use the “webSG” are allowed to communicate with any instances using the “appSG”.
(SG) Self References
Within an SG, an “SG source” is the same as “anything with the SG attached”. Using a “self reference” means “anything with this SG attached”.
-This scales with ADDS and REMOVES from the SG.
-Any IP changes are automatically handled.
-Allows for simplify management of any Intra app communication (MS Domain Controller or App HA)
Network Address Translation (NAT) & NAT Gateway (NATGW)
NAT a process of giving a private resource, outgoing only access to the Internet.
NAT Gateway is the AWS implementation available in a VPC.
What is NAT?
-Is a set of different processes which can adjust IP packets by changing their SRC or DST IPs.
-IP masquerading - hides a whole private CIDR IP Block behind one IP.
-Public IPv4 Addresses running out.
-Gives Private CIDR range OUTGOING only Internet access. (not INCOMING)
NAT Architecture
-NAT Gateways are located in the AWS Public Zone.
When instances are sending any data to any IP addresses, that don’t belong inside the VPC, by default, this default route will be used and that traffic will get sent to the NAT Gateway.
-If you need to give an instance, it’s own public IPv4 address, then only use the Internet Gateway.
-If you need to give private instances, public access to the Internet and the AWS Public Zone services, then you need both the NAT Gateway (many to one translation) & the Internet Gateway (IP of the NATGW to a public IP).
KEY POINTS of NAT Gateways
-Runs from a public subnet.
-Uses Elastic IPs (Static IPv4 Public) - They don’t change, and they are allocated to your account in a Region, where they can be used for whatever you want until you deallocate them.
-AZ resilient service (HA in that AZ)
-For Region resilience - you need to deploy a NATGW in each AZ.
-Then have a RT in for each AZ with that NATGW as target.
-Managed, scales to 45 Gbps, $ Duration (Hourly) & Data Volume.
Nat Instances
You launch a NAT instance in a public subnet to enable instances in the private subnet to initiate outbound IPv4 traffic to the internet or other AWS services, but prevent the instances from receiving inbound traffic initiated on the internet.
So if an instance is running as a Nat Instance, then it will be receiving some data, which the source address will be of other resources in that VPC, and the destination will be a host on the internet. It will need to be the source nor destination, so by default, that traffic would be dropped.
-If you need to allow that instance to function as a Nat Instance, then you need to disable “Source/Destination Checks”. **
Each EC2 instance performs source/destination checks by default. This means that the instance must be the source or destination of any traffic it sends or receives. However, a NAT instance must be able to send and receive traffic when the source or destination is not itself.
Why would you use a Nat Instances, instead of a NAT Gateway?
-If you value availability, bandwidth, low level of maintenance and high performance, use NAT Gateways.
–Offers high-end performance, it scales, it can be custom designed and perform network address translation.
–Nat Instances is limited by the capability of the instance that is running on, and that instance is often “General Purpose”.
-A Nat Instance is a single instance running in a single AZ, it will fail, if the EC2 hardware fails. (Less availability)
-If cost is your primarily choice, or if the VPC that you are deploying services into, is just a test-VPC, then the Nat Instance can be cheaper, with high volume of data.
-A NAT Gateway is also not “Free-tier” elegible.
-Nat Instances are just EC2 - SG are not compatible with them, so you can only use NACLs with them.
What about IPv6? (NAT)
-NAT isn’t required for IPv6.
-All IPv6 address in AWS are publicly routable.
-The Internet Gateway works with ALL IPv6 IPs directly
-NAT Gateways don’t work with IPv6.
-::/0 Route + IGW for bi-directional connectivity.
-::/0 Route + Egress-Only Internet Gateway - Outbound Only
