Skip to content

010-R53.md

Latest commit

 

History

History
299 lines (212 loc) · 10.2 KB

010-R53.md

File metadata and controls

299 lines (212 loc) · 10.2 KB

Manage Amazon Route 53 using the AWS Management Console UI.

Step 1: Accessing Route 53

  1. Log in to AWS Console:

  2. Navigate to Route 53:

    • In the AWS Management Console, in the search bar, type "Route 53" and click on the Route 53 service.

Step 2: Create a Hosted Zone

A hosted zone is a container for DNS records, and it's required to manage the DNS for a domain.

  1. Click on Hosted Zones:

    • In the left-hand navigation panel, click on Hosted zones.

  2. Create a Hosted Zone:

    • Click the Create hosted zone button at the top.

  3. Fill in the Hosted Zone Details:

    • Domain Name: Enter your domain name, for example, example.com.
    • Type: Choose Public hosted zone (since you want it to be accessible from the internet).
    • Comment: Optional, you can leave this blank or add a comment.
    • VPC: Leave it unassociated unless you want to associate it with a private VPC.
    • Click Create.

    Once created, you will see the hosted zone in your list, and it will have two default records:

    • NS (Name Server) record.
    • SOA (Start of Authority) record.

Step 3: Add a DNS Record

Now that you have a hosted zone, you can add DNS records (such as A, CNAME, MX, etc.).

  1. Click on the Hosted Zone:

    • In the Hosted Zones section, click on your hosted zone (e.g., example.com).

  2. Click Create Record:

    • At the top of the hosted zone, click Create record.

  3. Choose Record Type:

    • For this example, let’s create an A record (address record), which maps a domain to an IP address.
    • In the Record type dropdown, select A – IPv4 address.

  4. Fill in the Record Details:

    • Record name: Enter the subdomain or leave blank to point to the root domain. For example, for www.example.com, type www.
    • Value: Enter the IP address (e.g., 192.168.1.1).
    • TTL (Time to Live): Set the TTL (in seconds). A default of 300 seconds is often used.
    • Routing policy: Choose Simple routing (default). This works for basic setups.
    • Evaluate target health: Leave this option disabled unless you are setting up health checks.
    • Click Create records.

    You have now created an A record for www.example.com pointing to the IP 192.168.1.1.

Step 4: View and Edit DNS Records

  1. View Records:

    • In the hosted zone view, you’ll see the new A record you created.
    • If you added a subdomain, it will be listed as www.example.com.

  2. Edit a Record:

    • To modify a record, click on the edit icon (pencil) next to the record.
    • Update the Value, TTL, or other settings.
    • After making changes, click Save changes.

Step 5: Add More DNS Records (Optional)

You can create various types of records, such as:

  • CNAME Record (for aliasing another domain):

    • Choose CNAME – Canonical name as the record type.
    • Example: www → example.com (if you want www.example.com to point to example.com).

  • MX Record (for mail server routing):

    • Choose MX – Mail exchange as the record type.
    • Set the Value to the mail server address and priority.

  • TXT Record (for SPF or domain verification):

    • Choose TXT as the record type and add a text value (e.g., v=spf1 include:spf.example.com ~all).

Step 6: Test the DNS Resolution

Once the records have propagated (this can take some time), you can test them:

  1. Using the Command Line:

    • Open your terminal or command prompt.
    • Run the following command to check the DNS resolution: 
      nslookup www.example.com
    • This should return the IP address you configured.

  2. Using Online Tools:

    • Use online tools like DNSChecker to verify the propagation of your DNS records globally.

Step 7: Delete a DNS Record (Optional)

If you need to delete a DNS record:

  1. Go to Hosted Zone:

    • Click on your hosted zone in the AWS Route 53 console.

  2. Delete a Record:

    • Click the Delete button next to the record you want to remove (e.g., www.example.com).
    • Confirm the deletion.

Step 8: Monitor DNS Health (Optional)

Route 53 also offers health checks for your records. This is useful for ensuring that your website or server is up and running.

  1. Create Health Check:
    • In the Route 53 console, click on Health Checks in the left sidebar.
    • Click Create health check.
    • Configure the health check (e.g., monitor if a web server is reachable on http://www.example.com).
    • Link this health check to the relevant DNS record for automatic failover.

Amazon Route 53 provides multiple routing policies to handle traffic for your domain based on specific requirements. Below are examples and explanations for each routing policy with practical use cases.

1. Simple Routing Policy

This is the default routing policy, used to map a domain name to a single resource.

Example

  • Scenario: Map example.com to a single EC2 instance.
  • Configuration:
    • Record Type: A
    • Value: 192.0.2.1 (IP address of the EC2 instance)

Use Case

  • A static website hosted on a single EC2 instance or an S3 bucket.

2. Weighted Routing Policy

Distributes traffic based on weights assigned to multiple resources.

Example

  • Scenario: Distribute 70% of traffic to a primary server and 30% to a secondary server.
  • Configuration:
    • Record 1:
      • Name: example.com
      • Type: A
      • Value: 192.0.2.1 (Primary server)
      • Weight: 70
    • Record 2:
      • Name: example.com
      • Type: A
      • Value: 192.0.2.2 (Secondary server)
      • Weight: 30

Use Case

  • A/B testing or phased migration between different application versions.

3. Latency Routing Policy

Routes traffic to the resource with the lowest network latency based on the user’s location.

Example

  • Scenario: Serve users from the nearest region:
    • US-East (Virginia) for North American users.
    • AP-Southeast (Singapore) for Asian users.
  • Configuration:
    • Record 1:
      • Name: example.com
      • Type: A
      • Value: 192.0.2.1 (Virginia)
      • Region: us-east-1
    • Record 2:
      • Name: example.com
      • Type: A
      • Value: 192.0.2.2 (Singapore)
      • Region: ap-southeast-1

Use Case

  • Optimized user experience by reducing latency.

4. Failover Routing Policy

Routes traffic to a primary resource and redirects to a secondary resource in case of failure.

Example

  • Scenario: Use a primary EC2 instance and failover to a backup instance on failure.
  • Configuration:
    • Primary Record:
      • Name: example.com
      • Type: A
      • Value: 192.0.2.1 (Primary server)
      • Failover: Primary
      • Health Check: Enabled
    • Secondary Record:
      • Name: example.com
      • Type: A
      • Value: 192.0.2.2 (Backup server)
      • Failover: Secondary
      • Health Check: Enabled

Use Case

  • High availability for critical applications.

5. Geolocation Routing Policy

Routes traffic based on the geographic location of the user.

Example

  • Scenario: Direct North American users to US servers and European users to EU servers.
  • Configuration:
    • Record 1:
      • Name: example.com
      • Type: A
      • Value: 192.0.2.1 (US server)
      • Location: North America
    • Record 2:
      • Name: example.com
      • Type: A
      • Value: 192.0.2.2 (EU server)
      • Location: Europe

Use Case

  • Regulatory compliance or content localization.

6. Geoproximity Routing Policy (Traffic Flow Only)

Routes traffic based on the geographic location of resources and optionally shifts traffic by bias.

Example

  • Scenario: Redirect most traffic to US servers but allow some traffic to EU servers using bias.
  • Configuration:
    • Set up Route 53 Traffic Flow.
    • Use geoproximity with a bias of +10 for the US and -10 for the EU.

Use Case

  • Dynamic traffic shifting during events or regional promotions.

7. Multivalue Answer Routing Policy

Allows multiple records and performs health checks for each to ensure only healthy resources are returned.

Example

  • Scenario: Provide IP addresses for multiple servers, but exclude unhealthy ones.
  • Configuration:
    • Record 1:
      • Name: example.com
      • Type: A
      • Value: 192.0.2.1 (Server 1)
      • Health Check: Enabled
    • Record 2:
      • Name: example.com
      • Type: A
      • Value: 192.0.2.2 (Server 2)
      • Health Check: Enabled

Use Case

  • Load balancing across multiple resources with health checks.

8. IP-Based Routing (Resolver Rules)

Route traffic based on IP match rules for hybrid on-premise and cloud deployments.

Example

  • Scenario: Forward DNS queries for onprem.example.com to an on-premises DNS resolver.
  • Configuration:
    • Create a resolver rule to forward queries for onprem.example.com to the IP of the on-prem DNS resolver.

Use Case

  • Hybrid cloud setups with private DNS.

Comparison of Routing Policies

Routing Policy Use Case Key Feature
Simple Basic mapping One-to-one mapping
Weighted Load distribution Distribute traffic by weight
Latency Performance optimization Routes to the lowest-latency resource
Failover High availability Routes to backup resource on failure
Geolocation User-based routing Routes based on user location
Geoproximity Advanced geographic control Bias-based traffic shifting
Multivalue Answer Basic load balancing with health Returns multiple healthy endpoints