50+ คำถาม-คำตอบสัมภาษณ์งาน AWS ที่พบบ่อยสำหรับปี 2026

ทำไมต้อง AWS?

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

กราฟิกต่อไปนี้แสดงส่วนแบ่งตลาดทั่วโลกของผู้ให้บริการโครงสร้างพื้นฐานคลาวด์ชั้นนำในไตรมาสที่สาม (Q3) ปี 2025 โดยมีรายละเอียดส่วนแบ่งตลาดดังนี้:

• Amazon Web Services (AWS) ครองส่วนแบ่งตลาดมากที่สุดที่ 29%
• Microsoft Azure ตามมาที่ 20%
• Google Cloud ครอง 13% ของตลาด
• Alibaba Cloud มีส่วนแบ่ง 4%
• Oracle เติบโตจนถึง 3%
• Salesforce, IBM Cloud และ Tencent Cloud อยู่ลำดับท้าย ๆ ที่ 2% เท่ากัน

ที่มา (Statista)

กราฟิกยังระบุด้วยว่าข้อมูลรวมถึงแพลตฟอร์มเป็นบริการ (PaaS) และโครงสร้างพื้นฐานเป็นบริการ (IaaS) ตลอดจนบริการโฮสต์ระบบคลาวด์ส่วนตัว นอกจากนี้ยังระบุว่ารายได้จากบริการโครงสร้างพื้นฐานคลาวด์ใน Q3 2025 อยู่ที่ 107 พันล้านดอลลาร์ ซึ่งเพิ่มขึ้นอย่างมีนัยสำคัญจาก Q3 2024 ที่ 84 พันล้านดอลลาร์

Amazon Web Services (AWS) ยังคงเป็นผู้นำในตลาดคลาวด์ ณ Q3 2025 โดยมีคะแนนนำสำคัญเหนือคู่แข่งที่ใกล้ที่สุดอย่าง Microsoft Azure

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

ชีตสรุปของเรา การเปรียบเทียบบริการของ AWS, Azure และ GCP สำหรับ Data Science & AI นำเสนอการเทียบเคียงบริการหลักที่จำเป็นต่อการทำงานด้านข้อมูลและ AI ตั้งแต่วิศวกรรมข้อมูล การวิเคราะห์ข้อมูล และวิทยาการข้อมูล ไปจนถึงการสร้างแอปพลิเคชันข้อมูล

คำถามสัมภาษณ์ AWS ระดับพื้นฐาน

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

Cloud computing คืออะไร?

Cloud computing มอบการเข้าถึงทรัพยากรไอทีแบบออนดีมานด์ เช่น คอมพิวต์ สตอเรจ และฐานข้อมูล ผ่านอินเทอร์เน็ต ผู้ใช้จ่ายเฉพาะตามการใช้งานแทนการเป็นเจ้าของโครงสร้างพื้นฐานจริง

คลาวด์ช่วยให้เข้าถึงบริการเทคโนโลยีได้อย่างยืดหยุ่นตามความต้องการ โดยไม่ต้องลงทุนก้อนใหญ่ล่วงหน้า ผู้ให้บริการชั้นนำอย่าง AWS มีบริการคลาวด์หลากหลายผ่านโมเดลคิดค่าบริการตามการใช้งาน คอร์ส AWS Cloud Concepts ของเราครอบคลุมพื้นฐานเหล่านี้จำนวนมาก

ปัญหาของแนวทางไอทีแบบดั้งเดียบเทียบกับการใช้คลาวด์คืออะไร?

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

ในคลาวด์มีโมเดลการปรับใช้กี่ประเภท?

มีโมเดลการปรับใช้ในคลาวด์อยู่ 3 ประเภท และอธิบายไว้ดังนี้:

• Private cloud: ประเภทนี้ใช้โดยองค์กรเดียวและไม่เปิดสู่สาธารณะ เหมาะกับองค์กรที่ใช้งานที่มีความอ่อนไหว
• Public cloud: ทรัพยากรคลาวด์เป็นของและดำเนินการโดยผู้ให้บริการบุคคลที่สาม เช่น Amazon Web Services, Microsoft Azure และผู้ให้บริการทั้งหมดที่กล่าวถึงในส่วนส่วนแบ่งตลาด AWS
• Hybrid cloud: การผสานระหว่างคลาวด์แบบส่วนตัวและสาธารณะ ออกแบบให้คงบางเซิร์ฟเวอร์ไว้ในองค์กร ขณะขยายความสามารถที่เหลือสู่คลาวด์ ไฮบริดคลาวด์ให้ทั้งความยืดหยุ่นและความคุ้มค่าของคลาวด์สาธารณะ

ลักษณะสำคัญทั้งห้าของ Cloud computing คืออะไร?

Cloud computing ประกอบด้วยลักษณะสำคัญ 5 ประการ ดังนี้:

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

ประเภทหลักของ Cloud Computing มีอะไรบ้าง?

ประเภทหลักของ Cloud computing มี 3 ประเภท: IaaS, PaaS และ SaaS

• Infrastructure as a Service (IaaS): มอบบล็อกพื้นฐานของไอทีบนคลาวด์ เช่น คอมพิวต์ สตอเรจ และเครือข่าย ที่ผู้ใช้เข้าถึงแบบออนดีมานด์ โดยไม่ต้องจัดการโครงสร้างพื้นฐานเบื้องล่าง ตัวอย่าง: AWS EC2, S3, VPC
• Platform as a Service (PaaS): มอบแพลตฟอร์ม/สภาพแวดล้อมแบบจัดการสำหรับพัฒนา ดีพลอย และดูแลแอปบนคลาวด์ โดยไม่ต้องสร้างโครงสร้างพื้นฐานเบื้องล่าง ตัวอย่าง: AWS Elastic Beanstalk, Heroku
• Software as a Service (SaaS): มอบการเข้าถึงแอปสำหรับผู้ใช้ปลายทางที่รันอยู่บนคลาวด์ผ่านอินเทอร์เน็ต ผู้ใช้ไม่ต้องจัดการโครงสร้างพื้นฐานหรือแพลตฟอร์ม ตัวอย่าง: AWS Simple Email Service, Google Docs, Salesforce CRM

สามารถศึกษารายละเอียดเพิ่มเติมได้ในคอร์ส Understanding Cloud Computing ของเรา

Amazon EC2 คืออะไร และใช้ทำอะไรบ้าง?

Amazon EC2 (Elastic Compute Cloud) มอบเซิร์ฟเวอร์เสมือนแบบสเกลได้ที่เรียกว่าอินสแตนซ์ใน AWS Cloud ใช้รันเวิร์กโหลดหลากหลายอย่างยืดหยุ่นและคุ้มค่า ตัวอย่างการใช้งานหลัก ๆ ได้แก่:

• โฮสต์เว็บไซต์และเว็บแอปพลิเคชัน
• รันกระบวนการแบ็กเอนด์และงานแบตช์
• ทำโซลูชันไฮบริดคลาวด์
• บรรลุความพร้อมใช้งานสูงและการสเกลได้
• ลดเวลาออกสู่ตลาดสำหรับเคสการใช้งานใหม่

Amazon S3 คืออะไร และทำไมจึงสำคัญ?

Amazon Simple Storage Service (S3) เป็นบริการจัดเก็บวัตถุที่ยืดหยุ่น สเกลได้ และปลอดภัย เป็นรากฐานของแอปและเวิร์กโหลดบนคลาวด์จำนวนมาก จุดเด่นด้านความสำคัญ เช่น:

• ทนทานด้วยความทนทาน 99.999999999% และความพร้อมใช้งาน 99.99% เหมาะกับข้อมูลสำคัญ
• รองรับคุณสมบัติความปลอดภัยที่แข็งแกร่ง เช่น นโยบายการเข้าถึง การเข้ารหัส ปลายทาง VPC
• ผสานทำงานกับบริการ AWS อื่น ๆ อย่างไร้รอยต่อ เช่น Lambda, EC2, EBS เป็นต้น
• ความหน่วงต่ำและอัตราการรับส่งสูง เหมาะกับการวิเคราะห์บิ๊กดาต้า แอปมือถือ การเก็บและส่งสื่อ
• คุณสมบัติการจัดการที่ยืดหยุ่นสำหรับมอนิเตอร์ ล็อกการเข้าถึง การทำซ้ำ เวอร์ชันนิง นโยบายวงจรชีวิต
• หนุนหลังด้วยโครงสร้างพื้นฐานระดับโลกของ AWS เพื่อการเข้าถึงหน่วงต่ำทั่วโลก

อธิบายแนวคิดเรื่อง ‘Regions’ และ ‘Availability Zones’ ใน AWS

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

คอร์ส AWS Cloud Concepts ของเราเป็นคู่มือครบถ้วนสำหรับทำความรู้จักบริการหลักของ AWS แนวปฏิบัติที่ดีในการออกแบบแอปบน AWS และประโยชน์ของการใช้ AWS สำหรับธุรกิจ

IAM คืออะไร และทำไมจึงสำคัญ?

AWS Identity and Access Management (IAM) เป็นบริการที่ช่วยควบคุมการเข้าถึงบริการและทรัพยากร AWS อย่างปลอดภัย IAM ช่วยจัดการผู้ใช้ กลุ่ม และบทบาท ด้วยสิทธิ์แบบละเอียด สำคัญเพราะช่วยบังคับใช้หลักการสิทธิ์น้อยที่สุด ทำให้ผู้ใช้เข้าถึงเฉพาะทรัพยากรที่จำเป็น ช่วยเพิ่มความปลอดภัยและการปฏิบัติตามข้อกำหนด

ดูรายละเอียดครบถ้วนได้ใน คู่มือฉบับสมบูรณ์ของ AWS IAM ของเรา

Amazon RDS คืออะไร และแตกต่างจากฐานข้อมูลแบบดั้งเดิมอย่างไร?

Amazon Relational Database Service (RDS) เป็นบริการฐานข้อมูลแบบจัดการ ช่วยให้ผู้ใช้ตั้งค่า ดำเนินงาน และสเกลฐานข้อมูลได้ โดยไม่ต้องกังวลกับงานจัดการโครงสร้างพื้นฐาน เช่น แบ็กอัป แพทช์ และการสเกล ต่างจากฐานข้อมูลแบบดั้งเดิม RDS สเกลและมีความพร้อมใช้งานสูงตั้งแต่ต้น รองรับแบ็กอัปอัตโนมัติ และอนุญาตให้ทำรีดรีพลิกาและดีพลอยแบบหลาย AZ เพื่อการเฟลโอเวอร์และความซ้ำซ้อน

ต่อไปนี้เป็นตารางสรุปความแตกต่างระหว่าง RDS กับฐานข้อมูลแบบดั้งเดิม สำหรับผู้ที่ชอบภาพรวม:

Amazon VPC คืออะไร และใช้เพื่ออะไร?

Amazon Virtual Private Cloud (VPC) ช่วยให้สร้างเครือข่ายเสมือนใน AWS ที่มีลักษณะคล้ายเครือข่ายแบบดั้งเดิมในดาต้าเซ็นเตอร์ภายในองค์กร VPC ใช้เพื่อแยกทรัพยากร ควบคุมทราฟฟิกขาเข้า-ขาออก และแบ่งเวิร์กโหลดเป็นซับเน็ตด้วยการตั้งค่าความปลอดภัยที่เข้มงวด มอบการควบคุมช่วง IP กลุ่มความปลอดภัย และรายการควบคุมการเข้าถึงเครือข่ายอย่างละเอียด

Amazon CloudWatch คืออะไร และมีองค์ประกอบหลักอะไรบ้าง?

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

• Metrics: CloudWatch รวบรวมจุดข้อมูลหรือเมตริกที่ให้ข้อมูลเชิงลึกด้านการใช้ทรัพยากร ประสิทธิภาพแอป และสุขภาพการปฏิบัติการ ช่วยวิเคราะห์แนวโน้มและสเกลเชิงรุก
• Alarms: การเตือนแจ้งผู้ใช้หรือกระตุ้นการทำงานอัตโนมัติเมื่อเมตริกเกินเกณฑ์ เช่น หากการใช้ CPU เกินค่าที่กำหนด การเตือนอาจเริ่มการออโตสเกลเพื่อตอบรับโหลดที่เพิ่มขึ้น
• Logs: CloudWatch Logs มอบพื้นที่จัดเก็บรวมศูนย์สำหรับล็อกของแอปและโครงสร้างพื้นฐาน จำเป็นต่อการแก้ปัญหาและระบุปัญหา สามารถกรอง มอนิเตอร์ และวิเคราะห์ล็อกเพื่อการดำเนินงานที่ราบรื่น
• Events: CloudWatch Events (หรือ Amazon EventBridge) ตรวจจับการเปลี่ยนแปลงของทรัพยากร AWS และสามารถทริกเกอร์การกระทำที่กำหนดไว้ล่วงหน้า เช่น เรียกใช้ฟังก์ชัน Lambda เมื่อเกิดเหตุการณ์เฉพาะ ช่วยเพิ่มการอัตโนมัติและตอบสนองต่อเหตุการณ์วิกฤตได้รวดเร็ว

AWS Lambda คืออะไร และช่วยให้เกิด serverless computing ได้อย่างไร?

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

• รันโค้ดตามเหตุการณ์: Lambda รันโค้ดเฉพาะเมื่อถูกทริกเกอร์โดยเหตุการณ์ เช่น คำขอ HTTP หรือการอัปโหลดไฟล์ใน Amazon S3 ช่วยใช้ทรัพยากรเท่าที่จำเป็น เพื่อความคุ้มค่าและประสิทธิภาพ
• สเกลอัตโนมัติ: Lambda สเกลอัตโนมัติตามจำนวนคำขอที่เข้ามา รองรับตั้งแต่คำขอเดี่ยวจนถึงหลักพันต่อวินาที ทำให้แอปตอบสนองได้แม้ทราฟฟิกผันผวน
• โฟกัสที่โค้ด ไม่ใช่อินฟราฯ: Lambda ซ่อนความซับซ้อนของโครงสร้างพื้นฐาน นักพัฒนาจึงโฟกัสที่การเขียนและดีพลอยโค้ด โดยไม่ต้องกังวลเรื่องการจัดเตรียม จัดการ หรือสเกลเซิร์ฟเวอร์

ด้วยคุณสมบัติเหล่านี้ Lambda จึงสะท้อนหลักการของเซิร์ฟเวอร์เลสอย่างแท้จริง—ยกภาระการจัดการโครงสร้างพื้นฐานออกไป และเปิดโอกาสให้นักพัฒนาสร้าง ทดสอบ และสเกลแอปด้วยความคล่องตัวสูง

Elastic Load Balancing (ELB) ใน AWS คืออะไร?

Elastic Load Balancing (ELB) เป็นบริการที่กระจายทราฟฟิกแอปที่เข้ามาไปยังเป้าหมายหลายรายการโดยอัตโนมัติ เพื่อให้แอปยังคงตอบสนองและยืดหยุ่น ELB มีประโยชน์หลายประการที่ทำให้เป็นองค์ประกอบสำคัญของสถาปัตยกรรม AWS ที่สเกลได้:

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

คำถามสัมภาษณ์ AWS สำหรับสาย DevOps

เมื่อเข้าสู่บทบาทเฉพาะทาง จุดเน้นอยู่ที่วิธีที่ AWS สนับสนุนแนวปฏิบัติ DevOps ส่วนนี้ตรวจสอบการทำงานอัตโนมัติและการเพิ่มประสิทธิภาพสภาพแวดล้อม AWS โดยท้าทายให้แสดงทักษะการใช้ AWS เพื่อทำ CI/CD หากกำลังเล็งตำแหน่ง AWS ขั้นสูง ลองดูบล็อก คำถามสัมภาษณ์ Data Architect เพื่อฝึกคำถามด้านโครงสร้างพื้นฐานและสถาปัตยกรรมข้อมูล

ใช้งาน AWS CodePipeline เพื่อทำ CI/CD อัตโนมัติสำหรับแอปแบบหลายชั้นอย่างไร?

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

ขั้นตอนต่อไปนี้สามารถใช้เพื่อทำ CI/CD อัตโนมัติได้:

• สร้างไปป์ไลน์: เริ่มจากสร้างไปป์ไลน์ใน AWS CodePipeline ระบุแหล่งที่เก็บซอร์สโค้ด (เช่น GitHub, AWS CodeCommit)
• กำหนดขั้นตอนบิลด์: เชื่อมต่อกับบริการบิลด์อย่าง AWS CodeBuild เพื่อคอมไพล์โค้ด รันทดสอบ และสร้างอาร์ติแฟกต์พร้อมดีพลอย
• ตั้งค่าขั้นตอนดีพลอย: คอนฟิกขั้นตอนดีพลอยสำหรับแต่ละเลเยอร์ของแอป ใช้ AWS CodeDeploy เพื่อดีพลอยอัตโนมัติไปยัง Amazon EC2 ใช้ AWS Elastic Beanstalk สำหรับเว็บแอป หรือ AWS ECS สำหรับแอปที่เป็นคอนเทนเนอร์
• เพิ่มขั้นตอนอนุมัติ (ตัวเลือก): สำหรับสภาพแวดล้อมที่สำคัญ แทรกขั้นตอนอนุมัติโดยมนุษย์ก่อนขั้นตอนดีพลอยเพื่อคุมคุณภาพ
• มอนิเตอร์และปรับปรุง: ติดตามประสิทธิภาพไปป์ไลน์และปรับตามความจำเป็น ใช้ฟีดแบ็กและการวนซ้ำเพื่อปรับปรุงกระบวนการดีพลอยอย่างต่อเนื่อง

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

การออกแบบการดีพลอยบน AWS ที่เหมาะสมต้องปรับบริการ AWS ให้ตรงกับความต้องการของแอป ครอบคลุมคอมพิวต์ สตอเรจ และฐานข้อมูล กระบวนการนี้ซับซ้อนจากแคตตาล็อกบริการที่หลากหลายของ AWS และมีขั้นตอนสำคัญดังนี้:

• Provisioning: ตั้งค่าโครงสร้างพื้นฐาน AWS ที่จำเป็น เช่น EC2, VPC, ซับเน็ต หรือบริการแบบจัดการอย่าง S3, RDS, CloudFront สำหรับแอปเบื้องล่าง

• Configuring: ปรับแต่งการตั้งค่าให้ตรงตามข้อกำหนดเฉพาะด้านสภาพแวดล้อม ความปลอดภัย ความพร้อมใช้งาน และประสิทธิภาพ

• Deploying: ปล่อยหรืออัปเดตคอมโพเนนต์ของแอปอย่างมีประสิทธิภาพ เพื่อให้การเปลี่ยนเวอร์ชันราบรื่น

• Scaling: ปรับจัดสรรทรัพยากรแบบไดนามิกตามเกณฑ์ที่กำหนดไว้ล่วงหน้าเพื่อรองรับการเปลี่ยนแปลงของโหลด

• Monitoring: ติดตามการใช้ทรัพยากร ผลลัพธ์การดีพลอย สุขภาพของแอป และล็อก เพื่อให้ทุกอย่างทำงานตามคาด

Infrastructure as Code คืออะไร? อธิบายด้วยคำพูดของคุณเอง

Infrastructure as Code (IaC) เป็นวิธีการจัดการและจัดเตรียมดาต้าเซ็นเตอร์ด้วยไฟล์คำนิยามที่เครื่องอ่านได้ แทนการคอนฟิกฮาร์ดแวร์จริงหรือใช้เครื่องมือคอนฟิกแบบอินเทอร์แอกทีฟ

โดยสรุป ช่วยให้นักพัฒนาและทีมปฏิบัติการไอทีจัดการ มอนิเตอร์ และจัดเตรียมทรัพยากรแบบอัตโนมัติผ่านโค้ด แทนการตั้งค่าและคอนฟิกฮาร์ดแวร์ด้วยตนเอง

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

แนวทางของคุณในการดูแล CI/CD ใน AWS DevOps เป็นอย่างไร?

ในการทำ AWS DevOps สามารถจัดการการผสานรวมและดีพลอยอย่างต่อเนื่องด้วยเครื่องมือสำหรับนักพัฒนาของ AWS เริ่มจากเก็บและติดเวอร์ชันซอร์สโค้ดของแอปด้วยเครื่องมือเหล่านี้

จากนั้นใช้บริการอย่าง AWS CodePipeline เพื่อกำกับขั้นตอนบิลด์ ทดสอบ และดีพลอย โดย CodePipeline จะเป็นแกนเชื่อมกับ AWS CodeBuild สำหรับคอมไพล์และทดสอบโค้ด และ AWS CodeDeploy สำหรับดีพลอยอัตโนมัติสู่สภาพแวดล้อมต่าง ๆ แนวทางนี้ช่วยให้เวิร์กโฟลว์ CI/CD มีประสิทธิภาพและเป็นอัตโนมัติ

Amazon ECS ให้ประโยชน์อะไรกับ AWS DevOps?

Amazon ECS เป็นบริการจัดการคอนเทนเนอร์ที่สเกลได้ ช่วยให้รัน Docker containers บนอินสแตนซ์ EC2 หรือโครงสร้างพื้นฐานแบบเซิร์ฟเวอร์เลสผ่าน Fargate ได้ง่ายขึ้น เพื่อยกระดับการดีพลอยและปฏิบัติการแอป สำหรับทีม DevOps โดยเฉพาะ ECS ผสานกับ CodePipeline และ CodeDeploy ได้โดยตรงเพื่อดีพลอยคอนเทนเนอร์อัตโนมัติ — รวมถึงการปล่อยแบบ blue/green พร้อมการโรลแบ็กอัตโนมัติ — และเชื่อมต่อกับ IAM, CloudWatch และโหลดบาลานเซอร์โดยแทบไม่ต้องคอนฟิกเพิ่ม

กลยุทธ์สำหรับการดีพลอยแบบ blue/green บน AWS มีอะไรบ้าง?

การดีพลอยแบบ blue/green ลดดาวน์ไทม์และความเสี่ยงโดยรันสองสภาพแวดล้อม: blue คือเวอร์ชันปัจจุบัน และ green คือเวอร์ชันใหม่ บน AWS สามารถทำได้ด้วยบริการอย่าง Elastic Beanstalk, AWS CodeDeploy หรือ ECS สามารถสวิตช์ทราฟฟิกระหว่างสภาพแวดล้อมด้วย Route 53 หรือ Application Load Balancer ทดสอบสภาพแวดล้อม green ได้อย่างปลอดภัย และโรลแบ็กได้ทันทีหากจำเป็น

ทำไมบางครั้ง ECS จึงเป็นตัวเลือกที่ดีกว่า Kubernetes?

ECS ให้ความยืดหยุ่น การสเกล และความเรียบง่ายในการใช้งานมากกว่าเมื่อเทียบกับ Kubernetes จึงเป็นตัวเลือกที่เหมาะสมสำหรับการดีพลอยบางกรณี

จะจัดการและรักษาความปลอดภัยของซีเคร็ตสำหรับไปป์ไลน์ CI/CD ใน AWS อย่างไร?

เพื่อจัดการซีเคร็ตในไปป์ไลน์ CI/CD ของ AWS อย่างปลอดภัย สามารถใช้ AWS Secrets Manager หรือ AWS Systems Manager Parameter Store เพื่อเก็บข้อมูลอ่อนไหว เช่น คีย์ API รหัสผ่านฐานข้อมูล และใบรับรอง บริการทั้งสองผสานกับบริการ AWS อย่าง CodePipeline และ CodeBuild ทำให้เข้าถึงซีเคร็ตได้อย่างปลอดภัยโดยไม่ต้องฮาร์ดโค้ดลงในซอร์สโค้ด

โดยการควบคุมสิทธิ์ด้วย IAM จะมั่นใจได้ว่ามีเพียงเอนทิตีที่ได้รับอนุญาตเท่านั้นที่เข้าถึงข้อมูลอ่อนไหวได้ เพิ่มความปลอดภัยภายในกระบวนการ CI/CD

ใช้งาน AWS Systems Manager ในสภาพแวดล้อมโปรดักชันอย่างไร?

AWS Systems Manager ช่วยทำงานอัตโนมัติและจัดการโครงสร้างพื้นฐานขนาดใหญ่ ในโปรดักชัน มักใช้สำหรับการจัดการแพตช์ รันคำสั่งระยะไกล เก็บข้อมูลสินทรัพย์ และเก็บพารามิเตอร์คอนฟิกกับซีเคร็ตอย่างปลอดภัย ผสานกับ EC2, RDS และบริการ AWS อื่น ๆ เพื่อให้เห็นภาพรวมและควบคุมการปฏิบัติการจากศูนย์กลาง

AWS CloudFormation คืออะไร และช่วยสนับสนุนแนวปฏิบัติ DevOps อย่างไร?

AWS CloudFormation ทำให้การจัดเตรียมและจัดการโครงสร้างพื้นฐาน AWS เป็นอัตโนมัติผ่านโค้ด หรือ Infrastructure as Code (IaC) บริการนี้ให้กำหนดโครงสร้างพื้นฐานในรูปเทมเพลต ทำให้ง่ายต่อการติดเวอร์ชัน ทดสอบ และทำซ้ำสภาพแวดล้อมระหว่าง development, staging และ production

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

เพื่อปิดท้ายชุดคำถาม DevOps ต่อไปนี้เป็นตารางสรุปบริการ AWS ที่ใช้ในด้านนี้และยูสเคส:

คำถามสัมภาษณ์ AWS สำหรับสถาปนิกโซลูชัน

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

บทบาทของ AWS solution architect คืออะไร?

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

แนวปฏิบัติด้านความปลอดภัยที่สำคัญสำหรับ AWS EC2 มีอะไรบ้าง?

แนวปฏิบัติด้านความปลอดภัยที่จำเป็นสำหรับ EC2 ได้แก่ การใช้ IAM เพื่อจัดการการเข้าถึง จำกัดการเข้าถึงเฉพาะโฮสต์ที่เชื่อถือได้ ลดสิทธิ์ให้เหลือเท่าที่จำเป็น ปิดการเข้าสู่ระบบด้วยรหัสผ่านสำหรับ AMI และใช้การยืนยันตัวตนหลายปัจจัยเพื่อเพิ่มความปลอดภัย

จะทำให้เกิดความซ้ำซ้อนข้ามรีเจียน (multi-region redundancy) ในสถาปัตยกรรม AWS ได้อย่างไร?

ในการออกแบบให้รองรับหลายรีเจียน ให้ดีพลอยทรัพยากรสำคัญอย่างอินสแตนซ์ EC2 ฐานข้อมูล RDS และบักเก็ต S3 ในหลาย AWS Region ใช้ Route 53 สำหรับการกำหนดเส้นทาง DNS แบบอิงภูมิศาสตร์ และ S3 Cross-Region Replication เพื่อสำรองข้อมูล ใช้การกำหนดค่าแบบ active-active หรือ active-passive ตามกลยุทธ์เฟลโอเวอร์ และมอนิเตอร์ประสิทธิภาพและการทำซ้ำด้วย CloudWatch และ AWS Global Accelerator

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

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

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

อธิบายวิธีเลือกใช้ระหว่าง Amazon RDS, Amazon DynamoDB และ Amazon Redshift สำหรับแอปพลิเคชันที่ขับเคลื่อนด้วยข้อมูล

การเลือกใช้ Amazon RDS, DynamoDB และ Redshift สำหรับแอปที่ขับเคลื่อนด้วยข้อมูลขึ้นกับความต้องการเฉพาะ:

• Amazon RDS เหมาะกับแอปที่ต้องใช้ฐานข้อมูลเชิงสัมพันธ์แบบดั้งเดิม รองรับ SQL มาตรฐาน ทรานแซกชัน และคิวรีที่ซับซ้อน
• Amazon DynamoDB เหมาะกับแอปที่ต้องการฐานข้อมูล NoSQL ที่สเกลได้สูงและให้ประสิทธิภาพเร็วและคาดการณ์ได้ทุกสเกล ดีสำหรับโมเดลข้อมูลยืดหยุ่นและพัฒนาเร็ว
• Amazon Redshift เหมาะกับงานวิเคราะห์ที่ต้องคิวรีซับซ้อนบนชุดข้อมูลขนาดใหญ่ ให้ประสิทธิภาพคิวรีสูงด้วยคอลัมน์นาร์สตอเรจและเทคโนโลยีดาต้าแวร์เฮาส์

พิจารณาเรื่องใดบ้างเมื่อย้ายแอปที่รันในองค์กรไปยัง AWS? ยกตัวอย่างประกอบ

AWS แนะนำให้คิดเรื่องการย้ายผ่านกรอบงาน "7 Rs": rehost (ยกและย้าย), replatform, repurchase, refactor, retire, retain และ relocate ตัวเลือกที่เหมาะสมขึ้นกับความซับซ้อนของแอปและระดับการเปลี่ยนแปลงที่ยอมรับได้ระหว่างการย้าย

ยกตัวอย่างการย้ายระบบ CRM ประเด็นสำคัญ:

• กลยุทธ์ ระบบ CRM ที่พัฒนาขึ้นเองมักเหมาะกับ replatform — ย้ายไปบริการจัดการอย่าง RDS และ EC2 โดยไม่ต้องเขียนใหม่ ส่วน CRM เชิงพาณิชย์ที่ถูกปรับแต่งหนัก ๆ อาจเหมาะกับ repurchase (เปลี่ยนไปใช้ SaaS ที่เทียบเท่า)
• การย้ายข้อมูล ใช้ AWS DMS เพื่อย้ายฐานข้อมูลด้วยดาวน์ไทม์น้อย และใช้ Direct Connect เพื่อคงการเชื่อมต่อเครือข่ายให้เสถียรระหว่างเปลี่ยนผ่าน
• การพึ่งพิง สำรวจสิ่งที่ CRM เชื่อมต่อ (อีเมล บิลลิง ซัพพอร์ต) และย้ายโมดูลที่ไม่วิกฤตก่อนเพื่อพิสูจน์แนวทาง
• ความปลอดภัยและการปฏิบัติตามกฎ ทำซ้ำการควบคุมการเข้าถึงด้วย IAM เข้ารหัสข้อมูลด้วย KMS และยืนยันว่าสอดคล้องกับข้อกำหนด (GDPR, HIPAA)
• ต้นทุน จำลองต้นทุนหลังย้ายด้วย AWS Pricing Calculator และวางแผนเปลี่ยนจาก capex เป็น opex

ข้อผิดพลาดที่พบบ่อยในการสัมภาษณ์คือรีบตอบว่า "ผม/ฉันจะใช้ EC2 และ RDS" โดยไม่พูดถึงกลยุทธ์ก่อน

อธิบายวิธีใช้บริการ AWS เพื่อสร้างสถาปัตยกรรมไมโครเซอร์วิส

การทำสถาปัตยกรรมไมโครเซอร์วิสคือการแยกซอฟต์แวร์ออกเป็นบริการย่อยอิสระที่สื่อสารกันผ่าน API แนวทางโดยสรุป:

• ใช้การพัฒนาแบบ Agile: เพื่อเร่งการพัฒนาและดีพลอยของไมโครเซอร์วิสแต่ละตัว
• ยึดแนวคิด API-First: พัฒนา API สำหรับการสื่อสารระหว่างเซอร์วิสตั้งแต่ต้นเพื่อให้ชัดเจนและสอดคล้อง
• ใช้แนวปฏิบัติ CI/CD: ทำการทดสอบและดีพลอยอัตโนมัติเพื่อเพิ่มความเร็วและความน่าเชื่อถือ
• ผนวกหลัก Twelve-Factor App: เพื่อสร้างบริการที่สเกลได้ ดูแลง่าย และดีพลอยบนคลาวด์อย่าง AWS ได้สะดวก
• เลือกแพตเทิร์นสถาปัตยกรรมที่เหมาะสม: เช่น ขับเคลื่อนด้วย API เหตุการณ์ หรือสตรีมมิง ตามความต้องการของแอปเพื่อเพิ่มประสิทธิภาพการสื่อสารและการไหลของข้อมูล
• ใช้ AWS สำหรับการดีพลอย: ใช้เทคโนโลยีคอนเทนเนอร์สำหรับไมโครเซอร์วิสที่สเกลได้ หรือเซิร์ฟเวอร์เลสเพื่อลดความซับซ้อนด้านปฏิบัติการและโฟกัสที่ลอจิกของแอป
• ใช้หลักการเซิร์ฟเวอร์เลส: เมื่อเหมาะสม เพื่อตัดภาระการจัดการอินฟราฯ สเกลอัตโนมัติ และจ่ายเท่าที่ใช้ เพื่อเพิ่มประสิทธิภาพและความคุ้มค่า
• ทำให้ระบบทนทาน: ออกแบบไมโครเซอร์วิสให้ทนทานต่อความผิดพลาด ใช้คุณสมบัติความพร้อมใช้งานของ AWS เพื่อคงบริการ
• ใส่ใจงานข้ามเซอร์วิส: มอนิเตอร์ ล็อก เทรซแบบกระจาย และความสอดคล้องของข้อมูล เพื่อคงสุขภาพและประสิทธิภาพของระบบ
• ทบทวนด้วย AWS Well-Architected Framework: ใช้เครื่องมือ Well-Architected เพื่อตรวจสถาปัตยกรรมตามแนวปฏิบัติที่ดีที่สุดของ AWS ให้มั่นใจเรื่องความเชื่อถือได้ ความปลอดภัย ประสิทธิภาพ และความคุ้มค่า

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

ความสัมพันธ์ระหว่าง AWS Glue และ AWS Lake Formation คืออะไร?

AWS Lake Formation สร้างต่อยอดจากโครงสร้างของ AWS Glue โดยรวมความสามารถ ETL คอนโซลควบคุม ดาต้าคาแทล็อก และสถาปัตยกรรมเซิร์ฟเวอร์เลสของ Glue เข้ามา ขณะที่ AWS Glue เน้นกระบวนการ ETL Lake Formation เพิ่มความสามารถในการสร้าง รักษาความปลอดภัย และจัดการดาต้าเลค เพื่อยกระดับฟังก์ชันของ Glue

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

จะเพิ่มประสิทธิภาพต้นทุน AWS สำหรับเว็บแอปที่มีทราฟฟิกสูงได้อย่างไร?

เพื่อเพิ่มประสิทธิภาพต้นทุนสำหรับแอปที่มีทราฟฟิกสูง เริ่มจากใช้ AWS Cost Explorer และ AWS Budgets เพื่อติดตามและจัดการการใช้จ่าย จากนั้นพิจารณากลยุทธ์เหล่านี้:

• ใช้ Reserved และ Spot Instances สำหรับเวิร์กโหลดที่คาดการณ์ได้และยืดหยุ่นตามลำดับ
• ออโตสเกล เพื่อปรับทรัพยากรตามดีมานด์ ลดต้นทุนช่วงทราฟฟิกต่ำ
• เพิ่มประสิทธิภาพการจัดเก็บ ด้วยนโยบายวงจรชีวิตของ Amazon S3 และ S3 Intelligent-Tiering เพื่อย้ายข้อมูลที่เข้าถึงไม่บ่อยไปยังคลาสที่คุ้มค่า
• ทำแคช ด้วย Amazon CloudFront และ Amazon ElastiCache เพื่อลดคำขอซ้ำไปแบ็กเอนด์ ประหยัดแบนด์วิดท์และคอมพิวต์

แนวทางนี้ทำให้แอปคุ้มค่า โดยไม่กระทบประสิทธิภาพหรือความพร้อมใช้งาน

เสาหลักสำคัญของ AWS Well-Architected Framework คืออะไร?

AWS Well-Architected Framework เป็นแนวทางเชิงโครงสร้างสำหรับการออกแบบสถาปัตยกรรม AWS ที่ปลอดภัย มีประสิทธิภาพ และยืดหยุ่น ประกอบด้วย 5 เสาหลักหลัก:

• Operational excellence: สนับสนุนการพัฒนาและปฏิบัติการผ่านการมอนิเตอร์ การตอบสนองต่อเหตุการณ์ และระบบอัตโนมัติ
• Security: ปกป้องข้อมูล ระบบ และทรัพย์สิน ด้วยการจัดการอัตลักษณ์ การเข้ารหัส และการตอบสนองต่อเหตุการณ์
• Reliability: สร้างระบบที่กู้คืนจากความล้มเหลวได้ สเกลทรัพยากรแบบไดนามิก และรับมือปัญหาเครือข่าย
• Performance efficiency: ส่งเสริมการใช้ทรัพยากรที่สเกลได้และเวิร์กโหลดที่ปรับให้เหมาะสม
• Cost optimization: จัดการต้นทุนด้วยการเลือกทรัพยากรที่เหมาะสมและใช้โมเดลราคา เช่น Reserved Instances

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

คำถามสัมภาษณ์ AWS สำหรับวิศวกรข้อมูล

สำหรับ วิศวกรข้อมูล ส่วนนี้เจาะลึกบริการ AWS สำหรับการจัดการข้อมูล ทั้งคลังข้อมูลและการประมวลผลแบบเรียลไทม์ สำรวจความเชี่ยวชาญที่จำเป็นในการสร้างไปป์ไลน์ข้อมูลที่สเกลได้ด้วย AWS

อธิบายความแตกต่างระหว่าง Amazon Redshift, RDS และ S3 และควรใช้เมื่อใด

• Amazon S3 เป็นบริการจัดเก็บวัตถุที่ให้สตอเรจที่สเกลได้และทนทานสำหรับข้อมูลจำนวนเท่าไรก็ได้ ใช้เก็บข้อมูลดิบที่ไม่มีโครงสร้าง เช่น ไฟล์ล็อก CSV รูปภาพ เป็นต้น
• Amazon Redshift เป็นคลังข้อมูลบนคลาวด์ที่ปรับให้เหมาะกับงานวิเคราะห์และ BI ผสานกับ S3 และโหลดข้อมูลจากที่เก็บเพื่อรันคิวรีซับซ้อนและสร้างรายงาน
• Amazon RDS ให้บริการฐานข้อมูลเชิงสัมพันธ์แบบจัดการ เช่น PostgreSQL, MySQL เป็นต้น ใช้ขับเคลื่อนแอปทรานแซกชันที่ต้องการฐานข้อมูลที่สอดคล้องตาม ACID พร้อมคุณสมบัติอย่างดัชนี ข้อจำกัดต่าง ๆ

ยกสถานการณ์ที่ควรใช้ Amazon Kinesis แทน AWS Lambda สำหรับการประมวลผลข้อมูล พร้อมปัจจัยที่ต้องพิจารณา

Kinesis ใช้จัดการข้อมูลสตรีมมิงปริมาณมาก และอนุญาตให้แอปผู้บริโภคอ่านและประมวลผลสตรีมได้

ปัจจัยสำคัญที่ควรพิจารณามีดังนี้:

• ปริมาณข้อมูล: Kinesis รองรับระดับเมกะไบต์ต่อวินาที เทียบกับข้อจำกัด Lambda ที่ 6MB ต่อการเรียก เหมาะกับสตรีมที่มีทราฟฟิกสูง
• การประมวลผลแบบสตรีมมิง: ผู้บริโภค Kinesis ประมวลผลข้อมูลอย่างต่อเนื่องแบบเรียลไทม์ เทียบกับ Lambda ที่เป็นแบตช์ ช่วยลดความหน่วง
• ความสามารถในการรีเพลย์: Kinesis เก็บข้อมูลตามช่วงเวลาที่กำหนด ทำให้รีเพลย์และประมวลผลใหม่ได้หากจำเป็น ขณะที่ Lambda ไม่เหมาะกับการรีเพลย์
• การรักษาลำดับ: ชาร์ดของ Kinesis ทำให้ประมวลผลเรคอร์ดที่เกี่ยวข้องตามลำดับได้ ขณะที่ Lambda อาจประมวลผลไม่เรียงลำดับ
• การสเกลและการประมวลผลขนาน: Kinesis สเกลด้วยการเพิ่มชาร์ดเพื่อตอบรับโหลด ขณะที่ Lambda อาจต้องมีการออร์เคสเทรต
• การผสานงาน: Kinesis ผสานกับบริการ AWS อื่น ๆ อย่าง Firehose, Redshift, EMR สำหรับงานวิเคราะห์ได้ดี

ดังนั้น สำหรับเคสสตรีมที่ปริมาณสูง ต่อเนื่อง มีลำดับ และรีเพลย์ได้ เช่น การวิเคราะห์แบบเรียลไทม์ Kinesis ให้การรองรับสตรีมมิงแบบเนทีฟมากกว่าแนวทางแบตช์ของ Lambda

หากต้องการเรียนรู้ข้อมูลสตรีมมิงเพิ่มเติม คอร์ส Streaming Data with AWS Kinesis and Lambda ของเราช่วยให้เรียนรู้การใช้เทคโนโลยีเหล่านี้เพื่อรับข้อมูลจากแหล่งนับล้านและวิเคราะห์แบบเรียลไทม์ ช่วยเตรียมตัวสำหรับคำถามสัมภาษณ์เกี่ยวกับ AWS Lambda ได้ดีขึ้น

ความแตกต่างหลักระหว่างการประมวลผลแบบแบตช์และแบบเรียลไทม์คืออะไร และจะเลือกใช้แนวทางใดเมื่อไรสำหรับโครงการวิศวกรรมข้อมูล?

การประมวลผลแบบแบตช์คือการรวบรวมข้อมูลในช่วงเวลาหนึ่งแล้วประมวลผลเป็นชุดใหญ่ เหมาะกับการวิเคราะห์ข้อมูลย้อนหลังที่ไม่เกิดบ่อย

การประมวลผลแบบสตรีมมิงเรียลไทม์เป็นการวิเคราะห์ข้อมูลอย่างต่อเนื่องขณะมาถึงเป็นส่วนย่อย ๆ ช่วยวิเคราะห์ข้อมูลใหม่ที่อัปเดตบ่อยได้

สำหรับโครงการวิศวกรรมข้อมูล เลือกสตรีมมิงเรียลไทม์เมื่อ:

• ต้องการอินไซต์ทันทีและรอให้กระบวนการแบตช์ทำงานไม่ได้ เช่น ตรวจจับการทุจริต
• ข้อมูลเปลี่ยนแปลงตลอดและต้องวิเคราะห์ให้ทัน เช่น มอนิเตอร์โซเชียลมีเดีย
• ต้องการความหน่วงต่ำ เช่น ระบบเทรดอัตโนมัติ

การประมวลผลแบบแบตช์เหมาะกว่าเมื่อ:

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

สรุปคือ เรียลไทม์เหมาะกับข้อมูลที่เปลี่ยนแปลงรวดเร็วและต้องวิเคราะห์ต่อเนื่อง ขณะที่แบตช์เหมาะกับข้อมูลที่พร้อมเป็นช่วง ๆ และต้องวิเคราะห์ย้อนหลัง

จะทำให้การวิวัฒน์สคีมาในไปป์ไลน์ข้อมูลบน AWS เป็นอัตโนมัติได้อย่างไร?

การวิวัฒน์สคีมาสามารถจัดการได้ด้วยคุณสมบัติ dynamic frame และการเดาสคีมาของ AWS Glue เมื่อใช้ร่วมกับ Glue Data Catalog จะติดตามการเปลี่ยนแปลงสคีมาได้อัตโนมัติ เพื่อหลีกเลี่ยงการทำให้กระบวนการปลายทางพัง ควรมีขั้นตอนตรวจสอบสคีมาด้วยเครื่องมืออย่าง AWS Deequ หรือผนวกลอจิกปรับแก้ลงในสคริปต์ ETL เพื่อบันทึกและแก้ความไม่ตรงกัน

จะจัดการ schema-on-read เทียบกับ schema-on-write ในดาต้าเลคของ AWS อย่างไร?

Schema-on-read มักใช้ในดาต้าเลคที่เก็บข้อมูลดิบกึ่งมีโครงสร้าง (เช่น ใน S3) และนำสคีมามาใช้เฉพาะตอนคิวรีด้วยเครื่องมืออย่าง Athena หรือ Redshift Spectrum แนวทางนี้ยืดหยุ่นต่อแหล่งข้อมูลที่หลากหลาย Schema-on-write ซึ่งมักใช้ใน RDS หรือ Redshift บังคับใช้โครงสร้างตั้งแต่ต้น เหมาะกับชุดข้อมูลทรานแซกชันหรือข้อมูลที่มีโครงสร้างซึ่งต้องการการตรวจสอบข้อมูลอย่างเข้มงวด

Operational data store คืออะไร และเสริมคลังข้อมูลอย่างไร?

Operational data store (ODS) คือฐานข้อมูลที่ออกแบบมาเพื่อสนับสนุนปฏิบัติการธุรกิจและการวิเคราะห์แบบเรียลไทม์ ทำหน้าที่เป็นแพลตฟอร์มกลางระหว่างระบบทรานแซกชันกับคลังข้อมูล

ขณะที่คลังข้อมูลมีข้อมูลคุณภาพสูงที่ปรับให้เหมาะกับ BI และรายงาน ODS มีข้อมูลปัจจุบันที่เน้นหัวเรื่อง ผสานจากหลายแหล่ง

คุณลักษณะสำคัญของ ODS ได้แก่:

• ให้ข้อมูลเรียลไทม์สำหรับติดตามปฏิบัติการและตัดสินใจ
• ผสานข้อมูลสดจากหลายแหล่ง
• ปรับให้เหมาะกับคิวรีและการวิเคราะห์ที่รวดเร็ว มากกว่าการเก็บระยะยาว
• ODS เก็บข้อมูลเชิงละเอียดระดับอะตอม เทียบกับข้อมูลแบบรวมในคลังข้อมูล

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

จะตั้งค่าดาต้าเลคบน AWS อย่างไร และใช้บริการใดบ้าง?

ในการสร้างดาต้าเลคบน AWS บริการแกนหลักคือ Amazon S3 เพื่อเก็บข้อมูลดิบ โครงสร้าง และไม่มีโครงสร้างอย่างสเกลได้และทนทาน ขั้นตอนและบริการที่เกี่ยวข้อง:

• เลเยอร์สตอเรจ: ใช้ Amazon S3 เก็บข้อมูลปริมาณมาก จัดระเบียบด้วยโครงสร้างโฟลเดอร์ตามประเภท แหล่งที่มา หรือความสดใหม่ของข้อมูล
• การทำดาต้าคาแทล็อก: ใช้ AWS Glue สร้างดาต้าคาแทล็อก เพื่อให้ง่ายต่อการค้นหาและคิวรีข้อมูลใน S3 ด้วยเมทาดาตา
• การแปลงข้อมูลและ ETL: ใช้ AWS Glue ETL เพื่อเตรียมและแปลงข้อมูลดิบให้พร้อมสำหรับการวิเคราะห์
• ความปลอดภัยและการควบคุมการเข้าถึง: ใช้ AWS IAM และ AWS Lake Formation เพื่อจัดการการเข้าถึง สิทธิ์ และการเข้ารหัสข้อมูล
• การวิเคราะห์และคิวรี: ใช้ Amazon Athena สำหรับคิวรีเฉพาะกิจ Amazon Redshift Spectrum สำหรับงานวิเคราะห์ และ Amazon QuickSight สำหรับการทำภาพข้อมูล

สถาปัตยกรรมนี้ให้ดาต้าเลคที่ยืดหยุ่นและสเกลได้ รองรับข้อมูลปริมาณมากทั้งแบบมีและไม่มีโครงสร้างเพื่อการวิเคราะห์

อธิบายคลาสจัดเก็บข้อมูลต่าง ๆ ใน Amazon S3 และการใช้งานที่เหมาะสม

Amazon S3 มีหลายคลาสจัดเก็บที่ปรับให้เหมาะกับยูสเคสและข้อกำหนดด้านต้นทุนต่างกัน ตารางต่อไปนี้สรุป:

การเข้าใจคลาสจัดเก็บของ S3 ช่วยเพิ่มประสิทธิภาพต้นทุนและเวลาการเข้าถึงตามความต้องการของข้อมูล

Amazon Bedrock คืออะไร และควรใช้เมื่อใด?

Amazon Bedrock เป็นบริการแบบจัดการเต็มรูปแบบที่ให้เข้าถึงโมเดลพื้นฐานจากผู้ให้บริการอย่าง Anthropic, Meta, Mistral และอื่น ๆ รวมถึงโมเดล Nova และ Titan ของ Amazon เอง ใช้ Bedrock เมื่อต้องการสร้างแอปเจเนอเรทีฟเอไอโดยไม่ต้องจัดการโครงสร้างพื้นฐานของโมเดลหรือไปป์ไลน์ไฟน์จูน

ยูสเคสทั่วไปได้แก่ แอป RAG ด้วย Bedrock Knowledge Bases การสร้างเอเจนต์เอไอด้วย Bedrock Agents และปรับแต่งโมเดลด้วยข้อมูลของตนผ่านการไฟน์จูนหรือการฝึกสอนต่อเนื่อง

Amazon Q คืออะไร และต่างจาก Bedrock อย่างไร?

Amazon Q เป็นผู้ช่วยเจเนอเรทีฟเอไอของ AWS มีทั้ง Q Developer (ผู้ช่วยโค้ดดิ้งใน IDE คอนโซล AWS และ CLI) และ Q Business (ผู้ช่วยแชตที่เชื่อมต่อกับแหล่งข้อมูลองค์กรอย่าง S3, Salesforce, Confluence, ServiceNow) ความแตกต่างหลักจาก Bedrock คือระดับการนามธรรม: Bedrock ให้ API โมเดลพื้นฐานดิบ ๆ เพื่อให้คุณสร้างแอปเอง ขณะที่ Q เป็นแอปที่สร้างสำเร็จอยู่ชั้นบน

คำถาม AWS เชิงสถานการณ์

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

ตารางต่อไปนี้สรุปสถานการณ์ที่มักถูกถามในการสัมภาษณ์ AWS พร้อมคำอธิบายและบริการที่อาจเป็นทางออก:

คำถามสัมภาษณ์ AWS ที่ไม่ใช่ด้านเทคนิค

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

ติดตามเทรนด์ AWS และเทคโนโลยีคลาวด์อย่างไร?

• สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการรู้ถึงความมุ่งมั่นในการเรียนรู้อย่างต่อเนื่อง และการรักษาความทันสมัยของทักษะ มองหาทรัพยากรหรือแนวปฏิบัติเฉพาะที่ใช้ติดตามข่าวสาร
• คำตอบตัวอย่าง: "ผม/ฉันติดตามผ่านบล็อกทางการของ AWS และเข้าร่วมฟอรัมชุมชนอย่าง AWS subreddit รวมถึงเข้าร่วมมีตอัปของผู้ใช้ AWS ในท้องถิ่นและสัมมนาออนไลน์ กิจกรรมเหล่านี้ช่วยให้ทราบฟีเจอร์ล่าสุดและแนวปฏิบัติที่ดีของ AWS"

เล่าเหตุการณ์ที่ต้องอธิบายแนวคิด AWS ที่ซับซ้อนแก่ผู้ไม่มีพื้นฐานเทคนิค คุณทำอย่างไร?

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

อะไรเป็นแรงจูงใจให้ทำงานในอุตสาหกรรมคลาวด์ โดยเฉพาะกับ AWS?

• สิ่งที่คาดหวังจากผู้สมัคร: ผู้สัมภาษณ์ต้องการประเมินแพสชันและแรงขับ มองหาแรงจูงใจที่สอดคล้องกับบทบาทและคุณค่าของบริษัท
• คำตอบตัวอย่าง: "สิ่งที่น่าตื่นเต้นเกี่ยวกับคลาวด์ โดยเฉพาะ AWS คือพลังในการขยายขนาดธุรกิจและขับเคลื่อนนวัตกรรม การพัฒนาบริการของ AWS อย่างต่อเนื่องทำให้ผม/ฉันมีแรงผลักดันในการแก้โจทย์ใหม่ ๆ และมีส่วนร่วมในโครงการที่มีผลกระทบ"

อธิบายโปรเจกต์ที่ท้าทายที่คุณดูแล และคุณทำให้สำเร็จได้อย่างไร

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

รับมือเส้นตายที่แน่นและหลายโปรเจกต์เรียกร้องความสนใจพร้อมกันอย่างไร?

• สิ่งที่คาดหวังจากผู้สมัคร: ทดสอบการบริหารเวลาและการจัดลำดับความสำคัญ สนใจวิธีจัดการความเครียดและภาระงาน
• คำตอบตัวอย่าง: "ผม/ฉันใช้ทั้งการจัดลำดับความสำคัญและการมอบหมายงาน ประเมินความเร่งด่วนและผลกระทบของแต่ละโปรเจกต์ จัดลำดับให้เหมาะสม และมอบหมายเมื่อเหมาะสม พร้อมสื่อสารความคืบหน้าและการปรับแผนกับผู้มีส่วนได้ส่วนเสียอย่างสม่ำเสมอ"

อะไรทำให้ AWS แตกต่างจากผู้ให้บริการคลาวด์รายอื่น?

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

คุณเรียนรู้เครื่องมือหรือบริการใหม่ ๆ ของ AWS อย่างไรเมื่อถูกเปิดตัว?

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

อธิบายวิธีสร้างสมดุลระหว่างความปลอดภัยและประสิทธิภาพเมื่อออกแบบโซลูชัน AWS

• สิ่งที่คาดหวังจากผู้สมัคร: ประเมินความสามารถในการคิดเชิงกลยุทธ์ด้านความปลอดภัยควบคู่ประสิทธิภาพ ต้องการเห็นว่าสามารถรักษาแนวปฏิบัติที่ดีด้านความปลอดภัยควบคู่ความมีประสิทธิผลในการปฏิบัติงานได้
• คำตอบตัวอย่าง: "ผม/ฉันเชื่อว่าความปลอดภัยและประสิทธิภาพไปด้วยกัน เมื่อออกแบบโซลูชัน AWS จะเริ่มจากแนวคิด security-first โดยใช้ IAM, การแยกเครือข่ายด้วย VPC และการเข้ารหัสข้อมูล สำหรับประสิทธิภาพ จะปรับคอนฟิกให้เหมาะสมและเลือกบริการที่สเกลได้ เช่น AWS Lambda สำหรับงานคอมพิวต์หนัก แนวทางของผม/ฉันคือสร้างสถาปัตยกรรมที่ปลอดภัยแต่ยังตอบสนองและคุ้มค่า"

สรุป

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

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