คำถามที่พบบ่อยเกี่ยวกับ Amazon EventBridge

ถาม: Amazon EventBridge คืออะไร

Amazon EventBridge คือบริการที่มอบการเข้าถึงการเปลี่ยนแปลงของข้อมูลในบริการของ AWS และแอปพลิเคชันของคุณเอง รวมถึงแอปพลิเคชัน Software as a Service (SaaS) ได้แบบเรียลไทม์โดยไม่ต้องเขียนโค้ด

หากต้องการเริ่มต้น คุณสามารถเลือกแหล่งที่มาของเหตุการณ์บนคอนโซล EventBridge จากนั้น คุณสามารถเลือกเป้าหมายจากบริการของ AWS รวมถึง AWS Lambda, Amazon Simple Notification Service (SNS) และ Amazon Kinesis Data Firehose โดย EventBridge จะส่งเหตุการณ์โดยอัตโนมัติในเวลาแบบกึ่งเรียลไทม์

ถาม: ฉันจะเริ่มต้นใช้งาน EventBridge ได้อย่างไร

หากต้องการเริ่มใช้ Amazon EventBridge โปรดทําตาม 6 ขั้นตอนด้านล่างนี้

1. ลงชื่อเข้าใช้บัญชี AWS ของคุณ
2. ไปที่คอนโซล EventBridge
3. เลือกแหล่งที่มาของเหตุการณ์จากรายการแอปพลิเคชัน SaaS ของพาร์ทเนอร์และบริการของ AWS หากคุณกำลังใช้แอปพลิเคชันของพาร์ทเนอร์อยู่ โปรดตรวจสอบให้แน่ใจว่าคุณได้กำหนดค่าบัญชี SaaS ให้ปล่อยเหตุการณ์และยอมรับแอปพลิเคชันนั้นในแหล่งเหตุการณ์ที่มีให้ของคอนโซล EventBridge เอาไว้แล้ว
   
4. EventBridge จะสร้าง Event Bus ให้คุณโดยอัตโนมัติซึ่งเหตุการณ์ต่างๆ จะถูกจัดเส้นทางไปยังบัสนี้ นอกจากนี้ คุณสามารถใช้ AWS SDK เพื่อติดตั้งแอปพลิเคชันของคุณให้เริ่มปล่อยเหตุการณ์ไปยัง Event Bus ของคุณ
   
5. อีกทั้งคุณยังสามารถกำหนดค่ากฎการกรองและแนบเป้าหมายสำหรับเหตุการณ์ของคุณได้ ตัวอย่างเช่น อาจจะเป็นฟังก์ชัน Lambda
   
6. EventBridge จะนำเข้า กรอง และส่งเหตุการณ์ไปยังเป้าหมายที่กำหนดค่าไว้โดยอัตโนมัติด้วยวิธีที่ปลอดภัยและพร้อมใช้งานสูง
   

ถาม: ฉันสามารถเผยแพร่เหตุการณ์ของฉันไปยัง EventBridge ได้หรือไม่

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

ถาม: เหตุการณ์อยู่ในรูปแบบใด

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

ตัวอย่างเช่น เมื่อกลุ่ม Auto Scaling ของ Amazon Elastic Compute Cloud (EC2) สร้างอินสแตนซ์ Amazon EC2 ใหม่ กลุ่มนี้จะปล่อยเหตุการณ์ที่มีแหล่งข้อมูล คือ “aws.autoscaling” และรายละเอียด “สร้างอินสแตนซ์ EC2 เรียบร้อยแล้ว”

ถาม: ฉันจะกรองเหตุการณ์ที่ส่งไปยังเป้าหมายได้อย่างไร

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

กฎสามารถปรับแต่งเหตุการณ์ก่อนที่จะถูกส่งไปยังเป้าหมายได้โดยการส่งเฉพาะบางส่วนหรือโดยการเขียนทับด้วยค่าคงที่ สำหรับกรณีตามตัวอย่างในคำถามก่อนหน้านี้ คุณจะสามารถสร้างกฎเหตุการณ์ที่ตรงกันบนแหล่งข้อมูล: “aws.autoscaling” และรายละเอียด: “สร้าง EC2 instance เรียบร้อยแล้ว” เพื่อให้รับการแจ้งทุกครั้งที่กลุ่ม Auto Scaling สร้างอินสแตนซ์ EC2 สำเร็จ

ถาม: ฉันจะเข้าถึง EventBridge อย่างปลอดภัยได้อย่างไร

EventBridge ผสานรวมกับ AWS Identity and Access Management (IAM) เพื่อให้คุณระบุได้ว่าผู้ใช้ในบัญชี AWS ของคุณสามารถดำเนินการใดได้บ้าง ตัวอย่างเช่น คุณสามารถสร้างนโยบาย IAM ที่ให้สิทธิ์เฉพาะผู้ใช้งานบางคนในองค์กรของคุณในการสร้าง Event Bus หรือแนบเป้าหมายเหตุการณ์ได้

ถาม: บริการใดของ AWS ที่ได้รับการผสานรวมเป็นแหล่งเหตุการณ์สำหรับ Amazon EventBridge

มีบริการของ AWS กว่า 90 รายการที่พร้อมใช้งานเป็นแหล่งเหตุการณ์สำหรับ EventBridge ซึ่งรวมถึง AWS Lambda, Amazon Kinesis, AWS Fargate และAmazon Simple Storage Service (S3) ดูรายการที่แสดงการผสานรวมบริการของ AWS ทั้งหมดได้ที่เอกสารประกอบ EventBridge

ถาม: บริการใดของ AWS ที่ได้รับการผสานเป็นเป้าหมายเหตุการณ์สำหรับ EventBridge

มีบริการของ AWS กว่า 15 รายการที่พร้อมใช้งานเป็นเป้าหมายเหตุการณ์สำหรับ EventBridge ซึ่งรวมถึง Lambda, Amazon Simple Queue Service (SQS), Amazon SNS, Amazon Kinesis Streams และ Kinesis Data Firehose ดูรายการที่แสดงการผสานรวมบริการของ AWS ทั้งหมดได้ที่เอกสารประกอบ EventBridge

ถาม: การเก็บถาวรและการเล่นเหตุการณ์ซ้ำของ EventBridge คืออะไร

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

ถาม: API Destination ของ EventBridge คืออะไร

API Destination ช่วยให้นักพัฒนาสามารถส่งเหตุการณ์กลับไปยังแอปพลิเคชันภายในองค์กรหรือแอปพลิเคชัน SaaS ต่างๆ ได้ด้วยความสามารถในการควบคุมอัตราการโอนถ่ายข้อมูลและการตรวจสอบสิทธิ์ คุณสามารถกำหนดค่ากฎได้ด้วยการเปลี่ยนอินพุตที่จะแมปรูปแบบเหตุการณ์เป็นรูปแบบบริการการรับ และ EventBridge จะดูแลการรักษาความปลอดภัยและการส่งมอบ

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

ถาม: การเชื่อมต่อสำหรับ API Destination คืออะไร ฉันจะตั้งค่า API Destination ได้อย่างไร

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

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

ถาม: ขีดจำกัดของบริการคืออะไร

EventBridge มีโควตาเริ่มต้นสำหรับอัตราที่คุณสามารถเผยแพร่เหตุการณ์ได้ จำนวนกฎที่สามารถสร้างได้บน Event Bus และอัตราที่สามารถเรียกดำเนินการเป้าหมายได้ โปรดดูรายการโควตาทั้งหมดและวิธีเพิ่มโควตาที่หน้าโควต้าบริการ

ถาม: เวลาแฝงระหว่างการส่งและการรับเหตุการณ์จะอยู่ที่เท่าไร

เวลาแฝงทั่วไปจะอยู่ที่ประมาณครึ่งวินาที โปรดทราบว่าค่านี้อาจแตกต่างกันไป

ถาม: Amazon EventBridge รองรับการติดแท็กทรัพยากรหรือไม่

รองรับ คุณสามารถแท็กกฎและ Event Bus ได้

ถาม: EventBridge จะมีอัตราการโอนถ่ายข้อมูลอยู่ที่เท่าใด

โควตา EventBridge เริ่มต้นสามารถเพิ่มขึ้นเพื่อประมวลผลเหตุการณ์หลายแสนรายการต่อวินาทีได้ ขีดจำกัดอัตราการโอนถ่ายข้อมูลของ Event Bus จะระบุอยู่ในหน้าโควตาบริการของ AWS หากคุณจำเป็นต้องใช้อัตราการโอนถ่ายข้อมูลที่สูงกว่านี้ โปรดขอเพิ่มขีดจำกัดบริการผ่านทาง AWS Support Center โดยเลือก “สร้างกรณี” แล้วเลือก “เพิ่มขีดจำกัดบริการ”

ถาม: EventBridge มีข้อตกลงระดับการให้บริการหรือไม่

มี AWS ใช้ความพยายามที่สมเหตุสมผลในเชิงพาณิชย์เพื่อให้ EventBridge มีช่วงเวลาให้บริการเป็นเปอร์เซ็นต์ต่อเดือนอย่างน้อย 99.99% ในแต่ละ AWS Region ในระหว่างรอบการเรียกเก็บเงินรายเดือน ดูรายละเอียดได้ใน ข้อตกลงระดับการให้บริการ EventBridge ฉบับเต็ม

ถาม: สคีมาคืออะไร

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

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

ถาม: รีจิสทรีของสคีมาคืออะไร

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

ถาม: คุณสมบัติการสำรวจสคีมาคืออะไร

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

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

ถาม: ฉันสามารถค้นหาสคีมาจากเหตุการณ์ที่ส่งข้ามบัญชีอื่นได้หรือไม่

ได้ ภายในการค้นหาสคีมา คุณสามารถค้นหาเหตุการณ์ต่างๆ ข้ามบัญชีได้ เพื่อให้คุณสามารถมองเห็นสคีมาของเหตุการณ์ที่เผยแพร่ไปยัง Event Bus ได้อย่างครบถ้วน

ถาม: รีจิสทรีของสคีมามีค่าใช้จ่ายเท่าใด

การใช้รีจิสทรีของสคีมาไม่มีค่าใช้จ่าย แต่มีค่าใช้จ่ายต่อเหตุการณ์ที่นำเข้าเมื่อคุณเปิดใช้การสำรวจสคีมา

การสำรวจสคีมามี Free Tier จำนวน 5 ล้านเหตุการณ์ที่นำเข้าต่อเดือน ซึ่งครอบคลุมการใช้งานด้านการพัฒนาส่วนใหญ่ โดยมีค่าธรรมเนียมอยู่ที่ 0.10 USD ต่อหนึ่งล้านเหตุการณ์ที่ได้มาสำหรับการใช้งานเพิ่มเติมนอกเหนือจาก Free Tier สำหรับข้อมูลเพิ่มเติมเกี่ยวกับราคา ให้ดูที่หน้าราคา EventBridge

ถาม: รีจิสทรีของสคีมาลดจำนวนของโค้ดที่ฉันจำเป็นต้องเขียนได้อย่างไร

รีจิสทรีของสคีมาช่วยลดจํานวนโค้ดได้ โดยช่วยให้คุณสามารถทําสิ่งต่อไปนี้

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

ถาม: ทำไมฉันถึงควรใช้รีจิสทรีของสคีมา

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

ถาม: IDE ใดบ้างที่รีจิสทรีของสคีมารองรับ

รีจิสทรีของสคีมามีพร้อมให้บริการผ่านชุดเครื่องมือของ AWS สำหรับ JetBrains (IntelliJ IDEA, PyCharm, WebStorm, Rider) และ Visual Studio Code รวมถึงในคอนโซล EventBridge และ API เรียนรู้เพิ่มเติมเกี่ยวกับการใช้รีจิสทรีของสคีมาสำหรับ EventBridge ภายใน IDE ของคุณ

ถาม: ฉันสามารถใช้สคีมากับ Serverless Application Model (SAM) ของ AWS ได้หรือไม่

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

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

ปลั๊กอินชุดเครื่องมือ AWS สำหรับ Jetbrains (Intellij, PyCharm, Webstorm, Rider) และ AWS Toolkit for Visual Studio Code ยังมีฟังก์ชันการทำงานเพื่อสร้างแอปพลิเคชันแบบไม่ต้องใช้เซิร์ฟเวอร์จากเทมเพลตนี้ได้โดยตรงจาก IDE เหล่านี้ โดยมีสคีมาเป็นทริกเกอร์

ถาม: ฉันสามารถใช้ภาษาใดในการสร้างโค้ดจากสคีมาของฉัน

ใน EventBridge คุณสามารถสร้างโค้ดได้ในภาษา Java (8+), Python (3.6+), TypeScript (3.0+) และ Go (1+)

ถาม: AWS Region ใดที่มีรีจิสทรีของสคีมา

รีจิสทรีของสคีมา EventBridge พร้อมใช้งานในรีเจี้ยนต่อไปนี้

• สหรัฐอเมริกาฝั่งตะวันออก (โอไฮโอและเวอร์จิเนียเหนือ)
• สหรัฐอเมริกาฝั่งตะวันตก (แคลิฟอร์เนียเหนือและออริกอน)
• เอเชียแปซิฟิก (ฮ่องกง มุมไบ โซล สิงคโปร์ ซิดนีย์ และโตเกียว)
• แคนาดา (ภาคกลาง)
• ยุโรป (แฟรงเฟิร์ต ไอร์แลนด์ ลอนดอน ปารีส และสตอกโฮล์ม)
• อเมริกาใต้ (เซาเปาลู)
  

ถาม: Amazon EventBridge Pipes คืออะไร

EventBridge Pipes มอบวิธีในการสร้างการผสานรวมแบบจุดต่อจุดระหว่าง Event Producer และ Event Consumer ที่ง่ายดายกว่า มีความสอดคล้องกัน และคุ้มค่า การสร้าง Pipe ทำได้ง่ายดาย เพียงแค่เลือกต้นทางและเป้าหมายที่มีความสามารถในการปรับแต่งชุดงาน ตำแหน่งเริ่มต้น การทำงานพร้อมกัน และอื่นๆ ขั้นตอนการกรองที่เป็นทางเลือกจะอนุญาตให้เฉพาะเหตุการณ์ต้นทางที่เจาะจงเท่านั้นที่สามารถไหลเข้าสู่ Pipe ได้ และสามารถใช้ขั้นตอนการเพิ่มคุณค่าที่เป็นทางเลือกโดยใช้ AWS Lambda, AWS Step Functions, API Destinations หรือ เกตเวย์ของ Amazon API เพื่อเพิ่มประสิทธิภาพหรือแปลงเหตุการณ์ก่อนที่จะไปถึงเป้าหมาย ด้วยการลบความจำเป็นในการเขียนการจัดการและปรับขนาดรหัสการรวมที่ไม่แตกต่างกัน EventBridge Pipes จะช่วยให้คุณสามารถใช้เวลาสร้างแอปพลิเคชันแทนที่จะเชื่อมต่อ

ถาม: ฉันจะเริ่มต้นใช้งาน EventBridge Pipes ได้อย่างไร

คุณสามารถเริ่มต้นได้โดยไปที่คอนโซล EventBridge เลือกแท็บ Pipes และเลือกสร้าง Pipe จากตรงนั้น คุณจะสามารถเลือกจากรายการแหล่งที่มาที่มีอยู่ และระบุรูปแบบการกรองเพิ่มเติมที่จะใช้ในการถ่ายโอนเฉพาะเหตุการณ์ที่คุณต้องการได้ สำหรับขั้นตอนการแปลงและการเพิ่มคุณค่าที่เป็นทางเลือกของ Pipe คุณจะสามารถจัดเตรียมตำแหน่งข้อมูล API ได้ เช่น API ของแอปพลิเคชัน SaaS หรือคลัสเตอร์คอนเทนเนอร์ ฟังก์ชัน Lambda หรือ AWS Step Function Pipe จะสร้างคำขอ API และบันทึกการตอบสนองเมื่อการประมวลผลเสร็จสิ้น สุดท้าย ให้ตั้งค่าบริการปลายทางที่จะส่งมอบเหตุการณ์ และระบุว่าคุณต้องการให้เก็บถาวรหรือเปิดใช้ความสามารถ DLQ บน Pipe ดังกล่าวหรือไม่ นอกจากนี้ คุณยังสามารถสร้าง Pipe โดยใช้ AWS CLI, CloudFormation หรือ AWS Cloud Development Kit (CDK) ได้อีกด้วย

ถาม: แหล่งที่มาของเหตุการณ์ที่เป็นไปได้สำหรับ EventBridge Pipes คืออะไร

EventBridge Pipes มี Amazon SQS, Amazon Kinesis, Amazon DynamoDB, Amazon Managed Streaming Kafka, Kafka ที่จัดการด้วยตนเอง และ Amazon MQ เป็นแหล่งที่มาของชุดผลิตภัณฑ์ EventBridge EventBridge Pipes รองรับบริการเป้าหมายเดียวกันกับ Event Bus เช่น Amazon SQS, AWS Step Functions, Amazon Kinesis Data Streams, Amazon Kinesis Data Firehose, Amazon SNS, Amazon ECS รวมถึงตัว Event Bus เองด้วย

ถาม: การเปลี่ยนแปลงและการเพิ่มคุณค่ามีการทำงานอย่างไร

EventBridge Pipes รองรับการแปลงพื้นฐานโดยใช้ภาษาเทมเพลต Velocity (VTL) สำหรับการแปลงที่ทรงพลังยิ่งขึ้น EventBridge Pipes จะช่วยคุณในการระบุฟังก์ชัน Lambda หรือเวิร์กโฟลว์ Step Functions เพื่อแปลงเหตุการณ์ของคุณ หากคุณต้องการใช้บริการคอนเทนเนอร์ เช่น Amazon Elastic Container Service (ECS) หรือ Amazon Elastic Kubernetes Service (EKS) คุณก็สามารถระบุตำแหน่งข้อมูล API และรูปแบบการตรวจสอบสิทธิ์สำหรับคลัสเตอร์คอนเทนเนอร์ของคุณได้ และจากนั้น EventBridge จะดูแลต่อในด้านการแปลงของเหตุการณ์

ถาม: ฉันจำเป็นต้องใช้ Event Bus ของ EventBridge เพื่อใช้ EventBridge Pipes หรือไม่

ไม่จำเป็น คุณสามารถใช้ EventBridge Pipes แยกกับคุณสมบัติอื่นๆ จาก EventBridge ที่มีอยู่ได้เลย ซึ่งช่วยให้คุณรับเหตุการณ์จาก Event Producer อื่นๆ เช่น Kinesis, SQS หรือ Amazon MSK โดยไม่จำเป็นต้องใช้ Event Bus ของ EventBridge นอกจากนี้ ยังสามารถใช้สำหรับการผสานรวมแบบจุดต่อจุดได้อีกด้วย โดย Event Bus จะใช้สำหรับการผสานรวมแบบกลุ่มต่อกลุ่ม หากคุณใช้ Event Bus ของ EventBridge เพื่อกำหนดเส้นทางเหตุการณ์อยู่แล้ว คุณก็สามารถใช้ EventBridge Pipes เพื่อเชื่อมต่อกับแหล่งที่มาที่รองรับ และตั้งค่า Event Bus ให้เป็นแหล่งที่มาของ Pipe ได้

ถาม: Event Bus ของ EventBridge และ EventBridge Pipes แตกต่างกันอย่างไร

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

ถาม: EventBridge Pipes แตกต่างจากการแมปแหล่งที่มาของเหตุการณ์ (ESM) ของ AWS Lambda อย่างไร

การแมปแหล่งที่มาของเหตุการณ์ (ESM) ของ AWS Lambda และ Amazon EventBridge Pipes ใช้โครงสร้างพื้นฐานการทำโพลล์เดียวกันเพื่อเลือกและส่งเหตุการณ์ ESM เหมาะสมอย่างยิ่งสำหรับลูกค้าที่ต้องการใช้ Lambda เป็นเป้าหมายในการประมวลผลเหตุการณ์ที่ได้รับ Pipes เหมาะสำหรับลูกค้าที่อยากจะตัดความกังวลเกี่ยวกับการสร้าง บำรุงรักษา และปรับขนาดโค้ด Lambda และต้องการทรัพยากรที่เรียบง่ายและมีการจัดการ เพื่อเชื่อมต่อต้นทางกับหนึ่งในเป้าหมายกว่า 14 รายการ

ถาม: EventBridge Pipes มีการรับประกันในด้านลำดับของเหตุการณ์หรือไม่

มี EventBridge Pipes จะคงไว้ซึ่งลำดับของเหตุการณ์ที่ได้รับมาจากแหล่งที่มาเมื่อส่งเหตุการณ์เหล่านั้นไปยังบริการปลายทาง

ถาม: EventBridge Pipes รองรับเหตุการณ์การสร้างเป็นชุด (ฺBatching) หรือไม่

รองรับ สำหรับบริการที่สนับสนุนเหตุการณ์การสร้างเป็นชุด (ฺBatching) คุณสามารถกำหนดขนาดชุดที่คุณต้องการได้เมื่อสร้าง Pipe สำหรับแหล่งที่มาและเป้าหมายที่ไม่รองรับการสร้างเป็นชุด (Batching) คุณยังคงสามารถเลือกที่จะสร้างชุดเหตุการณ์สำหรับขั้นตอนการเพิ่มคุณค่าและการเปลี่ยนแปลงของคุณได้ ซึ่งช่วยให้คุณประหยัดค่าใช้จ่ายในการประมวลผล และยังช่วยให้คุณสามารถส่งเหตุการณ์ทีละรายการไปยังเป้าหมายที่คุณเลือกได้อีกด้วย

ถาม: ฉันสามารถรับประวัติการเรียก API ของ EventBridge Pipes ในบัญชีของฉันเพื่อวัตถุประสงค์ในการวิเคราะห์ความปลอดภัยและการแก้ไขปัญหาการดำเนินงานได้หรือไม่

ได้ หากต้องการรับประวัติการเรียก API ของ EventBridge Pipes ที่เรียกในบัญชีของคุณ คุณจะต้องเปิดใช้ CloudTrail ในคอนโซลการจัดการของ AWS ก่อน

ถาม: EventBridge Pipes มีค่าใช้จ่ายเท่าไร

หากต้องการดูรายละเอียดทั้งหมดของราคาสำหรับ Amazon EventBridge Pipes โปรดไปที่หน้าราคา

ถาม: Amazon EventBridge Scheduler คืออะไร

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

ถาม: ฉันจะเริ่มต้นใช้งาน EventBridge Scheduler ได้อย่างไร

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

ถาม: ความแตกต่างระหว่าง EventBridge Scheduler และ กฎที่มีกำหนดเวลา (Scheduled Rule) คืออะไร

EventBridge Scheduler สร้างขึ้นจากฟังก์ชันการจัดตารางเวลาที่มีให้ภายในกฎที่มีกำหนดเวลา (Scheduled Rule) EventBridge Scheduler รองรับโซนเวลา ขนาดที่เพิ่มขึ้น เพย์โหลดเป้าหมายที่กำหนดเอง การแสดงเวลาที่เพิ่ม และแดชบอร์ดสำหรับการตรวจสอบตารางเวลา สามารถสร้างกำหนดการได้อย่างอิสระโดยไม่จำเป็นต้องสร้าง Event Bus ด้วยกฎที่มีกำหนดเวลา (Scheduled Rule)

ถาม: ฉันควรใช้กฏที่มีกำหนดเวลาของ EventBridge หรือ EventBridge Scheduler เมื่อใด

กฏที่มีกำหนดเวลาจะพร้อมใช้งานอย่างต่อเนื่อง อย่างไรก็ตาม EventBridge Scheduler จะให้ชุดคุณสมบัติที่พิเศษกว่าโดยมีความยืดหยุ่นกว่าในการสร้าง ดำเนินการ และจัดการกำหนดการของคุณ คุณยังสามารถเริ่มใช้งานได้ฟรี ดูรายละเอียดเพิ่มเติมได้ที่หน้าราคา

ถาม: คุณสมบัตินี้ทำงานกับบริการอื่นๆ ของ AWS อย่างไร

EventBridge Scheduler มีการผสานกับบริการต่างๆ ของ AWS อย่างราบรื่นและสามารถสร้างกำหนดการสำหรับบริการด้วยการดำเนินการ API จาก AWS การกำหนดค่าสำหรับรูปแบบเวลาและการลองใหม่เป็นแบบเดียวกันใน AWS เพื่อประสบการณ์การกำหนดเวลาที่สอดคล้องกัน การตรวจสอบกำหนดการนั้นสามารถทำได้อย่างง่ายดายยิ่งขึ้นผ่านคอนโซล EventBridge Scheduler ที่จะมีการแสดงกำหนดการของคุณไว้ในแดชบอร์ด หรือด้วยคำขอ API “ListSchedule” คุณจะสามารถดูข้อมูลสำคัญเกี่ยวกับกำหนดการของคุณได้ เช่น เวลาเริ่มต้น การเรียกใช้ล่าสุด และเป้าหมาย AWS ที่กำหนด สำหรับรายละเอียดที่ลึกซึ้งยิ่งขึ้น คุณสามารถตรวจสอบข้อมูลบันทึกการดำเนินการที่มีอยู่ใน CloudWatch Logs หรือสามารถส่งไปยัง S3 หรือ Kinesis Firehose ได้

ถาม: ฉันจะอัปเดตกำหนดการได้อย่างไร

คุณสามารถอัปเดตกำหนดการของคุณได้ในคอนโซล EventBridge Scheduler โดยเลือกที่กำหนดการเพื่อแก้ไข แผงใหม่จะแสดงตัวเลือกของคุณ

ถาม: EventBridge Scheduler รองรับเขตเวลาทั้งหมดหรือไม่

รองรับ ด้วย EventBridge Scheduler คุณจะสามารถเลือกเขตเวลาที่จะให้กำหนดการทำงานได้ กำหนดการเหล่านี้จะปรับตามเวลาฤดูร้อน (DST) และกลับเป็นเวลามาตรฐานโดยอัตโนมัติ

ถาม: EventBridge Scheduler ตรวจสอบการส่งมอบตามกำหนดเวลาได้อย่างไร

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

ถาม: “การลบเมื่อเสร็จสิ้น” ของ EventBridge Scheduler จะมีผลกับรูปแบบการจัดกําหนดการทั้งหมดหรือไม่

“การลบเมื่อเสร็จสิ้น” จะใช้งานได้กับทุกรูปแบบการจัดกําหนดการที่รองรับในปัจจุบัน: cron, อัตราและการจัดกําหนดการแบบครั้งเดียว

ถาม: ฉันสามารถอัปเดตกําหนดการของฉันหลังจากตั้งค่า “การลบเมื่อเสร็จสิ้น” แล้วได้หรือไม่

ได้ คุณสามารถอัปเดตกําหนดการของคุณเพื่อกําหนดค่า “การลบเมื่อเสร็จสิ้น” ได้ตลอดเวลาก่อนที่จะเรียกดำเนินการกําหนดการดังกล่าว หลังจากเวลาเรียกดำเนินการกําหนดการล่าสุด คุณจะไม่สามารถทําการเปลี่ยนแปลงได้

ถาม: จะเกิดอะไรขึ้นหากฉันปิดกําหนดการที่เปิดใช้งาน “การลบเมื่อเสร็จสิ้น” ไว้ก่อนที่จะมีการเรียกดำเนินการกําหนดการ

หากคุณปิดกําหนดการที่มี “การลบเมื่อเสร็จสิ้น” ก่อนที่จะเรียกดำเนินการกําหนดการล่าสุด กําหนดการดังกล่าวจะยังคงอยู่ในบัญชีของคุณในสถานะปิดใช้งาน

ถาม: จะเกิดอะไรขึ้นหากกําหนดการที่เกิดซ้ำของฉันซึ่งตั้งค่าด้วย “การลบหลังจากเสร็จสิ้น” ไม่มีวันที่สิ้นสุด

กําหนดการดังกล่าวจะยังคงเรียกดำเนินการเป้าหมายต่อไปและจะไม่ลบโดยอัตโนมัติจนกว่าจะมีการกําหนดค่าวันที่สิ้นสุด

ถาม: ฉันสามารถกำหนดเวลางานสำหรับบริการภายนอก AWS เช่น เซิร์ฟเวอร์ในองค์กรของฉันหรือผลิตภัณฑ์ SaaS ภายนอกได้หรือไม่

EventBridge Scheduler ไม่รองรับเป้าหมายที่ไม่ใช่จาก AWS โดยตรง อย่างไรก็ตาม คุณสามารถเรียกใช้เป้าหมายที่ไม่ใช่จาก AWS ได้โดยใช้ Lambda, ECS และ Fargate หรือด้วย EventBridge ผ่านคุณสมบัติ API Destination

ถาม: EventBridge Scheduler มีค่าใช้จ่ายเท่าใด

หากต้องการดูรายละเอียดทั้งหมดของราคาสำหรับ Amazon EventBridge Scheduler โปรดไปที่หน้าราคา

ถาม: ตำแหน่งข้อมูลส่วนกลางคืออะไร

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

ถาม: เหตุใจฉันจึงควรใช้ตำแหน่งข้อมูลส่วนกลาง

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

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

ถาม: ตำแหน่งข้อมูลส่วนกลางช่วยปรับปรุงความพร้อมใช้งานของแอปพลิเคชันได้อย่างไร

เมื่อคุณเผยแพร่เหตุการณ์ไปยังตำแหน่งข้อมูลส่วนกลางแล้ว ระบบจะส่งเหตุการณ์ดังกล่าวไปยัง Event Bus ใน Region หลักของคุณ หากตรวจพบข้อผิดพลาดใน Region หลัก ระบบจะกำกับการตรวจสอบสถานะประสิทธิภาพไว้ว่าไม่มีประสิทธิภาพ และส่งเหตุการณ์ที่นำเข้ามาไปยัง Region รอง สามารถตรวจพบข้อผิดพลาดได้ง่ายยิ่งขึ้นโดยใช้ CloudWatch Alarms (ผ่านการตรวจสอบสถานะประสิทธิภาพของ Route 53) ที่คุณระบุ เมื่อปัญหาได้รับการแก้ไข เราจะกำหนดเส้นทางเหตุการณ์กลับไปยัง Region หลักอีกครั้ง และดำเนินการประมวลผลเหตุการณ์ดังกล่าวต่อไป

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

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

ถาม: ควรใช้ตัวชี้วัดใดเพื่อใช้ระบบสำรองเพื่อกู้คืนข้อมูลกับตำแหน่งข้อมูลส่วนกลาง

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

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

ถาม: ควรใช้ตัวชี้วัดจากสมาชิกของฉันเพื่อใช้ระบบสำรองเพื่อกู้คืนข้อมูลกับตำแหน่งข้อมูลส่วนกลางของฉันหรือไม่

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

หากสมาชิกรายใดรายหนึ่งของคุณไม่สามารถประมวลผลเหตุการณ์ใน Region หลักได้ คุณควรเปิดการจำลองเพื่อให้แน่ใจว่าสมาชิกของคุณใน Region รองสามารถประมวลผลเหตุการณ์ได้สำเร็จ

ถาม: ระยะเวลาที่ใช้ในการกู้คืนข้อมูล (RTO) ที่คาดหวังกับจุดที่ย้อนกลับไปกู้คืนข้อมูลได้ (RPO) คืออะไร

ระยะเวลาที่ใช้ในการกู้คืนข้อมูล (RTO) คือเวลาที่ Region สำรองหรือเป้าหมายจะเริ่มรับเหตุการณ์ใหม่หลังจากเกิดความล้มเหลว จุดที่ย้อนกลับไปกู้คืนข้อมูลได้ (RPO) คือมาตรวัดข้อมูลที่จะยังคงไม่ได้รับการประมวลผลระหว่างเกิดความล้มเหลว ในตำแหน่งข้อมูลส่วนกลาง หากคุณปฏิบัติตามคำแนะนำที่กำหนดไว้ในการกำหนดค่าการแจ้งเตือน RTO และ RPO จะอยู่ที่ 360 วินาที (สูงสุด 420 วินาที) สำหรับ RTO ระยะเวลาจะรวมช่วงเวลาสำหรับการทริกเกอร์ CloudWatch Alarms รวมถึงการอัปเดตสถานะสำหรับการตรวจสอบสถานะประสิทธิภาพของ Route53 ด้วย สำหรับ RPO ระยะเวลาจะรวมเหตุการณ์ที่ไม่ได้จำลองแบบไปยัง Region รอง และติดอยู่ใน Region หลักจนกว่าบริการหรือ Region จะมีการกู้คืน

ถาม: ควรเปิดการจำลองหรือไม่

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

ถาม: แนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการโควตาในทั้งสอง Region มีอะไรบ้าง

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

ถาม: มีวิธีในการจำลองสถาปัตยกรรมของฉันใน Region รองที่ง่ายกว่านี้หรือไม่

คุณสามารถใช้ AWS CloudFormation StackSets ที่ช่วยให้จำลองสถาปัตยกรรมของคุณทั่วทั้ง AWS Region ได้อย่างง่ายดายยิ่งขึ้น ดูตัวอย่างได้ในเอกสารประกอบของเรา

ถาม: ฉันสามารถใช้บัญชี บัส และ Region ใดก็ได้กับสถาปัตยกรรมรองของฉันได้หรือไม่

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

ถาม: ตำแหน่งข้อมูลส่วนกลางทำงานร่วมกับเหตุการณ์ AWS จาก CloudTrail, S3 และบริการของ AWS อื่นๆ ด้วยหรือไม่

ตำแหน่งข้อมูลส่วนกลางทำงานร่วมกับเหตุการณ์แบบกำหนดเองเท่านั้น เราจะเพิ่มการรองรับเหตุการณ์จากบริการต่างๆ ของ AWS, เหตุการณ์เลือกรับจาก S3 (การแจ้งเตือนเหตุการณ์ Amazon S3) และเหตุการณ์ของบุคคลที่สามในอนาคต

ถาม: คุณรองรับการกำหนดเส้นทางตามความหน่วงหรือไม่

ไม่ เราไม่รองรับการกำหนดเส้นทางตามความหน่วงในการทำซ้ำการเปิดตัวครั้งแรก

ถาม: ตำแหน่งข้อมูลส่วนกลางมีค่าบริการเท่าไร

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

ถาม: ฉันจะถูกเรียกเก็บเงินในการจำลองหรือไม่

ใช่ คุณจะถูกเรียกเก็บค่าบริการ 1 USD ต่อ 1 ล้านเหตุการณ์สำหรับการจำลอง ซึ่ง EventBridge จะเรียกเก็บค่าบริการสำหรับเหตุการณ์ข้าม Region

ถาม: สามารถใช้ตำแหน่งข้อมูลส่วนกลางใน Region ใดได้บ้าง

ตำแหน่งข้อมูลส่วนกลางมีให้บริการใน Region ต่อไปนี้

• สหรัฐอเมริกาฝั่งตะวันออก (โอไฮโอและเวอร์จิเนียเหนือ)
• สหรัฐอเมริกาฝั่งตะวันตก (แคลิฟอร์เนียเหนือและออริกอน)
  
• เอเชียแปซิฟิก (มุมไบ โอซาก้า โซล สิงคโปร์ ซิดนีย์ และโตเกียว)
• แคนาดา (ภาคกลาง)
• ยุโรป (แฟรงเฟิร์ต ไอร์แลนด์ ลอนดอน ปารีส และสตอกโฮล์ม)
• อเมริกาใต้ (เซาเปาลู)
  

ถาม: EventBridge มีราคาเท่าไร

Amazon EventBridge เสนอราคาที่ยืดหยุ่นด้วยโมเดลจ่ายตามที่ใช้งาน คุณจะชำระเงินเฉพาะเหตุการณ์ที่เผยแพร่โดย Event Bus ของคุณ, เหตุการณ์ที่นำเข้าสำหรับ Schema Discovery, การเล่นซ้ำเหตุการณ์ และ API Destination เท่านั้น หากต้องการดูตัวอย่างและรายละเอียดราคาเพิ่มเติมสําหรับ EventBridge โปรดไปที่หน้าราคาของเรา

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

ไม่

ถาม: ฉันสามารถมีเป้าหมายที่ส่งเหตุการณ์ไปยังบัญชีอื่นได้หรือไม่

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

ถาม: ฉันจะสามารถใช้ CloudFormation ร่วมกับ EventBridge ได้หรือไม่

ได้ CloudFormation มีให้บริการในทุก Region ที่ Amazon EventBridge พร้อมให้บริการอยู่ หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับวิธีใช้ CloudFormation เพื่อจัดเตรียมและจัดการทรัพยากรของ EventBridge ให้ไปที่เอกสารประกอบของเรา

ถาม: ฉันควรใช้ EventBridge และ SNS เมื่อใด

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

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

EventBridge ใช้โครงสร้างแบบอิงตาม JSON ที่กำหนดไว้สำหรับเหตุการณ์ และช่วยให้คุณสามารถสร้างกฎที่ปรับใช้ได้กับทั่วทั้งเนื้อหาเหตุการณ์ เพื่อให้สามารถเลือกเหตุการณ์ที่จะส่งต่อไปยังเป้าหมายได้ ขณะนี้ EventBridge รองรับบริการของ AWS กว่า 20 รายการเป็นเป้าหมาย ซึ่งรวมถึง Lambda, SQS, SNS และ Amazon Kinesis Data Streams ตลอดจน Kinesis Data Firehose

แนะนําให้ใช้ Amazon SNS สําหรับแอปพลิเคชันที่ต้องมีการกระจายสูง (ตําแหน่งข้อมูลหลายพันหรือหลายล้านตําแหน่ง) รูปแบบทั่วไปที่เราเห็นคือลูกค้าใช้ SNS เป็นเป้าหมายสําหรับกฎของตนเองเพื่อกรองเหตุการณ์ที่ต้องการและกระจายไปยังตำแหน่งข้อมูลหลายแห่ง

ข้อความจะไม่มีโครงสร้าง และสามารถอยู่ในรูปแบบใดก็ได้ SNS รองรับการส่งข้อความไปยังเป้าหมาย 6 ประเภทที่แตกต่างกัน ซึ่งได้แก่ Lambda, SQS, ตำแหน่งข้อมูล HTTP/S, SMS, การแจ้งเตือนแบบพุชสำหรับมือถือ และอีเมล เวลาแฝงโดยทั่วไปของ SNS จะไม่เกิน 30 มิลลิวินาที มีบริการของ AWS อยู่หลากหลายรายการที่ส่งข้อความ SNS โดยใช้วิธีกำหนดค่าบริการนั้นๆ ให้ดำเนินการส่ง (มากกว่า 30 รายการ ซึ่งรวมถึง Amazon EC2, Amazon S3 และ Amazon RDS)

ถาม: เมื่อใดที่ฉันจะใช้ EventBridge เทียบกับ AppFabric

AWS AppFabric เป็นบริการแบบไม่ต้องเขียนโค้ดที่ช่วยเสริมการลงทุนที่มีอยู่ของบริษัทในแอปพลิเคชัน Software as a Service (SaaS) พร้อมด้วยการรักษาความปลอดภัย การจัดการ และประสิทธิภาพการทำงานที่ดียิ่งขึ้น ใช้ AppFabric เพื่อรวบรวมและทำให้ข้อมูลบันทึก SaaS เป็นมาตรฐานจากแอปอย่าง Asana, Slack และ Zoom รวมถึงชุดเพิ่มประสิทธิภาพการทำงาน เช่น Microsoft 365 และ Google Workspace เพื่อเพิ่มข้อมูลการสังเกตของแอปพลิเคชันและลดต้นทุนการดำเนินงานที่เกี่ยวข้องกับการสร้างและการบำรุงรักษาการผสานรวมแบบจุดต่อจุด EventBridge เป็นบริการการผสานรวมแบบไม่ต้องใช้เซิร์ฟเวอร์ที่ใช้เหตุการณ์เพื่อเชื่อมต่อส่วนประกอบของแอปพลิเคชันเข้าด้วยกัน จึงทําให้นักพัฒนาสามารถสร้างแอปพลิเคชันที่ขับเคลื่อนด้วยเหตุการณ์ที่ปรับขนาดได้ง่ายขึ้น ใช้ EventBridge เพื่อกำหนดเส้นทางเหตุการณ์จากแหล่งที่มาต่างๆ เช่น แอปพลิเคชันแบบกำหนดเอง บริการของ AWS และแอปพลิเคชัน SaaS ของบริษัทอื่นไปยังแอปพลิเคชันสำหรับผู้บริโภคทั่วทั้งองค์กร EventBridge เป็นวิธีในการนําเข้า กรอง แปลง และส่งมอบกิจกรรมที่ง่ายและมีความสม่ำเสมอ

ถาม: ทำไมฉันจึงควรผสานรวมแอปพลิเคชัน SaaS เข้ากับ EventBridge

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

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

ถาม: บริษัท SaaS ของฉันน่าจะเป็นแหล่งเหตุการณ์ที่ดีได้ ฉันควรเตรียมความพร้อมอย่างไร

ผู้จำหน่าย SaaS ที่สนใจมาเป็นพาร์ทเนอร์ของ EventBridge ควรทำตามคำแนะนำแบบบริการตนเองที่หน้าการผสานรวม Amazon EventBridge เพื่อเริ่มเผยแพร่เหตุการณ์ไปยัง EventBridge

ถาม: ผู้จำหน่าย SaaS ต้องใช้ความพยายามมากน้อยเพียงใดในการผสานรวมกับ EventBridge

ผู้ให้บริการ SaaS ที่รองรับเว็บฮุค (Webhook) หรือโหมดการผสานรวมแบบพุชอื่นๆ อยู่แล้วอาจใช้เวลาน้อยกว่าห้าวันในการผสานรวมกับ EventBridge

ถาม: รองรับการผสานรวม SaaS ใดบ้าง

เรารองรับการผสานรวม SaaS มากกว่า 45 รายการ โปรดดูรายการการผสานรวม SaaS ที่รองรับทั้งหมดสำหรับ Amazon EventBridge