खोजें

ia

डीप डाइव : एआई एजेंट और Draw.io MCP के साथ AWS डायग्राम बनाना

डीप डाइव : एआई एजेंट और Draw.io MCP के साथ AWS डायग्राम बनाना

इन्फ्रास्ट्रक्चर को समझने के लिए एक अच्छा चार्ट हमेशा उपयोगी होता है। लेकिन इन्हें हाथ से बनाना समय लेता है: सही आइकन ढूँढना, एलिमेंट्स की पोजिशनिंग, कनेक्शंस खींचना… आज मुझे जो उत्साहित करता है, वह है कि इन सबको मैं AI के साथ ऑटोमेट कर पाऊं

इस आर्टिकल में मैं दिखाता/दिखाती हूँ कि कैसे एक AI एजेंट और MCP Draw.io का उपयोग करके AWS आर्किटेक्चर डायग्राम स्वचालित रूप से बनाए जा सकते हैं। मैंने अपने संदर्भ में Claude Code का उपयोग किया है, लेकिन यह तरीका किसी भी MCP-समर्थित एजेंट के साथ काम करेगा।

Claude Code और Draw.io MCP के साथ AWS डायग्राम का स्वचालित निर्माण

शुरूआत की स्थिति : एक पुराना चार्ट अपडेट करना

मेरे पास पहले से ही इस ब्लॉग के इंफ्रास्ट्रक्चर पर आलेख था, जो 2018 का है और जिसमें Draw.io में हाथ से बनाया गया एक चार्ट था। इंफ्रास्ट्रक्चर ज्यादा नहीं बदला — मैंने बेसिकली OAC (Origin Access Control) और एक CloudFront Function जोड़ा — लेकिन AWS आइकॉन बदल गए हैं और मैं चार्ट को लेटेस्ट वर्जन के साथ अपडेट करना चाहता था।

ऑटोमेशन के हल खोजते हुए, मैं Draw.io MCP Server पर पहुँचा, जिसकी एक Chrome एक्सटेंशन भी है। मैंने टेस्ट किया… और यह इतना बढ़िया लगा कि मैंने इसका एक आर्टिकल लिखने का निर्णय लिया!

MCP Draw.io : Draw.io को AI से नियंत्रित करना

Lадislav (lgazo) द्वारा बनाया गया Draw.io MCP Server एक MCP (Model Context Protocol) सर्वर है जो प्रोग्रामेटिकली Draw.io को कंट्रोल करने की अनुमति देता है। सरल शब्दों में, इसका मतलब है कि एक AI एजेंट Draw.io डायग्राम में एलिमेंट्स बना, बदल और ऑर्गनाइज़ कर सकता है।

उपलब्ध टूल्स

श्रेणीउपकरणउपयोग
निरीक्षणget-selected-cell, list-paged-modelकैनवास की स्थिति पढ़ना
सिर्जनाadd-rectangle, add-edge, add-cell-of-shapeएलिमेंट जोड़ना
संशोधनedit-cell, edit-edge, set-cell-dataमौजूदा एलिमेंट्स को बदलना
लाइब्रेरीget-shape-categories, get-shapes-in-categoryउपलब्ध शेप्स एक्सप्लोर करना

आवश्यक कॉन्फ़िगरेशन

एजेंट AI को Draw.io से संवाद करने के लिए दो चीज़ें कॉन्फ़िगर करनी होंगी, जैसा कि परियोजना की दस्तावेज़ीकरण में बताया गया है:

  1. एक लोकल MCP सर्वर — जिसे आपके एजेंट की सेटिंग्स फ़ाइल में कॉन्फ़िगर किया जाता है (उदा: .mcp.json Claude Code के लिए)
  2. Draw.io MCP Chrome एक्सटेंशन — जो MCP सर्वर और ब्राउज़र में चलने वाले Draw.io ऐप के बीच पुल का काम करता है

इन दोनों चीज़ों के होने पर, एजेंट सीधे Draw.io कैनवास को मैनिपुलेट कर सकता है: शेप्स बनाना, उन्हें पोज़िशन करना, कनेक्शंस बनाना — सब प्रोग्रामैटिक तरीके से।

MCP Draw.io का परीक्षण करते समय मैंने पाया कि एजेंट को सही परिणाम देने के लिए निर्देशित करना ज़रूरी है: रिसोर्सेज न बनाना जो कोड में न हों, सही AWS आइकॉन का उपयोग, समझदारी से पोजिशनिंग, श्रेणी के अनुसार रंग लागू करना, टेक्स्ट में HTML से बचना… इसलिए मैंने इन नियमों को एन्कोड करने वाला एक Claude Code skill बनाया।

Skill बनाएँ /aws-diagram

Claude Code का एक skill एक Markdown फ़ाइल होती है जो एक वर्कफ़्लो और नियमों को परिभाषित करती है। जब /aws-diagram को इनवॉक किया जाता है, Claude Code इन निर्देशों को लोड करता है और उन्हें स्वचालित रूप से लागू करता है।

वर्कफ़्लो

यह skill 4 चरणों की प्रक्रिया का पालन करता है:

  1. इन्फ्रास्ट्रक्चर कोड पढ़ना (Terraform, CloudFormation)
  2. AWS रिसोर्सेज और उनके रिलेशनशिप निकालना
  3. आधिकारिक AWS आइकॉन के साथ डायग्राम बनाना
  4. डिस्क्रिप्टिव लेबल्स के साथ कनेक्शंस जोड़ना
📄 Excerpt: Workflow
## Workflow

1. **Read infrastructure code** (Terraform, CloudFormation, etc.)
2. **Extract AWS resources** and their relationships
3. **Build diagram** with official AWS icons
4. **Add connections** with descriptive labels

महत्वपूर्ण नियम

मैंने skill में कई महत्वपूर्ण नियम एन्कोड किए:

1. कभी भी रिसोर्स बना कर नहीं जोड़ना

यह सबसे बड़ा जाल था। LLMs आमतौर पर जो तर्कसंगत लगता है उसे “पूरा” कर देते हैं। “CloudFront है, तो शायद Lambda@Edge भी होना चाहिए…” — नहीं! डायग्राम को सिर्फ वही दिखाना चाहिए जो कोड में मौजूद है, और कुछ नहीं।

📄 Excerpt: Ne jamais inventer
### NEVER invent resources

**Only diagram what actually exists in the infrastructure code.**

| Situation                  | Wrong                                         | Correct                                      |
| -------------------------- | --------------------------------------------- | -------------------------------------------- |
| No Lambda in Terraform     | Add Lambda@Edge because "it would make sense" | Don't add Lambda                             |
| CloudFront Function exists | Use Lambda icon                               | Use CloudFront icon with "CF Function" label |
| No WAF configured          | Add WAF for "security"                        | Don't add WAF                                |

2. उपयोगकर्ता बाहरी हैं

“Users” AWS रिसोर्स नहीं हैं। उन्हें AWS क्लाउड ग्रुप के बाहर दिखाया जाना चाहिए।

📄 Excerpt: Users externes
### Users OUTSIDE the AWS Cloud

**Users are NOT AWS resources.** They represent external actors.

WRONG:
┌─────────────────────────────────┐
│ AWS Cloud │
│ [Users] → [Route53] → [CF] │ ❌ Users inside cloud
└─────────────────────────────────┘

CORRECT:
[Users] → ┌─────────────────────────┐
│ AWS Cloud │
│ [Route53] → [CF] → [S3] │ ✅ Users outside
└─────────────────────────┘

3. टेक्स्ट में HTML न डालें

Draw.io HTML रेंडर नहीं करता। अगर आप text: "S3<br>Private" लिखते हैं, तो आप डायग्राम में वाकई में <br> देखेंगे।

📄 Excerpt: Pas de HTML
### NEVER use HTML in text parameters

Draw.io does NOT render HTML tags in text fields. They display as raw text.

**FORBIDDEN (will show ugly raw HTML):**

text: "S3 Bucket<br>Private" ❌ Shows "<br>" literally
text: "Route 53&nbsp;DNS" ❌ Shows "&nbsp;" literally
text: "<font color='red'>ACM</font>" ❌ Shows raw HTML tags

**CORRECT (clean text):**

text: "S3 Bucket" ✅ Single line, clean
text: "Route 53" ✅ Service name only
text: "ACM" ✅ Simple label

4. कॉलिशन से बचने के लिए लेआउट प्लान करें

क्रॉस करने वाली ऐज़ेज़ (edges) डायग्राम को पढ़ने लायक नहीं छोड़तीं। skill सिफारिश करता है कि मुख्य फ़्लो को एक हॉरिज़ॉन्टल लाइन पर रखें, और सहायक सर्विसेज़ को ऊपर या नीचे रखें।

📄 Excerpt: Layout et collisions
### Rule 1: Main Flow on a Horizontal Line

Place the primary data flow (request path) on a single horizontal row:

[Entry] → [Service A] → [Service B] → [Service C]
y=300 y=300 y=300 y=300

### Rule 2: Auxiliary Services Above or Below

Services that connect TO a main service (not part of the flow) go above or below:

        [Auth]     [Edge Logic]     ← Auxiliary row (y=150)
           \           /
            \         /
             ↓       ↓

[Entry] → [Gateway] → [Compute] → [Storage] ← Main flow (y=300)

5. एनोटेशन दाईं ओर रखें, नीचे नहीं

AWS आइकॉन के लेबल अपने आप नीचे दिखते हैं। अगर आप नीचे भी एनोटेशन जोड़ते हैं तो वे अगली लाइन को ओवरलैप करेंगे। उन्हें आइकॉन के दाईं ओर रखें।

📄 Excerpt: Placement annotations
### Annotation Placement Rules

**CRITICAL: Place annotations to the RIGHT of icons, not below.**

**WRONG - Annotations below icons:**

[CloudFront] [S3]
|
"Cache Policies" ← Overlaps with next row!
"Security Headers"
|
[CloudFront Preview] ← Collision!

**CORRECT - Annotations to the RIGHT:**

[CloudFront] ── "Cache Policies: HTML 0s | Assets 1y"
| "Security: CSP | HSTS"

[CloudFront Preview] ← No collision

रंग प्रणाली

मैंने AWS कन्वेंशन्स के अनुरूप एक सुसंगत पैलेट बनाया है:

श्रेणीरंगसर्विसेज़
Networking#8C4FFF (बैंगनी)Route53, CloudFront, VPC
Storage#7AA116 (हरा)S3, EFS
Security#DD344C (लाल)ACM, IAM, WAF
Compute#ED7100 (ऑरेंज)Lambda, EC2

डेटा फ्लो के लिए मैं एनवायरनमेंट कलर्स इस्तेमाल करता/करती हूँ:

  • Production : हरा #4CAF50
  • Preview : ऑरेंज #FF9800
  • Configuration : ग्रे #AAAAAA (dashed)
📄 Excerpt: Couleurs et styles
### Colors by Category

| Category       | Color               | Services                                   |
| -------------- | ------------------- | ------------------------------------------ |
| **Networking** | `#8C4FFF` (violet)  | Route53, CloudFront, VPC, ELB, API Gateway |
| **Compute**    | `#ED7100` (orange)  | Lambda, EC2, ECS, Fargate                  |
| **Storage**    | `#7AA116` (green)   | S3, EFS, EBS                               |
| **Database**   | `#C925D1` (magenta) | RDS, DynamoDB, ElastiCache                 |
| **Security**   | `#DD344C` (red)     | ACM, IAM, WAF, Cognito                     |
| **General**    | `#232F3D` (gray)    | Users, Generic                             |

### AWS Icon Style Template

sketch=0;outlineConnect=0;fontColor=#232F3E;fillColor=<COLOR>;strokeColor=#ffffff;
dashed=0;verticalLabelPosition=bottom;verticalAlign=top;align=center;html=1;
fontSize=12;fontStyle=0;aspect=fixed;shape=mxgraph.aws4.resourceIcon;
resIcon=mxgraph.aws4.<SERVICE>;

### Edge Colors by Environment

| Environment   | Color     | Usage                  |
| ------------- | --------- | ---------------------- |
| Production    | `#4CAF50` | Main production flow   |
| Preview       | `#FF9800` | Staging environments   |
| Configuration | `#AAAAAA` | Dashed, non-data links |

प्रैक्टिकल अप्लिकेशन : jls42.org की इन्फ्रास्ट्रक्चर

Skill का परीक्षण करने के लिए मैंने इसे अपने ब्लॉग की इन्फ्रास्ट्रक्चर पर चलाया।

विश्लेषित Terraform कोड

terraform/
├── cloudfront-astro.tf    # Distribution CloudFront prod
├── s3-astro.tf            # Bucket S3 privé avec OAC
├── acm-astro.tf           # Certificat SSL
├── route53.tf             # DNS
└── variables.tf           # Variables

निकाली गई आर्किटेक्चर

कंपोनेंटAWS सर्विसकॉन्फ़िगरेशन
DNSRoute 53Zone jls42.org, 3 डोमेन्स
CDNCloudFrontOAC, CF Function, cache policies
StorageS3प्राइवेट बकेट, AES256, OAC only
TLSACMसर्टिफिकेट us-east-1, DNS validation

जनरेट किया गया डायग्राम

यहाँ अंतिम परिणाम है:

स्वचालित रूप से जनरेट की गई jls42.org की AWS आर्किटेक्चर स्वचालित रूप से जनरेट की गई jls42.org की AWS आर्किटेक्चर

एक साधारण नेचुरल लैंग्वेज प्रॉम्प्ट से:

«Analyse en profondeur l’infrastructure de ce projet puis réalise un super schéma de l’architecture AWS comme un pro. Juste l’infra de prod, pas preview ni legacy.»

🇮🇳 “इस प्रोजेक्ट की इन्फ्रास्ट्रक्चर का गहन विश्लेषण करो और फिर एक प्रोफेशनल AWS आर्किटेक्चर का शानदार चार्ट बनाओ। केवल प्रोड प्रोडक्शन इन्फ्रा, न कि प्रिव्यू या लेगेसी।”

Claude Code ने पहले Terraform फ़ाइलों का विश्लेषण किया ताकि इन्फ्रास्ट्रक्चर की पहचान हो सके, फिर /aws-diagram skill को लोड किया गया जिसकी निर्देशों ने निम्न करने की अनुमति दी:

  1. मुख्य कंपोनेंट्स बनाए (Users, Route53, CloudFront, S3, ACM)
  2. विस्तृत एनोटेशन्स जोड़े (cache policies, security headers, bucket config…)
  3. लेबल्स के साथ कनेक्शंस ड्रॉ किए (HTTPS, DNS Alias, OAC, TLS Cert…)
  4. बाहरी सर्विसेज़ जोड़ीं (Plausible Analytics, Gandi ईमेल के लिए)
  5. श्रेणी अनुसार एक लेजेन्ड जनरेट किया

सभी कुछ एक साफ़ लेआउट बनाए रखते हुए किया गया:

  • AWS क्लाउड का साइज ऑटोमैटिकली (900×420px)
  • Users क्लाउड के बाईं तरफ़
  • बाहरी सर्विसेज़ दाईं तरफ़
  • डायग्राम के नीचे एक लेजेन्ड

पूरा वर्कफ़्लो : Terraform से वीडियो तक

मैंने अनुभव को आगे बढ़ाया और एक डेमो वीडियो बनाया।

रिकॉर्डिंग

मैंने डायग्राम की जनरेशन को रीयल-टाइम में रिकॉर्ड किया: 4 मिनट 10 सेकंड जहाँ Claude Code Terraform पढ़ता है, एलिमेंट्स एक-एक करके बनते हैं और डायग्राम मेरे सामने बनता है।

FFmpeg के साथ पोस्ट-प्रोडक्शन

4 मिनट एक डेमो के लिए लंबा है। मैंने FFmpeg का उपयोग करके वैरिएबल स्पीड के साथ एक फ़ास्ट-फ़ॉरवर्ड वर्जन बनाया:

सेगमेंटकंटेंटस्पीड
0:00-0:10Claude को डायग्राम जनरेट करने का निर्देश1x
0:10-0:32Terraform कोड का विश्लेषण15x
0:32-0:35Skill /aws-diagram का पता चलना और ऑटोमैटिक रूप से चलना1x
0:35-3:46ब्राउज़र में डायग्राम जनरेशन15x
3:46-3:56बेहतर विज़ुअल के लिए लेबल्स का रीपोजिशनिंग1x

परिणाम: मुख्य क्षणों को नॉर्मल स्पीड पर रखते हुए 4 मिनट के बजाय 42 सेकंड की एक वीडियो।

HeyGen के साथ नैरेशन

वॉइस-ओवर जोड़ने के लिए, मैंने एक नैरेशन स्क्रिप्ट लिखी, वीडियो को 30 सेकंड के सेगमेंट्स में बांटा (HeyGen की सीमा) और फ्रेंच में वॉइस जेनरेट की। बेस वॉइस मुझे पसंद नहीं आई, तो मैंने उनके “डिज़ाइन वॉइस” फ़ीचर का इस्तेमाल किया, जिससे वॉइस को ऑन-द-फ्लाई प्रॉम्प्ट से एडजस्ट कर के सही टोन मिल गया।

अंतिम परिणाम वही वीडियो है जिसे आप इस आर्टिकल की ऊपर की ओर देख सकते हैं।

दूसरा उदाहरण : हाई अवेलेबिलिटी EKS आर्किटेक्चर

यह दिखाने के लिए कि MCP Draw.io कितना अच्छा काम करता है, यहाँ एक दूसरा, अधिक जटिल उदाहरण है: एक हाई-अवेलेबिलिटी EKS आर्किटेक्चर। MCP Draw.io Draw.io में सारा निर्माण करता है — मुझे बस एक डिटेल्ड प्रॉम्प्ट देना था।

इस बार, मैंने वांछित आर्किटेक्चर का एक विस्तृत प्रॉम्प्ट दिया:

📋 EKS आर्किटेक्चर के लिए पूरा प्रॉम्प्ट
Architecture EKS Hautement Disponible

Génère un diagramme d'architecture AWS EKS avec les composants suivants :

## Services AWS à inclure

### Externes (gauche du cloud)

- Users (icône utilisateurs générique)

### Networking

- Route 53 (DNS)
- Application Load Balancer (ALB) - dans les subnets publics
- NAT Gateway (3x, un par AZ)
- VPC avec 3 AZ

### Compute (subnets privés)

- EKS Control Plane (géré par AWS - représenter séparément)
- 3 Node Groups (un par AZ) avec pods à l'intérieur

### Storage

- EFS (stockage partagé cross-AZ)

### Security

- ACM (Certificate Manager)
- IAM (pour Pod Identity / IRSA)

### Observability

- CloudWatch (logs et métriques)

## Connexions à tracer

| Source            | Target      | Label               | Style       |
| ----------------- | ----------- | ------------------- | ----------- |
| Users             | Route 53    | HTTPS               | Solid green |
| Route 53          | ALB         | DNS Alias           | Solid green |
| ALB               | Node Groups | Traffic             | Solid green |
| ACM               | ALB         | TLS                 | Dashed gray |
| Node Groups       | EFS         | NFS Mount           | Solid green |
| EKS Control Plane | Node Groups | kubectl API         | Solid green |
| EKS Control Plane | IAM         | IRSA / Pod Identity | Dashed gray |
| Node Groups       | CloudWatch  | Logs / Metrics      | Dashed gray |

जनरेट किया गया परिणाम

स्वचालित रूप से जनरेट की गई हाई-एवेलेबिलिटी EKS आर्किटेक्चर स्वचालित रूप से जनरेट की गई हाई-एवेलेबिलिटी EKS आर्किटेक्चर

यह डायग्राम एक प्रोडक्शन-रेडी Kubernetes आर्किटेक्चर को दर्शाता है जिसमें:

  • 3 Availability Zones उच्च उपलब्धता के लिए
  • NAT Gateways (AZ पर एक-एक) इंटरनेट आउटबाउंड के लिए
  • Node Groups प्रत्येक AZ में फैलाए गए pods के साथ
  • EFS क्रॉस-AZ साझा पर्सिस्टेंट स्टोरेज के लिए
  • कंट्रोल प्लेन (AWS-managed) को अलग दृश्य में दर्शाया गया
  • IRSA (IAM Roles for Service Accounts) पॉड्स की सुरक्षा के लिए

MCP Draw.io ने सही तरीके से VPC और AZ समूह बनाए, NAT Gateways को पब्लिक सबनेट में रखा और Node Groups को प्राइवेट सबनेट में पोजिशन किया। परिणाम एक शानदार वर्किंग बेस देता है जिसे बाद में अपनी विज़ुअल प्राथमिकताओं के अनुसार पॉलिश या किसी संभावित त्रुटि को ठीक किया जा सकता है — शून्य से शुरू करने से काफी तेज़।

इस प्रोजेक्ट से क्या स्पष्ट होता है

इस अनुभव ने मेरे काम करने के अधिकांश पहलुओं को उजागर किया:

  • डॉक्यूमेंटेशन का ऑटोमेशन: कोड स्रोत का सच्चाई है; डायग्राम उससे स्वतः निकलना चाहिए
  • सही टूल्स का उपयोग: MCP Draw.io मेरे लिए बिल्कुल उपयुक्त था, मैंने पहिया नया नहीं बनाया
  • नियमों का एन्कोड करना: skills विशेषज्ञता कैप्चर करने और सामान्य गलतियों से बचने में मदद करते हैं — यह किसी भी प्रकार के Draw.io डायग्राम पर लागू होता है, सिर्फ AWS पर नहीं
  • कंसैप्ट को असल पर परखना: मैंने अपनी खुद की इन्फ्रास्ट्रक्चर पर प्रयोग किया
  • खोज को आगे बढ़ाना: ऑटो-जनरेशन से लेकर नैरेटेड वीडियो तक, हर चरण सीखने का मौका था

Skill अब मेरे workflow में इंटीग्रेटेड है। अगली बार जब मैं इन्फ्रास्ट्रक्चर बदलूँगा, मैं सिर्फ एक सिंपल प्रॉम्प्ट से डायग्राम रीजनरेट कर पाऊँगा।

संसाधन


यदि आप किसी MCP-संगत कोडिंग एजेंट का उपयोग करते हैं और आपकी पास इन्फ्रास्ट्रक्चर दस्तावेज़ करने के लिए हैं, तो मैं इस तरीके को आज़माने के लिए प्रोत्साहित करता/करती हूँ। यह अनुभव काफी संतोषप्रद है जब आप एक साफ़ डायग्राम को अपने आँखों के सामने ऑटोमेटिकली बनते देखते हैं।

धन्यवाद पढ़ने के लिए, उम्मीद है यह आर्टिकल आपको प्रयोग करने के लिए प्रेरित करेगा!

यह दस्तावेज़ fr संस्करण से hi भाषा में gpt-5-mini मॉडल का उपयोग करके अनुवादित किया गया है। अनुवाद प्रक्रिया के बारे में अधिक जानकारी के लिए, देखें https://gitlab.com/jls42/ai-powered-markdown-translator