ภาพรวม

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

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

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

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

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

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

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

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

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

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

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

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

ถาม: Amazon EventBridge เกี่ยวข้องกับ CloudWatch Events อย่างไร

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

ถาม: ฉันกำลังใช้ Amazon CloudWatch Events อยู่และฉันต้องการลองใช้คุณสมบัติต่างๆ ของ Amazon EventBridge ฉันต้องย้ายกฎและสิทธิ์ของ Amazon CloudWatch Events ไปยัง Amazon EventBridge หรือไม่

ไม่ต้อง ผู้ที่ใช้ Amazon CloudWatch Events อยู่แล้วสามารถเข้าถึงบัส กฎ และเหตุการณ์ตามค่าเริ่มต้นที่มีอยู่ของตนได้ใน Amazon EventBridge Console และ API ใหม่ หรือใน Amazon CloudWatch Events Console และ API

ถาม: ฉันใช้ Amazon CloudWatch Events อยู่แล้ว และฉันยังไม่จำเป็นต้องใช้คุณสมบัติต่างๆ ของ Amazon EventBridge จะมีสิ่งใดเปลี่ยนแปลงสำหรับฉันหรือไม่

ไม่มี Amazon EventBridge ใช้ Amazon CloudWatch Events API เดียวกัน ดังนั้นการใช้ CloudWatch Events API ทั้งหมดที่มีอยู่ของคุณจะยังคงเหมือนเดิม

ถาม: ในอนาคตคุณจะยกเลิก Amazon CloudWatch Events ไหม

ไม่ เราจะไม่ยกเลิก API หรือตัวบริการเอง Amazon EventBridge ใช้ API เดียวกันและมีคุณสมบัติเพิ่มเติม ซึ่งในอนาคต เราจะเปลี่ยนชื่อ Amazon CloudWatch Events เป็น Amazon EventBridge

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

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

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

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

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

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

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

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

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

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

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

ข้อจำกัดและประสิทธิภาพ

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

โปรดดูหน้า "Service Limits" ที่นี่

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

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

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

รองรับ คุณติดแท็กกฏได้ แต่คุณไม่สามารถติดแท็กบัสเหตุการณ์หรือแหล่งเหตุการณ์ได้

ถาม: Amazon EventBridge มีปริมาณการประมวลผลเท่าใด

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

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

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

รีจิสทรีของสคีมา

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

การสร้างโค้ดสามารถใช้งาน Java (8+), Python (3.6+) และ TypeScript (3.0+) ได้

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

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

ตำแหน่งข้อมูลส่วนกลาง

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

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

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

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

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

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

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

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

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

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

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

เราไม่แนะนำให้รวมตัวชี้วัดสมาชิกในการตรวจสอบสภาพของคุณ เนื่องจากอาจทำให้ผู้เผยแพร่ของคุณเปลี่ยนระบบเมื่อเกิดข้อผิดพลาดไปยัง 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 ที่รองรับตั้งแต่เปิดตัวได้ที่คำถามที่ 16 ด้านล่าง และเรายังรองรับการเปลี่ยนระบบเมื่อเกิดข้อผิดพลาดและการกู้คืนระหว่างบัญชีเดียวกันและบัสที่มีชื่อเดียวกันทั่วทั้ง Region ด้วย

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

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

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

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

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

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

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

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

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

ราคาและการเก็บค่าบริการ

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

โปรดดูราคาที่นี่

 

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

ไม่

สถาปัตยกรรมและการออกแบบ

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

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

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

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

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

คุณสามารถใช้ทั้ง Amazon EventBridge และ Amazon SNS ในการพัฒนาแอปพลิเคชันที่ขับเคลื่อนด้วยเหตุการณ์ได้ และตัวเลือกของคุณจะขึ้นอยู่กับความต้องการเฉพาะของคุณ แนะนำให้ใช้ Amazon EventBridge หากคุณต้องการสร้างแอปพลิเคชันที่ตอบสนองต่อเหตุการณ์ต่างๆ จากแอปพลิเคชัน SaaS และ/หรือบริการของ AWS Amazon EventBridge เป็นบริการตามเหตุการณ์เพียงบริการเดียวที่ผสานรวมโดยตรงเข้ากับคู่ค้า SaaS ที่เป็นบริษัทอื่น อีกทั้ง Amazon EventBridge ยังย่อยเหตุการณ์จากบริการต่างๆ ของ AWS กว่า 90 รายการโดยอัตโนมัติ โดยที่นักพัฒนาไม่จำเป็นต้องสร้างทรัพยากรใดๆ ในบัญชีของตน นอกจากนี้ Amazon EventBridge ใช้โครงสร้างแบบอิงตาม JSON ที่กำหนดไว้สำหรับเหตุการณ์ และช่วยให้คุณสามารถสร้างกฎที่ปรับใช้ได้กับทั่วทั้งเนื้อหาเหตุการณ์เพื่อให้สามารถเลือกเหตุการณ์ที่จะส่งต่อไปยังเป้าหมายได้ ขณะนี้ Amazon EventBridge รองรับบริการของ AWS กว่า 15 รายการเป็นเป้าหมาย ซึ่งรวมถึง AWS Lambda, Amazon SQS, Amazon SNS และ Amazon Kinesis Streams ตลอดจน Kinesis Data Firehose และอื่นๆ ในช่วงที่เริ่มใช้งาน Amazon EventBridge มีปริมาณการประมวลผลที่จำกัด (ดู Service Limits) ซึ่งสามารถขอให้เพิ่มได้ รวมถึงมีเวลาแฝงทั่วไปที่ประมาณครึ่งวินาที

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

การผสานรวม

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

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

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

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

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

ผู้จำหน่าย SaaS ที่รองรับ Webhook หรือโหมดการผสานรวมแบบพุชอื่นๆ อยู่แล้วสามารถคาดการณ์ได้ว่าจะใช้เวลาไม่เกิน 5 วันในการพัฒนาเพื่อผสานรวมกับ Amazon EventBridge

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

โปรดดูรายการที่แสดงการผสานรวมที่รองรับทั้งหมดได้ที่นี่

การผสานรวม Amazon EventBridge
เรียนรู้เพิ่มเติมเกี่ยวกับการผสานรวม Amazon EventBridge

เข้าดูที่หน้าการผสานรวม Amazon EventBridge

เรียนรู้เพิ่มเติม 
เริ่มต้นสร้างใน Console
เริ่มต้นสร้างใน Console

เริ่มต้นสร้างด้วย Amazon EventBridge ใน AWS Management Console

ลงชื่อเข้าใช้ 
อ่านเอกสารประกอบ
เรียนรู้เพิ่มเติมได้ในเอกสารประกอบ

ดูข้อมูลเพิ่มเติมเกี่ยวกับ EventBridge ในคู่มือนักพัฒนา

เรียนรู้เพิ่มเติม