Amazon API Gateway

Amazon API Gateway เป็น fully managed service ที่ให้เราสร้าง publish maintain monitor และ secure APIs ได้ในระดับ scale ใหญ่ ทำหน้าที่เป็น front door เข้าสู่ backend เช่น Lambda, HTTP endpoints (EC2/ALB/ภายนอก) หรือ AWS service อื่น ๆ จุดเด่นคือ serverless ไม่ต้องดูแล infrastructure, รองรับ versioning/stages, authentication, throttling, caching, API keys และ generate SDK/API specs ได้

ขนาด payload สูงสุด ที่ API Gateway รับได้คือ 10 MB และ integration timeout สูงสุดคือ 29 วินาที (เป็นเลขที่ออกสอบบ่อยมาก)

3 ประเภทของ API

API Gateway มี endpoint type 3 แบบ ซึ่งกำหนดว่า request จะเข้าถึง API จากที่ไหนและผ่าน infrastructure อะไร

Integration คือวิธีที่ API Gateway ส่งต่อ request ไปยัง backend และรับ response กลับมา มี integration types หลายแบบ ต่างกันที่ระดับการ transform ข้อมูล

การเปลี่ยนแปลงใน API Gateway จะไม่มีผลจนกว่าจะ deploy ไปยัง stage หนึ่ง ๆ (เช่น dev, test, prod). แต่ละ stage มี invoke URL ของตัวเอง และเก็บ history ของ deployment ทำให้ rollback ได้ง่ายโดยเปลี่ยน deployment ที่ stage ชี้ไป

Stage Variables

Stage variables เปรียบเหมือน environment variables ของ API Gateway ใช้เปลี่ยนค่าตาม stage โดยไม่ต้องแก้โค้ด เช่นชี้ไป Lambda alias หรือ HTTP endpoint คนละตัวตาม stage. Use case คลาสสิก: ใช้ stage variable ชี้ Lambda alias ที่ตรงกับ stage (เช่น ${stageVariables.lambdaAlias}) เพื่อให้ prod เรียก prod alias, dev เรียก dev alias

// ใช้ stage variable ใน Lambda integration ARN
arn:aws:lambda:us-east-1:123456789012:function:myFunction:${stageVariables.lambdaAlias}

// ใช้ใน HTTP integration URL
http://${stageVariables.url}/resource

Canary Deployments

Canary deployment ทำได้ที่ระดับ stage โดยกำหนด % ของ traffic ให้ไปยัง canary (version ใหม่) ที่เหลือไปยัง production version เดิม เหมาะกับการทดสอบ release ใหม่กับ traffic ส่วนน้อยก่อน promote เต็ม. metrics และ logs ของ canary แยกได้ และมี stage variables เฉพาะของ canary ได้

Mapping templates เขียนด้วยภาษา VTL (Velocity Template Language) ใช้แปลง/reshape ข้อมูลระหว่าง client และ backend ใช้ได้กับ non-proxy integration เท่านั้น (proxy ส่งทุกอย่างตามเดิม). ใช้ได้ทั้ง request (แปลงก่อนเข้า backend) และ response (แปลงก่อนคืน client)

• เปลี่ยน JSON เป็น XML (SOAP) หรือกลับกัน
• เปลี่ยนชื่อ field / renaming keys
• filter ข้อมูลบาง field ออก
• ดึงค่าจาก query string / path / headers มาประกอบเป็น body
• เปลี่ยน Content-Type ของ response
• map request ให้กลายเป็น AWS service action (เช่น SQS SendMessage)

การจะให้ mapping template ทำงาน ต้องตั้งค่า Content-Type (เช่น application/json) ใน Integration Request และ Integration Response ให้ตรง

## ตัวอย่าง VTL mapping template ดึงค่ามาประกอบ
#set($inputRoot = $input.path('$'))
{
  "orderId": "$input.params('orderId')",
  "customer": "$inputRoot.name",
  "region": "$context.identity.sourceIp"
}

API Gateway caching ช่วยลดจำนวน request ที่ส่งไป backend ทำให้ลด latency และ load. cache เป็นการเก็บ response ของ endpoint ไว้

• Cache ตั้งค่าที่ระดับ stage (และ override per-method ได้)
• Default TTL = 300 วินาที, ตั้งได้ตั้งแต่ 0 ถึง 3600 วินาที (0 = ปิด cache)
• ขนาด cache ตั้งแต่ 0.5 GB ถึง 237 GB
• Cache มี ค่าใช้จ่าย จึงแนะนำให้เปิดเฉพาะ production
• Cache key default มาจาก request parameters; กำหนด cache key parameters ได้

Cache Invalidation

client สามารถ invalidate (flush) cache ได้โดยส่ง header `Cache-Control: max-age=0` แต่ต้องมี IAM authorization ที่อนุญาต action InvalidateCache มิฉะนั้นใคร ๆ ก็ flush cache ได้. สามารถ flush cache ทั้ง stage ได้จาก console เช่นกัน

API Gateway มี throttling หลายระดับเพื่อป้องกัน backend จาก traffic ที่มากเกิน และใช้ usage plans + API keys เพื่อ monetize/จำกัดการใช้งานต่อ customer

Account-level & Stage/Method Throttling

• Account-level limit (soft, default ~10,000 RPS) ต่อ region — ขอเพิ่มได้
• Burst limit default ~5,000 requests (ใช้ token bucket)
• ตั้ง throttling per stage หรือ per method ได้
• ถ้าเกิน limit จะได้ 429 Too Many Requests (client ควร retry แบบ exponential backoff)
• หนึ่ง API ที่ throttle หนักอาจทำให้ทั้ง account ถูกกระทบ — ใช้ stage/method limit เพื่อป้องกัน

Usage Plans & API Keys

Usage plan กำหนด throttle (rate/burst) และ quota (จำนวน request ต่อ วัน/สัปดาห์/เดือน) ให้กับ API keys. API key เป็น string ที่ client ส่งผ่าน header `x-api-key` เพื่อระบุตัวตน customer แล้วผูกกับ usage plan. เหมาะกับการขาย API ให้ลูกค้าหลายราย โดยจำกัดโควต้าต่างกัน

API Gateway รองรับการ authorize/authenticate request หลายแบบ ออกสอบบ่อยมากเรื่อง 'เลือก authorizer ตาม use case'

CORS (Cross-Origin Resource Sharing)

CORS ต้องเปิดเมื่อ browser เรียก API จาก domain ต่างจาก API. browser จะส่ง preflight request (OPTIONS) ก่อน แล้วคาดหวัง header `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods`, `Access-Control-Allow-Headers` กลับมา. ใน API Gateway สามารถ enable CORS ได้จาก console (สร้าง OPTIONS method ให้อัตโนมัติ)

Request Validation

REST API ทำ request validation ได้ที่ระดับ API Gateway ก่อนส่งไป backend ตรวจได้ว่า required query string params / headers มีครบ และ request body ตรงตาม JSON Schema (request model) ที่กำหนด ช่วยลดการ invoke Lambda ที่ไม่จำเป็น (ลด cost) และคืน error เร็วขึ้น

Gateway Responses

Gateway Responses ใช้ปรับแต่ง response ที่ API Gateway สร้างเองเมื่อเกิด error ก่อนถึง backend (เช่น 4XX/5XX, ACCESS_DENIED, UNAUTHORIZED, THROTTLED, missing authentication, DEFAULT_4XX). สามารถ override status code, body, และเพิ่ม header (เช่น CORS headers ในกรณี error) ได้ เพื่อให้ client ได้ response ที่สม่ำเสมอ

API Gateway รองรับ import/export OpenAPI (Swagger) spec ได้ ทำให้ define API จากไฟล์ spec เดียว และ generate SDK ให้ client ภาษาต่าง ๆ ได้ (JavaScript, iOS, Android เป็นต้น). ยัง export เป็น OpenAPI 3 ได้เพื่อ documentation

Monitoring & Logging

• CloudWatch Logs: เปิด execution logging และ access logging ต่อ stage ได้ (ปรับ log level ERROR/INFO)
• CloudWatch Metrics: ดู CacheHitCount/CacheMissCount, Count, Latency, IntegrationLatency, 4XXError, 5XXError
• X-Ray: เปิด tracing เพื่อดู end-to-end request และ debug latency ได้
• 429 Too Many Requests = ถูก throttle; 504 มักมาจาก integration timeout เกิน 29s