> ## Documentation Index
> Fetch the complete documentation index at: https://ai-kb.automationanywhere.com/llms.txt
> Use this file to discover all available pages before exploring further.

# EKB - AWS EKS (सेवाएँ और अवसंरचना) गाइड

> AWS EKS पर EKB सेवाओं की अवसंरचना के लिए वास्तुकला अवलोकन, घटक विवरण और डेटा प्रवाह।

यह दस्तावेज़ EKB सेवाओं की अवसंरचना के लिए AWS वास्तुकला का एक व्यापक अवलोकन प्रदान करता है। वास्तुकला AWS प्रबंधित सेवाओं, Kubernetes ऑर्केस्ट्रेशन और स्वचालित स्केलिंग के साथ क्लाउड-नेटिव पैटर्न का अनुसरण करती है।

***

# AWS वास्तुकला अवलोकन

वास्तुकला AWS प्रबंधित सेवाओं, Kubernetes ऑर्केस्ट्रेशन और स्वचालित स्केलिंग के साथ क्लाउड-नेटिव पैटर्न का अनुसरण करती है।

***

## वास्तुकला आरेख

```mermaid theme={null}
flowchart TD
    INTERNET["🌐 INTERNET"]
 
    DNS["DNS Provider
(Route 53 / Cloudflare / etc.)
──────────────────────────────
• app.your-domain — Web Frontend
• api.your-domain — FastAPI Backend
• automations.your-domain — Automator
• supabase.your-domain — Supabase Kong
• signoz.your-domain — SigNoz"]
 
    ALB["APPLICATION LOAD BALANCER
──────────────────────────────
• SSL Termination via ACM
• HTTP → HTTPS Redirect
• Health Checks & Target Groups
• Routing by hostname/path"]
 
    subgraph VPC["VPC"]
        subgraph PUB["Public Subnets (3 AZs)"]
            NAT["NAT Gateway × 3"]
        end
        subgraph PRIV["Private Subnets (3 AZs)"]
            NODES["EKS Worker Nodes"]
        end
    end
 
    subgraph EKS["EKS CLUSTER"]
        KARPENTER["KARPENTER — Dynamic Node Provisioning
──────────────────────────────
• Spot prioritisation & consolidation
• Interruption handling via SQS
• Node classes: general, compute-intensive, database"]
        KEDA["KEDA — Event-driven Pod Autoscaling
──────────────────────────────
• CPU / Memory threshold scaling
• Fast scale-down stabilisation"]
        PODS["APPLICATION PODS
──────────────────────────────
• Web Frontend (port 3000)
• FastAPI Backend (port 8001)
• Celery Workers
• Automator (port 80)
• Supabase services (Kong, Auth, Storage…)
• PostgreSQL Automator (port 5432)"]
        SIGNOZ["OBSERVABILITY — SigNoz (optional)
──────────────────────────────
• Distributed tracing, metrics, logs
• k8s-infra agent for cluster metrics"]
    end
 
    subgraph DATA["DATA LAYER"]
        REDIS["ELASTICACHE
(Redis)
──────────
• Encryption
• Multi-AZ
• Port 6379"]
        MQ["AMAZON MQ
(RabbitMQ)
──────────
• Async queue
• AMQP/SSL
• Port 5671"]
        SUPABASE["SUPABASE
(DB / Auth)
──────────
Option A: Cloud
Option B: Self-hosted
via CNPG HA on EKS"]
    end
 
    INTERNET --> DNS
    DNS --> ALB
    ALB --> VPC
    PUB --> PRIV
    PRIV --> EKS
    EKS --> DATA
```

<Info>
  सेल्फ़-होस्टेड Supabase CloudNativePG-प्रबंधित HA PostgreSQL क्लस्टर (`ha-supabase-db`) का उपयोग करता है जिसमें PgBouncer pooling, MinIO ऑब्जेक्ट स्टोरेज के लिए, और `helm-deployment/supabase-kubernetes-ha` के माध्यम से तैनात पूर्ण Supabase एप्लिकेशन स्टैक शामिल है। यदि सेल्फ़-होस्टिंग की आवश्यकता नहीं है तो Supabase Cloud एक विकल्प है।
</Info>

***

## मुख्य घटक

### 1. नेटवर्किंग लेयर

#### DNS Provider

* **उद्देश्य:** डोमेन नाम रिज़ॉल्यूशन; किसी भी प्रदाता के साथ काम करता है (Route 53, Cloudflare, आदि)
* **डोमेन** (अपना स्वयं का डोमेन उपयोग करें, जैसे `example.com`):
  * `app.example.com` — वेब फ़्रंटएंड
  * `api.example.com` — FastAPI बैकएंड
  * `automations.example.com` — Automator सेवा
  * `supabase.example.com` — Supabase Kong (केवल सेल्फ़-होस्टेड)
  * `signoz.example.com` — SigNoz अवलोकन (वैकल्पिक)
* **SSL सत्यापन:** ACM DNS सत्यापन के लिए CNAME रिकॉर्ड्स आवश्यक

#### Application Load Balancer (ALB)

* **उद्देश्य:** SSL termination, लोड बैलेंसिंग और hostname-आधारित रूटिंग
* **विशेषताएँ:**
  * ACM प्रमाणपत्रों का उपयोग करके SSL/TLS termination (वाइल्डकार्ड या प्रति-सेवा)
  * HTTP → HTTPS रीडायरेक्ट
  * सभी लक्ष्य समूहों के लिए हेल्थ चेक्स
* **द्वारा प्रबंधित:** AWS Load Balancer Controller (`helm-deployment/infrastructure` में Helm chart)

#### VPC

* **CIDR:** वातावरण-विशिष्ट (जैसे `10.x.0.0/16`)
* **उपलब्धता क्षेत्र:** चयनित क्षेत्र में 3 AZs
* **सबनेट्स:** 3 पब्लिक (NAT Gateways) + 3 प्राइवेट (EKS नोड्स)
* **आउटबाउंड:** नोड ईग्रेस के लिए प्रति AZ NAT Gateway

***

### 2. कम्प्यूट लेयर

#### EKS क्लस्टर

* **संस्करण:** Kubernetes 1.33
* **सिस्टम Node Group:** Karpenter कंट्रोलर चलाने वाला प्रबंधित node group (AWS बेस्ट प्रैक्टिस के अनुसार, Karpenter-प्रबंधित नोड्स पर नहीं)
* **ऐड-ऑन्स:** EBS CSI Driver, AWS Load Balancer Controller, CoreDNS, kube-proxy

#### Karpenter — गतिशील Node प्रोविज़निंग

* **उद्देश्य:** जस्ट-इन-टाइम node प्रोविज़निंग और लागत अनुकूलन
* **Node Classes:**
  * **जनरल पर्पस:** अधिकांश वर्कलोड के लिए Spot instances
  * **कम्प्यूट इंटेंसिव:** CPU-बाउंड टास्क के लिए हाई-CPU instances
  * **मेमोरी इंटेंसिव:** बड़े डेटासेट के लिए मेमोरी-अनुकूलित instances
  * **डेटाबेस:** स्टेटफुल/डेटाबेस वर्कलोड के लिए On-Demand instances
  * **GPU:** AI/ML वर्कलोड के लिए GPU instances (वैकल्पिक)
* **विशेषताएँ:** Spot प्राथमिकता, स्वचालित समेकन, SQS-आधारित interruption handling

#### KEDA — Kubernetes Event-Driven Autoscaling

* **उद्देश्य:** संसाधन मेट्रिक्स के आधार पर हॉरिज़ॉन्टल pod autoscaling
* **लक्ष्य:**

| सेवा           | रेप्लिकास | CPU सीमा | मेमोरी सीमा |
| -------------- | --------- | -------- | ----------- |
| वेब फ़्रंटएंड  | 2–8       | 60%      | 80%         |
| FastAPI बैकएंड | 2–10      | 70%      | 80%         |
| Celery Workers | 2–8       | 70%      | 80%         |
| Automator      | 2–8       | 70%      | 80%         |

* **स्केल-डाउन:** तेज़ प्रतिक्रिया के लिए 30s स्थिरता विंडो

***

### 3. एप्लिकेशन सेवाएँ

#### वेब फ़्रंटएंड

* **पोर्ट:** 3000
* **रेप्लिकास:** 2–8 (KEDA-प्रबंधित)
* **उद्देश्य:** उपयोगकर्ता इंटरफ़ेस प्रदान करने वाला React एप्लिकेशन

#### FastAPI बैकएंड

* **पोर्ट:** 8001
* **रेप्लिकास:** 2–10 (KEDA-प्रबंधित)
* **उद्देश्य:** बिज़नेस लॉजिक और डेटा पहुँच को संभालने वाला REST API सर्वर

#### Celery Workers

* **रेप्लिकास:** 2–8 (KEDA-प्रबंधित)
* **उद्देश्य:** पृष्ठभूमि टास्क प्रोसेसिंग (RabbitMQ के माध्यम से क्यू किया गया)

#### Automator सेवा

* **पोर्ट:** 80
* **रेप्लिकास:** 2–8 (KEDA-प्रबंधित)
* **उद्देश्य:** वर्कफ़्लो स्वचालन और ऑर्केस्ट्रेशन

#### Supabase Kong

* **पोर्ट:** 8000 (आंतरिक क्लस्टर सेवा)
* **उद्देश्य:** सभी Supabase सेवाओं के लिए API gateway
* **रूटिंग:** बाहरी ट्रैफ़िक `odin-services/main-ingress.yaml` में परिभाषित ALB ingress के माध्यम से Kong तक पहुँचता है

#### SigNoz (वैकल्पिक)

* **Namespace:** `monitoring`
* **घटक:** SigNoz प्लेटफ़ॉर्म + k8s-infra DaemonSet agent
* **उद्देश्य:** वितरित tracing, मेट्रिक्स एकत्रीकरण, लॉग प्रबंधन
* **सक्षम:** `ENABLE_SIGNOZ=true`

***

### 4. डेटा लेयर

#### ElastiCache Redis

* **उद्देश्य:** कैशिंग, सत्र स्टोरेज, और Celery broker/result backend
* **कॉन्फ़िगरेशन:**
  * Node प्रकार: कॉन्फ़िगर करने योग्य (जैसे `cache.t3.micro`)
  * पोर्ट: `6379`
  * रेस्ट और ट्रांज़िट में एन्क्रिप्शन
  * उच्च उपलब्धता के लिए Multi-AZ
* **सक्षम:** `ENABLE_AWS_SERVICES=true`

#### Amazon MQ (RabbitMQ)

* **उद्देश्य:** अतुल्यकालिक टास्क प्रोसेसिंग के लिए मैसेज क्यूइंग
* **कॉन्फ़िगरेशन:**
  * Engine: RabbitMQ
  * पोर्ट्स: `5671` (AMQP/SSL), `15671` (Management/SSL)
  * तैनाती मोड: सिंगल-इंस्टैंस या active/standby
* **सक्षम:** `ENABLE_AWS_SERVICES=true`

#### Supabase — विकल्प A: क्लाउड (प्रबंधित)

* **उद्देश्य:** बाहरी प्रबंधित PostgreSQL, Auth, Storage और Realtime
* **कनेक्शन:** `values/odin-services.yaml` में कॉन्फ़िगर किया गया Supabase प्रोजेक्ट URL और service role key

#### Supabase — विकल्प B: EKS पर सेल्फ़-होस्टेड

* **उद्देश्य:** क्लस्टर के अंदर चलने वाला पूर्ण Supabase स्टैक
* **घटक:**
  * CloudNativePG operator (`cnpg-system`) — Postgres क्लस्टर जीवनचक्र प्रबंधित करता है
  * HA Supabase DB (`ha-supabase-db`) — PgBouncer pooler के साथ CloudNativePG Cluster रिसोर्स
  * Supabase एप्लिकेशन (`supabase` namespace) — Kong, Auth, Storage (MinIO), Meta, Rest, Realtime, Studio
* **तैनाती क्रम:** CloudNativePG → HA Supabase DB → Supabase ऐप
* **सक्षम:** `ENABLE_CNPG=true`, `ENABLE_HA_SUPABASE_DB=true`, `ENABLE_SUPABASE=true`

#### PostgreSQL Automator

* **उद्देश्य:** Automator सेवा के लिए स्थानीय PostgreSQL डेटाबेस
* **पोर्ट:** 5432
* **स्टोरेज:** EBS स्थायी volume
* **Node affinity:** डेटाबेस-समर्पित नोड्स

***

### 5. सुरक्षा और IAM

#### IAM भूमिकाएँ

| भूमिका                            | उद्देश्य                                 |
| --------------------------------- | ---------------------------------------- |
| EKS Cluster Role                  | क्लस्टर-स्तरीय API अनुमतियाँ             |
| Node Group Role                   | EC2 नोड अनुमतियाँ (ECR, SSM, नेटवर्किंग) |
| Karpenter Controller Role         | EC2 प्रोविज़निंग, SQS interruption क्यू  |
| AWS Load Balancer Controller Role | ELBv2 और EC2 प्रबंधन                     |
| EBS CSI Driver Role               | EBS volume जीवनचक्र प्रबंधन              |

भूमिका नाम `<env-name>-<component>` पैटर्न का पालन करते हैं और EKS Terraform मॉड्यूल द्वारा बनाए जाते हैं।

#### सुरक्षा समूह

* **ALB:** AWS Load Balancer Controller द्वारा स्वतः बनाया गया (80/443 इनबाउंड)
* **EKS Cluster:** नोड-से-नोड और pod संचार
* **Redis:** केवल VPC CIDR से पोर्ट 6379
* **RabbitMQ:** केवल VPC CIDR से पोर्ट्स 5671, 15671

#### SSL/TLS

* **Termination:** ALB स्तर (pods आंतरिक रूप से प्लेन HTTP देखते हैं)
* **प्रमाणपत्र:** ACM प्रमाणपत्र — या तो प्रति-सेवा या एकल वाइल्डकार्ड
* **सत्यापन:** आपके DNS provider के माध्यम से DNS CNAME सत्यापन
* **न्यूनतम प्रोटोकॉल:** TLS 1.2

***

### 6. Infrastructure as Code

#### Terraform मॉड्यूल्स

* **`modules/eks`:** EKS क्लस्टर, VPC, node groups, Karpenter, IAM, Helm releases
* **स्टेट:** S3 bucket वर्शनिंग के साथ, DynamoDB lock table

#### Terragrunt

* **वातावरण अलगाव:** `terragrunt/environments/` के अंतर्गत प्रति वातावरण एक निर्देशिका
* **टेम्पलेट:** `env-template-folder` — नया वातावरण बनाने के लिए कॉपी करें और placeholders भरें
* **DRY कॉन्फ़िगरेशन:** प्रति-वातावरण overrides के साथ साझा `root.hcl`
* **सक्षम/अक्षम फ़्लैग्स:** वातावरण चरों (`ENABLE_*`) के माध्यम से सेवाएँ टॉगल की जाती हैं

#### Helm Charts

| Chart                    | Namespace        | विवरण                                 |
| ------------------------ | ---------------- | ------------------------------------- |
| `infrastructure`         | `infrastructure` | ALB Controller                        |
| `odin-services`          | `default`        | Web, API, Workers, Automator, Ingress |
| `aws-ebs-csi-driver`     | `kube-system`    | EBS volume प्रोविज़निंग               |
| `keda`                   | `keda`           | Pod autoscaling                       |
| `cloudnative-pg`         | `cnpg-system`    | PostgreSQL operator                   |
| `ha-supabase-db`         | `ha-supabase-db` | HA Postgres क्लस्टर + PgBouncer       |
| `supabase-kubernetes-ha` | `supabase`       | पूर्ण Supabase स्टैक                  |
| `signoz`                 | `monitoring`     | अवलोकन प्लेटफ़ॉर्म                    |
| `k8s-infra`              | `monitoring`     | क्लस्टर मेट्रिक्स agent               |

***

## डेटा प्रवाह

### 1. उपयोगकर्ता अनुरोध प्रवाह

```
उपयोगकर्ता → DNS → ALB (SSL termination) → EKS Pod (वेब फ़्रंटएंड)
                                   → EKS Pod (FastAPI बैकएंड)
                                   → EKS Pod (Supabase Kong)
```

1. उपयोगकर्ता `app.example.com` तक पहुँचता है
2. DNS ALB को रिज़ॉल्व करता है
3. ALB SSL को terminate करता है और hostname द्वारा सही लक्ष्य समूह में रूट करता है
4. वेब फ़्रंटएंड React ऐप प्रदान करता है और `api.example.com` पर API कॉल करता है
5. FastAPI बैकएंड अनुरोधों को प्रोसेस करता है और डेटा सेवाओं से पढ़ता/लिखता है

### 2. API अनुरोध प्रवाह

```
Client → ALB → FastAPI बैकएंड → Redis (कैश) / RabbitMQ (क्यू) / Supabase (DB)
```

1. Client `api.example.com` पर कॉल करता है
2. ALB FastAPI pod में रूट करता है
3. बैकएंड Redis कैश जाँचता है; मिस होने पर, Supabase डेटाबेस को क्वेरी करता है
4. अतुल्यकालिक टास्क RabbitMQ में क्यू किए जाते हैं और Celery Workers द्वारा प्रोसेस किए जाते हैं

### 3. पृष्ठभूमि प्रोसेसिंग प्रवाह

```
FastAPI → RabbitMQ → Celery Worker → Supabase DB
```

1. FastAPI RabbitMQ में एक टास्क क्यू करता है
2. Celery Worker टास्क को डीक्यू और प्रोसेस करता है
3. परिणाम Supabase डेटाबेस में वापस लिखे जाते हैं

### 4. Automator वर्कफ़्लो

```
Automator → PostgreSQL (स्थानीय) → Redis → बाहरी APIs
```

1. Automator एक वर्कफ़्लो अनुरोध प्राप्त करता है
2. वर्कफ़्लो स्टेट स्थानीय PostgreSQL instance में संग्रहीत होता है
3. Redis मध्यवर्ती परिणामों को कैश करता है
4. स्वचालन के भाग के रूप में बाहरी APIs कॉल की जाती हैं

### 5. स्केलिंग प्रवाह

```
मेट्रिक्स → KEDA → Pod स्केलिंग → Karpenter → Node प्रोविज़निंग
```

1. KEDA CPU/Memory मेट्रिक्स को कॉन्फ़िगर की गई सीमाओं के विरुद्ध मूल्यांकन करता है
2. Pods कॉन्फ़िगर की गई रेप्लिका रेंज के भीतर हॉरिज़ॉन्टली स्केल किए जाते हैं
3. यदि क्लस्टर क्षमता अपर्याप्त है, तो Karpenter नए EC2 नोड्स प्रोविज़न करता है (Spot को प्राथमिकता)
4. जब लोड कम होता है, KEDA pods को स्केल-डाउन करता है; Karpenter निष्क्रिय नोड्स को समेकित और समाप्त करता है

### 6. सुरक्षा प्रवाह

```
इंटरनेट → ALB (TLS 1.2+, ACM) → सुरक्षा समूह → Pods → IAM IRSA भूमिकाएँ → AWS APIs
```

1. सभी बाहरी ट्रैफ़िक ALB पर TLS को terminate करता है
2. सुरक्षा समूह न्यूनतम-विशेषाधिकार नेटवर्क पहुँच लागू करते हैं
3. Pods IRSA (IAM Roles for Service Accounts) के माध्यम से AWS सेवाओं के साथ संवाद करते हैं

***

## उच्च उपलब्धता सारांश

| विशेषता          | कार्यान्वयन                                                               |
| ---------------- | ------------------------------------------------------------------------- |
| Multi-AZ तैनाती  | EKS नोड्स, Redis, सबनेट्स के लिए 3 AZs                                    |
| लोड बैलेंसिंग    | कई लक्ष्य समूहों के साथ ALB                                               |
| Pod रिडंडेंसी    | प्रति सेवा न्यूनतम 2 रेप्लिकास                                            |
| डेटाबेस HA       | PgBouncer के साथ CloudNativePG क्लस्टर (सेल्फ़-होस्टेड) या Supabase Cloud |
| कैश रिडंडेंसी    | ElastiCache Multi-AZ                                                      |
| Node autoscaling | Spot + On-Demand मिश्रण के साथ Karpenter                                  |
| Pod autoscaling  | KEDA CPU/Memory-आधारित                                                    |
| अवलोकन           | SigNoz (वैकल्पिक)                                                         |
| स्टेट प्रबंधन    | S3 वर्शनिंग + DynamoDB lock                                               |

***

## लागत अनुकूलन

* **Spot Instances:** Karpenter गैर-डेटाबेस वर्कलोड के लिए Spot को प्राथमिकता देता है
* **Node समेकन:** Karpenter स्वचालित रूप से कम उपयोग वाले नोड्स को पुनः प्राप्त करता है
* **Pod राइट-साइज़िंग:** KEDA शांत अवधि के दौरान pods को स्केल-डाउन करता है
* **केवल जहाँ आवश्यक On-Demand:** डेटाबेस node class स्थिरता के लिए On-Demand का उपयोग करता है

***

## रखरखाव और संचालन

### तैनाती प्रक्रिया

```bash theme={null}
cd terragrunt/environments/<your-env-name>
# आवश्यक ENABLE_* और domain/certificate वातावरण चर सेट करें
terragrunt apply
# रोलिंग अपडेट: image tags या values files अपडेट करने के बाद पुनः लागू करें
```

पूर्ण तैनाती क्रम के लिए [Terragrunt तैनाती गाइड](/on-premise/kubernetes-deployment/terragrunt-deployment.mdx) देखें।

### बैकअप रणनीति

* **EBS Snapshots:** स्थायी volumes (Automator DB, Supabase MinIO) के लिए स्वचालित snapshots
* **CloudNativePG:** लगातार WAL archiving + अनुसूचित base backups (यदि कॉन्फ़िगर किया गया)
* **Supabase Cloud:** प्रबंधित दैनिक बैकअप (क्लाउड विकल्प)
* **IaC स्टेट:** S3 वर्शन्ड bucket

### आपदा वसूली

* **Multi-AZ:** सभी स्टेटफुल सेवाएँ कई उपलब्धता क्षेत्रों में फैली हुई हैं
* **CloudNativePG HA:** Postgres primary और replicas के बीच स्वचालित failover
* **Supabase Cloud:** क्रॉस-क्षेत्र रिडंडेंसी (क्लाउड विकल्प)
* **Terraform स्टेट:** S3 वर्शनिंग किसी भी पिछली स्थिति में वापस जाने की अनुमति देता है

***

## अतिरिक्त संसाधन

* [AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/)
* [Karpenter दस्तावेज़ीकरण](https://karpenter.sh/docs/)
* [KEDA दस्तावेज़ीकरण](https://keda.sh/docs/)
* [CloudNativePG दस्तावेज़ीकरण](https://cloudnative-pg.io/documentation/)
* [Supabase सेल्फ़-होस्टिंग](https://supabase.com/docs/guides/self-hosting)
* [SigNoz दस्तावेज़ीकरण](https://signoz.io/docs/)
* [Terragrunt तैनाती गाइड](/on-premise/kubernetes-deployment/terragrunt-deployment.mdx)