Amazon SES আর Pinpoint

এই lesson শেষে তুমি পারবে

• Amazon SES কীসের জন্য (transactional, marketing আর bulk email, পাঠানো আর নেওয়া দুটোই) ব্যাখ্যা করতে, আর SES API বা SMTP interface দিয়ে mail পাঠাতে।
• Account-কে SES sandbox থেকে বের করতে, একটা domain verify করতে, আর SPF (custom MAIL FROM), DKIM (Easy DKIM) ও DMARC এমনভাবে বসাতে যাতে আসল mail inbox-এ যায় আর জাল mail না যায়।
• পাঠানোর reputation রক্ষা করতে: bounce আর complaint-এর হার, কোন সীমায় SES account review করে বা পাঠানো বন্ধ করে, suppression list, shared আর dedicated IP address, configuration set আর event publishing।
• Receipt rule দিয়ে email নিতে (S3, Lambda, SNS), আর Mail Manager ও Virtual Deliverability Manager কোথায় বসে তা জানতে।
• SES আর SNS-এর তফাত ঠিকঠাক বলতে, আর notes-এর “SES শুধু email, SNS শুধু app-to-app বা SMS” কথাটা শুধরে দিতে।
• Amazon Pinpoint কী করত, ৩০ অক্টোবর ২০২৬-এ তার support শেষ হওয়া, কোন অংশ AWS End User Messaging হিসেবে চলছে, কোন অংশ Amazon Connect-এ গেছে, আর পরীক্ষা এখনও কী আশা করতে পারে, তা ব্যাখ্যা করতে।
• Scenario-র keyword দেখে SES, SNS, End User Messaging, Amazon Connect বা SQS বেছে নিতে।

#কেন: email আর SMS যতটা সহজ মনে হয় ততটা না

প্রায় সব application-কেই মানুষের সাথে কথা বলতে হয়: “তোমার order নিশ্চিত হয়েছে”, “এই নাও password reset-এর link”, “তোমার OTP 482913”, “আজ রাত থেকে ঈদ sale”। দেখতে সহজ: একটা mail server বসাও, port 25-এ যুক্ত হও, পাঠিয়ে দাও। বাস্তবে নিজে চালানোর মধ্যে এটা সবচেয়ে ঝামেলার কাজগুলোর একটা:

• Mailbox provider অচেনাকে বিশ্বাস করে না। নতুন server, কোনো ইতিহাস নেই, SPF, DKIM বা DMARC record নেই, reputation নেই: তার mail সোজা spam-এ যায়, নয়তো ফেরত আসে।
• EC2-তে port 25 default-ভাবে throttle করা, ঠিক এই কারণে যে spammer-রা নতুন cloud server খুব পছন্দ করে।
• একটা খারাপ list সব নষ্ট করে। কোনো marketing blast হাজারখানেক মৃত ঠিকানায় গেলে, সেই একই IP address থেকে তোমার password reset-ও আর পৌঁছায় না।
• Bounce, complaint আর unsubscribe সামলাতেই হয়, নইলে provider তোমাকে আটকে দেয়।
• SMS একেবারে আলাদা জগৎ: দেশভেদে নিয়ম, নিবন্ধিত sender ID, carrier, প্রতি message-এর দাম।

প্রতিটা অংশের জন্য AWS-এর managed service আছে। এই lesson-এ আছে SAA-C03 পরীক্ষা যে দুটোর নাম নেয়, Amazon SES আর Amazon Pinpoint, ২০২৬-এ Pinpoint-এর জায়গায় কী এল, আর এরা SNS থেকে কীভাবে আলাদা (lesson 13.4), কারণ SNS-ও email আর SMS পাঠায়।

#Amazon SES

Amazon Simple Email Service (SES) একটা পুরোপুরি managed, যতটুকু ব্যবহার ততটুকু দামের service, যেটা দিয়ে তোমার application যেকোনো পরিমাণে email পাঠাতে আর নিতে পারে, API বা SMTP দিয়ে। দাম মোটামুটি প্রতি ১,০০০ email-এ ০.১০ USD, কোনো server নেই, ন্যূনতম খরচ নেই, patch করার মতো mail software নেই। এটা চলে Region ধরে: identity, quota, sandbox আর reputation সবই এক Region-এর এক account-এর জিনিস (বাংলাদেশ থেকে সাধারণত বেছে নেওয়া হয় Singapore ap-southeast-1 আর Mumbai ap-south-1)।

#Transactional, marketing আর bulk email

Application যে দুই রকম email পাঠায়, SES দুটোই সামলায়, আর production access চাওয়ার সময় AWS জানতে চায় তোমার বেশিরভাগ mail কোনটা:

বাস্তবে এই ভাগটা জরুরি: একটা খারাপ marketing list সেই reputation নষ্ট করতে পারে যার ওপর তোমার password reset নির্ভর করে। তাই অভিজ্ঞ প্রেরকরা দুটোকে আলাদা configuration set-এ রাখে, প্রায়ই আলাদা dedicated IP pool-এ, কখনো কখনো আলাদা account-এ।

#পাঠানোর দুই পথ: API নাকি SMTP

• SES API (SDK বা CLI): API v2-এর SendEmail (aws sesv2)। অন্য সব AWS call-এর মতো IAM দিয়ে যাচাই হয় (lesson 2.4), তাই Lambda function বা EC2 instance নিজের role ব্যবহার করে, আর policy দিয়ে ses:SendEmail একটা নির্দিষ্ট identity-তে সীমিত করা যায়। পাঠাতে পারো একটা simple message (subject, text, HTML), নিজে বানানো একটা raw MIME message (নিজের header, attachment), অথবা placeholder-সহ একটা template। একটা message attachment-সহ 40 MB পর্যন্ত হতে পারে।
• SMTP interface: SES-এর SMTP endpoint আছে, যেমন email-smtp.ap-southeast-1.amazonaws.com, port 25, 587 বা 2587-এ (STARTTLS) আর 465 বা 2465-এ (TLS wrapper)। যে পুরোনো software শুধু SMTP বোঝে (WordPress, কোনো ERP, printer, পুরোনো Java application), তার জন্য এটা। এতে লাগে SMTP credential: একটা IAM identity থেকে বানানো user name আর password, যেটা সাধারণ access key-এর মতো না।

Console থেকেও test mail পাঠানো যায়; বেশিরভাগ মানুষ sandbox-এর সাথে প্রথম পরিচিত হয় সেখানেই।

#Sandbox আর production access

প্রতিটা নতুন account শুরু হয় SES sandbox-এ, প্রতিটা Region-এ আলাদাভাবে। Sandbox-এ সব feature ব্যবহার করা যায়, কিন্তু:

• পাঠানো যায় শুধু verified ঠিকানা বা domain-এ (অথবা mailbox simulator-এ, যেটা কয়েকটা test ঠিকানা: delivery, bounce, complaint বা suppression-এর ভান করে);
• ২৪ ঘণ্টায় সর্বোচ্চ ২০০টা আর সেকেন্ডে ১টা message।

বেরোতে হলে console-এ বা aws sesv2 put-account-details --production-access-enabled দিয়ে production access চাও: বলো mail বেশিরভাগ marketing নাকি transactional, website-এর URL দাও, আর নিশ্চিত করো যে শুধু যারা চেয়েছে তাদেরই পাঠাও আর bounce ও complaint সামলাও। AWS মোটামুটি ৯৬ ঘণ্টার মধ্যে প্রথম উত্তর দেয়; আগে domain verify করে রাখলে কাজে দেয়। অনুমোদনের পর account বড় quota পায়, যেটা AWS প্রতিটা account-এর জন্য আলাদা ঠিক করে (অনেকে শুরুতে দিনে ৫০,০০০ পেয়েছে বলে জানায়, তবে এটা AWS-এর ঘোষিত default নয়), ভালোভাবে পাঠালে বা চাইলে সেটা বাড়ে, আর যেকোনো প্রাপকে mail পাঠানো যায়। তবে From ঠিকানা সবসময়ই কোনো verified identity-র হতে হবে।

#Verified identity: একটা domain নাকি একটা ঠিকানা

Identity হলো যার নামে তুমি পাঠাতে পারো:

• Email address identity: SES ওই ঠিকানায় একটা যাচাইয়ের link পাঠায়; click করলে শুধু ওই একটা ঠিকানা থেকে পাঠাতে পারবে। দ্রুত test-এর জন্য ভালো।
• Domain identity: DNS record প্রকাশ করে প্রমাণ করো domain-টা তোমার (Easy DKIM-এ তিনটা DKIM CNAME record দিয়েই যাচাই হয়ে যায়)। তারপর ওই domain-এর যেকোনো ঠিকানা থেকে পাঠানো যায় (orders@, no-reply@, support@), আর তার mail-এ DKIM সই বসে। Production-এ এটাই চলে।

Identity Region ধরে চলে; Singapore-এ verify করা domain Mumbai-তে আবার verify করতে হয় (নিজের DKIM key আনলে একই DNS record আবার কাজে লাগে, নইলে Easy DKIM প্রতি Region-এ নতুন token দেয়)।

#Mail-টা যে সত্যিই তোমার, তার প্রমাণ: SPF, DKIM আর DMARC

Email বানানোর সময় From লাইন যাচাইয়ের কোনো ব্যবস্থাই রাখা হয়নি: যেকোনো server লিখে দিতে পারে From: no-reply@shop.example। তিনটা DNS-নির্ভর ব্যবস্থা এটা ঠিক করে। এদের record type তুমি দেখেছ lesson 8.1-এ (TXT আর CNAME); এখানে দেখো SES-এর জন্য এরা কী করে।

#SPF আর custom MAIL FROM domain

SPF (Sender Policy Framework) একটা TXT record, যেখানে লেখা থাকে কোন কোন server একটা domain-এর হয়ে mail পাঠাতে পারে। গ্রহণকারী এটা মেলায় MAIL FROM (envelope sender, অন্য নাম Return-Path) domain-এর সাথে, চোখে দেখা From লাইনের সাথে না।

Default-ভাবে SES নিজের MAIL FROM ব্যবহার করে, amazonses.com-এর একটা subdomain, তাই SPF পাস করে ঠিকই, তবে amazonses.com-এর জন্য, তোমার domain-এর জন্য না। SPF-কে তোমার domain-এর জন্য পাস করাতে একটা custom MAIL FROM domain বসাও, যেমন mail.shop.example, দুটো record দিয়ে:

mail.shop.example.   MX   10 feedback-smtp.ap-southeast-1.amazonses.com
mail.shop.example.   TXT  "v=spf1 include:amazonses.com ~all"

MX record দিয়ে bounce ফিরে আসে SES-এর কাছে; TXT record-টা SPF policy।

#DKIM আর Easy DKIM

DKIM প্রতিটা message-এ একটা digital signature বসায়, একটা private key দিয়ে বানানো; public key থাকে DNS-এ, <selector>._domainkey.<domain>-এর নিচে। গ্রহণকারী সইটা যাচাই করে, তাতে প্রমাণ হয় message-টা সত্যিই domain-এর মালিকের কাছ থেকে এসেছে আর পথে বদলায়নি।

Easy DKIM-এ key pair বানায় আর রাখে SES নিজেই। Domain identity বানালে SES তোমাকে তিনটা CNAME record দেয়:

abc123._domainkey.shop.example.   CNAME   abc123.dkim.amazonses.com
def456._domainkey.shop.example.   CNAME   def456.dkim.amazonses.com
ghi789._domainkey.shop.example.   CNAME   ghi789.dkim.amazonses.com

SES এগুলো দেখতে পেলেই domain verified, আর সেখান থেকে যাওয়া প্রতিটা message-এ সই বসে। Key নিজের হাতে রাখতেই হলে BYODKIM (bring your own DKIM) দিয়ে নিজের private key import করো আর তার public key TXT record হিসেবে প্রকাশ করো।

#DMARC: মিল (alignment) আর policy

DMARC (Domain-based Message Authentication, Reporting and Conformance) একটা TXT record, _dmarc.<domain>-এ। এটা গ্রহণকারীকে দুটো জিনিস বলে:

1. পাসের নিয়ম (alignment)। একটা message DMARC পাস করে যদি SPF এমন domain-এর জন্য পাস করে যেটা From domain-এর সাথে মেলে, অথবা DKIM এমন domain-এর সই নিয়ে পাস করে যেটা From domain-এর সাথে মেলে। একটাই যথেষ্ট।
2. ব্যর্থ হলে কী করতে হবে। p=none (শুধু report), p=quarantine (spam folder) বা p=reject (ফিরিয়ে দাও), আর rua=-তে লেখা থাকে দৈনিক সারসংক্ষেপ report কোথায় যাবে।

_dmarc.shop.example.   TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@shop.example"

SES-এ তোমার domain-এ Easy DKIM থাকলেই DMARC পাস করে (সইয়ের domain তোমার)। Custom MAIL FROM থাকলে SPF-ও মেলে, DKIM কখনো ভাঙলে সেটা দ্বিতীয় পথ। শুরু করো p=none দিয়ে, কয়েক সপ্তাহ report পড়ে খুঁজে বের করো তোমার domain-এর নামে আর কোন কোন system mail পাঠায় (CRM, helpdesk, বেতনের system), তারপর ধাপে ধাপে quarantine আর reject-এ যাও।

#Reputation: bounce, complaint আর suppression list

তোমার mail কোথায় যাবে, mailbox provider সেটা ঠিক করে মূলত reputation দেখে: তোমার কত message bounce হয়, কতজন spam বলে চিহ্নিত করে, তুমি কতটা নিয়মিতভাবে পাঠাও। SES অনেক customer-এর মধ্যে IP address ভাগ করে দেয়, তাই প্রতিটা account কড়া নজরে রেখে সে সবাইকে রক্ষা করে।

#Bounce আর complaint

• Hard bounce মানে স্থায়ী ব্যর্থতা: “550 user unknown”, domain-এরই অস্তিত্ব নেই। Bounce rate-এ গোনা হয় শুধু hard bounce। Soft bounce (mailbox ভর্তি, server ব্যস্ত) সাময়িক, SES কিছুক্ষণ ধরে আবার চেষ্টা করে।
• Complaint মানে প্রাপক “Report spam” চেপেছে। যে provider feedback loop চালায়, সে complaint-টা SES-কে ফেরত পাঠায়; SES সেটা complaint rate-এ গোনে আর তোমাকে জানাতে পারে।

SES account-এর দুটো হারই CloudWatch metric হিসেবে প্রকাশ করে, Reputation.BounceRate আর Reputation.ComplaintRate, আর হিসাব করে তোমার সাম্প্রতিক পাঠানোর একটা প্রতিনিধিত্বমূলক পরিমাণ ধরে, কোনো নির্দিষ্ট একটা দিন ধরে না।

#SES কখন account review করে বা পাঠানো বন্ধ করে

SES-এর নিজের লেখা সংখ্যা (এই lesson-এর জন্য যাচাই করা):

• Under review: SES account মালিককে email করে আর একটা support case খোলে। পাঠানো তখনও চলে, কিন্তু review-এর সময় শেষ হওয়ার আগে কারণ ঠিক করতে হবে (খারাপ campaign থামাও, list পরিষ্কার করো), আর case-এ উত্তর দিয়ে জানাতে হবে কী কী বদলেছ।
• Paused: ওই Region-এ account আর কিছুই পাঠাতে পারে না, transactional mail-ও না। সমস্যা ঠিক করে review চাইতে হয়। aws sesv2 get-account-এ দেখা যায় EnforcementStatus (HEALTHY, PROBATION, SHUTDOWN)।
• গুরুতর অপব্যবহার (phishing, spam trap, হাতে-কলমে তদন্ত) হলে review ছাড়াই সরাসরি pause হতে পারে।

দুটো metric-এর ওপর CloudWatch alarm বসাও review-এর সীমার অনেক নিচে (যেমন bounce ৩% আর complaint ০.০৫%), আর ভাবো “marketing configuration set বন্ধ করো” ধরনের একটা স্বয়ংক্রিয় action রাখা যায় কিনা, যাতে একটা খারাপ campaign তোমার password reset বন্ধ করে দিতে না পারে।

#Suppression list

Account-level suppression list-এ জমা থাকে সেই ঠিকানাগুলো যেগুলো hard bounce করেছে বা complaint করেছে। এটা চালু থাকলে (BOUNCE, COMPLAINT বা দুটোর জন্যই), SES এমন ঠিকানা নিজেই তালিকায় তোলে আর তারপর provider-কে না ছুঁয়েই ওই ঠিকানায় আর পাঠাতে অস্বীকার করে, ফলে একটা মৃত ঠিকানা তোমার bounce rate দুবার নষ্ট করতে পারে না। চাইলে নিজেও ঠিকানা যোগ বা বাদ দিতে পারো (put-suppressed-destination, delete-suppressed-destination), sandbox-এর বাইরে এলে একসাথে অনেক ঠিকানা import করতে পারো, আর configuration set ধরে এই setting বদলাতে পারো। এটা তোমার নিজের ব্যবস্থার পরিপূরক, বদলি না: তোমার application-কেও ঠিকানাটা অকেজো বলে চিহ্নিত করতে হবে।

#Shared, dedicated আর managed IP address

Dedicated IP pool দিয়ে traffic ভাগ করা যায়: একটা pool transactional mail-এর, আরেকটা marketing-এর, configuration set দেখে বেছে নেওয়া হয়। বড় প্রেরকদের জন্য SES নিজের IP range আনার সুবিধাও দেয়।

#Configuration set আর event publishing

Configuration set হলো নাম দেওয়া কিছু নিয়মের একটা গুচ্ছ, যার নাম তুমি পাঠানোর সময় দাও (ConfigurationSetName)। এটা পারে:

• open আর click tracking চালু করতে (SES একটা ছোট্ট ছবি বসায় আর link-গুলো নিজের tracking domain হয়ে ঘুরিয়ে দেয়; চাইলে সেই domain নিজেরটা দিয়ে বদলানো যায়);
• dedicated IP pool বেছে নিতে, suppression setting বদলাতে, নিজের tracking domain বসাতে, আর পৌঁছানোর সময় TLS বাধ্যতামূলক করতে;
• event পাঠাতে event destination-এ।

Event-গুলো হলো SEND, REJECT, DELIVERY, BOUNCE, COMPLAINT, DELIVERY_DELAY, RENDERING_FAILURE (template-এর কোনো variable ছিল না), OPEN, CLICK আর SUBSCRIPTION। Destination-গুলো:

Configuration set ছাড়াও identity-র ওপর সহজ feedback notification বসানো যায় (bounce, complaint, delivery একটা SNS topic-এ, বা email-এ forward করে)।

#Virtual Deliverability Manager

Virtual Deliverability Manager (চালু হয় নভেম্বর ২০২২-এ) SES-এর একটা ইচ্ছামতো চালু করা feature, প্রতি email-এ চার্জ। এটা যোগ করে একটা deliverability dashboard (mailbox provider, sending identity আর configuration set ধরে delivery, open, click, bounce আর complaint-এর হার) আর একটা advisor, যেটা DKIM বা DMARC record না থাকার মতো সমস্যা খুঁজে বের করে আর কীভাবে ঠিক করতে হবে বলে। নতুন একটা “global deliverability” অংশ inbox placement test আর blocklist monitoring যোগ করে। Pinpoint-এর পুরোনো deliverability dashboard-এর জায়গা এটাই নিয়েছে। পরীক্ষা এটার নাম ধরে জিজ্ঞেস করে না; বাস্তবে “একটা provider-এ আমাদের mail spam-এ যাচ্ছে কেন?” প্রশ্নের উত্তর এটা।

#Email নেওয়া

Notes-এর keyword “email-এর inbound routing” মানে গ্রহণকারী হিসেবে SES: SES তোমার domain-এর mail নিয়ে তোমার code-এর হাতে দিতে পারে। এতে কোনো mailbox নেই, IMAP বা POP3-ও নেই: মানুষ যদি Outlook-এ mail পড়তে চায়, সেটা Amazon WorkMail বা কোনো SaaS product-এর মতো mail service-এর কাজ, SES-এর না।

#Receipt rule

1. Domain verify করো, তারপর তার MX record দাও এমন একটা Region-এর SES receiving endpoint-এ যেটা email নেয়, যেমন 10 inbound-smtp.ap-southeast-1.amazonaws.com (Singapore আর Mumbai দুটোই নেয়; সব Region নেয় না)।
2. একটা receipt rule set বানাও আর সেটাকে active করো (এক account আর Region-এ একবারে একটাই active থাকে)।
3. Receipt rule যোগ করো, প্রতিটায় recipient condition (একটা ঠিকানা, একটা domain বা subdomain) আর ক্রম ধরে কয়েকটা action:

SES আসা mail-এর SPF, DKIM আর DMARC যাচাই করে, আর spam ও virus খোঁজে (প্রতি rule-এ default-ভাবে চালু); সে শুধু রায় জানায়, কী করা হবে তা ঠিক করে তোমার rule বা Lambda code। IP address filter প্রেরকের IP range আটকায় বা ছাড় দেয় SMTP কথোপকথনের মধ্যেই, তাই আটকানো mail কখনো জমা হয় না, তার দামও লাগে না; receipt rule চলে message গ্রহণ করার পরে।

#Mail Manager (২০২৪)

Mail Manager (২০২৪) SES-এর নতুন একটা email gateway, প্রতিষ্ঠানের আসা-যাওয়া mail-এর প্রবাহের জন্য: ingress endpoint (খোলা, অথবা বিশ্বস্ত SMTP server-এর জন্য authenticated) সঙ্গে traffic policy (প্রেরকের IP, TLS version, প্রাপক দেখে ছাড় বা আটকানো), rule set যেটা route করে, archive করে, অন্য SMTP server-এ (যেমন Microsoft 365) relay করে বা S3-এ লেখে, compliance-এর জন্য search আর retention-সহ নিজস্ব archiving, আর বাড়তি নিরাপত্তা scan-এর add-on। মনে রাখো: receipt rule মানে “আমার application-এর mail”, Mail Manager মানে “আমার company-র mail-এর প্রবাহ”। এটা যাচাই করা একটা পার্শ্ব-তথ্য: inbound processing-এর পরীক্ষার উত্তর এখনও receipt rule-সহ SES receiving।

#SES নাকি SNS? Notes-এর সংশোধন

Notes বলে: “SNS হলো message বা notification-এর জন্য (app-to-app বা SMS); SES শুধু email-এর জন্য।” দ্বিতীয় অংশ ঠিক, প্রথমটা অসম্পূর্ণ। SNS-ও email পাঠায়, আর SMS পাঠানোর AWS service শুধু SNS না: AWS End User Messaging-ও পাঠায়। আসল সীমারেখা হলো subscriber-দের notification আর customer-দের কাছে আসল email বা SMS-এর মধ্যে:

আর notes-এর বাকি কথার জন্য:

• SNS করে app-to-app (A2A: SQS, Lambda, Firehose, HTTP/S) আর app-to-person (A2P: email, SMS, mobile push), topic আর fan-out দিয়ে।
• SNS থেকে SMS নিচে পৌঁছে দেয় AWS End User Messaging SMS (lesson 13.4)। OTP আর একজনকে পাঠানো transactional SMS-এর জন্য সরাসরি End User Messaging ডাকলে পাও sender ID, phone pool, খরচের সীমা আর delivery event।
• SES শুধু email, তবে পাঠানো আর নেওয়া দুটোই।

#Amazon Pinpoint, আর তার কী হলো

#Pinpoint কী করত

Amazon Pinpoint ছিল AWS-এর marketing আর customer engagement service। SES আর SNS তোমার দেওয়া প্রতিটা message পাঠিয়ে দেয়; Pinpoint-এর হাতে ছিল পুরো campaign:

• Endpoint আর segment: প্রত্যেক customer একটা endpoint (email, phone, device), attribute-সহ (শহর, শেষ কেনাকাটা), আর সেগুলো দিয়ে বানানো segment (“গত ঈদে কেনা ঢাকার customer”)।
• Campaign (একটা segment-কে একটা message, একবার বা নির্দিষ্ট সময়সূচিতে) আর journey (কয়েক ধাপের প্রবাহ: অপেক্ষা, খুলেছে কিনা দেখে ভাগ, channel বদল)।
• Template, message-এর বিভিন্ন রূপ নিয়ে A/B testing, quiet hours আর কতবার পাঠানো যাবে তার সীমা।
• Channel: email, SMS, mobile push, voice, in-app message, আর two-way SMS, যাতে customer উত্তর দিতে পারত।
• Analytics: open, click, conversion, আর Kinesis বা Firehose-এ event-এর স্রোত।

Notes-এর পরীক্ষার কৌশল: “Targeted multi-channel marketing campaign”, “user engagement”, “message-এর A/B testing” → “চোখ বন্ধ করে” Pinpoint। Slide আরও বলে, Pinpoint দিনে কোটি কোটি message সামলাতে পারত, উত্তর নিতে পারত, আর TEXT_SUCCESS, TEXT_DELIVERED-এর মতো event পাঠাত।

#Support শেষ: ৩০ অক্টোবর ২০২৬

অবস্থা, এই lesson লেখার দিন (১ নভেম্বর ২০২৬) Pinpoint-এর migration guide-এর সাথে মিলিয়ে দেখা:

• ২০ মে ২০২৫: Pinpoint নতুন customer নেওয়া বন্ধ করে।
• ৩০ অক্টোবর ২০২৬ (লেখার সময় থেকে দুই দিন আগে): support শেষ। Pinpoint-এর console আর engagement feature-গুলো, মানে endpoint, segment, campaign, journey, analytics আর তার metric-এর API, in-app messaging আর recommender, আর পাওয়া যায় না।
• যা চলছে: message পৌঁছানোর API-গুলো, যাদের নাম Q3 ২০২৪-এ হয়েছে AWS End User Messaging: SMS, MMS, voice, mobile push, WhatsApp, OTP API (SendOTPMessage, VerifyOTPMessage) আর phone নম্বর যাচাই। Push, OTP আর phone যাচাই সব account-এর জন্য চলে; Pinpoint API দিয়ে SMS, voice আর email পাঠানো চলে শুধু তাদের জন্য যারা ২০ মে ২০২৫-এর আগে নিয়েছিল, আর AWS তাদেরও End User Messaging আর SES-এ যেতে বলে; সরাসরি পাঠানো message-এর event আর metric Kinesis, Firehose আর CloudWatch-এ যেতেই থাকে।
• Engagement গেল কোথায়: segment, campaign আর journey-র জন্য AWS বলে Amazon Connect (outbound campaign, যেটা এখন journey-ও চালায়, আর Customer Profiles); email-এর জন্য Amazon SES (আর deliverability dashboard-এর জন্য SES Virtual Deliverability Manager); event সংগ্রহের জন্য Kinesis।

তাই ২০২৬-এ কোনো নতুন project “Pinpoint” চাইলে সেটা বানায় তিনটা service জুড়ে:

Amazon Connect হলো AWS-এর cloud contact centre (lesson 18.1): phone নম্বর, queue আর agent। এর outbound campaign voice, SMS, email আর WhatsApp জুড়ে journey চালাতে পারে, agent-সহ বা ছাড়া। Pinpoint-এর engagement অংশ এজন্যই সেখানে গেছে।

#কোন messaging service বাছবে

পরীক্ষা বারবার যে তুলনা চায়, পাশে SQS রেখে (SQS মানুষ না, program-এর কাছে পাঠায়; lesson 13.1):

#কোথায় গোলমাল হয়

#System design-এ messaging

• User-এর request-এর ভেতরে কখনো email পাঠাবে না। Order লেখো, একটা event প্রকাশ করো (DynamoDB Streams, SNS, EventBridge বা SQS), আর একটা worker-কে SES ডাকতে দাও। Sign-up আর checkout দ্রুত থাকে, email-এর খারাপ এক মিনিটে ব্যর্থও হয় না (lesson 15.5 আর 15.8)।
• হঠাৎ চাপের জন্য SES-এর সামনে queue রাখো। Flash sale-এ সেকেন্ডপ্রতি quota-র চেয়ে বেশি email তৈরি হতে পারে; নিয়ন্ত্রিত concurrency-র Lambda consumer-সহ একটা SQS queue স্থির গতিতে পাঠায় আর throttle হলে আবার চেষ্টা করে।
• Reputation আলাদা রাখো। Transactional আর marketing mail আলাদা configuration set, IP pool বা account-এ; marketing-এর একটা ভুল যেন password reset থামাতে না পারে।
• Feedback-এর চক্র বন্ধ করো। Bounce আর complaint event → SNS বা EventBridge → একটা function যেটা ঠিকানা অকেজো চিহ্নিত করে; আর reputation metric-এর ওপর alarm।
• Domain একবার যাচাই করো, প্রতিটা প্রেরকের জন্য। তোমার domain-এর নামে যে system-ই পাঠায়, তার DKIM লাগবে (আর সম্ভব হলে SPF-এর মিল); তারপর DMARC reject-এ যেতে পারে।
• একাধিক Region: identity, quota আর sandbox-এর অবস্থা Region ধরে। DR-এর জন্য দরকার হওয়ার আগেই দ্বিতীয় Region-এ domain verify করো আর production access নিয়ে রাখো।
• Channel আর campaign গুলিয়ে ফেলো না। SES আর End User Messaging message পৌঁছে দেয়; segment, journey আর agent-এর জায়গা Amazon Connect (বা কোনো marketing platform)।
• খরচ: SES মোটামুটি প্রতি ১,০০০ email-এ ০.১০ USD; SMS-এর দাম দেশভেদে প্রতি message, আর প্রতি message-এ অনেক বেশি; এজন্যই গ্রহণযোগ্য হলে OTP প্রায়ই email বা push-এ পাঠানো হয়।

#নিজে করে দেখো

এই command-গুলোতে ধরা হয়েছে ap-southeast-1 (Singapore), domain shop.example আর account 111122223333। নিজের domain ব্যবহার করো, আর মনে রেখো sandbox-এর account শুধু verified ঠিকানায় পাঠাতে পারে।

# 1. Verify a domain identity; Easy DKIM returns three tokens to publish as CNAME records
aws sesv2 create-email-identity --email-identity shop.example
# {
#   "IdentityType": "DOMAIN",
#   "VerifiedForSendingStatus": false,
#   "DkimAttributes": {
#     "SigningEnabled": true,
#     "Status": "PENDING",
#     "Tokens": ["abc123exampletoken", "def456exampletoken", "ghi789exampletoken"],
#     "SigningAttributesOrigin": "AWS_SES"
#   }
# }
# Publish: abc123exampletoken._domainkey.shop.example CNAME abc123exampletoken.dkim.amazonses.com (and the other two)

# 2. A custom MAIL FROM domain (then publish its MX and SPF TXT records)
aws sesv2 put-email-identity-mail-from-attributes --email-identity shop.example \
  --mail-from-domain mail.shop.example --behavior-on-mx-failure USE_DEFAULT_VALUE

# 3. Is the account still in the sandbox? What are the quotas and the enforcement status?
aws sesv2 get-account
# {
#   "SendQuota": { "Max24HourSend": 200.0, "MaxSendRate": 1.0, "SentLast24Hours": 3.0 },
#   "SendingEnabled": true,
#   "ProductionAccessEnabled": false,
#   "EnforcementStatus": "HEALTHY"
# }

# 4. Request production access
aws sesv2 put-account-details --production-access-enabled --mail-type TRANSACTIONAL \
  --website-url https://shop.example --contact-language EN \
  --additional-contact-email-addresses ops@shop.example

# 5. A configuration set that sends bounces and complaints to an SNS topic
aws sesv2 create-configuration-set --configuration-set-name transactional
aws sesv2 create-configuration-set-event-destination --configuration-set-name transactional \
  --event-destination-name feedback-to-sns \
  --event-destination '{"Enabled":true,"MatchingEventTypes":["BOUNCE","COMPLAINT"],
    "SnsDestination":{"TopicArn":"arn:aws:sns:ap-southeast-1:111122223333:ses-feedback"}}'

# 6. Send a simple HTML + text email through the configuration set
aws sesv2 send-email --from-email-address orders@shop.example \
  --destination ToAddresses=success@simulator.amazonses.com \
  --configuration-set-name transactional \
  --content '{"Simple":{"Subject":{"Data":"Order #10234 confirmed"},
    "Body":{"Text":{"Data":"Thank you for your order."},
            "Html":{"Data":"<h1>Thank you!</h1><p>Order <b>#10234</b> is confirmed.</p>"}}}}'
# { "MessageId": "010e019a1b2c3d4e-5f6a7b8c-0000-0000-0000-000000000000-000000" }

# 7. Test a bounce safely with the mailbox simulator, then look at the suppression list
aws sesv2 send-email --from-email-address orders@shop.example \
  --destination ToAddresses=bounce@simulator.amazonses.com \
  --content '{"Simple":{"Subject":{"Data":"test"},"Body":{"Text":{"Data":"test"}}}}'
aws sesv2 put-account-suppression-attributes --suppressed-reasons BOUNCE COMPLAINT
aws sesv2 put-suppressed-destination --email-address old.customer@customer.example --reason BOUNCE
aws sesv2 list-suppressed-destinations --reasons BOUNCE --query 'SuppressedDestinationSummaries[].EmailAddress'
# [ "old.customer@customer.example" ]

# 8. Receive mail: a rule set that stores support@ mail in S3 and invokes a function
aws ses create-receipt-rule-set --rule-set-name inbound
aws ses create-receipt-rule --rule-set-name inbound --rule '{
  "Name": "support", "Enabled": true, "ScanEnabled": true, "TlsPolicy": "Require",
  "Recipients": ["support@shop.example"],
  "Actions": [
    {"S3Action": {"BucketName": "shop-inbound-mail-example", "ObjectKeyPrefix": "support/"}},
    {"LambdaAction": {"FunctionArn": "arn:aws:lambda:ap-southeast-1:111122223333:function:open-ticket",
                      "InvocationType": "Event"}}]}'
aws ses set-active-receipt-rule-set --rule-set-name inbound
# Then: shop.example MX 10 inbound-smtp.ap-southeast-1.amazonaws.com

# 9. SNS email for comparison: the subscriber must confirm before anything arrives
aws sns subscribe --topic-arn arn:aws:sns:ap-southeast-1:111122223333:ops-alerts \
  --protocol email --notification-endpoint oncall@shop.example
# { "SubscriptionArn": "pending confirmation" }

# 10. An SMS through AWS End User Messaging (the former Pinpoint SMS API)
aws pinpoint-sms-voice-v2 describe-account-attributes
# { "AccountAttributes": [ { "Name": "ACCOUNT_TIER", "Value": "SANDBOXED" } ] }
aws pinpoint-sms-voice-v2 send-text-message --destination-phone-number +8801XXXXXXXXX \
  --origination-identity SHOPBD --message-type TRANSACTIONAL \
  --message-body "Your order #10234 has shipped."
# { "MessageId": "a1b2c3d4-1111-2222-3333-444455556666" }
# (+8801XXXXXXXXX stands for your own verified test number while the account is sandboxed)

# 11. Clean up
aws ses set-active-receipt-rule-set
aws ses delete-receipt-rule-set --rule-set-name inbound
aws sesv2 delete-configuration-set --configuration-set-name transactional
aws sesv2 delete-email-identity --email-identity shop.example

Console-এও দেখো: SES খুলে Get set up-এ যাও, sandbox-এর banner আর production access-এর form দেখো; কোনো identity-র Authentication tab খুলে DKIM record আর তাদের অবস্থা দেখো; Reputation metrics খুলে দুটো হার আর তাদের সীমা দেখো।

#সারসংক্ষেপ

মূল কথা

• SES email পাঠায় আর নেয়: transactional (order confirmation, password reset) আর marketing বা bulk; API (IAM) বা SMTP interface (SMTP credential) দিয়ে; মোটামুটি প্রতি ১,০০০ email-এ ০.১০ USD; সবকিছু Region ধরে।
• Sandbox (প্রতি Region-এ): শুধু verified প্রাপক বা mailbox simulator, ২৪ ঘণ্টায় ২০০টা, সেকেন্ডে ১টা; বেরোতে production access চাও (মোটামুটি ৯৬ ঘণ্টায় উত্তর)। From identity সবসময় verified হতে হবে।
• যাচাই: SPF (custom MAIL FROM subdomain: feedback-smtp-এ MX, include:amazonses.com-সহ TXT), DKIM (Easy DKIM: তিনটা CNAME, SES প্রতিটা message-এ সই করে), DMARC (SPF বা DKIM From domain-এর সাথে মিললেই পাস; p=none, quarantine, reject)।
• Reputation: bounce rate ২%-এর নিচে রাখা ভালো, ৫%-এ review, ১০%-এ pause; complaint rate ০.১%-এর নিচে রাখা ভালো, ০.১%-এ review, ০.৫%-এ pause। Suppression list, Reputation.* metric-এ alarm, আর transactional থেকে marketing আলাদা রাখো।
• Configuration set: open আর click tracking, IP pool, event publishing CloudWatch, Data Firehose, SNS, EventBridge-এ। Default-ভাবে shared IP; dedicated standard (তুমি warm up করো) বা managed (SES warm up করে আর বাড়ায়-কমায়)।
• নেওয়া: MX SES-এর দিকে, active receipt rule set, action S3 (40 MB), Lambda, SNS (150 KB), bounce, stop; IP filter গ্রহণের আগেই আটকায়। Mail Manager (২০২৪) company-জুড়ে email gateway; Virtual Deliverability Manager deliverability-র dashboard আর advisor।
• SNS বনাম SES: SNS-এর email হলো confirm করা subscriber-দের সাদা text notification; SES হলো তোমার domain থেকে যে কাউকে আসল email। SNS SMS আর push-ও পাঠায় (SMS যায় End User Messaging দিয়ে)।
• Pinpoint: segment, campaign, journey, A/B test, কয়েক channel; ২০ মে ২০২৫ থেকে নতুন customer নেই, ৩০ অক্টোবর ২০২৬-এ support শেষ। Channel চলছে AWS End User Messaging নামে (SMS, voice, push, OTP, phone যাচাই); engagement গেছে Amazon Connect outbound campaign আর Customer Profiles-এ; email SES-এ। পরীক্ষায় “targeted multi-channel campaign / A/B testing” → option-এ থাকলে Pinpoint।

নিজেকে যাচাই করো: SES, Pinpoint আর messaging৩০টি প্রশ্ন