AWS Fundamentals: CLI, SDK & IAM

AWS SDK (Software Development Kit) คือชุดเครื่องมือสำหรับเรียก AWS API จากภายในโค้ดแอปพลิเคชันแบบ programmatic แทนการคลิกใน Console หรือพิมพ์คำสั่ง CLI ทำให้แอปสามารถสร้าง, อ่าน, จัดการ resource บน AWS ได้โดยตรง

• มีให้ใช้หลายภาษา: Java, Python (boto3), JavaScript/Node.js, .NET, Go, Ruby, PHP, C++
• ต้องระบุ default region เสมอ (ถ้าไม่ระบุบางภาษาจะ default เป็น us-east-1)
• ต้องจัดการ credentials เพื่อให้ SDK รู้ว่าใครเป็นผู้เรียก (มักผ่าน credentials provider chain)
• AWS CLI สร้างขึ้นบน AWS SDK for Python (boto3) - นี่คือเกร็ดที่ออกสอบได้

EC2 Instance Metadata Service (IMDS) ให้ EC2 instance เรียกดูข้อมูลของตัวเองได้โดยไม่ต้องใช้ IAM permission ใดๆ เข้าถึงผ่าน URL พิเศษ (link-local address) ที่ http://169.254.169.254/latest/meta-data ซึ่งเข้าถึงได้จากภายใน instance เท่านั้น เข้าจากภายนอกไม่ได้

• /latest/meta-data/ - ข้อมูล instance เช่น instance-id, hostname, AMI id, security groups
• /latest/user-data - ข้อมูล user data ที่ใส่ตอน launch (เช่น bootstrap script)
• /latest/meta-data/iam/security-credentials/<role-name> - ดึง IAM Role credentials
• สิ่งที่สำคัญที่สุดสำหรับ developer: ดึง IAM role credentials ได้โดยไม่ต้องใส่ access key ในโค้ดเลย

# IMDSv1 - เรียกตรงๆ (legacy)
curl http://169.254.169.254/latest/meta-data/

# ดึงชื่อ role ที่ attach อยู่
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# ดึง temporary credentials ของ role นั้น (คืนค่าเป็น JSON: AccessKeyId, SecretAccessKey, Token)
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/MyEC2Role

AWS แนะนำให้ใช้ IMDSv2 ซึ่งปลอดภัยกว่าด้วยการเป็น token-based ต้องขอ session token ก่อนแล้วจึงนำไปใช้ใน request เพื่อป้องกันการโจมตีแบบ SSRF (Server-Side Request Forgery)

# IMDSv2 - Step 1: ขอ token (PUT) พร้อมกำหนด TTL
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

# IMDSv2 - Step 2: ใช้ token ใน GET request ทุกครั้ง
curl http://169.254.169.254/latest/meta-data/profile \
  -H "X-aws-ec2-metadata-token: $TOKEN"

Named Profiles ช่วยให้จัดการหลายชุด credentials/หลายบัญชีบนเครื่องเดียวได้ โดยเก็บใน 2 ไฟล์: ~/.aws/credentials (เก็บ access key) และ ~/.aws/config (เก็บ region/output) แล้วเลือกใช้ผ่าน flag --profile

# ~/.aws/credentials
[default]
aws_access_key_id = AKIA_DEFAULT_XXXX
aws_secret_access_key = wJalrXUtnXXXX

[prod-account]
aws_access_key_id = AKIA_PROD_XXXX
aws_secret_access_key = abc123XXXX

# ~/.aws/config
[default]
region = us-east-1
output = json

# หมายเหตุ: profile ที่ไม่ใช่ default ต้องขึ้นต้นด้วยคำว่า profile
[profile prod-account]
region = ap-southeast-1
output = json

# ใช้ profile เฉพาะ
aws s3 ls --profile prod-account

# ตั้งค่า profile ใหม่แบบ interactive
aws configure --profile prod-account

เมื่อ policy บังคับ MFA สำหรับการเรียก API ต้องขอ temporary credentials ที่ผ่าน MFA ก่อน โดยใช้คำสั่ง aws sts get-session-token พร้อมระบุ MFA device และ token code

aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/my-user \
  --token-code 123456 \
  --duration-seconds 3600

# ผลลัพธ์ที่ได้ (นำไปตั้งเป็น temporary credentials):
# {
#   "Credentials": {
#     "AccessKeyId": "ASIA...",
#     "SecretAccessKey": "...",
#     "SessionToken": "...",      <-- ต้องใช้ SessionToken ด้วย
#     "Expiration": "2026-06-09T..."
#   }
# }

• --serial-number = ARN ของ MFA device (หรือ serial number สำหรับ hardware token)
• --token-code = รหัส 6 หลักจากแอป MFA (เช่น Google Authenticator)
• ผลลัพธ์มี SessionToken ที่ต้องใส่ด้วยเสมอเมื่อใช้ temporary credentials
• temporary credentials เริ่มต้นด้วย ASIA (ต่างจาก long-term key ที่ขึ้นต้น AKIA)

เมื่อ SDK/CLI ต้องการ credentials มันจะค้นหาตาม ลำดับ (chain) ที่กำหนดไว้ และใช้ชุดแรกที่เจอ การเข้าใจลำดับนี้สำคัญมากเพราะเป็นกับดักข้อสอบยอดนิยม

• 1. Command line options (เช่น --region, --profile) [สำหรับ CLI]
• 2. Environment variables - AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN
• 3. CLI credentials/config file - ~/.aws/credentials และ ~/.aws/config
• 4. Container credentials - สำหรับ ECS tasks (task role)
• 5. EC2 Instance Profile credentials - ผ่าน IMDS (ลำดับสุดท้าย)

เมื่อ API call ล้มเหลวด้วย throttling (เช่น ProvisionedThroughputExceededException, ThrottlingException) หรือ 5xx Server Error ควร retry ด้วย Exponential Backoff คือเพิ่มเวลา wait แบบทวีคูณ ในแต่ละครั้งที่ retry (เช่น 1s, 2s, 4s, 8s...) พร้อมเพิ่ม jitter (ค่า random) เพื่อกระจาย load

• SDK ทำ exponential backoff ให้อัตโนมัติ สำหรับ throttling และ 5xx (built-in retry) ปรับ max attempts ได้
• ถ้าเรียก API โดยตรง (ไม่ผ่าน SDK) ต้อง implement backoff + jitter เอง
• 4xx client errors ทั่วไปไม่ควร retry เพราะ retry ไปก็ผิดเหมือนเดิม (ยกเว้น throttling)
• jitter ช่วยกัน thundering herd (client หลายตัว retry พร้อมกัน)
• ถ้าชน limit จริงต่อเนื่อง -> ขอ Service Limit Increase ผ่าน Service Quotas console/API

AWS Signature v4 (SigV4) คือกระบวนการ ลงนาม (sign) HTTP request ด้วย AWS credentials ทุกครั้งที่เรียก AWS API จุดประสงค์คือพิสูจน์ ตัวตน (authentication) ของผู้เรียก และยืนยันว่า request ไม่ถูกแก้ไขระหว่างทาง (integrity)

• ทำไมต้อง sign: เพื่อให้ AWS รู้ว่าใครเป็นคนเรียกและป้องกันการปลอมแปลง request
• ใช้ AWS CLI หรือ SDK -> SigV4 signing ทำให้อัตโนมัติ (transparent) ไม่ต้อง sign เอง
• ส่ง signature ได้ 2 ทาง: ผ่าน Authorization HTTP header หรือผ่าน query string (เช่น X-Amz-Signature ใน S3 pre-signed URL)
• จำเป็นต้อง sign เองเฉพาะกรณีเรียก API ด้วย raw HTTP (เช่น curl, Postman) โดยไม่ผ่าน SDK/CLI

# ตัวอย่าง SigV4 ผ่าน Authorization header
Authorization: AWS4-HMAC-SHA256
  Credential=AKIAIOSFODNN7EXAMPLE/20260609/us-east-1/s3/aws4_request,
  SignedHeaders=host;range;x-amz-date,
  Signature=fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024

# หรือผ่าน query string (S3 pre-signed URL)
# https://bucket.s3.amazonaws.com/key?X-Amz-Algorithm=AWS4-HMAC-SHA256
#   &X-Amz-Credential=...&X-Amz-Signature=...