Skip to main content

AWS SOA-C02 Drill: Route 53 Routing Policies - Geolocation vs Latency Routing

Jeff Taakey
Author
Jeff Taakey
21+ Year Enterprise Architect | AWS SAA/SAP & Multi-Cloud Expert.

The Jeff’s Note (Contextual Hook)
#

Jeff’s Note
#

Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Site Reliability Engineer (SRE).

For SOA-C02 candidates, the confusion often lies in distinguishing routing policies that route based on user location versus latency metrics. In production, this is about knowing exactly which Route 53 policy to implement to direct traffic by geography rather than performance. Let’s drill down.

The Certification Drill (Simulated Question)
#

Scenario
#

TechNova Corp operates a popular consumer-facing web portal hosted primarily in the AWS us-east-1 Region. As part of their global expansion, they are deploying an identical copy of the website infrastructure in eu-west-1 to better serve European users and improve regional fault tolerance. Their DNS is managed via Amazon Route 53.

The Requirement:
#

Visitors located within European countries should be routed to the eu-west-1 hosted website, while all other visitors around the globe should be directed to the us-east-1 hosted website instance. The company wants to implement this routing logic using Route 53.

The Options
#

  • A) Geolocation routing policy
  • B) Geoproximity routing policy
  • C) Latency routing policy
  • D) Multivalue answer routing policy

Google adsense
#

leave a comment:

Correct Answer
#

A) Geolocation routing policy

Quick Insight: The SysOps Imperative
#

The critical nuance for SREs is that Geolocation routing allows routing decisions strictly based on the geographic location of the DNS resolver’s IP address, perfect for this “route European users to Europe” use case.

Latency routing routes based on lowest network latency rather than specific geography, which may not stick Europe users strictly to Europe.

Geoproximity routing is more complex and requires using Route 53 traffic weights combined with AWS resource health check regions, generally not needed here.

Multivalue answers provide DNS-level failover but don’t route specifically by geography.

Content Locked: The Expert Analysis
#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?


The Expert’s Analysis
#

Correct Answer
#

Option A: Geolocation routing policy

The Winning Logic
#

Geolocation routing policy in Route 53 allows DNS queries to be answered based on the physical location of the user’s DNS resolver. Since the requirement is to direct all European visitors to the eu-west-1 website and everyone else to us-east-1, geolocation routing is the most straightforward method to achieve this. It supports granular region-level or continent-level differentiation and does not depend on network conditions or latency measurements.

  • When a DNS resolver inside Europe makes a request, Route 53 returns the IP address of the European site.
  • Resolvers outside Europe receive DNS records pointing to the US site.

This traffic segregation is both explicit and stable, critical for compliance or user experience scenarios requiring strict geographic routing.

The Trap (Distractor Analysis):
#

  • Option B: Geoproximity routing policy
    Geoproximity routing uses geographic bias and resource weights to influence routing but requires Route 53 traffic flow or must be combined with health checks. It is more suited for shifting traffic gradually between endpoints or weighting, not strict geographic segmentation.

  • Option C: Latency routing policy
    Latency routing directs users to the AWS endpoint with the best network latency, regardless of geography. This can send a European visitor to US if that path is faster, violating explicit geographic segmentation.

  • Option D: Multivalue answer routing policy
    This provides DNS-level load balancing and health checks but does not support geography-based routing. It is best for providing multiple healthy endpoints for client-side load balancing.


The Technical Blueprint
#

B) For SysOps (Code/CLI Snippet):

To create a geolocation routing policy in Route 53 using AWS CLI, the JSON snippet for a Route 53 record set might look like this:

aws route53 change-resource-record-sets --hosted-zone-id Z3EXAMPLE123 \
--change-batch '{
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.technova.example.com",
        "Type": "A",
        "SetIdentifier": "Europe",
        "GeoLocation": {
          "ContinentCode": "EU"
        },
        "TTL": 60,
        "ResourceRecords": [
          {
            "Value": "EUROPE_WEBSITE_IP"
          }
        ]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "www.technova.example.com",
        "Type": "A",
        "SetIdentifier": "Default",
        "TTL": 60,
        "ResourceRecords": [
          {
            "Value": "US_WEBSITE_IP"
          }
        ]
      }
    }
  ]
}'

This specifies a geolocation record for Europe, and a default record for all other visitors.


The Comparative Analysis
#

Option Operational Overhead Automation Level Impact on User Routing
A) Geolocation Routing Moderate (needs regional records) Can be scripted via CLI/CloudFormation Strict geographic routing (correct fit)
B) Geoproximity Routing Higher (requires weights and bias) Medium Weighted geographic proximity, not absolute
C) Latency Routing Low High Sends users to lowest latency region, ignoring strict geography
D) Multivalue Answer Low Medium Provides multiple endpoint answers, no geographic routing

Real-World Application (Practitioner Insight)
#

Exam Rule
#

For the exam, always pick Geolocation Routing when you see keywords like “route users based on their geographic region.”

Real World
#

In actual deployments, companies sometimes pair geolocation routing with latency-based routing for improved performance within regions, but strict geographic segmentation always starts with geolocation policy.


(CTA) Stop Guessing, Start Mastering
#


Disclaimer

This is a study note based on simulated scenarios for the SOA-C02 exam.

The DevPro Network: Mission and Founder

A 21-Year Tech Leadership Journey

Jeff Taakey has driven complex systems for over two decades, serving in pivotal roles as an Architect, Technical Director, and startup Co-founder/CTO.

He holds both an MBA degree and a Computer Science Master's degree from an English-speaking university in Hong Kong. His expertise is further backed by multiple international certifications including TOGAF, PMP, ITIL, and AWS SAA.

His experience spans diverse sectors and includes leading large, multidisciplinary teams (up to 86 people). He has also served as a Development Team Lead while cooperating with global teams spanning North America, Europe, and Asia-Pacific. He has spearheaded the design of an industry cloud platform. This work was often conducted within global Fortune 500 environments like IBM, Citi and Panasonic.

Following a recent Master’s degree from an English-speaking university in Hong Kong, he launched this platform to share advanced, practical technical knowledge with the global developer community.


About This Site: AWS.CertDevPro.com


AWS.CertDevPro.com focuses exclusively on mastering the Amazon Web Services ecosystem. We transform raw practice questions into strategic Decision Matrices. Led by Jeff Taakey (MBA & 21-year veteran of IBM/Citi), we provide the exclusive SAA and SAP Master Packs designed to move your cloud expertise from certification-ready to project-ready.