Well, the other day I happened to not pass this test, my experience with it is here in case you haven’t had a read yet. I’m going to list my study notes here while hoping readers understand I didn’t pass because I lack real world experience with migrations from on-prem to AWS and extending datacenters to AWS. If someone can combine this experience and their study, plus couple it up with my notes, I reckon you’re on to a winner. Without further ado, here’s part 1 which is about AWS’ Virtual Private Cloud. This is the longest post in this series. Here’s the entire listing:
Virtual Private Cloud – overview
- Multiple VPC within a region, all can have the same IP address range (think bubble networks, akin to those cordoned off networks SRM creates for testing failover, remember?!).
- The primary IPv4 CIDR cannot be removed/deleted. A VPC must have at least 1 such address block.
- An internet gateway of some sort is required to connect a VPC out to the internet.
- When a new EC2 instance is launched in a VPC, it won’t get a public IP addresss by default if it’s assigned to a non-default subnet. Blow away the instance (retain the disks). Launch a new instance, attach the same volumes the previous instance had and ensure it gets a public IP address.
- An EC2 instance operates in dual stack mode (IPv4 and v6 at the same time).
- All AWS accounts have a default VPC created. The assigned CIDR block range is always 172.31.0.0/16. This subnet will not have IPv6 enabled (probably for simplicity or something?).
- Any VPC cannot be given a user-chosen IPv6 address range. AWS do this on their own.
- A VPC spans multiple AZs in a region but a subnet resides within an AZ.
- First four and last IP in a subnet are reserved for use by the AWS system.
- A subnet needs an attached internet gateway to be called a public subnet. The NAT gateway must also sit in a public subnet otherwise it won’t be able to hit the outside world.
- There’s something called a “main” route table, the one that’s there by default and can be modified. It’s assigned to all subnets that don’t have a explicit route table provided.
- Routes that need to be added to a route table cannot be smaller than the local route. There’s a local route per route table.
- Routing is evaluated separately for IPv4 and v6.
- If IPv4 initially configured, then IPv6 required later, needs to be enabled at both the subnet and VPC that require IPv6 going.
- Elastic IP addresses are static IP addresses pulled from a pool AWS maintain and put back into the pool when the EC2 instance has been terminated.
- The first IP address assigned to an EC2 instance by AWS is not an elastic IP.
- EIPs are allocated to an account and remain allocated even after the EC2 instance has been deleted. First EIP is free, subsequent and unused ones are charged.
- How to assign an EIP? – Get one for a VPC and then able to assign it.
- EIPs are REGION SPECIFIC AND ACCOUNT SPECIFIC. So they cannot be assigned to an instance in a VPC in different region.
- 1:1 mapping between an EIP and private IPv4 address.
- IPv6 has a link local address and a global unicast address. LLA is from the fe80::10 address range used for things like DHCP v6 and Neighbour Discovery Protocol (like ARP). The LLA is useful for the VPC it resides in, not out of it. To get packet processing going and reach the internet, the GUA is required.
- A non-default VPC will not have connectivity to any networks outside of it. A new EC2 instance wont be reachable from the internet either. Create an internet gateway so traffic has a way to go in and out. Then add a route in getting traffic from the subnet the VPC is associated with (the destination being 0.0.0.0/0 that’s if unrestricted access is required and the target being the internet gateway).
- Max MTU is 1500. Be aware of tricky questions around MTUs and enhanced networking.
- Stateful virtual firewall. All outbound traffic is allowed, all inbound’s blocked. All resources within the group talk freely.
- Cannot put in any deny rules, that’s done by the NACLs.
- Rules need to be added for inbound traffic, otherwise nothing is let in.
- Instances using the same security group wont be talking to each other automatically. A rule will need to be added to get the group talking to itself. Same applies to instances within a subnet, won’t talk unless rule’s added.
- Changes made to these groups are immediate. Groups don’t go across regions (at the time of this writing).
- Once a group has been associated with a VPC, the association cannot be changed or allocated to another security group.
- Gotta remember these things dont work across regions.
- Another level of security at the subnet level, complementary to security groups. Think of this as subnet level filtering.
- Ordered list of rules, starts with the lowest numbered first.
- Final deny rule always there and cannot be changed.
- A custom NACL starts off with deny all all (inbound and outbound).
- The default NACL starts off with allow all all (inbound and outbound).
- Every subnet is associated with a NACL automatically.
Differences NACL and Security Groups
- Groups are the NIC level, NACLs at the subnet level.
- Groups have allow rules only, NACL do both denies and allows.
- Groups are stateful, NACLs are stateless.
- Groups are all evaluated to see if traffic is allowed where as NACLs are like traditional firewall rules (eval’d one after the other).
- Just a NAT translator that translates a private IP to a public IP address associated with the NAT instance (works with IPv6 too, the machine will need a IPv6 GUA).
- Having this on its own isn’t enough, requires a route for the subnet that needs internet connectivity.
- Gateways provide better availability, bandwidth and lower admin effort.
- Gateways can do upto 45 Gbps while instances depend on the initial config chosen.
- Actually perform many-to-one IPv4 translation – PAT.
- Either’s not supported for IPv6 (since IPv6 is meant for end-to-end connectivity).
- A NAT gateway is highly available within an availability zone.
- Source/destination check must be disabled on the NAT instance (since this is a VM) as without it, and normally too, a machine expects itself to the sender/receiver of traffic it transmits.
Egress-only Internet Gateways
- Meant for machines using IPv6.
- Does a similar thing as a NAT instance/gateway, but doesn’t do any translation of IP addresses, IPv6 is meant to be visible end to end.
VGW, Customer Gateways and VPN
- Makes the AWS setup an extension of the on-premises datacenter.
- The VGW is a logical construct in the VPC providing edge routing for AWS managed VPN connections and AWS Direct Connect.
- NOT the same as route tables.
- The VGW is a next hop router on the AWS side of the VPN tunnel. This talks BGP only, can let AWS assign it or custom. Gotta remember one VGW can hook up with multiple Customer Gateways.
- The Customer Gateway is on the customer side of the VPN connection. This consists of a name, an IP address and an ASN. The IP address MUST be static, routable and can be located behind a NAT gateway/instance (usually is, apparently)
- The VPN tunnel contains information about the above constructs. For the tunnel to be brought up, the connection must be initiated by the customer gateway.
- When the VPN is being setup, the wizard allows for certain routes to be advertised to the VPC. If BGP, then use route filtering on the corporate router to control what’s advertised to the VPC.
- If static routing only, then only those routes are advertised up.
- Finally, a machine in the VPC running any VPN software will be required to get the VPN going. Charges apply the moment the VPN connection is setup, not when the connection is established (probably because stuff is ready to use). This machine must have the Source/destination check disabled.
- The AWS version of VPN runs IPsec only, if GRE or some other encapsulation is required, the software can be purchased from AWS’ marketplace.
- Two IPSec tunnels for the VPN for HA. If BGP cannot be used, software must be chosen from the AWS marketplace.
- When a subnet doesn’t have a route added to it for the IGW/EIGW but has one for the VGW, it’s called a VPN-only subnet.
- The VPN tunnel does NOT come up unless a connection is initiated < Important!
- This thing allows a VPC to connect, privately, with:
- A stock AWS service (S3, SNS, SQS whatever).
- An AWS Marketplace service that the account has been subscribed to.
- With the Gateway Endpoint a routing entry is added to specifically allow a subnet to get to the service. The destination is a pl-*** type entry for the AWS service with the target being the VPC endpoint. MUST have a proxy to get access from an external network (an EC2 instance with the source/destination check disabled).
- With the interface endpoint, DNS names and an Elastic Network Interface are used along with security group to provided an entry point to the AWS service over Private Link link to the created network interfaces. Accessed over Direct Connect only, not VPC peering or VPN. Great for granular access since IAM can be used within security group (reckon that’s a good test tip).
- Two types of endpoints – gateway (only two S3, DynamoDB). The rest are all interfaces.
- TCP only. Ipv4 only. Important to remember traffic never leaves the AWS network.
- Pose no availability/scaling/bandwidth constraints (this could be an exam tip too if they ask about using a device for easy and rapid scale).
- Require DNS resolution enabled on the VPC (not just the VPC, but the subnet too).
- Connections originating from the VPN or Direct Connect cannot directly access these endpoints (this is because transitive routing isn’t allowed). The way around this is to configure a proxy which is able to direct traffic from a network to the endpoint.
- Much more granular to implement an RBAC model with endpoints than with peering since endpoints have policies which control access (plus use S3 bucket policies).
- VPC to VPC connectivity. Requires route table entries.
- No transitive routing.
- One VPC can have multiple VPC peerings going at the same time (think hub and spoke).
- CIDR blocks must be non-overlapping.
- ** Hostname resolution MUST be enabled for machines within the same region to receive private IPv4 **.
- Across regions the traffic is encrypted, within it isn’t since it won’t go over the WAN. Within regions, IPv6 is supported, as are jumbo frames.
- Better to use VPC endpoints for to restrict only various applications to talk to each other.
- Can be used to hook up VPCs across AWS accounts too (and across regions).
- This thing is all or nothing permissions with the need to lock down after the connection has been established.
- An IP address that can be given to any EC2 instance.
- Only available within a VPC (the scope of an EIP is the AZ it’s in).
- Current public IP address is released if an instance gets a new EIP.
- Can be associated with an instance if it’s already allocated to another one.
- Only incur costs if they’re actually used.
- Use a secondary network interface if an EC2 instance needs to talk to both public and private subnets.
- ** Thing to note is the primary network card of an EC2 instance cannot be removed **
- Can be hot/warm/cold added.
- Autoscaling groups cannot have multiple EIPs (if required, do after launch).
DHCP Options Sets
- Every VPC will get assigned to the default DHCP Options Set unless assigned manually.
- Contains name tags, domain name, DNS, netbios name servers, NTP server.
- Once created cannot be edited, only deleted.
- Good way to get EC2 instances be able to resolve names of objects living in an on-prem location.
VPC Flow Logs
- Captures IP traffic flow, stored in Amazon CloudWatch logs.
- Can be enabled at the VPC, subnet or NIC level.
- Published every 10 mins.
Private Link (private access, as the name indicates, flows over the AWS network)
- Gets the VPC hooked up with interface endpoints that AWS provides.
- Also allows for the building of custom endpoint services.
- Used for making services in VPC available to OTHER accounts and services.
- Other accounts and services can also create interface endpoint to access custom services.
- Requires an NLB pre-created.
- UNI-DIRECTIONAL (I didn’t know/think of this).
- A tech that allows a VGW on one VPC to advertise routes to the VPN/Direct Connect peers it is connected to.
- Apparently, this behaviour of the VGW cannot be altered. Not sure why this is even a topic on its own.
- Helpful in sort of disguising the source IP address. By placing an AWS proxy (which is an EC2 instance) in the path of the traffic, the receiving VPN peer will think it’s not from an external network. Don’t understand this fully yet. ** (Not sure of security implication here either)
- As expected this will require the disabling of the source/destintion check on the EC2 instance.
- IF traffic being forwarded on requires to be inspected first, the inspecting machine must be in the same VPC. This traffic cannot be inpsected by a firewall in another VPC by default. There are apparently some advanced routing strategies that need to be learned
IP redesign for a VPC
- Choose a large CIDR block to begin with.
- Upto 5 additional CIDR v4 blocks can be assigned. > 5 requires AWS approval.
- The new block wizard wont allow any blocks that overlap or already taken (this is obvious otherwise traffic wouldn’t exactly end up where intended).
We’re onto Part 2 next, which is about Direct Connect and a bit more about VPNs.