AWS VPC and Subnet Facts To Prepare for AWS Solutions Architect Associate Certification 2018

AWS VPC and Subnet Facts To Prepare for AWS Solutions Architect Associate Certification 2018 – also including subnet, security group, network access control list, and routing table facts.

VPC stands for Virtual Private Cloud

You may have up to 5 VPCs per region – call AWS Support for more

Each region gets a default VPC defined (whether you are using that region or not) – with the IP4 CIDR block- 172.31.0.0/16.  This will cause a potential problem if you use objects in more than one default VPC two  across multiple regions as all regions that use the default VPC CIDR block (again that is 172.31.0.0/16) – at least in the sense that the IP address ranges will overlap.  If this is an issue create your own custom VPC – more work but more control.

All subnets in the a default VPC have a route out to the internet via IGW / an internet gateway object – a highly redundant robust object that routes to the world outside AWS.  All subnets in a default VPC are public.

In Amazon VPC, an EC2 instance retains its private IP and private DNS through stop & start cycles – public IP and DNS is assigned new on a stop / start.  Reboots there is no change – keeps private and public IP.

A subnet cannot span more than one availability zone. 

You can have many subnets per availability zone (e.g. one private, one public – with a internet gateway / IGW is quite common)

Minimum CIDR /28 – which is 16 IP addresses per subnet – 11 available to you

Maximum CIDR / 16 – which is 65,536 IP addresses per subnet

AWS always uses 5 IP addresses per subnet no matter what your CIDR size is (the first four .0,.1,.2,.3 and last one .255) – so subtract 5 and that is what is the number of IPs available to your subnet.  .0 is the network address – used by AWS – .1 is the gateway address – used by AWS – 2. is the DNS address used by AWS – .255 is the broadcast address used by AWS – and .3 is just reserved.

A subnet can be associated with one and only one Network Access Control List (NACL)

A public subnet has an Internet GateWay (IGW) in it’s route table which allows traffic into and or out to the internet and yes if you are creating a VPC manually from scratch, you have to add the IGW to the public subnets route table manually and pick your IP restrictions.

You can only have ONE IGW per VPC – up to 5 IGWs per region (implying 5 VPCs in the case of 5 IGWs) – if you need more than that call AWS Support

IGWs belong to VPCs – not availability zones or subnets.

Diagram of typical AWS networking for a Client that uses both the public internet on AWS and a VPN Gateway to AWS.

http://cidr.xyz  has a CIDR calculator

Security Groups are defined within a VPC and a given Security Group cannot span VPCs – in other words, you can say the domain or owner of a security group is a VPC

A Security Group is a stateful virtual firewall – again defined within VPCs – stateful just means if traffic is allowed into it – is also allowed out or vice versa without explicitly defining outbound info.

Security Groups – ALLOW only – no denys – deny is the default.  Security groups are stateful, if you allow an inbound, the outbound is allowed as well without an explicit definition.

Security groups apply to network interfaces, not to IP addresses. Therefore, IP addresses are subject to the security group of the network interface in which they’re specified

Network Access Control Lists / NACL – apply to subnets – and are stateless (if you allow an inbound rule you still have to create an outbound explicitly) – they can allow and deny

Remember that subnets use Network Access Control Lists to control network traffic entering and leaving the subnet.  EC2 instances use Security Groups to control network traffic entering and leaving an instance

What is the order of evaluation for NACLs and Security Groups?  From what I hear and I have not extensively tested this – you can.

  • if its inbound traffic: Network ACLs are evaluated before Security Groups
  • if its outbound traffic: Security Groups are evaluated before Network ACLs
  • because NACLs only come into play when accessing a subnet – if the access never leaves the subnet only a security group would be evaluated
  • once an allow or deny is identified at either level the other level of security is not used

A subnet can only be associated to ONE Network ACL / Access Control List – but – a Network ACL can be associated with more than one subnet

For a Network ACL – there is a limit of 20 rules per NACL – remember that deny rule numbers should be less then the first allow rule number – if you put them in the opposite order the deny can over-ride the allow

Each EC2 instance launched is connected to only one subnet

When you create a VPC a default Network ACL is also automatically created by AWS that allows all inbound and outbound traffic.  If you define a subnet without a Network ACL – the default VPN NACL will be assigned.  When you assign a Network ACL to a subnet, any previous NACL will be removed for you – in other words – one NACL per subnet.  If you create your own NACL, everything is denied by default and you have to explicitly add rules like allow and specific denies.

Network ACLs are processed by rule number from low to high (one or more rules per NACL) and per Amazon – “Rules are evaluated starting with the lowest numbered rule. As soon as a rule matches traffic, it’s applied (and searching stops – my words) regardless of any higher-numbered rule that may contradict it”.  So if there was a higher number rule that denied access, after an earlier rule allowed it in a NACL, the earlier rule prevails.

VPCs can be peered but there is no transitive peering.

Until recently you could not VPC peer across regions.  Now you can as of just recently.  Which leads me to my latest pet peeve.  If you create resources in two or more regions and you use a default VPC – the default is (at least for US-West regions) an overlapping CIDR block.  One of the big rules is you cannot peer VPCs that have overlapping IP addresses / CIDR blocks.  This happened to me, opened a support case fortunately on of the VPCs was a small Dev env.  I had to drop the resources connected to the VPC, then drop the VPC, and created a new VPC manually.  The support Rep seemed to think that you could not over-ride the CIDR on a default VPC – I’m still researching.

If you create a VPC manually – not using the wizard then

  • a default route table is created for you

  • a default security group is created for you

  • a default Network Access Control List (NACL) is created for you

  • subnets are NOT created when creating a VPC manually

EC2 instances in a private subnet must use NAT to gain stateful outbound access to the internet

For EC2 instances in a private subnet that use NAT Instances (old style versus new NAT Gateway) – when you create your NAT instance – make sure you UNCHECK – source destination check

NAT Instances are still useful as “jump servers” or bastion servers to allow SSH or RDP access to a hosts (e.g. EC2) in a private subnet

Create NAT Instances in a public subnet – and an entry must be put into the default route table pointing to it – to allow it to be used

When using NAT Gateways – define one per availability zone – with an entries in the default route table for the VPC

To block IP addresses, use Network ACLs – not Security Groups – NACLs can deny and allow – Security Groups can only allow

Ephemeral ports should be opened on NACL outbound rules

A DHCP option set is created by default for each VPC

Dynamic Host Configuration Protocol (DHCP) provides a standard for passing configuration information to hosts on a TCP/IP network.

When you create a DHCP option set you specify at least one of the following configuration parameters: Domain name, Domain name servers, NTP servers, NetBIOS name servers, NetBIOS node type.

More from LonzoDB on AWS

Leave a Comment

Scroll to Top