แนวคิดเรื่องคลาวด์และการแบ่งความรับผิดชอบ

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

Pay-as-you-go (จ่ายตามการใช้งานจริง) เป็นหลักการที่ไม่มีการจ่ายล่วงหน้าและไม่มีข้อผูกมัดระยะยาว โดยจ่ายเฉพาะส่วนที่ใช้จริงเท่านั้น เนื่องจากสามารถขยายหรือลดขนาดตามความต้องการจริงแทนที่จะเป็นการคาดการณ์ล่วงหน้า จึงช่วยลดความเสี่ยงจากการจัดสรรทรัพยากรเกินความจำเป็น การลดราคาต่อหน่วยเพื่อแลกกับการผูกมัดปริมาณการใช้งานในระยะเวลาที่กำหนดคือ Save when you commit (ประหยัดเมื่อผูกมัด) ส่วนราคาต่อหน่วยที่ลดลงเมื่อใช้มากขึ้นคือ Pay less by using more (ใช้มากจ่ายน้อยลง) และการรวมเป็นค่าบริการรายเดือนคงที่โดยไม่มีค่าใช้จ่ายส่วนเกินคือ Flat rate (อัตราคงที่) ซึ่งทั้งหมดนี้เป็นหลักการอื่นที่แตกต่างกัน

ใช้มากจ่ายน้อยลง (Pay less by using more) เป็นหลักการที่ใช้ระบบราคาแบบขั้นบันไดกับบริการอย่าง S3 หรือการส่งข้อมูล โดยราคาต่อ GB จะลดลงเมื่อปริมาณการใช้งานเพิ่มขึ้น การลดราคาต่อหน่วยเพื่อแลกกับการผูกมัดปริมาณการใช้งานในระยะเวลาที่กำหนดคือ Save when you commit (ประหยัดเมื่อผูกมัด) ซึ่ง Savings Plans ตรงกับหลักการนี้ ส่วนการจ่ายเฉพาะส่วนที่ใช้จริงในแต่ละครั้งคือ Pay-as-you-go (จ่ายตามการใช้งานจริง) และการรวมเป็นค่าบริการรายเดือนคงที่โดยไม่มีค่าใช้จ่ายส่วนเกินคือ Flat rate (อัตราคงที่) หลักการทั้ง 4 ข้อมีจุดประสงค์ต่างกัน จึงไม่ได้ขัดแย้งกันแต่ใช้ร่วมกันได้

ประหยัดเมื่อผูกมัด (Save when you commit) เป็นหลักการที่ผูกมัดระดับการใช้งานที่กำหนดไว้เป็นระยะเวลา 1 ปีหรือ 3 ปี เช่น Savings Plans เพื่อแลกกับส่วนลดค่าบริการของคอมพิวติ้งหรือแมชชีนเลิร์นนิง การกำหนดค่าบริการรายเดือนคงที่โดยไม่ให้เกิดค่าใช้จ่ายส่วนเกินคือ Flat rate (อัตราคงที่) ซึ่งไม่ใช่กลไกการยกยอด ส่วนระบบราคาแบบขั้นบันไดที่ราคาต่อหน่วยลดลงเมื่อใช้งานมากขึ้นคือใช้มากจ่ายน้อยลง (Pay less by using more) การไม่มีข้อผูกมัดและสามารถเลิกใช้ได้ทุกเมื่อเป็นคุณสมบัติของ Pay-as-you-go (จ่ายตามการใช้งานจริง) ซึ่งมีสมมติฐานตรงข้ามกับหลักการนี้ที่ตั้งอยู่บนการผูกมัด

จากรายการ Exam Guide อย่างเป็นทางการ ณ เดือนสิงหาคม 2026 การรับรองที่จัดอยู่ในระดับ Foundational มี 2 รายการ คือ AWS Certified Cloud Practitioner (CLF-C02) และ AWS Certified AI Practitioner (AIF-C01) ส่วน Developer - Associate (DVA-C02) และ Data Engineer - Associate (DEA-C01) ทั้งคู่อยู่ในระดับ Associate ขณะที่ Advanced Networking - Specialty (ANS-C01) อยู่ในระดับ Specialty การรับรองที่มีชื่อระดับต่อท้ายชื่อจะใช้เป็นเบาะแสได้ แต่ Cloud Practitioner และ AI Practitioner ไม่มีชื่อระดับต่อท้าย จึงควรจำไว้ว่าทั้งสองนี้คือ Foundational

CLF-C02 เป็นรหัสข้อสอบของ AWS Certified Cloud Practitioner โดย CLF ย่อมาจาก Cloud Practitioner และ C02 ท้ายรหัสหมายถึงรุ่นที่ปรับปรุง รหัสของ AWS Certified AI Practitioner คือ AIF-C01, AWS Certified Developer - Associate คือ DVA-C02 และ AWS Certified Data Engineer - Associate คือ DEA-C01 ชื่อการรับรองอาจถูกเปลี่ยนชื่อได้ แต่รหัสข้อสอบจะไม่เปลี่ยนจนกว่าจะมีการปรับปรุงรุ่น ดังนั้นการตรวจสอบว่าสื่อการเรียนเป็นรุ่นปัจจุบันหรือไม่ ให้ดูจากรหัสข้อสอบจึงจะแน่นอนที่สุด

รหัสข้อสอบของ AWS Certified Solutions Architect - Professional คือ SAP-C02 ส่วน SAA-C03 คือ Solutions Architect ในระดับ Associate เช่นกัน SOA-C03 คือ CloudOps Engineer - Associate และ SCS-C03 คือ Security - Specialty ตัวอักษร 3 ตัวแรกคล้ายกันจนอาจสับสน แต่ควรจำไว้ว่า SAA สอดคล้องกับ Associate ส่วน SAP สอดคล้องกับ Professional

Exam Guide ของ CLF-C02 กำหนดสัดส่วนไว้ว่า Cloud Concepts 24 เปอร์เซ็นต์ Security and Compliance 30 เปอร์เซ็นต์ Cloud Technology and Services 34 เปอร์เซ็นต์ และ Billing, Pricing, and Support 12 เปอร์เซ็นต์ ดังนั้นสัดส่วนมากที่สุดคือ Cloud Technology and Services และน้อยที่สุดคือ Billing, Pricing, and Support แม้จะเป็นการรับรองระดับเริ่มต้นที่หลายคนคิดว่าเนื้อหาด้านแนวคิดจะหนักที่สุด แต่ในความเป็นจริงโดเมนที่ถามความรู้เรื่องบริการมีสัดส่วนมากที่สุด รองลงมาคือด้านความปลอดภัย การแบ่งเวลาเรียนควรให้สอดคล้องกับสัดส่วนนี้

Exam Guide ของ SAA-C03 กำหนดสัดส่วนไว้ว่า Design Secure Architectures 30 เปอร์เซ็นต์ Design Resilient Architectures 26 เปอร์เซ็นต์ Design High-Performing Architectures 24 เปอร์เซ็นต์ และ Design Cost-Optimized Architectures 20 เปอร์เซ็นต์ สัดส่วนมากที่สุดคือการออกแบบสถาปัตยกรรมที่ปลอดภัย ชื่อโดเมนทั้ง 4 นี้อ่านคู่กับเสาหลักของ Well-Architected ได้ง่ายขึ้น โดยเรียงตามลำดับความปลอดภัย ความน่าเชื่อถือ ประสิทธิภาพการทำงาน และการเพิ่มประสิทธิภาพต้นทุน

การรับรองระดับ Associate สายปฏิบัติการเปลี่ยนชื่อจาก SysOps Administrator เป็น CloudOps Engineer และรหัสข้อสอบก็เปลี่ยนจาก SOA-C02 เป็น SOA-C03 วันสุดท้ายที่สามารถสอบด้วยรหัสเดิมคือ 29 กันยายน 2025 และรหัสใหม่เริ่มใช้ตั้งแต่วันที่ 30 กันยายน 2025 ส่วน Data Engineer - Associate และ Machine Learning Engineer - Associate ไม่ใช่ผู้สืบทอดสายปฏิบัติการ แต่เป็นการรับรองใหม่ที่ตั้งขึ้นแยกต่างหากในด้านข้อมูลและ ML ตามลำดับ ส่วน DevOps Engineer - Professional เป็นการรับรองระดับ Professional ที่มีอยู่ก่อนแล้วและอยู่คนละระดับ

AWS เรียกความรับผิดชอบฝั่งตนเองว่า "Security of the Cloud" และกำหนดว่าคือการปกป้องโครงสร้างพื้นฐานที่ใช้ให้บริการทุกอย่างบนคลาวด์ของ AWS นั่นคือการปกป้องฮาร์ดแวร์ ซอฟต์แวร์ เครือข่าย และสถานที่ตั้ง การรับมือช่องโหว่ของแอปพลิเคชันที่ติดตั้งบนอินสแตนซ์เป็นความรับผิดชอบของผู้ใช้ในกรณีที่เลือกใช้ EC2 ส่วนการเลือกตัวเลือกการเข้ารหัสข้อมูลและการให้สิทธิ์ผ่าน IAM เป็นงานที่ยังคงอยู่ฝั่งผู้ใช้ไม่ว่าจะเลือกใช้บริการใดก็ตาม ซึ่งทั้งสองอย่างนี้จัดอยู่ในฝั่ง "Security in the Cloud"

ทาง AWS ระบุไว้ชัดเจนว่า "ความรับผิดชอบของลูกค้าถูกกำหนดโดยบริการคลาวด์ของ AWS ที่ลูกค้าเลือกใช้" หมายความว่าปริมาณงานตั้งค่าที่ผู้ใช้ต้องทำในฐานะส่วนหนึ่งของความรับผิดชอบด้านความปลอดภัยจะเปลี่ยนไปตามบริการที่เลือก แผนสนับสนุนเป็นเรื่องของวิธีรับความช่วยเหลือทางเทคนิค ไม่ใช่สิ่งที่เปลี่ยนเส้นแบ่งความรับผิดชอบ ภูมิภาคและโซนความพร้อมใช้งานเป็นเรื่องของการวางตำแหน่ง ส่วนระยะเวลาใช้งานและยอดเงินเป็นเรื่องของการเรียกเก็บเงิน ไม่มีข้อใดเป็นปัจจัยที่กำหนดขอบเขตความรับผิดชอบ

ทาง AWS ระบุว่าสำหรับบริการที่ต้องมีการกำหนดค่าอย่าง EC2 ผู้ใช้จะรับผิดชอบ "การจัดการ Guest OS (รวมถึงการอัปเดตและติดตั้งแพตช์ความปลอดภัย) ซอฟต์แวร์แอปพลิเคชันหรือยูทิลิตี้ที่ติดตั้งบนอินสแตนซ์ และการตั้งค่ากลุ่มความปลอดภัย (Security Group)" ดังนั้นการติดตั้งแพตช์ให้ OS จึงเป็นความรับผิดชอบของผู้ใช้ ในกรณีของ EC2 สิ่งที่ AWS ดำเนินการมีเพียงโครงสร้างพื้นฐานทางกายภาพและชั้นเวอร์ชวลไลเซชันเท่านั้น ไม่รวมถึง OS ภายในอินสแตนซ์ แผนสนับสนุนเป็นสัญญาสำหรับรับความช่วยเหลือทางเทคนิค ไม่ได้เปลี่ยนตำแหน่งความรับผิดชอบ

สำหรับบริการที่ถูกทำให้เป็นนามธรรมหรือเป็นแบบจัดการให้ (Managed) ทาง AWS ระบุว่า "AWS ดำเนินการชั้นโครงสร้างพื้นฐาน OS และแพลตฟอร์ม ส่วนลูกค้าเข้าถึงผ่านเอนด์พอยต์เพื่อจัดเก็บและดึงข้อมูล" สิ่งที่ยังคงอยู่ฝั่งผู้ใช้คือการจัดการข้อมูลของตนเอง (รวมถึงตัวเลือกการเข้ารหัส) การจัดหมวดหมู่ทรัพย์สิน และการให้สิทธิ์ที่เหมาะสมผ่านเครื่องมือ IAM ทั้งการอัปเดต OS และการดำเนินการแพลตฟอร์มไม่ใช่สิ่งที่ผู้ใช้ทำ แต่การจัดหมวดหมู่ข้อมูลและการตั้งค่าสิทธิ์ยังคงเป็นของผู้ใช้ไม่ว่าจะเป็นบริการใดก็ตาม

เส้นแบ่งของโมเดลความรับผิดชอบร่วมไม่คงที่ แต่เปลี่ยนไปตามบริการที่เลือกใช้ สำหรับบริการอย่าง EC2 ที่ผู้ใช้ต้องจัดการ Guest OS เอง การติดตั้งแพตช์เป็นความรับผิดชอบของผู้ใช้ แต่สำหรับบริการอย่าง S3 หรือ DynamoDB ที่ AWS ดำเนินการ OS และแพลตฟอร์มให้ จะกลายเป็นความรับผิดชอบของ AWS ดังนั้นทั้ง "เป็นของ AWS เสมอ" และ "เป็นของผู้ใช้เสมอ" ล้วนไม่ถูกต้อง ภูมิภาคเป็นเพียงการเลือกสถานที่วาง ไม่ได้เปลี่ยนการแบ่งความรับผิดชอบ หากจำจุดนี้ได้ แม้เจอบริการใหม่ที่ไม่เคยเห็นมาก่อน ก็สามารถเดาเส้นแบ่งได้จากการพิจารณาว่าใกล้เคียง EC2 หรือ S3 มากกว่ากัน

สถานที่ตั้งถูกระบุไว้อย่างชัดเจนใน Security of the Cloud ว่าเป็นส่วนหนึ่งของโครงสร้างพื้นฐานที่ใช้ให้บริการคลาวด์ของ AWS จึงเป็นความรับผิดชอบของ AWS เสมอไม่ว่าจะใช้บริการใด ผู้ใช้ไม่สามารถตรวจสอบขอบเขตนี้ด้วยตนเองหรือเข้าไปตรวจสอบในสถานที่ได้ แต่จะยืนยันผ่านการรับรองจากบุคคลที่สามหรือรายงานการตรวจสอบที่ AWS เปิดเผยแทน นี่ตรงกับการควบคุมประเภทที่สืบทอดมา (Inherited Controls) ในสามหมวดของการควบคุม ซึ่งเป็นส่วนที่ผู้ใช้รับสืบทอดมาจาก AWS โดยสมบูรณ์ สิ่งที่เปลี่ยนไปตามบริการที่เลือกคือชั้น OS และมิดเดิลแวร์ ไม่ใช่ชั้นทางกายภาพ

การจัดการข้อมูลของตนเอง (รวมถึงตัวเลือกการเข้ารหัส) การจัดหมวดหมู่ทรัพย์สิน และการให้สิทธิ์ที่เหมาะสมผ่านเครื่องมือ IAM ถูกระบุไว้อย่างเป็นทางการว่ายังคงอยู่ฝั่งผู้ใช้แม้จะใช้บริการที่ถูกทำให้เป็นนามธรรมก็ตาม เนื่องจากไม่ว่าจะเลือกบริการใดก็ไม่เปลี่ยนแปลง จึงถือเป็นจุดคงที่เมื่อพิจารณาเส้นแบ่ง การเปลี่ยนเซิร์ฟเวอร์กายภาพและการปกป้องเครือข่ายแบ็กโบนล้วนเกี่ยวกับสถานที่และฮาร์ดแวร์ ซึ่งเป็นฝั่ง AWS เสมอ ส่วน OS ที่เป็นฐานของบริการแบบจัดการให้นั้น AWS เป็นผู้ดำเนินการ การติดตั้งแพตช์จึงไม่ใช่งานของผู้ใช้

การควบคุมที่สืบทอดคือสิ่งที่ผู้ใช้สืบทอดมาจาก AWS โดยสมบูรณ์ ได้แก่การควบคุมทางกายภาพและสิ่งแวดล้อม ตามที่ระบุไว้อย่างเป็นทางการ ส่วนการควบคุมที่ใช้แยกกันในทั้งชั้นโครงสร้างพื้นฐานและชั้นผู้ใช้คือการควบคุมร่วม (Shared Controls) และการควบคุมที่เป็นความรับผิดชอบของผู้ใช้ทั้งหมด ได้แก่ความปลอดภัยของบริการและโซน คือการควบคุมเฉพาะของลูกค้า (Customer Specific Controls) ทิศทางของการสืบทอดเป็นทางเดียวจาก AWS ไปยังผู้ใช้ ไม่ใช่ความสัมพันธ์ที่ AWS รับช่วงการตั้งค่าของผู้ใช้มาดำเนินการ

ตัวอย่างของการควบคุมร่วมที่ทาง AWS ยกไว้มี 3 อย่าง คือการจัดการแพตช์ การจัดการการกำหนดค่า และการสร้างความตระหนักรู้และการฝึกอบรม ทั้งหมดนี้มีลักษณะเด่นคือกิจกรรมเดียวกันถูกดำเนินการควบคู่กันทั้งในชั้นโครงสร้างพื้นฐานและชั้นผู้ใช้ เช่นการจัดการแพตช์ AWS จะดำเนินการกับโครงสร้างพื้นฐานของตนเอง ส่วนผู้ใช้ดำเนินการกับ Guest OS และแอปพลิเคชันแยกกันไป การควบคุมการเข้าออก การสำรองระบบไฟฟ้า การจัดหาและกำจัดฮาร์ดแวร์ เป็นการควบคุมทางกายภาพและสิ่งแวดล้อมซึ่งผู้ใช้สืบทอดมาจาก AWS ส่วนความปลอดภัยของบริการและโซนเป็นตัวอย่างของการควบคุมเฉพาะของลูกค้า

DynamoDB เป็นบริการที่ถูกทำให้เป็นนามธรรม ดังนั้น AWS จึงดำเนินการชั้นโครงสร้างพื้นฐาน OS และแพลตฟอร์ม การติดตั้งแพตช์ Guest OS ซึ่งเดิมผู้ใช้ต้องทำเองบน EC2 จะกลายเป็นงานของ AWS หลังการย้าย ในขณะที่การจัดหมวดหมู่ข้อมูล การเลือกตัวเลือกการเข้ารหัส และการให้สิทธิ์ผ่าน IAM ยังคงอยู่ฝั่งผู้ใช้ไม่ว่าจะเลือกบริการใด การปกป้องสถานที่ตั้งเป็นความรับผิดชอบของ AWS อยู่แล้วตั้งแต่แรก จึงไม่มีทางย้ายไปเป็นของผู้ใช้แม้จะย้ายระบบก็ตาม ควรจำไว้ว่า "ส่วนที่เปลี่ยนคือชั้น OS หรือแพลตฟอร์ม ส่วนที่ไม่เปลี่ยนคือข้อมูลและสิทธิ์"

เสาหลักในปัจจุบันมี 6 ข้อ คือ ความเป็นเลิศด้านการดำเนินงาน ความปลอดภัย ความน่าเชื่อถือ ประสิทธิภาพการทำงาน การเพิ่มประสิทธิภาพต้นทุน และความยั่งยืน ความยั่งยืนถูกเพิ่มเข้ามาเป็นเสาที่ 6 ในปี 2021 ดังนั้นรายการที่มีเพียง 5 เสาโดยไม่มีความยั่งยืนจึงเป็นข้อมูลเก่าก่อนการเพิ่มนี้ ส่วนความสามารถในการทำงานร่วมกันและความสามารถในการเคลื่อนย้ายไม่ใช่คำที่ถูกระบุว่าเป็นเสาหลักของเฟรมเวิร์ก ไม่มีอยู่ในรายการอย่างเป็นทางการทั้งคู่ บทความที่มีจำนวนเสาหลักผิดมักมีความเสี่ยงสูงที่ชื่อบริการหรือรหัสข้อสอบจะเก่าไปด้วย จึงใช้เป็นจุดสังเกตความสดใหม่ของสื่อการเรียนได้

ความเป็นเลิศด้านการดำเนินงานเป็นเสาหลักที่ให้ความสำคัญกับการรันและติดตามระบบ รวมถึงการปรับปรุงกระบวนการและขั้นตอนอย่างต่อเนื่อง สิ่งที่เกี่ยวข้องได้แก่ การทำให้การดีพลอยเป็นอัตโนมัติ การปรับปรุงขั้นตอนหลังทบทวนความล้มเหลว และการเปลี่ยนแปลงทีละเล็กน้อยบ่อยครั้ง การปกป้องข้อมูลและระบบคือความปลอดภัย การเพิ่มประสิทธิภาพการจัดสรรทรัพยากรและการเลือกประเภททรัพยากรคือประสิทธิภาพการทำงาน การขจัดค่าใช้จ่ายที่ไม่จำเป็นและการปรับทรัพยากรให้เหมาะสมคือการเพิ่มประสิทธิภาพต้นทุน ซึ่งทั้งหมดนี้ชี้ไปยังเสาหลักอื่น

เสาหลักความปลอดภัยให้ความสำคัญกับการปกป้องข้อมูลและระบบ โดยเน้นที่ความสมบูรณ์ของข้อมูลและการควบคุมการเข้าถึงเป็นศูนย์กลาง การเข้ารหัสข้อมูลและการควบคุมการเข้าถึงตามหลักการให้สิทธิ์น้อยที่สุดตรงกับข้อนี้โดยตรง การหยุดใช้ทรัพยากรที่ไม่ได้ใช้งานและปรับขนาดอินสแตนซ์ให้เหมาะสมคือการเพิ่มประสิทธิภาพต้นทุน การทำให้การดีพลอยเป็นอัตโนมัติและปรับปรุงขั้นตอนหลังทบทวนความล้มเหลวคือความเป็นเลิศด้านการดำเนินงาน ส่วนการวัดและลดผลกระทบต่อสิ่งแวดล้อมคือความยั่งยืน ส่วนใหญ่ของขอบเขตที่ผู้ใช้รับผิดชอบในโมเดลความรับผิดชอบร่วมจะถูกจัดการในเสาหลักความปลอดภัยนี้

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

ประสิทธิภาพการทำงานเป็นเสาหลักที่ให้ความสำคัญกับการเพิ่มประสิทธิภาพการจัดสรรทรัพยากรไอที และการเลือกประเภททรัพยากรให้เหมาะกับความต้องการของเวิร์กโหลด การเลือกประเภททรัพยากรใหม่เพื่อให้ตรงตามข้อกำหนดตรงกับข้อนี้โดยตรง การเพิ่มประสิทธิภาพต้นทุนดูเหมือนเป็นงานคล้ายกัน แต่มีจุดประสงค์เพื่อขจัดค่าใช้จ่ายที่ไม่จำเป็น ในขณะที่กรณีนี้แรงจูงใจคือการทำให้ตรงตามข้อกำหนดด้านเลเทนซี จึงมีจุดเน้นต่างกัน ความน่าเชื่อถือดูความทนทานต่อความล้มเหลว ความเป็นเลิศด้านการดำเนินงานดูการปรับปรุงขั้นตอน ซึ่งทั้งสองไม่ใช่จุดเน้นหลักในกรณีนี้

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

ความยั่งยืนเป็นเสาหลักที่ให้ความสำคัญกับการลดผลกระทบต่อสิ่งแวดล้อมที่เกิดจากการรันเวิร์กโหลดบนคลาวด์ให้น้อยที่สุด เป็นเสาหลักใหม่ที่สุดซึ่งถูกเพิ่มเข้ามาเป็นเสาที่ 6 ในปี 2021 การมีหรือไม่มีเสานี้จึงเป็นจุดแบ่งกับสื่อการเรียนรุ่นเก่า การเพิ่มประสิทธิภาพการจัดสรรทรัพยากรและการเลือกประเภททรัพยากรคือประสิทธิภาพการทำงาน การรันติดตามและปรับปรุงขั้นตอนอย่างต่อเนื่องคือความเป็นเลิศด้านการดำเนินงาน การทำหน้าที่ตามที่ตั้งใจและการฟื้นตัวจากความล้มเหลวคือความน่าเชื่อถือ ซึ่งทั้งหมดนี้ชี้ไปยังเสาหลักอื่น

เสาหลักที่ขาดไปคือความยั่งยืน (Sustainability) ซึ่งดูแลการลดผลกระทบต่อสิ่งแวดล้อมที่เกิดจากการรันเวิร์กโหลดบนคลาวด์ เนื่องจากถูกเพิ่มเข้ามาเป็นเสาที่ 6 ในปี 2021 บทความที่เขียนก่อนหน้านั้นจึงยังคงมีแค่ 5 เสา ส่วนความเป็นเลิศด้านการดำเนินงาน ประสิทธิภาพการทำงาน และความน่าเชื่อถือ มีอยู่ก่อนการเพิ่มเสานี้แล้ว จึงปรากฏอยู่ในบทความที่เขียนว่ามี 5 เสาด้วยเช่นกัน บทความที่เนื้อหาพื้นฐานอย่างจำนวนเสาหลักผิดพลาด ควรพิจารณาว่าเนื้อหาส่วนอื่นก็มีแนวโน้มจะเก่าไปด้วยเช่นกัน

เสาหลักในปัจจุบันมี 6 ข้อ คือ ความเป็นเลิศด้านการดำเนินงาน ความปลอดภัย ความน่าเชื่อถือ ประสิทธิภาพการทำงาน การเพิ่มประสิทธิภาพต้นทุน และความยั่งยืน ซึ่งไม่รวมความสามารถในการทำงานร่วมกัน แม้การที่ระบบต่างชนิดกันสามารถเชื่อมต่อกันได้จะเป็นประเด็นสำคัญด้านการออกแบบ แต่เฟรมเวิร์ก Well-Architected ไม่ได้ตั้งเป็นเสาหลักแยกต่างหาก การเพิ่มประสิทธิภาพต้นทุน ความเป็นเลิศด้านการดำเนินงาน และประสิทธิภาพการทำงาน ล้วนเป็นเสาหลักที่ถูกต้องในบรรดา 6 ข้อ การจำคำที่ไม่มีอยู่ในเฟรมเวิร์กว่าเป็นเสาหลัก อาจทำให้สับสนเมื่อต้องตัดตัวเลือกออก

การขจัดค่าใช้จ่ายที่ไม่จำเป็นและการปรับทรัพยากรให้เหมาะสมกับความต้องการทางธุรกิจคือจุดเน้นของการเพิ่มประสิทธิภาพต้นทุน ไม่ใช่จุดเน้นของความน่าเชื่อถือ ความน่าเชื่อถือคือเสาหลักที่ให้ความสำคัญกับการที่เวิร์กโหลดทำหน้าที่ตามที่ตั้งใจไว้ และการฟื้นตัวจากความล้มเหลวได้อย่างรวดเร็วเพียงใด อีก 3 ข้อที่เหลือเป็นการจับคู่ที่ตรงตามที่ระบุไว้อย่างเป็นทางการ ชื่อของเสาหลักใกล้เคียงกับคำที่ใช้ในชีวิตประจำวัน จึงอาจเชื่อมโยงผิดได้จากความรู้สึกของตัวอักษร การจำประโยคที่แสดงจุดเน้นควบคู่กันไปจะช่วยไม่ให้สะดุดกับคำถามรูปแบบนี้

ภูมิภาค (Region) คือสถานที่ทางกายภาพในโลกที่ AWS มีโซนความพร้อมใช้งานหลายแห่ง มีชื่อเรียกเช่น us-east-1 หรือ ap-northeast-1 การเลือกภูมิภาคจะพิจารณาจากที่ตั้งของข้อมูลและกฎระเบียบ ระยะห่างจากผู้ใช้ และค่าบริการ หน่วยแยกความล้มเหลวที่ประกอบด้วยศูนย์ข้อมูลอิสระตั้งแต่หนึ่งแห่งขึ้นไปคือคำอธิบายของโซนความพร้อมใช้งาน จุดที่ CloudFront แคชและกระจายเนื้อหาคือ Edge Location ส่วนโซนที่วางอยู่ในเครือข่ายของผู้ให้บริการโทรคมนาคมคือ Wavelength Zones

โซนความพร้อมใช้งานถูกนิยามว่าประกอบด้วยศูนย์ข้อมูลอิสระตั้งแต่หนึ่งแห่งขึ้นไป โดยแต่ละแห่งมีระบบไฟฟ้า เครือข่าย และการเชื่อมต่อที่สำรองซ้ำซ้อน และตั้งอยู่ในสถานที่แยกจากกัน จุดสำคัญคือไม่ใช่ศูนย์ข้อมูล 1 อาคารเท่านั้น แต่หมายถึงกลุ่มของศูนย์ข้อมูล และอยู่คนละอาคารกับโซนอื่น ชั้นที่อยู่ระหว่าง Edge Location กับ Origin คือ Regional Edge Cache ส่วนจุดที่อยู่ในเมืองใกล้ผู้ใช้และรันแอปพลิเคชันได้คือคำอธิบายของ Local Zones ซึ่งทั้งสองนี้เป็นกลไกที่แตกต่างกัน

ทาง AWS ระบุว่าแต่ละภูมิภาคประกอบด้วย "โซนความพร้อมใช้งานอย่างน้อย 3 แห่งที่แยกจากกันทางกายภาพโดยอิสระ" แม้จำนวนภูมิภาคและโซนทั้งหมดจะเพิ่มขึ้นเรื่อย ๆ จนไม่มีประโยชน์มากนักที่จะจำ แต่กฎเกณฑ์ที่ว่าแต่ละภูมิภาคมีโซนขั้นต่ำเท่าไรนั้นค่อนข้างคงที่ และสามารถนำไปใช้เป็นข้อสมมติในการออกแบบได้เลย คำอธิบายที่ว่าตั้งอยู่ในสถานที่เดียวกันขัดแย้งกับนิยามที่ว่าอยู่ในสถานที่แยกจากกัน โซนไม่ใช่สิ่งที่ผู้ใช้ร้องขอเพื่อเพิ่มจำนวน หรือมีเพียง 1 โซนต่อภูมิภาคเท่านั้น

Edge Location เป็นเครือข่ายศูนย์ข้อมูลทั่วโลกที่ CloudFront ใช้กระจายเนื้อหา คำร้องขอจะถูกส่งไปยัง Edge Location ที่มีเลเทนซีต่ำที่สุด แล้วกระจายเนื้อหาจากจุดนั้น ไม่ใช่หน่วยสำรองซ้ำซ้อนเพื่อความพร้อมใช้งาน แต่เป็นจุดแคชสำหรับกระจายเนื้อหาให้ใกล้ผู้ใช้มากขึ้น การแยกความล้มเหลวคือบทบาทของโซนความพร้อมใช้งาน การแบ่งช่วง IP แอดเดรสคือบทบาทของซับเน็ต และการรันภายในอุปกรณ์ของผู้ให้บริการโทรคมนาคมคือบทบาทของ Wavelength Zones

คำร้องขอจะถูกส่งไปยัง Edge Location ที่มีเลเทนซีต่ำที่สุด หากมีเนื้อหาอยู่ก็จะกระจายให้ทันที หากไม่มีก็จะดึงจาก Origin เช่น S3 bucket หรือเซิร์ฟเวอร์ HTTP มากระจายให้ พร้อมทั้งเก็บไว้ในแคชด้วย ดังนั้นคำร้องขอครั้งต่อไปจึงได้รับข้อมูลจากจุดใกล้เคียงโดยตรง การไม่มีแคชไม่ได้กลายเป็นข้อผิดพลาดหรือทำให้ผู้ใช้ต้องรอค้างไว้ ส่วนการส่งต่อไปยังโซนความพร้อมใช้งานเป็นกลไกแยกความล้มเหลว ไม่ใช่ขั้นตอนของการกระจายเนื้อหา

Regional Edge Cache คือชั้นแคชที่วางอยู่ระหว่าง Edge Location กับ Origin มีหน้าที่ลดจำนวนครั้งที่ต้องไปดึงข้อมูลจาก Origin เมื่อไม่พบที่ Edge หน่วยจัดการที่รวมโซนความพร้อมใช้งานคือภูมิภาค ส่วนโซนที่วางอยู่ในเครือข่ายของผู้ให้บริการโทรคมนาคมคือ Wavelength Zones ซึ่งทั้งสองเป็นแนวคิดที่แตกต่างกัน แคชฝั่งเครื่องผู้ใช้ไม่ใช่กลไกของ AWS แต่เป็นฟังก์ชันของเบราว์เซอร์หรือ OS

โซนความพร้อมใช้งานเป็นหน่วยแยกความล้มเหลวที่ตั้งอยู่ในสถานที่แยกจากกัน มีระบบไฟฟ้าและเครือข่ายสำรองซ้ำซ้อน หากวางทรัพยากรที่ทำหน้าที่เดียวกันไว้ในหลายโซน แม้โซนหนึ่งจะหยุดทำงานทั้งหมด ก็ยังสามารถประมวลผลต่อด้วยโซนที่เหลือได้ นี่คือโครงสร้าง Multi-AZ ซึ่งเป็นจุดเริ่มต้นของการออกแบบด้านความพร้อมใช้งาน การกระจายจากจุดใกล้ผู้ใช้เป็นบทบาทของ Edge Location สถานที่จัดเก็บข้อมูลเป็นปัจจัยในการเลือกภูมิภาค ส่วนการลดราคาต่อหน่วยด้วยการผูกมัดปริมาณการใช้งานเป็นเรื่องของรูปแบบราคา ซึ่งทั้งหมดนี้ไม่ใช่แรงจูงใจในการแยกโซน

Local Zones เป็นกลไกที่ทำให้สามารถรันแอปพลิเคชันบนโครงสร้างพื้นฐานของ AWS ที่อยู่ใกล้ผู้ใช้ปลายทางหรือเวิร์กโหลดมากขึ้น โดยตั้งอยู่ในเมืองที่ห่างจากภูมิภาค แม้จะคล้ายกับ Edge Location ในแง่ที่ดูแลเรื่อง "ความใกล้" แต่ต่างกันตรงที่นี่คือจุดที่ใช้รันแอปพลิเคชันจริง ไม่ใช่แคชสำหรับกระจายเนื้อหา การแยกความล้มเหลวภายในภูมิภาคคือโซนความพร้อมใช้งาน จุดกระจายเฉพาะคือ Edge Location และแคชกลางก่อนถึง Origin คือ Regional Edge Cache

Wavelength Zones เป็นโซนที่ตั้งอยู่ภายในเครือข่ายของผู้ให้บริการโทรคมนาคม เช่นเดียวกับ Local Zones ที่เป็นกลไกสำหรับรันแอปพลิเคชันเองในที่ใกล้ผู้ใช้ ซึ่งมีจุดประสงค์ต่างจาก Edge Location ที่เป็นจุดสำหรับกระจายเนื้อหา สิ่งที่ตั้งอยู่ระหว่าง Edge Location กับ Origin คือ Regional Edge Cache หน่วยแยกความล้มเหลวภายในภูมิภาคคือโซนความพร้อมใช้งาน และสิ่งที่แบ่งช่วง IP แอดเดรสของ VPC คือซับเน็ต

โซนความพร้อมใช้งานเป็นหน่วยแยกความล้มเหลวที่ตั้งอยู่ในสถานที่แยกจากกัน ดังนั้นการเตรียมพร้อมสำหรับกรณีที่โซนใดโซนหนึ่งหยุดทำงานทั้งหมด จำเป็นต้องวางทรัพยากรข้ามโซน แต่ละภูมิภาคประกอบด้วยโซนที่แยกจากกันอย่างน้อย 3 แห่ง จึงสามารถกระจายไปยังหลายโซนภายในภูมิภาคเดียวกันได้ การเพิ่มจำนวนเครื่องในโซนเดิมจะไม่ตอบโจทย์ เพราะหากโซนนั้นล่ม ทุกเครื่องก็จะล่มไปด้วย CloudFront เป็นกลไกสำหรับเร่งความเร็วการกระจายเนื้อหา หาก Origin หยุดทำงาน การประมวลผลแบบไดนามิกก็จะไม่สามารถดำเนินต่อได้ การเปลี่ยนแผนราคาเป็นเรื่องของค่าใช้จ่าย ไม่เกี่ยวข้องกับความพร้อมใช้งาน