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!
Top comments (0)