Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
28 commits
Select commit Hold shift + click to select a range
ccff86a
Add section header for EC2 connection instructions
Chirantana-g-156 Jul 18, 2026
3301c5b
Create Understanding deployment yaml file
Chirantana-g-156 Jul 20, 2026
14965ad
Enhance comments in deployment YAML file
Chirantana-g-156 Jul 20, 2026
fd3dad1
Update Understanding deployment yaml file
Chirantana-g-156 Jul 20, 2026
10ba482
Create Understanding srv yaml file
Chirantana-g-156 Jul 20, 2026
7005106
Clarify targetPort with comment in srv yaml file
Chirantana-g-156 Jul 20, 2026
1337614
Create serviceaccount yaml file
Chirantana-g-156 Jul 20, 2026
4c0a96a
Update serviceaccount yaml file
Chirantana-g-156 Jul 20, 2026
f1ce763
Add complete-deploy yaml for microservices deployment
Chirantana-g-156 Jul 20, 2026
348cdd1
Update Understanding deployment yaml file
Chirantana-g-156 Jul 21, 2026
ee8b9da
Change service type to NodePort for external access
Chirantana-g-156 Jul 21, 2026
fb9b8ea
Create load balancer service type
Chirantana-g-156 Jul 21, 2026
3845f59
Update load balancer service type
Chirantana-g-156 Jul 22, 2026
68c78da
Create downsides of LB.md
Chirantana-g-156 Jul 22, 2026
b9a3bc7
Create ingress yaml file
Chirantana-g-156 Jul 22, 2026
18f511f
Rename Understanding deployment yaml file to 03-Understanding deploym…
Chirantana-g-156 Jul 22, 2026
298d658
Rename Understanding srv yaml file to 04-Understanding srv yaml file
Chirantana-g-156 Jul 22, 2026
75c1f9c
Rename file for changing service type to NodePort
Chirantana-g-156 Jul 22, 2026
318d930
Rename load balancer service type to 05-load balancer service type
Chirantana-g-156 Jul 22, 2026
4f27604
Rename downsides of LB.md to 05-downsides of LB.md
Chirantana-g-156 Jul 22, 2026
7b4698e
Rename ingress yaml file to 08-ingress yaml file
Chirantana-g-156 Jul 22, 2026
aa346fe
Create flow.md
Chirantana-g-156 Jul 26, 2026
28d08b1
Create Route53.md
Chirantana-g-156 Jul 27, 2026
261f656
Create CICD overview.md
Chirantana-g-156 Jul 27, 2026
2bb87c4
Update CICD overview.md
Chirantana-g-156 Jul 27, 2026
6c22726
Create CI.yaml file.md
Chirantana-g-156 Jul 27, 2026
d84e75b
Add CI pipeline for Product Catalog Service
Chirantana-g-156 Jul 27, 2026
7e57777
Update CI.yaml
Chirantana-g-156 Jul 27, 2026
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
863 changes: 863 additions & 0 deletions flow.md

Large diffs are not rendered by default.

398 changes: 398 additions & 0 deletions section-10/Route53.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,398 @@
Good. Since you already know DNS, let's focus on **what Route 53 adds**.

---

# First, what is Route 53?

**Amazon Route 53 is AWS's managed DNS service.**

Think of it like this:

```text
DNS = The concept (phonebook of the Internet)

Route 53 = AWS's implementation of DNS
```

Just like:

```text
Kubernetes = Container orchestration

EKS = AWS's implementation of managed Kubernetes
```

---

# Without Route 53

Suppose your website is running on an AWS Load Balancer.

AWS gives you:

```text
my-alb-123456.us-east-1.elb.amazonaws.com
```

Imagine asking users to visit:

```text
https://my-alb-123456.us-east-1.elb.amazonaws.com
```

Not practical.

Instead you want:

```text
https://amazon.com
```

---

# What Route 53 does

Route 53 simply maps

```text
amazon.com
```

to

```text
my-alb-123456.us-east-1.elb.amazonaws.com
```

Now the user only remembers

```text
amazon.com
```

---

# Complete Flow

Suppose you type

```text
amazon.com
```

Your browser asks

```text
What is the IP for amazon.com?
```

Route 53 replies

```text
amazon.com


my-alb-123456.elb.amazonaws.com
```

Then AWS DNS resolves that further to the current IP address(es) of the load balancer.

Finally

```text
Browser


AWS Load Balancer


Ingress Controller


Payment Service


Payment Pod
```

---

# Why not directly map to an EC2 IP?

Suppose you mapped

```text
amazon.com


18.220.15.10
```

Now imagine that EC2 crashes.

AWS creates another one.

New IP

```text
18.220.40.25
```

Your DNS is now wrong.

Everyone gets

```text
Server Not Found
```

---

Instead

```text
amazon.com


AWS Load Balancer
```

The Load Balancer always knows which EC2 instances are healthy.

So DNS **never changes**.
Comment on lines +157 to +169

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== locate file =="
fd -a 'Route53\.md$' . || true

echo "== relevant section =="
if [ -f section-10/Route53.md ]; then
  cat -n section-10/Route53.md | sed -n '130,190p'
else
  file="$(fd 'Route53\.md$' . | head -n1)"
  [ -n "${file:-}" ] && cat -n "$file" | sed -n '130,190p'
fi

echo "== surrounding concepts =="
rg -n "Route 53|Load Balancer|ALB|DNS|IP|healthy|changes|hostname|route53" section-10/Route53.md

Repository: iam-veeramalla/ultimate-devops-project-aws

Length of output: 3193


Avoid saying DNS “never changes.”

The Route 53 record can remain stable while the Load Balancer’s DNS-resolved addresses change. Prefer wording such as: “the application hostname does not need to change.”

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@section-10/Route53.md` around lines 157 - 169, Update the Route 53/load
balancer explanation to avoid claiming that DNS never changes. Clarify that the
application hostname or Route 53 record can remain stable while the load
balancer’s DNS-resolved addresses change, using wording such as “the application
hostname does not need to change.”


---

# In Kubernetes

Now connect this to everything you've learned.

Suppose you deployed your application on EKS.

You have

```text
Pods


Services


Ingress


AWS Application Load Balancer
```

AWS creates

```text
my-alb-123456.us-east-1.elb.amazonaws.com
```

Then Route 53 maps

```text
shop.com


my-alb-123456.us-east-1.elb.amazonaws.com
```

Now when someone types

```text
shop.com/payment
```

the journey is

```text
Browser
Route 53
(shop.com → ALB)
AWS Application Load Balancer
Ingress Controller
Ingress Rules
Payment Service
Payment Pod
Comment on lines +219 to +241

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== locate file and relevant lines =="
git ls-files | grep -F 'section-10/Route53.md' || true
if [ -f section-10/Route53.md ]; then
  wc -l section-10/Route53.md
  echo "--- lines 200-250 ---"
  sed -n '200,250p' section-10/Route53.md | nl -ba -v200
  echo "--- lines 375-405 ---"
  sed -n '375,405p' section-10/Route53.md | nl -ba -v375
fi

echo "== search for Load Balancer Controller mention / Ingress path context =="
if [ -f section-10/Route53.md ]; then
  rg -n "Load Balancer Controller|Load Balancer|Ingress Controller|Route 53|ALB|Application Load Balancer" section-10/Route53.md
fi

Repository: iam-veeramalla/ultimate-devops-project-aws

Length of output: 327


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== lines 200-250 =="
sed -n '200,250p' section-10/Route53.md | awk '{printf "%5d\t%s\n", NR+199, $0}'

echo "== lines 375-405 =="
sed -n '375,405p' section-10/Route53.md | awk '{printf "%5d\t%s\n", NR+374, $0}'

echo "== occurrences of relevant terms =="
grep -nE "Load Balancer Controller|Alb|ALB|Ingress Controller|Route 53|Application Load Balancer|Payment Service|Payment Pod" section-10/Route53.md || true

echo "== nearby AWS Load Balancer Controller usage sections =="
grep -n "AWS Load Balancer Controller" section-10/Route53.md || true

Repository: iam-veeramalla/ultimate-devops-project-aws

Length of output: 3362


🌐 Web query:

Kubernetes AWS Load Balancer Controller Ingress resource controller reconciles configuration AWS ALB runtime proxy

💡 Result:

The AWS Load Balancer Controller manages the lifecycle and configuration of AWS Application Load Balancers (ALBs) by continuously monitoring Kubernetes Ingress resources and reconciling their desired state with the actual infrastructure in AWS [1][2][3]. Reconciliation Process The controller operates as a standard Kubernetes controller using a continuous reconciliation loop [4]. The process generally follows these steps: 1. Monitoring: The controller watches the Kubernetes API for the creation, modification, or deletion of Ingress resources that match its configured IngressClass (defaulting to alb) [1][5][6]. 2. Processing: When a change is detected, the resource is queued [1][5]. The controller calculates an intermediate representation of the required AWS resources [4]. 3. Mapping and Execution: The Ingress definition—including path-based rules, hostnames, and annotations—is mapped to AWS components, including the ALB itself, listeners, listener rules, and target groups [1][2][3]. The controller then makes AWS API calls to create, update, or delete these components to match the desired state [2][4]. 4. Status Updates: After reconciliation, the controller updates the status field of the Ingress resource, providing feedback such as the load balancer's DNS name [1][5]. Configuration and Runtime Proxy The controller does not manually configure an "ALB runtime proxy" in the sense of a standalone software layer; rather, it configures the AWS ALB itself to act as the traffic manager for the cluster [3]. Users control this configuration primarily through Kubernetes Ingress annotations and the Ingress resource specification [1][2]. For example, to configure proxy protocol (which ensures that the original client IP is preserved when using certain load balancer configurations), you can use annotations such as service.beta.kubernetes.io/aws-load-balancer-proxy-protocol [7][8]. Because the controller manages these configurations, users should avoid making out-of-band modifications directly via the AWS Console or CLI, as the controller may revert these manual changes during its next reconciliation cycle [1][6]. The controller is designed for high availability, typically using an active-passive leadership model where only the leader replica modifies the AWS state, while others assist with validation [4]. Synchronisation of all resources is also enforced periodically (default is 10 hours) to ensure consistency [6].

Citations:


Show only runtime traffic hops after DNS resolution.

Route 53 only resolves shop.com to the ALB DNS name; the HTTP request flow should not include Route 53 or the Load Balancer Controller. Keep the DNS lookup separate, then document the actual runtime path: ALB → backend pods/service. This also applies to the call-out block starting at line 388.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@section-10/Route53.md` around lines 219 - 241, Update the journey diagram and
the call-out block around the payment request flow to separate Route 53 DNS
resolution from runtime traffic. Remove Route 53 and the Load Balancer
Controller from the HTTP hop sequence, and show the runtime path as ALB →
ingress rules/controller as applicable → backend service/pods, preserving only
actual request hops after resolution.

```

---

# Why is it called Route **53**?

This is a common interview question.

DNS servers communicate over **port 53**.

Both:

* UDP 53 (most DNS queries)
* TCP 53 (large responses, zone transfers)

AWS named the service **Route 53** after the DNS port.

---

# Besides DNS mapping, what else can Route 53 do?

This is where it becomes more powerful than a basic DNS server.

Suppose your application is deployed in two AWS regions.

```text
India


ALB (Mumbai)
```

```text
Germany


ALB (Frankfurt)
```

Route 53 can intelligently decide where to send users.

Examples:

### 1. Latency-based routing

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Fix the heading hierarchy.

Change this heading to ## 1. Latency-based routing so it does not jump from H1 to H3; apply the same level to the following routing headings.

🧰 Tools
🪛 markdownlint-cli2 (0.23.0)

[warning] 287-287: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3

(MD001, heading-increment)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@section-10/Route53.md` at line 287, Update the “1. Latency-based routing”
heading and the following routing headings to level-two Markdown headings,
ensuring the section hierarchy does not jump from H1 to H3.

Source: Linters/SAST tools


```text
Indian User


Mumbai ALB
```

```text
German User


Frankfurt ALB
```

---

### 2. Health checks

Suppose the Mumbai ALB goes down.

Normally users would get errors.

Route 53 continuously checks health.

If Mumbai fails:

```text
Indian User


Frankfurt ALB
```

Automatically.
Comment on lines +307 to +325

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Inspect the surrounding Route53 content and nearby references to health checks/failover.
if [ -f section-10/Route53.md ]; then
  echo "== section-10/Route53.md line count =="
  wc -l section-10/Route53.md
  echo "== lines 260-345 =="
  sed -n '260,345p' section-10/Route53.md | nl -ba -v260
else
  echo "section-10/Route53.md not found"
  fd -i 'Route53\.md$' .
fi

echo "== references to health, failover, alternate, routing policy, latency, failover =="
rg -n --ignore-case 'health |failover|alternate|routing policy|latency|Weighted|Mumbai|Frankfurt' section-10/Route53.md section-10 2>/dev/null || true

Repository: iam-veeramalla/ultimate-devops-project-aws

Length of output: 305


🌐 Web query:

AWS Route 53 failover routing policy health check alternate record configuration

💡 Result:

To configure AWS Route 53 failover routing, you create two records—a primary and a secondary—with the same name and type, both using the Failover routing policy [1][2][3]. Key Configuration Details: 1. Record Setup: You must create both a primary record and a secondary record [2][3]. Set the Failover record type accordingly for each [4][3]. 2. Health Checks: - Primary Record: Typically associated with a health check to monitor the primary resource [5][3]. When the health check determines the primary resource is unhealthy, Route 53 routes traffic to the secondary record [5][2]. - Secondary Record: Associating a health check is optional [5]. If you do not associate a health check with the secondary record, Route 53 will consider it healthy by default and route traffic to it if the primary record fails [5]. If you do associate a health check, Route 53 will only use the secondary record if it is also confirmed as healthy [5]. 3. Alias Records & Evaluate Target Health: If you are using alias records (e.g., pointing to an Elastic Load Balancer or S3 bucket), you can enable Evaluate Target Health [6][2]. This allows Route 53 to automatically monitor the health of the AWS resource itself without needing a separate, manually configured health check [6]. When set to Yes, Route 53 treats the record as unhealthy if the alias target is unhealthy [6][2]. Best Practices: - Avoid associating a health check that monitors the same domain name as the records themselves, as this can lead to unpredictable health check results [7]. Instead, monitor specific endpoints (e.g., individual server IPs or specific load balancer endpoints) [7]. - If you have complex routing needs, consider using Route 53 Traffic Flow, which provides a visual editor to manage these configurations and ensures health checks are correctly applied [6]. - When both primary and secondary records are unhealthy (and both have health checks), Route 53 will generally revert to returning the primary record [5].

Citations:


🏁 Script executed:

#!/bin/bash
set -u

echo "== lines 260-345 of section-10/Route53.md =="
awk 'NR>=260 && NR<=345 {printf "%8d  %s\n", NR, $0}' section-10/Route53.md

echo "== references to health, failover, alternate, routing policy, latency, weighted, Mumbai, Frankfurt =="
grep -InE 'health (check|evaluation)|failover|alternate|routing policy|latency|Weighted|Mumbai|Frankfurt' section-10/Route53.md || true

Repository: iam-veeramalla/ultimate-devops-project-aws

Length of output: 2139


Make failover conditional on Route 53 configuration.

Route 53 will not redirect Mumbai traffic to Frankfurt just because an ALB is unhealthy. Mention the required failover configuration, such as an alternate secondary record with failover routing and health evaluation/associated health check.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@section-10/Route53.md` around lines 307 - 325, Update the “Health checks”
explanation to state that Route 53 redirects Mumbai traffic to Frankfurt only
when failover routing is configured. Mention the required primary and secondary
records, with the secondary targeting Frankfurt and health evaluation or an
associated health check enabled.


---

### 3. Weighted routing

Suppose you're testing a new version.

```text
90% Traffic


Version 1
```

```text
10% Traffic


Version 2
```

Very useful for canary deployments.
Comment on lines +329 to +349

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

AWS Route 53 weighted routing policy DNS caching approximate traffic distribution

💡 Result:

AWS Route 53 weighted routing distributes traffic based on the relative weights assigned to records, but the distribution is statistical and approximate rather than an active load-balancing mechanism that functions on a per-request basis [1][2][3]. Because Route 53 operates at the DNS layer, its influence on traffic routing is constrained by DNS caching behavior [1][4][5]. Key factors affecting traffic distribution: 1. DNS Caching and TTL: When a recursive DNS resolver receives a response from Route 53, it caches that result for the duration of the Time to Live (TTL) value [1][6][7]. During this window, all clients relying on that specific resolver will be directed to the same endpoint, regardless of the weighted distribution configured in Route 53 [1][5]. This often leads to skewed or "sticky" traffic patterns, especially for small volumes of requests or when testing from a single client machine [4][3]. 2. Statistical Nature: Route 53 applies the weighting policy only when it receives an actual DNS query [4]. Because many clients and intermediate resolvers cache these results, the intended traffic split is only realized over a larger aggregate of queries originating from diverse sources [1][3]. Over time and across a sufficient volume of queries, the distribution tends to converge toward the configured weights [3]. 3. TTL Configuration: The TTL value is the primary lever for controlling the granularity of traffic distribution [5][8]. A shorter TTL (e.g., 60 seconds or less) forces recursive resolvers to query Route 53 more frequently, allowing for more responsive and accurate adherence to the weighted policy [7][5][8]. However, lower TTLs also increase query volume and associated costs [6][9][8]. In summary, weighted routing is not a substitute for an application-layer load balancer. If precise, real-time traffic splitting is required, Route 53 weighted routing should be used in conjunction with a load balancer (such as an Application Load Balancer), or by accepting that distribution will be approximate and influenced by the caching behavior of global DNS resolvers [2][5][3].

Citations:


🏁 Script executed:

#!/bin/bash
set -euo pipefail

if [ -f section-10/Route53.md ]; then
  echo "== file exists =="
  wc -l section-10/Route53.md
  echo "== weighted routing section =="
  sed -n '300,370p' section-10/Route53.md
else
  echo "section-10/Route53.md not found"
  fd -i 'Route53\.md$'
fi

Repository: iam-veeramalla/ultimate-devops-project-aws

Length of output: 940


Call weighted routing approximate traffic splitting.

Route 53 weighted policies control DNS responses, not active load balancing, so resolver/client caching can make a 90/10 configuration skew per-client. Describe this as approximate when presenting it as a canary strategy.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@section-10/Route53.md` around lines 329 - 349, Update the “Weighted routing”
explanation to describe the 90%/10% split as approximate rather than exact.
Clarify that Route 53 weighted policies distribute DNS responses and resolver or
client caching can cause per-client traffic to skew, while preserving the canary
deployment example.


---

# Mental Picture

Think of the entire Internet like this:

```text
You want to visit "Amazon"

Ask Route 53
("Where is amazon.com?")
Route 53 replies
("Go to this AWS Load Balancer")
AWS Load Balancer
("I'll forward you into the Kubernetes cluster")
Ingress Controller
("Which microservice do you need?")
Payment Service
("I'll choose a healthy Pod")
Payment Pod
("Here's your response")
```

---

## The role of Route 53 in one sentence

**Route 53 does not know anything about Pods, Services, or Kubernetes. Its only job is to answer the question: "When someone types this domain name, where should they go?"**

Once it points the request to your AWS Load Balancer, Kubernetes takes over. That's why in an EKS architecture:

* **Route 53** gets the request to your cluster.
* **AWS Load Balancer** receives the traffic.
* **Ingress Controller** decides which Service should handle it.
* **Service** chooses a healthy Pod.
* **Pod** runs your application.
Loading