Mi történne, ha az AI kezébe adnám az AWS infrastruktúrámat?

Bevezető

Sok időt töltök AWS-erőforrások kezelésével. Általában olyan jól ismert Infrastructure as Code (IaC) eszközökkel dolgozom, mint az OpenTofu és a Terragrunt. Ezek megbízhatóan végzik a dolgukat: az erőforrásokat kiszámíthatóan definiálhatom, a modulokat és stack-eket újrahasznosíthatom, és mindent verziókezeléssel, automatizáltan tarthatok kézben.

De nemrég, amikor megjelentek az AWS Model Context Protocols (MCPs), elgondolkodtam: mi lenne, ha egyáltalán nem lenne szükségem IaC-re? Mi lenne, ha egyszerűen leírhatnám, mit szeretnék természetes nyelven és az AWS intézné a többit? Kikerülhetném a kódírást és a plan/apply ciklust, és közvetlenül kommunikálhatnék az AWS API-jával.

Túl jól hangzik, hogy igaz legyen, ugye? Nos… részben az is.

Hogy kiderítsem, kipróbáltam egy kisebb kísérletet: létrehoztam egy EKS cluster-t az Amazon Q és a Claude Sonnet 4 segítségével. A célom nem az volt, hogy az AI teljes architektúrát tervezzen, hanem hogy lássam, képes-e kezelni az alapokat — az EKS cluster létrehozását, a frissítések kezelését és egy-két Helm chart telepítését — mindezt minimális emberi beavatkozással.

Az AWS MCP-kről

Mielőtt belevágnánk magába a kísérletbe, nézzük röviden az AWS Model Context Protocols (MCPs) működését — ezek képezik az egész setup gerincét. Az MCP-k lényegében olyan kapcsolódási pontok, amelyek lehetővé teszik, hogy az AI modellek közvetlenül, strukturált és biztonságos módon kommunikáljanak az AWS szolgáltatásaival és API-jaival. Nem csak kódot generálnak, hanem valódi operációs kontextust adnak az AI-nak — képesek lekérdezni, létrehozni és kezelni az AWS erőforrásokat jól definiált végpontokon keresztül.

Ehhez a projekthez a következő MCP-ket használtam:

• ccapi-mcp-server – integráció a Common Cloud API-val az erőforrások kezeléséhez.
• aws-api-mcp-server – közvetlen hozzáférés az AWS szolgáltatások API-jaihoz.
• cfn-mcp-server – lehetővé teszi az AI számára, hogy CloudFormation stack-ekkel és sablonokkal dolgozzon.
• eks-mcp-server – kifejezetten az Amazon EKS klaszterek, node-ok és konfigurációk kezelésére fókuszál.

Minden MCP olyan, mint egy specializált plugin, amely kontrollált láthatóságot és működési képességeket biztosít az AI számára az AWS környezetemben.

Ehhez a projekthez az Amazon Q agent-hez ezt a konfigurációt használtam.

"mcpServers": {
    "awslabs.aws-api-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-api-mcp-server@latest"],
      "disabled": false,
      "autoApprove": []
    },
    "awslabs.ccapi-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.ccapi-mcp-server@latest"],
      "disabled": false,
      "autoApprove": []
    },
    "awslabs.eks-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.eks-mcp-server@latest",
        "--allow-write",
        "--allow-sensitive-data-access"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "autoApprove": [],
      "disabled": false
    },
    "awslabs.cfn-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.cfn-mcp-server@latest"
      ],
      "disabled": false,
      "autoApprove": []
    }
  }

Már most is egyre több MCP érhető el, és valószínűleg néhány további konfigurációval még simábbá tehettem volna a folyamatot. Ehhez a teszthez azonban egyszerű akartam maradni, és a legfontosabb, EKS-hez legrelevánsabb MCP-kre koncentráltam.

Aggodalmak

Három fő aggályom volt a projekttel kapcsolatban: biztonság, pontosság és állapotkezelés. Nézzük ezeket egyenként.

Biztonság

Ha egy AI közvetlenül az AWS környezeteddel kommunikál, az nyilvánvaló biztonsági kockázatokat hordoz. Az Amazon Q ad némi útmutatást, de a legfontosabb szempontok, amiket figyelembe vettem, a következők:

1. Túlzott jogosultságok: Az AI-nak nem szabad AdministratorAccess jogokat adni. A least-privilege IAM role-ok elengedhetetlenek.

2. Nem kívánt erőforrások vagy kockázatos alapértelmezések: Ha a prompt homályos, az AI véletlenül létrehozhat publikus erőforrásokat, nyithat portokat, vagy rossz régióban telepíthet. A CloudFormation change set-ek segítettek, hogy ezeket a hibákat még a tényleges telepítés előtt észrevegyem.

3. Érzékeny adatok kiszivárgása: A promptokban nem szabad titkokat vagy érzékeny azonosítókat megadni. Minden titkos adatkezelést AWS natív eszközökben tartottam.

4. Nyomonkövethetőség: Ha többen használják az Amazon Q-t, könnyű elveszíteni a nyomát annak, ki mit módosított. A konzisztens tag-elés és naplózás a legtöbb problémát megoldotta.

5. Read-only mód: Hagyjuk, hogy Q javaslatokat adjon, és generáljon CloudFormation template-eket vagy script-eket, de ne adjuk neki közvetlen írási jogot a környezethez. Egy egyszerű kérés, például “make my EC2 instances more cost-efficient”, véletlenül leállíthat futó erőforrásokat.

Pontosság

Az egyik fő célom a reprodukálhatóság volt. Nem akartam ugyanazokat a hibákat újra és újra javítani, vagy hogy minden futtatásnál kissé eltérő EKS cluster-t kapjak.

Ehhez két dolgot vezettem be:

1. Project standards file – tartalmazza a naming convention-öket, tag-eket, szabályokat és alapértelmezett konfigurációkat minden erőforráshoz. Minden promptnak ezen kellett alapulnia.

2. Prompt template – minden új prompt megírásakor újrahasználtam.

Ez biztosította, hogy a promptok részletesek, strukturáltak és konzisztenssek legyenek, így az infrastruktúra kiszámítható és reprodukálható lett. Az AI időnként tett feltételezéseket, de a standardizált bemenet miatt sokkal könnyebb volt hibát keresni és finomhangolni.

Állapotkezelés

Az állapotkezelés is aggodalomra adott okot. Mi történik, ha új munkamenetet indítok, vagy ha többen kezdik alkalmazni az erőforrásokat AI-val? Hogyan tudjuk, ki mit és mikor módosított?

A kontroll érdekében a következő bevált gyakorlatokat követtem:

1. Minden erőforrás először CloudFormation-en keresztül jött létre, így biztonságosan át tudtam nézni és jóvá tudtam hagyni a változtatásokat.

2. Minden erőforrást konzisztensen tag-eltem, hogy az ownership, cél és környezet azonnal látható legyen.

3. Az AI-al cache fájlokat generáltattam, amik dokumentálták, melyik CloudFormation stack-ek jöttek létre, frissültek vagy törlődtek, így teljes összefoglalót kaptam minden általa érintett erőforrásról.

# Deployment Monitoring Checklist
## Mandatory Steps for Every Infrastructure Deployment
### Pre-Deployment
- [ ] Template validated with `aws cloudformation validate-template`
- [ ] Deployment tracking directory created
- [ ] deployment-info.md created with initial status
### During Deployment
- [ ] **IMMEDIATE**: First status check within 60 seconds of deployment start
- [ ] Status checks every 2-3 minutes until completion
- [ ] deployment-info.md updated after each status check
- [ ] Progress reported to user with current resources being created
- [ ] Any failures immediately reported with detailed error analysis
### Post-Deployment
- [ ] Final deployment status confirmed (SUCCESS or FAILED)
- [ ] deployment-info.md updated with final status
- [ ] If successful: kubectl configuration command provided
- [ ] If failed: Root cause analysis and template fixes documented
## Enforcement Reminders
- **Never end deployment conversation without final status**
- **Always provide next steps based on final outcome**
- **User should ask "What's the deployment status?" if monitoring stops**

Ez a munkafolyamat átlátható auditot biztosított — és meglepően jól működött (amit véletlenül ki is teszteltem egyszer, amikor bezártam a terminálomat a művelet közben).

Promptok tervezése

Ebben a projektben nem merültem el mélyen a prompt engineering világában. Inkább az AWS meglévő prompt mintáira támaszkodtam a prompt library segítségével, ami jó kiindulópontot adott anélkül, hogy mindent újra kellett volna találni.

A végső prompt a következő elemeket tartalmazta:

1. Lépésről lépésre történő utasítások: kérje be az EKS cluster nevét → generálja a CloudFormation template-et → telepítés → ellenőrzés

2. Szigorú követelmények az EKS és a CloudFormation számára: tag formátumok, endpoint konfigurációk, IAM szerepek, subnet elrendezések

3. Explicit validációs szabályok a gyakori EKS hibák elkerülésére

4. Integrált projekt standardok, így a kimenet konzisztens maradt

5. Telepítési automatizáció, beleértve script-eket, könyvtárstruktúrát és nyomkövető fájlokat

6. Addon telepítési utasítások (cluster autoscaler + AWS Load Balancer Controller) IRSA követelményekkel

Tanulságok

1. Az Amazon Q nagyon könnyen beállítható és használható — a MCP-khez való csatlakozás és az AWS-szel való interakció meglepően gyorsan ment.

2. Az EKS MCP API kifejezetten jól működik hibakeresésre — az EKS cluster állapotának lekérdezése és a problémák diagnosztizálása zökkenőmentes volt, gyakran gyorsabb, mint a manuális CLI használata.

3. A CloudFormation template-ek generálásának még mindig vannak hibái, még a CFN MCP használata mellett is — az AI gyorsan készít template-eket, de szinte mindig szükséges kisebb javítás.

4. Teljesen reprodukálható promptot létrehozni nehezebb, mint vártam — az iteratív chatelés és finomhangolás megbízhatóbb eredményeket hozott, mint egyetlen statikus prompt.

5. Az AI jobban alkalmas javaslatok készítésére, mint autonóm működésre — a kimenetet mindig ellenőrizni és validálni kell, különösen éles környezetben.

Összegzés

A projekt során többször is őszintén meglepődtem — néha azon, hogy az AI mennyire ügyesen oldott meg bizonyos feladatokat, máskor pedig azon, mekkorákat hallucinált.

Végül azt mondanám: az AI nem varázseszköz, amely önállóan képes kezelni egy komplex infrastruktúrát (legalábbis egyelőre nem), de már most is hasznos asszisztensként működik.

Érdekel a téma? Kérdés merült fel a cikkel kapcsolatosan? Foglalj egy ingyenes konzultációt és nézzük meg, hogy a Code Factory csapata miben tud segíteni neked / nektek! A szolgáltatásaink listáját itt találod meg!