AWS Learn In Public Week 4, Route53 and VPC

The AWS learning challenge continues. This week was about Route53 which is literally the first time I touch this service and then some deeper dive into VPCs. Route53 gives a lot of flexibility and customisation but it is quite expensive for buying new domains and also you have to pay to transfer your domain which was a bummer. Nevertheless I gave it a try and it now makes a lot of sense.

Afterwards, in the VPC section there were some a bit advanced topic which I have to admit are difficult to make sense in a tweet. One of the biggest advantages I have seen so far is that it is a lot easier to follow devops related conversations and understand why certain decisions were made. Enough with me blabbing let's go to the content.

Route53

Let’s talk about AWS Route53

It is a managed DNS (Domain Name System) service which contains a collection of rules and records for reaching a server through its domain name

The most common records include

• A which is a hostname to IPv4
• AAAA which is hostname to IPv6
• CNAME which is hostname to hostname
• Alias which is hostname to an AWS resource like ELB

CNAME vs Alias

Let's do a comparison of when to use CNAME vs Alias in AWS Route53

AWS resources expose a hostname that looks like

http://abc-123.eu-west-2.elb.amazonaws.com. You want that to point to http://yoursite.example.com

The CNAME points a hostname to another hostname. Only for non root domains

e.g. http://yoursite.example.com -> http://another.site.com

An Alias points a hostname to an AWS resource, is free and provides native health check

e.g. http://another.site.com -> http://abc-123.eu-west-2.elb.amazonaws.com

Route 53 Overview

Let's do an overview of AWS Route53

It can use

🔓 Public domain names you own

🔒 Private domains within your VPC

Advanced features

⚖ Client load balancing (through DNS)

🩺 Health checks

📃 Multiple routing policies

Each site lives in a hosted zone which is $0.50 per month

Route53 Routing policies

Let's talk about AWS Route53 routing policies

Weighted routing policy

Control the % of the requests that go to specific endpoints

Helpful for AB testing

Helpful for splitting traffic between regions

Can be associated with health checks

Latency routing policy

Redirect to the server that has the least latency close to us

Latency of users is a priority

Latency is evaluated in terms of users designated AWS region

Some from Greece can be redirected to the UK is the latency is lower

Failover Routing Policy

Route53 does a health check to the primary instance

If it is unhealthy then Route53 will failover to the secondary instance (Disaster Recovery)

Geo Location routing policy

Routing based on location

Different from latency based policy

Traffic form the UK should go to specific IP

Should create a default policy in case there's no match

Multi Value routing policy

Use when routing traffic to multiple resources

Want to associate Route53 health checks with records

Up to 8 healthy records are returned for each Multi Value query

Multi Value is not a substitute of having an ELB

Route53 health checks

Finally let's talk about health checks in AWS Route53

We ping a server and expect it to respond

A server becomes unhealthy when X health checks fail (default is 3)

Then when Y health checks pass it is marked as healthy (default is 3)

The default interval is 30s between each health check but can be set to 10s but it's more expensive

There are around 15 health checkers that will check the endpoint health

That means that there's 1 request every 2 seconds for the default interval

There are HTTP, TCP and HTTPS healthchecks and don't use SSL verification

We can integrate them with CloudWatch

As we saw in the routing policies, health checks can be linked to Route53 DNS queries

VPC Summary

Let's do a summary of VPC components in AWS

☁️ VPC: A private network (Virtual Private Cloud) to deploy your resources

🆎 AZ: Availability Zones, different data centres in a AWS region

📡 Internet Gateway: At the VPC level to provide Internet Access

🚦 NAT Gateway / Instances: Giving internet access to private subnets

🚥 NACL: Stateless subnet rules for inbound and outbound traffic

🛡 Security Groups: Stateful rules that operate at the EC2 instance level or ENI (Elastic Network Interfaces)

🤝 VPC Peering: Connect 2 VPCs with non overlapping IP ranges

📃 VPC Flow logs: Logs for network traffic

🔐 Site to Site VPN: VPN over public internet between on-premises data centre and AWS

🔌 Direct Connect: Direct private connection to AWS

3 tier solution architecture

Let's talk about a typical 3 tier solution architecture in AWS

1. Public subnet

Route53 talking to our ELB
Our public ELB

2. Private subnet

Our EC2 Instances
ASG amongst AZs
ELB connects to EC2 instances using route tables

3. Data subnet

RDS & ElastiCache

Internet Gateways and NAT Gateways / instances

Let's talk about AWS IGWs (Internet Gateway) and NAT gateways / instances

• IGWs help our VPC instances connect to the internet with Public Subnets
• NAT Gateways and NAT instances allow our VPC instances in your Private Subnets to access the internet while remaining private

In simple words

• If we want to give internet access to a VPC in a Public Subnet then we need a IGW
• If the VPC is in a Private Subnet then we need a NAT gateway (AWS managed) or a NAT instance (self managed)

Security Groups and NACL

Let's talk about AWS Network security with NACLs (Network ACL) and SGs (Security Group)

🔥 Network ACL is a firewall which controls traffic to and from subnets

🚦 Supports Allow and Deny rules

📗 Attached at the subnet level and only allow rules for IP addresses

Security groups are firewalls which control traffic to and from an ENI (Elastic Network Interface) or EC2 instance

✅ Can only have ALLOW rules

📒 Can include IP addresses and other security groups

Security Groups VS NACL

Let's do a quick comparison of AWS SG (Security Groups) vs NACL (Network Access Control Lists)

For SGs

• Operate at the instance level
• Support allow rules only
• Stateful: Traffic is automatically allowed regardless of any rules
• Rules need to be evaluated before deciding whether to allow traffic
• Can be applied when launching the instance or can be edited later on

For NACLs

• Operate at the subnet level
• Support allow and deny rules
• Stateless: Traffic to be explicitly allowed by the rules
• Process rules in order when deciding to allow traffic
• Automatically applies to all instances in the subnets and doesnt rely on users creating SGs

VPC Flow logs

Let's talk about AWS VPC Flow logs

• Capture information about IP traffic into your interfaces (VPC, Subnet Flow Logs, ENI Flow Logs)
• Helps to monitor and troubleshoot connectivity issues like Subnets to the internet, Subnets to other Subnets and Internet to Subnets
• Captures network information from AWS managed interfaces too. (ELB, ElastiCache, RDS etc)
• VPC Flow logs data can go to S3 or CloudWatch logs

VPC Peering

Let's talk about AWS VPC

• It is a connection for allowing 2 VPC being part of the same network
• They are privately connection and they behave like they are on the same network.
• They must not have overlapping IP address ranges (CIDR)
• VPC peering connections are not transitive
  • VPC1 is connected to VPC2
  • VPC2 is connected to VPC3
  • VPC1 is NOT connected to VPC3

VPC Endpoints

Let's talk about AWS VPC Endpoints

• They allow you to connect to AWS services using a private network instead of a public one
• That results in enhanced security and lower latency to access AWS services
• VPC Endpoints gateways are popular for S3 and DynamoDB
• For all the rest of the AWS services we have VPC Endpoint Interfaces
• VPC Endpoints are only used within your VPC

Site to Site VPN and Direct Connect

To close the VPC section, let's talk about AWS Site to Site VPN and Direct Connect

Site to Site VPN is for connecting at on-premises VPN to AWS with an automatically encrypted public connection

Direct Connect (DX) is a physical connection between on premises and AWS. That connection is private, secure and fast. However, it takes at least a month to establish.

Note. Neither of them can access VPC endpoints

Summary

Route53 was a lot more interesting than originally anticipates. It had some great examples of ways we can split traffic which I thought would normally be handled by the load balancer. Then diving deeper into VPCs was quite interesting because they are great for sharpening my networking skills which are not my strongest card.

I would love to hear from you about the format and any suggestions on how to make this challenge more beneficial for the people out there that follow my updates. Next week is all about S3!