Azure Cost Review — ทำไมเกิน budget และลดอะไรได้บ้าง
วิเคราะห์ค่าใช้จ่าย Azure non-prod ทั้ง 2 subscription จากข้อมูลจริง (Cost Management API + live cluster) — เกิน plan 69% ในเดือนกรกฎาคม แผนลบ dev/SIT ช่วยได้เท่าไหร่จริง และต้องทำอะไรอีกถึงจะเข้า budget
อัปเดต: 2026-08-21
แหล่งข้อมูล: Azure Cost Management API + query cluster จริง (
aks-SupperApp-dev) วันที่ 21/08/2026 · อัตราแลกเปลี่ยนที่ใช้ ~33.42 THB/USD (อิงจากตาราง billing)
1. เกิดอะไรขึ้น — ภาพรวม
เดือนกรกฎาคม 2026 ใช้จริง $3,387.56 (฿113,212) จาก plan $2,000 → เกิน $1,387.56 (+69%)
แต่ประเด็นสำคัญคือ เกินไม่เท่ากันทั้ง 2 subscription:
| Subscription | Plan | ก.ค. ใช้จริง | ส่วนต่าง | สถานะ |
|---|---|---|---|---|
| EximNonPrdHubSua | $931.03 | $1,056.06 | +$125.03 | +13% — เกือบตรง plan |
| EximSuperAppDev&SIT | $1,062.02 | $2,331.50 | +$1,269.48 | 🔴 +120% — ตัวปัญหา |
| รวม | $2,000.00 | $3,387.56 | +$1,387.56 | +69% |
🔑 91% ของยอดที่เกิน ($1,269 จาก $1,388) มาจาก subscription เดียว คือ EximSuperAppDev&SIT — ส่วน hub นั้นคนตั้ง plan เผื่อไว้ ~$931 อยู่แล้วและมันก็ออกมาใกล้เคียง
แนวโน้มน่ากังวล — subscription ที่เกินยังโตขึ้นทุกเดือน
| เดือน | Hub | Dev&SIT | รวม (USD) | รวม (THB) |
|---|---|---|---|---|
| เม.ย. 2026 | 44.27 | 29.47 | 73.74 | 2,416 |
| พ.ค. 2026 | 1,178.39 | 1,663.47 | 2,841.86 | 92,616 |
| มิ.ย. 2026 | 1,216.74 | 2,112.54 | 3,329.28 | 111,165 |
| ก.ค. 2026 | 1,056.06 | 2,331.50 | 3,387.56 | 113,212 |
- Dev&SIT: 1,663 → 2,113 → 2,332 = โตขึ้น 40% ใน 2 เดือน ยังไม่มีทีท่าหยุด
- Hub: ทรงตัวแล้วเริ่มลง (1,178 → 1,217 → 1,056)
- เม.ย. ต่ำเพราะเป็นเดือนที่เพิ่งเริ่มสร้าง environment (ยังไม่เต็มเดือน)
หมายเหตุ: ตัวเลข $771 ที่เคยคุยกันคือคนละขอบเขต
$771 ที่เคยรายงานคือ เฉพาะส่วน AKS (resource group MC_* + AKS control plane meter) และเป็นช่วง 1–21 ส.ค. (21 วัน) เท่านั้น — เป็น ส่วนย่อย ของ subscription EximSuperAppDev&SIT ไม่ใช่ยอดทั้งบิล เอกสารนี้ใช้ตัวเลขเดือนกรกฎาคมเต็มเดือนทั้ง 2 subscription
2. เงินไปไหนบ้าง
2.1 EximSuperAppDev&SIT — $2,331.50 (฿77,919)
| บริการ | USD | สัดส่วน | ประเภท |
|---|---|---|---|
| Virtual Machines (AKS nodes 6× D4s_v4) | 920.85 | 39.5% | shared cluster |
| Virtual Network (private endpoints) | 249.24 | 10.7% | แยกตาม env |
| Azure Monitor (Log Analytics) | 211.41 | 9.1% | shared workspace |
| Azure DevOps | 170.00 | 7.3% | ⚠️ ไม่ใช่ infra |
| Azure Grafana | 162.43 | 7.0% | shared 1 instance |
| PostgreSQL | 159.17 | 6.8% | shared 1 server |
| Storage | 105.84 | 4.5% | ~98% เป็น AKS disk |
| Defender for Cloud | 74.82 | 3.2% | ตามจำนวน resource |
| AKS control plane (tier Standard) | 74.29 | 3.2% | shared 1 cluster |
| Key Vault | 58.68 | 2.5% | shared (คิดตาม transaction) |
| Load Balancer | 52.15 | 2.2% | บางส่วนแยก env |
| Container Registry | 51.67 | 2.2% | shared 1 registry |
| Redis Cache | 29.76 | 1.3% | shared 1 instance |
| Service Bus | 10.06 | 0.4% | shared |
| DNS + EventGrid + Bandwidth | 1.13 | 0.0% |
2.2 🔴 ปมที่ยังตอบไม่ได้ — Hub $1,056/เดือน มีทรัพยากรแค่ชิ้นเดียว
Subscription EximNonPrdHubSua มีทรัพยากร ชิ้นเดียวทั้ง subscription คือ APIM exim-az-hub-apim และตรวจแล้วเป็น Developer tier capacity 1 ซึ่งราคาปกติอยู่ที่ ~$50–75/เดือน
แต่บิลออกมา $1,056–1,217/เดือน ตลอด พ.ค.–ก.ค. → มีส่วนที่อธิบายไม่ได้ ~$1,000/เดือน (฿33,000)
ตรวจ activity log ตั้งแต่ 1 มิ.ย. แล้ว ไม่พบการเปลี่ยน SKU เลย → ไม่ใช่กรณี “เคยเป็น Premium แล้วเพิ่งลด”
⚠️ ผมเข้าถึง Cost Management ของ subscription นี้ไม่ได้ (RBAC ปฏิเสธ) เลยเจาะดู meter ไม่ได้ — ข้อนี้จึงเป็น สมมติฐานที่ต้องไปยืนยัน ไม่ใช่ข้อสรุป
สมมติฐานที่เป็นไปได้มากที่สุด: ยอดนี้อาจไม่ใช่ค่า infra แต่เป็น ค่า license Azure DevOps (ผู้ใช้ × $6/เดือน) ที่ผูกบิลไว้กับ subscription นี้ — สังเกตว่าฝั่ง Dev&SIT ก็มีรายการ “Azure DevOps $170” ที่ไม่ผูกกับ resource group ใดๆ เช่นกัน
วิธียืนยัน (เลือกทางใดทางหนึ่ง):
- Azure Portal → Cost analysis เลือก subscription
EximNonPrdHubSua→ group by Service (ต้องใช้สิทธิ์ billing ของคนที่ทำตารางสรุปนี้ได้) - dev.azure.com/eximth → Organization settings → Billing — เห็นจำนวน user license + parallel jobs และ subscription ที่ผูกไว้โดยตรง ไม่ต้องใช้สิทธิ์ Cost Management
ผลลัพธ์ต่างกันคนละทาง:
- ถ้าเป็น license → ไม่ใช่ค่า infra ต้องย้ายออกจาก budget infra (แล้ว infra จริง = เฉพาะ subscription Dev&SIT) ไม่ใช่เรื่องที่ตัดได้ด้วยการแก้ระบบ
- ถ้าเป็น ค่า APIM จริง → ผิดปกติหนัก ต้องเปิด support case กับ Microsoft
ห้ามสั่ง “ลด SKU ของ APIM” — มันเป็น Developer tier (ต่ำสุดที่รองรับ VNet Internal) อยู่แล้ว ลดไม่ได้อีก
2.3 ความจริงที่เปลี่ยนแผน — ของแพงส่วนใหญ่เป็น “ตัวเดียวใช้ร่วมกันทุก env”
ตรวจ resource จริงทั้งหมดแล้วพบว่า:
| ทรัพยากร | จำนวน | SKU ปัจจุบัน | ลบ dev/SIT แล้วหายไหม |
|---|---|---|---|
| AKS cluster | 1 | 6 nodes D4s_v4 | ❌ ไม่หาย (ลด node ได้บ้าง) |
| PostgreSQL | 1 | Standard_B2ms Burstable 32GB | ❌ ไม่หาย — เล็กสุดอยู่แล้ว |
| Redis | 1 | Balanced_B0 | ❌ ไม่หาย — เล็กสุดอยู่แล้ว |
| Container Registry | 1 | Premium | ❌ ไม่หาย |
| Key Vault | 1 | — | ❌ ไม่หาย |
| Grafana | 1 | — | ❌ ไม่หาย |
| Log Analytics workspace | 1 | — | ❌ ไม่หาย (ปริมาณ log ลด) |
| Private Endpoint | 31 | dev 12 · SIT 7 · UAT 8 · shared 4 | ✅ ลบได้ 19 ตัว |
| Storage account | 13 | dev 6 · SIT 3 · UAT 4 | ✅ ลบได้ แต่เกือบไม่มีผล |
🔑 นี่คือหัวใจของเรื่อง — ของแพง (PG, Redis, ACR, KV, Grafana, cluster) เป็น instance เดียวที่ dev/SIT/UAT ใช้ร่วมกัน ขนาดของมันไม่ได้ผูกกับจำนวน environment ลบ dev/SIT ไปมันก็ยังอยู่เท่าเดิม และ PG กับ Redis ก็ถูกตั้งไว้ที่ SKU เล็กที่สุดอยู่แล้ว ลดต่ออีกไม่ได้
กับดักที่ต้องรู้: ลบ storage account ของ dev/SIT ประหยัดแทบเป็นศูนย์
รายการ “Storage $105.84” ดูเหมือนเยอะ แต่แยกออกมาแล้ว $103.86 เป็น managed disk ของ AKS node (ผูกกับจำนวน node ไม่ใช่ env) → storage account ทั้ง 13 ตัวรวมกันเหลือแค่ ~$2/เดือน
แปลว่าการไล่ลบ storage account ของ dev/SIT (9 ตัว) ประหยัดได้ ไม่ถึง $1.50/เดือน — ไม่คุ้มความเสี่ยง
ทำไม AKS ถึงกิน $920 ทั้งที่ CPU แทบไม่ถูกใช้
วัดจาก cluster จริง 21/08:
- 6 nodes (system 1 + user 5) — system pool ถูก taint
CriticalAddonsOnlyapp pod ลงไม่ได้ - CPU ที่จองไว้ (request) รวม 18.82 cores แต่ใช้จริงแค่ 2.67 cores = พอง 7 เท่า
- cluster-autoscaler ตัดสินใจจาก request ไม่ใช่การใช้จริง → เห็น user pool เต็ม 89% เลยยุบ node ไม่ได้ ทั้งที่ CPU จริงเดินอยู่ 12%
ตัวที่พองที่สุดคือ app-routing-system: จอง 4 cores แต่ใช้จริง 0.06 core (67 เท่า) เพราะมี NGINX ingress controller 4 ชุดแยกกัน (public / internal / sit / argocd) ชุดละ 2 replicas
| Namespace | CPU จอง | CPU ใช้จริง | พอง |
|---|---|---|---|
| kube-system | 6.57 | 1.53 | 4.3× |
| app-routing-system | 4.00 | 0.06 | 67× |
| superappdev | 2.90 | 0.13 | 22× |
| superappuat | 2.70 | 0.21 | 13× |
| security | 1.10 | 0.01 | 110× |
| superappsit | 0.10 | ~0 | — |
Memory เป็นตัวกำหนดเพดานล่างของจำนวน node ไม่ใช่ CPU — pod ทั้ง cluster ใช้ memory จริง 22.76 GiB ส่วน node หนึ่งตัว (D4s_v4) ให้ pod ได้ 13.33 GiB
| จำนวน node | รองรับได้ | 22.76 GiB คิดเป็น | ผล |
|---|---|---|---|
| 1 | 13.33 | 171% | ❌ ใส่ไม่ลงทางกายภาพ |
| 2 | 26.66 | 85% | ⚠️ ไม่มี headroom |
| 3 | 39.99 | 57% | ✅ เพดานล่างที่ใช้ได้จริง |
| 5 (ปัจจุบัน) | 66.63 | 34% | เกินความจำเป็น 2 ตัว |
ดังนั้น “ใช้ node เดียวพอ” เป็นไปไม่ได้ — CPU พอ (62%) แต่ memory ต้องการ 171% ของ node เดียว · เป้าหมายที่ทำได้จริงคือ 3 user node (ยังต้อง verify P95 7 วันก่อนลงมือ)
3. ปรับอะไรได้บ้าง
3.1 แผนลบ dev + SIT ได้เท่าไหร่จริง
| รายการ | ประหยัด/เดือน | ความมั่นใจ |
|---|---|---|
| Private endpoint 19 ตัว (dev 12 + SIT 7) | ~$130–140 | สูง |
| AKS ลดได้ 1 node (จาก request ที่ว่างลง) | ~$154 | สูง |
sit-nginx-internal ingress + internal LB | ~$12 | สูง |
| Log Analytics ingest ลดลง (pod น้อยลง 24 ตัว) | ~$30–60 | ปานกลาง — ยังไม่ verify |
| Defender (resource น้อยลง) | ~$10–20 | ต่ำ |
| Storage account 9 ตัว | ~$1.50 | สูง (แต่แทบไม่มีผล) |
| รวม | ~$340–390 (฿11,400–13,000) |
🔴 ลบ dev + SIT ทั้งหมด กู้คืนได้แค่ ~27–31% ของยอดที่เกิน ($340–390 จาก $1,269) — เพราะเงินส่วนใหญ่อยู่บน shared resource ที่ไม่หายไปตาม environment
3.2 Simulation — ถ้าลด request ที่จองเวอร์ จะเหลือกี่ node
คำถามที่มักเข้าใจผิด: “ลด RAM ที่จองไว้ 512Mi ต่อ pod ลงมา น่าจะประหยัดได้เยอะ”
คำตอบจากข้อมูลจริง: ลด RAM แทบไม่ช่วยอะไรเลย เพราะ RAM ไม่ใช่ตัวที่บีบ — CPU ต่างหาก
| กลุ่ม (user pool) | pods | CPU จอง | CPU ใช้จริง | พอง | RAM จอง | RAM ใช้จริง | พอง |
|---|---|---|---|---|---|---|---|
| ของเรา | 61 | 7.55 | 1.00 | 8× | 16.38 GiB | 12.05 GiB | 1.4× |
| kube-system (Azure addon) | 80 | 5.09 | 0.81 | 6× | 11.38 | 6.63 | 1.7× |
| app-routing (nginx) | 8 | 4.00 | 0.04 | 105× | 0.99 | 0.62 | 1.6× |
RAM จองเกินแค่ 1.4 เท่า = headroom ที่กำลังพอดี (ต่ำกว่านี้เสี่ยง OOM) ส่วน CPU จองเกิน 8–105 เท่า ยืนยันด้วยตัวเลขตรงๆ: request ชุดปัจจุบันต้องการ CPU = 5 node แต่ RAM = แค่ 2 node → ลด RAM ลงไปอีกก็ไม่ทำให้ node ลด เพราะ CPU บีบอยู่ที่ 5
ผลจำลอง 5 แผน
| แผน | node ที่ต้องใช้ | ตัวที่บีบ | ประหยัด/เดือน |
|---|---|---|---|
| S0 ปัจจุบัน | 5 | CPU | — |
| S1 ลด CPU request เฉพาะ pod ของเรา | 4 | CPU | $159 |
| S2 S1 + app-routing เหลือ 1 replica | 3 | RAM ใช้จริง | $319 |
| S3 S2 + ลด CPU ของ app-routing อีก | 3 | RAM ใช้จริง | $319 — ไม่ได้เพิ่ม |
| S4 S3 + ลบ dev/SIT ออกด้วย | 2 | RAM ใช้จริง | $478 |
(node ละ $143 VM + $16 disk = $159/เดือน)
2 ข้อสรุปที่สำคัญกว่าตัวเลข:
- 🔑 มี “จุดหยุด” ที่ 3 node — ไล่ลด CPU ต่อไปเสียเวลาเปล่า ดูจาก S3: ลด CPU จนเหลือความต้องการแค่ 2 node ก็จริง แต่ RAM ที่ใช้จริงบังคับไว้ที่ 3 อยู่ดี → ทำถึง S2 แล้วหยุด จะลงต่ำกว่า 3 ต้องเอา workload ออกจริง (S4) เท่านั้น
- 🔑 ลด CPU request อย่างเดียวได้แค่ 4 node ต้องทำคู่กับ app-routing ถึงจะถึง 3 — สองอย่างนี้ต้องทำด้วยกัน ทำอย่างเดียวได้ครึ่งเดียว
เจาะ pod ที่จอง RAM 512Mi ขึ้นไป — และ 2 ตัวที่ต้องรีบแก้
pod ที่จอง 512Mi มีแค่ 7 ตัว เป็น user-service (5) กับ thirdparty-service (2) ใช้จริง 21–48% → ลดเหลือ 256Mi ได้ แต่ไม่ทำให้ node ลด
แต่ที่เจอแล้วน่าสนใจกว่าคือ 2 ตัวใน namespace security:
| Pod | RAM จอง | RAM ใช้จริง | % | ต้องทำอะไร |
|---|---|---|---|---|
dependency-track-apiserver | 4,096Mi | 855Mi | 21% | จองเกิน 4.8 เท่า — ลดเหลือ ~1,536Mi |
sonarqube | 2,048Mi | 2,374Mi | 116% | 🔴 ใช้เกินที่จอง — ต้องเพิ่มเป็น ~3,072Mi |
sonarqube เป็น pod ที่กิน RAM มากที่สุดใน cluster และจองไว้ ต่ำกว่าที่ใช้จริง → เสี่ยงโดน OOM-kill เวลา memory ตึง โดยเฉพาะตอนยุบ node ต้องแก้ก่อนเริ่มยุบ node
ถ้าจะลงมือ ตั้งค่าประมาณนี้
| เป้าหมาย | ปัจจุบัน | แนะนำ | เหตุผล |
|---|---|---|---|
| CPU service ทั่วไป | 100m | 50m | ใช้จริงเฉลี่ย 16m = เผื่อ 3 เท่า |
CPU user-service / thirdparty-service | 250m | 100m | ใช้จริง 2–15m |
| RAM service ทั่วไป | 128Mi | คงเดิม | headroom พอดีแล้ว |
| RAM ที่ตั้ง 512Mi (7 pods) | 512Mi | 256Mi | ใช้จริง 21–48% (ไม่เร่งด่วน) |
dependency-track | 4,096Mi | 1,536Mi | ใช้จริง 855Mi |
sonarqube | 2,048Mi | 3,072Mi | 🔴 ใช้จริง 2,374Mi — ต้องเพิ่ม |
app-routing × 4 | minReplicas: 2 | minReplicas: 1 | ใช้จริง 0.04 core จาก 4 core ที่จอง |
แก้ที่ Backend_Iac deployment yaml (folder ตาม env, branch development) แล้ว cluster-autoscaler จะยุบ node ให้เอง ไม่ต้อง scale node เองและไม่ต้องสู้กับ ArgoCD — CA คุมจำนวน node · ArgoCD คุมจำนวน pod
⚠️ ตัวเลขทั้งหมดมาจาก snapshot วันเดียว (21/08) — ก่อนแก้จริงต้องดู P95 ย้อนหลัง 7 วัน จาก Grafana โดยเฉพาะ sonarqube ที่แตะเพดานอยู่แล้ว
3.3 มาตรการที่ไม่ต้องลบ environment (ทำคู่กันได้)
| # | มาตรการ | ประหยัด/เดือน | ความเสี่ยง |
|---|---|---|---|
| A | AKS tier Standard → Free (non-prod ไม่ต้องการ Uptime SLA) | ~$74 | ต่ำมาก |
| B | app-routing ตั้ง scaling.minReplicas: 1 ทั้ง 4 ตัว → ลด node เพิ่มอีก 1 | ~$154 | ต่ำ |
| C | Key Vault: CSI rotation poll 2m → 30m–1h | ~$40–50 | ต่ำ |
| D | Log Analytics diet (basic tier / filter namespace / ลด retention) | ~$60–100 | ปานกลาง |
| E | Reserved Instance / Savings Plan บน node ที่เหลือ | ~$150–200 | ต่ำ (ผูก 1–3 ปี) |
| F | ทบทวน Grafana ($162) — จำเป็นแค่ไหนถ้าเหลือแต่ UAT | สูงสุด $162 | ต้องถามทีม |
ข้อ C — ทำไม Key Vault ถึงแพงถึง $58/เดือน
Key Vault คิดเงินตามจำนวน transaction ไม่ใช่ตามขนาด — ตรวจ daemonset บน cluster จริงพบว่า CSI secret driver ตั้ง --rotation-poll-interval=2m คือ ยิงถาม Key Vault ทุก 2 นาที คูณจำนวน pod × จำนวน secret ต่อ pod
สำหรับ non-prod ที่ secret แทบไม่เปลี่ยน การ poll ทุก 2 นาทีไม่มีประโยชน์ — ปรับเป็น 30 นาที–1 ชั่วโมงจะลด transaction ลง 15–30 เท่า แก้ที่ addon config จุดเดียว ไม่เกี่ยวกับการลบ environment
3.4 รวมทั้งหมดแล้วเข้า budget ไหม
จัดใหม่ให้ตรงกับ simulation §3.2 (แยก “เงินที่ได้จากการลด node” ออกมาก้อนเดียว จะได้ไม่นับซ้ำ):
| ขั้น | ยอดคงเหลือ/เดือน |
|---|---|
| EximSuperAppDev&SIT ปัจจุบัน (ก.ค.) | $2,331 |
| − ลด node 5 → 2 (S4 = right-size CPU + app-routing + ลบ dev/SIT) | −$478 |
| − ส่วนของ dev/SIT ที่ไม่ใช่ node (PEP $135 + LB $12 + log $40 + Defender $15) | −$204 |
| − AKS tier Free (A) | −$74 |
| − Key Vault poll (C) | −$45 |
| − Log Analytics diet (D) | −$60–80 |
| − Reserved Instance บน 2 node ที่เหลือ (E) | −$100 |
| คงเหลือ | ~$1,330–1,370 |
| + Hub (ยังไม่แก้) | +$1,056 |
| รวมทั้งหมด | ~$2,390–2,430 |
🔴 ทำครบทุกข้อรวมทั้งลบ dev/SIT แล้ว ยังเกิน $2,000 อยู่ประมาณ $390–430
ทางเดียวที่จะถึง $2,000 คือต้องเคลียร์ปม Hub ~$1,000/เดือน ให้ได้ก่อน (ข้อ 2.2) — ถ้าพิสูจน์ว่าเป็นค่า license ก็ต้องย้ายออกจาก budget infra แล้วตัวเลขจะเปลี่ยนไปคนละภาพทันที
ถ้าเคลียร์ hub ไม่ได้จริงๆ ทางเลือกที่เหลือคือต้องไปลดฝั่ง UAT เอง (ทบทวน Grafana, ลดขนาด node SKU) ซึ่งกระทบ environment ที่ต้องใช้จริง
3.5 ลำดับที่แนะนำ
- เคลียร์ปม Hub ก่อนทุกอย่าง (ข้อ 2.2) — เป็นก้อนใหญ่สุดและอาจไม่ใช่ค่า infra ด้วยซ้ำ ใช้เวลาแค่เปิด Portal ดู
- ข้อ A + C — คำสั่ง/config จุดเดียว ได้ ~$120/เดือน ไม่กระทบใคร ทำได้วันนี้
- 🔴 แก้
sonarqubeเป็น 3,072Mi ก่อนแตะเรื่อง node (§3.2) — ตอนนี้มันใช้ RAM เกินที่จองไว้ 116% ถ้ายุบ node ก่อนแก้ ตัวนี้จะโดน OOM-kill เป็นตัวแรก - ดึง P95 ย้อนหลัง 7 วันจาก Grafana ยืนยันตัวเลขใน §3.2 ก่อนตั้ง request จริง
- ข้อ B + right-size CPU (S2) — ทำคู่กัน ได้ 5 → 3 node ≈ $319/เดือน โดยไม่ต้องลบ environment
- ลบ dev + SIT ตามแผน (→ S4 = 2 node) — ดูข้อ 4 เป็นงานโปรเจกต์ ไม่ใช่กดปุ่มเดียว
- ข้อ D — Log Analytics
- ข้อ E (Reserved Instance) — ทำ หลังสุด เมื่อจำนวน node นิ่งแล้ว ไม่งั้นจะ commit ผิดขนาด (2 node ที่เหลือ ≠ 5 node วันนี้)
4. ⚠️ การลบ dev/SIT จริง — เป็นงานโปรเจกต์ ไม่ใช่กดปุ่มเดียว
ห้ามใช้ kubectl delete namespace ตรงๆ — ArgoCD ตั้ง selfHeal: true ไว้ มันจะสร้างกลับทันที การลบต้องทำผ่าน git (Backend_Iac) + ลบ ArgoCD Application ตามลำดับ
สิ่งที่ต้องไล่เก็บให้ครบ (ถ้าตกข้อใดข้อหนึ่งจะเหลือของค้างที่ยังเสียเงินหรือพังเงียบ):
| # | ของที่ต้องจัดการ | หมายเหตุ |
|---|---|---|
| 1 | ArgoCD Application {svc}-dev, {svc}-sit + app-of-apps superapp-dev | ต้องลบก่อน ไม่งั้น selfHeal สร้าง namespace กลับ |
| 2 | Manifest ใน Backend_Iac (src/yamls/dev/, src/yamls/sit/) | ต้นทางที่แท้จริง |
| 3 | Private endpoint 19 ตัว + NIC + DNS record | ตัวที่ประหยัดเงินจริงที่สุด |
| 4 | Storage account 9 ตัว + EventGrid system topic | ต้อง backup ก่อนถ้ามีข้อมูลที่ต้องเก็บ |
| 5 | Database/schema ของ dev+SIT บน PG server ที่ใช้ร่วมกัน | ⚠️ server เดียวปนกัน 3 env ลบผิดตัว = UAT พัง |
| 6 | Redis key prefix ของ dev/SIT | instance เดียวกัน แยกด้วย prefix |
| 7 | API ของ dev/SIT บน APIM + routing | ตาม convention {env}-{service}-api |
| 8 | CI/CD pipeline ที่ deploy ลง dev/SIT (GITOPS_BRANCH) | ไม่แก้ = build ล้มทุกครั้ง |
| 9 | sit-nginx-internal NginxIngressController CR | ลบแล้วได้ internal LB คืนด้วย |
| 10 | Secret ของ dev/SIT ใน Key Vault | ลดจำนวน transaction ตามข้อ C |
🔴 ข้อ 5 อันตรายที่สุด — PostgreSQL เป็น server เดียวที่ dev/SIT/UAT ใช้ร่วมกัน และชื่อ database ของ dev บางตัวไม่มี prefix บอก env ห้ามลบด้วยการ match ชื่อแบบ pattern เด็ดขาด ต้องไล่ยืนยันทีละตัวก่อน
5. สิ่งที่ยังต้องยืนยันก่อนลงมือ
| # | เรื่อง | ทำไมต้องเช็ค |
|---|---|---|
| 1 | ปม Hub $1,056 (ข้อ 2.2) | ก้อนใหญ่สุด และเปลี่ยนภาพรวมทั้งหมด |
| 2 | P95 CPU/Memory ย้อนหลัง 7 วัน จาก Grafana | ตัวเลขในเอกสารนี้เป็น snapshot วันเดียว พอสำหรับตัดสินใจทิศทาง แต่ไม่ควรใช้ตั้งค่า request รายตัว — โดยเฉพาะ sonarqube ที่ใช้เกิน request อยู่แล้ว (§3.2) |
| 3 | สัดส่วน Log Analytics ที่มาจาก dev/SIT | ตัวเลข $30–60 เป็นการประมาณ ยังไม่ได้ query จริง |
| 4 | dev/SIT ยังมีใครใช้อยู่ไหม | SIT แทบว่างแล้ว (เหลือ 1 pod) แต่ dev ยังใช้พัฒนาอยู่ทุกวัน |
| 5 | cluster-autoscaler ยุบ node ได้จริงไหม | อาจถูกบล็อกด้วย PodDisruptionBudget หรือ pod ที่ evict ไม่ได้ |
สถานะ: ยังไม่ได้ execute อะไรทั้งสิ้น — ทุกข้อในเอกสารนี้เป็นข้อเสนอที่รอการตัดสินใจ