บริการหลักของ AWS

EC2 คือ Amazon Elastic Compute Cloud ให้บริการคอมพิวติ้งที่ปรับขนาดได้ นั่นคือเซิร์ฟเวอร์เสมือน ส่วน S3 คือ Amazon Simple Storage Service ใช้จัดเก็บข้อมูลไม่จำกัดปริมาณในรูปแบบอ็อบเจ็กต์ การสลับบทบาททั้งสองนี้เป็นความสับสนที่พบบ่อยมาแต่ไหนแต่ไร จึงควรจำจากตัวสะกดของชื่อเพื่อนึกถึงบทบาทได้ การรันโค้ดของฟังก์ชันคือ Lambda และการแชร์ไฟล์คือ EFS

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

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

Fargate เป็นเอนจินคอมพิวติ้งแบบเซิร์ฟเวอร์เลสที่จ่ายตามการใช้งานสำหรับคอนเทนเนอร์ ไม่ต้องจัดสรร ตั้งค่า หรือปรับขนาดเซิร์ฟเวอร์หรือคลัสเตอร์ และใช้เป็นประเภทการรัน (Launch Type) ของ ECS หรือ EKS การจัดการ Kubernetes แบบจัดการให้คือ EKS การเลือกประเภทและจำนวนอินสแตนซ์เองคือประเภทการรันแบบ EC2 ส่วนการกำหนดขั้นตอนเป็นเวิร์กโฟลว์คือ Step Functions

ตัวเลือกความจุพื้นฐานของ ECS มี 2 แบบ คือ Fargate ซึ่งเป็นเซิร์ฟเวอร์เลสให้ AWS จัดการฐานให้ และ EC2 ซึ่งผู้ใช้เลือกประเภทและจำนวนอินสแตนซ์เพื่อจัดการเอง นอกจากนี้ยังมี ECS Managed Instances และ ECS Anywhere สำหรับใช้งานแบบออนพรีมิส ไม่ว่าจะเลือกแบบใด ผู้ที่จัดการการจัดวางและปรับขนาดคอนเทนเนอร์คือ ECS เหมือนกัน สิ่งที่เปลี่ยนไปมีเพียงว่าใครเป็นผู้ดูแลฐานเท่านั้น

EKS คือ Amazon Elastic Kubernetes Service เป็นบริการแบบจัดการให้ที่ทำให้สามารถรัน Kubernetes บน AWS ได้โดยไม่ต้องติดตั้งและดำเนินการคลัสเตอร์ Kubernetes ด้วยตนเอง และได้รับการรับรองความสอดคล้องกับ Kubernetes การทำให้การดำเนินการฐานข้อมูลเป็นอัตโนมัติคือ RDS การกระจายเนื้อหาจากจุดใกล้เคียงคือ CloudFront ส่วนการกระจายทราฟฟิกคือ Elastic Load Balancing

Lambda สามารถรันโค้ดได้โดยไม่ต้องจัดการเซิร์ฟเวอร์ และคิดค่าบริการเฉพาะตามเวลาคอมพิวติ้งที่ใช้ไป โดยไม่มีค่าใช้จ่ายในช่วงที่ไม่ได้ทำงาน ดังนั้นสำหรับงานที่ถูกเรียกใช้อย่างห่าง ๆ Lambda จึงได้เปรียบเพราะไม่มีค่าใช้จ่ายในช่วงเวลาที่รอ โครงสร้างที่รันคลัสเตอร์ EC2 หรือ EKS ตลอดเวลาจะมีค่าใช้จ่ายต่อเนื่องแม้ในช่วงเวลาส่วนใหญ่ที่ไม่มีการประมวลผลใด ๆ

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

ECS คือ Amazon Elastic Container Service ซึ่งเป็นบริการจัดการคอนเทนเนอร์แบบจัดการให้เต็มรูปแบบ ช่วยให้การดีพลอย จัดการ และปรับขนาดแอปพลิเคชันที่ทำเป็นคอนเทนเนอร์ทำได้ง่ายขึ้น การให้บริการคลัสเตอร์ที่สอดคล้องกับ Kubernetes คือ EKS การรันอินสแตนซ์ของเซิร์ฟเวอร์เสมือนคือ EC2 และการรันโค้ดตามเหตุการณ์คือ Lambda ทั้ง ECS และ EKS ต่างจัดการคอนเทนเนอร์เหมือนกัน แต่แตกต่างกันตรงที่ใช้ Kubernetes หรือไม่

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

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

S3 คือ Amazon Simple Storage Service เป็นสตอเรจแบบอ็อบเจ็กต์ที่มีความสามารถขยายขนาดและความพร้อมใช้งานสูง สามารถจัดเก็บและปกป้องข้อมูลได้ไม่จำกัดปริมาณ สตอเรจแบบบล็อกคือ EBS ระบบไฟล์แชร์สำหรับ Linux คือ EFS และแคชในหน่วยความจำคือ ElastiCache ความแตกต่างของวิธีจัดเก็บทั้ง 3 แบบ คือ อ็อบเจ็กต์ บล็อก และไฟล์ นับเป็นจุดเริ่มต้นเมื่อต้องเลือกสตอเรจของ AWS

EFS เป็นสตอเรจไฟล์ที่ขนาดขยายหรือหดอัตโนมัติตามการเพิ่มลดของไฟล์ และรองรับการเข้าถึงพร้อมกันจากอินสแตนซ์ EC2 นับพันเครื่อง จึงเหมาะกับการใช้งานที่ต้องการเมานต์ไดเรกทอรีเดียวกันจากอินสแตนซ์จำนวนมากพร้อมกัน EBS เป็นสตอเรจแบบบล็อกภายในโซนความพร้อมใช้งาน โดยหลักการจะแนบกับอินสแตนซ์เดียว ทำให้พื้นที่ของแต่ละเครื่องแยกจากกัน Glacier Deep Archive เป็นคลาสสำหรับอาร์ไคฟ์ที่ต้องใช้เวลาในการดึงข้อมูล ส่วน ElastiCache ไม่ใช่ระบบไฟล์ แต่เป็นแคชในหน่วยความจำ

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

S3 Glacier เป็นกลุ่มคลาสสตอเรจสำหรับอาร์ไคฟ์ ประกอบด้วย S3 Glacier Instant Retrieval สำหรับข้อมูลที่ต้องการดึงได้ทันที S3 Glacier Flexible Retrieval สำหรับข้อมูลระยะยาวที่แทบไม่ถูกเข้าถึง และ S3 Glacier Deep Archive ที่ใช้เวลาหลายชั่วโมงในการดึงข้อมูลแต่มีต้นทุนต่ำที่สุด เป็นการออกแบบให้เลือกคลาสตามความสมดุลระหว่างความเร็วในการดึงข้อมูลกับค่าใช้จ่าย ไม่ได้มีเวลาดึงข้อมูลที่เท่ากันทุกคลาส ไม่มีข้อจำกัดว่าต้องจัดเก็บเฉพาะข้อมูลบางประเภท และไม่ได้เชื่อมต่อในลักษณะสตอเรจแบบบล็อก

S3 เป็นสตอเรจแบบอ็อบเจ็กต์ EBS เป็นสตอเรจแบบบล็อกที่เชื่อมต่อกับ EC2 และ EFS เป็นสตอเรจไฟล์สำหรับเวิร์กโหลด Linux หากจัดระเบียบความเข้าใจว่าอ็อบเจ็กต์คือสิ่งที่นำเข้าออกทั้งก้อนผ่าน API บล็อกคือสิ่งที่ OS มองเห็นเป็นดิสก์ และไฟล์คือสิ่งที่เมานต์และแชร์จากหลายโฮสต์ได้ ก็จะเลือกได้ไม่หลงเมื่อพิจารณาจากความต้องการ

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

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

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

S3 Glacier Deep Archive จัดเก็บข้อมูลที่แทบไม่ถูกเข้าถึงด้วยต้นทุนต่ำที่สุด โดยใช้เวลาหลายชั่วโมงในการดึงข้อมูล ซึ่งตรงกับเงื่อนไขนี้ EBS และ EFS ถูกออกแบบมาเพื่อรักษาความเร็วในการดึงข้อมูล จึงมักมีต้นทุนสูงเกินไปสำหรับข้อมูลที่พักตัวในระยะยาว ElastiCache เป็นแคชในหน่วยความจำ ไม่ใช่กลไกสำหรับจัดเก็บระยะยาวตั้งแต่แรก การกำหนดก่อนว่ายอมรอได้นานเท่าใดคือแนวทางในการเลือกคลาส

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

Aurora เป็นส่วนหนึ่งของ Amazon RDS ซึ่งเป็นบริการฐานข้อมูลแบบจัดการให้ โดยดำเนินการจัดสรร ติดตั้งแพตช์ สำรองข้อมูล กู้คืน และตรวจจับความล้มเหลว ผ่านคอนโซล CLI และ API เดียวกัน ความแตกต่างอยู่ที่หน่วยการจัดการ กล่าวคือ RDS มาตรฐานจัดการแต่ละอินสแตนซ์ฐานข้อมูล ในขณะที่ Aurora จัดการทั้งคลัสเตอร์ของเซิร์ฟเวอร์ฐานข้อมูลที่ซิงค์กันด้วยการจำลองข้อมูล Aurora เป็นฐานข้อมูลเชิงสัมพันธ์ที่เข้ากันได้กับ MySQL และ PostgreSQL ไม่ใช่ฐานข้อมูลแบบคีย์-แวลู

DynamoDB เป็นฐานข้อมูล NoSQL แบบคีย์-แวลูและเอกสาร ที่ให้ประสิทธิภาพระดับหน่วยมิลลิวินาทีตัวเดียวในทุกขนาด เป็นฐานข้อมูลแบบจัดการให้เต็มรูปแบบและรองรับหลายภูมิภาค ดาต้าเวอร์เฮาส์คือ Redshift ฐานข้อมูลเชิงสัมพันธ์ที่เข้ากันได้กับ MySQL และ PostgreSQL คือ Aurora ส่วนการอ่านเขียนบนหน่วยความจำคือ ElastiCache

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

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

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

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

DynamoDB เป็นฐานข้อมูล NoSQL แบบคีย์-แวลูและเอกสาร และทาง AWS ระบุไว้อย่างเป็นทางการว่าให้ประสิทธิภาพระดับหน่วยมิลลิวินาทีตัวเดียวในทุกขนาด Redshift เป็นดาต้าเวอร์เฮาส์ที่เหมาะกับการสรุปรวมและวิเคราะห์ข้อมูลปริมาณมาก RDS เป็นบริการที่ดูแลการอ่านเขียนในรูปแบบเชิงสัมพันธ์ ส่วน EFS เป็นสตอเรจที่ดูแลการแชร์ไฟล์ ซึ่งไม่มีข้อใดมุ่งเน้นเงื่อนไขนี้เป็นอันดับแรก

RDS คือ Amazon Relational Database Service เป็นบริการแบบจัดการให้ที่ทำให้การติดตั้ง ดำเนินการ และปรับขนาดฐานข้อมูลเชิงสัมพันธ์บนคลาวด์ทำได้ง่ายขึ้น การจัดเก็บเป็นคู่คีย์และแวลูคือ DynamoDB แคชในหน่วยความจำเพื่อเร่งการอ่านคือ ElastiCache ส่วนดาต้าเวอร์เฮาส์ที่นำเข้าและสรุปรวมข้อมูลปริมาณมากคือ Redshift ทั้งนี้ Aurora เป็นเอนจินที่ให้บริการในฐานะส่วนหนึ่งของ RDS

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

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

SQS มีคิวมาตรฐานและคิว FIFO คิวมาตรฐานเป็นแบบส่งอย่างน้อยหนึ่งครั้ง (at-least-once) จึงอาจมีข้อความเดียวกันมาถึงหลายครั้ง ส่วนคิว FIFO มีการรับประกันการประมวลผลเพียงครั้งเดียว (exactly-once) และรักษาลำดับ ทำให้ข้อความถูกส่งตามลำดับและประมวลผลเพียงครั้งเดียว สำหรับเวิร์กโฟลว์ที่สำคัญเรื่องลำดับหรือการป้องกันการสูญหาย จะเลือกใช้คิว FIFO

SNS ผลักส่งข้อความที่ส่งไปยังทอปิกให้กับผู้สมัครรับข้อมูลหลายรายพร้อมกัน และสามารถระบุคิว SQS เป็นผู้สมัครรับข้อมูลได้ รูปแบบที่ส่งจากทอปิก SNS นี้ไปยังคิว SQS หลายคิวคือรูปแบบ Fan-out ที่ทางการระบุไว้เป็นแบบมาตรฐาน คิวเป็นฝั่งผู้รับไม่ใช่ต้นทางของการส่ง จึงไม่มีทิศทางที่คิวจะไปอ่านทอปิก

ประเภทของผู้สมัครรับข้อมูลของ SNS แบ่งเป็น A2A ซึ่งหมายถึงระหว่างแอปด้วยกัน เช่น SQS, Lambda, HTTP(S), Data Firehose และ A2P ซึ่งหมายถึงถึงตัวบุคคล เช่น อีเมล การพุชไปยังมือถือ และ SMS ไม่ได้จำกัดอยู่เพียงฝั่งใดฝั่งหนึ่ง และไม่ใช่กลไกที่ระบุปลายทางได้เฉพาะอินสแตนซ์ EC2 ความกว้างขวางนี้เองที่ทำให้ SNS ถูกใช้ทั้งการแจ้งเตือนถึงบุคคลและการเชื่อมต่อระหว่างแอป

Step Functions เป็นบริการที่ทำให้สามารถสร้างเวิร์กโฟลว์หรือสเตทแมชชีนได้ ช่วยให้สร้างแอปพลิเคชันแบบกระจาย ทำให้กระบวนการเป็นอัตโนมัติ ประสานงานไมโครเซอร์วิส และสร้างไปป์ไลน์ข้อมูลหรือแมชชีนเลิร์นนิงได้ แต่ละขั้นตอนเรียกว่า state และอินสแตนซ์ที่กำลังรันเรียกว่า execution การกระจายทราฟฟิกคือ Elastic Load Balancing การเก็บอ็อบเจ็กต์คือ S3 ส่วนแคชคู่คีย์และแวลูในหน่วยความจำคือ ElastiCache

API Gateway เป็นบริการที่สร้าง เผยแพร่ ดูแลรักษา ติดตาม และปกป้อง API แบบ REST, HTTP, WebSocket ได้ในทุกขนาด ทำหน้าที่เป็นประตูหน้าสำหรับการเข้าถึงแบ็กเอนด์ เช่น เวิร์กโหลดบน EC2, Lambda หรือเว็บแอปพลิเคชันใด ๆ การรันกระบวนการเองเป็นหน้าที่ของฝั่งแบ็กเอนด์ การใช้กฎการปกป้องร่วมกันหลายบัญชีคือ AWS Firewall Manager ส่วนการแคชที่ Edge คือบทบาทของ CloudFront

EventBridge เป็นบริการเซิร์ฟเวอร์เลสที่เชื่อมต่อคอมโพเนนต์ของแอปพลิเคชันเข้าด้วยกันโดยใช้อีเวนต์ ทำหน้าที่รับ กรอง แปลง และกระจายอีเวนต์ อีเวนต์บัสคือเราเตอร์ที่กระจายอีเวนต์จากแหล่งจำนวนมากไปยังเป้าหมายจำนวนมาก คิวคือ SQS สเตทแมชชีนคือ Step Functions ส่วนประตูหน้าคือ API Gateway

EventBridge Scheduler เป็นกลไกที่จัดการการรันตามกำหนดเวลาและการรันแบบครั้งเดียวด้วยนิพจน์ cron หรือ rate จึงจัดการเรื่องการรันตามเวลาที่ตั้งไว้ SQS เป็นคิวที่เก็บข้อความให้ผู้รับมาดึงออก SNS เป็นแบบพับ-ซับที่ส่งไปยังผู้สมัครรับข้อมูล และ API Gateway เป็นบริการที่เผยแพร่และส่งต่อ API ซึ่งทั้งหมดนี้ไม่ใช่กลไกที่มุ่งเน้นการรันตามเวลา

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

SNS ผลักส่งข้อความที่ส่งไปยังทอปิกให้กับผู้สมัครรับข้อมูลหลายรายพร้อมกัน และสามารถระบุคิว SQS เป็นผู้สมัครรับข้อมูลได้ ดังนั้นการส่งเหตุการณ์ 1 เหตุการณ์ไปยัง 3 กระบวนการจึงใช้รูปแบบ Fan-out ด้วยทอปิก SNS และคิว SQS หลายคิว หากใช้คิวเดียวร่วมกันทั้ง 3 กระบวนการ โดยปกติเมื่อฝ่ายใดฝ่ายหนึ่งดึงออกไป ฝ่ายที่เหลือก็จะไม่ได้รับข้อความนั้นอีก โครงสร้างที่ให้ต้นทางส่ง 3 ครั้ง หรือให้ผู้ที่รับไปส่งต่อ จะต้องแก้ไขฝั่งผู้ส่งทุกครั้งที่ปลายทางเพิ่มขึ้น จึงไม่ใช่การเชื่อมต่อแบบหลวม