Corgiro: Agent Skill ที่ช่วยให้การทำ Cloud operations สะดวกมากยิ่งขึ้น

งานประจำอย่างหนึ่งของคนที่ดูแลระบบ cloud คือการตรวจสถานะของ environment ต่างๆ ไม่ว่าจะเป็นการเช็ค AWS Health event ที่กระทบ account ไหน, การตรวจหา RDS หรือ EKS ที่ใกล้หมดระยะ End-of-Support, หรือสำรวจว่า account ไหนใน Organization ยังใช้งานได้ปกติอยู่บ้าง ปัญหาคือลูกค้าองค์กรขนาดใหญ่มักมีหลายสิบถึงหลายร้อย account การไล่เช็คทีละ account ด้วยมือทั้งช้าและมีความเสี่ยงที่จะตรวจไม่ครบ

Corgiro คือ Agent Skill แบบ open source ที่สร้างขึ้นมาเพื่อแก้ปัญหาที่กล่าวมานี้โดยเฉพาะ โดยเกิดจากการที่ ทาง AWS TAM (Technical Account Manager) ได้ทำงานร่วมกับ Enterprise customer หลายๆที่ แล้วพบว่ามีงาน operation หลายอย่างที่ AI ช่วยงานในส่วนนี้ได้และมีประโยชน์ต่อหลายๆองค์กร ซึ่งแนวคิดหลักคือ “AWS USER’s operational playbook, one command away” — รันคำสั่งเดียว แล้วให้ Agent กวาดข้อมูลทั้ง AWS Organization แบบ read-only จากนั้นได้รายงานที่พร้อมแชร์ให้ทีมงานได้ทันที

บทความนี้ผมจะพาไปดูว่า Corgiro ทำอะไรได้บ้าง พร้อมลงมือติดตั้งและทดสอบใช้งานจริงกับ AWS account เพื่อให้เห็นผลลัพธ์ที่ได้จริง

1. ความสามารถของ Corgiro ที่ครอบคลุมงาน Cloud Operations ที่ใช้บ่อย

• Account coverage – ตรวจว่า account ไหนใน Organization เข้าได้บ้าง เจอ account ใหม่หรือไม่
• Health event analysis – วิเคราะห์ AWS Health Dashboard event ทั้ง Organization พร้อม risk assessment (ต้องมี Business support+ plan ขึ้นไป)
• RDS/Aurora end-of-support analysis – หา instance ที่ใกล้หรือเลยกำหนด EOL แล้ว จัดลำดับความเสี่ยงพร้อมคำแนะนำอัปเกรด
• EKS end-of-support analysis – เช็ค Kubernetes version ที่ใกล้ end of support พร้อม upgrade path
• EC2 compute review – ตรวจสุขภาพ EC2 fleet ทั้งเรื่อง instance generation, Graviton eligibility, EBS optimization
• IAM security review – access key ที่ไม่ได้ใช้งาน, MFA gap ทั้ง Organization
• Bedrock model lifecycle – เช็คว่ามี Bedrock model ที่ deprecated หรือใกล้หมดระยะใช้งานหรือไม่
• RI/Savings Plans coverage – วิเคราะห์ commitment coverage และ utilization ทั้ง payer account
• Ask mode – ถามคำถาม แล้วให้ Agent วางแผน AWS CLI call เอง พร้อมให้ operator approve ก่อนรันจริง

จุดที่น่าสนใจคือ Corgiro ถูกออกแบบให้ read-only เป็นหลัก และมีการป้องกัน prompt injection ที่มาจาก resource metadata (เช่น ชื่อ resource หรือ tag ที่ถูกแต่งขึ้นมาเพื่อพยายามหลอกให้ Agent รันคำสั่งที่ไม่ควรรัน) ซึ่งเป็นเรื่องสำคัญมากเมื่อ Agent ต้องอ่านข้อมูลจากหลาย account ที่เราไม่ได้ควบคุมทั้งหมด

2. ทำไมเรื่องนี้ถึงสำคัญ

สำหรับทีมที่ดูแลลูกค้าหรือองค์กรที่มีหลายสิบถึงหลายร้อย account การไล่ตรวจ ด้วยมือทีละ account ไม่ใช่แค่กินเวลา แต่ยังเสี่ยงตรวจไม่ครบและพลาด finding สำคัญไป Corgiro แก้ปัญหานี้ด้วยการรวบ “playbook” ที่ทีม Cloud Operations ใช้งานจริงมาไว้ในคำสั่งเดียว จุดที่ทำให้ต่างจากการเขียน script เรียก API เองมีดังนี้:

• เห็นภาพทั้ง Organization ด้วยคำสั่งเดียว – แทนที่จะคลิกไล่ทีละ account คำสั่ง /corgiro <mode> เดียวจะ fan-out ไปทุก account ที่เข้าถึงได้แล้วรวมผลให้อัตโนมัติ
• Read-only และปลอดภัยตั้งแต่ออกแบบ – ค่า default เรียกแค่ describe/list/get การกระทำที่เปลี่ยนแปลง resource ต้องให้ผู้ใช้ approve ก่อนเสมอ และ credential ไม่ถูกแสดงออกมา
• เป็น playbook การใช้งานจาก USER จริง ไม่ใช่แค่ raw API – แต่ละ mode เหมือนฝัง operator ที่มีประสบการณ์ไว้ ทั้งเรื่องว่าควรเช็คอะไร ให้คะแนนความเสี่ยงอย่างไร และควรแนะนำ remediation แบบไหน
• Finding แม่นยำและอ้างอิงได้ – การวิเคราะห์ End-of-Support จะไม่ใช้ “ความจำ” ของโมเดลในการระบุวันหมดระยะ support แต่จะ scrape วันจากเอกสารทางการของ AWS ทุกครั้ง และถ้า scrape ไม่สำเร็จก็จะหยุด ไม่เดา
• ได้ deliverable ที่เอาไปใช้ต่อได้ทันที – ทุก mode render เป็นรายงาน HTML + Markdown แบบ self-contained พร้อม KPI card, ตาราง และ risk badge แชร์ได้เลยโดยไม่ต้องมี runtime เพิ่ม
• ครอบคลุม account ใหม่ให้อัตโนมัติ – ภายใต้ cross-account model, read-only role จะ deploy ไปยัง account ใหม่ให้เอง และ account-coverage จะ flag account ที่เพิ่งเพิ่มหรือเพิ่งเข้าไม่ได้ในทุกครั้งที่รัน

Corgiro ต่างจาก AWS Config, Security Hub หรือ Trusted Advisor อย่างไร

Corgiro ไม่ได้มาแทนบริการเหล่านี้ แต่ทำงานเสริมกัน AWS Config ติดตาม compliance rule, Security Hub รวบรวม security finding, Trusted Advisor ให้ best-practice check ตามเกณฑ์มาตรฐาน ส่วน Corgiro เพิ่มชั้นของการวิเคราะห์เชิง operation เข้ามา คือเชื่อมโยงข้อมูลข้าม service ให้ เช่น เอาสถานะ version ของ EKS ไปคำนวณกับค่า extended support ที่จะเกิดขึ้น แล้วเรียบเรียงออกมาเป็นรายงานที่อ่านรู้เรื่อง พร้อม workflow ที่ปรับแต่งเองได้ตามบริบทองค์กร

3. Corgiro ทำงานอย่างไร

เบื้องหลังการทำงานของ Corgiro สรุปได้เป็น 5 ขั้นตอนง่าย ๆ ตั้งแต่รับคำสั่งจนได้รายงาน:

• 1. รันคำสั่ง – SKILL.md จะอ่าน token แรกของคำสั่งเป็นชื่อ mode แล้ว route ไปยัง modes/<mode>/MODE.md (ถ้ายังไม่มี ~/.corgiro/config.json จะหยุดและบอกให้รัน setup ก่อน)
• 2. Resolve credential – อ่าน roster และ accessMode แล้วเลือกวิธีเข้าถึงแต่ละ account ตาม field via: ถ้าเป็น sso ใช้ CLI profile, ถ้าเป็น assume-role จะ AssumeRole เข้า CorgiroReadOnlyRole พร้อม external ID
• 3. Fan-out – กระจายงานด้วย parallel worker (default 4 พร้อมกัน) มี exponential backoff เมื่อโดน throttle แล้วเรียกเฉพาะ API แบบ read-only (describe/list/get)
• 4. Aggregate – เก็บผลข้อมูลของแต่ละ account เป็น JSON แยกไว้ก่อน (per-account) แล้วค่อยรวมเป็น aggregated.json วิธีนี้ทำให้ยังได้ผลบางส่วนแม้บาง account จะ fail
• 5. สร้างรายงาน – render ออกมาเป็นรายงาน HTML + Markdown แบบ self-contained พร้อม branding, KPI card, ตาราง และ risk badge ที่แชร์ให้ทีมได้ทันที

4. ลงมือติดตั้งและทดสอบจริง

1ติดตั้ง Skill

การติดตั้งทำผ่าน skills CLI ซึ่งรองรับทั้ง Kiro CLI และ Agent อื่น ๆ:

npx skills@latest add aws-samples/sample-corgiro-aws-ops-skills -g -a kiro-cli -y

คำสั่งนี้จะ clone repository และ copy skill ไปไว้ที่ ~/.kiro/skills/corgiro ให้พร้อมใช้งานทันที

2Setup Multi-Account Access

Corgiro รองรับ 2 รูปแบบการเข้าถึง:

• Option A (Existing access) – ใช้ IAM Identity Center ที่มีอยู่แล้ว ไม่ต้องแก้ไข Organization ใด ๆ Corgiro จะ discover account/role ที่เรามีสิทธิ์อยู่แล้วอัตโนมัติ
• Option B (Cross-account setup) – deploy CorgiroReadOnlyRole ผ่าน StackSet ทั้ง Organization ให้ coverage ครบทุก account รวมถึง account ใหม่ในอนาคต โดยใช้ delegated admin กับ external ID เพื่อความปลอดภัย

ทั้งสองแบบจะบันทึกผลไว้ที่ ~/.corgiro/config.json และ ~/.corgiro/state/roster.json พร้อม enforce permission chmod 700/600 เพื่อป้องกันไม่ให้ไฟล์ state (ที่มี external ID และ account roster) หลุดไปให้คนอื่นอ่านได้

3รัน Account Coverage

หลัง setup แล้ว คำสั่งแรกที่ควรรันคือ account-coverage เพื่อยืนยันว่า Corgiro เข้าถึง account ที่ต้องการได้จริง:

/corgiro account-coverage

Mode นี้จะ probe ทุก account ด้วย aws sts get-caller-identity แบบ parallel (default 4 accounts พร้อมกัน) แล้วจัดกลุ่มผลลัพธ์เป็น reachable, auth_expired, role_missing, trust_mismatch ฯลฯ พร้อมสร้างรายงาน HTML/Markdown พร้อม KPI card สรุปจำนวน account ที่เข้าถึงได้

4รัน RDS End-of-Support Analysis กับข้อมูลจริงใน account ทดสอบ

ส่วนที่น่าสนใจที่สุดคือการลองรัน rds-eol-analysis จริงกับ account ทดสอบที่มี RDS instance อยู่ 2 ตัว ผลลัพธ์ที่ Agent ดึงออกมาได้:

Corgiro จะไม่เดา EOL date จาก training data — mode นี้บังคับให้ Agent ไป scrape release calendar ของ RDS for PostgreSQL จากเอกสารทางการของ AWS ใหม่ทุกครั้งที่รัน แล้ว match version ที่เจอกับวันหมดระยะ support จริง

ขณะที่ทดสอบ (สิงหาคม 2026) minor version 16.13 เหลือเวลาไม่ถึง 6 เดือนก่อนหมดระยะ standard support จึงจัดอยู่ในระดับ ความเสี่ยงสูง ตาม risk tier ของ mode นี้ ในขณะที่ major version 16 โดยรวมยังมี standard support ถึงปี 2029 (ความเสี่ยงต่ำ) ความแตกต่างนี้สำคัญมาก เพราะถ้าดูแค่ major version เฉย ๆ อาจพลาดไม่เห็นว่า minor version ปัจจุบันที่ใช้งานอยู่กำลังจะหมดระยะ support เร็วกว่าที่คิด

นอกจากนี้ยังเจอ finding อื่นที่ควรตาม follow-up ต่อ:

• mydbinstancreadreplica มี backup retention = 0 วัน คือไม่มี automated backup เลย
• ทั้งสอง instance ไม่ได้เปิด Multi-AZ

Finding เหล่านี้ใช้เป็นจุดเริ่มต้นในการปรับปรุงเรื่อง resiliency และ data protection ได้ทันที โดยไม่ต้องเข้าไปไล่ดูทีละ console เอาเวลาไปโฟกัสกับงานวิเคราะห์ด้านอื่นต่อ

5. ความปลอดภัยที่ออกแบบมาให้เหมาะกับงาน Multi-Account

สิ่งที่น่าสนใจตอนอ่าน source code คือ Corgiro ไม่ได้ treat ข้อมูลที่ดึงมาจาก AWS API เป็นข้อมูลที่ไว้ใจได้เสมอไป — resource name, tag, description ทั้งหมดถูก treat เป็น untrusted data เพราะในโลกจริง account ที่ compromised อาจจะแอบฝัง instruction ปลอม ๆ ไว้ใน tag เพื่อพยายามหลอกให้ Agent รันคำสั่งที่ไม่ควรรัน (prompt injection) Corgiro มี pattern detection และ sanitization step ที่ escape ค่าพวกนี้ก่อนใส่ลงรายงาน และห้าม Agent ใช้ tag value ไปสร้าง CLI command หรือเปลี่ยน execution flow เด็ดขาด

อีกจุดที่สำคัญคือความแตกต่างของ enforcement ระดับ IAM: ถ้าเลือก Option B (cross-account role) read-only จะถูก enforce จริงที่ระดับ IAM ผ่าน CorgiroReadOnlyRole แต่ถ้าเลือก Option A (ใช้ access ที่มีอยู่) read-only จะเป็นแค่ “behavioral only” คือขึ้นอยู่กับ permission set ที่ operator มีอยู่แล้ว Corgiro เตือนเรื่องนี้อย่างชัดเจนในรายงาน พร้อม flag เป็น “Residual Risk” ถ้า operator ใช้ role ที่ไม่ใช่ read-only

6. สิ่งที่ควรทราบเพิ่มเติม

• Corgiro เป็น sample code แบบ open source (MIT-0 license) สำหรับ demo และการเรียนรู้ ไม่ใช่ AWS managed service — ก่อนใช้งานจริงกับ production organization ควร review และทดสอบให้ละเอียดก่อน
• ต้องมี AWS CLI v2 และ IAM Identity Center (SSO) เป็น prerequisite — ถ้า Organization ยังไม่ได้ใช้ Identity Center จะต้อง setup ก่อน
• ถ้าต้องการ mode เฉพาะทางที่ไม่มีใน list ปัจจุบัน Corgiro มี mode-builder ให้สร้าง mode ใหม่เองได้ตาม use case ขององค์กร โดยผ่านขั้นตอน ideation, AWS API discovery, drafting และ validation
• ทุกผลลัพธ์ที่ Corgiro สร้างเป็น AI-generated — ควร review และตรวจสอบความถูกต้องก่อนนำไปใช้ตัดสินใจด้าน operation จริง

7. ทดลองใช้งานได้แล้วตอนนี้

Corgiro เปิดเป็น open source อยู่ที่ aws-samples/sample-corgiro-aws-ops-skills พร้อมเอกสารการติดตั้งและตัวอย่างรายงานให้ดูก่อนตัดสินใจ สำหรับทีม Cloud Operations หรือองค์กรที่มีหลาย AWS account นี่คือจุดเริ่มต้นที่ดีในการลดเวลาตรวจ environment แบบ manual แล้วเอาเวลาไปโฟกัสกับการวิเคราะห์ด้านอื่นๆ ต่อไป

อ้างอิง:
Corgiro – AWS Cloud Operation Skills (aws-samples)
Amazon RDS for PostgreSQL release calendar