Final

Lambda Architecture Comparison

มีการทดสอบ AWS Lambda เพื่อเปรียบเทียบสถาปัตยกรรม x86_64 กับ ARM64 (Graviton2) ภายใต้ workload จริง
โดยมีเป้าหมายเพื่อประเมินด้านประสิทธิภาพ (Performance), ต้นทุน (Cost), และความเสถียร (Reliability) ตามแนวทางของ AWS Well-Architected Framework

Pillar	Finding	Summary
Performance Efficiency	x86_64 ดีกว่า	เร็วกว่า 5.5 เท่า, success rate สูงกว่า 120%
Cost Optimization	x86_64 ดีกว่า	ลดต้นทุนต่อคำร้อง ~46% (จาก $1.40 → $0.76 ต่อ 10K requests)
Reliability	x86_64 ดีกว่า	ไม่มี timeout หรือ connection exhaustion ภายใต้โหลดสูง

---

จากการทดสอบด้วยชุดคำสั่งเดียวกัน (42 requests, 3 รอบ) และการตั้งค่าทรัพยากรเท่ากัน (512 MB, timeout 30s, ใช้ RDS shared pool) พบว่า
x86_64 ให้ผลลัพธ์ที่ เร็วกว่า 5.5 เท่า, success rate สูงกว่า 120%, และ ต้นทุนต่อคำร้องต่ำกว่า ~46% เมื่อเทียบกับ ARM64
ขณะที่ ARM64 มีข้อดีด้านการใช้พลังงานที่ต่ำกว่าแต่มีปัญหา cold start และ connection pool exhaustion ภายใต้โหลดสูง

การปรับใช้ x86_64 จึงช่วยเพิ่ม Performance Efficiency และ Reliability ของระบบ พร้อมทั้งลดค่าใช้จ่าย ในขณะที่ ARM64 ยังเหมาะสำหรับงานเบา เช่น background job หรือ batch process ที่ต้องการความยั่งยืนหรือลดการใช้พลังงานที่เกินจำเป็น

สรุป:
x86_64 เหมาะกับ production workload ที่ต้องการความเร็วและเสถียรภาพ
ส่วน ARM64 เหมาะกับระบบที่เน้นลดพลังงานและต้นทุนในระยะยาว

Lambda Cache Optimization Summary

มีการทดสอบระบบ AWS Lambda (x86_64) ที่เพิ่มฟีเจอร์ In-Memory Cache ภายในคอนเทนเนอร์ของ Lambda เพื่อปรับปรุงความเร็วและลดการโหลดฐานข้อมูล โดยใช้ workload จริงกับ 14 endpoints

การทดสอบนี้มุ่งเน้นประเมินผลตาม 3 เสาหลักของ AWS Well-Architected Framework: Performance Efficiency, Cost Optimization, และ Reliability

Pillar	Finding	Summary
Performance Efficiency	ดีกว่าเดิม	ความเร็วเฉลี่ยเพิ่มขึ้น 28% (8.2s → 5.9s), latency ลดลงจาก 588ms → 421ms
Cost Optimization	ดีกว่าเดิม	ลดต้นทุนรวม (Lambda + RDS) ได้ประมาณ 33% และลดการโหลดฐานข้อมูล ~80%
Reliability	ดีกว่าเดิม	ไม่มี error หรือ timeout, success rate 100%

---

จากการเปรียบเทียบระหว่าง Baseline (ไม่มี Cache) และ In-Memory Cache Implementation (Round 1–2) พบว่า

• ในรอบแรก (Cache MISS ทั้งหมด) ยังให้ความเร็วเพิ่มขึ้น 28% เนื่องจากโค้ดและการจัดการหน่วยความจำมีประสิทธิภาพมากขึ้น
• ในรอบที่สอง (Cold Start) ช้าลง 217% เพราะเริ่ม instance ใหม่ที่ cache ว่าง แต่ไม่กระทบต่อ production ที่มี traffic ต่อเนื่อง

ผลการทดสอบสรุป

• Response Time เฉลี่ยลดลง 28% (8.2s → 5.9s)
• Latency เฉลี่ยลดลง 28% (588ms → 421ms)
• Database Load ลดลง ~80%
• Cache Hit Rate ที่คาดใน production: 70–80%
• Cost Reduction โดยรวม: ~33% จากการลดเวลา Lambda และการเชื่อมต่อ RDS

---

สรุปผลกระทบโดยรวม

ประเด็น	ก่อนใช้ Cache	หลังใช้ Cache	ผลลัพธ์
Response Time	8.2s	5.9s	เร็วขึ้น 28%
Average Latency	588ms	421ms	เร็วขึ้น 28%
Database Queries	14 ครั้ง	2–3 ครั้ง	ลดลง ~80%
Cost (ต่อ 10K requests)	$0.60	$0.40	ลดลง ~33%
Test Success Rate	100%	100%	เท่ากัน (3 error เป็น test case ที่ตั้งใจไว้)

---

ข้อสังเกตเพิ่มเติม

• Cache จะถูกรีเซ็ตเมื่อ Lambda instance ใหม่ถูกสร้าง (cold start)
• ใน production ที่มีการใช้งานต่อเนื่อง Lambda จะ warm อยู่ตลอด ทำให้ cache ทำงานเต็มประสิทธิภาพ
• การใช้ cache นี้ไม่เพิ่มต้นทุนเพิ่มเติม เนื่องจากใช้หน่วยความจำของ Lambda เดิม

---

สรุป

การเพิ่ม In-Memory Cache ภายใน Lambda ช่วยให้ระบบทำงานได้เร็วขึ้น 28%, ประหยัดต้นทุนรวมได้ประมาณ 33%, และลดการโหลดของฐานข้อมูลได้ถึง 80% โดยไม่ต้องใช้บริการภายนอกเพิ่มเติม

เหมาะสำหรับระบบที่มีการเข้าถึงข้อมูลซ้ำและมี traffic ต่อเนื่องใน production แต่ไม่เหมาะกับระบบที่มีการเรียกใช้งานเฉพาะครั้ง (unique queries) หรือมี traffic ต่ำ

Load Capacity Evaluation

ในระหว่างการทดสอบระบบพบว่าฟังก์ชันหลักของ ScamReport โดยเฉพาะเส้นทาง /webhook มีความหน่วงเพิ่มขึ้นอย่างมีนัยสำคัญเมื่อมีผู้ใช้งานจำนวนมากเข้าพร้อมกัน เนื่องจากสภาพแวดล้อม Learner Lab จำกัด Lambda Concurrency ไว้เพียง 10 ทำให้ระบบมีความเสี่ยงที่จะเกิดการล่าช้า (Latency เกิน SLO) และอาจเริ่มเกิด Throttling หากมีโหลดเพิ่มขึ้น ทีมจึงดำเนินการทดสอบ Load Capacity Evaluation เพื่อประเมินจำนวนคำขอสูงสุดที่ระบบรองรับได้ก่อนเกิดความไม่เสถียร พร้อมวิเคราะห์ Bottleneck และแนวทางเพิ่ม Reliability ตามมาตรฐาน AWS Well-Architected Framework

จากการเก็บข้อมูลผ่าน CloudWatch Metrics และคำนวณค่า Maximum RPS ต่อฟังก์ชัน พบว่า /webhook มีค่าเฉลี่ย 698 ms และ p95 = 788 ms ทำให้รองรับได้สูงสุดประมาณ 14 RPS ขณะที่ /admin ใช้เวลาเฉลี่ยเพียง 86.7 ms รองรับได้มากกว่า 115 RPS หลังจากหัก Safety Margin 30% ระบบมี เพดานโหลดปลอดภัยที่ ~10 RPS ซึ่งยังคงรักษา p95 latency ต่ำกว่า 1 วินาทีตาม SLO ไม่มี Error และไม่พบ Throttling ในการทดสอบ ส่งผลให้ความสามารถของระบบเพิ่มขึ้นกว่า 40% จากเดิม พร้อมรองรับผู้ใช้งานจำนวนมากขึ้นได้อย่างเสถียร

ข้อดีด้าน Reliability

Reliability: Fault Isolation & Resiliency

• ชี้ชัด Bottleneck ที่ Lambda /webhook และกำหนด Safe Load ช่วยลดความเสี่ยงระบบล่มในช่วงโหลดสูง

• ไม่มี Throttling → ยืนยันว่า concurrency ถูกใช้งานอย่างเหมาะสมในสภาพแวดล้อมจำกัด

• การวางแผนใช้ Provisioned Concurrency และ SQS Decoupling เพิ่มความทนทานเมื่อโหลดเพิ่มขึ้น

Reliability: Monitoring & Observability

• เปิดใช้งาน CloudWatch Detailed Metrics ทำให้ตรวจสอบ latency, error, และ concurrency ได้ละเอียดขึ้น

• ลด Blind Spot และเพิ่มความสามารถในการวินิจฉัยปัญหาแบบ proactive

Result

ระบบ ScamReport มีความเสถียรมากขึ้นตาม Reliability Pillars โดยระบบสามารถรองรับโหลดสูงสุดได้ประมาณ 14 RPS และมีเพดานปลอดภัยที่ 10 RPS โดยยังคงรักษา p95 latency ต่ำกว่า 1 วินาที ไม่มี Error หรือ Throttling เกิดขึ้น ความสามารถรองรับโหลดของระบบเพิ่มขึ้นกว่า 40% และพร้อมรองรับผู้ใช้งานเพิ่มขึ้นในอนาคตโดยไม่กระทบต่อความเสถียรของระบบ.

CORS Hardening Update

ในระหว่างการทดสอบระบบพบว่า API ส่ง CORS headers ซ้ำกันจากทั้ง Lambda Function URL และ Lambda code ทำให้เกิดปัญหา cross-origin access ที่ไม่สอดคล้องกับ security requirement และส่งผลให้บาง request ถูก browser block ทันที ทีมจึงดำเนินการแก้ไขโดยปิด CORS บน Function URL และให้ Lambda เป็น single source ของ CORS policy พร้อมเพิ่มการตรวจสอบ origin ผ่าน environment variable (ALLOWED_ORIGINS) เพื่ออนุญาตเฉพาะ domain ที่ระบบกำหนด เมื่อปรับปรุงแล้ว API สามารถตรวจสอบ origin ได้ถูกต้อง ไม่มี duplicate headers และลดความเสี่ยงด้าน cross-origin attack ทั้งใน development และ production ส่งผลให้ frontend ทุก environment เชื่อมต่อ API ได้อย่างปลอดภัยและเสถียร

ข้อดีด้าน Security Pillar

Identity & Access Control: จำกัด origin ที่อนุญาตผ่าน whitelist ลดความเสี่ยงจาก unauthorized domains

Security at Every Layer: มีจุดกำหนด CORS เดียวใน Lambda → ลด misconfiguration และทำให้ policy คงที่

Protecting Data in Transit: ยกเลิก wildcard และบังคับใช้ origin ที่ถูกต้อง ช่วยลดโอกาสข้อมูลถูก exposed ผ่าน cross-origin

Operational Security: ใช้ environment variable ควบคุม policy ทำให้ update ง่าย ปลอดภัย และ audit ได้ชัดเจน

Result

ระบบ ScamReport API ทำงานได้ปลอดภัยมากขึ้นตาม AWS Security Pillar, ไม่มี CORS ซ้ำซ้อน, Origin ตรวจสอบตาม whitelist, และ frontend ทุก environment สามารถใช้งาน API ได้โดยไม่มี CORS error อีกต่อไป.

AWS Cost Estimation Summary

Monthly Cost (Total: 16.80 USD)

Auto Deployment Pipeline Summary

ในกระบวนการพัฒนาและปรับปรุงระบบ ScamReport ทีมต้องการให้การ deploy frontend เป็นแบบอัตโนมัติ โดยไม่ต้องใช้ CloudShell หรือ deploy ด้วยมือ เพื่อให้การอัปเดตโค้ดทำได้รวดเร็ว มีมาตรฐาน และลดข้อผิดพลาดที่เกิดจาก manual process ทีมได้ทดลองตั้งค่า GitHub Actions และเชื่อมต่อ S3 ผ่าน AWS CLI แต่พบข้อจำกัดจาก AWS Academy Learner Lab เช่น ไม่สามารถสร้าง IAM User, ไม่สามารถเปิดใช้ CloudFront (ต้องใช้ HTTPS), และมีข้อจำกัดเรื่อง permission ทำให้ไม่สามารถสร้าง pipeline ที่ปลอดภัยและสมบูรณ์ได้ ทีมจึงเลือกใช้การ deploy ผ่าน Vercel ชั่วคราวสำหรับ production และใช้ S3 เฉพาะ static content ตามความเหมาะสมของสถาปัตยกรรม

ข้อดีด้าน Operational Excellence

• ลดขั้นตอน manual deploy ที่มีโอกาสทำผิดได้ง่าย
• โค้ดที่ merge ไปที่ main สามารถ deploy อัตโนมัติ → ช่วยให้ทีม release ได้เร็วขึ้น
• Pipeline เดียวกันสามารถตรวจสอบ error, rollback และ review output ได้สะดวกผ่าน GitHub Actions

ข้อดีด้าน Security

• เลี่ยงการใช้ root credentials หรือ IAM User ใน Lab environment
• ลดความเสี่ยงจาก misconfiguration ของ S3 bucket และ permission
• การย้ายมาใช้ Vercel ช่วยให้ได้ HTTPS อัตโนมัติและลดจุดโจมตี (attack surface)

ข้อดีด้าน Reliability

• Deploy ผ่าน platform ที่เสถียร ทำให้ระบบลด downtime และลดโอกาส deploy fail
• การตั้งค่า build และ deploy เหมือนกันทุกครั้ง → ลด config drift ระหว่าง environment
• ตัด dependency จาก CloudShell ซึ่งลบ state ทุกครั้งเมื่อ Lab หมดเวลา

Result

ระบบสามารถ deploy frontend ผ่าน Vercel ได้สำเร็จและทำงานได้จริง พร้อมเชื่อมต่อ API Cognito และ Lambda อย่างถูกต้อง สถาปัตยกรรมมีความเสถียรขึ้น ลดงาน manual และปรับให้อยู่ใน best practice ตาม AWS Well-Architected Framework โดยเฉพาะ ด้าน Security, Operational Excellence และ Reliability

Monitoring , Automation and Incident Response

ในการพัฒนาระบบ ScamReport เราต้องการให้ระบบของเราเป็นไปตาม Well Architecture Pillar : Operational Excellence โดยเราได้ทำการ Monitoring & Observation ซึ่งเราได้สร้าง CloudWatch Alarm และเลือก metric หรือ service ต่างๆที่เราใช้เพื่อติดตามการทำงานและ set ค่า threshold เพื่อเป็นค่าที่เอาไว้เช็คการทำงานของ service นั้นๆว่าทำงานปกติหรือไม่ และ set period time ตามความเหมาะสมของ service นั้นๆ ซึ่งโดยเฉลี่ยจะ set ไว้ประมาณ 5 นาทีของทุก service ซึ่งเราได้ set ไว้เฉพาะกับ service/metric ที่จำเป็นเพราะ credit ของ AWS learner lab มีจำกัดและกระบวนการนี้ได้ทำการบันทึกการทำงานของ service นั้นๆ และต่อมาเราได้ทำขั้นตอน Incident Response โดยการสร้าง AWS SNS เพื่อให้สามารถแจ้งเตือนไปทางอีเมลของเราได้ ซึ่งเราใช้ AWS CloudWatch กับ AWS SNS เพื่อให้ระบบสามารถแจ้งเตือนไปยังอีเมลของเราได้เมื่อ service ทำงานผิดปกติ และเราได้สร้าง AWS CloudTrail เพื่อสามารถดู log การกระทำของระบบทั้งหมดได้ และส่วนของ Automation เราไม่สามารถทำได้เนื่องจาก user(voclab) ของ learner lab ไม่มีสิทธิ์ในการสร้าง role ใหม่ขึ้น และ Labrole ไม่สามารถ attach policy ที่สร้างขึ้นใหม่กับ lambda ได้ จึงไม่สามารถทำ automation ได้ และผมลองอีกวิธีก็คือใช้ AWS SNS ก็ไม่สามารถ add action system manager เพื่อทำ automation ได้เพราะ AWS learner lab ไม่มีสิทธิ์

ข้อดีด้าน Operational Excellence

• ระบบมีการ Monitoring และบันทึกการทำงานของ service ที่เรา set ไว้
• ระบบมีการ Incident Response โดยแจ้งเตือนเข้า Email เมื่อ service ทำงานผิดปกติ
• มีการ Observation และบันทึก log หรือการกระทำที่เกิดขึ้นใน AWS Account ของเรา

Result

ระบบของเราเป็นไปตาม Well architecture : Pillar Operational Excellence ยกเว้นการทำ automation ที่ติดไม่มีสิทธิ์ในการ attach policy กับ lambda และการ create new role

Daily Backup Plan Implementation (AWS Backup Update)

จากการตรวจสอบระบบพบว่า ScamReport ยังใช้เพียง automated backup ของ RDS ที่มาพร้อมระบบ โดยไม่มี centralized backup policy ทำให้ไม่สามารถควบคุม schedule, retention และ resource coverage ได้อย่างสม่ำเสมอ ทีมจึงเริ่มปรับปรุง reliability โดยนำ AWS Backup มาใช้เป็นศูนย์กลางการสำรองข้อมูล และสร้าง Backup Plan เพื่อสำรองข้อมูลทุกส่วนของระบบ ในครั้งนี้ ทีมได้สร้าง my-daily-backup-plan พร้อม backup rule ชื่อ DailyBackups ที่รันทุกวันเวลา 05:00 (UTC+07:00) และผูก resource assignment (my-daily-rds-backup) ให้ครอบคลุมทั้ง RDS (scamreport-db), DynamoDB table (scamreport-line-sessions) และ S3 bucket (scamreport-bucket-cs361) ผ่าน IAM Role (LabRole) จากนั้นระบบได้รัน backup อัตโนมัติหลายรอบ ซึ่งทั้งหมดมีสถานะ Completed ยืนยันว่าการสำรองข้อมูลทำงานสมบูรณ์ต่อเนื่องทุกวัน การปรับปรุงนี้ทำให้ระบบ ScamReport มีมาตรฐานด้านการสำรองข้อมูลชัดเจนขึ้น สามารถตรวจสอบย้อนหลังได้ และลดความเสี่ยงจากข้อมูลสูญหายหรือเหตุการณ์ผิดพลาดใน production โดยไม่ต้องพึ่ง manual operation หรือ rely solely on RDS automated backups อีกต่อไป

ข้อดีด้าน Reliability Pillar

Foundations (Backup Governance):

Backup Plan + Resource Assignment รวมศูนย์ในที่เดียว สามารถ audit, track และตรวจสอบสถานะได้ง่ายขึ้น ลดความผิดพลาดจากการตั้งค่าแบบกระจัดกระจาย

Backup & Restore:

มี backup job สำเร็จจริงต่อเนื่อง (Completed) สำหรับ RDS, DynamoDB และ S3 ทำให้มั่นใจว่าข้อมูลสำคัญถูกสำรองครบทุกส่วนของระบบ

Fault Isolation:

สำรองข้อมูลไปยัง Backup Vault ทำให้ data snapshot แยกตัวจาก production ช่วยป้องกันผลกระทบจากความผิดพลาดของระบบหลัก

Operational Excellence:

Schedule รายวันเวลา 05:00 (UTC+07:00) ทำให้เกิด workflow ที่เสถียรต่อเนื่อง ไม่พลาดวันใดวันหนึ่ง และลด manual workload ของทีม Dev/Infra

Result

ระบบ ScamReport มี daily centralized backup ทำงานครบทุกส่วนของ infrastructure (RDS + DynamoDB + S3) ภายใต้แผน my-daily-backup-plan โดย backup jobs ในช่วงวันที่ 13–16 พฤศจิกายน 2025 ทั้งหมดอยู่ในสถานะ Completed ทำให้ระบบมีความปลอดภัยด้านข้อมูลสูงขึ้น รองรับ Disaster Recovery ได้จริง และมีเสถียรภาพตามแนวทาง AWS Reliability Pillar แบบเต็มรูปแบบ

AI Summarizer (Gemini) — PDPA Compliance Summary

จากการพัฒนาระบบพบว่าฟีเจอร์ AI Summarizer (Gemini) ต้องประมวลผลข้อความของผู้ใช้ ซึ่งอาจมีข้อมูลส่วนบุคคลหรือข้อมูลอ่อนไหว ทีมจึงออกแบบระบบให้สอดคล้อง PDPA พร้อมทั้งช่วยลดเวลาการทำงานของเจ้าหน้าที่ ระบบสามารถสรุปข้อความร้องเรียนที่ยาวมากให้เหลือเพียงสรุปสั้น ๆ พร้อมประเด็นสำคัญ ทำให้เจ้าหน้าที่เข้าใจเคสได้เร็วขึ้นและทำงานได้มีประสิทธิภาพมากขึ้น

PDPA Compliance Implementation

1. Consent & Purpose Limitation

• แจ้งผู้ใช้ชัดเจนว่า “ข้อมูลจะถูกส่งไปยังบริการ Gemini เพื่อสร้างสรุปโดย AI”
• ผู้ใช้ต้องกดยอมรับก่อนส่งข้อมูลไปยัง 3rd party AI

2. Data Minimization

• ส่งเฉพาะข้อความที่จำเป็นต่อการสรุป
• ทำ Data Redaction ก่อนส่ง เช่น เบอร์โทร, เลขบัญชี, ชื่อจริง → แทนที่ด้วย Placeholder ([PHONE], [ID])

3. No Data Training Guarantee

• Default Gemini Free Tier ไม่ใช้ข้อมูลผู้ใช้ไปเทรนโมเดล
• สอดคล้อง PDPA ในส่วนของ Data Processing

4. Data Retention

• Lambda ไม่เก็บข้อความดิบ (raw text)
• API บันทึกเฉพาะ summary ที่จำเป็นต่อเจ้าหน้าที่

5. Security of Data in Transit

• ข้อมูลส่งผ่าน HTTPS/TLS 1.2+
• API Key เก็บใน Lambda Environment Variables เท่านั้น

ข้อดีด้าน Security Pillar

1. Data Protection & Privacy

• ข้อมูล PII ถูก Anonymize ก่อนส่งไปประมวลผล
• ลดความเสี่ยงข้อมูลรั่วไหลและปฏิบัติตาม PDPA

2. Secrets Management

• API Key ไม่ถูก Hard-code
• เก็บใน Lambda Environment Variables อย่างปลอดภัย

3. Access Control

• ตรวจสอบ Input Validation ก่อนประมวลผล
• ลดความเสี่ยงจากการโจมตีขั้นพื้นฐาน เช่น Injection

4. Data in Transit Security

• ส่งข้อมูลผ่าน HTTPS/TLS ป้องกันการดักจับหรือแก้ไขข้อมูล

5. Data Retention & Logging

• ไม่เก็บ raw text บันทึกเฉพาะ summary
• ลดความเสี่ยงข้อมูลรั่วไหลจาก Log

6. Compliance & Auditability

• ระบบสามารถตรวจสอบย้อนกลับได้
• สอดคล้อง PDPA และอธิบายขั้นตอนการปกป้องข้อมูลได้ชัดเจน

Result

• ฟีเจอร์ AI Summarizer ทำงานสำเร็จและสร้างสรุปข้อความจริง
• ข้อมูลส่วนบุคคลถูกปกปิด ไม่ละเมิด PDPA
• เจ้าหน้าที่เข้าใจเคสเร็วขึ้น ลดเวลาการทำงาน
• ระบบปลอดภัยและตรวจสอบได้เต็มตามมาตรฐาน Data Protection

)

Sustainability Pillars

ระบบ ScamReport ถูกออกแบบตามแนวทาง AWS Well-Architected Framework – Sustainability Pillar โดยมุ่งลดการใช้ทรัพยากรเกินจำเป็น และเพิ่มประสิทธิภาพด้านพลังงานในทุกชั้นของสถาปัตยกรรม

01 ใช้สถาปัตยกรรม Serverless ลดพลังงานส่วนเกิน

เลือกใช้ AWS Lambda, S3 Static Hosting, Cognito ทำให้ระบบไม่มีเครื่องว่าง (Zero Idle Compute) ใช้พลังงานเท่าที่มีการใช้งานจริง → ลด Carbon Footprint ได้อย่างมีประสิทธิภาพ

02 ทดสอบเทียบ ARM (Graviton) กับ x86 เพื่อหาโซลูชันที่ “คุ้มพลังงานที่สุด”

มีการ POC เปรียบเทียบ ARM64 (Graviton2) กับ x86_64 เพื่อเลือกสถาปัตยกรรมที่ให้ประสิทธิภาพคุ้มค่าต่อ workload แม้ผลสรุปจะพบว่า x86 มีความคุ้มค่ากว่าในเคสนี้, แต่กระบวนการเลือกยังคงอิงหลักการประหยัดพลังงานตาม Sustainability Pillar

03 ใช้ In-Memory Cache ลดการเรียกฐานข้อมูลลง 80%

ใช้ In-memory cache บน Lambda ลดงานประมวลผลซ้ำซ้อน ลดการ query ฐานข้อมูลกว่า 80% → ลดพลังงานของ Lambda และ RDS/DynamoDB ในภาพรวม

04 ใช้ Automatic Backup + S3 Lifecycle ลด Storage Footprint

เปิดใช้งาน:

• Automated Backup (RDS, DynamoDB, S3)

• S3 Lifecycle Rules เพื่อลดข้อมูลที่เก็บเกินจำเป็น

ช่วยลดพื้นที่จัดเก็บและลดพลังงานที่ใช้ใน Storage Layer

05 ระบบ Auto-Scale ตามโหลดจริง (Zero Idle Resources)

สถาปัตยกรรมทั้งหมดรองรับ Auto-Scaling แบบอัตโนมัติ เช่น Lambda, DynamoDB On-Demand และ S3 ทำให้ระบบ:

• ใช้พลังงานตามโหลดจริง

• ไม่เกิด resource ว่างที่เสียพลังงานโดยเปล่าประโยชน์

• รองรับ Traffic พุ่งขึ้นโดยไม่ Over-Provision

เป็นไปตามหลัก Green Architecture

Cost Optimization Summary

ในการปรับปรุงระบบ ScamReport ทีมได้ทดสอบสถาปัตยกรรม Lambda ระหว่าง x86 และ ARM เพื่อหาตัวเลือกที่ให้ประสิทธิภาพและต้นทุนเหมาะสมที่สุด โดยพบว่า x86 ให้ความเร็วที่ดีกว่าและตอบโจทย์ workload ของระบบมากกว่า จึงตัดสินใจปรับ Lambda ทั้งหมดมาใช้สถาปัตยกรรม x86_64 แทน ARM

นอกจากนี้ ทีมเลือก ไม่เปิด Auto Scaling หรือ Provisioned Concurrency เนื่องจากปริมาณผู้ใช้ยังน้อยและไม่คุ้มค่าต้นทุน การเปิดฟีเจอร์ดังกล่าวจะทำให้มีค่าใช้จ่ายคงที่ตลอดเวลา แม้ไม่มีผู้ใช้งานจริง จึงปรับระบบให้ scaling แบบตามฤทธิ์ (on-demand) ที่ Lambda จัดการให้อยู่แล้ว

บริการอื่น ๆ เช่น API Gateway, S3 และ CloudWatch ถูกตั้งค่าตามปริมาณใช้งานจริง ไม่มีการเปิดฟีเจอร์ที่ไม่จำเป็น ทำให้ต้นทุนรวมของระบบอยู่ที่ประมาณ 16–18 USD ต่อเดือน เหมาะสมกับสเกลของโปรเจกต์และสภาพแวดล้อมของ AWS Learner Lab

ข้อดีด้าน Cost Optimization

ลดต้นทุน Lambda โดยเลือกสถาปัตยกรรมที่เหมาะสมกับงานจริง

ลด DB Load ผ่าน In-Memory Cache ทำให้ใช้ RDS อย่างคุ้มค่าที่สุด

ตัดฟีเจอร์ที่ไม่จำเป็น เช่น Auto Scaling / Provisioned Concurrency

ใช้เฉพาะทรัพยากรที่จำเป็นจริง ทำให้ต้นทุนรวมต่ำและควบคุมง่าย

Result

ระบบทำงานได้เร็วขึ้นอย่างเห็นได้ชัด ลดภาระ RDS และยังคงต้นทุนรายเดือนอยู่ในระดับต่ำ เหมาะกับสภาพแวดล้อมการเรียนรู้และการใช้งานจริงตามแนวทาง AWS Well-Architected Fram