Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Virtual Private Cloud (VPC) section #17

Open
wants to merge 8 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
147 changes: 77 additions & 70 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -1689,7 +1689,7 @@ Dotted decimal notation for human readability.

There are just over 4 billion addresses.
This was not very flexible because it was either too small or large for
some corporations. Some IP addresses was always left unused.
some corporations. Some IP addresses were always left unused.

#### 1.5.1.2. Classful Addressing

Expand Down Expand Up @@ -1748,8 +1748,8 @@ Contains:

TCP and UDP are protocols built on top of IP.

- TCPIP means TCP running with IP
- UDPIP means UDP running with IP
- TCP/IP means TCP running with IP
- UDP/IP means UDP running with IP

TCP/UDP Segment has a source and destination port number.
This allows devices to have multiple conversations at the same time.
Expand Down Expand Up @@ -1788,11 +1788,11 @@ VPC Consideration
- Are there any networks we can't use?
- Be mindful of ranges other VPCs use or are used in other cloud environments
- Try to predict the future uses.
- VPC structure with tiers and resilience (availability) zones
- VPC structure with tiers and resilience (availability zones)
- VPC min /28 network (16 IP)
- VPC max /16 (65456 IP)
- VPC max /16 network (65456 IP)
- Avoid common range 10.0 or 10.1, include up to 10.10
- Suggest starting of 10.16 for a nice clean base 2 number.
- Suggest starting from 10.16

Reserve 2+ network ranges per region being used per account.
Think of the highest region you will operate in and add extra as a buffer.
Expand All @@ -1809,31 +1809,32 @@ An example using 4 AWS accounts.

A subnet is located in one availability zone.
Try to split each subnet into tiers (web, application, db, spare).
Since each Region has at least 3 AZ's, it is a good practice to start
Since each Region has at least 3 AZs, it is a good practice to start
splitting the network into 4 different AZs.
This allows for at least one subnet in each AZ, and one spare.
Taking a /16 subnet and splitting it 16 ways will make each a /20.

### 1.5.3. Custom VPC

- Regional Isolated and Resilient Service.
- Operates from all AZs in that region
- It is created in a region and operates from all AZs in that region
- Allows isolated networks inside AWS.
- Nothing IN or OUT of a VPC without explicit configuration.
- Nothing is allowed IN or OUT of a VPC without explicit configuration.
- Isolated blast radius. Any problems are limited to that VPC or anything
connected to it.
- Flexible configuration
- Hybrid networking to allow connection to other cloud or on-prem networking.
- Default or Dedicated Tenancy. This refers to how the hardware is configured.
- Default allows on a per resource decision later on.
- Dedicated locks any resourced created in that VPC to be on dedicated
- Default or Dedicated Tenancy. This controls whether the resources created
inside the VPC are provisioned on shared or dedicated hardware.
- Default allows to change tenancy on a per-resource basis later on.
- Dedicated locks any resources created in that VPC to be on dedicated
hardware which comes at a cost premium.

#### 1.5.3.1. Custom VPC Facts

IPv4 private and public IPs

- Allocated 1 mandatory private IPv4 CIDR blocks
- VPCs are allocated 1 mandatory private IPv4 CIDR blocks
- Min /28 prefix (16 IP)
- Max /16 prefix (65,536 IP)
- Can add secondary IPv4 Blocks after creation.
Expand All @@ -1845,7 +1846,7 @@ Single assigned IPv6 /56 CIDR block

- Still being matured, not everything works the same as IPv4.
- With increasing use of IPv6, this should be added as a default
- Range is either allocated by AWS as in you have no choice on which range
- Range is either allocated by AWS, which means you have no choice on which range
to use, or you can select to use your own IPv6 addresses which you own.
- IPv6 does not have private addresses, they are all routed as public by
default.
Expand All @@ -1858,12 +1859,12 @@ If the VPC is `10.0.0.0` then the DNS IP will be `10.0.0.2`
Two options that manage how DNS works in a VPC:

- Edit DNS hostnames
- If true, instances with public IPs in a VPC are given public DNS hostnames.
- If false, this is not available.
- If enabled, instances with public IPs in a VPC are given public DNS hostnames.
- If not enabled, this is not available.

- Edit DNS resolution
- If true, instances in the VPC can use the DNS IP address.
- If false, this is not available.
- If enabled, instances in the VPC can use the DNS IP address.
- If not enabled, this is not available.

### 1.5.4. VPC Subnets

Expand Down Expand Up @@ -1932,23 +1933,23 @@ associated at a time, but a route table can be associated by many subnets.
When traffic leaves the subnet that this route table is associated with, the
VPC router reviews the IP packets looking for the destination address.
The traffic will try to match the route against the route table. If there
are more than one routes found as a match, the prefix is used as a priority.
are more than one route found as a match, the prefix is used as a priority.
The higher the prefix, the more specific the route, thus higher priority.
If the target says local, that means the destination is in the VPC itself.
Local route can never be updated, they're always present and the local route
Local routes can never be updated, they're always present and they
always takes priority. This is the exception to the prefix rule.

#### 1.5.5.2. Internet Gateway

A managed service that allows gateway traffic between the VPC and the internet
or AWS Public Zones (S3, SQS, SNS, etc.)
or AWS Public Zones (S3, SQS, SNS, etc).

- Regional resilient gateway attached to a VPC.
- One IGW will cover all AZ's in a region the VPC is using.
- A VPC can have either:
- No IGW and be entirely private.
- One IGW
- IGW can be created and attached to no VPC.
- IGW can be created and attached to no VPC or just 1.
- Runs from within the AWS public zone.

#### 1.5.5.3. Using IGW
Expand All @@ -1964,7 +1965,7 @@ to the public IP. This is why when an EC2 instance is created it only
sees the private IP address. This is IMPORTANT. For IPv4 it is not configured
in the OS with the public address.

When the linux instance wants to communicate with the linux update service,
When a linux instance wants to communicate with a linux update server,
it makes a packet of data.
The packet has a source address of the EC2 instance and a destination address
of the linux update server. At this point the packet is not configured with
Expand All @@ -1973,15 +1974,15 @@ any public addressing and could not reach the linux update server.
The packet arrives at the internet gateway.

The IGW sees this is from the EC2 instance and analyzes the source IP address.
It changes the packet source IP address from the linux EC2 server and puts
on the public IP address that is routed from that instance. The IGW then
It changes the packet source IP address from the linux EC2 server to the public
IP address that is allocated to that instance. The IGW then
pushes that packet on the public internet.

On the return, the inverse happens. As far as it is concerned, it does not know
about the private address and instead uses the instance's public IP address.
When returning, the inverse happens. As far as the update server is concerned, it does
not know about the private address and instead uses the instance's public IP address.

If the instance uses an IPv6 address, that public address is good to go. The IGW
does not translate the packet and only pushes it to a gateway.
does not translate the packet and only pushes it to the internet server.

#### 1.5.5.4. Bastion Host / Jumpbox

Expand All @@ -2004,19 +2005,17 @@ by default.
NACLs are used when traffic enters or leaves a subnet.
Since they are attached to a subnet and not a resource, they only filter
data as it crosses in or out.
If two EC2 instances in a VPC communicate, the NACL does nothing because
If two EC2 instances in the same subnet communicate, the NACL does nothing because
it is not involved.

NACLs have an inbound and outbound sets of rules.
NACLs have two set of rules: inbound and outbound.

When a specific rule set has been called, the one with the lowest
rule number first.
As soon as one rule is matched, the processing stops for
that particular piece of traffic.
Rules are processed in order and that processing starts with the lowest rule number.
As soon as one rule is matched, the processing stops for that particular piece of traffic.

The action can be for the traffic to **allow** or **deny** the traffic.
The action on a particular NACL rule can be to explicitly **allow** or **deny** the traffic.

Each rule has the following fields related to traffic
Each rule has the following fields related to traffic:

- type
- protocol: tcp, udp, or icmp
Expand All @@ -2031,68 +2030,70 @@ Examples:
- https: tcp port 443
- ping traffic: icmp

If all of those fields match, then the first rule will either allow or deny.
If all of those fields match, then the first rule will either allow or deny the traffic.

The rule at the bottom with `*` is the **implicit deny**
The rule at the bottom with `*` is the **implicit deny**.
This cannot be edited and is defaulted on each rule list.
If no other rules match the traffic being evaluated, it will be denied.

#### 1.5.6.1. NACLs example below

- Bob wants to view a blog using https(tcp/443)
- We need a NACL rule to allow TCP on port 443.
- All IP communication has two parts
- All IP communication has two parts:
- Initiation
- Response
- Bob is initiating a connection to the server to ask for a webpage
- Server will respond with an **Ephemeral** port
- Bob talks to the webserver connecting to a port on that server (tcp/443)
- This is a well known port number
- Bob's PC tells the server it can talk to back to Bob on a specific port
- Wide range from port 1024, 65535
- Bob's PC tells the server it can talk back to him on a specific port,
an **ephemeral** port
- It could be any port between 1024 and 65535
- That response is outbound traffic
- When using NACLs, you must add an outbound port for the response traffic
as well as the inbound port. This is the ephemeral port.
- If the webserver is not managing the apps server, it may communicate
back on a different port.
- This back and forth communication can be hard to configure for.
- If there is an app subnet that contains the application apart from the webserver
Bob is communicating with, the webserver also have to initiate communication with the
app server. This back and forth communication can be hard to manage.

#### 1.5.6.2. NACL Exam PowerUp

- NACLs are stateless
- Initiation and response traffic are separate streams requiring two rules.
- Initiation and response traffic are separate streams requiring two rule sets.
- NACLs are attached to subnets and only filter data as it crosses the
subnet boundary. Two EC2 instances in the same subnet will not check against
the NACLs when moving data.
- Can explicitly allow and deny traffic. If you need to block one particular
thing, you need to use NACLs.
- They only see IPs, ports, protocols, and other network connections.
No logical resources can be changed with them.
They do not have any visibility of AWS logical resources.
- NACLs cannot be assigned to specific AWS resources.
- NACLs can be used with security groups to add explicit deny (Bad IPs/nets)
- One subnet can only be assigned to one NACL at a time.
- You can associate a NACL with multiple subnets but one subnet can only be
associated with one NACL at a time.

NACLs are processed in order starting at the lowest rule number until
NACLs are processed in order starting with the lowest rule number until
it gets to the catch all. A rule with a lower rule number will be processed
before another rule with a higher rule number.

### 1.5.7. Security Groups

- SGs are boundaries which can filter traffic.
- Attached to a resource and not a subnet.
- Attached to a resource and not a subnet, specifically to a network interface of an
AWS product.
- SGs have two sets of rules like NACLs.
- SGs are stateful.
- Only one inbound rule is needed.
- They see traffic and response as the same thing.
- Understand AWS logical resources so they're not limit to IP traffic only.
- They see initiating traffic and the response as part of the same communication.
- Understand AWS logical resources so they're not limited to IP traffic only.
- Can have a source and destination referencing the instance and not the IP.
- Default SG is created in a VPC to allow all traffic.
- Does so by referencing itself. Anything this SG is attached to is matched
by this rule.
- SGs have a hidden implicit **Deny**.
- SGs have a hidden implicit **Deny** and can explicitly allow.
- Anything that is not allowed in the rule set for the SG is implicitly denied.
- SG cannot explicit deny anything.
- NACLs are used in conjunction with SGs to do explicit denys.
- SG cannot explicitly deny anything.
- NACLs are used in conjunction with SGs to do explicit denies.

#### 1.5.7.1. SGs vs NACL

Expand All @@ -2104,7 +2105,7 @@ that boundary. If the resource is in the same subnet, it will not do anything.

### 1.5.8. Network Address Translation (NAT) Gateway

Set of different processes that can address IP packets by changing
Set of different processes that can adjust IP packets by changing
their source or destination addresses.

**IP masquerading**, hides CIDR block behind one IP. This allows many IPv4
Expand All @@ -2113,29 +2114,35 @@ Incoming connections don't work. Outgoing connections can get a response
returned.

- Must run from a public subnet to allow for public IP address.
- Internet Gateway subnets configure to allocate public IPv4 addresses
- Internet Gateway subnets are configured to allocate public IPv4 addresses
and default routes for those subnets pointing at the IGW.
- Uses Elastic IPs (Static IPv4 Public)
- Don't change
- Allocated to your account
- AZ resilient service , but HA in that AZ.
- AZ resilient service. HA only in that AZ.
- If that AZ fails, there is no recovery.
- For a fully region resilient service, you must deploy one NATGW in each AZ
with a Route Table in each AZ with NATGW as target.
- Managed service, scales up to 45 Gbps in terms of bandwidth. Can deploy multiple NATGW
to increase bandwidth.
- AWS charges on the number of NAT Gateways used, usage per hour and data volume processed.

#### 1.5.8.1. NAT Gateway vs NAT Instance

- NAT instance is limited by capabilities of the instance it is running on and that instance is also general purpose, so won't offer the same level of custom design performance as NAT Gateway.
- NAT instance is single instance running in single AZ it'll fail if EC2 hardware fails, network fails, storage fails or AZ itself fails.
- NAT Gateway has benefit over NAT instance, inside one AZ it is highly available.
- You can connect to NAT instance just like any other instance, you can use them as Bastion host or can use them for port forwarding.
- With NAT Gateway it is not possible, it is managed service. NAT Gateway cannot be used as Bastion host and it cannot do port forwarding.
- You cannot use SG with NAT instance, you can only use NACLs.
- NAT is not required for IPv6. Inside AWS all IPv6 addresses are publicly routable. IG works with all IPv6 addresses directly.
- That means if you choose to make an instance in private subnet that have a default IPv6 route to IG, it'll become public instance.
- Managed service, scales up to 45 Gbps. Can deploy multiple NATGW to increase
bandwidth.
- AWS charges on usage per hour and data volume processed.
- NAT instance is a single instance running in a single AZ. It'll fail if EC2 hardware fails, network fails, storage fails or AZ itself fails.
- NAT Gateway has benefit over NAT instance in that inside one AZ it is highly available.
- You can connect to a NAT instance just like any other instance, you can use them as Bastion host or can use them for port forwarding.
- It is not possible to connect to a NAT Gateway since it is a managed service.
It cannot be used as Bastion host and it cannot do port forwarding.
- NAT instance is just an EC2 instance so you can filter traffic using NACLs on the subnet
the instance is in or SGs directly associated with that instance.
- You cannot use SGs with a NAT Gateway, you can only use NACLs.

NATGW cannot do port forwarding or be a bastion server. In that case it might
be necessary to run a NAT EC2 instance instead.
#### 1.5.8.2. NAT Gateway and IPv6

- NAT is not required for IPv6. Inside AWS all IPv6 addresses are publicly routable. IG works with all IPv6 addresses directly.
- That means if you choose to make an instance in a private subnet that has a default IPv6 route to IG, it'll become a public instance.

---

Expand Down