IAM Roles สำหรับ Service-to-Service
ทำไมไม่ควรฝัง access key ในเครื่อง และใช้ role แทน
การฝัง Access key ไว้ในโค้ดหรือบนเซิร์ฟเวอร์ เหมือนเขียนรหัสตู้เซฟแปะไว้หลังประตู — ใครเห็นก็เอาไปใช้ได้ ส่วน Role เหมือนให้ รปภ. ออกบัตรชั่วคราวให้เฉพาะตอนต้องใช้ แล้วบัตรจะหมดอายุไปเอง
เวลาที่บริการหนึ่งต้องคุยกับอีกบริการ (เช่น EC2 ต้องการอ่านไฟล์จาก S3) กฎเหล็กคืออย่าฝัง Access key ลงในเครื่อง ให้ใช้วิธีแนบ IAM Role (บทบาทจำลอง) กับบริการนั้นแทน AWS จะจ่าย Credential ชั่วคราวที่หมุนเปลี่ยนเองอัตโนมัติ ปลอดภัยกว่ามาก
ให้ "บริการ" สวม role แทนการฝังรหัสลับ
❌ ฝัง access key ในโค้ด
✅ ใช้ IAM Role
role ให้ credential ชั่วคราวที่หมุนเองอัตโนมัติ ไม่มีรหัสลับค้างในเครื่อง
- EC2 ใช้ Instance Profile เพื่อสวม Role
- Lambda มี Execution Role ของตัวเอง
- การให้สิทธิ์ผู้ใช้ข้ามบัญชี (Cross-account) ก็ใช้วิธี Assume Role เช่นกัน
สรุป Key Takeaways
- อย่าฝัง access key — ใช้ IAM Role ให้บริการสวมเพื่อรับ credential ชั่วคราว
- EC2 ใช้ instance profile, Lambda ใช้ execution role
- role ปลอดภัยกว่าเพราะ credential หมุนเปลี่ยนเองและไม่ค้างในเครื่อง
คำถามที่พบบ่อย
ทำไม EC2 ควรใช้ role แทน access key
Access key ที่ฝังในเครื่อง/โค้ดคือความลับถาวรที่หลุดได้และหมุนยาก ส่วน role ให้ credential ชั่วคราวที่หมุนเวียนเองอัตโนมัติผ่าน instance profile — ทุกโจทย์ "แอปบน EC2/Lambda/ECS เข้าถึงบริการ AWS อย่างปลอดภัยที่สุด" คำตอบคือ IAM Role เสมอ
Trust policy กับ permission policy ของ role ต่างกันยังไง
Role มี policy สองด้าน: trust policy บอกว่า "ใครสวม role นี้ได้" (เช่น ec2.amazonaws.com หรือบัญชีอื่น) ส่วน permission policy บอกว่า "สวมแล้วทำอะไรได้" — role ที่สวมไม่ได้ทั้งที่สิทธิ์ถูกมักพังที่ trust policy
ลองทำ Quiz ท้ายบท
คำถามแนวข้อสอบของโมดูลนี้ 5 ข้อ · เฉลยทันที