# AWS SAA - Services - Networking ### VPC Overview - Virtual Private Cloud - Secure isolated network segment. - Isolates resources from other resources within the cloud. - Subnetting (IP Addresses) - Routing (Route Tables) - Firewalls (NACLS & Security Groups) - Gateways - A VPC is specific to a single region. - AWS Cloud <-> Region A <-> VPC 1 - VPC act as a network boundary. - By default they aren't able to talk to other VPCs or Internet. - Every VPC has a CIDR block assigned to it. - SIzes can be between /16 to a /28. - Optional secondary IPv4 CIDR block. - Option IPv6 /56 CIDR block. - Limit can be adjusted. - Default VPCs are configured by AWS. - By default allows connectivity to Internet. - Uses /16 CIDR block & 172.31.0.0/16 addresses, (65,526 addresses). - /20 default subnet in each AZ (4,096 addresses). - Internet gateway attached to the VPC. - Routes all traffic to the Internet Gateway. - Devices are internet accessible. - Has a default Security Group applied to the resources. - Has a default NACL for securing subnets & VPC overall. - Allows inbound/outbound traffic. - Custom VPCs are configured by you the end user. - Summary - VPC isolates computing resources from other resources in the AWS cloud. - VPCs are isolated to a region. - VPC CIDR blocks defines IP addresses VPC use. - VPC can have optional secondary IPv4 CIDR block & IPv6 CIDR block. - Every region has default VPC with default subnets, Security Groups, & NACLs. - The default CIDR block is 127.31.0.0/16. - The default VPC & its subnets have outbound Internet access by default. - One default subnet in each AZ. - Security Groups in default VPC allow outbound traffic & NACLs allow both inbound & outbound traffic. ### Custom VPC Demo - A brief overview & demo of creating & deleting a VPC. ### Default VPC Demo - A brief overview & demo of the AWS default VPC. ### Subnets - Subnets are groups of IPs in your VPC. - A subnet resides within a single AZ. - Can be public or private to allow external access within them. - Subnets within the VPC must be within the CIDR range. - e.g. Meaning a 10.100.1.0/24 can't exist within the 192.168.0.0/16 CIDR. - Subnet block size must be between a /16 & a /28. - The first 4 IPs of a subnet are reserved & can't be used. e.g. - 192.168.10.0 - Network address - 192.168.10.1 - VPC Router - 192.168.10.2 - DNS - 192.168.10.3 - for future use - The last IP of subnet, 192.168.10.255 is reserved as broadcast address. - Subnet Configuration Options - Can't have overlapping subnets with other subnets in the VPC. - e.g. 10.16.0.0/24 subnet overlaps in the 10.16.0.128/25 subnet. - Can allow for optional IPv6 /56 CIDR. - Can be configured to be IPv6 only. - Subnets within the same VPC can communicate with each other without additional configuration. - Can auto-assigned IPv4/IPv6 address along with the private address. - Summary - Subnets are a range of IPs within a VPC. - Subnets reside within a single AZ. - Subnets can be made public/privae using Internet Gateways or NAT Gateways. - Subnets can be configured with IPv4 & IPv6. - Subnets cannot overlap with other subnets within a VPC. ### Subnets Demo - A brief overview & demo of adding/removing subnets within a VPC. ### Routing in VPC - VPC routers have interfaces in every subnet of the VPC. - Is accessible via the IP addresses subnet + 1. - e.g. for 192.168.1.0/24 it would be 192.168.1.1 - Configurable route tables. - Larger IP prefix length will be the preferred route that a packet takes. - The target area is where the router with send the packet. - By default the VPC router uses the "local" route for forwarding packets. - Every subnet is associated with one route table. - There is always a default route table that is created when a subnet is created. - Multiple subnets can be associated with a single route table. - A subnet can only be associated with one route table. - Summary - Every VPC has a router responsible for routing traffic between subnets & in/out of a VPC. - The outer has an interface in every subnet of the VPC & is accessible via the network + 1 address of each subnet. - Route tables are a set of rules the router uses to forward network traffic - each rule is referred to as a route. - The router looks at the destination IP of a packet leaving the subnet & will identify a matching route by checking the destination column. - Once matched with a destination, the packet will be forwarded to the respective target column of the route. - All route tables have exactly one route by default, which is the local route. 2 local routes will be created if IPv6 is enabled for VPC. - Every subnet is associated with one route table. - Each VPC has one default route table. - Multiple subnets can be associated with a single route table. ### Route Table Demo - A brief overview & demo of routing for a VPC. ### Internet Gateways (VPC) - Overview of internet connectivity using Internet Gateway. - Create Internet Gateway. - Attach the Internet Gateway to the VPC. - Create custom route table. - Configure the default route. - Associate the subnet with route table. - AWS instances don't have direct access to the public IP address. - The public IP address is associated with the private IP. - Thus traffic going to the public IP is forwarded to private IP through AWS abstraction. - Summary - Internet Gateways enable resources to connect to the internet. - Internet Getways attach to a VPC and are region resilient. - VPC can only have 1 Internet Gateway & an Internet Gateway can only be attach to 1 VPC. - A subnet is made public once a default route points to the Internet Gateway in the VPC. ### Internet Gateways (VPC) - Demo - A brief over & demo of creating a Internet Gateway to establish Internet connectivity to a specific subnet within a VPC. ### NAT Gateways (VPC) - NAT Gateways are used to provide internet access to private subnets. - NAT GW still require using a IGW. - You'll attach the NAT GW to the IGW. - Then you'll setup routing to use the NAT GW. - NAT GW is charged per hour & per GB of data processed. - NAT GW are not region resilient. - They are associated per subnet. - Summary - NAT GW allow subnets to communicate to internet but connections must be initiated from within VPC. - NAT GW are deployed onto public subnets so that they have a public IP & internet access. - Uses Elastic IPs. - AZ-reliant service; need 1 NAT GW in each AZ. - You'd create additional NAT GWs for resiliency. - Route table for private subnets should point to NAT GW. - NAT GW are managed by AWS. - NAT GW is charged per hour & per GB of data processed. - NAT GW supports 5 Gbps of BW & automatically scales up to 100 Gbps. ### NAT Gateways (VPC) - Demo - A brief overview & demo of creating a NAT GW for a specific subnet in a VPC. ### Private and Public Subnets - Of course which you select depends on if the application needs to be accessed by public/end users. - e.g. web servers would be public. - e.g. DB/app servers would be private. - Then the web server would connect to whatever backend services. - Usage of VPNs can be used to connect between your DC to the AWS private subnet resources. - Summary - Resources in public subnets are accessible to & from the internet. - Resources in the private subnets are not accessible from the internet. - Gateways determine whether a subnet is public or private. ### LAB - Public and Private subnets and the gateways that enable them - Access URL: $URL - Username: $USER - Passphrase: $PASSPHRASE - Use `showcreds` command to obtain creds. >Imagine you are a Cloud Architect with a knack for crafting intricate cloud solutions. You are approached by a startup called "KloudSwift" to design an advanced network architecture within an Amazon Virtual Private Cloud (VPC). You are asked to create a secure network environment to host their applications. The Services you will be using for this scenario are: >- VPC and subnets. >- Internet Gateways. >- NAT Gateways. >- EC2 Instances. > > Each step in this lab offers you an opportunity to learn and demonstrate your skills. - Task request - Part 0: - Create VPC `kloudswift-vpc` using CIDR `10.16.0.0/16` in `us-east-1`. - Task request - Part 1: - Create 2 subnets - `public-subnet` use CIDR `10.16.1.0/24` in `us-east-1a`. - `private-subnet` use CIDR `10.16.2.0/24` in `us-east-1a`. - Task request - Part 2: - Create EC instance - Name: `kloudswift-ec2` - Size: t2.micro - AMI: AMZN Linux - Keypair: `ec2-user` (already present) - VPC: `kloudswift-vpc` - Subnet: `public-subnet` - Auto-assign Public IP: True - SecGroup: `kloudswift-sg` - Region: `us-east-1` - Task request - Part 3: - Create Internet Gateway in `us-east-1` - Name: `igw-kk` & attached to VPC `kloudswift-vpc` - Task request - Part 4: - Create route table `public-rt` for `kloudswift-vpc` - Task request - Part 5: - Add default IPv4 route, `0.0.0.0/0` & point to IGW `igw-kk`. - Associate `public-subnet` with this route. - Task request - Part 6: - Create EC2 instance - Name: `kloudswift-ec2-private` - Size: t2.micro - AMI: AMZN Linux - Keypair: `ec2-user` (already present) - VPC: `kloudswift-vpc` - Subnet: `private-subnet` - SecGroup: `kloudswift-sg` - Region: `us-east-1` - Task request - Part 7: - Note: Remember that NAT GW requires to be on public subnet to access internet. - Create NAT GW: - Name: `private-nat` - Assign elastic IP & set connectivity to public. - Region: `us-east-1` - Task request - Part 8: - Create private route named: `private-rt`. - Associate `private-subnet` to `private-rt`. - Add default route, `0.0.0.0/0` to `private-nat`. - Task request - Part 9: - Access the `kloudswift-ec2-private` instance from the `kloudswift-ec2` instance via private IP. - lab -> `kloudswift-ec2` -> `kloudswift-ec2-private` ### DNS (VPC) - By default all EC2 instances will get a domain name on private IP addresses. - By default this will be the private IP address embedded with the domain name. - The 2nd IP within a VPC subnet CIDR block is the AWS provided DNS service. - e.g. For `10.16.2.0/24` this would be `10.15.2.2` - The public IP of this service is `169.254.169.253` - Use the `enableDnsHostname` & `enableDnsSupport` option to utilize DNS resolution feature. - Summary - Device private IPs will automatically be assigned a DNS entry. - The 2nd IP within a VPC subnet CIDR block is the AWS provided DNS service. - `enableDnsHostnames` determines if a VPC supports assigning public DNS hostnames to instances with public IP addresses. - `enableDnsSupport` determines if a VPC supports DNS resolution through the AWS provided DNS server. ### DNS (VPC) - Demo - A brief overview & demo of the VPC DNS support features. - However this disables public DNS resolution. Meaning you'll need to use an alternate DNS server for public requests. ### Elastic IP - Non-elastic public IPs are not reserved to EC2 instances. - e.g. rebooting an EC2 instance will change public IP. - Elastic IPs that are allocated to your account are reserved for your EC2 instances. - Elastic IPs are able to be migrated to other EC2 instances within your account, (it's a "floating IP"). - Elastic IP pricing - Additional IP charged per hour. - Non-associated Elastic IPs also incur hourly fee. - Elastic IPs are region specific. - Elastic IPs are provide from AWS' pool of IP addresses. - You can bring your own IP space to AWS to use with your account EC2 instances. - Summary - Public IPs are not static & if EC2 instance goes down it will get a new public IP. - Elastic IPs are static IPv4 addresses that do not change. - To use an Elastic IP, you first allocate one to your account and then associate it with your instance or network interface. - Elastic IPs are region specific & can't be moved/used to a different region. ### Elastic IP - Demo - A brief overview & demo of the Elastic IP feature. ### Security Groups & NACLs - Stateless Firewall - Rules are broken down into inbound & outbound rules. - You define the inbound port for connectivity that is to be allowed. - Then you'll have another rule to allow the outbound traffic for that port to be responded to. - Stateful Firewall - Stateful firewalls are intelligent enough to understand which request & response are part of the same connection. - For instance, you'll define an inbound rule for a port and the stateful firewall will automagically know which outbound traffic to associate with that rule. - It is the same for an outbound rule for a port. - Network Access Control List (NACL) - Filters traffic entering & leaving a subnet. - NACLs do not filter traffic within a subnet. - NACLs are stateless firewalls, so inbound & outbound rules must be defined. - This is a stateful firewall. - Either allows or denies traffic. - Have rule numbers that get processed by numeric ordering. - Every subnet within a VPC must be associated with a NACL. - You can associate a NACL with multiple subnets. - However a subnet can only be associated with one NACL at a time. - NACLs don't filter traffic destined to/from the following: - AWS DNS - AWS DHCP - AWS EC2 instance metadata - AWS ECS task metadata endpoints - License activation for Windows intances - AWS NTP - Reserved IP addresses used by default VPC router - Security Groups - Act as firewalls for individual resources, (EC2, ELB, RDS) - Are a stateful firewall. - Whatever request is allowed inbound, the outbound request it automatically allowed. - Security groups, when there are no rules, it blocks everything. - When you add a security group rule, it allows a certain type of traffic. - All security group rules "allow" traffic; where is no "deny" option. - Implicit deny. - Configuring Security Groups - reference AWS Control Panel for further info. - Can have multiple SGs for a single resource. - The rules for both SGs get merged. - By default SG groups contain outbound rules that allow all outbound traffic. - This rule can be removed/deleted. - Summary - Stateless firewalls require traffic to be explicitly permitted inbound & outbound. - NACLs are stateless firewalls. - NACLs filter traffic at the subnet level. - NACL rules have the option to "allow" or "deny". - Every subnet within a VPC must be associated with a NACL. - You can associate a NACL with multiple subnets but a subnet can only be associated with one NACL at a time. - Stateful firewalls are intelligent firewalls that track request and allow response. - Security Groups are stateful firewalls. - Security Groups filter traffic at individual resource level. - Security Group rules only "allow" traffic. - Multiple Security Groups applied to a resource will have their rules merged. ### Security Groups - Demo - A brief overview & demo of the Security Groups feature. - You can even use another SG as a source that makes it more dynamic to allow connectivity to a resource. ### NACLs - Demo - A brief overview & demo of the NACLs feature. ### Elastic Load Balancers (ELB) - Three types of LBs - Classic LB - First LB introduced by AWS. - Not recommended for use. - Has limitations related to SSL/TLS certs, only supports one SSL/TLS cert. - Application LB - Supports HTTP/HTTPS/WebSockets specifically, (web apps). - Operations at the application layer, (layer 7). - Forward requests based off of: - URL path conditions - Host domain - HTTP fields - header, method, query & IP - Supports HTTP redirects & custom HTTP responses - Perform application specific health checks - HTTP/HTTPS is terminated at the ALB. Meaning the ALB handles the SSL/TLS portion & the requests are sent plaintext to backend EC2 nodes. - It does support HTTPS to backend nodes but requires an additional SSL/TLS cert on EC2 nodes that you manage/maintain. - Network LB - Manages traffic based on TCP/UDP (layer 4) - Meant for applications that don't use HTTP/HTTPS - Faster than application load balancers - Health checks are only basic TCP/ICMP connections - NLB forwards TCP connections to EC2 instances - For SSL/TLS support, this will be performed on the backend EC2 nodes themselves. - ELBs will utilize subnets within specified AZs in the VPC. - A ELB node will be deployed within the VPC to connect to the specified subnet in VPC. - A DNS record is created for the ELB. - Cross-Zone Load Balancing - Allows ELBs to manage traffic between two AZs to better spread traffic. - Deployment Modes - Public Load Balancers - Deployed on public subnets - Accessible by users over the internet - Private Load Balancers - Deployed on private subnets - Accessible by users within the Organizations AWS network - ELB Architecture Example - VPC - Public ELB on public subnet - 2 EC2 API nodes on private subnet - Private ELB on private subnet - 2 EC2 DB nodes on private subnet - ELS Listeners & Target Groups - Listeners is a process that checks for connection requests for the port/protocol configured. - e.g. `app1.com` goes to EC2 nodes Target Group - e.g. `app1.com/auth` goes to ECS Target Group - e.g. `app1.com/cart` goes to Lambda Target Group - Target Groups is a process that routes requests to one or more targets, e.g. EC2 or AWS resource Lambda, etc. - Summary - ELB auto-distributes incoming traffic across multiple targets in multiple AZs. - Distributes traffic to EC2 instances, IPs & Lambda functions. - Three types of ELBs: - Classic - Are outdated and not recommended to use. - Application - Functions are the application layer & forwards HTTP/HTTPS traffic. - SSL/TLS is always terminated on ALB. - Network - Can forward non-HTTP/HTTPS traffic. - Are faster than ALBs. - Does not terminate SSL/TLS & relies on backend nodes to do so. - Cross-Zone Load Balancing equally distributes traffic across all instances in all AZs. - A listener matches traffic based on rules & handles connection requests. - Target Groups route requests to registered EC2 instances based on specified port & protocol. ### Elastic Load Balancers - Demo - A brief overview & demo of ELB features. - Created 2 subnets for each of the AZs that the EC2 instances are in for the ELB to manage traffic for them. - Utilize a SG to allow the specified traffic. - Configure the listener for the specified port. - Create the Target Group that has the specific EC2 nodes or resources to send traffic to. - This includes defining the port the application/service is listening on for the EC2 nodes. ### VPN - A general use case is for securely connecting AWS resources with remote on-premise resources. - VPN Gateway terminates VPN on AWS side. - IPSec Tunnel. - Connects to Customer Gateway that terminates VPN on Customer on-premise side. - VPN Routing - You can manually create a static route to establish connectivity between the 2 sites. - You can use a dynamic routing protocol using BGP to establish connectivity between the 2 sites. - VPN Pricing - Charged for each VPN connection per hour. - Charged for outbound data from the VPN. - VPN Gateway Limitations - 1.25 Gbps max bandwidth. - 140k max pps. - 1466 bytes max MTU. - Summary - Connects VPCs to on-premise DCs. - A Virtual Private Gateway is the AWS side endpoint for your VPN that attaches to one VPN. - Customer Gateway is customers physical device or software in a VPN connection. - VPN IPSec Tunnel goes over public internet. - On-premise network can be set statically in a route table or dynamically exchanged via BGP. - Charged for each VPN connection per hour. - Charged for outbound data from the VPN. - 1.25 Gbps max bandwidth. ### Direct Connect - Corp DC <-> Direct Connect Service (DX) <-> AWS Resources - On-premise network Customer Gateway - Direct Connect (DX) Location - Customer Router connects to AWS Router port. - AWS Router connects to AWS resources. - VPN Gateway for private resources. - Directly to public resources. - Cross connect is a connection between a **port** on a AWS router & Customer Router. - Uses AWS backbone - Direct Connect Pricing - Port hours. - Outbound Data Transfer. - Summary - DX links on-premise with AWS without internet routing like a VPN. - Offers increased throughput over a more secure, stable connection than VPN over the internet. - Charges per **Port** hour & **Outbound** data transfer. ### VPC Peering - Reminder VPCs can't access resources between a different VPC. - VPC Peering acts like a network between VPCs. - Supports connections between VPC in same region, different region or different AWS account. - VPC Peering Pricing - No cost associated with the VPC Peering connection itself. - Data transfer within AZ via VPC Peering is free. - Data transfer across AZs using VPC peering incurs charges. - How does VPC Peering Work? - Sends a Peering Request to another VPC. - Accept Peering Request to allow the connection. - Configure a route that targets the Peering name/UUID between both of the peering locations. - VPC peering does not support transitive peering. - Meaning you can't use a VPC Peer between VPC 1 & VPC 2 to connect to VPC 3. - Each VPC will need to have peering setup between each VPC needing connectivity. - Summary - VPC Peering is network connectivity between two VPCs that routes traffic between them. - VPC Peering connects VPCs in same/different regions & AWS accounts. - No charge for creating a VPC peering; data transfer that crosses AZs is chargable. - VPC peering is not transitive. ### VPC Peering - DEMO - A brief overview & demo of VPC Peering features. - Select VPC then **Peering Connections**. - From here configure the VPC Peering between two VPCs. - CIDR blocks must be different between the VPCs. - In the **Peering connections** area after peering has been configured, go to **actions** & then select **Accept Request**. - Then go to **Route Tables** & select the associated VPC route table. - Add the subnet and then select **peering connection** using the specified **Peer Connection**. - e.g. 10.12.0.1/16 - Do this for both VPCs that are being peered but add the opposite subnet. - e.g. 10.13.0.1/16 ### LAB - Connecting three VPCs together in a region and cross-region - Task Request Overview >Imagine you are a Cloud Architect with a knack for crafting intricate cloud solutions. A tech company, CloudTech enterprises is looking to establish a robust and secure network architecture to enable seamless communication between their development, testing, and production environments. >As a Solutions Architect, your goal is to design a network solution that allows for efficient communication within and between VPCs across different regions. >Each step in this lab presents you with an opportunity to learn and demonstrate your skills. - Task request - Part 0: - Create `vpc-1` using CIDR `10.0.0.0/16` - Create 2 subnets - `subnet-1-1` & CIDR `10.0.1.0/24` - `subnet-1-2` & CIDR `10.0.2.0/24` - Region: `us-east-1` - Task Request - Part 1: - Create IGW `igw-1` & attach to `vpc-1` - Task Request - Part 2: - Create route `rt-1` - Add route that targets `igw-1` with dest `0.0.0.0/0` - Associate `subnet-1-1` to `rt-1` - Task Request - Part 3: - For this lab, we also need another VPC, subnets and their associated route tables. We have already deployed those resources for you in us-east-1 region. - Task Request - Part 4: - Create 2 EC2 instances. - `ec2-vpc-1` - t2.micro - keypair: `ec2-user` - VPC: `vpc-1` - Subnet: `subnet-1-1` - Select `Public IP enable` - SG: `sec-vpc1` - `ec2-vpc-2` - t2.micro - keypair `ec2-user` - VPC: `vpc-2` - Subnet: `subnet-2-1` - Select `Public IP enable` - SG: `sec-vpc2` - Task Request - Part 5: - Create peering connection - Peer connection: `my-pc-1` - Requester: `vpc-1` - Acceptor: `vpc-2` - Task Request - Part 6: - Add peering routes for both VPCs. - Route: `rt-1` - Dest: `vpc-2` - CIDR: `192.168.0.0/16` - Target: Peering Connection `my-pc-1` - Route: `rt-2` - Dest: `vpc-1` - CIDR: `10.0.0.0/16` - Target: Peering Connection `my-pc-1` - Task Request - Part 7: - Connect to the private IP of instance `ec2-vpc-2` from `ec2-vpc-1` ### LAB - Connecting three VPCs together in a region and in another region - 2A - Task Request Overview >Imagine you are a Cloud Architect with a knack for crafting intricate cloud solutions. A tech company, CloudTech enterprises, is looking to establish a robust and secure network architecture to enable seamless communication between their development, testing, and production environments. > As a Solutions Architect, your goal is to design a network solution that allows for efficient communication across different VPCs. In the previous lab, you have performed the peering connections for the different VPCs in the single region. In this lab, you will create a peering connection between two VPC in two different regions - Task Request - Part 0: - Precreated resources: - In us-east-1 region: - VPC with name: vpc-east - Subnets: subnet-east-1 and subnet-east-2 - Route table: rt-east - Security group: sec-vpc-east. - In us-west-2 region: - VPC with name: vpc-west - Subnets: subnet-west-1 and subnet-west-2 - Route table: rt-west - Security group: sec-vpc-west - Task Request - Part 1: - Create EC2 instance - Name: `ec2-east` - Image: AMZN Linux - Size: t2.micro - Keypair: `ec2-user-1` - VPC: `vpc-east` - Subnet: `subnet-east-1` & enable Public IP - SG: `sec-vpc-east` - Task Request - Part 2: - Create EC2 instance - Name: `ec2-west` - Image: AMZN Linux - Size: t2.micro - Keypair: `ec2-user-1` - VPC: `vpc-west` - Subnet: `subnet-west-1` & enable Public IP - SG: `sec-vpc-west` - Task Request - Part 3: - Connect to `ec2-east` node and try to connect to `ec2-west` node via private IP. - Note: Won't work due to not having connectivity between the VPCs. - Task Request - Part 4: - Create peer connection: `my-pc-cross-region` - Requester VPC `vpc-east` in `us-east-1` - Select **another region** & `us-west-2` - For acceptor VPC select `vpc-west` by using the VPC ID - Accept the peer connection request from the `us-west-2` region peering connections area - Task Request - Part 5: - Create route table entry in `rt-east` route in `us-east-1` - Dest as CIDR of `vpc-west` in `us-west-2` - Target pointing to `my-pc-cross-region` - Task Request - Part 6: - Create route table entry in `rt-west` route in `us-west-2` - Dest as CIDR of `vpc-east` in `us-east-1` - Target pointing to `my-pc-cross-region` - Task Request - Part 7: - Connect to `ec2-east` node and try to connect to `ec2-west` node via private IP. - Note: Will now work due to having connectivity between the VPCs using peer connection. ### Transit Gateway - To reduce the amount of VPC Peer Connections needed when VPCs scale, utilize the AWS Transit Gateway feature. - Transit Gateway acts as a transitive routing device to route traffic between VPCs. - Must specify one subnet from each AZ to be used by the transit gateway to route traffic. - Any AZ used for the Transit Gateway will need to have separate subnet in each of those AZs for the Transit GW to route traffic for. - Transit GW can terminate VPC VPN connectivity from customer on-premise DC to the associated/connected AZs it routes for. - AWS Direct Connect (DX) can also communicate to the Transit GW to reduce overhead of needing to create additional VPC VPNs. - Transit GW can peer between other Transit GW in other regions/ AWS accounts. - Summary - Transit GW simplify the networking between VPCs & on-premise environments. - Allows for transitive routing. - Must specify one subnet from each AZ to be used by the Transit GW to route traffic. - Can peer with other Transit GWs in different regions or AWS accounts. ### Private Link - Used for establishing connectivity between VPC private subnets to public AWS resources, e.g. S3, Lambda, etc. - Can be used to connect to 3rd party private subnet VPCs. - Summary - Allows resources in our VPC to connect to services as if they were in the same VPC. - Used to connect to public AWS services, e.g. S3, CloudWatch or to other VPCs in AWS. - VPC endpoints facilitate communication between VPC instances & services. ### CloudFront - Edge Locations are small CDN PoPs, (Point of Presence). - CloudFront is a CDN. - CloudFront Architecture - Origin is source location for content, e.g. S3, HTTP server, etc. - Takes the content & caches them in Edge Locations. - You'll create a Distribution that defines the origin of the content. - CF will then create a custom domain to access the cached content. - CF will then push the Distribution configuration to the Edge Location. - If the Edge Location doesn't have the data, it will request the content from the source & then cache it from there. - Cloud Front Time-To-Live (TTL) - Cached content at an Edge Location remains for a set time known as the TTL. - TTL value decides content validity before an Edge Location request content from the origin. - The default TTL is 24 hours. - Objects can expire at a specific time instead of the default. - Cache Invalidation - Cache invalidation allows you to manually invalidate content at Edge Locations. - Invalidations are performed on a distribution. - All objects, specfic folders, or a specific object can be invalidated. - `/*` - The entire distribution. - `/file.txt` - An individual file. - `/images/*` - All objects in an directory. - CloudFront Basic Integrations - SSL/TLS with ACM - SSL/TLS by default for domain `*cloudfront.net`. - Custom domain names are supported as well via ACM. - CloudWatch - Automatically publishes operational metrics for distributions. - For an additional cost, extra metrics can be enabled. - CloudFront Basic Use Cases - Static websites - Video/media content - Streaming - Summary - Delivers content via global network & DCs called Edge Locatons. - Helps get content closer to end users. - Origin is the content source for CloudFront Edge Locations. - Distribution is a unit of configuration for CloudFront. - CloudFront distros get a default domain name, `http://xyz.cloudfront.net`. - TTL decides how long content is valid before an Edge Location requests the origin. - Default TTL is 24 hours. - Cache invalidation, expires objects at Edge Locations before their TTL expires. ### CloudFront - Demo - A brief overview & demo of the CloudFront service & features. ### Lambda@Edge - CloudFront Functions & Lambda@Edge - Lightweight functions that run on the Edge Locations. - CloudFront Functions - Executes when CloudFront receives a viewer request. - Before CloudFront returns the response to the viewer. - Lambda@Edge - When a CloudFront receives a request from a viewer, (viewer request). - Before CloudFront forwards a request to the origin, (origin request). - When CloudFront receives a response from the origin (origin response). - Before CloudFront returns the response to the viewer, (viewer response). - CloudFront Functions Use Cases - Cache key normalization. - Header manipulation. - URL redirects & rewrites. - Request authorization. - Lambda@Edge Use Cases - Long-running functions. - Configurable CPU & memory functions. - Dependencies on 3rd party libraries. - Network dependent functions. - File system or HTTP Request Access functions. - Differences between CloudFront & Lambda@Edge ![[LamdaAtEdge_0.png]] - Summary - Allows you to run code at Edge Locations as close to users as possible. - Can be used to manipulate requests/responses that flow through CloudFront. - CloudFront functions are great for header manipulations, URL redirects & authorization. - Lambda@Edge: Long runtime, Network/File access. ### Global Accelerator - Similar to Edge Locations. - Uses the AWS backbone instead of ISP provider network. - Summary - CloudFront is meant for caching data at the edge. - Global Accelerator routes users to edge locations so they can immediate get on the AWS network & optimize the time taken to reach the apps, as the AWS global network is much faster & more efficient than the internet. ### Route 53 - AWS managed DNS service. - Acts as a domain registrar. - Purchase domains via Route 53. - Global service not region specific. - Hosted Zones - Where resource records are defined & stored. - Four nameservers are allocated for each hosted zone. - Summary - AWS managed DNS service. - Route 53 is a global service. - Hosted zones are a collection of DNS records. ### Demo: Route 53 - A brief overview & demo of the Route 53 service & features. - Outside of cost for purchasing a domain, there is a small fee for the hosted zone. ### Route 53 Application Recovery Controller (ARC) - A service that monitors a application can recover from failure. - Can verify if the backup environment is running as expected. - If there is a problem with the primary environment, failover to the backup. - ARC Architecture Example - VPC in US-EAST-1 & US-WEST-1 - ELB in both sites. - Application is in us-east-1a & us-west-1a. - Uses managed DynamoDB service. - Uses Route 53 for DNS zone management. - Note: Cell groups are all resources required for an application to operate independently. - In this instance, each instance of the application in each region is a cell. - Note: A Recovery Group is a collection of cells that represent an application to check for failover readiness. - Note: Resource set is a set of AWS resources that can span multiple cells. - In this example, that would be DynamoDB. - Readiness checks monitor the readiness of a standby deployment. - Routing Control allows you to manually failover the entire application stack to standby site via Route 53. - Summary - Route 53 ARC is a service that continually monitors the applications' ability to recover from failures. - Route 53 ARC's capabilities make application recovery simpler & more reliable by eliminating manual steps. - Cells are silos that contain an application's independent unit of failure. They group all AWS resources required for the application to operate independently. - Recovery Group is a collection of cells that represent or group of applications that you want to check for failover readiness. - Resource sets are resources that span multiple cells. - Readiness checks validate a set of AWS resources' readiness to be failed over to. ### Challenge Yourself Quiz - Meet your Services - Networking - Questions: 22 - 20 of 22 successful - 91% - Q: A company is looking to run their custom authentication logic at AWS edge locations to reduce latency and improve security. Which service should they use? - A: AWS Lambda@Edge - Incorrect: CF Functions. I selected this due to the course specifically mentioning this being a use case for it. - Q: Which AWS feature allows a customer to consume AWS services and third-party services privately from their own VPC? - A: AWS PrivateLink - Incorrect: VPC Peering. I totally misunderstood the question & need to slow down when answering.