Amazon VPC

 

• Create a virtual network in the cloud dedicated to your AWS account where you can launch AWS resources
• Amazon VPC is the networking layer of Amazon EC2
• A VPC spans all the Availability Zones in the region. After creating a VPC, you can add one or more subnets in each Availability Zone.

Key Concepts

• A virtual private cloud (VPC) allows you to specify an IP address range for the VPC, add subnets, associate security groups, and configure route tables.
• A subnet is a range of IP addresses in your VPC. You can launch AWS resources into a specified subnet. Use a public subnet for resources that must be connected to the internet, and a private subnet for resources that won’t be connected to the internet.
• To protect the AWS resources in each subnet, use security groups and network access control lists (ACL).
• Expand your VPC by adding secondary IP ranges.

EC2-VPC vs EC2-Classic

Default vs Non-Default VPC

Default	Non-Default VPC
If your account supports the EC2-VPC platform only, it comes with a default VPC that has a default subnet in each Availability Zone.	You can create your own non-default VPC, and configure it as you need. Subnets that you create in your non-default VPC and additional subnets that you create in your default VPC are called non-default subnets.
Your default VPC includes an internet gateway, which allows your instances to communicate with the internet, and each default subnet is a public subnet.	Instances can communicate with each other, but can’t access the internet. You can enable internet access for an instance launched into a non-default subnet by attaching an Internet Gateway and associating an Elastic IP address with the instance.
Each instance that you launch into a default subnet has a private IPv4 address and a public IPv4 address.	By default, each instance that you launch into a non-default subnet has a private IPv4 address, but no public IPv4 address, unless you specifically assign one at launch, or you modify the subnet’s public IP address attribute.
To allow an instance in your VPC to initiate outbound connections to the internet but prevent unsolicited inbound connections from the internet, you can use a network address translation (NAT) device for IPv4 traffic.
You can optionally associate an Amazon-provided IPv6 CIDR block with your VPC and assign IPv6 addresses to your instances. IPv6 traffic is separate from IPv4 traffic; your route tables must include separate routes for IPv6 traffic.

A diagram of default VPC

A diagram of non-default VPC

Accessing a Corporate or Home Network

• • You can optionally connect your VPC to your own corporate data center using an IPsec AWS managed VPN connection, making the AWS Cloud an extension of your data center.
  • A VPN connection consists of:
    • a virtual private gateway (which is the VPN concentrator on the Amazon side of the VPN connection) attached to your VPC.
    • a customer gateway (which is a physical device or software appliance on your side of the VPN connection) located in your data center.
    • A diagram of the connection

• • AWS Site-to-Site Virtual Private Network (VPN) connections can be moved from a virtual private gateway to an AWS Transit Gateway without having to make any changes on your customer gateway. Transit Gateways enable you to easily scale connectivity across thousands of Amazon VPCs, AWS accounts, and on-premises networks.
  • AWS PrivateLink enables you to privately connect your VPC to supported AWS services, services hosted by other AWS accounts (VPC endpoint services), and supported AWS Marketplace partner services. You do not require an internet gateway, NAT device, public IP address, AWS Direct Connect connection, or VPN connection to communicate with the service. Traffic between your VPC and the service does not leave the Amazon network.
  • AWS PrivateLink-Supported Services:

Amazon IP Gateway	Amazon Elastic Container Registry
Amazon AppStream 2.0	Amazon Elastic Container Service
AWS App Mesh	AWS Glue
Application Auto Scaling	AWS Key Management Service
Amazon Athena	Amazon Kinesis Data Firehouse
AWS Auto Scaling	Amazon Kinesis Data Streams
Amazon Cloud Directory	Amazon Rekognition
AWS CloudFormation	Amazon SageMaker and Amazon SageMaker Runtime
AWS CloudTrail	Amazon SageMaker Notebook
Amazon CloudWatch	AWS Secrets Manager
Amazon CloudWatch Events	AWS Security Token Service
Amazon CloudWatch Logs	AWS Server Migration Service
AWS CodeBuild	AWS Service Catalog
AWS CodeCommit	Amazon SNS
AWS CodePipeline	Amazon SQS
AWS Config	Amazon Systems Manager
AWS DataSync	AWS Storage Gateway
Amazon EC2 API	AWS Transfer for SFTP
Amazon EC2 Auto Scaling	Amazon WorkSpaces
Amazon Elastic File System	Endpoint services hosted by other AWS accounts
Elastic Load Balancing	Supported AWS Marketplace partner services
AWS CloudHSM

• • You can create a VPC peering connection between your VPCs, or with a VPC in another AWS account, and enable routing of traffic between the VPCs using private IP addresses. You cannot create a VPC peering connection between VPCs that have overlapping CIDR blocks.
  • Applications in an Amazon VPC can securely access AWS PrivateLink endpoints across VPC peering connections. The support of VPC peering by AWS PrivateLink makes it possible for customers to privately connect to a service even if that service’s endpoint resides in a different Amazon VPC that is connected using VPC peering.
  • AWS PrivateLink endpoints can now be accessed across both intra- and inter-region VPC peering connections.

VPC Use Case Scenarios

• VPC with a Single Public Subnet
• VPC with Public and Private Subnets (NAT)
• VPC with Public and Private Subnets and AWS Managed VPN Access
• VPC with a Private Subnet Only and AWS Managed VPN Access

Subnets

• When you create a VPC, you must specify a range of IPv4 addresses for the VPC in the form of a Classless Inter-Domain Routing (CIDR) block (example: 10.0.0.0/16). This is the primary CIDR block for your VPC.
• You can add one or more subnets in each Availability Zone of your VPC’s region.
• You specify the CIDR block for a subnet, which is a subset of the VPC CIDR block.
• A CIDR block must not overlap with any existing CIDR block that’s associated with the VPC.
• Types of Subnets
  • Public Subnet – has an internet gateway
  • Private Subnet – doesn’t have an internet gateway
  • VPN-only Subnet – has a virtual private gateway instead
• IPv4 CIDR block size should be between a /16 netmask (65,536 IP addresses) and /28 netmask (16 IP addresses).
• The first four IP addresses and the last IP address in each subnet CIDR block are NOT available for you to use, and cannot be assigned to an instance.
• You cannot increase or decrease the size of an existing CIDR block.
• When you associate a CIDR block with your VPC, a route is automatically added to your VPC route tables to enable routing within the VPC (the destination is the CIDR block and the target is local).
• You have a limit on the number of CIDR blocks you can associate with a VPC and the number of routes you can add to a route table.
• The following rules apply when you add IPv4 CIDR blocks to a VPC that’s part of a VPC peering connection:
  • If the VPC peering connection is active, you can add CIDR blocks to a VPC provided they do not overlap with a CIDR block of the peer VPC.
  • If the VPC peering connection is pending-acceptance, the owner of the requester VPC cannot add any CIDR block to the VPC. Either the owner of the accepter VPC must accept the peering connection, or the owner of the requester VPC must delete the VPC peering connection request, add the CIDR block, and then request a new VPC peering connection.
  • If the VPC peering connection is pending-acceptance, the owner of the accepter VPC can add CIDR blocks to the VPC. If a secondary CIDR block overlaps with a CIDR block of the requester VPC, the VPC peering connection request fails and cannot be accepted.
• If you’re using AWS Direct Connect to connect to multiple VPCs through a direct connect gateway, the VPCs that are associated with the direct connect gateway must not have overlapping CIDR blocks.
• The CIDR block is ready for you to use when it’s in the associated state.
• You can disassociate a CIDR block that you’ve associated with your VPC; however, you cannot disassociate the primary CIDR block.

Subnet Routing

• Each subnet must be associated with a route table, which specifies the allowed routes for outbound traffic leaving the subnet.
• Every subnet that you create is automatically associated with the main route table for the VPC.
• You can change the association, and you can change the contents of the main route table.
• You can allow an instance in your VPC to initiate outbound connections to the internet over IPv4 but prevent unsolicited inbound connections from the internet using a NAT gateway or NAT instance.
• To initiate outbound-only communication to the internet over IPv6, you can use an egress-only internet gateway.

Subnet Security

• Security Groups — control inbound and outbound traffic for your instances
  • You can associate one or more (up to five) security groups to an instance in your VPC.
  • If you don’t specify a security group, the instance automatically belongs to the default security group.
  • When you create a security group, it has no inbound rules. By default, it includes an outbound rule that allows all outbound traffic.
  • Security groups are associated with network interfaces.

• Network Access Control Lists — control inbound and outbound traffic for your subnets
  • Each subnet in your VPC must be associated with a network ACL. If none is associated, automatically associated with the default network ACL.
  • You can associate a network ACL with multiple subnets; however, a subnet can be associated with only one network ACL at a time.
  • A network ACL contains a numbered list of rules that is evaluated in order, starting with the lowest numbered rule, to determine whether traffic is allowed in or out of any subnet associated with the network ACL.
  • The default network ACL is configured to allow all traffic to flow in and out of the subnets to which it is associated.
  • For custom ACLs, you need to add a rule for ephemeral ports, usually with the range of 32768-65535. If you have a NAT Gateway, ELB or a Lambda function in a VPC, you need to enable 1024-65535 port range.
• Flow logs — capture information about the IP traffic going to and from network interfaces in your VPC that is published to CloudWatch Logs.
• Flow logs can help you with a number of tasks, such as:
  • Diagnosing overly restrictive security group rules
  • Monitoring the traffic that is reaching your instance
  • Determining the direction of the traffic to and from the network interfaces
• Flow log data is collected outside of the path of your network traffic, and therefore does not affect network throughput or latency. You can create or delete flow logs without any risk of impact to network performance.
• After you’ve created a flow log, it can take several minutes to begin collecting and publishing data to the chosen destinations. Flow logs do not capture real-time log streams for your network interfaces.
• VPC Flow Logs can be sent directly to an Amazon S3 bucket which allows you to retrieve and analyze these logs yourself.
• Amazon security groups and network ACLs don’t filter traffic to or from link-local addresses or AWS-reserved IPv4 addresses. Flow logs do not capture IP traffic to or from these addresses.

Security Group	Network ACL
Operates at the instance level	Operates at the subnet level
Supports ALLOW rules only	Supports ALLOW rules and DENY rules
Is stateful: Return traffic is automatically allowed, regardless of any rules	Is stateless: Return traffic must be explicitly allowed by rules
We evaluate all rules before deciding whether to allow traffic	We process rules in number order when deciding whether to allow traffic
Applies only to EC2 instances and similar services that use EC2 as a backend.	Automatically applies to all
Security group is specified when launching the instances, or is associated with the instance later on	Instances in the subnets it’s associated with

• Diagram of security groups and NACLs in a VPC

VPC Networking Components

• Network Interfaces

  • a virtual network interface that can include:
    • a primary private IPv4 address
    • one or more secondary private IPv4 addresses
    • one Elastic IP address per private IPv4 address
    • one public IPv4 address, which can be auto-assigned to the network interface for eth0 when you launch an instance
    • one or more IPv6 addresses
    • one or more security groups
    • a MAC address
    • a source/destination check flag
    • a description
  • Network interfaces can be attached and detached from instances, however, you cannot detach a primary network interface.

• Route Tables

  • contains a set of rules, called routes, that are used to determine where network traffic is directed.
  • A subnet can only be associated with one route table at a time, but you can associate multiple subnets with the same route table.
  • You cannot delete the main route table, but you can replace the main route table with a custom table that you’ve created.
  • You must update the route table for any subnet that uses gateways or connections.
  • Uses the most specific route in your route table that matches the traffic to determine how to route the traffic (longest prefix match).

• Internet Gateways

  • Allows communication between instances in your VPC and the internet.
  • Imposes no availability risks or bandwidth constraints on your network traffic.
  • Provides a target in your VPC route tables for internet-routable traffic, and performs network address translation for instances that have been assigned public IPv4 addresses.
  • The following table provides an overview of whether your VPC automatically comes with the components required for internet access over IPv4 or IPv6.
  • To enable access to or from the Internet for instances in a VPC subnet, you must do the following:
    • Attach an Internet Gateway to your VPC
    • Ensure that your subnet’s route table points to the Internet Gateway.
    • Ensure that instances in your subnet have a globally unique IP address (public IPv4 address, Elastic IP address, or IPv6 address).
    • Ensure that your network access control and security group rules allow the relevant traffic to flow to and from your instance
      

	Default VPC	Non-default VPC
Internet gateway	Yes	Yes, if you created the VPC using the first or second option in the VPC wizard. Otherwise, you must manually create and attach the internet gateway.
Route table with route to internet gateway for IPv4 traffic (0.0.0.0/0)	Yes	Yes, if you created the VPC using the first or second option in the VPC wizard. Otherwise, you must manually create the route table and add the route.
Route table with route to internet gateway for IPv6 traffic (::/0)	No	Yes, if you created the VPC using the first or second option in the VPC wizard, and if you specified the option to associate an IPv6 CIDR block with the VPC. Otherwise, you must manually create the route table and add the route.
Public IPv4 address automatically assigned to instance launched into subnet	Yes (default subnet)	No (non-default subnet)
IPv6 address automatically assigned to instance launched into subnet	No (default subnet)	No (non-default subnet)

• Egress-Only Internet Gateways

  • VPC component that allows outbound communication over IPv6 from instances in your VPC to the Internet, and prevents the Internet from initiating an IPv6 connection with your instances.
  • An egress-only Internet gateway is stateful.
  • You cannot associate a security group with an egress-only Internet gateway.
  • You can use a network ACL to control the traffic to and from the subnet for which the egress-only Internet gateway routes traffic.

• NAT

  • Enable instances in a private subnet to connect to the internet or other AWS services, but prevent the internet from initiating connections with the instances.
  • NAT Gateways
    • You must specify the public subnet in which the NAT gateway should reside.
    • You must specify an Elastic IP address to associate with the NAT gateway when you create it.
    • Each NAT gateway is created in a specific Availability Zone and implemented with redundancy in that zone.
    • Deleting a NAT gateway disassociates its Elastic IP address, but does not release the address from your account.
    • A NAT gateway supports the following protocols: TCP, UDP, and ICMP.
    • You cannot associate a security group with a NAT gateway.
    • A NAT gateway can support up to 55,000 simultaneous connections to each unique destination.
    • A NAT gateway cannot send traffic over VPC endpoints, VPN connections, AWS Direct Connect, or VPC peering connections.
    • A NAT gateway uses ports 1024-65535. Make sure to enable these in the inbound rules of your network ACL.
  • NAT Instance vs NAT Gateways

• DHCP Options Sets

  • Dynamic Host Configuration Protocol (DHCP) provides a standard for passing configuration information to hosts on a TCP/IP network.
  • You can assign your own domain name to your instances, and use up to four of your own DNS servers by specifying a special set of DHCP options to use with the VPC.
  • Creating a VPC automatically creates a set of DHCP options, which are domain-name-servers=AmazonProvidedDNS, and domain-name=domain-name-for-your-region, and associates them with the VPC.
  • After you create a set of DHCP options, you can’t modify them. Create a new set and associate a different set of DHCP options with your VPC, or use no DHCP options at all.

• DNS

  • AWS provides instances launched in a default VPC with public and private DNS hostnames that correspond to the public IPv4 and private IPv4 addresses for the instance.
  • AWS provides instances launched in a non-default VPC with private DNS hostname and possibly a public DNS hostname, depending on the DNS attributes you specify for the VPC and if your instance has a public IPv4 address.
  • Set VPC attributes enableDnsHostnames and enableDnsSupport to true so that your instances receive a public DNS hostname and Amazon-provided DNS server can resolve Amazon-provided private DNS hostnames.
    • If you use custom DNS domain names defined in a private hosted zone in Route 53, the enableDnsHostnames and enableDnsSupport attributes must be set to true.
• VPC Peering
  • A networking connection between two VPCs that enables you to route traffic between them privately. Instances in either VPC can communicate with each other as if they are within the same network.

• Elastic IP Addresses

  • A static, public IPv4 address.
  • You can associate an Elastic IP address with any instance or network interface for any VPC in your account.
  • You can mask the failure of an instance by rapidly remapping the address to another instance in your VPC.
  • Your Elastic IP addresses remain associated with your AWS account until you explicitly release them.
  • AWS imposes a small hourly charge when EIPs aren’t associated with a running instance, or when they are associated with a stopped instance or an unattached network interface.
  • You’re limited to five Elastic IP addresses.

• VPC Endpoints

  • Privately connect your VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.
  • Endpoints are virtual devices.
  • Two Types
    • Interface Endpoints
      • An elastic network interface with a private IP address that serves as an entry point for traffic destined to a supported service.
      • Can be accessed through AWS VPN connections or AWS Direct Connect connections, through intra-region VPC peering connections from Nitro instances, and through inter-region VPC peering connections from any type of instance.
      • For each interface endpoint, you can choose only one subnet per Availability Zone. Endpoints are supported within the same region only.
      • You can add endpoint policies to interface endpoints. The Amazon VPC endpoint policy defines which principal can perform which actions on which resources. An endpoint policy does not override or replace IAM user policies or service-specific policies. It is a separate policy for controlling access from the endpoint to the specified service.
      • An interface endpoint supports IPv4 TCP traffic only.

• • • Gateway Endpoints
      • A gateway that is a target for a specified route in your route table, used for traffic destined to a supported AWS service.
      • You can create multiple endpoints in a single VPC, for example, to multiple services. You can also create multiple endpoints for a single service, and use different route tables to enforce different access policies from different subnets to the same service.
      • You can modify the endpoint policy that’s attached to your endpoint, and add or remove the route tables that are used by the endpoint.
      • Endpoints are supported within the same region only. You cannot create an endpoint between a VPC and a service in a different region.
      • Endpoints support IPv4 traffic only.
      • You must enable DNS resolution in your VPC, or if you’re using your own DNS server, ensure that DNS requests to the required service (such as S3) are resolved correctly to the IP addresses maintained by AWS.
  • You can create your own application in your VPC and configure it as an AWS PrivateLink-powered service (referred to as an endpoint service). You are the service provider, and the AWS principals that create connections to your service are service consumers.

• ClassicLink

  • Allows you to link an EC2-Classic instance to a VPC in your account, within the same region. This allows you to associate the VPC security groups with the EC2-Classic instance, enabling communication between your EC2-Classic instance and instances in your VPC using private IPv4 addresses.

VPN Connections

VPN connectivity option	Description
AWS managed VPN	You can create an IPsec VPN connection between your VPC and your remote network. On the AWS side of the VPN connection, a virtual private gateway provides two VPN endpoints (tunnels) for automatic failover. You configure your customer gateway on the remote side of the VPN connection.
AWS VPN CloudHub	If you have more than one remote network, you can create multiple AWS-managed VPN connections via your virtual private gateway to enable communication between these networks.
Third-party software VPN appliance	You can create a VPN connection to your remote network by using an Amazon EC2 instance in your VPC that’s running a third-party software VPN appliance. AWS does not provide or maintain third-party software VPN appliances; however, you can choose from a range of products provided by partners and open source communities.
AWS Direct Connect	You can also use AWS Direct Connect to create a dedicated private connection from a remote network to your VPC. You can combine this connection with an AWS-managed VPN connection to create an IPsec-encrypted connection.

• Specify a private Autonomous System Number (ASN) for the virtual private gateway. If you don’t specify an ASN, the virtual private gateway is created with the default ASN (64512). You cannot change the ASN after you’ve created the virtual private gateway.
• When you create a VPN connection, you must:
  • Specify the type of routing that you plan to use (static or dynamic)
  • Update the route table for your subnet
• If your VPN device supports Border Gateway Protocol (BGP), specify dynamic routing when you configure your VPN connection. If your device does not support BGP, specify static routing.
• VPG uses path selection to determine how to route traffic to your remote network. Longest prefix match applies.
• Each VPN connection has two tunnels, with each tunnel using a unique virtual private gateway public IP address. It is important to configure both tunnels for redundancy.

VPC Traffic Mirroring

• Allows you to replicate the network traffic from EC2 instances within your VPC to security and monitoring appliances for content inspection, threat monitoring, troubleshooting, and more.
• Both Nitro and non-Nitro instances are supported.

Pricing

• Charged for VPN Connection-hour
• Charged for each “NAT Gateway-hour” that your NAT gateway is provisioned and available.
• Data processing charges apply for each Gigabyte processed through the NAT gateway regardless of the traffic’s source or destination.
• You also incur standard AWS data transfer charges for all data transferred via the NAT gateway.
• Charges for unused or inactive Elastic IPs.

Amazon Route 53

 

• A highly available and scalable Domain Name System (DNS) web service used for domain registration, DNS routing, and health checking.

Key Features

• Resolver
• Traffic flow
• Latency based routing
• Geo DNS
• Private DNS for Amazon VPC
• DNS Failover
• Health Checks and Monitoring
• Domain Registration
• CloudFront and S3 Zone Apex Support
• Amazon ELB Integration

Domain Registration

• Choose a domain name and confirm that it’s available, then register the domain name with Route 53. The service automatically makes itself the DNS service for the domain by doing the following:
  • Creates a hosted zone that has the same name as your domain.
  • Assigns a set of four name servers to the hosted zone. When someone uses a browser to access your website, such as www.example.com, these name servers tell the browser where to find your resources, such as a web server or an S3 bucket.
  • Gets the name servers from the hosted zone and adds them to the domain.
• If you already registered a domain name with another registrar, you can choose to transfer the domain registration to Route 53.
• Enable DNSSEC signing on new or existing public hosted zones. DNSSEC provides data integrity verification and
  data origin authentication for DNS.
• You can also configure DNSSEC on domain registration.

Routing Internet Traffic to your Website or Web Application

• Use the Route 53 console to register a domain name and configure Route 53 to route internet traffic to your website or web application.
• After you register your domain name, Route 53 automatically creates a public hosted zone that has the same name as the domain.
• To route traffic to your resources, you create records, also known as resource record sets, in your hosted zone.
• You can create special Route 53 records, called alias records, that route traffic to S3 buckets, CloudFront distributions, and other AWS resources.
• Each record includes information about how you want to route traffic for your domain, such as:
  • Name – name of the record corresponds with the domain name or subdomain name that you want Route 53 to route traffic for.
  • Type – determines the type of resource that you want traffic to be routed to.
  • Value
• How traffic is routed

Route 53 Health Checks

• • How it works

• • Create a health check and specify values that define how you want the health check to work, such as:
    • The IP address or domain name of the endpoint that you want Route 53 to monitor.
    • The protocol that you want Route 53 to use to perform the check: HTTP, HTTPS, or TCP.
    • The request interval you want Route 53 to send a request to the endpoint.
    • How many consecutive times the endpoint must fail to respond to requests before Route 53 considers it unhealthy. This is the failure threshold.
  • You can configure a health check to check the health of one or more other health checks.
  • You can configure a health check to check the status of a CloudWatch alarm so that you can be notified on the basis of a broad range of criteria.

Know the following Concepts

• Domain Registration Concepts – domain name, domain registrar, domain registry, domain reseller, top-level domain
• DNS Concepts
  • Alias record – a type of record that you can create to route traffic to AWS resources.
  • DNS query
  • DNS resolver
  • Domain Name System (DNS)
  • Private DNS
  • Hosted zone – a container for records, which includes information about how to route traffic for a domain and all of its subdomains.
  • Name servers – servers in the DNS that help to translate domain names into the IP addresses that computers use to communicate with one another.
  • Record (DNS record) – an object in a hosted zone that you use to define how you want to route traffic for the domain or a subdomain.
  • Routing policy
  • Subdomain
  • Time to live (TTL)
• Health Checking Concepts
  • DNS failover – a method for routing traffic away from unhealthy resources and to healthy resources.
  • endpoint
  • health check

Routing Policies

• Simple routing policy – route internet traffic to a single resource that performs a given function for your domain. You can’t create multiple records that have the same name and type, but you can specify multiple values in the same record, such as multiple IP addresses.
• Failover routing policy – use when you want to configure active-passive failover.
• Geolocation routing policy – use when you want to route internet traffic to your resources based on the location of your users.
• Geoproximity routing policy – use when you want to route traffic based on the location of your resources and, optionally, shift traffic from resources in one location to resources in another.
  • You can also optionally choose to route more traffic or less to a given resource by specifying a value, known as a bias. A bias expands or shrinks the size of the geographic region from which traffic is routed to a resource.
  • The effect of changing the bias for your resources depends on a number of factors, including the following:
    • The number of resources that you have.
    • How close the resources are to one another.
    • The number of users that you have near the border area between geographic regions.
• Latency routing policy – use when you have resources in multiple locations and you want to route traffic to the resource that provides the best latency.
• Multivalue answer routing policy – use when you want Route 53 to respond to DNS queries with up to eight healthy records selected at random.
• Weighted routing policy – use to route traffic to multiple resources in proportions that you specify.
• When you register a domain or transfer domain registration to Route 53, it configures the domain to renew automatically. The automatic renewal period is typically one year, although the registries for some top-level domains (TLDs) have longer renewal periods.
• When you register a domain with Route 53, it creates a hosted zone that has the same name as the domain, assigns four name servers to the hosted zone, and updates the domain to use those name servers.

Hosted Zones

• Route 53 automatically creates the Name Server (NS) and Start of Authority (SOA) records for the hosted zones.
• Route 53 creates a set of 4 unique name servers (a delegation set) within each hosted zone.
• Public hosted zone – route internet traffic to your resources
• Private hosted zone – route traffic within an Amazon VPC. You create a private hosted zone, and specify the VPCs that you want to associate with the hosted zone.
  • To use private hosted zones, you must set the following VPC settings to true:
    • enableDnsHostnames
    • enableDnsSupport
  • In a private hosted zone, you can associate Route 53 health checks only with weighted and failover records.
  • You can use the following routing policies when you create records in a private hosted zone:
    • Simple
    • Failover
    • Multivalue answer
    • Weighted

Records

• Create records in a hosted zone. Records define where you want to route traffic for each domain name or subdomain name. The name of each record in a hosted zone must end with the name of the hosted zone.
• Alias Records
  • Route 53 alias records provide a Route 53–specific extension to DNS functionality. Alias records let you route traffic to selected AWS resources. They also let you route traffic from one record in a hosted zone to another record.
  • You can create an alias record at the top node of a DNS namespace, also known as the zone apex.
• CNAME Record
  • You cannot create an alias record at the top node of a DNS namespace using a CNAME record.
• Alias records vs CNAME records

CNAME Records	Alias Records
You can’t create a CNAME record at the zone apex.	You can create an alias record at the zone apex. Alias records must have the same type as the record you’re routing traffic to.
Route 53 charges for CNAME queries.	Route 53 doesn’t charge for alias queries to AWS resources.
A CNAME record redirects queries for a domain name regardless of record type.	Route 53 responds to a DNS query only when the name and type of the alias record matches the name and type in the query.
A CNAME record can point to any DNS record that is hosted anywhere.	An alias record can only point to selected AWS resources or to another record in the hosted zone that you’re creating the alias record in.
A CNAME record appears as a CNAME record in response to dig or Name Server (NS) lookup queries.	An alias record appears as the record type that you specified when you created the record, such as A or AAAA.

Supported DNS Record Types

• A Record Type – the value for an A record is an IPv4 address in dotted decimal notation.
• AAAA Record Type – the value for a AAAA record is an IPv6 address in colon-separated hexadecimal format.
• CAA Record Type – lets you specify which certificate authorities (CAs) are allowed to issue certificates for a domain or subdomain.
• CNAME Record Type – a CNAME Value element is the same format as a domain name.
• MX Record Type – each value for an MX record actually contains two values, priority and domain name.
• NAPTR Record Type
• NS Record Type – identifies the name servers for the hosted zone. The value for an NS record is the domain name of a name server.
• PTR Record Type – is the same format as a domain name.
• SOA Record Type – provides information about a domain and the corresponding Amazon Route 53 hosted zone.
• SPF Record Type
• SRV Record Type
• TXT Record Type

DNS Domain Name Format

• Names of domains, hosted zones, and records consist of a series of labels separated by dots, which can be up to 63 bytes long. The total length of a domain name cannot exceed 255 bytes, including the dots.
• You can create hosted zones and records that include * in the name.

Using Traffic Flow to Route DNS Traffic

• You use the visual editor to create a traffic policy. A traffic policy includes information about the routing configuration that you want to create:
  • the routing policies that you want to use
  • resources that you want to route DNS traffic to, such as the IP address of each EC2 instance and the domain name of each ELB load balancer.
• Create a policy record where you specify the hosted zone in which you want to create the configuration that you defined in your traffic policy. It’s also where you specify the DNS name that you want to associate the configuration with.

Route 53 Resolvers

• Resolver answers DNS queries for VPC domain names such as domain names for EC2 instances or ELB load balancers, and performs recursive lookups against public name servers for all other domain names.
• DNS resolvers on your network can forward DNS queries to Resolver in a specified VPC. You can also configure Resolver to forward queries that it receives from EC2 instances in your VPCs to DNS resolvers on your network.
• Resolver is regional.
• An inbound endpoint specifies the VPC that queries pass through on the way from your network to Resolver.
• To forward DNS queries that originate on EC2 instances in one or more VPCs to your network, you create an outbound endpoint and one or more rules.
• Route 53 Resolver DNS Firewall is a managed firewall that lets you block DNS queries made from known malicious domains and allow queries from trusted domains. This is achieved through the use of “blocklists” and “allowlists”.

Route 53 Health Checks and DNS Failover

• Each health check that you create can monitor one of the following:
  • The health of a specified resource, such as a web server
  • The status of other health checks
  • The status of an Amazon CloudWatch alarm
• Each health checker evaluates the health of the endpoint based on two values:
  • Response time
  • Whether the endpoint responds to a number of consecutive health checks that you specify (the failure threshold)
• Types of health checks
  • HTTP and HTTPS health checks – Route 53 must be able to establish a TCP connection with the endpoint within four seconds. In addition, the endpoint must respond with an HTTP status code of 2xx or 3xx within two seconds after connecting.
  • TCP health checks – Route 53 must be able to establish a TCP connection with the endpoint within ten seconds.
  • HTTP and HTTPS health checks with string matching – Route 53 must be able to establish a TCP connection with the endpoint within four seconds, and the endpoint must respond with an HTTP status code of 2xx or 3xx within two seconds after connecting. After a Route 53 health checker receives the HTTP status code, it must receive the response body from the endpoint within the next two seconds.
• Health-checking features to route traffic only to the healthy resources:
  • Check the health of EC2 instances and other resources (non-alias records)
  • Evaluate the health of an AWS resource (alias records)
• Two types of failover configurations
  • Active-Active Failover – all the records that have the same name, the same type, and the same routing policy are active unless Route 53 considers them unhealthy. Use this failover configuration when you want all of your resources to be available the majority of the time.
  • Active-Passive Failover – use this failover configuration when you want a primary resource or group of resources to be available the majority of the time and you want a secondary resource or group of resources to be on standby in case all the primary resources become unavailable. When responding to queries, Route 53 includes only the healthy primary resources.
• To create an active-passive failover configuration with one primary record and one secondary record, you just create the records and specify Failover for the routing policy.
• To configure active-passive failover with multiple resources for the primary or secondary record, create records with the same name, type, and routing policy for your primary resources. If you’re using AWS resources that you can create alias records for, specify Yes for Evaluate Target Health.
• You can also use weighted records for active-passive failover, with caveats.
• You can configure Amazon Route 53 to log information about the queries that Route 53 receives. Query logging is available only for public hosted zones.

Authentication and Access Control

• Authenticate with IAM before allowing to perform any operation on Route 53 resources.
• Every AWS resource is owned by an AWS account, and permissions to create or access a resource are governed by permissions policies. A permissions policy specifies who has access to what.

Monitoring

• The Route 53 dashboard provides detailed information about the status of your domain registrations, including:
  • Status of new domain registrations
  • Status of domain transfers to Route 53
  • List of domains that are approaching the expiration date
• You can use Amazon CloudWatch metrics to see the number of DNS queries served for each of your Route 53 public hosted zones. With these metrics, you can see at a glance the activity level of each hosted zone to monitor changes in traffic.
• You can monitor your resources by creating Route 53 health checks, which use CloudWatch to collect and process raw data into readable, near real-time metrics.
• Log API calls with CloudTrail

Pricing

• A hosted zone is charged at the time it’s created and on the first day of each subsequent month. To allow testing, a hosted zone that is deleted within 12 hours of creation is not charged, however, any queries on that hosted zone will still incur charges.
• Billion queries / month
• Queries to Alias records are provided at no additional cost to current Route 53 customers when the records are mapped to the following AWS resource types:
  • Elastic Load Balancers
  • Amazon CloudFront distributions
  • AWS Elastic Beanstalk environments
  • Amazon S3 buckets that are configured as website endpoints
• Traffic flow policy record / month
• Pricing for domain names varies by Top Level Domain (TLD)

Amazon CloudFront

 A web service that speeds up distribution of your static and dynamic web content to your users. A Content Delivery Network (CDN) service.

• It delivers your content through a worldwide network of data centers called edge locations. When a user requests content that you’re serving with CloudFront, the user is routed to the edge location that provides the lowest latency, so that content is delivered with the best possible performance.
  • If the content is already in the edge location with the lowest latency, CloudFront delivers it immediately.
  • If the content is not in that edge location, CloudFront retrieves it from an origin that you’ve defined

How CloudFront Delivers Content

• • You specify origin servers, like an S3 bucket or your own HTTP server, from which CloudFront gets your files which will then be distributed from CloudFront edge locations all over the world.
  • Upload your files to your origin servers. Your files, also known as objects.
  • Create a CloudFront distribution, which tells CloudFront which origin servers to get your files from when users request the files through your web site or application. At the same time, you specify details such as whether you want CloudFront to log all requests and whether you want the distribution to be enabled as soon as it’s created.
  • CloudFront assigns a domain name to your new distribution that you can see in the CloudFront console.
  • CloudFront sends your distribution’s configuration (but not your content) to all of its edge locations—collections of servers in geographically dispersed data centers where CloudFront caches copies of your objects.
• CloudFront supports the WebSocket protocol as well as the HTTP protocol with the following HTTP methods:
  • GET
  • HEAD
  • POST
  • PUT
  • DELETE
  • OPTIONS
  • PATCH.
• Using Lambda@Edge with CloudFront enables a variety of ways to customize the content that CloudFront delivers. It can help you configure your CloudFront distribution to serve private content from your own custom origin, as an option to using signed URLs or signed cookies.(See AWS Compute Services Lambda Lambda@Edge)
• CloudFront also has regional edge caches that bring more of your content closer to your viewers, even when the content is not popular enough to stay at a CloudFront edge location, to help improve performance for that content.
• You can use a zone apex name on CloudFront
• CloudFront supports wildcard CNAME
• Different CloudFront Origins
  • Using S3 buckets for your origin – you place any objects that you want CloudFront to deliver in an S3 bucket.
  • Using S3 buckets configured as website endpoints for your origin
  • Using a mediastore container or a media package channel for your origin – you can set up an S3 bucket that is configured as a MediaStore container, or create a channel and endpoints with MediaPackage. Then you create and configure a distribution in CloudFront to stream the video.
  • Using EC2 or other custom origins – A custom origin is an HTTP server, for example, a web server.
  • Using CloudFront Origin Groups for origin failover – use origin failover to designate a primary origin for CloudFront plus a second origin that CloudFront automatically switches to when the primary origin returns specific HTTP status code failure responses.
• Objects are cached for 24 hours by default. You can invalidate files in CloudFront edge caches even before they expire.
• You can configure CloudFront to automatically compress files of certain types and serve the compressed files when viewer requests include Accept-Encoding: gzip in the request header.
• CloudFront can cache different versions of your content based on the values of query string parameters.
• CloudFront Distributions
  • You create a CloudFront distribution to tell CloudFront where you want content to be delivered from, and the details about how to track and manage content delivery.
  • You create a distribution and choose the configuration settings you want:
    • Your content origin—that is, the Amazon S3 bucket, MediaPackage channel, or HTTP server from which CloudFront gets the files to distribute. You can specify any combination of up to 25 S3 buckets, channels, and/or HTTP servers as your origins.
    • Access—whether you want the files to be available to everyone or restrict access to some users.
    • Security—whether you want CloudFront to require users to use HTTPS to access your content.
    • Cookie or query-string forwarding—whether you want CloudFront to forward cookies or query strings to your origin.
    • Geo-restrictions—whether you want CloudFront to prevent users in selected countries from accessing your content.
    • Real Time Access logs—whether you want CloudFront to create access logs that show viewer activity, which are recorded in real time.
  • You can use distributions to serve the following content over HTTP or HTTPS:
    • Static and dynamic download content.
    • Video on demand in different formats, such as Apple HTTP Live Streaming (HLS) and Microsoft Smooth Streaming.
    • A live event, such as a meeting, conference, or concert, in real time.
  • Values that you specify when you create or update a distribution
    • Delivery Method – Web HTTP or protocols.
    • Origin Settings – information about one or more locations where you store the original versions of your web content.
    • Cache Behavior Settings – lets you configure a variety of CloudFront functionality for a given URL path pattern for files on your website.
    • Custom Error Pages and Error Caching
    • Restrictions – if you need to prevent users in selected countries from accessing your content, you can configure your CloudFront distribution either to allow users in a whitelist of specified countries to access your content or to not allow users in a blacklist of specified countries to access your content.

Cache Behavior Settings

• • The functionality that you can configure for each cache behavior includes:
    • The path pattern.
    • If you have configured multiple origins for your CloudFront distribution, which origin you want CloudFront to forward your requests to.
    • Whether to forward query strings to your origin.
    • Whether accessing the specified files requires signed URLs.
    • Whether to require users to use HTTPS to access those files.
    • The minimum amount of time that those files stay in the CloudFront cache regardless of the value of any Cache-Control headers that your origin adds to the files.
  • CloudFront also offers a new method of cache configuration called policies. You may use the policies premade by AWS or you can create your own. These policies define how you’d like the cache to behave, such as cache TTL Settings, Cache Key Contents, and Compression settings.
  • After creating your CloudFront distribution, you can invalidate its cached items by creating an invalidation request.

Price Class

• • Choose the price class that corresponds with the maximum price that you want to pay for CloudFront service. By default, CloudFront serves your objects from edge locations in all CloudFront regions.

Performance and Availability

• • CloudFront also allows you to set up multiple origins to enable redundancy with Origin Failover. To set up origin failover, you must have a distribution with at least two origins. Next, you create an origin group for your distribution that includes the two origins, setting one as the primary. Finally, you define a cache behavior in which you specify the origin group as your origin.
    • The two origins in the origin group can be any combination of the following: AWS origins, like Amazon S3 buckets or Amazon EC2 instances, or custom origins, like your own HTTP web server.
    • When you create the origin group, you configure CloudFront to failover to the second origin for GET, HEAD, and OPTIONS HTTP methods when the primary origin returns specific status codes that you configure.
  • CloudFront is optimized for both dynamic and static content, providing extensive flexibility for optimizing cache behavior, coupled with network-layer optimizations for latency and throughput.

Using HTTPS with CloudFront

• • You can choose HTTPS settings both for communication between viewers and CloudFront, and between CloudFront and your origin.
  • If you want your viewers to use HTTPS and to use alternate domain names for your files, you need to choose one of the following options for how CloudFront serves HTTPS requests:
    • Use a dedicated IP address in each edge location
    • Use Server Name Indication (SNI)

Monitoring

• • The billing report is a high-level view of all of the activity for the AWS services that you’re using, including CloudFront.
  • The usage report is a summary of activity for a service such as CloudFront, aggregated by hour, day, or month. It also includes usage charts that provide a graphical representation of your CloudFront usage.
  • CloudFront console includes a variety of reports based on the data in CloudFront access logs:
    • CloudFront Cache Statistics Reports
    • CloudFront Popular Objects Report
    • CloudFront Top Referrers Report
    • CloudFront Usage Reports
    • CloudFront Viewers Reports
  • You can use AWS Config to record configuration changes for CloudFront distribution settings changes.
  • CloudFront integrates with Amazon CloudWatch metrics so that you can monitor your website or application.
  • Capture API requests with AWS CloudTrail. CloudFront is a global service. To view CloudFront requests in CloudTrail logs, you must update an existing trail to include global services.

Security

• • CloudFront, AWS Shield, AWS WAF, and Route 53 work seamlessly together to create a flexible, layered security perimeter against multiple types of attacks including network and application layer DDoS attacks.
  • You can deliver your content, APIs or applications via SSL/TLS, and advanced SSL features are enabled automatically.
  • Through geo-restriction capability, you can prevent users in specific geographic locations from accessing content that you’re distributing through CloudFront.
  • With Origin Access Identity feature, you can restrict access to an S3 bucket to only be accessible from CloudFront.
  • Field-Level Encryption is a feature of CloudFront that allows you to securely upload user-submitted data such as credit card numbers to your origin servers.

Pricing

• • Charge for storage in an S3 bucket.
  • Charge for serving objects from edge locations.
    • Data Transfer Out
  • Charge for submitting data to your origin.
    • Data Transfer Out
    • HTTP/HTTPS Requests
    • Invalidation Requests,
    • Dedicated IP Custom SSL certificates associated with a CloudFront distribution.
  • You also incur a surcharge for HTTPS requests, and an additional surcharge for requests that also have field-level encryption enabled.

• Compliance

  • CloudFront has been validated as being compliant with Payment Card Industry (PCI) Data Security Standard (DSS).
  • CloudFront is a HIPAA eligible service.
  • CloudFront is compliant with SOC measures.

Amazon API Gateway

 

• Enables developers to create, publish, maintain, monitor, and secure APIs at any scale.
• This is a HIPAA eligible service.
• Allows creating, deploying, and managing a RESTful API to expose backend HTTP endpoints, Lambda functions, or other AWS services.
• Together with Lambda, API Gateway forms the app-facing part of the AWS serverless infrastructure.

 Concepts

• • API deployment – a point-in-time snapshot of your API Gateway API resources and methods. To be available for clients to use, the deployment must be associated with one or more API stages.
  • API endpoints – host names APIs in API Gateway, which are deployed to a specific region and of the format: rest-api-id.execute-api.region.amazonaws.com
  • API key – An alphanumeric string that API Gateway uses to identify an app developer who uses your API.
  • API stage – A logical reference to a lifecycle state of your API. API stages are identified by API ID and stage name.
  • Model – Data schema specifying the data structure of a request or response payload.
  • Private API – An API that is exposed through interface VPC endpoints and isolated from the public internet
  • Private integration – An API Gateway integration type for a client to access resources inside a customer’s VPC through a private API endpoint without exposing the resources to the public internet.
  • Proxy integration – You can set up a proxy integration as an HTTP proxy integration type or a Lambda proxy integration type.
    • For the HTTP proxy integration, API Gateway passes the entire request and response between the frontend and an HTTP backend.
    • For the Lambda proxy integration, API Gateway sends the entire request as an input to a backend Lambda function.
  • Usage plan – Provides selected API clients with access to one or more deployed APIs. You can use a usage plan to configure throttling and quota limits, which are enforced on individual client API keys.

API Endpoint Types

• • Edge-optimized API endpoint: The default host name of an API Gateway API that is deployed to the specified region while using a CloudFront distribution to facilitate client access typically from across AWS regions. API requests are routed to the nearest CloudFront Point of Presence.
  • Regional API endpoint: The host name of an API that is deployed to the specified region and intended to serve clients, such as EC2 instances, in the same AWS region. API requests are targeted directly to the region-specific API Gateway without going through any CloudFront distribution.
    • You can apply latency-based routing on regional endpoints to deploy an API to multiple regions using the same regional API endpoint configuration, set the same custom domain name for each deployed API, and configure latency-based DNS records in Route 53 to route client requests to the region that has the lowest latency.
  • Private API endpoint: Allows a client to securely access private API resources inside a VPC. Private APIs are isolated from the public Internet, and they can only be accessed using VPC endpoints for API Gateway that have been granted access.

Features

• • API Gateway can execute Lambda code in your account, start Step Functions state machines, or make calls to Elastic Beanstalk, EC2, or web services outside of AWS with publicly accessible HTTP endpoints.
  • API Gateway helps you define plans that meter and restrict third-party developer access to your APIs.
  • API Gateway helps you manage traffic to your backend systems by allowing you to set throttling rules based on the number of requests per second for each HTTP method in your APIs.
  • You can set up a cache with customizable keys and time-to-live in seconds for your API data to avoid hitting your backend services for each request.
  • API Gateway lets you run multiple versions of the same API simultaneously with API Lifecycle.
  • After you build, test, and deploy your APIs, you can package them in an API Gateway usage plan and sell the plan as a Software as a Service (SaaS) product through AWS Marketplace.
  • API Gateway offers the ability to create, update, and delete documentation associated with each portion of your API, such as methods and resources.
  • Amazon API Gateway offers general availability of HTTP APIs, which gives you the ability to route requests to private ELBs AWS AppConfig, Amazon EventBridge, Amazon Kinesis Data Streams, Amazon SQS, AWS Step Functions and IP-based services registered in AWS CloudMap such as ECS tasks. Previously, HTTP APIs enabled customers to only build APIs for their serverless applications or to proxy requests to HTTP endpoints.
  • You can create data mapping definitions from an HTTP API’s method request data (e.g. path parameters, query string, and headers) to the corresponding integration request parameters and from the integration response data (e.g. headers) to the HTTP API method response parameters.
  • Use wildcard custom domain names (*.example.com) to create multiple URLs that route to one API Gateway HTTP API.
  • You can configure your custom domain name to route requests to different APIs. Using multi-level base path mappings, you can implement path-based API versioning and migrate API traffic between APIs according to request paths with many segments.

• All of the APIs created expose HTTPS endpoints only. API Gateway does not support unencrypted (HTTP) endpoints.

Monitoring

• • API Gateway console is integrated with CloudWatch, so you get backend performance metrics such as API calls, latency, and error rates.
  • You can set up custom alarms on API Gateway APIs.
  • API Gateway can also log API execution errors to CloudWatch Logs.

Security

• • To authorize and verify API requests to AWS services, API Gateway can help you leverage signature version 4. Using signature version 4 authentication, you can use IAM and access policies to authorize access to your APIs and all your other AWS resources.
  • You can enable AWS WAF for your APIs in Amazon API Gateway, making it easier to protect your APIs against common web exploits such as SQL injection and Cross-Site Scripting (XSS).
  • For API Gateway HTTP APIs, in addition to the previously supported OIDC/OAuth2 authorization option, you can also secure them using Lambda authorizers and IAM authorizers.

Pricing

• • You pay only for the API calls you receive and the amount of data transferred out.
  • API Gateway also provides optional data caching charged at an hourly rate that varies based on the cache size you select.

AWS Server Migration Service (SMS)

 

• An agentless service for migrating thousands of on-premises workloads to AWS. This is the enhanced replacement of Amazon EC2 VM Import service.
• SMS orchestrates server migrations by:
  • automating incremental replication of live server volumes to the AWS cloud
  • allowing customers to schedule replications
  • track the replication progress of a group of servers via Management Console
• Each server volume replicated is saved as a new Amazon Machine Image (AMI), which can be launched as an EC2 instance in the AWS cloud. If you are using application groupings, Server Migration Service will launch the servers in a CloudFormation stack using an auto-generated CloudFormation template.
• AWS SMS creates a new EBS snapshot with every replication.  It replicates server volumes from your on-premises environment to S3 temporarily and purges them from S3 right after creating EBS snapshots.
• You can migrate virtual machines from VMware vSphere and Windows Hyper-V to AWS.
• You can replicate your on-premises servers to AWS for up to 90 days (per server). After that, your replication job will be automatically terminated. This duration can be increased by submitting a request to AWS.
• Customers are able to migrate large volumes up to 16 TB.


• AWS Server Migration Service Connector
  • A pre-configured FreeBSD virtual machine (in OVA format). You need to first deploy the SMS Connector virtual appliance on each of your on-premises VMware vCenter environment to use AWS SMS.
  • The AWS Server Migration Service Connector supports password-based proxy, but not NTLM-based proxy.
  • The SMS Connector can be configured to use SCVMM or standalone Hyper-V VMs.
  • You need two separate SMS Connectors to simultaneously migrate VMs from both VMware and Hyper-V environments.

• AWS Server Migration Service offers multi-server migration support as well. You can migrate entire application stacks rather than migrating each server individually. This is done through an auto-generated CloudFormation template (non-modifiable).
• AWS Server Migration Service has the ability to resume failed replication jobs, allowing you to take remedial action and resume the replication from the point it failed, as opposed to restarting the job. This adds resiliency to the migration process and allows you to complete large-scale server migrations in an efficient and timely manner.
• Security
  • Replicated server volumes are encrypted in transit by TLS.
  • AWS SMS Connector only captures basic VM inventory information and snapshots of server volumes from VMware vCenter and does not gather any sensitive information.
• Pricing
  • You incur charges with every S3 usage and EBS snapshot created by AWS SMS.