คำศัพท์ · amazon ses

Amazon SES คืออะไร และส่งผลต่ออีเมลของแอปพลิเคชันอย่างไร

Amazon Simple Email Service หรือ Amazon SES คือโครงสร้างพื้นฐาน AWS สำหรับส่งอีเมลผ่าน API หรืออินเทอร์เฟซ SMTP และรับอีเมล สำหรับทีมแอปพลิเคชัน การเลือก SES หมายถึงการรับผิดชอบมากกว่าคำสั่งส่ง ได้แก่ ตัวตนที่ยืนยันแล้ว การกำหนดค่าตามภูมิภาค สิทธิ์ IAM การจัดการโควตา การสร้างข้อความ การนำเข้าอีเวนต์ การตอบสนองต่ออีเมลตีกลับและการร้องเรียน การระงับการส่ง และการติดตามการปฏิบัติการ การที่ SES ยอมรับหมายความว่า AWS จะพยายามส่ง ไม่ได้พิสูจน์การเข้ากล่องจดหมาย ให้ถือ SES เป็นชั้นการขนส่งและ feedback ภายในระบบอีเมลแอปพลิเคชันที่ใหญ่กว่า

เข้าใจขอบเขตของบริการ

SES รับอีเมลแอปพลิเคชันผ่าน AWS API หรือ endpoint SMTP และสามารถประกอบข้อความ MIME จากฟิลด์ที่มีโครงสร้าง หรือรับข้อความที่ผู้ส่งประกอบไว้เองได้ นั่นทำให้เป็นโครงสร้างพื้นฐาน ไม่ใช่เวิร์กโฟลว์ผลิตภัณฑ์ที่สมบูรณ์ แอปพลิเคชันของคุณยังเป็นผู้ตัดสินว่าใครส่งได้ tenant ใดเป็นเจ้าของโดเมน จัดการเทมเพลตและข้อมูลผู้รับอย่างไร การลองใหม่ปลอดภัยเมื่อใด และผู้ใช้เห็นอะไรหลัง request สำเร็จ สถาปัตยกรรมที่มีประโยชน์แยกสามสถานะ ได้แก่ แอปพลิเคชันยอมรับงาน SES ยอมรับข้อความ และเซิร์ฟเวอร์อีเมลผู้รับยอมรับหรือปฏิเสธข้อความ สถานะเหล่านี้เกิดต่างเวลากันและต้องใช้ตัวระบุคนละแบบ จัดเก็บ job ID ที่เปลี่ยนแปลงไม่ได้ของคุณเองข้างตัวระบุข้อความ SES เพื่อให้กระทบยอดการลองใหม่ของ webhook และการตรวจสอบซัพพอร์ตได้โดยไม่ต้องเดาจากบรรทัดหัวเรื่องหรือข้อมูลผู้รับ

ยืนยันตัวตนก่อนส่ง

AWS นิยามตัวตนที่ยืนยันแล้วว่าเป็นโดเมนหรือที่อยู่อีเมลที่ใช้กับ SES ก่อนส่ง ตัวตนของ From, Source, Sender หรือ Return-Path ต้องเป็นไปตามกฎการยืนยันของ SES การยืนยันโดเมนมักเป็นตัวเลือกที่ยั่งยืนสำหรับแอปพลิเคชัน เพราะอนุญาตที่อยู่ภายใต้โดเมนนั้นได้และรองรับการยืนยันตัวตนระดับโดเมน การยืนยันไม่ใช่ช่องทำเครื่องหมายครั้งเดียวที่คัดลอกไปใช้กับทุกการดีพลอยได้ สถานะตัวตนและการตั้งค่า Easy DKIM เป็นแบบเฉพาะภูมิภาค โดเมนที่ยืนยันในภูมิภาค AWS หนึ่งจึงไม่พร้อมใช้ในอีกภูมิภาคโดยอัตโนมัติ ออกแบบการเริ่มใช้งานเป็น state machine ได้แก่ ขอตัวตน แสดงเรคคอร์ด DNS ที่แน่นอน ตรวจสถานะจากผู้ให้บริการที่เป็นแหล่งข้อมูลที่เชื่อถือได้ และอนุญาตให้ส่งในระบบจริงเมื่อภูมิภาคที่เลือกรายงานว่าสำเร็จแล้วเท่านั้น คงนโยบาย SPF และ DMARC เดิมไว้เมื่อใช้ DNS ร่วมกับผู้ส่งรายอื่น และอย่าสร้างเรคคอร์ด SPF ที่สองเพื่อความสะดวก

ทำให้ภูมิภาคเป็นส่วนหนึ่งของการกำหนดค่าอีเมล

ทรัพยากรและขีดจำกัดการดำเนินงานของ SES เป็นแบบเฉพาะภูมิภาค ตัวตนที่ยืนยันแล้ว สถานะ sandbox โควตารายวัน อัตราการส่งสูงสุด การตั้งค่า Easy DKIM การกำหนดค่าการระงับการส่ง และปลายทางฟีดแบ็กอาจต่างกันในแต่ละภูมิภาค ข้อมูลรับรองที่ใช้ได้ใน AWS ไม่ได้ทำให้ตัวตนย้ายไปใช้กับ endpoint SES อื่นได้ ให้ใส่ภูมิภาคไว้ข้างบัญชีผู้ให้บริการและตัวตนในการกำหนดค่า แทนที่จะซ่อนไว้ในค่าเริ่มต้นของสภาพแวดล้อมทั่วไป สำหรับ failover ให้เตรียมภูมิภาครองก่อนเกิดเหตุ ได้แก่ ยืนยันตัวตน เผยแพร่เรคคอร์ด DKIM ขอสิทธิ์เข้าถึงระบบจริงและโควตาที่เหมาะสม กำหนดค่าปลายทางอีเวนต์ ทดสอบตัวระบุข้อความและการประมวลผล webhook และยืนยันว่าเข้าใจพฤติกรรมการระงับการส่ง หากสลับเพียง endpoint ระหว่างเหตุขัดข้อง อาจเปลี่ยนเหตุการณ์หนึ่งเป็นปัญหาการยืนยัน การถูกจำกัดอัตรา หรือฟีดแบ็กที่หายไป

เลือก API หรือ SMTP อย่างตั้งใจ

AWS รองรับการส่งในระบบจริงผ่าน SES API และอินเทอร์เฟซ SMTP API เหมาะกับแอปพลิเคชันที่ใช้การยืนยันตัวตนและ SDK ของ AWS อยู่แล้ว และมีทั้งการทำงานแบบมีโครงสร้างและแบบข้อความดิบ SMTP เหมาะกับซอฟต์แวร์ที่ใช้ SMTP อยู่แล้ว แต่ข้อมูลรับรอง SMTP ของ SES ต่างจาก access key ปกติของ AWS และเป็นแบบเฉพาะภูมิภาค ตัวเลือกนี้ไม่ได้ลดความจำเป็นของคิว idempotency การจัดการ timeout หรือกฎการลองใหม่ที่ปลอดภัย หากการเชื่อมต่อล้มเหลวก่อนที่แอปพลิเคชันจะได้รับการตอบกลับ ผู้ให้บริการอาจยอมรับข้อความไปแล้ว หลีกเลี่ยงการลองคำขอที่ผู้ใช้เห็นใหม่แบบสุ่มสี่สุ่มห้าด้วยตัวระบุแอปพลิเคชันใหม่ ให้เข้าคิวครั้งเดียว เก็บการตอบกลับของผู้ให้บริการเมื่อมี และให้ worker ลองงานที่คงที่ซ้ำ ใช้การทำงานแบบข้อความดิบเมื่อจำเป็นต้องควบคุม MIME อย่างแม่นยำเท่านั้น และตรวจสอบเฮดเดอร์กับความยาวบรรทัดก่อนส่งข้อความให้ SES

ถือ sandbox และโควตาเป็นข้อจำกัดขณะทำงาน

คู่บัญชี-Region ของ SES ใหม่อาจอยู่ใน sandbox ปัจจุบัน AWS ระบุขีดจำกัด sandbox ที่การส่งถึงผู้รับ 200 รายต่อ 24 ชั่วโมง และหนึ่งอีเมลต่อวินาที โดยจำกัดการส่งถึงผู้รับที่ยืนยันแล้ว ยกเว้น mailbox simulator โควตาระบบจริงแตกต่างตามบัญชี Region และกรณีใช้งานที่ได้รับอนุมัติ โควตานับผู้รับ ไม่ใช่ request API ดังนั้น request เดียวถึงผู้รับสิบรายใช้สิบหน่วย อ่านโควตาจริงสำหรับ Region ที่ใช้งานทุกแห่ง และออกแบบ backpressure ครอบคลุมทั้งโควตารายวันแบบเลื่อนและอัตราส่ง การ throttle ของผู้ให้บริการควรหน่วงงานในคิว ไม่ใช่สร้างการส่งซ้ำหรือแสดงเป็นความสำเร็จที่อธิบายไม่ได้ ขอสิทธิ์ใช้งานจริงและขีดจำกัดที่สมจริงก่อนเปิดตัว แล้ว load-test กับผู้รับที่ควบคุมได้ อย่าเรียก sandbox ว่า free tier และอย่าคิดว่าการอนุมัติใน Region หนึ่งใช้กับอีก Region หนึ่ง

สร้างสถานะการส่งถึงจากอีเวนต์

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

จัดการอีเมลตีกลับ การร้องเรียน และการระงับการส่ง

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

ใช้สิทธิ์ขั้นต่ำและแยก tenant

นโยบาย IAM จำกัดได้ว่า principal เรียกการทำงานใดของ SES ได้ และจำกัดที่อยู่ From, ผู้รับ หรือ Return-Path สำหรับการส่งได้ นโยบายการอนุญาตการส่ง (sending authorization) แก้ปัญหาคนละแบบ คือให้เจ้าของตัวตนมอบสิทธิ์การใช้ตัวตนที่ยืนยันแล้ว และเพิกถอนได้อย่างอิสระ สำหรับแอปพลิเคชันเดียว ควรใช้ principal ที่มีเฉพาะการทำงานส่งและติดตามที่ปริมาณงานต้องการจริง ห้ามให้เว็บเบราว์เซอร์มีข้อมูลรับรอง AWS ผลิตภัณฑ์อีเมลแบบหลาย tenant ยังต้องมีการอนุญาตในเลเยอร์แอปพลิเคชัน เพราะบัญชี SES ที่ใช้ร่วมกันไม่เข้าใจโมเดลเวิร์กสเปซของคุณโดยอัตโนมัติ ตรวจสอบว่า tenant ที่ยืนยันตัวตนแล้วเป็นเจ้าของโดเมน From ที่ยืนยันแล้วก่อนส่งให้ SES จำกัดขอบเขต API key และบันทึกข้อความไว้ที่ tenant นั้น และทำให้ตัวระบุข้ามระหว่าง tenant ไม่ส่งข้อมูลกลับ IAM ของผู้ให้บริการและการอนุญาตของแอปพลิเคชันเป็นการควบคุมที่เสริมกัน ไม่ใช่ทดแทนกัน

ใช้เช็กลิสต์ความพร้อมสำหรับระบบจริง

ก่อนเปิดตัว ให้บันทึกบัญชี AWS ภูมิภาค ARN ของตัวตน สถานะการยืนยัน สถานะ DKIM สถานะ sandbox โควตารายวัน อัตราการส่งสูงสุด ปลายทางอีเวนต์ ขอบเขตการระงับการส่ง และเจ้าของข้อมูลรับรอง ทดสอบการส่งถึงปกติ อีเมลตีกลับจาก mailbox simulator การทดสอบการร้องเรียนที่รองรับ การตอบสนองเมื่อถูกจำกัดอัตรา การลองอีเวนต์ซ้ำ และ timeout ของผู้ให้บริการหลังส่งข้อมูลแล้ว ยืนยันว่า worker ของคิวไม่ทำให้งานที่คงที่ซ้ำ อีเวนต์ delivery อัปเดตข้อความที่ถูกต้อง และอีเมลตีกลับถาวรป้องกันการส่งตามปกติอีกครั้ง ตั้งการแจ้งเตือนสำหรับคำขอที่ถูกปฏิเสธ การถูกจำกัดอัตรา ความล้มเหลวในการรับอีเวนต์ การเปลี่ยนแปลงของอีเมลตีกลับและการร้องเรียน และช่องว่างของโควตา ทบทวนการกำหนดค่าทุกครั้งที่มีภูมิภาค โดเมน ประเภท tenant หรือประเภทข้อความใหม่ เช็กลิสต์นี้เปลี่ยน SES จากสิ่งที่พึ่งพาแบบซ่อนอยู่ให้เป็นระบบย่อยที่ชัดเจน มีผู้รับผิดชอบและโหมดความล้มเหลวที่สังเกตได้

ตัดสินว่า SendHQ เหมาะที่ตรงไหน

ทีมสามารถเชื่อมต่อ SES โดยตรงได้เมื่อต้องการควบคุมแบบ AWS-native และพร้อมสร้างเลเยอร์แอปพลิเคชันโดยรอบ SendHQ เสนอสัญญาการส่งอีเมลที่แคบกว่าในระดับเวิร์กสเปซ ประกอบด้วยโดเมนผู้ส่งที่ยืนยันแล้ว API key ที่จำกัดขอบเขต การส่งเดี่ยวและแบบแบตช์ กล่องจดหมายขาเข้า การเข้าถึงอีเวนต์การส่งถึง และเวิร์กโฟลว์การระงับการส่ง API สาธารณะของ SendHQ กำหนดให้โดเมน From เป็นของเวิร์กสเปซและยืนยันแล้ว และบันทึกข้อความที่ถูกยอมรับไว้ให้ตรวจสอบภายหลัง เลเยอร์ผลิตภัณฑ์นั้นไม่ได้ทดแทนกฎด้านตัวตน โควตา ชื่อเสียง หรือการกรองฝั่งผู้รับของ SES ให้ประเมินสองเลเยอร์แยกกัน ผู้ให้บริการขนส่งและรายงานอีเมล ส่วนเลเยอร์แอปพลิเคชันบังคับใช้ความเป็นเจ้าของของ tenant เปิดเผยทรัพยากรที่คงที่ และแสดงสถานะการดำเนินงาน ทั้ง SES โดยตรงและ SendHQ ไม่ได้ยืนยันการเข้ากล่องจดหมาย ดังนั้นควรประเมินทั้งสองด้านการควบคุม การสังเกตการณ์ ความเป็นเจ้าของ และความเหมาะสมกับเวิร์กโฟลว์ของแอปพลิเคชัน

คำถามที่พบบ่อย

Amazon SES เป็น email API หรือเซิร์ฟเวอร์ SMTP

มีทั้ง HTTPS API และอินเทอร์เฟซ SMTP ให้เลือกตามความต้องการด้านการยืนยันตัวตนและการประกอบข้อความของแอปพลิเคชัน โดยให้คิว ตัวระบุงานที่คงที่ การประมวลผลอีเวนต์ และการระงับการส่งอยู่นอกการเรียกขนส่ง

ต้องยืนยันโดเมนเพื่อใช้ Amazon SES หรือไม่

คุณต้องยืนยันทุกตัวตนที่ใช้เป็นที่อยู่ From, Source, Sender หรือ Return-Path ตัวตนแบบที่อยู่อีเมลใช้ได้ในบางกรณีที่จำกัด ขณะที่การยืนยันโดเมนมักใช้งานได้จริงมากกว่าสำหรับที่อยู่ที่แอปพลิเคชันควบคุมและ DKIM

การตอบกลับสำเร็จของ SES หมายความว่าอีเมลส่งถึงแล้วหรือไม่

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

โควตาของ Amazon SES ใช้ร่วมกันข้ามภูมิภาคหรือไม่

ไม่ AWS ระบุว่าโควตาการส่ง สถานะ sandbox ตัวตนที่ยืนยันแล้ว การตั้งค่า DKIM และการกำหนดค่าการระงับการส่งเป็นแบบเฉพาะภูมิภาค ให้เตรียมและทดสอบทุกภูมิภาคที่อาจรับทราฟฟิกระบบจริง แทนที่จะสลับ endpoint ระหว่างเหตุขัดข้อง

แอปพลิเคชันควรเก็บอะไรหลังส่งผ่าน SES

เก็บ ID งานของแอปพลิเคชันที่คงที่ ตัวระบุข้อความของ SES เมื่อถูกยอมรับ ผู้ให้บริการและภูมิภาค สถานะปัจจุบัน เวลา และอีเวนต์การส่งถึงที่ normalize แล้ว ไม่เก็บเนื้อหาข้อความและข้อมูลผู้รับไว้ในล็อกและระบบวิเคราะห์ที่กว้าง

เมื่อใดที่ทีมควรใช้ SendHQ แทน SES โดยตรง

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

แหล่งอ้างอิง

เรียนรู้ต่อ

ต้นทุน Amazon SES: โมเดลราคาสำหรับทีมผลิตภัณฑ์สร้างโมเดลต้นทุน Amazon SES ตามผู้รับ ข้อมูล แพ็กเกจราคา IP เฉพาะ โครงสร้างพื้นฐานอีเวนต์ โควตา และเลเยอร์วิศวกรรมรอบการส่งถึง