Tag Archives: AWS

Streamlining outbound emails with Amazon SES Mail Manager

Post Syndicated from Manoj Gaddam original https://aws.amazon.com/blogs/messaging-and-targeting/streamlining-outbound-emails-with-amazon-ses-mail-manager/

In today’s digital landscape, efficient email management is crucial for businesses of all sizes. Amazon Simple Email Service (Amazon SES) has long been a go-to solution for handling transactional and marketing emails. Through Mail Manager, Amazon SES offers powerful tools to enhance your email infrastructure, particularly for outbound email handling and archiving.

In this post, we explore how Mail Manager can modernize your approach to outbound email management. We’ll dive into the various options available for controlling email flows and archiving all outgoing emails. By the end of this article, you’ll have a clear understanding of how you can use Mail Manager to:

  • Strengthen your email infrastructure
  • Simplify outbound email workflow management
  • Help meet compliance through robust email archiving

In this post, we consider a real-world customer use case from a university where students should receive clean emails free from malware and phishing attempts. Amazon SES Mail Manager provides a comprehensive email pipeline that handles security screening, message archival, and reliable delivery. By implementing this system, the university significantly improved its email infrastructure, helping to ensure that important communications reach students safely and efficiently.

Walkthrough

In this walkthrough, we guide you through the process of configuring Amazon SES Mail Manager with the following components:

  • Traffic policy: You’ll create a traffic policy designed to help ensure that students receive only clean, secure emails. The default action is set to Deny all, providing a strict baseline. The policy includes two key statements connected by an OR condition. Policy Statement 1 allows emails if the recipient address is in the Valid-Address list. Policy Statement 2 allows emails that meet all of the following conditions: not listed in Abusix Guardian Mail, recipient address is not in the Invalid-Email-List, and uses TLS protocol version 1.3 or higher. This configuration effectively filters potential threats while allowing legitimate communications to reach students’ inboxes, maintaining a secure email environment for the university.
  • Rule set: You’ll create a rule set containing two rules that execute in sequential order:
    • Rule 1: Scan and isolate malicious content: Scans messages and, if the scan fails, stores emails in an Amazon Simple Storage Service (Amazon S3) bucket for further validation and halts sending email.
    • Rule 2: Archive and send clean emails to recipients: Archives all outgoing emails for audit and compliance after passing the security scan and routes emails to recipients.
  • Ingress endpoint: You’ll create a Mail Manager ingress endpoint that will receive, route, and manage emails based on your configured policies and rules.

After setting up these components, you’ll use sample Python code to send an email through the ingress endpoint. To verify functionality, we’ll check the email archive to confirm that all incoming emails are archived for compliance or audit purposes and confirm email is received in the intended inbox. The workflow is shown in the following figure.

Prerequisites

Before beginning, make sure that you have completed domain verification in your desired AWS Region and moved out of the Amazon SES sandbox. Domain verification is a crucial first step that validates your authority to send emails through SES from your domain. In this tutorial, you’ll use a sample Python program to send emails programmatically through an ingress SMTP endpoint. You can run this program either on your local machine or using AWS CloudShell.

You should have:

Before creating traffic policies and rule sets, you will first set up Email Add Ons, and email archiving, and AWS Identity and Access Management (IAM) roles, which will be needed while creating traffic policies and rules.

Step 1: Enable Email Add Ons for Amazon SES Mail Manager

To implement security features such as malicious content scanning in your email workflow, first enable the necessary Email Add Ons:

  1. Open the AWS Management Console for Amazon SES.
  2. Choose Mail Manager and then Email Add Ons.
  3. Select your desired Add Ons:
    • Trend Micro Virus Scanning
    • Abusix Guardian Mail
    • Spamhaus Domain Block List (DBL)
    • Vade Advanced Email Security
  4. Choose Enable.

Important Notes:

  • Email Add Ons are third-party security products integrated with Mail Manager
  • Once subscribed, you can use them in your traffic policies or rule sets

As part of this post, you will be using the Abusix Guardian Mail and Vade Advanced Email Security Add Ons to enhance email security posture. It doesn’t mean you have to use all of them—you can subscribe to the ones that best fit your requirements based on your use case.

Step 2: Configure an email archive for compliance and retention

You will create an email archive to store outgoing messages to use as part of configuring Rule 2. This archive will serve as a repository for outgoing messages.

  1. Navigate to Mail Manager and then to Email Archiving.
  2. Choose Create archive.
  3. Complete the archive configuration:
    1. Enter a unique name in the Archive name field.
    2. (Optional) Select a retention period to override the default of 180 days.
    3. (Optional) Set up encryption by either entering your own AWS Key Management System (AWS KMS) key in the KMS key ARN field or selecting Create new key.
  4. Choose Create archive.
  5. After being created, this archive will store your emails according to the rules you’ll define in the next step.

Step 3: Create and S3 bucket and IAM role for S3 access

When emails fail the Vade security scan, they need to be stored securely for further investigation. In this step, we’ll create an S3 bucket to store these flagged emails and set up the necessary IAM permissions.

  1. Create an S3 bucket to quarantine suspicious and malicious emails identified by the Vade scanner. This bucket will store these emails for further investigation by the security team. Note the bucket name, because you’ll need it in the next step.
  2. Create an IAM role that allows Mail Manager to upload suspicious emails to an S3 bucket. This IAM role will be used in Rule 1 when configuring the Write to S3 rule action for storing emails that fail the security scan.
    1. Go to the IAM console.
    2. Choose Roles and then choose Create role.
    3. For trusted entity, select Custom trust policy and paste the following (replace "XXXXXXXXXXX" with your AWS account ID). 
      {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ses.amazonaws.com"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "XXXXXXXXXXX"
        },
        "ArnLike": {
          "aws:SourceArn": "arn:aws:ses:us-east-1:XXXXXXXXXXX:mailmanager-rule-set/*"
        }
      }
    }
  ]
}

    4. Choose Next and create an inline policy with the following permissions (replace "MyDestinationBucketName" with your S3 bucket name). 
      {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPutObject",
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": ["arn:aws:s3:::MyDestinationBucketName/*"]
    },
    {
      "Sid": "AllowListBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::MyDestinationBucketName"]
    }
  ]
}

    5. Enter a name your role and choose Create role.

Step 4: Create and IAM role permission policy for send to internet rule action

Configure an IAM role that permits Mail Manager to send emails to external domains. This role will be referenced in Rule 2 for delivering validated emails to recipients.

  1. You can either:
    1. Use the same IAM role created in Step 3 and add this policy, or
    2. Create a new IAM role and add the following permission policy (Replace example.com with your verified domain, "XXXXXXXXXXX" with your AWS account ID and my-configuration-set with your configuration set name if applicable).

This policy grants the necessary permissions to send emails to recipients on the internet, which will be used in rule 2 of your rule set.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ses:SendEmail", "ses:SendRawEmail"],
      "Resource": [
        "arn:aws:ses:us-east-1:XXXXXXXXXXX:identity/",
        "arn:aws:ses:us-east-1:XXXXXXXXXXX:configuration-set/"
      ]
    }
  ]
}
  1. If adding to an existing role:
    • Go to the IAM console and select your role
    • Choose Add permissions and then select Create inline policy.
    • Paste the preceding JSON and choose Review policy.
    • Enter a name for the policy and choose Create policy.
  2. If you create a new role, name it appropriately and choose Create role.

Step 5: Create a traffic policy

Traffic policies serve as security checkpoints for your email infrastructure, controlling which messages can enter your system based on defined security rules. To create a traffic policy that enforces security requirements for your emails:

  1. Open the Amazon SES console.
  2.  Go to Mail Manager and choose Traffic policies.
  3.  Choose Create traffic policy.
  4. Enter a unique name for your policy.
  5. Set Default action to Allow (this handles emails that don’t match any specific rules).
  6. Add policy statements by choosing Add new policy statement:
    1. Choose Deny for emails that don’t meet security requirements.
    2. Add condition: TLS Protocol Version select Less than and then select 1.2.
    3. Add conditions for any Email Add-Ons you’ve subscribed to, such as Spamhaus, Abusix, and so on.)
  7.  Choose Create traffic policy.

Traffic policies are evaluated in a specific sequence:

  1. First, all Deny policy statements are evaluated in order. If any match, the email is immediately blocked and no further evaluation occurs.
  2. If no Deny statements match, all Allow policy statements are evaluated in order. Multiple statements within a policy are connected by OR logic. If any statement matches, the email is allowed.
  3. Within each individual policy statement, multiple conditions are connected by AND logic. All conditions must be true for the statement to match.
  4. If no policy statements match (neither Deny nor Allow), the default action of the traffic policy (either Allow or Deny) is applied.

In this step, you’ll establish a robust policy that enforces strict TLS security protocols while harnessing the power of specialized email security add-ons such as Abusix Guardian Mail to preemptively identify and block potentially harmful messages before they can penetrate your system. In this traffic policy configuration, you’ll create two policy statements that work together to provide security and flexibility:

Default policy statement:

  • Deny-by-default where all email traffic is initially blocked unless explicitly allowed by below policy statements

Policy statement 1:

  • Allows emails if the recipient address is in a list called Valid-Address

Policy statement 2 (with three conditions connected by AND):

  • Must NOT be listed in Abusix Guardian Mail (FALSE condition)
  • The recipient address must NOT be in the Invalid-Email-List
  • The TLS protocol version must be at least TLS 1.3

In basic terms, this policy will allow emails that either:

  • Have recipients from an approved address list, or
  • Meet all three security conditions (not deny-listed, not on the invalid list, and using secure TLS 1.3)

Step 6: Create a rule set

Rule sets define how your emails are processed after they pass through your traffic policy. In this example, the rule set establishes a sequential email processing workflow. First, you will perform email scanning (marking and segregating spam emails while allowing clean ones to proceed) and archiving outgoing messages, then finally delivering clean messages to recipients. To create a rule set:

  1. Open the Amazon SES console.
  2. Go to Mail Manager and choose Rule sets.
  3. Choose Create rule set.
  4. Enter a unique name for your rule set.
  5. On the rule set’s overview page, choose Edit, then choose Create new rule

Step 7: Create rules

After creating your rule set, you’ll need to add rules that define how your emails are processed. Follow these steps to create and configure your rules:

  1. On the rule set’s overview page, choose Edit, then Create new rule.
  2. In the Rule details sidebar, enter a unique name for your rule.
  3. Add conditions or exceptions as needed:
    1. Select Add new condition to specify what messages the rule applies to.
    2. Select EXCEPT in the case of and select Add new exception for exclusions.
  4. Configure actions by choosing Add new action.
    1. For multiple actions, use the up and down arrows to set the execution order.
  5. When finished creating your rules, choose Save rule set to apply your changes.

Rule 1: Scan and isolate malicious content

This rule targets emails flagged by Vade Advanced Email Security as potentially harmful. It applies to messages identified as scams, suspect content, phishing attempts, or containing malware. When a message is flagged as malicious, the rule marks it with a custom header, stores a copy in Amazon S3 for investigation, and prevents it from reaching recipients. An exception allows emails with Action required in the subject line to bypass this security check.

Use the following settings to create and configure Rule 1:

  • Rule name: Scan and isolate
  • Conditions:
    • Property: Select Verdict (Vade Advanced Email Security).
    • Operator: Select Equals.
    • Value: Select scam, suspect, phishing, and malware.
  • Actions:
    • Add header: For Key, enter X-vedacheck and for Value, enter failed.
    • Write to S3: Enter the name of an S3 bucket to store the message for investigation.
    • Drop: Stop processing the message.

Rule 2: Archive and send clean emails to recipients

This final rule processes messages that have successfully passed through the previous security checks. With no additional conditions, it forwards clean emails to their intended recipients, completing the secure email delivery workflow for the university’s communication system. Use the following settings to create and configure Rule 2:

  • Rule name: SendEmail
  • Action:
    • Add header: For Key , enter Add X-vedacheck with a Value of Approved.
    • Archive resource name: Select your Mail Manager archive (Email_Archive)
    • Send to internet: Send email to intended recipient.

The workflow makes sure that:

  • All outbound emails are securely archived
  • Each email undergoes scanning
  • Scan results are documented in email headers
  • Clean emails are delivered to their intended recipients

Step 8 : Store password in AWS Secrets Manager for the ingress endpoint

Before creating an ingress endpoint, you need to set up a password in AWS Secrets Manager:

  1. Go to the AWS Secrets Manager console and choose Store a new secret.
  2. Select Other type of secret.
  3. Enter password as the key and your desired password as the value.
  4. For Encryption key: Use a custom KMS key (not AWS managed keys).
    1. KMS customer managed key (CMK) key policy for ingress endpoint. Replace XXXXXXXXXXX with your AWS account ID.
{
    "Effect": "Allow",
    "Principal": {
        "Service": "ses.amazonaws.com"
    },
    "Action": "kms:Decrypt",
    "Resource": "*",
    "Condition": {
        "StringEquals": {
           "kms:ViaService": "secretsmanager.us-east-1.amazonaws.com",
            "aws:SourceAccount": "XXXXXXXXXXX"
        },
        "ArnLike": {
            "aws:SourceArn": "arn:aws:ses:us-east-1:XXXXXXXXXXX:mailmanager-ingress-point/*"
        }
    }
}
  1. Choose Next to proceed
  2. Enter a secret name and choose Edit permissions and update the resource policy. Replace XXXXXXXXXXX with your AWS account ID.
{
    "Version": "2012-10-17",
    "Id": "Id",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ses.amazonaws.com"
            },
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "XXXXXXXXXXX"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:ses:us-east-1:XXXXXXXXXXX:mailmanager-ingress-point/*"
                }
            }
        }
    ]
}
  1. Choose Next and create your secret

For step-by-step guidance, see the Developer guide for Ingress endpoints.

Step 9: Create an authenticated ingress endpoint

Now that you’ve created your traffic policy, rule set, and stored your credentials, you can create the ingress endpoint:

  1. In the Amazon SES console, choose Mail Manager and then choose Ingress endpoints.
  2. Choose Create ingress endpoint.
  3. Configure your endpoint:
    1. Select the Traffic policy you created earlier.
    2. Select the Rule set you created earlier.
    3. Enter a unique name for your endpoint.
    4. For authentication, select the Secret ARN you created in Secrets Manager.
  4. Choose Create ingress endpoint.

After your ingress endpoint is created, note down the following details from the General details section:

  • Amazon Resource Name (ARN): arn:aws:ses:us-east-1:XXXXXXXXXXX:mailmanager-ingress-point/inp-XXXXXXXXXXXX
  • Username: inp-XXXXXXXXXXXX
  • Host: XXXXXXXXX.fips.wmjb.mail-manager-smtp.amazonaws.com (ARecord)

You’ll need these details when configuring your email client or application to send emails through this endpoint.

Step 10: Send email using an ingress endpoint

The following Python sample code can be executed from your local machine with the appropriate AWS credentials, but for this post you’ll run the script from the AWS CloudShell terminal from within the Amazon SES console. When running the sample Python code, the email will pass through an ingress endpoint and, if all policies are met, the email will be sent to the recipient’s email address.

Running the Python script in CloudShell

  1. Sign in to the console and open CloudShell.
  2. Create the script file and paste the following Python code into the editor.
nano send_email.py
  1. Paste the following Python code:
import smtplib, boto3, json, logging
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
from botocore.exceptions import ClientError

# Configure logging
logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')
logger = logging.getLogger(__name__)

def get_secret(secret_name, region_name="us-east-1"):
    """Retrieve secret from AWS Secrets Manager"""
    try:
        secrets_client = boto3.session.Session().client('secretsmanager', region_name=region_name)
        logger.info(f"Connecting to AWS Secrets Manager in region {region_name}")
        response = secrets_client.get_secret_value(SecretId=secret_name)
        
        if 'SecretString' in response:
            logger.info("Successfully retrieved credentials from Secrets Manager")
            return json.loads(response['SecretString'])
        else:
            logger.error("No SecretString found in the response")
            raise ValueError("No SecretString found in the response")
    except Exception as e:
        logger.error(f"Error retrieving secret: {str(e)}")
        raise

def send_email(region_name="us-east-1"):
    try:
        # Fetch SMTP credentials from Secrets Manager
        smtp_secrets = get_secret('SES_Ingress_Endpoint_Credentials', region_name)
        
        # SMTP Configuration
        INGRESS_SERVER = 'XXXXXXXXXXX.fips.wmjb.mail-manager-smtp.amazonaws.com'
        INGRESS_PORT = 587
        INGRESS_USERNAME = 'inp-XXXXXXXXXXX'
        INGRESS_PASSWORD = smtp_secrets.get('password')
        
        # Email details
        sender = '[email protected]'
        recipient = '[email protected]'
        subject = 'Sent via SES Mail Manager'
        body = "Successfully passed through SES Mail Manager and Email Archived successfully"
        
        # Create message
        msg = MIMEMultipart()
        msg['From'], msg['To'], msg['Subject'] = sender, recipient, subject
        msg.attach(MIMEText(body, 'plain'))
        
        # Send email
        logger.info(f"Connecting to SMTP server {INGRESS_SERVER}:{INGRESS_PORT}...")
        with smtplib.SMTP(INGRESS_SERVER, INGRESS_PORT) as mail:
            mail.ehlo()
            mail.starttls()
            mail.login(INGRESS_USERNAME, INGRESS_PASSWORD)
            mail.send_message(msg)
            logger.info(f"Email successfully sent to {recipient}")
        
        return {'statusCode': 200, 'message': 'Email sent successfully'}
            
    except Exception as e:
        error_msg = f"Error: {str(e)}"
        logger.error(error_msg)
        return {'statusCode': 500, 'message': error_msg}

if __name__ == "__main__":
    result = send_email("us-east-1")
    print(json.dumps(result, indent=2))
  1. Replace all placeholders
    1. INGRESS_SERVER = XXXXXXXXXXX.fips.wmjb.mail-manager-smtp.amazonaws.com is your ingress endpoint hostname.
    2. INGRESS_PORT = Supported ports: 25, 587
    3. INGRESS_USERNAME = inp-XXXXXXXXXXXX is your ingress endpoint username.
    4. Recipient and sender= [email protected] is your verified sender and recipient email addresses.
  2. Save the file.
  3. Run the script:
python3 send_email.py
  1. Verify the results:
    1. Check the recipient’s inbox for the email.
    2. Check the Mail Manager archive to confirm the message was archived.

To search the Mail Manager archive for the specific message sent by the Python script:

  1. Navigate to the Amazon SES console and choose Mail Manager.
  2. Under Email Archiving, choose the Search archive tab.
  3. Under Archive, select the archive you created and choose Search. This should return all the emails you have sent.

Clean up

Clean up your AWS environment by removing all resources created during this walkthrough, including Mail Manager configurations, S3 buckets, secrets, and any associated Lambda functions.

Conclusion

In this post, we’ve demonstrated the implementation of sophisticated traffic policies, multi-layered rule systems, and automated archiving capabilities—all seamlessly integrated into a scalable architecture. The ability of Amazon SES Mail Manager to enforce TLS requirements, conduct email scanning, and maintain searchable archives while providing programmatic access through ingress endpoints makes it an invaluable tool for organizations seeking to modernize their email infrastructure.As businesses continue to rely heavily on email communication, Amazon SES Mail Manager emerges as a powerful ally, helping organizations navigate the complexities of modern digital correspondence while ensuring rock-solid security, seamless compliance, and optimal efficiency.

References:

About the authors

AT&T email-to-text service migration: AWS solution implementation

Post Syndicated from Vinay Ujjini original https://aws.amazon.com/blogs/messaging-and-targeting/att-email-to-text-service-migration-aws-solution-implementation/

Email-to-text services allow businesses to send short message service (SMS) messages through email, critical for automatic notifications, customer service, and operational workflows. These services process over 1.2 billion messages annually across U.S. carriers, with AT&T supporting 34% of this volume through 2024. AT&T’s deprecation of email-to-text and text-to-email services impacts businesses that rely on these communication channels. This blog post outlines an Amazon Web Services (AWS) solution to maintain service continuity for customers.

AT&T discontinued their email-to-text and text-to-email services in Q2 2025, which will impact about 23,000 business customers. Organizations rely on these communication channels for critical workflows and need a quick solution to maintain business continuity. By the numbers:

  • Average message volume: 50,000 texts per customer monthly
  • Critical use cases: Appointment reminders, security alerts, and system notifications
  • Regulatory requirements mandate message retention and delivery confirmation

Solution architecture

The following diagram shows the architecture for the solution:

Email-to-SMS architecture flow:

  1. An email is sent to [phone-number]@[your-domain.com]
  2. Amazon Simple Email Service (Amazon SES) routes emails to the Mail Manager ingress endpoint
  3. The email is written to an Amazon Simple Storage Service (Amazon S3) bucket
  4. An Amazon S3 event notification triggers an AWS Lambda function
  5. Lambda extracts the email content, formats the phone number, and sends an SMS message using AWS End User Messaging
  6. Message details are stored in DynamoDB for tracking

System components in this solution:

  • Processing: Mail Manager applies rules to incoming emails
  • Storage: Amazon S3 stores emails securely
  • Computation: Lambda processes stored emails
  • Identification: Amazon DynamoDB lookup matches the sender email to phone number
  • Delivery: AWS End User Messaging User Messaging sends an SMS message to the recipient

This architecture, which uses simple notification service (SNS), is suitable for SMS-to-email. While this post and the AWS CloudFormation template primarily focus on email-to-SMS implementation, the SMS-to-email flow works as follows:

SMS-to-email flow:

  1. A user replies to an SMS message
  2. AWS End User Messaging SMS service captures the message and publishes it to an SNS topic
  3. SNS triggers a Lambda function
  4. Lambda formats the message and sends an email through Amazon SES
  5. The email is delivered to the original sender

The solution

The solution was to build an email-to-text service using AWS core services. The architecture routes emails through an Amazon SES Mail Manager ingress endpoint. After receiving an email, Mail Manager processes it using defined business rules and stores it in Amazon S3. This triggers a Lambda function to fetch the phone number associated with the email address and send an SMS to that phone number. When successful, it stores data such as the email address, phone number, and message ID from the sent text message in DynamoDB.

Estimated setup time: 15–20 minutes

Prerequisites

To deploy the solution described in this post, you must have the following in place:

Step 1: Set up Amazon SES Verified Identity

Start by setting up an Amazon SES verified identity.

  1. Sign in to the AWS Management Console.
  2. Navigate to Amazon SES service.
  3. In the navigation pane, go to Configuration and choose Identities (skip this step if you have a verified identity).
  4. If you do not have a verified identity, choose e.
  5. Review this post to learn how to verify an identity. Best practice is to verify a domain identity. This will authenticate your domain and improve deliverability. An email address identity, while simpler, won’t be authenticated through DomainKeys Identified Mail (DKIM), which might decrease deliverability.

Reference: Creating and verifying identities in Amazon SES

  1. Confirm that the status of your domain identity is Verified before proceeding to the next step.

Step 2: Deploy the email-to-SMS CloudFormation template

Use the following steps to create a CloudFormation stack that deploys all the required components for email-to-SMS functionality:

  1. Sign in to your AWS account.
  2. Download the email-to-sms.yaml CloudFormation template file.
  3. Navigate to the CloudFormation console.
  4. Choose Create stack and select With new resources (standard).
  5. Prerequisite: Prepare template is selected as Choose an existing template.
  6. Under Specify template, choose Upload a template file and  upload the email-to-sms.yaml file you downloaded earlier. Choose Next.
  7. For Stack name, enter Email-To-SMS-Stack.
  8. Configure the following parameters:
    • e: Enter the SES verified domain name or a verified email address.
    • OriginationPhoneNumberId: Enter the AWS End User Messaging SMS phone number ID that you plan to use to send SMS messages.
      • Go to AWS End User Messaging, under Phone Numbers, select your number and find Phone number ID.
    • DestinationPhoneNumber: Enter the destination phone number to receive SMS messages.
  9. Choose Next.
  10. (Optional) Add tags to help identify and organize your AWS resources.
  11. Select Acknowledge All checkbox and choose Next.
  12. Review the configuration and choose Submit.
  13. Wait for the stack creation to complete. You can monitor the progress in the CloudFormation console

Step 3: Verify deployed stack services

After successful CloudFormation template deployment, verify the following resources and configurations:

  1. A DynamoDB table is created with the name <stackname>-email-to-sms-db
  2. A Lambda function is created with the name <stackname>-<accountnumber>-<awsregion>-process-email-to-sms
  3. The Lambda function has the following AWS Identity and Access Management (IAM)role policies attached:
    1. s3:GetObject
    2. dynamodb:PutItem
    3. sms-voice:SendTextMessage
    4. kms:Decrypt for Lambda encryption keys.
    5. IAM permissions for dead letter queue (if configured).
  4. S3 buckets are created:
    1. Main bucket: <stackname>-<accountnumber>-<awsregion>-emailtosms-storage
    2. Logging bucket: <stackname>-<accountnumber>-<awsregion>-emailtosms-logging
  5. In Amazon SES:
    1. A receipt rule set is created named <stackname>-EmailToSms-Rule-Set
    2. The receipt rule is configured to:
      1. Write messages in the S3 bucket.
      2. Invoke the Lambda function.
    3. Traffic policy is created named <stackname>-EmailToSms-Traffic-Policy
    4. The Rule set and traffic policy are configured in the ingress point <stackname>-EmailToSms-Ingress-Point
      • CAUTION: Testing this solution requires access to modify mail exchange (MX) DNS records for your domain.
      • Potential impact: Changes to MX records can interrupt email delivery to your primary domain.
      • Best practice: We strongly recommend creating a dedicated subdomain (such as testing.example.com) rather than using your primary domain (example.com) for testing purposes. This approach prevents disruption to your organization’s regular email service

Additional verifications:

  • Verify that the S3 bucket policies are correctly set
  • Verify that S3 bucket logging is on and working
  • Check the Lambda function’s environment variables
  • Monitor Amazon CloudWatch logs for any errors

Step 4: Test the email-to-SMS flow

  1. Send an email to mobile-number@verified-domain
  2. You will receive an SMS from the source number (AWS End User Messaging phone number) containing:
    • Subject: <EmailSubject>
    • Content: First 160 characters of your email body
  3. SMS character Limitations:
    1. AWS End User Messaging’s SMS messaging has character limits based on content type
    2. By default, the solution uses first 160 characters
    3. You can modify this limit by updating the Lambda function code
  4. Troubleshooting:
    1. If SMS or email responses aren’t received
    2. Check Lambda function logs in CloudWatch
    3. Review any error messages or execution issues
    4. Verify all permissions and configurations are correct

Make sure that your domain and phone numbers are properly verified before testing. If you don’t receive the email or SMS, check the Lambda CloudWatch logs for troubleshooting

Clean up

To avoid ongoing charges and remove all deployed resources, perform the following cleanup steps:

  1. Remove the CloudFormation stack:
    1. Navigate to the CloudFormation console
    2. Delete the Email-To-SMS stack
    3. Wait for complete stack deletion confirmation
  2. Amazon SES cleanup:
    1. Navigate to the Amazon SES console
    2. Remove any verified domains
    3. Delete verified email addresses
    4. Confirm all SES resources are removed
  3. AWS End User Messaging:
    1. Navigate to the AWS End User Messaging console
    2. Release all provisioned phone numbers
    3. Verify that no active phone numbers remain
  4. Additional verification:
    1. Confirm that S3 buckets are deleted
    2. Verify that Lambda functions are removed
    3. Check that DynamoDB tables are deleted
    4. Make sure that all associated IAM roles and policies are removed

Verify complete resource removal to prevent unexpected charges.

Additional recommendations

  • Security best practices:
    • Set up S3 bucket logging to track access and changes
    • Make sure that S3 buckets have:
      • No public read/write access
      • Enable Encryption at rest
      • Apply appropriate bucket policies
    • Implement least privilege access for IAM roles
    • Use KMS encryption for sensitive data
    • Add CloudWatch logging for monitoring
    • Protect against SMS pumping:
      • Enable AWS End User Messaging protect configuration: Enable filter mode to automatically block suspicious messages
      • Block countries that you don’t do business in to prevent unnecessary exposure
      • Add CAPTCHA to web forms that trigger SMS to prevent bot attacks
      • Set up SMS volume alerts to quickly detect unusual activity
      • Create separate configurations for different message types (password resets compared to marketing)
  • Cost and operational considerations:

Results

This implementation delivers three key improvements:

  1. This achieves 99.99% uptime through AWS managed services.
  2. The pay-per-use model reduces operating costs by 45% compared to maintaining dedicated infrastructure. Customers save an average of $2.30 per thousand messages.
  3. End-to-end encryption and AWS security protocols maintain GDPR and CCPA compliance while protecting customer data.

Conclusion

This AWS-based solution addresses the immediate need and provides a foundation for future enhancements in cross-platform messaging. Whether you’re migrating from AT&T’s email-to-text service or building a new notification system, this AWS-based solution provides a scalable foundation for your messaging needs.

About the author

The evolution of Grab’s machine learning feature store

Post Syndicated from Grab Tech original https://engineering.grab.com/evolution-of-grab-machine-learning-feature-store

Introduction

In this post, we outline how we transformed the way we serve data for our machine learning (ML) models and why we chose Amazon Aurora Postgres as the storage layer for our new feature store. At Grab, we have always been at the forefront of leveraging technology to enhance our services and provide the best possible experience for our platform users. This journey has led us to transition from a traditional approach to a more sophisticated and efficient ML feature store.

Over the years, ML at Grab has progressed from being used for specific, tactical purposes to being utilised to create long-term business value. As the complexity of our systems and ML models increased, requiring richer amounts of data over time, our platforms faced new challenges in managing more complex features such as a large number of feature keys (high-cardinality) and high-dimensional data or vectors. This evolution necessitated a shift in our data processing and management strategy. We needed a system to store and manage these complex features efficiently. In November 2023, this brought us back to the drawing board to evolve from Amphawa, our initial feature store.

We landed on the concept of feature tables: a set of data lake tables for ML features that are automatically and atomically ingested into our serving layer. While this concept is not new to the industry, as other platforms like Databricks and Tecton have evolved towards it, our approach is focused on atomicity and reproducibility. The rationale is that ensuring consistency and reliability during the serving lifecycle has become more critical, which has made it more challenging to manage within the model serving layer itself.

From feature store to data serving

A feature store is a repository that stores, serves, and manages ML features. It provides a unified platform where data scientists can access and share features, reducing redundancy and ensuring consistency across different models.

Figure 1: The high-level architecture of our centralised feature platform.

Our feature data is a key-value dataset. The key identifies a specific entity, such as a consumer ID, which is a known value in the incoming request. A composite key is supported by concatenating two or more entity identifiers. For example, (key = consumer_id + restaurant_id). The value is a binary that encodes the feature value and its type. Whenever a new value for a given entity needs to be updated, we write a new key-value pair for that entity.

New functional requirements

As our users designed and deployed increasingly complex ML solutions, new essential functional requirements were requested by our users:

  • Ability to retrieve the features given in the composite keys (contextual retrieval): The ML models in an upstream service might need to fetch all matching entities to form complete contextual information in order to make the recommendation. We build that context inside our ML orchestration layer before calling the model. This was previously not possible due to the design of composite keys in our initial approach.
  • Ability to update not just one entity atomically, but all the entities in a collection (atomic updates): This requirement concerns reducing the complexity of operations, such as rolling out new models and switching between versions of feature data. In Amphawa, newly ingested data is visible to consumer systems immediately after it’s written. As changes to the data may be ingested over a long period of time, users are responsible for ensuring the models or services don’t break while the new and old data coexist during ingestion, especially during potentially breaking changes to data. This complexity translates into quite complex code, which is hard to refactor over time. With the new approach, all feature changes will only become visible through atomic updates once the entire operation finishes successfully. This eases users’ pain of maintaining compatibility across versions.
  • Isolation of reading and writing capacity: The noisy-neighbor effect is one of the significant issues in our centralised feature store. Different readers could compete for read capacity. For some storage systems, write traffic could consume I/O capacity and affect reading latency. While reading capacity can be adjusted by scaling the storage, the competition between reading and writing capacity is highly dependent on the choice of storage. Hence, from the beginning, one of the top requirements of our second-generation feature store design was isolating reads from writes.

Feature table

To meet the functional requirements, we landed on the concept of a “feature table,” where users define and manage the schema and data on a per-table basis. Feature consumers can customise their tables based on their needs. Working with a table format directly makes it easier for data scientists to work with complex tabular data that needs to be retrieved in different ways depending on the context of the request. Moreover, it’s more manageable for us, on the platform side, because it’s closer to the actual format in the storage layer.

Amphawa (feature-centric) New design (feature-table centric)
A user defines individual features and their types. Grouping into the table is storage layer is implicit. A user defines their tables with compatibility with data-lake tools such as Spark.
The only index is on the data key. A user defines their own indexes for their tables, based on their access pattern.
Table 1: Comparison between Amphawa and the new feature table.

Our feature tables are not just a storage solution but a critical component of our ML infrastructure. They enable us to simplify our feature management, efficiently handle the model lifecycle, and enhance our ML models’ performance. This has allowed us to provide a better experience for our platform users and dramatically improve the quality of our ML models based on our A/B testing results.

The data serving’s ingestion workflow

We designed an ingestion framework to address the atomicity requirements from the ground up.

The data ingestion process in Amphawa was meticulously crafted to ensure efficiency and reduce the pressure on the key-value store. Conversely, our priority has shifted to atomicity (all or nothing) to serve our feature tables and simplify version compatibility.

Figure 2: Ingestion workflow.
  • Landing feature table in the data lake: Data scientists use SQL or Python on Spark to build ML pipelines that output data lake tables. These tables and metadata for version control are stored as Parquet objects in Amazon S3.
  • Register collection summary: A “collection summary” consists of a group of feature tables to be served and other related metadata regarding customised individual tables. In this step, our registry will validate the table’s schema and ensure the customisations are defined correctly.
  • Deploy collection summary: Data scientists send another request to our registry to deploy a collection summary.
  • Pre-ingestion validation: The schema is validated to ensure compatibility with the target online ML models. This process ensures consistency and compatibility across feature updates.
  • Ingestion: The ingestion mechanism is a classic reverse ETL where the data from S3 is loaded into our Aurora Postgres tables.
  • Post-ingestion warm-up: To avoid cold-start latency spikes, shadow reading duplicates a part of the ongoing reading queries to the new tables for a period before the final switch.

One of the core propositions of feature tables is to offer a simplified interface for writing. Compared to writing directly to a database or providing SDKs for different processing frameworks, we provide a single, common interface for writing, independent of the actual choice of database. This allows us to evolve or even integrate feature tables with other data stores without requiring our users to modify their pipelines. We can decide how the data is represented in the database at a specific isolation level while guaranteeing total transparency for writes and reducing the complexity of read operations.

However, if a producer has access to S3 and can write in a columnar format, they can always write feature tables. This also means they can access samples from the data lake and use other tools for data validation, as well as tools for data discovery.

Do take note that a feature table can only be used for data that can be represented in tabular format and requires a minimum of one index to be present in the data. In this initial phase, we support the following data types:

  • Atomic types (int, long, boolean, string, float, double)
  • List of atomic types (List[atomic])
  • List of list of atomic types (2d array)
  • Dictionary with strict types of keys and values

Leveraging AWS Aurora for Postgres to meet our non-functional requirements

In our quest to optimise our ML infrastructure, we strategically decided to use Amazon Web Services (AWS) Aurora for PostgreSQL to meet our non-functional requirements. Aurora’s unique features and capabilities, which aligned perfectly with our operational needs, drove this decision.

AWS Aurora is a fully managed relational database service that combines the speed and reliability of high-end commercial databases with the simplicity and cost-effectiveness of open-source databases. A key differentiator is Aurora’s distributed storage architecture.

Figure 3: AWS Aurora storage architecture.

Architecture breakdown

The cluster volume consists of copies of the data across three “Availability Zones” in a single AWS Region. Since each database instance in the cluster reads from the distributed storage, this allows for minimal replication lag and ease of scaling out read replicas to meet performance requirements as traffic patterns change.

The separation between readers and writers also allows us to scale each independently. This is a crucial feature as our traffic is predominantly read-heavy. Most of our data-writes occur once a day. Using a serverless instance class with the writer node being scaled down during idle time significantly reduces our overall operational costs.

The independent scaling of reader and writer nodes allows us to maintain high performance and availability of our feature store. During peak read times, we can scale out the reader nodes to handle the increased load, ensuring that our ML models have uninterrupted access to the features they need. Conversely, during periods of heavy data ingestion, we can scale up the writer nodes to ensure efficient data storage.

To facilitate the seamless scaling up and down of the writer node, Aurora also allows a cluster to have a mixture of Serverless and Provisioned nodes. The key difference between the two is that with Serverless, the Aurora service manages the capacity of a single node and adjusts accordingly as the load increases and decreases. In our context, we’re using Serverless for our writer node to quickly scale up when heavy data ingestion starts and scale down automatically once the ingestion is done. We then use Provisioned nodes for the reader nodes since read traffic is more consistent.

In addition to cost and performance benefits, AWS Aurora simplifies our database management tasks. As a fully managed service, Aurora takes care of time-consuming database administration tasks such as hardware provisioning, software patching, setup, configuration, or backups, allowing our team to focus on optimising our ML models.

Accessing the data through our SDK

With the goal of providing a high-performing and highly available data serving SDK design, we’ve moved on from the centralised API design of Amphawa to a decentralised access architecture in Data Serving. Each data serving deployment is a self-contained system with a cluster and feature catalogue stored within the cluster as additional metadata tables. This minimises dependency, which improves the availability of the system.

The data serving SDK is designed to be a thin wrapper around the database driver to optimise performance. The SDK contains only a set of utility functions that load user configuration from the Catwalk platform and a query builder to translate user queries to SQL. No additional data validation is performed in the query code path, as all validation is done during feature table generation and ingestion. Therefore, the database handles most of the heavy lifting.

Decentralised deployments: A strategic shift in our infrastructure

We also investigated the difference between centralised and decentralised deployments. We have been exploring these options in the context of our ML feature store, specifically with our Amphawa service and Catwalk orchestrators.

Our original feature store was deployed as a standalone service where different model-serving applications can connect to it. On the other hand, a decentralised deployment is integrated within a model-serving orchestrator, and a specific orchestrator is bound to a set of pods.

After extensive discussions and evaluations, we concluded that a decentralised deployment for data serving would better align with our operational needs and objectives. Below is the list of factors we compared that led us to this decision:

  • Version control: Centralised deployments simplify version control but risk accumulating technical debt due to backward compatibility requirements. Decentralised deployments, while needing robust tracking, offer more flexibility.
  • Deployment strategies: Decentralised deployments enabled seamless use of Blue-green and Rolling Deployment strategies. They allow multiple versions to coexist and easy rollbacks, reducing client mismatch issues.
  • Noisy neighbour problem: Centralised deployments struggle with the noisy neighbour issue, which requires complex rate limiting. Decentralised setups mitigate this problem by isolating services.
  • Caching efficiency: Centralised deployments often suffer low cache hits, whereas decentralised deployments improve caching efficiency by better fitting data into the cache.

Conclusion

In conclusion, leveraging AWS Aurora for Postgres has enabled us to create a robust, scalable, and cost-effective feature store that supports our complex ML infrastructure. This is a testament to our commitment to using cutting-edge technology to enhance our services and provide the best possible experience for our users. Our shift towards decentralised deployments represents our dedication to optimising our infrastructure to support our ML models effectively. By aligning our deployment strategy with our operational needs, we aim to enhance the performance of our services and provide the best possible experience for our users.

Join us

Grab is a leading superapp in Southeast Asia, operating across the deliveries, mobility and digital financial services sectors. Serving over 800 cities in eight Southeast Asian countries, Grab enables millions of people everyday to order food or groceries, send packages, hail a ride or taxi, pay for online purchases or access services such as lending and insurance, all through a single app. Grab was founded in 2012 with the mission to drive Southeast Asia forward by creating economic empowerment for everyone. Grab strives to serve a triple bottom line – we aim to simultaneously deliver financial performance for our shareholders and have a positive social impact, which includes economic empowerment for millions of people in the region, while mitigating our environmental footprint.

Powered by technology and driven by heart, our mission is to drive Southeast Asia forward by creating economic empowerment for everyone. If this mission speaks to you, join our team today!

Grab’s service mesh evolution: From Consul to Istio

Post Syndicated from Grab Tech original https://engineering.grab.com/service-mesh-evolution

The challenge: When good enough isn’t good enough

Picture this: It’s 2024, and Grab’s microservices ecosystem is thriving with over 1000 services running in different infrastructure. But behind the scenes, our service mesh setup is showing its age. We’re running Consul with a fallback mechanism called Catcher – a setup that has served us well but is starting to feel like wearing a winter coat in Singapore’s heat.

The challenges we faced were becoming increasingly apparent. A single Consul server issue could trigger a fleet-wide impact, affecting critical services like food delivery and ride-hailing. Our fallback solution, while necessary, added complexity and limited our ability to implement advanced features like circuit breaking and retry policies. As we expanded our presence across Southeast Asia, the need for robust multi-cluster support became more critical than ever. The existing setup struggled with modern requirements like advanced traffic management and fine-grained security controls, while the growing complexity of our microservices architecture demanded better traffic management capabilities.

The complexity of Grab’s infrastructure

Our infrastructure landscape is as diverse as the Southeast Asian markets we serve. We operate a complex hybrid environment encompassing services on traditional VMs and EKS clusters with diverse infrastructure provisioning and deployment approaches. This diversity isn’t merely about deployment models—it’s about meeting the unique needs of different business units and regulatory requirements across the region.

The complexity doesn’t stop there. We handle dual traffic protocols (HTTP and gRPC) across our entire service ecosystem. Our services communicate across cloud providers between AWS and GCP. Within AWS alone, we maintain multiple organizations to segregate different Grab entities, each operating in its own isolated network. This multi-cloud, multi-protocol, multi-organization setup presented unique challenges for our service mesh implementation.

The quest for a better solution

Like any good tech team, we didn’t just jump to conclusions. We embarked on a thorough evaluation of service mesh solutions, considering various options including Application Load Balancer (ALB), Istio, AWS Lattice, and Linkerd. Our evaluation process was comprehensive and focused on real-world needs, examining everything from stability under high load to the performance impact on service-to-service communication.

We needed a solution that could handle our distributed architecture while maintaining operational simplicity. The ideal service mesh would need to integrate seamlessly with our existing infrastructure landscape while offering the flexibility to scale with our growing needs. After careful consideration, Istio emerged as the clear winner, offering robust multi-cluster support with flexible deployment models and a comprehensive set of features for traffic management, security, and observability.

What really sealed the deal was Istio’s strong Kubernetes integration and native support, combined with active community backing. The rich ecosystem of tools and integrations meant we wouldn’t be building everything from scratch, while the flexible deployment options could accommodate our unique requirements.

Designing our Istio architecture

When it came to designing our Istio implementation, we took a slightly unconventional approach. Instead of following the traditional “one control plane per cluster” pattern, we designed a more resilient architecture that would better suit our needs. We implemented multiple control planes running on dedicated Kubernetes clusters for better isolation and scalability, with active-active pairs ensuring high availability.

Figure 1. External control planes and Kubernetes API servers – Endpoints discovery
Figure 2. Istio proxy to Istio control plane – xDS flow

Our architecture needed to support high-throughput service-to-service communication while enabling complex routing rules for A/B testing and canary deployments. We implemented custom resource definitions for service mesh configuration and integrated with our existing monitoring and alerting systems. The organization-based mesh boundaries we designed would support our multi-tenant architecture, while our solution for cross-cluster endpoint discovery would ensure reliable service communication across our distributed system.

This design wasn’t just about following best practices – it was about learning from our past experiences with etcd and Consul. We wanted a setup that could handle Grab’s scale while maintaining simplicity and reliability. The architecture needed to support everything from high-throughput service-to-service communication to complex routing rules for A/B testing and canary deployments, all while maintaining fine-grained security policies and comprehensive observability.

The migration journey begins

In Q4 2024, we kicked off our migration journey with a clear plan. While our initial strategy focused on gRPC traffic migration, real-world priorities led us down a different path. Our first major milestone was the GCP to AWS migration, a cross-cloud initiative that would test our service mesh capabilities in a complex, multi-cloud environment.

This cross-cloud migration was a significant undertaking, requiring careful coordination between teams and careful consideration of network policies, security requirements, and service dependencies. We had to ensure seamless communication between services running in different cloud providers while maintaining security and performance standards.

Alongside our ongoing cloud migration efforts, we launched parallel initiatives focused on gRPC and HTTP traffic migration with cross-mesh connectivity requirements. This phase introduced distinct challenges, as it involved migrating business-critical services while implementing gradual traffic shifting capabilities and quick rollback mechanisms to ensure zero-downtime migrations. We also maintained close monitoring of performance metrics throughout the process.

Additionally, we needed to ensure seamless compatibility between different service mesh implementations and navigate the complexities of cross-mesh communication. The insights and experience gained from our cloud migration phase have proven invaluable in informing our approach and execution strategy for this critical migration effort.

The journey hasn’t been without its challenges. We’ve had to balance migration speed with stability while coordinating across multiple teams and organizations. Handling both gRPC and HTTP traffic patterns required careful planning and execution. We’ve had to deal with legacy systems and technical debt while training and supporting teams through the transition. Maintaining service continuity during these transitions has been our top priority.

Lessons learned

This journey has taught us several valuable lessons. We’ve learned that sometimes the standard approach isn’t the best fit, and innovation often comes from questioning assumptions. We’ve discovered the importance of balancing innovation with stability, taking calculated risks while building capability for a quick mitigation.

Keeping the bigger picture in mind has been crucial, considering long-term implications and planning for scale and growth. We’ve learned to document challenges and solutions, sharing knowledge across teams to avoid repeating mistakes. Most importantly, we’ve learned to stay flexible and adapt to changing needs, being ready to pivot when necessary while keeping an eye on emerging technologies.

What’s next?

The service mesh landscape is constantly evolving, and we’re excited to be part of this journey. Our next steps include continuing our migration efforts with a focus on stability while exploring mesh features like advanced traffic management, and enhanced security policies.

We’re also working on enhancing our operational capabilities through automated testing and validation, improved monitoring and alerting, and better debugging tools. As we progress, we’re committed to sharing our experiences with the community through open source contributions, conference participation, and technical blogs.

Shape the future with us

We’re not just implementing a service mesh—we’re architecting the backbone of Grab’s microservices future. Every decision prioritizes reliability, scalability, and maintainability, ensuring we build something that will stand the test of time.

The journey continues, and we’re excited about what lies ahead. Follow our progress for real-world insights that might shape your own service mesh evolution.

Want to help us build the future? We have exciting opportunities waiting for you.

Credits to the Service Mesh team: Aashif Bari, Hilman Kurniawan, Hofid Mashudi, Jingshan Pang, Kaitong Guo, Mikko Turpeinen, Sok Ann Yap, Jesse Nguyen, and Xing Yii.

Join us

Grab is a leading superapp in Southeast Asia, operating across the deliveries, mobility and digital financial services sectors. Serving over 800 cities in eight Southeast Asian countries, Grab enables millions of people everyday to order food or groceries, send packages, hail a ride or taxi, pay for online purchases or access services such as lending and insurance, all through a single app. Grab was founded in 2012 with the mission to drive Southeast Asia forward by creating economic empowerment for everyone. Grab strives to serve a triple bottom line – we aim to simultaneously deliver financial performance for our shareholders and have a positive social impact, which includes economic empowerment for millions of people in the region, while mitigating our environmental footprint.

Powered by technology and driven by heart, our mission is to drive Southeast Asia forward by creating economic empowerment for everyone. If this mission speaks to you, join our team today!

Creando experiencias de cliente con IA mediante un hub de comunicaciones moderno

Post Syndicated from Bruno Giorgini original https://aws.amazon.com/blogs/messaging-and-targeting/creando-experiencias-de-cliente-con-ia-mediante-un-hub-de-comunicaciones-moderno/

Los clientes de hoy esperan que las organizaciones satisfagan proactivamente sus necesidades con contenido personalizado, entregado en el momento, lugar y forma de su elección. Buscan interacciones dinámicas y conscientes del contexto con conversaciones sofisticadas a través de todos los canales de comunicación. Esta creciente demanda ejerce presión sobre las organizaciones para transformar sus flujos de trabajo de experiencia del cliente para mejorar la lealtad y aumentar la eficiencia operativa. Si bien los avances recientes en Generative AI (GenAI), incluida la hiperpersonalización y Agentic AI, ofrecen posibilidades interesantes, también presentan nuevos desafíos. Las organizaciones necesitan una arquitectura flexible y reutilizable que les permita incorporar GenAI en sus sistemas existentes de participación del cliente sin requerir una revisión completa de sus soluciones dispares actuales.

Esta publicación de blog explora cómo construir un centro de comunicaciones moderno impulsado por IA utilizando ejemplos de GitHub de código abierto que integran servicios de SMS/MMS y WhatsApp con capacidades de GenAI. Las organizaciones pueden crear experiencias innovadoras de cliente impulsadas por IA con una rápida prueba de concepto sin interrumpir los sistemas existentes.

En combinación con Vector Databases y Retrieval Augmented Generation (RAG), GenAI hace posible reorganizar el conocimiento en un solo sistema y consultar desde una única interfaz de usuario a través de conversación en lenguaje natural con un chatbot o asistente virtual. Canalizar las comunicaciones de los clientes a través de un centro de comunicaciones multicanal vinculado con capacidades de GenAI ayuda a unificar los mecanismos de participación del cliente y agiliza la creación de experiencias ricas para el cliente. Los clientes interactúan con agentes de IA y bots de preguntas y respuestas en el canal de comunicación que les resulta conveniente para autogestionar sus necesidades. Las organizaciones pueden construir experiencias de cliente agnósticas al canal de comunicación mientras recopilan eventos de participación del canal y datos conversacionales en un almacén de datos centralizado para obtener información en tiempo real, consultas ad-hoc, análisis y entrenamiento de ML.

Descripción general de la solución

En el núcleo de la solución se encuentra el Centro de Comunicaciones Moderno que conecta los canales de comunicación digital con servicios clave de GenAI, como Amazon Bedrock y Amazon Q, junto con servicios de AWS ML, bases de datos, almacenamiento y computación sin servidor.

Este diagrama muestra la arquitectura de la solución en Nivel 300

AWS End User Messaging y Amazon SES proporcionan acceso a nivel de API a canales de comunicación digital, ofreciendo servicios seguros, escalables, de alto rendimiento y rentables para que las aplicaciones empresariales intercambien SMS/MMS, WhatsApp, notificaciones push y de voz, y correo electrónico con los clientes.

Una colección de código de muestra de código abierto, publicada en el repositorio AWS-samples de GitHub, ilustra cómo facilitar conversaciones generativas en canales SMS/MMS y WhatsApp. Esto se extenderá para incluir servicios de correo electrónico. Dos componentes clave forman la base de las Muestras de Integración de GenAI: el Orquestrador de chat Multicanal con Agentes de IA, y la Base de Datos de Participación y Análisis para End User Messaging y SES. Nos referiremos a estos simplemente como el Procesador de Conversaciones y la Base de Datos de Participación en el diagrama de la solución.

El Procesador de Conversaciones recibe mensajes de clientes a través de AWS End User Messaging y Amazon Simple Email Service (SES), almacena los detalles de la conversación e invoca al Agente de Amazon Bedrock relevante. Los Agentes de Amazon Bedrock utilizan Modelos de Lenguaje Grandes (LLMs) y bases de conocimiento para analizar tareas, dividirlas en pasos accionables, ejecutar esos pasos o buscar en la base de conocimiento, observar resultados y refinar iterativamente su enfoque hasta completar la tarea junto con una respuesta. Alternativamente, el Procesador de Conversaciones puede funcionar como un bot de preguntas y respuestas, en cuyo caso utiliza Amazon Bedrock Knowledge Bases junto con su función RAG para generar una respuesta LLM y enviarla por el mismo canal que el mensaje del cliente.

La Base de Datos de Participación recopila y combina datos de participación del cliente y registros conversacionales de todos los canales de comunicación, almacenando la información en un data lake centralizado en Amazon S3. Al convertir los datos a un formato común y canónico, la solución simplifica la consulta y el análisis de estos eventos entrantes. Una función Lambda Transformer aprovecha las Plantillas Apache Velocity para transformar los datos JSON entrantes, permitiendo obtener información en tiempo real.

Los datos de eventos sin procesar almacenados en el data lake de Amazon S3 pueden luego alimentar otros servicios de AWS para su procesamiento posterior. Por ejemplo, los datos pueden fluir hacia Amazon Connect Customer Data Profiles o Amazon SageMaker para apoyar el entrenamiento de modelos de machine learning. Los analistas de datos pueden usar Amazon Athena para realizar consultas directas para informes detallados ad-hoc, o enviar los datos a Amazon QuickSight para visualizaciones avanzadas y capacidades de consulta en lenguaje natural a través de Amazon Q en QuickSight.

NOTA: Existe la posibilidad de que los usuarios finales envíen Información Personal Identificable (PII) en los mensajes. Para proteger la privacidad del cliente, considere usar Amazon Comprehend para ayudar a redactar PII antes de almacenar mensajes en S3. La siguiente publicación de blog proporciona una buena descripción general de cómo usar Comprehend para redactar PII: Redact sensitive data from streaming data in near-real time using Amazon Comprehend and Amazon Kinesis Data Firehose.

Amazon Bedrock proporciona capacidades centrales de GenAI como LLMs, Knowledge Bases, Retrieval Augmented Generation (RAG), agentes de IA y Guardrails, para comprender las solicitudes de los clientes, determinar qué acción tomar y qué comunicar de vuelta. Amazon Bedrock Knowledge Bases proporciona conocimiento y razonamiento específico de la organización, mientras que los Agentes de Amazon Bedrock automatizan tareas de múltiples pasos conectándose perfectamente con los sistemas, APIs y fuentes de datos de la empresa.

Requisitos previos

Los siguientes requisitos previos son necesarios para construir su centro de comunicaciones moderno:

  • Una cuenta de AWS. Regístrese para obtener una cuenta de AWS en el sitio web de AWS si no tiene una.
  • Roles y permisos apropiados de AWS Identity and Access Management (IAM) para Amazon Bedrock, AWS End User Messaging y Amazon S3. Para más información, consulte Create a service role for model import.
  • Configuración de AWS End User Messaging: Necesitará configurar la identidad de origen necesaria en el servicio AWS End User Messaging para entregar mensajes a través de SMS o WhatsApp. Si configura SMS, se debe aprovisionar un Número de Teléfono de Origen SMS registrado y activo en AWS End User Messaging SMS. (Dentro de Estados Unidos, use 10DLC o Números Gratuitos (TFNs)). Si configura WhatsApp, se debe aprovisionar un número activo que haya sido registrado con Meta/WhatsApp en AWS End User Messaging Social.
  • Modelos de Amazon Bedrock: Bedrock Anthropic Claude 3.0 Sonnet y Titan Text Embeddings V2 habilitados en su región. Tenga en cuenta que estos son los modelos predeterminados utilizados por la solución; sin embargo, puede experimentar con diferentes modelos.
  • Docker instalado y en ejecución – Se utiliza localmente para empaquetar recursos para el despliegue.
  • Node (> v18) y NPM (> v8.19) instalados y configurados en su computadora
  • AWS Command Line Interface (AWS CLI) instalado y configurado
  • AWS CDK (v2) instalado y configurado en su computadora.

Implementación del Procesador de Conversaciones y Base de Datos de Participación

Implemente las siguientes dos soluciones. Si bien no es obligatorio, es mejor implementarlas en este orden, ya que las salidas de la Base de Datos de Participación pueden utilizarse en el ejemplo de Chat Multicanal:

    1. Engagement Database and Analytics for End User Messaging and SES
    2. Orquestrador de chat Multicanal con Agentes de IA

Cada solución contiene instrucciones detalladas para implementar los servicios requeridos usando AWS Cloud Development Kit (CDK). La primera solución de Base de Datos de Participación creará un flujo de Amazon Data Firehose que puede utilizarse como entrada para la segunda aplicación de Chat Multicanal, de modo que los datos puedan almacenarse y consultarse en la Base de Datos de Participación.

Orquestrador de chat Multicanal con Agentes de IA

Esta solución demuestra cómo los usuarios pueden interactuar con tres diferentes fuentes de conocimiento. Puede que no necesite las tres, sin embargo, esto debería servir como un buen ejemplo para construir la fuente de conocimiento adecuada para su caso de uso particular:

Construya sus Bases de Conocimiento en Amazon Bedrock usando Amazon S3. Por defecto, la solución creará Bases de Conocimiento usando un Bucket de Amazon S3 como fuente de datos. Esta solución le permite cargar documentos a un bucket de Amazon S3 para poblar la base de conocimiento.

NOTA: El proyecto inicial crea un bucket S3 para almacenar los documentos utilizados para la Base de Conocimiento de Bedrock. Por favor, considere usar Amazon Macie para ayudar en el descubrimiento de datos potencialmente sensibles en buckets S3. Amazon Macie puede habilitarse en una prueba gratuita durante 30 días, hasta 150GB por cuenta.

Construya su Base de Conocimiento en Amazon Bedrock usando un Web Crawler. Opcionalmente configure su base de conocimiento para escanear o rastrear sitio(s) web para poblar su base de conocimiento.

Agentes de Amazon Bedrock: Opcionalmente permita que sus usuarios chateen con Agentes de Amazon Bedrock. Los agentes tienen el beneficio adicional de soportar bases de conocimiento para responder preguntas y guiar a los usuarios a través de la recopilación de información necesaria para automatizar una tarea como hacer una reserva. Hay agentes de ejemplo disponibles en el repositorio Amazon Bedrock Agent Samples. Tenga en cuenta que necesitará tener un Agente de Amazon Bedrock creado en su región antes de implementar la solución.

Conclusión

Un Centro de Comunicaciones Moderno, acoplado de manera flexible con servicios centrales de Generative AI, establecerá una base componible para construir experiencias de cliente agnósticas al canal de comunicación. Construya uno aprovechando las Muestras de Integración de GenAI, el Procesador de Conversaciones y la Base de Datos de Participación, combinándolos con los servicios de comunicación digital seguros, escalables, de alto rendimiento y rentables de AWS End User Messaging y Amazon SES. Esto proporcionará un único punto de acceso conversacional a bases de conocimiento y capacidades de IA agéntica en Amazon Bedrock. Comience a experimentar con innovaciones de experiencia del cliente impulsadas por IA con una rápida prueba de concepto que no interferirá con su configuración actual de participación del cliente.

Acerca de los Autores

Guide to IP and domain warming and migrating to Amazon SES

Post Syndicated from Tyler Holmes original https://aws.amazon.com/blogs/messaging-and-targeting/guide-to-ip-and-domain-warming-and-migrating-to-amazon-ses/

Transitioning your email workloads from another email service provider (ESP) to Amazon Simple Email Service (Amazon SES) can be a challenge, given that each workload can be unique. In this post, we show you how to successfully warm up IP addresses and domains when migrating to Amazon SES. This guide aims to provide a comprehensive overview of IP and domain warming best practices so you can make your transition to Amazon SES as smooth as possible. We discuss some of the challenges you might encounter and how to overcome those common pitfalls when transitioning to a new email service provider (ESP).

Understanding IP and domain email warming

IP warming and domain warming are strategic processes designed to gradually introduce a new sending identity to mailbox providers. A new sending identity can be a dedicated IP address, new domain, a subdomain of that domain, or any combination of them. The core objective of warming is to build a positive reputation with mailbox providers so your emails are delivered to the inbox rather than being filtered into spam folders or potentially blocked from being delivered to a mailbox altogether.

Mailbox providers such as Gmail, Yahoo, and Outlook are vigilant about protecting their users from spam and malicious content. When you introduce a new sending identity, mailbox providers evaluate the new sending identity with caution. They evaluate the early sending from the domain and IPs to ensure they’re sending the mailbox provider’s users messages that are wanted and aren’t engaged in abusive practices such as spam or phishing. Warming provides mailbox providers the opportunity to observe your sending patterns, content, and engagement metrics, allowing them to gradually build trust in your new sending identity.

Warming can be different for each scenario. For example, you can have completely warmed IPs, but if your sending domain is new, you’ll likely have to warm it up as well but you won’t need to worry about IP warming as much. Another common scenario is that of adding a new IP but sending with an established domain. In this case, the IP will need warming, but the domain itself is helping the warming because it already has an established reputation. When you have a net new IP and a net new domain, you’ll have to warm them together. The warm-up best practices we outline in this post, such as starting out slow and targeting your highest engaged subscribers first, apply to your situation.

Why warming is critical

Warming is essential for several reasons, each contributing to the overall success and reliability of your email marketing campaigns:

  1. Building trust with mailbox providers – A positive sender reputation is crucial for email deliverability. Mailbox providers use complex algorithms to evaluate the reputation of senders, and warming helps them build trust in your new sending identity.
  2. Avoiding initial deliverability issues – When you switch to a new ESP or introduce a new sending identity, it’s common to experience an initial dip in deliverability metrics, such as lower open rates, click-through rates, or higher bounce rates. Warming can mitigate these issues by giving mailbox providers time to adapt to your new sending patterns, whether that is a new domain, subdomain, or new IP infrastructure.
  3. Maintaining consistent sending behavior – Warming encourages you to maintain a steady and predictable sending cadence. Sudden, significant changes in sending volume, content, or frequency can trigger inbox spam filters because such changes might indicate that the sender has been compromised or is engaging in abusive practices. Even anomalies such as large changes in volume or throughput during seasonal events such as Black Friday can be interpreted as negative, and mailbox providers take a cautious approach when they detect anomalies such as sudden large spikes in volume.
  4. Long-term deliverability success – It’s a misconception that warming is done only one time. In reality you need to maintain traffic volumes and sending cadences to keep those sending identities warm. Additionally, if you plan on increasing volume considerably, for example from 1M to 5M or 5M to 25M, you need to warm up to those volumes. Those large jumps in volumes look suspicious to inbox providers even if you’ve been sending consistently.
  5. Adapting to mailbox provider changes – Mailbox providers also continuously update their algorithms to better detect spam and abusive behavior. If you view warming as a constant process and consistently monitor your deliverability and engagement signals you can make adjustments to your sending strategy as needed, ensuring that your emails continue to reach the inbox, even as inbox and audience behavior changes.

Common challenges to moving traffic and warming up on a new ESP

Transitioning your email traffic to a new ESP can present unique challenges that require careful consideration and strategic planning to overcome. These challenges include the following:

  1. Event-driven traffic – If all your email is event-driven, it’s hard to control volume and throughput.
  2. Multiple sending domains – Having many sending domains with varying traffic volumes and throughputs can complicate the transition.
  3. No shared IPs – Some organizations aren’t allowed to use shared pools of IPs.
  4. Lack of engagement data – Absence of data related to engagement can make it difficult to optimize the warming process.
  5. Outdated bounce and unsubscribe info – Not having up-to-date bounce and unsubscribe information in your current ESP can lead to deliverability issues.
  6. Single second-level domain – You’re currently sending your mail from your second-level domain, such as example.com, without separate subdomains for logical use cases such as transactional or marketing.
  7. Tight timelines – Contracts ending or other reasons might impose a tight timeline for the transition.
  8. Challenges for independent service providers (ISVs) and software-as-a-service (SaaS) providers – These organizations often don’t have complete control over the volume, content, lists, or sending consistency of their customers. They also might not have direct access to the DNS needed to update and align sending domains and authentication.

Strategies for a successful warm-up and migration

The following list isn’t suitable for every case, and many customers will use more than one strategy to address their challenges and smooth their transition to Amazon SES:

  1. Send to your best audience first – The most important thing you need to do when transitioning to a new ESP is to send to your highest and most active recipients on the new ESP and leave the less active or risky segments on the previous ESP until you’re ready to full switch. For example, if you’re a daily sender who sends to 1M addresses a day and have an open rate of about 20%, you need to start onboarding with segments that include those who are opening. A good strategy is to start with openers from the last 30 days, then move to openers from 31–90 days, and so on.
  2. Gradually shift traffic – Gradually move your less engaged subscribers to the new ESP while continuing to send in your current ESP and compare performance metrics between the two providers. After you’ve transitioned your most active segments, you can start to include the less engaged a little at a time. Make sure to continue monitoring for issues and immediately stop increasing your workloads if you encounter deliverability issues such as increased bounce or spam rates.
  3. Start with predictable workloads – Begin with workloads that aren’t time-dependent, such as newsletters, which are easier to control and monitor.
  4. Batch event-driven messages – For event-driven messages that aren’t time-sensitive, try to batch and spread them out to manage the volume.
  5. Use automated warm-up processes – Standard and managed dedicated IPs can help to manage the daily volume by allowing predefined levels of traffic on your dedicated IPs and spilling over into shared IP pools when the volume of email has reached a level we deem to be sufficient for your dedicated IPs. This is dependent on your warm-up progress thus far. Dedicated standard is a static 45-day increase, but managed dedicated has a more sophisticated process. To learn more, refer to Dedicated IP addresses for Amazon SES.
  6. Strategically use shared IP pools – Use shared IP pools for workloads that don’t require dedicated IPs. Because there is consistent volume already going through these IPs, they’re a little more forgiving than dedicated IPs being warmed up.
  7. Transition gradually to dedicated IPs – Begin with shared IPs and gradually transition to dedicated IPs as they warm up.
  8. Transition gradually to logical subdomains – Split your traffic into logical workloads that can have consistent volume and throughput. Even something as simple as marketing.example.com and transactional.example.com is better than sending mail from example.com
  9. Onboard new customers on the new ESP – For ISVs and SaaS providers, consider onboarding new customers directly on the new ESP to gather initial data and test the waters. New customers already need to be warmed up, so if you warm them up on Amazon SES rather than your legacy ESP, you don’t need to go through a warming process twice.

Prepare to migrate email traffic to Amazon SES

Before you migrate your email program to Amazon SES, it’s important to thoroughly document and organize your existing setup. This preparatory work will lay the foundation for a successful warm-up and migration process. For best practices, include the following tasks:

  1. Document your use cases – Categorize your use cases as either marketing or transactional. This will help you understand the nature of the emails you send and how they should be handled.
  2. Document your sending domains – Include the “from” names associated with each domain. This will assist in mapping the appropriate domain to the corresponding email type. Ideally, you should avoid sending from your root domain. For example, use a subdomain such as email.brand.com instead of brand.com. Review and document your authentication (for example, SPF, DKIM, or DMARC). In some cases, you might not need to align all of them, but you’ll definitely need to align DMARC as part of the bulk sender requirements.
  3. Map use cases to sending domains and from names – Create a clear correspondence to ensure the right emails are sent from the appropriate domains. At a minimum, it’s a best practice to have separate subdomains for transactional and promotional email use cases, such as transactional.brand.com and promo.brand.com.
  4. Document volume and max throughput – Capture this information for each use case mapped to your sending domains. This will help you understand the scale of your email operations and plan your architecture and warming strategy accordingly.
  5. Anticipate a temporary dip in deliverability metrics – While transitioning to a new ESP, you might experience a short-term fluctuation in metrics such as open rates and click-through rates. This is a common occurrence and shouldn’t be viewed as a failure of the service. It’s an expected part of the migration process as mailbox providers adapt to your new sending identity. By closely monitoring your bounce and complaint rates, you can make proactive adjustments to your ramp-up plan to ensure a smooth transition.
  6. Document your warming plan – Have a plan to gradually increase traffic for each identity and monitor engagement metrics. Plan for how to address high bounce or complaint rates.

The following table shows a sample warm-up plan. Notice that the days are categorized by large inbox providers. This is because these providers all accept new mail at different rates. Categorizing this way is a recommended best practice, but if you can’t segment that granularly, then you can use the Daily totals column as a guide. The AWS managed dedicated IP service automatically does this segmentation and throttling at the domain level for you.

The following plan is a typical ramp. You can get more aggressive the higher your overall engagement rates are, so if you’re at 40–60% engagement, you can use this warm-up. If your rates are lower, you might want to be a little more conservative. Make sure to be adaptive as you go into your warming plan because you might need to maintain the same rate for a couple days or even roll back a step if you’re experiencing negative trends such as a drop in deliverability or engagement. Remember, as you get into the less engaged segments of your list, engagement will drop, but it shouldn’t be drastic. Constantly monitor your metrics during this critical time.

Day @gmail.com @hotmail.com @outlook.com @yahoo.com @icloud.com @aol.com Others Daily total
1 150 150 150 150 150 150 150 1,050
2 300 300 300 300 300 300 300 2,100
3 600 600 600 600 600 600 600 4,200
4 1,200 1,200 1,200 1,200 1,200 1,200 1,200 8,400
5 2,400 2,400 2,400 2,400 2,400 2,400 2,400 16,800
6 5,000 5,000 5,000 5,000 5,000 5,000 5,000 35,000
7 10,000 10,000 10,000 10,000 10,000 10,000 10,000 70,000
8 20,000 20,000 20,000 20,000 20,000 20,000 20,000 140,000
9 40,000 40,000 40,000 40,000 40,000 40,000 40,000 280,000
10 80,000 80,000 80,000 80,000 80,000 80,000 80,000 560,000
11 150,000 150,000 150,000 150,000 150,000 150,000 150,000 1,050,000
12 300,000 300,000 300,000 300,000 300,000 300,000 300,000 2,100,000
13 425,000 425,000 425,000 425,000 425,000 425,000 425,000 2,975,000
14 500,000 500,000 500,000 500,000 500,000 500,000 500,000 3,500,000
15 600,000 600,000 600,000 600,000 600,000 600,000 600,000 4,200,000
16 650,000 650,000 650,000 650,000 650,000 650,000 650,000 4,550,000
17 700,000 700,000 700,000 700,000 700,000 700,000 700,000 4,900,000
18 800,000 800,000 800,000 800,000 800,000 800,000 800,000 5,600,000
19 900,000 900,000 900,000 900,000 900,000 900,000 900,000 6,300,000
20 1,000,000 1,000,000 1,000,000 1,000,000 1,000,000 1,000,000 1,000,000 7,000,000
21 1,100,000 1,100,000 1,100,000 1,100,000 1,100,000 1,100,000 1,100,000 7,700,000
22 1,200,000 1,200,000 1,200,000 1,200,000 1,200,000 1,200,000 1,200,000 8,400,000
23 1,300,000 1,300,000 1,300,000 1,300,000 1,300,000 1,300,000 1,300,000 9,100,000
24 1,400,000 1,400,000 1,400,000 1,400,000 1,400,000 1,400,000 1,400,000 9,800,000
25 1,500,000 1,500,000 1,500,000 1,500,000 1,500,000 1,500,000 1,500,000 10,500,000
26 1,600,000 1,600,000 1,600,000 1,600,000 1,600,000 1,600,000 1,600,000 11,200,000
27 1,700,000 1,700,000 1,700,000 1,700,000 1,700,000 1,700,000 1,700,000 11,900,000
28 1,800,000 1,800,000 1,800,000 1,800,000 1,800,000 1,800,000 1,800,000 12,600,000
29 1,900,000 1,900,000 1,900,000 1,900,000 1,900,000 1,900,000 1,900,000 13,300,000
30 2,000,000 2,000,000 2,000,000 2,000,000 2,000,000 2,000,000 2,000,000 14,000,000
31 2,100,000 2,100,000 2,100,000 2,100,000 2,100,000 2,100,000 2,100,000 14,700,000
32 2,200,000 2,200,000 2,200,000 2,200,000 2,200,000 2,200,000 2,200,000 15,400,000
33 2,300,000 2,300,000 2,300,000 2,300,000 2,300,000 2,300,000 2,300,000 16,100,000
34 2,400,000 2,400,000 2,400,000 2,400,000 2,400,000 2,400,000 2,400,000 16,800,000
35 2,500,000 2,500,000 2,500,000 2,500,000 2,500,000 2,500,000 2,500,000 17,500,000
36 2,600,000 2,600,000 2,600,000 2,600,000 2,600,000 2,600,000 2,600,000 18,200,000
37 2,700,000 2,700,000 2,700,000 2,700,000 2,700,000 2,700,000 2,700,000 18,900,000
38 2,800,000 2,800,000 2,800,000 2,800,000 2,800,000 2,800,000 2,800,000 19,600,000
39 2,900,000 2,900,000 2,900,000 2,900,000 2,900,000 2,900,000 2,900,000 20,300,000
40 3,000,000 3,000,000 3,000,000 3,000,000 3,000,000 3,000,000 3,000,000 21,000,000

Best practices for a successful IP warm-up

A successful IP warm-up involves a strategic approach that combines technical preparation, engaged subscribers, compelling content, and ongoing monitoring.

  1. Ensure technical readiness – Configure DNS records and set up SPF, DKIM, DMARC, and BIMI so your email content complies with best practices. Make sure your DMARC is aligned if you’re sending across multiple ESPs or domains.
  2. Use an engaged, permission-based mailing list – Use a clean, opt-in list of subscribers who are interested in your content. For more information, refer to Optimizing Email Deliverability: A User-Centric Approach to List Management and Monitoring.
  3. Provide compelling, valuable email content – Send content that resonates with your audience and encourages engagement.
  4. Gradually ramp up sending volume and cadence – Start with a small volume of emails and gradually increase over time to allow mailbox providers to observe your sending patterns.
  5. Maintain consistency in sending behavior – Avoid sudden, significant changes in sending volume, content, or frequency.
  6. Continuously monitor and optimize key metrics – Track open rates, click-through rates, bounce rates, and complaint rates, and make adjustments as needed. For more information, refer to Amazon SES – Set up notifications for bounces and complaints.
  7. Ongoing maintenance of sender reputation – Audit data flows, ramp up changes gradually, and follow evolving email marketing best practices.

Navigating initial deliverability challenges

When transitioning to a new ESP, you might encounter some initial deliverability challenges. It’s important to monitor and exercise caution if you observe increased bounce or complaint rates. If you do have challenges, you need to address them promptly. Maintain the same volume or even reduce the volume the next day if you encounter these issues:

  1. Spike in hard bounce rates – Bring over your suppression lists from the ESP you’re offboarding from, but if your previous ESP didn’t manage these well or you load some old addresses you weren’t aware of, it’s common to experience hard bounce spikes at the beginning. If this happens, slow your volume increases or even stop increasing until things stabilize. It’s more important to warm up properly than it is to get to production levels of sending as fast as possible. This is one more reason that it’s always best to start with your most engaged segments.
  2. Increased spam complaints – Emails might reach recipients who previously filtered them, leading to more spam complaints. Changing an identity can also cause your recipients to hit the spam button because they don’t recognize it. Announce identity changes before changing your ESP to reduce the chances of an issue.
  3. Heightened mailbox provider scrutiny – Mailbox providers will closely monitor new senders to confirm they’re not engaged in malicious activities. This can divert emails to the spam filter initially or even be throttled if you reach volume or throughput limits. Gmail is known to be stringent. Amazon SES managed dedicated IPs use our data to know how much mail the big inbox providers will accept while you’re warming up and keep you from overshooting their limits.
  4. ESP throttling and sending limits – The new ESP might have stricter rules regarding the volume of emails that can be sent to individual mailbox providers. Amazon SES has account limits for daily volume and max throughput, so adjust yours to what you’ll need. To learn more, refer to Increasing your Amazon SES sending quotas in the Amazon SES Developer Guide.

Maintaining IP reputation after warming

IP warming is an ongoing process. Even after the initial warm-up phase, it’s essential to maintain your sender reputation by continuously managing your email program. Your subscriber engagement might fluctuate as your list grows and changes. Similarly, ramping up email volume for a seasonal campaign will require adjustments to your warm-up process. You need to be proactive and adapt your IP warming strategy.

Audit data flows and campaigns and monitor email list sources, data collection practices, and campaign performance. When introducing new elements, do so incrementally to avoid triggering reputation issues. To allow time for your reputation to stabilize, provide at least a month for a new baseline to be established after major program changes. Engage with customers, provide value, and implement re-engagement campaigns to nurture your customer relationships. Adhere to evolving email marketing best practices, including proper authentication protocols and emerging technologies. Be proactive and track domain and IP reputation so you can quickly address the deliverability issues that arise. To learn more about monitoring inbox tools such as Google Postmaster, refer to Understanding Google Postmaster Tools (spam complaints) for Amazon SES email senders.

Conclusion

Transitioning your email program to a new ESP such as Amazon SES can seem complex, but it can be quick and seamless if you follow the best practices explained in this post. IP warming is a critical component of this process because it helps build a positive sender reputation with mailbox providers and promotes the reliable delivery of your emails.

Throughout this guide, we’ve covered the key aspects of IP warming and email migration, from understanding the importance of this practice to identifying common challenges and outlining effective strategies for a successful transition. By following best practices such as facilitating technical readiness, using an engaged subscriber base, providing compelling content, and gradually ramping up sending volume, you can navigate the initial deliverability challenges and establish a strong foundation for long-term email program success.

However, the work doesn’t stop when the initial warm-up phase is complete. Maintaining IP reputation and adapting your strategy as your email program and subscriber engagement evolve is an ongoing process. Continuously monitoring key metrics, auditing data flows, and staying up to date with evolving email marketing best practices is crucial for sustaining deliverability. A long-lasting sender reputation and enduring relationships with your list and recipients are some of the key benefits of following these best practices.Transitioning to a new ESP is a significant undertaking, but with the right preparation, execution, and commitment to ongoing maintenance, your migration can be smooth and successful.

Resources for deliverability

About the authors

Secure collaboration and file sharing with AWS Wickr

Post Syndicated from Anne Grahn original https://aws.amazon.com/blogs/messaging-and-targeting/secure-collaboration-and-file-sharing-with-aws-wickr/

File sharing has become an integral part of collaboration. However, when security protocols aren’t enforced, businesses expose themselves to the risk of data loss.

Whether you’re exchanging documents with colleagues, sharing information with partners, or transferring sensitive data, unsecure file sharing can lead to unauthorized access and security incidents. Although no organization is completely immune to data loss, the increasing frequency of cyber threats underscores the need for mitigation strategies.

This post highlights how AWS Wickr can help you protect sensitive data and securely share files as part of a balanced approach to security and compliance.

The need to safeguard communications and files

Following the breach of telecommunication networks by a state-sponsored threat actor known as Salt Typhoon, the Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) advised individuals to start using end-to-end encryption to protect sensitive text and voice communications.

CISA’s Mobile Communications Best Practice Guidance recommends the adoption of “…a free messaging application for secure communications that guarantees end-to-end encryption.” However, as the role of messaging applications in business communication expands, it’s important not to lose sight of recordkeeping and compliance obligations. Although consumer messaging applications can protect data and offer file sharing capabilities, they often lack the administrative controls and data retention features needed to reduce organizational risk.

During RSA Conference 2025 Cryptographer’s Panel, concerns about the recent US government group chat leak were raised. Public-key cryptography pioneer Whitfield Diffie noted that the use of an encrypted consumer messaging application to communicate classified information broke archiving laws. Because some commercial tools use 256-bit Advanced Encryption Standard (AES) encryption, which is strong enough to protect communications, he predicted an increase in the use of consumer applications to protect sensitive information in unapproved ways.

How Wickr can help

Wickr can help you protect communications and files against external threats, and employees that misuse their privileges (either intentionally or unintentionally) and expose sensitive data.

Wickr is a secure messaging and collaboration solution that protects one-to-one and group messaging, voice and video calling, file sharing, screen sharing, and location sharing with end-to-end encryption. Additionally, Wickr provides the data retention and administrative controls needed to help you meet recordkeeping requirements, and manage user and device data remotely. Specialized features help you organize files and control how they’re viewed and downloaded.

Wickr Files provides a dedicated space to access and manage files in conversations. Moderators of Wickr rooms and users in self-moderated group conversations can upload and organize files in folders. Users can toggle between Messages and Files tabs to access relevant content and streamline collaboration.

The new Wickr File Previews feature helps you protect sensitive files and lower the risk of data loss. Wickr network administrators can configure a view-only mode in the Security Groups section of the AWS Management Console for Wickr. Users within these groups will be restricted to only viewing the supported files, and will be unable to download them.

Wickr is available in commercial AWS Regions that include US East (N. Virginia), Canada (Central), Asia Pacific (Malaysia, Singapore, Sydney, and Tokyo), and Europe (Frankfurt, London, Stockholm, and Zurich). It is also available as Department of Defense Cloud Computing Security Requirements Guide Impact Level 5 (DoD CC SRG IL5) and Federal Risk and Authorization Management Program (FedRAMP) High-authorized AWS WickrGov in AWS GovCloud (US-West).

Conclusion

There is no single solution for preventing data loss. However, Wickr facilitates efforts to protect sensitive conversations and files while meeting regulatory requirements. Incorporating Wickr alongside clear policies and awareness training covering messaging apps and secure file sharing can position you to accelerate collaboration, mitigate risks, and drive positive business outcomes.

To learn more and get started, see the following resources:

About the authors

Monitoring AWS End User Messaging SMS Registrations with Lambda

Post Syndicated from Patrick Viker original https://aws.amazon.com/blogs/messaging-and-targeting/monitoring-aws-end-user-messaging-sms-registrations-with-lambda/

Managing AWS End User Messaging SMS registrations can be challenging, especially when dealing with multiple registrations in various states and countries. This post introduces an automated monitoring solution that helps you stay on top of your registration statuses. By leveraging AWS Lambda, EventBridge, and Simple Email Service (SES), you’ll create a system that provides regular updates about registrations that need attention, are under review, in draft pending submission, or have recently been completed.

Whether you’re managing Sender IDs, United States 10DLC campaigns, toll-free numbers, or short codes, this solution will help you maintain visibility across all your registrations and respond promptly to status changes. The setup takes approximately 15-20 minutes and requires no ongoing maintenance beyond occasional adjustments to meet your evolving needs.

Estimated Setup Time: 15-20 minutes

Prerequisites

  • An AWS account with access to Lambda, IAM, EventBridge, End User Messaging SMS, and SES
  • A verified email address in Amazon SES for sending reports.
Figure 1: AWS End User Messaging SMS registrations in the console. This view shows registrations in various states that our Lambda function will monitor.

Figure 1: AWS End User Messaging SMS registrations in the console. This view shows registrations in various states that our Lambda function will monitor.

Step 1: Set up Amazon SES

  1. Open the Amazon SES console
  2. Navigate to “Verified identities”
  3. If you have an identity verified you can skip this section
  4. If you do not already have an identity verified Click “Create identity”
  5. Review this post to learn how to verify an identity
    NOTE: Best practice is to verify a domain identity. This will authenticate your domain and improve deliverability. An email address identity, while more simple, will not be authenticated through DKIM which may decrease deliverability.

Reference: Creating and verifying identities in Amazon SES

Step 2: Create an IAM Role

  1. Open the IAM console
  2. Navigate to “Roles” and click “Create role”
  3. Select “AWS service” and “Lambda” as the use case
  4. Add only the following AWS managed policy: AWSLambdaBasicExecutionRole
  5. Name the role (e.g., “EndUserMessagingRegistrationsMonitorRole”) and click “Create role”
  6. After role creation, click on the newly created role
  7. Select “Add permissions” → “Create inline policy”
  8. Click on the “JSON” tab and paste the following policy: 
    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sms-voice:DescribeRegistrations",
                "sms-voice:DescribeRegistrationVersions"
            ],
            "Resource": "arn:aws:sms-voice:${region}:${account-id}:registration/*"
        },
        {
            "Effect": "Allow",
            "Action": "ses:SendRawEmail",
            "Resource": [
                "arn:aws:ses:${region}:${account-id}:identity/${domain}",
                "arn:aws:ses:${region}:${account-id}:configuration-set/*"
            ],
            "Condition": {
                "StringLike": {
                    "ses:FromAddress": [
                        "*@${domain}"
                    ]
                }
            }
        }
    ]
}
  9. Replace the placeholders in the policy:
    1. ${region}: Your AWS region (e.g., ‘us-west-2’)
    2. ${account-id}: Your AWS account ID
    3. ${domain}: Your verified SES domain
  10. Click “Next”
  11. Name the policy (e.g., “EndUserMessagingRegistrationsAccess”) and click “Create policy”

Reference: Creating a role for an AWS service (console)

Step 3: Create the Lambda Function

  1. Open the Lambda console
  2. Click “Create function”
  3. Choose “Author from scratch”
  4. Configure basic settings:
  5. Name: EndUserMessagingRegistrationsMonitor
  6. Runtime: Python 3.12
  7. Architecture: x86_64
  8. Permissions: Use the IAM role created in Step 2
  9. Click “Create function”
  10. Configure environment variables:
    1. Under “Configuration” tab → “Environment variables”
    2. Set the following key/value pairs:
      1. Key: SENDER_EMAIL, Value: [Your verified SES email]
      2. Key: RECIPIENT_EMAIL, Value: [Email to receive reports]
  11. Configure function timeout:
    1. Under “Configuration” → “General configuration”
    2. Set timeout to 1 minute
  12. In the function code area, paste the following code: 
    import boto3
import json
from datetime import datetime, timedelta
from collections import defaultdict
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
import os

# Constants
REGION = os.environ['AWS_REGION']
SENDER_EMAIL = os.environ['SENDER_EMAIL']
RECIPIENT_EMAIL = os.environ['RECIPIENT_EMAIL']
COMPLETED_LOOKBACK_DAYS = 7

# Initialize AWS clients
sms_client = boto3.client('pinpoint-sms-voice-v2', region_name=REGION)
ses_client = boto3.client('ses', region_name=REGION)

# Global registration dictionary
registrations = {
    'REQUIRES_UPDATES': defaultdict(list),
    'CREATED': defaultdict(list),
    'COMPLETED': defaultdict(list),
    'REVIEWING': defaultdict(list)
}

def get_console_url(registration_id):
    return f"https://{REGION}.console.aws.amazon.com/sms-voice/home?region={REGION}#/registrations?registration-id={registration_id}"

def get_version_details(registration_id, latest_denied_version=None):
    try:
        if latest_denied_version:
            response = sms_client.describe_registration_versions(
                RegistrationId=registration_id,
                VersionNumbers=[latest_denied_version]
            )
        else:
            response = sms_client.describe_registration_versions(
                RegistrationId=registration_id,
                MaxResults=1
            )
        
        if response['RegistrationVersions']:
            return response['RegistrationVersions'][0]
    except Exception as e:
        print(f"Error getting version details for {registration_id}: {str(e)}")
    return None

def is_recently_completed(version_info):
    if 'RegistrationVersionStatusHistory' in version_info:
        history = version_info['RegistrationVersionStatusHistory']
        if 'ApprovedTimestamp' in history:
            approved_time = history['ApprovedTimestamp']
            if isinstance(approved_time, datetime):
                approved_time = approved_time.timestamp()
            lookback_time = (datetime.now() - timedelta(days=COMPLETED_LOOKBACK_DAYS)).timestamp()
            return approved_time > lookback_time
    return False

def categorize_registration_type(registration_type):
    if 'TEN_DLC' in registration_type:
        return 'TEN_DLC'
    elif 'LONG_CODE' in registration_type:
        return 'LONG_CODE'
    elif 'SHORT_CODE' in registration_type:
        return 'SHORT_CODE'
    elif 'SENDER_ID' in registration_type:
        return 'SENDER_ID'
    elif 'TOLL_FREE' in registration_type:
        return 'TOLL_FREE'
    else:
        return 'OTHER'

def categorize_registrations():
    global registrations
    registrations = {
        'REQUIRES_UPDATES': defaultdict(list),
        'CREATED': defaultdict(list),
        'COMPLETED': defaultdict(list),
        'REVIEWING': defaultdict(list)
    }

    try:
        response = sms_client.describe_registrations()
        
        for registration in response.get('Registrations', []):
            status = registration['RegistrationStatus']
            registration_id = registration['RegistrationId']
            registration_type = registration['RegistrationType']
            category = categorize_registration_type(registration_type)
            
            reg_info = {
                'id': registration_id,
                'type': registration_type,
                'status': status,
                'version': registration['CurrentVersionNumber'],
                'console_url': get_console_url(registration_id)
            }

            if 'AdditionalAttributes' in registration:
                reg_info['additional_attributes'] = registration['AdditionalAttributes']

            if status == 'REQUIRES_UPDATES':
                latest_denied_version = registration.get('LatestDeniedVersionNumber')
                version_info = get_version_details(registration_id, latest_denied_version)
                if version_info and 'DeniedReasons' in version_info:
                    reg_info['denial_reasons'] = version_info['DeniedReasons']
                registrations['REQUIRES_UPDATES'][category].append(reg_info)
            
            elif status == 'CREATED':
                registrations['CREATED'][category].append(reg_info)
            
            elif status == 'REVIEWING':
                registrations['REVIEWING'][category].append(reg_info)
            
            elif status == 'COMPLETE':
                version_info = get_version_details(registration_id)
                if version_info and is_recently_completed(version_info):
                    approved_timestamp = version_info['RegistrationVersionStatusHistory']['ApprovedTimestamp']
                    if isinstance(approved_timestamp, datetime):
                        approved_timestamp = approved_timestamp.timestamp()
                    reg_info['approved_timestamp'] = approved_timestamp
                    registrations['COMPLETED'][category].append(reg_info)
                
    except Exception as e:
        print(f"Error listing registrations: {str(e)}")
        raise e

def generate_html_output():
    html = """
    <html>
    <head>
        <style>
            body { 
                font-family: Arial, sans-serif;
                margin: 20px;
                line-height: 1.6;
            }
            .registration-group { margin: 20px 0; }
            .registration-category { 
                background-color: #f0f0f0;
                padding: 10px;
                margin: 10px 0;
                border-radius: 5px;
            }
            .registration-item {
                border-left: 4px solid #ccc;
                margin: 10px 0;
                padding: 10px;
                background-color: #ffffff;
            }
            .requires-updates { border-left-color: #ff9900; }
            .created { border-left-color: #007bff; }
            .completed { border-left-color: #28a745; }
            .reviewing { border-left-color: #6c757d; }
            .denial-reasons {
                background-color: #fff3f3;
                padding: 10px;
                margin: 5px 0;
                border-radius: 3px;
            }
            .console-link {
                color: #007bff;
                text-decoration: none;
                padding: 2px 5px;
                border: 1px solid #007bff;
                border-radius: 3px;
            }
            .console-link:hover {
                background-color: #007bff;
                color: #ffffff;
            }
            .summary {
                margin: 20px 0;
                padding: 15px;
                background-color: #e9ecef;
                border-radius: 5px;
                box-shadow: 0 2px 4px rgba(0,0,0,0.1);
            }
            .divider {
                border-top: 2px solid #dee2e6;
                margin: 20px 0;
            }
            .lookback-info {
                background-color: #e2e3e5;
                padding: 10px;
                border-radius: 5px;
                margin: 10px 0;
                font-style: italic;
            }
            h2, h3, h4 {
                color: #333;
                margin-top: 20px;
            }
            ul {
                margin: 5px 0;
                padding-left: 20px;
            }
            li {
                margin: 5px 0;
            }
        </style>
    </head>
    <body>
    """

    html += f"<h2>Registration Status Report - {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}</h2>"

    html += f"""
    <div class="lookback-info">
        Note: Completed registrations shown are those completed within the last {COMPLETED_LOOKBACK_DAYS} days.
    </div>
    """

    html += '<div class="summary"><h3>Summary</h3>'
    for status, categories in registrations.items():
        total = sum(len(regs) for regs in categories.values())
        html += f"<p><strong>{status}:</strong> {total}"
        if status == 'COMPLETED':
            html += f" (last {COMPLETED_LOOKBACK_DAYS} days)"
        html += "<br>"
        for category, regs in categories.items():
            if regs:
                html += f"&nbsp;&nbsp;{category}: {len(regs)}<br>"
        html += "</p>"
    grand_total = sum(sum(len(regs) for regs in categories.values()) for categories in registrations.values())
    html += f"<p><strong>Total Registrations:</strong> {grand_total}</p>"
    html += "</div>"

    html += '<div class="divider"></div>'

    html += "<h3>Detailed Registration Status</h3>"

    for status, categories in registrations.items():
        total = sum(len(regs) for regs in categories.values())
        html += f"""
        <div class="registration-group">
            <h3>{status} Registrations (Total: {total})</h3>
        """

        for category, regs in categories.items():
            if regs:
                html += f"""
                <div class="registration-category">
                    <h4>{category} Registrations ({len(regs)})</h4>
                """

                for reg in regs:
                    css_class = status.lower().replace('_', '-')
                    html += f"""
                    <div class="registration-item {css_class}">
                        <strong>Registration ID:</strong> {reg['id']}<br>
                        <strong>Type:</strong> {reg['type']}<br>
                        <strong>Status:</strong> {reg['status']}<br>
                        <strong>Version:</strong> {reg['version']}<br>
                        <strong>Console:</strong> <a href="{reg['console_url']}" class="console-link" target="_blank">Open in Console</a><br>
                    """

                    if (reg['type'] == 'US_TEN_DLC_BRAND_VETTING' and 
                        status == 'COMPLETED' and 
                        'additional_attributes' in reg and 
                        'VETTING_SCORE' in reg['additional_attributes']):
                        html += f"<strong>Vetting Score:</strong> {reg['additional_attributes']['VETTING_SCORE']}<br>"

                    if status == 'REQUIRES_UPDATES' and reg.get('denial_reasons'):
                        html += '<div class="denial-reasons"><strong>Denial Reasons:</strong><ul>'
                        for reason in reg['denial_reasons']:
                            html += f"""
                            <li>
                                <strong>{reason.get('Reason', 'N/A')}</strong><br>
                                {reason.get('ShortDescription', 'N/A')}<br>
                            """
                            if reason.get('LongDescription'):
                                html += f"{reason['LongDescription']}<br>"
                            if reason.get('DocumentationLink'):
                                html += f'<a href="{reason["DocumentationLink"]}" target="_blank">Documentation</a>'
                            html += "</li>"
                        html += "</ul></div>"

                    if status == 'COMPLETED':
                        approved_time = datetime.fromtimestamp(reg['approved_timestamp']).strftime('%Y-%m-%d %H:%M:%S')
                        html += f"<strong>Approved:</strong> {approved_time}<br>"

                    html += "</div>"
                html += "</div>"
        html += "</div>"

    html += "</body></html>"
    return html

def send_email(html_content, subject, recipient):
    msg = MIMEMultipart('mixed')
    msg['Subject'] = subject
    msg['From'] = SENDER_EMAIL
    msg['To'] = recipient

    html_part = MIMEText(html_content, 'html')
    msg.attach(html_part)

    try:
        response = ses_client.send_raw_email(
            Source=msg['From'],
            Destinations=[recipient],
            RawMessage={'Data': msg.as_string()}
        )
        print(f"Email sent! Message ID: {response['MessageId']}")
    except Exception as e:
        print(f"Error sending email: {str(e)}")
        raise e

def lambda_handler(event, context):
    try:
        print("Starting registration categorization...")
        categorize_registrations()
        
        print("Generating HTML report...")
        html_content = generate_html_output()
        
        print("Sending email...")
        subject = f"End User Messaging SMS Registration Status Report - {datetime.now().strftime('%Y-%m-%d %H:%M')}"
        send_email(html_content, subject, RECIPIENT_EMAIL)
        
        return {'statusCode': 200, 'body': json.dumps('Registration status report generated and sent successfully')}
    except Exception as e:
        print(f"Error in lambda execution: {str(e)}")
        return {'statusCode': 500, 'body': json.dumps(f'Error generating report: {str(e)}')}

Reference: Building Lambda functions with Python

Step 4: Set Up EventBridge Rule

  1. Open the Amazon EventBridge console
  2. Click “Create rule”
  3. Name your rule (e.g., “EndUserMessagingRegistrationsMonitorSchedule”)
  4. For the event pattern, choose “Schedule” then select “Continue in EventBridge Scheduler”
  5. Configure your schedule pattern to your requirements (for example, Cron-based schedule to run at specific days and times or rate-based schedule such as every 1 day). Click “Next”.
  6. Select “Lambda” for “Target detail” and select the Lambda function created in Step 3 as the target from the dropdown. Click “Next”.
  7. For permissions:
    1. Select “Create new role for this schedule”
    2. EventBridge will automatically create a role with the necessary permissions to invoke your Lambda function
  8. Click “Next” to review your configuration
  9. Click “Create schedule”

Reference: Amazon EventBridge Scheduler

Step 5: Test the Setup

  1. Open the Lambda console and navigate to your function
  2. Click “Test” and create a test event (you can use an empty JSON object {})
  3. Run the test and check the execution results
  4. Verify that you receive an email report

Reference: Testing Lambda functions in the console

The generated email report provides a clear summary of all registrations, categorized by their status.

Figure 2: The generated email report provides a clear summary of all registrations, categorized by their status.

Understanding the Lambda Function

Let’s break down the key components of our Lambda function:

  1. Initialization: The script sets up necessary AWS clients and defines constants.
  2. categorize_registrations(): This function fetches all registrations and categorizes them based on their status and type.
  3. generate_html_output(): Creates a formatted HTML report of the registration statuses.
  4. send_email(): Uses Amazon SES to send the HTML report via email.
  5. lambda_handler(): The main entry point for the Lambda function, orchestrating the entire process.

The function categorizes registrations into four main statuses:

  • REQUIRES_UPDATES: Registrations that need attention or modifications
  • CREATED: Newly created registrations
  • REVIEWING: Registrations currently under review
  • COMPLETED: Registrations that have been approved recently (within the last 7 days by default)
Detailed view of a registration requiring updates and created registrations pending submission, including specific denial reasons if applicable and direct console links.

Figure 3: Detailed view of a registration requiring updates and created registrations pending submission, including specific denial reasons if applicable and direct console links.

Customization Options

  1. Lookback Period: Modify the COMPLETED_LOOKBACK_DAYS constant to change how far back the function checks for completed registrations.
  2. Email Formatting: Adjust the HTML and CSS in generate_html_output() to customize the email report’s appearance.
  3. Additional Data: Modify the reg_info dictionary in categorize_registrations() to include more data fields in your report.

Monitoring and Maintenance

  1. CloudWatch Logs: Regularly check the Lambda function’s CloudWatch Logs for any errors or unexpected behavior.
  2. Adjusting Schedule: If you find the current schedule doesn’t meet your needs, adjust the EventBridge rule accordingly.

Conclusion

You now have an automated system that monitors your End User Messaging SMS registrations and sends you regular, detailed status reports. This setup provides:

  • Automated visibility into registrations requiring updates or attention
  • Clear tracking of draft registrations awaiting your submission
  • Monitoring of registrations under review
  • Notifications of recently completed registrations
  • A consolidated view of all registration states through formatted email reports

This automated solution eliminates the need for manual status checking and helps ensure timely responses to registration changes. As your messaging needs grow, you can easily customize the monitoring frequency, lookback period, and report format to match your requirements.

Next Steps:

  • Consider adjusting the EventBridge schedule based on your registration volume
  • Customize the email format to highlight information most relevant to your team
  • Set up CloudWatch alarms to monitor the Lambda function’s health
  • Review and update the completed registrations lookback period as needed

For more complex scenarios, consider extending this solution with additional features like Slack notifications, registration metrics tracking, or integration with your ticketing system.

 

Navigating AWS Migration: Achieving Clarity and Confidence

Post Syndicated from Tim Schmidt original https://blog.rapid7.com/2025/06/09/navigating-aws-migration-achieving-clarity-and-confidence-2/

Navigating AWS Migration: Achieving Clarity and Confidence

Migrating workloads to Amazon Web Services (AWS) represents a significant strategic opportunity, enabling greater agility, scalability, and potential for innovation. But undertaking this transition without a comprehensive strategy for visibility and security can introduce unforeseen risks, operational delays, and challenges in managing the new cloud environment effectively. A critical aspect often overlooked is the discovery and protection of sensitive data as it moves to and resides within the cloud, demanding specific attention.

Addressing security proactively is not merely a technical requirement: it functions as a crucial enabler, allowing organizations to fully realize the strategic benefits of the cloud without being hindered by security roadblocks or compliance failures.

Furthermore, bringing sensitive data protection into focus early connects the technical migration process directly to significant business risks, such as regulatory non-compliance and the potential impact of data breaches, underscoring the importance of robust security solutions for confidently realizing cloud benefits.

Integrating security across the migration lifecycle

A successful and secure migration is not achieved by treating security as an afterthought. Security considerations must be integrated throughout the entire migration lifecycle – from the initial assessment of the current environment, through mobilizing resources and establishing the cloud foundation, to the final migration and modernization phases.

Cloud migration typically involves distinct stages:

  1. Assess: Evaluating the current state, identifying assets, and understanding existing risks.
  2. Mobilize: Preparing resources and establishing a secure cloud foundation or landing zone in AWS.
  3. Migrate and modernize: Transferring workloads and potentially optimizing them for the cloud environment.

Addressing security continuously across these stages helps prevent costly delays and rework often associated with late-stage security implementations. Effective tooling and methodology are essential here.

Rapid7’s security platform is designed to support organizations through this journey, providing the necessary visibility, risk context, and security controls for a smoother transition to AWS. The platform unifies critical capabilities, aiming to provide a 360° view of the attack surface and streamlining security operations across hybrid environments.

Improving migration efficiency through unified security

Efficiency is paramount across migration phases to maintain project velocity without compromising security. Managing multiple disparate tools can impede progress and obscure visibility. Rapid7 helps streamline critical activities by unifying essential capabilities within its Command Platform:

  • Asset Discovery: Identify every vulnerable device and weak identity across your environment with comprehensive attack surface management.
  • Risk-based prioritization: Incorporate business context, third-party vulnerability findings, and threat intelligence into how you assess risk to improve your cloud security posture and protect cloud workloads.
  • Proactive remediation:Customize remediation workflows to seamlessly orchestrate and automatically respond to any vulnerability.

This integrated approach offers advantages beyond simplified tool management, potentially leading to richer context through data correlation and more effective prioritization.

During assessment

Comprehensive planning requires a complete asset inventory. Surface Command accelerates the initial assessment phase through rapid, comprehensive asset discovery across internal and external inventories, including cloud environments like AWS. This helps to eliminate blind spots and identify all assets, including potentially unsecured systems, before they are considered for migration.

Subsequently, Exposure Command builds upon this asset foundation, adding vulnerability data and risk scoring to identify critical weaknesses in on-premises systems slated for migration. It enables teams to focus remediation efforts effectively by prioritizing vulnerabilities based on threat-aware risk context before these systems move to the cloud.

During mobilize and migrate and modernize

In these intensive phases, Exposure Command ensures the AWS landing zone and core services are configured securely according to organizational policies and industry best practices (e.g., CIS Benchmarks) through its Cloud-Native Application Protection Platform  (CNAPP) capabilities, while providing ongoing monitoring for misconfigurations. It also plays a critical role in managing cloud permissions by analyzing identities and access rights to help enforce least-privilege access models.

As workloads are deployed, it offers  vulnerability management tailored for cloud assets, including container security. Concurrently, InsightConnect reduces the manual workload associated with security tasks. As a SOAR solution, it utilizes numerous plugins to automate repetitive processes like configuration validation, vulnerability enrichment, or initiating remediation workflows. This automation frees up valuable security and IT resources, helping maintain project velocity.

Enhancing risk management: Before, during, and after migration

Migrating to the cloud should not involve transferring existing on-premises security risks or inadvertently creating new ones in the AWS environment. Proactive risk management, integrated throughout the migration lifecycle, is essential.

  • Before migration: Surface Command’s ability to discover known and unknown assets provides a foundational inventory, helping prevent the migration of forgotten or unsecured systems. Concurrently, Exposure Command’s vulnerability management capabilities allow organizations to identify and address critical weaknesses in on-premises systems targeted for migration, leveraging threat-aware risk scoring to prioritize remediation efforts before these systems enter the cloud.
  • During migration (mobilize and migrate phases): As the AWS environment is established and workloads deployed, Exposure Command ensures secure configuration and detects drift. Its capabilities aid in managing cloud permissions and enforcing least privilege. Critically, Exposure Command integrates sensitive data discovery capabilities, leveraging technologies like InsightCloudSec or ingesting findings from services such as Amazon Macie. This provides visibility into the location of sensitive data within AWS. This data-centric context is incorporated into Exposure Command’s risk analysis, including attack path analysis, allowing teams to prioritize threats based on the potential business impact of compromised sensitive information.
  • During and after migration (modernization and ongoing operations): In modern cloud environments utilizing CI/CD pipelines, Exposure Command supports a proactive DevSecOps approach. By integrating security checks directly into the development lifecycle—scanning container images and validating Infrastructure-as-Code (IaC) templates—organizations can identify and fix security flaws before deployment to AWS. This “shift-left” strategy, facilitated by integrations with CI/CD platforms, significantly reduces the risk of introducing vulnerabilities into the production AWS environment and embeds security into cloud operations.

Building confidence through visibility, control, and automation

Achieving efficiency and robust risk management culminates in greater organizational confidence throughout the migration process and into ongoing cloud operations. Access to accurate, comprehensive data on assets and their associated vulnerabilities and risks allows for more informed, data-driven migration planning.

This comprehensive approach enables organizations to:

  • Move beyond simple lift-and-shift approaches, using security posture data to strategically decide which workloads to migrate, identify necessary pre-migration remediation, and design secure target architectures in AWS.
  • Validate the security posture of the foundational AWS environment with Exposure Command providing assurance before large-scale workload migration commences.
  • Benefit from consolidated visibility and reporting through dashboards and features like Executive Risk View, offering stakeholders clear insights into the security status and risk landscape. This capability translates technical findings into business-relevant risk information to foster broader confidence.
  • Leverage integrated detection and automatic response capabilities post-migration to ensure the security team can manage potential threats effectively in the new AWS environment.

This level of comprehensive visibility and control replaces uncertainty with operational readiness.

Achieving a secure and confident AWS transition

The transition to AWS offers substantial benefits in terms of agility, scalability, and innovation. However, realizing these benefits securely requires navigating the inherent complexities of migration and cloud operations.

Rapid7’s integrated solutions – Surface Command for foundational visibility and Exposure Command for comprehensive risk management across vulnerabilities, cloud  workloads, sensitive data, and CI/CD pipelines)provide the unified capabilities needed to manage the cloud journey efficiently and securely.

By delivering clarity and control across the entire migration lifecycle and into ongoing operations, the platform helps organizations manage the complexity of cloud security, enabling them to migrate to and operate within AWS with confidence.

Gain complete visibility for your AWS migration. Start your Surface Command free trial today.

Use AI agents and the Model Context Protocol with Amazon SES

Post Syndicated from Zip Zieper original https://aws.amazon.com/blogs/messaging-and-targeting/use-ai-agents-and-the-model-context-protocol-with-amazon-ses/

Amazon Simple Email Service (Amazon SES) delivers a cloud-based email solution that empowers businesses to send emails more efficiently and at a larger scale. Its powerful, scalable platform enables organizations from startups to global brands to send personalized, high-volume email communications while maintaining exceptional deliverability and performance.

Amazon SES caters to a wide range of users, from developers and technical marketing professionals to business communicators. In addition to offering robust programmatic access through APIs and SMTP protocols, Amazon SES provides a comprehensive web console and intuitive dashboards that make email configuration and performance monitoring accessible to users with varying technical backgrounds. Historically, navigating email workflows and configuring advanced email capabilities in Amazon SES has required specialized knowledge, resulting in a learning curve for new users. As seen in many other areas, today’s AI tools can offer more intuitive ways to manage Amazon SES to get the most out of your email communications. We have found, however, that these AI tools occasionally produce inconsistent results, often as a result of the underlying large language model’s (LLM’s) training data.

Recognizing the need for a specialized, service-aware, AI-friendly Amazon SES solution, we are introducing the SESv2 MCP Server, a sample Model Context Protocol (MCP) for Amazon SES. We’ve integrated the SESv2 MCP Server sample with the Amazon SES v2 APIs to provide more precise and reliable AI-assisted use, management, and configuration for Amazon SES.

MCP is an open protocol that enables seamless integration between your AI-powered integrated development environment (IDE) or AI assistant, enriching the capabilities of the AI and enabling you to use Amazon SES using natural language. For more info, see the GitHub repo.

We’ve released the SESv2 MCP Server sample on GitHub and invite current and prospective customers to experiment with it in non-production environments. You can use it with your AI tools to explore ways in which AI can be used with Amazon SES to send emails, check configurations, and review deliverability. We’re interested in learning how you use your AI tools and the SESv2 MCP Server to test out email sending in different services or applications. We’re also curious if new customers find it helpful when configuring and learning about their Amazon SES service. No matter how you use it, we are eager for your feedback, comments, and contributions through the GitHub project’s issues.

Solution overview

You can use the SESv2 MCP Server sample with AI assistant applications like Anthropic’s Claude Desktop. You can also integrate it into MCP-compatible agentic AI coding assistants such as Amazon Q Developer, Amazon Q for command line, Cline, Cursor, and Windsurf. When used as an AI coding assistant, the SESv2 MCP Server sample helps developers add Amazon SES email capabilities to their applications and services using plain, natural language prompting. For recommendations from AWS on how to improve your vibe coding experience, refer to Vibe coding tips and tricks.

After you’ve configured the sample and authenticated with your AWS credentials, you can use natural language in your chosen AI tool. For example, an email marketing manager might want to ask Anthropic’s Claude Desktop “provide me with the status of the verified identities in my SES account, along with any recommendations to improve deliverability.” Someone new to Amazon SES can ask the Amazon Q CLI “create a new Amazon SES configuration set for the octank.com identity, enable it for event publishing for bounces and complaints.” Similarly, the developer of an AI-enabled restaurant booking application might ask the Amazon Q CLI “my application needs to send email confirmation of a customers online booking. Can you walk me thru adding this capability to my app using my SES account?”

As you can see from these examples, although it’s helpful to know a bit about email, and Amazon SES in general, with the help of your AI tool and the SESv2 MCP Server sample, you don’t need to be an email or Amazon SES expert. The combination of your creativity, AI tool, and the SESv2 MCP Server sample empowers even non-developers to create, test, and monitor Amazon SES workflows using natural language.

The SESv2 MCP Server sample release uses the open source Smithy Java project, which is still in development. As such, the SESv2 MCP Server is considered a sample, and we do not recommend employing it for production use. When a stable version is available, we might update this post and the GitHub repository accordingly.

Prerequisites

To follow along with the example use cases, make sure you have the following prerequisites set up:

  • AWS credentials with appropriate permissions.
  • An MCP-compatible LLM client (such as Anthropic’s Claude Desktop, Cline, Amazon Q CLI, or Cursor). For this post, we use the Amazon Q Developer CLI. For installation instructions, refer to Installing Amazon Q for command line.
  • Java 21 (or later) runtime (as required by Smithy Java).
  • Access to GitHub.
  • Git installed locally. For instructions, see Getting Started – Installing Git.

Best practices for using MCPs

To maximize the benefits of MCP-assisted development while maintaining security and code quality, we suggest you follow these essential guidelines:

  • Always review generated code for security implications before deployment
  • Use MCP servers as accelerators, not replacements for developer judgment and expertise
  • Keep MCP servers updated with the latest AWS security best practices
  • Follow the principle of least privilege when configuring AWS credentials
  • Run security scanning tools on generated infrastructure code

Configure the AWS CLI

Use the following command to configure the AWS Command Line Interface (AWS CLI) with the AWS credentials for your Amazon SES account and AWS Region:

aws configure

Clone and build the GitHub repository locally

To use macOS or Linux, use the following command to clone and build the GitHub repo:

git clone https://github.com/aws-samples/sample-for-amazon-ses-mcp.git
cd sample-for-amazon-ses-mcp
./build.sh

For Windows, use the following command:

git clone https://github.com/aws-samples/sample-for-amazon-ses-mcp.git
cd sample-for-amazon-ses-mcp
.\build.bat

Copy the absolute path to the .jar file (JAR_PATH_FROM_BUILD_OUTPUT). This will be printed at the end of the build script:

/<your path>/sample-for-amazon-ses-mcp/artifacts/sample-for-amazon-ses-mcp-all.jar

Configure your AI tool to use SESv2 MCP Server

When the build is complete, add SESv2 MCP Server to your AI tool’s MCP configuration:

{
  "mcpServers": {
    "sesv2-mcp-server": {
      "command": "java",
      "args": [
        "-jar",
        "JAR_PATH_FROM_BUILD_OUTPUT"
      ]
    }
  }
}

See MCP configuration for configuration steps. See the Claude Desktop MCP configuration guide for setup instructions.

After you build the SESv2 MCP Server and configure your AWS credentials, you’re ready to interact with Amazon SES. Keep in mind that effective, thoughtful prompting is crucial for successful AI-assisted development. For more information about vibe coding, see Vibe coding tips and tricks.

Example use cases

In this section, we provide some guided examples using the Amazon Q Developer CLI to interact with Amazon SES. Feel free to experiment on your own use cases, and share your comments and ideas through the GitHub project’s issues. Do not disclose any personal, commercially sensitive, or confidential information.

Get information, recommendations, and configurations your Amazon SES account

Open your AI tool; for these examples, we use a macOS terminal and initiate a chat session with the Amazon Q CLI:

q chat

We’ve found it useful to provide your AI tool with some guidance:

You're connected to the SESv2 MCP Server and have access to the AWS SESv2 APIs.

Ask the Amazon Q CLI about your AWS account’s SES email identities:

Tell me about the identities in my account, and also if the account is in the SES sandbox?

The Amazon Q CLI will request permission to use the SESv2 MCP Server (which provides the Amazon Q CLI with the SESv2 APIs ListEmailIdentities and GetAccount) to query your AWS SES account and reply with a detailed summary.

Ask the Amazon Q CLI if it has any recommendations related to improving deliverability for your Amazon SES account:

Do you have any recommendations to improve email deliverability for my SES account?

The Amazon Q CLI will use the SESv2 MCP Server (which provides the CLI with the SESv2 API ListRecommendations) to query your Amazon SES account and reply with a detailed summary.

Ask the Amazon Q CLI to set up Amazon SES click tracking for one of your domains. We have found it helpful to remind the CLI that it has access to additional knowledge of the AWS service APIs. It’s also a good idea to make sure the AI tool doesn’t invent nonexistent APIs.

You also have access to other AWS service APIs via the AWS CLI and your general knowledge, but you may only use known, documented APIs - do not invent or create any APIs or commands.
Set up Amazon SES click tracking with CloudWatch integration for the domain <my verified identity> to monitor email metrics. Use Amazon's default tracking domain (no SSL or https) for the click tracking to ensure immediate functionality without requiring custom domain setup. Include all necessary configuration steps and verify the setup works correctly. Create a test HTML email to <my email address> from <no-reply@verified domain> with subject "Testing SES click tracking". Create an HTML (with fallback to text) body with links and short descriptions taken from the public AWS webpages for Amazon SES, AWS End User Messaging and Amazon Connect. 

Send emails with your Amazon SES account

Using its knowledge of Amazon SES from the SESv2 MCP Server and permissions to use your Amazon SES account (aws configure), you can use your AI tool to create and send emails using Amazon SES.

If your Amazon SES account is in the Amazon SES sandbox, you are limited to sending and receiving email from verified email addresses. You are also limited to 200 messages in 24 hours. For more information about the Amazon SES sandbox, see Request production access (Moving out of the Amazon SES sandbox). If you’re in the sandbox, you can simply ask your AI tool “verify my email address <[email protected]>.”

Ask the Amazon Q CLI to send a test email with a sample HTML body:

Send a test email to <my verified email address> from <verified SES email identity>. Set the from email display name to "MCP testing". Make the email subject "Test sending an email via SES MCP". Use the information found on the Amazon SES website to create an HTML message body with a few sentences and bullet points about SES. Provide a text version of the message body in case of fallback.

Check your email, where you will receive a response.

You can get creative and ask the Amazon Q CLI to create a formatted email template with personalization using a simple table with email recipients, the product they bought, and their postal code:

Use the table below to send each person in the table an html formatted (with fallback) email message. 
-- table --
email,name,product,zipcode
<my verified email address>,Alice,an umbrella,98101
<my verified email address>,Bob,lots of sunscreen,10001
-- end table --
Use the template below. Create a 5-day weather forecast graphic similar to popular weather app graphics based on estimated weather for their ZIP code.
-- template --
"Hi {{name}}, thanks for buying {{product}}; it looks like you'll need it soon based on the 5-day weather forecast for your local area: <5-day weather forecast graphic>.

As we’ve demonstrated, you don’t need to be a seasoned developer to create and test Amazon SES workflows when you have an AI tool and the SESv2 MCP Server sample.

Conclusion

The SESv2 MCP Server sample democratizes the ability to configure, manage, and create sophisticated email automation workflows with Amazon SES.

The examples and guidance in this post demonstrate how even newcomers can use AI tools like the Amazon Q CLI to test out configuring, monitoring, and sending emails with Amazon SES using natural language. More technical users, including developers, can use the SESv2 MCP Server sample to build and test intelligent email applications that use Amazon SES, or to test out building Amazon SES sending into their own application.

We hope you will experiment with the SESv2 MCP Server sample and provide us with your thoughts and feedback, and perhaps contribute to the project through the GitHub project’s issues.

Additional resources

Navigating AWS Migration: Achieving Clarity and Confidence

Post Syndicated from Jack Clavette original https://blog.rapid7.com/2025/06/05/navigating-aws-migration-achieving-clarity-and-confidence/

Navigating AWS Migration: Achieving Clarity and Confidence

Migrating workloads to Amazon Web Services (AWS) represents a significant strategic opportunity, enabling greater agility, scalability, and potential for innovation. But undertaking this transition without a comprehensive strategy for visibility and security can introduce unforeseen risks, operational delays, and challenges in managing the new cloud environment effectively. A critical aspect often overlooked is the discovery and protection of sensitive data as it moves to and resides within the cloud, demanding specific attention.

Addressing security proactively is not merely a technical requirement: it functions as a crucial enabler, allowing organizations to fully realize the strategic benefits of the cloud without being hindered by security roadblocks or compliance failures.

Furthermore, bringing sensitive data protection into focus early connects the technical migration process directly to significant business risks, such as regulatory non-compliance and the potential impact of data breaches, underscoring the importance of robust security solutions for confidently realizing cloud benefits.

Integrating security across the migration lifecycle

A successful and secure migration is not achieved by treating security as an afterthought. Security considerations must be integrated throughout the entire migration lifecycle – from the initial assessment of the current environment, through mobilizing resources and establishing the cloud foundation, to the final migration and modernization phases.

Cloud migration typically involves distinct stages:

  1. Assess: Evaluating the current state, identifying assets, and understanding existing risks.
  2. Mobilize: Preparing resources and establishing a secure cloud foundation or landing zone in AWS.
  3. Migrate and modernize: Transferring workloads and potentially optimizing them for the cloud environment.

Addressing security continuously across these stages helps prevent costly delays and rework often associated with late-stage security implementations. Effective tooling and methodology are essential here.

Rapid7’s security platform is designed to support organizations through this journey, providing the necessary visibility, risk context, and security controls for a smoother transition to AWS. The platform unifies critical capabilities, aiming to provide a 360° view of the attack surface and streamlining security operations across hybrid environments.

Improving migration efficiency through unified security

Efficiency is paramount across migration phases to maintain project velocity without compromising security. Managing multiple disparate tools can impede progress and obscure visibility. Rapid7 helps streamline critical activities by unifying essential capabilities within its Command Platform:

  • Surface Command: Provides comprehensive asset discovery and attack surface management.
  • Exposure Command: Delivers vulnerability risk management, cloud security posture management, and workload protection.
  • Insight Connect: Enables security orchestration, automation, and response (SOAR).

This integrated approach offers advantages beyond simplified tool management, potentially leading to richer context through data correlation and more effective prioritization.

During assessment

Comprehensive planning requires a complete asset inventory. Surface Command accelerates the initial assessment phase through rapid, comprehensive asset discovery across internal and external inventories, including cloud environments like AWS. This helps to eliminate blind spots and identify all assets, including potentially unsecured systems, before they are considered for migration.

Subsequently, Exposure Command builds upon this asset foundation, adding vulnerability data (often leveraging capabilities from solutions like InsightVM) and risk scoring to identify critical weaknesses in on-premises systems slated for migration. It enables teams to focus remediation efforts effectively by prioritizing vulnerabilities based on threat-aware risk context before these systems move to the cloud.

During mobilize and migrate and modernize:

In these intensive phases, Exposure Command ensures the AWS landing zone and core services are configured securely according to organizational policies and industry best practices (e.g., CIS Benchmarks) through its Cloud Security Posture Management (CSPM) capabilities, while providing ongoing monitoring for misconfigurations. It also plays a critical role in managing cloud permissions by analyzing identities and access rights to help enforce least-privilege access models.

As workloads are deployed, it offers Cloud Workload Protection (CWP) and vulnerability management tailored for cloud assets, including container security. Concurrently, Insight Connect reduces the manual workload associated with security tasks. As a SOAR solution, it utilizes numerous plugins to automate repetitive processes like configuration validation, vulnerability enrichment, or initiating remediation workflows. This automation frees up valuable security and IT resources, helping maintain project velocity.

Enhancing risk management: Before, during, and after migration

Migrating to the cloud should not involve transferring existing on-premises security risks or inadvertently creating new ones in the AWS environment. Proactive risk management, integrated throughout the migration lifecycle, is essential.

  • Before migration: Surface Command’s ability to discover known and unknown assets provides a foundational inventory, helping prevent the migration of forgotten or unsecured systems. Concurrently, Exposure Command’s vulnerability management capabilities allow organizations to identify and address critical weaknesses in on-premises systems targeted for migration, leveraging threat-aware risk scoring to prioritize remediation efforts before these systems enter the cloud.
  • During migration (mobilize and migrate phases): As the AWS environment is established and workloads deployed, Exposure Command’s CSPM functions ensure secure configuration and detect drift. Its capabilities aid in managing cloud permissions and enforcing least privilege. Critically, Exposure Command integrates sensitive data discovery capabilities, leveraging technologies like InsightCloudSec or ingesting findings from services such as Amazon Macie. This provides visibility into the location of sensitive data within AWS. This data-centric context is incorporated into Exposure Command’s risk analysis, including attack path analysis, allowing teams to prioritize threats based on the potential business impact of compromised sensitive information.
  • During and after migration (modernization and ongoing operations): In modern cloud environments utilizing CI/CD pipelines, Exposure Command supports a proactive DevSecOps approach. By integrating security checks directly into the development lifecycle—scanning container images and validating Infrastructure-as-Code (IaC) templates—organizations can identify and fix security flaws before deployment to AWS. This “shift-left” strategy, facilitated by integrations with CI/CD platforms, significantly reduces the risk of introducing vulnerabilities into the production AWS environment and embeds security into cloud operations.

Building confidence through visibility and control

Achieving efficiency and robust risk management culminates in greater organizational confidence throughout the migration process and into ongoing cloud operations. Access to accurate, comprehensive data on assets (via Surface Command) and their associated vulnerabilities and risks (via Exposure Command) allows for more informed, data-driven migration planning.

This comprehensive approach enables organizations to:

  • Move beyond simple lift-and-shift approaches, using security posture data to strategically decide which workloads to migrate, identify necessary pre-migration remediation, and design secure target architectures in AWS.
  • Validate the security posture of the foundational AWS environment with Exposure Command’s CSPM capabilities, providing assurance before large-scale workload migration commences.
  • Benefit from consolidated visibility and reporting through dashboards and features like the Executive Risk View, offering stakeholders clear insights into the security status and risk landscape. This capability translates technical findings into business-relevant risk information, fostering broader confidence.
  • Leverage integrated detection and response capabilities post-migration, often orchestrated through Insight Connect, ensuring the security team is equipped to manage potential threats effectively in the new AWS environment

This comprehensive visibility and control replace uncertainty with operational readiness.

Achieving a secure and confident AWS transition

The transition to AWS offers substantial benefits in terms of agility, scalability, and innovation. However, realizing these benefits securely requires navigating the inherent complexities of migration and cloud operations.

Rapid7’s integrated solutions – Surface Command for foundational visibility, Exposure Command for comprehensive risk management (including vulnerability management, cloud security posture, workload protection, sensitive data context, and DevSecOps integration), and Insight Connect for automation and response – provide the unified capabilities needed to manage this journey efficiently and securely.

By delivering clarity and control across the entire migration lifecycle and into ongoing operations, the platform helps organizations manage the complexity of cloud security, enabling them to migrate to and operate within AWS with confidence.

Gain complete visibility for your AWS migration. Start your Surface Command free trial today.

AWS End User Messaging SMS & Voice v2 API: A Migration Guide from v1

Post Syndicated from Brett Ezell original https://aws.amazon.com/blogs/messaging-and-targeting/aws-end-user-messaging-sms-and-voice-v2-api-a-migration-guide-from-v1/

This blog covers the steps on how to upgrade to the latest APIs offered by AWS for SMS messaging.

IMPORTANT: Understanding this Migration in Context of Amazon Pinpoint’s End of Support

Amazon Pinpoint announced its end of support (EOS) on October 2026. However, if you are an existing customer using Amazon Pinpoint for SMS, your current SMS operations are not impacted by the EOS, and you are not required to migrate to the v2 API at this time.

This blog post details an optional upgrade path from the Amazon Pinpoint v1 SendMessages API to the AWS End User Messaging SMS and Voice v2 SendTextMessage API. Transitioning allows you to leverage enhanced capabilities and new features available exclusively in the v2 API.

Regarding your existing resources: Your SMS phone numbers and sender ID resources are already stored in AWS End User Messaging. There is no need to register new numbers (originators) or configure new Sender IDs if you choose to migrate your API usage as described here.

AWS End User Messaging provides developers with a scalable and cost-effective messaging infrastructure without compromising the safety, security, or results of their communications. Developers can integrate messaging over channels such as SMS, MMS, voice text-to-speech, WhatsApp and mobile push to support use cases such as one-time passwords (OTP) at sign-ups, account updates, appointment reminders, delivery notifications, promotions and more. AWS End User Messaging was renamed in 2024 as the new name for Amazon Pinpoint’s communication capabilities. For the SMS protocol, the service includes two sets of APIs, including SMS and Voice, version 2 API (v2 API), which provides enhanced capabilities and flexibility for customer communications and the original Amazon Pinpoint v1 API.

The End User Messaging SMS service provides core building blocks and is the core service in charge of SMS delivery for other AWS services, including Amazon Simple Notification Service (SNS), Amazon Cognito, and Amazon Connect. Transitioning to the v2 API allows customers using the older Amazon Pinpoint v1 API to access enhanced capabilities available now—like improved control via Configuration Sets, Phone Pools, Protect Configurations, and Registrations—as well as ensuring access to future features developed exclusively in the V2 APIs.

In this post, we will focus on why transitioning is beneficial and how developers can transition from Amazon Pinpoint’s v1 SendMessages API to the AWS End User Messaging SMS and Voice, version 2 (SendTextMessage) API. This move offers more functionality for creating custom messaging solutions and integrating seamlessly with third-party applications. Consolidating management and messaging into AWS End User Messaging provides customers with greater control and access to the features and capabilities described below.

What Are the Changes and Benefits of Migrating?

Migrating from the Pinpoint v1 SendMessages API to the AWS End User Messaging v2 SendTextMessage API offers several key advantages in plain language:

  • Simpler Code: The new SendTextMessage API has a flatter, more straightforward structure compared to the nested configuration required by the old SendMessages API. This makes your code easier to write, read, and maintain.
  • More Control Over Delivery: AWS End User Messaging introduces new tools that give you fine-grained control:
    • Configuration Sets: Apply specific rules for logging via Event Destinations, routing (using specific number pools), and opt-out management per message.
    • Phone Pools: Group your sending phone numbers or sender IDs to manage sender reputation, improve reliability with failover, and handle different use cases more effectively.
    • Protect Configurations: Set account-level safety rules, like blocking messages to certain countries, or filtering messages suspected to be Artificially Inflated Traffic (AIT), enhancing security and compliance.
    • Message Feedback: Enable detailed feedback mechanisms and track message conversion data like one time passcode conversions.
  • Better Monitoring & Troubleshooting: With Configuration Sets and Event Destinations, you retain detailed delivery logs, Delivery Receipts (DLRs), and event tracking, similar to Pinpoint’s event streaming. This allows comprehensive monitoring via Amazon EventBridge, Amazon CloudWatch, Amazon Data Firehose, or Amazon SNS.
  • Expanded Capabilities: The AWS End User Messaging v2 API exclusively supports Media Messaging Service (MMS) and includes integrated tools for managing control plane activities, such as sender registrations required in many countries.
  • Future-Proofing: AWS is actively developing new features exclusively for the AWS End User Messaging v2 API. Migrating ensures you can leverage the latest advancements in messaging technology.

Understanding Key AWS End User Messaging Components

Migration involves understanding and utilizing several core AWS End User Messaging components:

Phone Pools

  • What they are: A Phone Pool is a collection of your origination identities (phone numbers, Sender IDs) that share common settings. When you send a message using a pool, AWS End User Messaging can automatically select an appropriate identity from that pool.
  • Benefits:
    • Improved Reliability: Pools provide automatic failover; if one number in the pool fails, another can be used.
    • Reputation Management: You can create separate pools for different use-cases, or types of messages (e.g., transactional vs. promotional) to isolate sender reputations.
    • Simplified Configuration: Apply settings like opt-out lists or two-way SMS configurations to the entire pool.
  • When to Use: Pools are highly recommended for managing multiple origination identities, ensuring high availability, or separating traffic. However, they are optional. If you only use a single phone number or Sender ID for a specific use case, you can continue to specify that single identity directly in your SendTextMessage API calls.

Protect Configurations

  • What they are: Protect Configurations allow you to define account-wide or configuration-set-level rules that safeguard against unwanted traffic, including Artificially Inflated Traffic (AIT) and messages to specific destinations. They operate using rules applied per country, which can be set to different modes: Block (prevent sending to specified countries), Monitor (analyze traffic for AIT risk without blocking, providing visibility), or Filter (automatically block messages suspected of being AIT based on risk analysis, in addition to blocking specified countries).
  • Benefits:
    • Enhanced Security: Prevent accidental or malicious sending to unintended destinations by explicitly blocking specific countries.
    • Proactive AIT Defense (Filter): Automatically block suspected fraudulent SMS pumping traffic based on risk analysis before messages are sent, reducing exposure to financial costs and potential reputation damage associated with AIT.
    • Risk Visibility (Monitor): Gain insights into potential AIT patterns targeting your account and understand the likely impact of Filter rules without disrupting legitimate message delivery. Recommendations are provided via event destinations.
    • Compliance: Helps enforce geographic sending restrictions required by regulations or internal policies.
    • Cost Control: Avoid unexpected charges from sending to blocked/filtered destinations.
    • Granular Application: Apply different rules (Block/Monitor/Filter) per country and use multiple Protect Configurations tailored to different workflows (e.g., stricter filtering for public-facing forms vs. internal notifications).
  • Note: Protect Configurations, including the Monitor and Filter modes for AIT, are features unique to the AWS End User Messaging v2 API and are not available in the Pinpoint v1 API. Check out Defending Against SMS Pumping: New AWS Features to Help Combat Artificially Inflated Traffic to learn more.

Configuration Sets

  • What they are: Configuration Sets are collections of rules applied to messages when you send them. You specify which Configuration Set to use in your SendTextMessage API call.
  • Benefits:
    • Essential for Monitoring: Configuration Sets are required to receive message event data (including Delivery Receipts – DLRs). They replace the automatic event streaming provided by Pinpoint v1. You must associate an Event Destination (EventBridge, CloudWatch Logs, Amazon Data Firehose, or SNS) with your Configuration Set to capture delivery status, failures, and other events.
    • Granular Control: Apply specific settings per message, such as routing messages through specific Phone Pools, using different default Sender IDs, or associating different opt-out lists.
    • Message Feedback: Enable detailed feedback mechanisms.
  • Key Takeaway: Migrating users must create and use Configuration Sets with associated Event Destinations if they need to monitor message delivery status, replicating the functionality previously provided by Pinpoint event streams.

Registrations

  • What they are: In many countries and regions, regulations require businesses to register their Sender IDs or phone numbers (like US 10DLC numbers) before sending A2P (Application-to-Person) messages. Some regions (like India or China) may also require pre-registering message templates.
  • Benefits:
    • Compliance: Ensures adherence to local telecommunication laws and carrier requirements.
    • Improved Deliverability: Registered traffic is often treated with higher priority and is less likely to be filtered as spam by carriers.
  • When Needed: Registration requirements — or lack thereof — vary significantly by country (e.g., US 10DLC, UK Sender IDs, India Sender IDs) and the type of number/Sender ID used. While some origination identities in certain regions may not require pre-registration, the landscape is complex and evolving. Always check the AWS documentation for the specific, current requirements of the countries you send messages to. AWS End User Messaging provides tools within the console and API to help manage any necessary registrations.

Additional Key Differences & Benefits

  • MMS Support: The AWS End User Messaging v2 API provides clear, first-class support for sending Multimedia Messaging Service (MMS) messages via the SendMediaMessage API call, offering richer media possibilities than typically available via the older Pinpoint API.
  • API Simplicity: The SendTextMessage API call is significantly less nested and complex than the SendMessages API structure, making integration and maintenance easier.
    • Example Comparison:
    • # Pinpoint v1 SendMessages (Nested Structure)
response = pinpoint_client.send_messages(
    ApplicationId='YOUR_PINPOINT_PROJECT_ID',
    MessageRequest={
        'Addresses': {
            '+12065550100': { # Destination Address
                'ChannelType': 'SMS'
            }
        },
        'MessageConfiguration': {
            'SMSMessage': {
                'Body': 'Your message content',
                'MessageType': 'TRANSACTIONAL',
                'OriginationNumber': '+12065550199' # Origination Number
            }
        }
    }
)

# AWS End User Messaging v2 SendTextMessage (Flatter Structure)
response = end_user_messaging_client.send_text_message(
    DestinationPhoneNumber='+12065550100',
    OriginationIdentity='+12065550199', # Can be Number, SenderID, Pool ARN/ID
    MessageBody='Your message content',
    MessageType='TRANSACTIONAL'
    # Optional: ConfigurationSetName='MyConfigSet'
)

      This side-by-side comparison clearly shows the reduced nesting and more direct parameter usage in the AWS End User Messaging SendTextMessage API call.

  • Broader Regional Availability: The AWS End User Messaging v2 API offers significantly broader regional availability compared to the older Pinpoint v1 API (currently supported in over 30 regions versus 13). AWS also plans to expand this support to an additional 4 regions soon (reaching 34 total), further improving global reach and potentially reducing latency.

How to Use AWS End User Messaging Features Functionally (API Examples)

Here’s how you use the SendTextMessage API (using AWS SDK for Python Boto3 as an example) to leverage these features:

import boto3
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

# Initialize the AWS End User Messaging v2 client
# Note the client name change from 'pinpoint'
end_user_messaging_client = boto3.client('pinpoint-sms-voice-v2')

# --- Basic SMS Send ---
try:
    response = end_user_messaging_client.send_text_message(
        DestinationPhoneNumber='+12065550100',
        OriginationIdentity='+12065550199', # Your AWS End User Messaging registered Phone Number, Sender ID, or Pool ARN/ID
        MessageBody='Hello from AWS End User Messaging!',
        MessageType='TRANSACTIONAL' # Or 'PROMOTIONAL'
    )
    logger.info(f"Basic Send - Message ID: {response.get('MessageId')}")
except Exception as e:
    logger.error(f"Basic Send Failed: {e}")

# --- Send with a Configuration Set (for DLRs/Events) ---
try:
    response = end_user_messaging_client.send_text_message(
        DestinationPhoneNumber='+12065550101',
        OriginationIdentity='+12065550199',
        MessageBody='This message uses a configuration set.',
        MessageType='TRANSACTIONAL',
        ConfigurationSetName='MyConfigSet' # Specify your Configuration Set
    )
    logger.info(f"Config Set Send - Message ID: {response.get('MessageId')}")
except Exception as e:
    logger.error(f"Config Set Send Failed: {e}")

# --- Send using a Phone Pool ---
try:
    response = end_user_messaging_client.send_text_message(
        DestinationPhoneNumber='+12065550102',
        OriginationIdentity='arn:aws:sms-voice:us-east-1:111122223333:pool/MyPhonePool', # Use Pool ARN or ID
        MessageBody='This message is sent via a phone pool.',
        MessageType='TRANSACTIONAL',
        ConfigurationSetName='MyConfigSet' # Still need a Config Set for events
    )
    logger.info(f"Pool Send - Message ID: {response.get('MessageId')}")
except Exception as e:
    logger.error(f"Pool Send Failed: {e}")

# --- Send with a Protect Configuration (via Config Set or directly) ---
# Option 1: Protect Config applied via Configuration Set
# (Configure association in the AWS End User Messaging console or via AssociateProtectConfiguration API)
# No change needed in SendTextMessage call beyond specifying the ConfigurationSetName

# Option 2: Protect Config applied directly per message
try:
    response = end_user_messaging_client.send_text_message(
        DestinationPhoneNumber='+12065550103',
        OriginationIdentity='+12065550199',
        MessageBody='This message has direct protect config applied.',
        MessageType='TRANSACTIONAL',
        ProtectConfigurationId='MyProtectConfig' # Specify Protect Configuration ID or ARN
        # ConfigurationSetName='MyConfigSet' # Can also be used if needed for other rules like events
    )
    logger.info(f"Protect Config Send - Message ID: {response.get('MessageId')}")
except Exception as e:
    logger.error(f"Protect Config Send Failed: {e}")

# --- Standard Exception Handling ---
try:
    response = end_user_messaging_client.send_text_message(
        DestinationPhoneNumber='+12065550104',
        OriginationIdentity='+12065550199',
        MessageBody='Testing exception handling.',
        MessageType='TRANSACTIONAL',
        ConfigurationSetName='MyConfigSet'
    )
    logger.info(f"Exception Test Send - Message ID: {response.get('MessageId')}")
except end_user_messaging_client.exceptions.ThrottlingException:
    logger.error("Rate limit exceeded. Implementing backoff.")
except end_user_messaging_client.exceptions.ValidationException as e:
    logger.error(f"Validation error: {str(e)}")
except Exception as e:
     logger.error(f"Generic error sending message: {e}")

How to Migrate SDKs

Migrating your application code involves updating your AWS SDK initialization:

  1. Identify SDK Usage: Locate where your code uses the AWS SDK to interact with the Pinpoint v1 API, specifically for sending SMS (likely using client.send_messages(...)).
  2. Update Client Initialization: Change the service client you initialize.
    • Python (Boto3): Change boto3.client('pinpoint') to boto3.client('pinpoint-sms-voice-v2').
    • Other SDKs: Consult the specific AWS SDK documentation for the equivalent change. The service identifier will typically change from pinpoint or similar to pinpoint-sms-voice-v2 or equivalent.
  3. Update API Calls: Replace calls to the Pinpoint v1 SendMessages operation with calls to the AWS End User Messaging v2 SendTextMessage operation, adjusting the parameter structure as shown in the examples above.
  4. Dependencies: Ensure your application deployment includes the necessary updated SDK libraries.

Data Migration Considerations

Endpoint Contextual Data: Pinpoint allows associating rich attributes and user data with endpoints, often used in campaigns. If your application logic for sending direct SMS via the Pinpoint SendMessages API previously relied on accessing these Pinpoint endpoint attributes at the time of sending (e.g., for personalization), note that the AWS End User Messaging SendTextMessage API operates independently of the Pinpoint endpoint data model. Your application will now need to fetch any required contextual data (user attributes, preferences, etc.) itself before calling SendTextMessage if that information is needed for message construction or logic.

Opt-Out Lists (Optional):

IMPORTANT: End User Messaging has automatically been adding opt-outs to a “default optout list” for all SMS you have sent out unless you have been self managing opt-outs. Check to see if you have numbers in the “default” list in the console or by using DescribeOptedOutNumbers and using “default” as the OptOutListName.

If you are managing opt-outs at the endpoint level, managing them within your application, or only have opt-outs in the “default” list, it’s recommended that you export those numbers into a new End User Messaging Opt-Out List.

  1. Extract from Pinpoint: Identify and extract the phone numbers opted out of SMS within your Pinpoint project. This typically involves exporting endpoint data (using the Pinpoint API, like GetEndPoints, or GetSegmentExportJobs) and filtering for endpoints associated with the SMS channel that have an OptOut status set (e.g., ALL). You may need custom processing to isolate the correct phone numbers.
  2. Create AWS End User Messaging List: Create a new opt-out list in AWS End User Messaging using the CreateOptOutList API operation (e.g., name it MigratedPinpointOptOuts).
  3. Import Numbers: Add the phone numbers extracted from Pinpoint into the newly created AWS End User Messaging opt-out list using the PutOptedOutNumber API operation for each number.
  4. Associate List: Associate your new AWS End User Messaging Opt-Out List with the relevant Phone Pool(s) or individual origination phone number(s)/Sender ID(s) using the appropriate AWS End User Messaging API calls (e.g., SetDefaultPoolOptOutList, SetPhoneNumberOptedOut). This ensures AWS End User Messaging automatically blocks sends to these numbers when using those specific origination identities. Note: Opt-out lists are associated with origination identities, not directly with Configuration Sets.

Here’s an accurate AWS SDK for Python (Boto3) example that demonstrates this process:

import boto3

# Initialize clients
pinpoint = boto3.client('pinpoint')
eum = boto3.client('pinpoint-sms-voice-v2')

# Step 1: Extract opted-out numbers from Pinpoint
def get_opted_out_numbers(project_id):
    opted_out_numbers = set()
    paginator = pinpoint.get_paginator('get_endpoints')
    
    for page in paginator.paginate(ApplicationId=project_id):
        for item in page['ItemResponse'].values():
            if item['ChannelType'] == 'SMS' and item.get('OptOut') == 'ALL':
                opted_out_numbers.add(item['Address'])
    
    return opted_out_numbers

# Example usage
project_id = 'YOUR_PINPOINT_PROJECT_ID'
opted_out_numbers = get_opted_out_numbers(project_id)

# Step 2: Create AWS End User Messaging Opt-Out List
opt_out_list_name = 'MigratedPinpointOptOuts'
eum.create_opt_out_list(OptOutListName=opt_out_list_name)

# Step 3: Import Numbers to the new Opt-Out List
for number in opted_out_numbers:
    eum.put_opted_out_number(
        OptOutListName=opt_out_list_name,
        OptedOutNumber=number
    )

# Step 4: Associate the Opt-Out List with a Phone Pool
phone_pool_id = 'YOUR_PHONE_POOL_ID'
eum.set_default_pool_opt_out_list(
    PhonePoolId=phone_pool_id,
    OptOutListName=opt_out_list_name
)

# If you're using individual numbers not in a pool:
# phone_number = 'YOUR_PHONE_NUMBER'
# eum.set_phone_number_opted_out(
#     PhoneNumber=phone_number,
#     OptOutListName=opt_out_list_name
# )

print(f"Migration complete. {len(opted_out_numbers)} numbers added to the opt-out list.")

Conclusion

Migrating from the legacy Amazon Pinpoint v1 SendMessages API to the modern AWS End User Messaging v2 SendTextMessage API aligns strategically with End User Messaging, the focus of AWS’s ongoing messaging development and advancements. As we’ve explored, this transition is driven by tangible benefits and enhanced capabilities designed for contemporary communication needs.

This guide detailed the key advantages, including a significantly simplified API structure that streamlines development and maintenance. We also covered the core components that provide enhanced control and functionality: Configuration Sets, which are crucial for enabling detailed monitoring and delivery reporting (DLRs); Phone Pools for flexible and reliable sender identity management; Protect Configurations for improved security and compliance; and Registrations for adhering to regional requirements and maximizing deliverability.

This post also outlined the practical steps involved in this migration, from updating your SDK client initialization and adapting your code to use the SendTextMessage API with its new features, to the critical process of migrating existing opt-out lists to ensure continuity and compliance.

By understanding these components, leveraging the new features, and executing the necessary technical and data migration steps, you can successfully transition your SMS operations. This move not only modernizes your infrastructure but also positions you to take full advantage of future advancements on the AWS End User Messaging platform, enabling you to build more robust, scalable, and sophisticated messaging solutions.

Navigate Bulk Sender Requirements with Amazon SES

Post Syndicated from Vinay Ujjini original https://aws.amazon.com/blogs/messaging-and-targeting/navigate-bulk-sender-requirements-with-amazon-ses/

Introduction

Email communication remains a critical component of business operations and customer engagement. As the digital landscape evolves, major mailbox providers continually update their policies to enhance security and user experience. This blog will explore the changes implemented by Microsoft for bulk senders trying to reach Outlook.com (supporting Hotmail.com, live.com consumer domain addresses). This follows the Google & Yahoo! bulk sender requirements changes in February of 2024. Microsoft is implementing the enforcement of sender requirements for bulk email senders, particularly those sending over 5,000 messages daily, starting May 5, 2025. These requirements focus on improving email authentication and trust. This will ensure Outlook and Hotmail recipients are receiving messages that are authenticated and from who they claim to be from. These measures will help reduce spoofing, phishing, and spam, and safeguarding individuals and businesses relying on email.

This blog will discuss what these changes mean for you, and how Amazon Simple Email Service (Amazon SES) can help you maintain compliance and optimize your email sending practices.

Background

In February 2024, Google and Yahoo implemented new requirements for bulk email senders, building upon industry efforts to combat spam and improve email deliverability. These changes aligned with Google’s 2024 bulk sender requirements initiative, signaling a unified approach among major mailbox providers to enhance the privacy and compliance in email.

What does this mean for customers and email senders?

What’s Changing?

Microsoft’s New Requirements

  1. DMARC enforcement with at least a p=none policy
  2. Sender domain authentication (SPF, DKIM)
  3. Functional unsubscribe links required in the email
  4. Requirement for From and Reply-to addresses to be deliverable

Why These Changes Matter?

These new requirements serve several crucial purposes:

  1. Enhances trust in your sending domain: Validates that the sender is who they are claiming to be. Enhances trust by delivering messages that are authenticated and aligned with the bulk sender requirements.
  2. Improved Deliverability: Ensuring legitimate emails reach the recipients who have subscribed to sender’s messages.
  3. User-Centric: Providing recipients with control over their inboxes.
  4. Industry Standardization: Aligning sender requirements across major email providers

Best Practices for Compliance

To adhere to these new requirements and optimize your email sending practices, consider the following best practices:

1. Implement Strong Authentication

  • Configure SPF: SPF (Sender Policy Framework) is an email authentication standard that’s designed to prevent email spoofing. Domain owners use SPF to tell email providers which servers are allowed to send email from their domains. Follow setup instructions to authenticate your email with SPF. Must pass SPF for sending domain.
    • Configure “custom MAIL FROM“, which is how senders can ensure that the SPF-authenticated domain is aligned with the From header domain’s DMARC policy.
  • Enable DKIM signing: DomainKeys Identified Mail (DKIM) is an email security standard. It is designed to ensure that an email that claims to have come from a specific domain, was indeed authorized by the owner of that domain. It uses public-key cryptography to sign an email with a private key. Recipient servers use a public key, published to a domain’s DNS to verify that parts of the email have not been modified during the transit. Follow these set up instructions to authenticate email with DKIM in SES. Must pass to validate email integrity and authenticity.
    • Verify your domain with Easy DKIM. If currently using email identities, you have to move to domain
    • If you utilize email identities only, you will default all authentication to amazonses.com. That will not align with your friendly from address which will not satisfy the bulk sender requirements. This means that when you send email to mailbox providers, your messages will be rejected because you do not have proper authentication on your emails. To satisfy the bulk sender requirements, you must use domain verified identities which ensure that you have ownership of or permission to use the sending domain. That will allow SES to sign the outgoing emails with a DKIM signature that aligns with the friendly from domain.
  • Set up DMARC with an appropriate policy: Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication protocol that uses SPF and DKIM to detect email spoofing and phishing. To comply with DMARC, messages must be authenticated through either SPF or DKIM. Ideally, when both are used with DMARC, you’ll be ensuring the highest level of protection possible for your email sending.
Name Type Value
_dmarc.example.com TXT “v=DMARC1;p=none;rua=mailto:[email protected]“

In the preceding records:

    • example.com is your domain
    • Value of the TXT record contains the DMARC policy that applies to your domain.
    • In this example, the policy tells email providers to do the following:
      • At least p=none should be implemented.

2. Optimize Email Content

  • Clearly identify yourself as the sender: Use a recognizable “From” name and email address that accurately represents your brand or organization. For example, use “[email protected]” instead of a generic or misleading address.
  • Implement user friendly unsubscribe mechanisms: Include a visible, easy-to-use unsubscribe link in every email, typically in the header. Ensure the unsubscribe process is simple and honors requests promptly, ideally within 24-48 hours. Visit this guide on how Amazon SES helps you do that.
  • Subject line aligns with content: Avoid deceptive subject lines that don’t match the email content.
  • Clearly identify commercial content: If your email is promotional, make it obvious. Use clear language in the subject line and body that indicates the nature of the email, such as “Special Offer” or “Newsletter.”
  • Include a valid physical address: Add your company’s physical mailing address in the email footer. This is not only a legal requirement in many jurisdictions but builds trust with recipients.
  • Verify URLS in the emails: Verify that links in the emails you send work and are not misleading to the reader/subscriber. Be transparent with URLs/links in the email content.

3. Monitor and Maintain

  • Monitor bounces: A bounce typically indicates why a message was not delivered. The SMTP response in the bounce message will have details on why the message was bounced. For example: if it is missing authentication records (fix: include authentication records for the domain – quick fix) versus an IP or domain reputation bounce reason (this maybe a longer term fix).
    • Track both hard bounces (permanent delivery failures) and soft bounces (temporary issues). High bounce rates can indicate list quality problems or delivery issues. Visit this blog to set up notifications for bounces & complaints. Virtual Deliverability Manager (VDM) is an Amazon SES feature that helps you enhance email deliverability. It helps increasing inbox deliverability and email conversions, by providing insights into your sending and delivery data. VDM advices on how to fix the issues that are negatively affecting your delivery success rate and reputation.
  • Track complaint rates: Regularly monitor the number of spam complaints your emails receive with a goal of keeping the complaint rate under 0.2%. Not all mailbox providers have complaint feedback loop data, so use aggregate data from the mailbox providers that do, such as Hotmail and Yahoo. Email providers that don’t provide complaint feedback loops, such as Gmail may have alternative dashboards or tools available like Google Postmaster tools.
  • Perform regular authentication checks: Periodically verify that your SPF, DKIM, and DMARC records are correctly set up and functioning. Alternative to manual DNS checks, Amazon SES has a feature in Virtual Deliverability Manager that performs authentication checks for your sending identities.
  • Maintain list hygiene: Regularly clean your email list by removing inactive subscribers, correcting typos in email addresses, and honoring unsubscribe requests. This helps improve deliverability and engagement rates.

How Amazon SES Helps

Amazon SES provides a robust set of features to help you meet these new requirements and optimize your email sending practices:

Authentication Support

  • Easy DKIM configuration
  • SPF record management
  • DMARC implementation guidance

Comprehensive Monitoring

  • Virtual Deliverability Manager
  • Complaint tracking
  • Bounce rate monitoring
  • Event publishing to Amazon CloudWatch, SNS , Kinesis Firehose and Event Bridge
  • Detailed sending statistics

Compliance Tools

  • List management capabilities (included with SES)
  • Suppression list handling (included with SES)
  • Feedback loop processing (included with SES)
  • Authentication status tracking: This is done through Amazon SES feature Virtual Deliverability Manager (VDM).

Implementation Strategy

To successfully implement these changes, consider the following strategy:

  1. Assessment: Audit your current email practices, review authentication status, and evaluate compliance gaps.
  2. Technical Implementation: Configure authentication protocols, update DNS records, and implement required unsubscribe mechanisms.
  3. Monitoring and Optimization: Track deliverability metrics, monitor complaint rates, and adjust sending practices as needed.

Measuring Success

To ensure ongoing compliance and optimize your email practices, track these key metrics:

  1. Delivery rates
  2. Complaint rates
  3. Authentication pass rates
  4. Engagement metrics (open rates, click-through rates)

Conclusion

The new bulk sender requirements from Microsoft and Yahoo represent an important step towards a more secure and reliable email ecosystem. By leveraging Amazon SES’s powerful features and following industry best practices, you can maintain compliance, improve deliverability, and enhance the overall effectiveness of your email communications.

Amazon SES is committed to helping you navigate these changes and optimize your email sending practices. For the most up-to-date guidance and support, please consult SES’s documentation or contact Amazon SES support.

Additional Resources

The email landscape is constantly evolving. Stay informed and adaptable to ensure your email practices remain effective and compliant.

About the authors:

SMS Onboarding for SaaS, ISV, and Multi-Tenant Applications with AWS End User Messaging

Post Syndicated from Tyler Holmes original https://aws.amazon.com/blogs/messaging-and-targeting/sms-onboarding-for-saas-isv-and-multi-tenant-applications-with-aws-end-user-messaging/

Introduction

SMS messaging continues to be one of the most reliable and effective communication channels. However, for Software as a Service (SaaS) companies, Independent Software Vendors (ISVs), and multi-tenant solution providers looking to incorporate SMS capabilities into their offerings, the journey can be complex and filled with challenges.

This guide is specifically designed for technology providers—whether you’re a SaaS company, an ISV, or any platform that enables your customers to send SMS messages to their end users. Throughout this article, the following terminology will be used:

  • Provider: An organization offering SMS capabilities as part of your product or service
  • Customer: The entities using Provider technology to send SMS messages
  • End User: The recipients who opt in to receive SMS messages from Customers

The landscape of SMS implementation can be complicated, with varying country-specific regulations, lengthy registration processes that can take weeks or even months, different originator types (Long Code, Short Code, Sender ID, etc.) with unique capabilities, and the diverse needs of Customers and End Users. These challenges are amplified when you’re a Provider offering SMS services to your own Customers, who in turn serve their End Users.

By the end of this guide, you’ll understand:

  • How opt-in influences architecture
  • Options for how to structure your SMS offering to Customers
  • Strategies for reducing friction in the SMS implementation process

Let’s dive in.

The Registration Dilemma: Who Owns the Relationship?

One of the most critical decisions for your SMS Originator registration is determining whose information is used to apply. The biggest mistake AWS sees Providers make is not knowing how their relationship with their Customers and their Customers’ End Users affects their architecture and how they complete any registrations that are necessary.

Mobile carriers want to know who will be sending SMS to their customers, how that entity will opt them in, and what content they will be sending. When registering for originators, especially in the United States, you will need to succinctly explain how End Users will opt in and how that data will not be shared with any third parties. Your architecture must ensure:

AWS consistently sees Providers register themselves when obtaining an Originator when they do not have a relationship with their Customers’ End Users. The decision of whose information belongs in the registration hinges primarily on a fundamental question: Who does the End User believe they’re entering into a relationship with when they provide their phone number?

The most common scenarios are below:

Scenario 1: End Users interact with the Customer’s brand only

In most cases, End Users are completely unaware of your existence as the Provider. They believe they’re opting in to receive messages from your Customer directly. In this scenario:

  • Registration should be completed using the Customer’s information. There are many ways you can facilitate this process and some ways to reduce this common friction point will be discussed later in this post.
  • Messages should appear to come from the Customer, not the Provider, your service name should not appear in messaging

Scenario 2: End Users explicitly opt in through the Provider application

In some cases, End Users clearly understand they’re opting in to receive messages via your technology platform, on behalf of your Customer. The opt-in data will not be shared with your Customers and your brand, as the Provider, will be the named entity in all SMS sent.

There are a number of ways that this can happen:

  • End Users could opt in using a widget you build that your Customers install on their site or in their app
  • A paper form or verbal script that you supply that clearly identifies you, the Provider

AWS commonly sees this occurring with Providers that supply:

  • Third-party payment processing
  • Shipping and logistics support
  • Customer service platforms
  • One-Time Password (OTP) capabilities

In this scenario your company name would typically appear in the messaging and registration would use your company information.

NOTE: There are edge cases to these two scenarios but the implementation can be complicated, so if you are a Provider and you don’t think that you fit into these two scenarios above make sure to reach out to your Account Manager, open a case, or speak to a specialist before starting to implement anything.

Architectural Models for SMS Implementation

Let’s explore various architectural models for structuring your SMS offering based on your business needs and Customer relationships. Each model has distinct characteristics in the following areas:

1. “Bring Your Own AWS Account” Model

Who does the registration and configuration?

  • The Customer connects their own AWS account, so the registration and any configuration happens in the Customer account.
  • Usually in this scenario the information that is input into the registration is the Customer’s since it’s their account

Customer responsibilities:

  • Customer handles all registration and configuration requirements themselves
  • Customer integrates their account with the Provider service
  • Customer manages sending, opt-out lists, etc.
  • Pays the AWS bill

Provider responsibilities:

  • The Provider offers a user-friendly interface that calls the AWS End User Messaging Service APIs using the Customer’s credentials.
  • The depth of services offered by the Provider can vary

Best for: Technical Customers who want full control and already use AWS; Providers who want to avoid registration and configuration complexities.

2. Provider Account – Manual Registration and Configuration

Who does the registration and configuration?

  • The Provider owns the account and is not providing the Customer with a way to submit their own information so the Provider must enter the information
  • The Customer’s information is captured manually
  • The Provider handles the complexity of registration and configuration through the console

Customer responsibilities:

  • Provide necessary information to the Provider for registration purposes

Provider responsibilities:

  • Captures the registration information manually from Customers.
  • Manages the complexity on behalf of your Customers.

This can be implemented either with separate AWS accounts for each Customer or a multi-tenant architecture in a single account.

Best for: Providers with a small number of high-value Customers who need hand-holding through the SMS implementation process.

3. Semi-Automated Solution – Customer Sending

Who does the registration and configuration?

  • The Provider builds a way for the Customer to submit their registration information, which the Provider then programmatically submits to carriers/regulators.

Customer responsibilities:

  • Your platform manages the technical configuration and provides sending capabilities, but the Customer is responsible for maintaining compliance.

Provider responsibilities:

  • You provide a streamlined way for Customers to submit registration information (webhooks, forms, APIs).
  • You programmatically submit the registration data to carriers/regulators.
  • You manage the technical configuration and provide sending capabilities.

Best for: Providers with moderate technical sophistication who want to reduce friction while maintaining separation of regulatory responsibilities.

4. Fully Automated Solution – Provider Sending

Who does the registration and configuration?

  • The Customer’s information is used in the registration, which you handle programmatically.

Customer responsibilities:

  • You handle all technical aspects of registration, but the Customer is still responsible for maintaining messaging compliance.

Provider responsibilities:

  • You provide hosted, customizable Terms & Conditions and Privacy Policies for each Customer that are compliant out of the box.
  • You offer compliant opt-in pathways (web forms, verbal scripts, etc.).
  • You handle all technical aspects of registration.

Best for: Large-scale Providers serving many Customers with varying levels of technical sophistication.

5. Template-Restricted Fully Automated Messaging

Who does the registration and configuration?

  • The Customer’s information is used in the registration, which you handle programmatically.

Customer responsibilities:

  • You manage all regulatory compliance centrally, and the Customer can only personalize specific fields in pre-approved message templates.

Provider responsibilities:

  • You provide a suite of pre-approved message templates.
  • You manage all regulatory compliance centrally.
  • You simplify the registration process since the content is tightly controlled.

Best for: Use cases with predictable messaging needs like appointment reminders, shipping notifications, or one-time passwords.

6. Fully Managed Programs

Who does the registration and configuration?

  • The Customer authorizes you to send messages on their behalf, so you own the relationship with the end-user and the registration.

Customer responsibilities:

  • Only required to give you any pertinent information necessary for you to send messages to the End-Users. This could be things like tracking numbers or other information that the particular use case requires and is part of the personalization that is allowed.

Provider responsibilities:

  • You manage all aspects of the end-user relationship.
  • You control the entire messaging experience, including opt-in collection and the end-user relationship.

Example: A shipping notification service might send messages like: “ShipTrack: Your order from ACME Corp will arrive tomorrow. Track at [link]”

Best for: Specialized use cases where your platform adds significant value as an identified intermediary.

Shaping Your SMS Offering: Strategic Considerations

Pricing Strategies

When incorporating SMS into your product, one of the first considerations is how to structure your pricing. Unlike many digital services with predictable costs, SMS pricing varies significantly based on destination country, originator type, and volume.

AWS End User Messaging Service bills based on volume sent per country, with each country having its own price point. This pricing is determined by the recipient’s handset country code, not their physical location. This means that even if you primarily serve U.S. based Customers, you may need to account for international rates when recipients have non-U.S. phone numbers.

There are also one-time and ongoing fees to be accounted for. Registrations often have one-time processing fees and Originators can have leasing costs that range from free to more than $1,000 a month for short codes in some countries. Make sure that you think through how those costs will or will not be passed to your Customers.

As you design your pricing model, consider these common volume based approaches:

  • SMS Credits: Create a standardized credit system where Customers purchase credits regardless of destination country. You would internally manage the conversion between credits and actual costs.
  • Dollar-Based Allocation: Provide Customers with a budget that gets depleted based on actual costs per message sent.
  • Tiered Country Pricing: Group countries into tiers (e.g., Tier 1 for North America, Tier 2 for Western Europe) with different pricing for each tier.
  • Bundled Messaging: Include a certain number of messages in your base subscription with overage fees for additional messages.

Each approach has trade-offs in terms of simplicity, transparency, and risk management. Your decision should align with your overall business model and Customer expectations.

Geographic Considerations

Different countries have distinct regulatory requirements for SMS messaging, including:

  • Originator Support: Not all countries support all originator types, view the details here
  • Originator Selection: In cases where multiple types of originators are supported, how do you support your Customer in selecting the right originator for the right use case?
  • Read through this tutorial to help decide what originator(s) are right for your use case(s)
  • Registration: An increasing numbers of countries require you to register before being allowed to send
  • Quiet hours: Many countries restrict when promotional messages can be sent
  • Content restrictions: Certain types of content (gambling, alcohol, adult content, etc.) may be prohibited or heavily restricted. A more comprehensive list can be found here
  • Template requirements: Some jurisdictions require pre-approval of message templates
  • Sender ID regulations: Rules regarding who can use alphanumeric sender IDs vary widely

As a Provider, you need to decide which countries you’ll support and how you’ll ensure compliance across markets. This decision affects not just your pricing but your entire product architecture, especially if you serve global Customers.

Strategies to Reduce Implementation Friction

Implementing SMS can be complex for your Customers. Here are some strategies that can simplify and/or streamline the process. Some of these can be mixed and matched and could also be used as a value-add or even as a paid offering to your Customers:

Provider-Hosted Privacy Policy and/or Terms & Conditions

Create customizable, compliant templates for Privacy Policies and Terms & Conditions that your Customers can use. This ensures proper disclosure of SMS practices without requiring Customers to update their own legal documents.

Registration Webforms and Workflows

Develop user-friendly webforms that collect all required registration information in a guided process. These can significantly simplify complex registrations like 10DLC brand and campaign registration.

Below, Figures 1-3, you will find several examples of compliant forms that could be customized for your use:

Fig. 1

Fig. 2

Fig. 3

Pre-Approved Opt-In Widgets

Create embeddable widgets, such as Figures 1-3 above, that your Customers can add to their websites or apps that implement compliant opt-in processes. These can include all required disclosures and confirmations while being easy to integrate.

Template Libraries

Provide a library of pre-approved message templates for common use cases. This reduces compliance risks and simplifies the sending process for your Customers.

Testing Environments

Create sandbox environments where Customers can test their SMS implementation before going live. This helps catch issues with formatting, opt-in processes, or content compliance.

Documentation and Training

Develop clear documentation and training resources specific to each originator type and use case. This empowers your Customers while reducing support burden.

Conclusion

Incorporating SMS capabilities into your platform can enhance Customer engagement, but the journey can be complex. This guide has explored key considerations to help you navigate it successfully.

This post examined various architectural models, each with tradeoffs in Customer responsibilities and Provider responsibilities. This post reviewed strategic factors like pricing, geographic regulations, and originator types that must be carefully considered.
Finally, practical strategies to reduce implementation friction for Customers such as hosted compliance documents, streamlined registration workflows, and pre-approved templates, you can use to simplify the integration process were discussed .

The critical first step though, is understanding the relationship between you as the Provider, your Customers, and their End Users. This shapes whose information is used for originator registration, which in turn defines the SMS experience.

Ultimately, a successful SMS solution requires balancing technical, regulatory, and Customer-centric factors. Leveraging this guidance will equip you to design and deploy an offering that delights your Customers and their End Users.

Additional resources:

Defending Against SMS Pumping: New AWS Features to Help Combat Artificially Inflated Traffic

Post Syndicated from Tyler Holmes original https://aws.amazon.com/blogs/messaging-and-targeting/defending-against-sms-pumping-new-aws-features-to-help-combat-artificially-inflated-traffic/

As businesses increasingly rely on SMS messaging to engage customers, AWS End User Messaging is enhancing its SMS Protect feature to now include automated message filtering based on the risk of Artificially Inflated Traffic (AIT) from each message request. This new capability helps protect against AIT, also known as SMS pumping. AIT occurs when malicious actors use bots and other measures to generate fake SMS traffic, targeting businesses’ customer communication workflows like one-time password triggers, app downloads, and promotional signups. In a recent report co-authored by Enea it was shown that AIT accounted for 19.8 billion to 35.7 billion fraudulent SMS messages in 2023, costing over $1 billion. All workflows with user generated messages are susceptible to AIT but insecure public webforms are the most commonly used as a vector to exploit and generate SMS messages. The goal is to artificially inflate the number of SMS messages a business sends, resulting in increased costs and a negative impact on the sender’s reputation.

We launched AWS End User Messaging Protect to help our customers combat this growing threat. Initially launched with Country Level Blocking, we’ve now launched two new features, called Monitor and Filter, within AWS End User Messaging’s Protect capabilities. Updating your current security posture for SMS with Monitor and Filter, along with adhering to some other best practice security measures we will cover later, will make it harder for bad actors to target and inflate your SMS costs with bots or other measures.

What is SMS Protect Filter and Monitor?

Filter and Monitor are the next layers of defense in our Protect Feature Set. These features are designed to provide enhanced protection against AIT for countries in which you need to send messages by analyzing and proactively blocking messages that are suspected to be fraudulent. The Filter setting blocks suspected AIT messages. The Monitor mode allows you to evaluate how Filter would affect your sending, without blocking. Monitor could also be used for the events it emits, which could be leveraged in your own custom AIT solutions, but again, does not automatically block messages.

Filter Mode: Automated Blocking of Suspected Artificial Traffic

The Filter mode in Protect takes your AIT mitigation efforts to the next level by automatically blocking messages that exhibit patterns of artificial inflation. When you set your configuration to “Filter” the model will automatically filter any messages being sent that match patterns indicative of AIT.

Filter mode provides automated defense against AIT by analyzing and proactively blocking AIT messages before they leave AWS, reducing your exposure to the financial and reputational impacts of SMS pumping. Turning on Filter at the Account level is the quickest way to protecting yourself. The tutorial below will walk you through configuration.

Importantly, when a message is blocked in Filter mode, you do not incur the normal per-message fees, instead you only pay for the lesser costs associated with the Protect Filter capabilities, providing a more cost effective approach to message security.

Monitor Mode: Gain Visibility and Insights into Potentially Suspicious Traffic

The Monitor mode in Protect works identical to filter, it uses the same AIT prediction models behind the scenes, but rather than blocking suspected AIT it simply emits recommendations for blocking based on the patterns of data. The recommendations are delivered in a new field attached to the Delivery Receipts (DLRs) that are already streamed via Event Destinations. The recommendations are also logged in summary to CloudWatch and the End User Messaging Console Dashboards. This provides you with valuable data and insights to help inform your AIT mitigation strategy.

Messages sent while in monitor mode will not be blocked and will be charged the country per message cost as well as the Protect Monitor per message cost.

If you want to see what our AIT prediction models recommend without AWS actually blocking messages, you can start in Monitor Mode and change to Filter when you are more comfortable. This allows you to understand how your traffic is analyzed by our AIT prediction models without immediately blocking messages, offering a cautious and informed approach to how Filter will affect your Account.

The Monitor mode reports include detailed analytics on blocked message volumes, geographic distribution, carrier patterns, and more. By analyzing this data, you can identify specific countries, number ranges, or sending behaviors that may be indicative of artificially inflated traffic. This helps you make informed decisions about where to apply more stringent controls.

Importantly, during the monitoring phase, Protect also provides recommendations on whether a particular message would have been blocked and whether certain numbers should be blocked in the future. This gives you the ability to fine-tune your configurations and better understand your traffic before taking enforcement actions.

How do you get started with Protect Monitor and Filter?

Every customer’s needs are unique, but for most customers, we suggest the following steps:

  1. Block all countries to which you do not send messages
    1. Your first line of defense should be to block all traffic to countries where you don’t conduct business or need to send messages. Preventing unwanted messages from being sent is the simplest way to help prevent SMS pumping in the first place. You can use Protect Country Blocking rules to do this and they can can be applied to SMS, MMS, and voice messages sent from your AWS account. For a tutorial on how to do this you can read this earlier blog on Protect.
  2. Create an account level “Filter” configuration
    1. When considering the risk of AIT in a specific country we recommend aligning risk level with the SMS per message cost. The higher the cost the higher the risk.
  3. Make sure that your forms and other vulnerable public facing messaging workflows are protected with best practice security measures that we will review further on in this post.

How to create a protect configuration

You can use a Protect configuration at different levels of granularity:

  1. As the default for your entire AWS account(Good for customers with a single use case)
  2. Associated with a specific Configuration Set
  3. Directly specified when calling the SendMediaMessage, SendTextMessage, or SendVoiceMessage APIs
    NOTE: You can only change your MMS country rules list through the AWS End User Messaging SMS and voice v2 API or AWS CLI. The Voice rules can be changed in the console but only after creating an SMS Protect Configuration. Once you have created your first Configuration you can edit it and select the “Voice Rules” tab.

The main benefit of Protect configurations is the ability to control where you send messages and avoid unexpected costs or compliance issues. By creating multiple configurations you can apply specific rules that control how messages are processed and delivered based on your unique business needs. Let’s walk through how to set them up.

Creating a Protect Configuration

  1. To create a Protect Configuration, log into the AWS Management Console and navigate to End User Messaging.
  2. From there, go to the “SMS” section and select “Protect configurations”.
  3. Click the “Create protect configuration” button and give your new configuration a name.
    1. Define the specific allow and block rules for SMS, MMS, and voice messages.
      1. Checking a box next to a country blocks that country and checking the box for a region will block all countries associated with that region.

Once you’ve configured the country rules, you can choose how to associate this Protect configuration:

  1. Set it as the default for your entire AWS account
    1. For many customers this should be the default. Having an account level configuration as a fallback helps protect you incase you forget to specify a protect configuration in your request.
    2. Note: To use a protect configuration with other AWS services to send messages, like Amazon SNS, Amazon Connect, or Amazon Pinpoint, you need to set your protect configuration as the account default
  2. Associate it with one or more Configuration Sets
    1. This setting will be applied anytime you send SMS with the config set associated with this Protect Configuration
  3. Leave it unassociated to use it explicitly in API calls
    1. This setting allows you to apply it whenever you want. This will override any previous associations when you reference the “ProtectConfigurationId” in your SendMediaMessage, SendTextMessage, or SendVoiceMessage calls

You can also add optional tags to help organize your resources.

  1. Click “Create protect configuration”
    1. NOTE: You can only change your MMS country rules list through the AWS End User Messaging SMS and voice v2 API or AWS CLI. The Voice rules can be changed in the console but only after creating an SMS Protect Configuration. Once you have created your first Configuration you can edit it and select the “Voice Rules” tab.
  2. How to add Filter or Monitor to the Protect Configuration you just created
    1. Click into the Protect Configuration you just created
      1. Note the “SMS Rules” tab and the “Voice Rules” tab can have different rule settings. Make sure you are editing the right channel
  3. You will once again select the country or region you wish to set to Filter(recommended) or Monitor

    1. Confirm the changes and you will see your changes in the next screen

Getting more granular with Protect Configurations

In most cases you should be using “Filter” account wide for the countries you are concerned about AIT in, but If you have different public and/or private messaging workflows you may benefit from a more precise, or granular, approach to your messaging and security practices. If you want more control, the first step is to identify your traffic that is a high risk for SMS pumping. Any public-facing forms or workflows that trigger SMS being sent are prime targets for attackers to try and pump SMS are at high risk, such as:

  • One-time passwords or 2FA flows
  • Password/User resets
  • New user registrations
  • Other

Creating a separate Protect Configuration for each of these different workflows will help the models in Protect more effectively identify anomalies and tailor its detection models to your specific messaging patterns. Service-initiated messages, such as appointment reminders or marketing campaigns that are not user-generated are at much less risk of SMS pumping attacks so you may decide not to include them in the same Protect config as a public facing workflow to reduce overall costs.

You can follow the directions above for creating a Protect Configuration for each of the workflows you identify. You might configure something like the below, where “OTP New Sign Up” and “Password Reset” have Filter enabled for the countries of concern and the “Marketing Newsletter” Configuration would not have either configured since that use case does not involve a publicly available form that triggers an SMS being sent. Creating a Protect Configuration for different use cases gives you more granular control over your messaging, your messaging budget, and ensuring the integrity of your communications

Updating an Existing Protect Configuration

After creating a Protect configuration, you may need to modify the country rules, change the association or as we saw above, add Filter or Monitor to certain countries. To do this, simply navigate back to the “Protect configurations” section and select the one you want to update.

From here you can edit the allow/block country lists, change the association, or even delete the configuration if needed. Just be careful with the account default – you’ll want to be sure you have another default in place before removing the existing one.

Using Protect Configurations

Once you have your Protect configurations set up, you can start putting them to use. If you’ve associated one with a Configuration Set, any messages sent using that Configuration Set will automatically have the Protect rules applied.

Alternatively, you can specify the ProtectConfigurationId parameter when calling the SendMediaMessage, SendTextMessage, or SendVoiceMessage APIs. This allows you to override the account default or Configuration Set association on a per-message basis.

Reporting on Protect Configurations

There are two places within the console that you can see metrics for your Protect Configurations. The Monitoring tab on a protect configuration provides an overview of message delivery metrics for the protect configuration. To view all metrics for your account in the AWS End User Messaging SMS console choose Dashboard in the left hand navigation. You can also use CloudWatch to view and create alarms. For more information on CloudWatch metrics, see Dashboard metrics, and Create CloudWatch Alarms.

Monitoring tab on a specific Protect Configuration

End User Messaging provides multiple charts that helps you understand how your country rule configurations (Allow, Block, Monitor, or Filter), along with phone number rule overrides are controlling SMS sending overall, and to specific countries.

The included charts are:

  • Number and Percentage of Blocked Messages: Shows the count and percentage of SMS and MMS messages that were blocked during the selected time period. This includes messages blocked by country rules set to ‘block’ or ‘filter’ mode, as well as messages blocked by phone number override rules.
  • Number of Blocked Messages by Country: Shows the count of SMS and MMS messages that were blocked during the selected time period, broken down by destination country.
  • Number and Percentage of Messages Recommended to Block: Shows the count and percentage of SMS and MMS messages that were identified as risky by the AIT risk prediction model. This includes messages in both ‘monitor’ and ‘filter’ modes. In monitor mode, these messages are delivered but flagged; in filter mode, these messages are blocked.
  • Number of Messages Recommended to Block by Country: Shows the count of SMS and MMS messages identified as risky by the AIT prediction model, broken down by destination country.

Implementing a Layered Approach to SMS Security

While Filter and Monitor are new tools in the fight against AIT, they should be implemented as part of a broader, layered security strategy for your SMS messaging infrastructure. Here are some best practices to consider:

Identify and compartmentalize Your Traffic

You are able to create multiple Protect Configurations based on different use cases, such as one-time passwords, marketing campaigns, and appointment reminders. This granular approach allows Protect’s prediction models to better understand your expected traffic patterns and identify anomalies more accurately. Once you have identified your traffic types you can assign different configurations to them. You may set a marketing configuration to not be filtered or monitored because it’s not user generated but an OTP type with a publicly available form you may want to set to Filter. In this way you save money by protecting only the messages that are more likely to be susceptible to AIT. Each of these may block the same countries but operate differently with regards to identifying and blocking potentially fraudulent traffic.

Leverage Geographic Controls:

Always start by blocking countries where you have no business presence, then allow-list the regions where you actively engage customers and have not seen AIT issues. For countries where you suspect potential abuse, utilize the Monitor mode to gather data before deciding on a blocking strategy.

Allow-list Legitimate phone numbers in countries you are blocking

To avoid impacting your critical messaging workflows, implement phone number rule overrides for specific countries where you are blocking traffic. As an example, if you have engineers in Columbia that you want to be able to send SMS to but you don’t have any legitimate reason other than that to send to Columbian handsets you can block Columbia but allow-list those engineer’s phone numbers. You can also provide your front end support teams the functionality to add numbers to allow-lists in case a number is mistakenly blocked by Filter recommendations

  1. To create a phone number override rule using the console, follow these steps:
  2. Open the AWS End User Messaging SMS console at https://console.aws.amazon.com/sms-voice/.
  3. In the navigation pane, under Protect, choose the Protect configuration you want to add allow-list numbers in
  4. Choose the Rule overrides tab and in the Rules override section choose Add override.
    1. In the Rule override details section, enter the following:
      1. For Destination phone number enter the phone number to create the rule for. The phone number must start with a ‘+’ and can’t contain any spaces, hyphens, or parentheses. For example, +1 (206) 555-0142 is not in the correct format, but +12065550142 is.
      2. For Override type choose either Always allow or Always block.
      3. For Expiration date – optional choose a date for the rule expire or leave it blank for the rule to never expire.
  5. Choose Add rule override.

Integrate with Complementary Security Services

Enhance your SMS security posture by integrating Protect with other AWS services, such as AWS Web Application Firewall (WAF) for web-based attack protection and Amazon Cognito for robust user authentication. See this post on Cognito Security for more detailed information on how to add self-service sign-up, sign-in, and control access features to your web and mobile applications while benefitting from SMS authentication and fraud protection with End User Messaging Protect Block, Monitor, and Filter.

WAF has out of the box support for complementary security protections such as CAPTCHA, IP blocking, and JA3 fingerprint matching which are all best practice features to help protect your public forms that may be at risk for SMS pumping.

Review and Iterate

Regularly review your Protect configurations, analyze false positive rates, and update your allow-lists and rules as your messaging patterns evolve. If you are satisfied with your blocking, leave it alone. If you want to get more precise and remove false positives, look for which protect configurations have identified suspected AIT, and try to make them more granular. For example, if you have a sign-up form that is currently being triggered from two separate web pages, you could have a config set for each of those pages and trigger a different config set with Filter mode activated for each. Maintaining an agile, data-driven approach is key to ensuring optimal balance between security and service availability for your legitimate customers.

Conclusion

Take a proactive, multilayered approach to combating the growing threat of SMS fraud by leveraging the new Filter and Monitor capabilities within AWS End User Messaging Protect. These features empower you to gain visibility into potentially malicious traffic, automate the blocking of suspected AIT, and protect your messaging infrastructure while preserving the seamless experience your customers expect.

To get started with Protect and explore these new features, visit the AWS End User Messaging documentation or reach out to your AWS account team. We’re here to help you strengthen the security and integrity of your SMS communications.

Automating Sender ID Configuration for SMS with AWS End User Messaging APIs

Post Syndicated from Tyler Holmes original https://aws.amazon.com/blogs/messaging-and-targeting/automating-sender-id-configuration-for-sms-with-aws-end-user-messaging-apis/

Global SMS messaging with consistent Sender ID branding requires configuring the same Sender ID across multiple countries, which is a time-consuming process for businesses operating internationally. In this post, we’ll show you how to automate the configuration of Sender IDs for countries that do not have registration requirements using the AWS End User Messaging v2 API.

The Challenge of Multi-Country Sender ID Configuration

When sending SMS messages internationally, if you are using Sender ID, you want your brand to be consistently recognized. This means configuring the same Sender ID in each country you send to. However there are several challenges related to this:

  • Each country must be done manually, one at a time, if using the AWS Console
  • If you have multiple environments for testing the process must be repeated for each Account/Region
  • If you are moving account/regions you have to reconfigure each country in the new Account/Region
  • Manual configuration can be error prone
  • Errors can be detrimental to a brand

The Solution: AWS Lambda Automation

This solution can be applied to any country that supports Sender ID configurations and does not require registration. You can view a comprehensive list of these eligible countries here.

Below is an AWS Lambda function that streamlines this process by handling bulk configuration requests. The function solves the challenges in handling multiple country configurations in a single automated workflow. Here’s the complete code:

import boto3
import uuid
import json
import time
from typing import Dict, Any, List

def validate_input(sender_id: str, countries: List[str]) -> bool:
    if not 1 <= len(sender_id) <= 11:
        raise ValueError("Sender ID must be between 1 and 11 characters")
    
    if not sender_id.replace('_', '').replace('-', '').isalnum():
        raise ValueError("Sender ID can only contain alphanumeric characters, underscore, and hyphen")
    
    if not countries:
        raise ValueError("At least one country code must be provided")
    
    return True

def request_sender_id(client, sender_id: str, countries: List[str], message_types: List[str] = None, tags: List[Dict] = None) -> List[Dict]:
    if message_types is None:
        message_types = ["TRANSACTIONAL", "PROMOTIONAL"]
    
    results = []
    
    for i, country in enumerate(countries):
        if i > 0:
            time.sleep(1)  # Rate limiting: 1 request per second
            
        try:
            print(f"Processing country: {country} ({i+1}/{len(countries)})")
            request_params = {
                'ClientToken': str(uuid.uuid4()),
                'SenderId': sender_id,
                'IsoCountryCode': country.upper(),
                'MessageTypes': message_types,
                'DeletionProtectionEnabled':True
            }
            
            if tags:
                request_params['Tags'] = tags
                
            response = client.request_sender_id(**request_params)
            
            results.append({
                'Country': country,
                'Status': 'Success',
                'SenderIdArn': response.get('SenderIdArn'),
                'MonthlyLeasingPrice': response.get('MonthlyLeasingPrice')
            })
            
        except Exception as e:
            results.append({
                'Country': country,
                'Status': 'Failed',
                'Error': str(e)
            })
            
        print(f"Completed {country}: {'Success' if results[-1]['Status'] == 'Success' else 'Failed'}")
    
    return results

def lambda_handler(event: Dict[str, Any], context: Any) -> Dict[str, Any]:
    try:
        # Extract parameters from event
        sender_id = event['sender_id']
        countries = [c.strip().upper() for c in event['countries'] if c.strip()]
        tags = event.get('tags')  # Optional
        message_types = event.get('message_types', ["TRANSACTIONAL", "PROMOTIONAL"])  # Optional
        
        # Validate input
        validate_input(sender_id, countries)
        
        # Initialize the AWS SMS Voice v2 client
        client = boto3.client('pinpoint-sms-voice-v2')
        
        # Process the request
        results = request_sender_id(
            client=client,
            sender_id=sender_id,
            countries=countries,
            message_types=message_types,
            tags=tags
        )
        
        # Calculate summary
        successful = sum(1 for r in results if r['Status'] == 'Success')
        
        return {
            'statusCode': 200,
            'body': {
                'results': results,
                'summary': {
                    'total': len(countries),
                    'successful': successful,
                    'failed': len(countries) - successful
                }
            }
        }
        
    except Exception as e:
        return {
            'statusCode': 500,
            'body': {
                'error': str(e)
            }
        }

How the Lambda Function Works to Configure Sender IDs

The Lambda function automates the Sender ID configuration process through these key steps:

  • Input Validation: Ensures the Sender ID meets format requirements (1-11 alphanumeric characters, with optional underscores or hyphens).
  • Bulk Registration: Processes each country sequentially with built-in rate limiting (1 request per second) to prevent API throttling.
  • Logging: Returns the full ARN of each successfully configured Sender ID
  • Flexible Configuration Settings:
    • Supports multiple message types (transactional, promotional, or both)
    • Enables resource tagging for organizational and cost tracking
    • Provides deletion protection to prevent accidental removal
  • Cost Transparency: Displays monthly leasing price for each successful country configuration
  • Error Handling: Individual country failures don’t halt the entire process, allowing partial success if a single country were to fail for some reason.

Using the Lambda Function

To use this function, create a Lambda with the code above and configure an event. The tags are optional and we have provided an example below:
NOTE: Depending on the number of countries you are attempting to register at a time, you may need to increase the 3 second default Lambda timeout. For reference, in our testing, we were able to do all Sender IDs(160) in less than 3 minutes.

Test Event Example

{
    "sender_id": "YourBrand",
    "countries": ["GB", "DE", "FR"],
    "tags": [
        {
            "Key": "Environment",
            "Value": "Production"
        },
        {
            "Key": "Department",
            "Value": "Marketing"
        }
    ]
}

IAM Permissions

Your Lambda will need these minimum AWS Identity and Access Management (IAM) permissions, scale back the resource if necessary:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sms-voice:RequestSenderId",
                "sms-voice:TagResource"
            ],
            "Resource": "arn:aws:sms-voice:*:**ACCOUNT#**:sender-id/*"
        }
    ]
}

The Trust Policy required for Lambda to assume the role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "lambda.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Results Example

The Lambda will return results for each country, including configuration status and monthly costs, if any. Below you will see an example of 3 countries being configured:


{
  "statusCode": 200,
  "body": {
    "results": [
      {
        "Country": "GB",
        "Status": "Success",
        "SenderIdArn": "arn:aws:sms-voice:us-west-2:**ACCOUNT#**:sender-id/LAMBDATEST2/GB",
        "MonthlyLeasingPrice": "0.00"
      },
      {
        "Country": "DE",
        "Status": "Success",
        "SenderIdArn": "arn:aws:sms-voice:us-west-2:**ACCOUNT#**:sender-id/LAMBDATEST2/DE",
        "MonthlyLeasingPrice": "0.00"
      },
      {
        "Country": "FR",
        "Status": "Success",
        "SenderIdArn": "arn:aws:sms-voice:us-west-2:**ACCOUNT#**:sender-id/LAMBDATEST2/FR",
        "MonthlyLeasingPrice": "0.00"
      }
    ],
    "summary": {
      "total": 3,
      "successful": 3,
      "failed": 0
    }
  }
}
Function Logs:
START RequestId: 81d2d144-9023-413d-b976-c87c79a82eae Version: $LATEST
Processing country: GB (1/3)
Completed GB: Success
Processing country: DE (2/3)
Completed DE: Success
Processing country: FR (3/3)
Completed FR: Success

After processing your Sender ID configurations, it’s crucial to verify them. You can do this via the AWS console or by using the DescribeSenderIds API. This API offers flexible retrieval options:

  • Specify individual Sender IDs for targeted information
    • Providing an invalid Sender ID will result in an error
  • Apply filters to narrow your results
  • Retrieve all Sender IDs associated with your AWS account by omitting both

Conclusion

Automating Sender ID configuration with the AWS End User Messaging v2 API and a Lambda function will dramatically reduce the time spent on manual configuration, ensure consistent branding across all supported and configured countries, and simplify a complex process. You’ll gain a scalable, reliable solution that allows you to deploy and manage your Sender IDs with confidence.

Additional resources:

AWS End User Messaging SMS documentation

SMS V2 API

Building a voice interface for generative AI assistants

Post Syndicated from Reynaldo Hidalgo original https://aws.amazon.com/blogs/messaging-and-targeting/building-voice-interface-for-genai-assistant/

Generative AI is revolutionizing how businesses interact with their customers through natural conversational interfaces. While organizations can implement AI assistants across various channels, phone calls remain a preferred method for many customers seeking support or information.

We’ll demonstrate how to create a voice interface for your existing Amazon Bedrock generative AI assistant, enabling customers to engage in phone-based conversations with your AI implementation.

Solution overview

Using Workflow Studio for Amazon Web Services (AWS) Step Functions, we built a voice communication interface that connects with the Amazon Nova Micro model in Amazon Bedrock (Figure 1). The demo application uses the base model to enable open-ended questions. Organizations can implement either Amazon Bedrock Agents or Flows to address specific business requirements.

A Step Functions workflow diagram illustrating a voice communication system integrated with Amazon Bedrock. The workflow shows a sequential process starting with call handling, followed by parallel branches: one for managing hold music and another for processing voice input through Amazon Transcribe and Amazon Nova Micro model. The diagram demonstrates the complete call flow from initial welcome message through question-answer cycles to call completion.

Figure 1 – Step Functions workflow that enables voice communication to a generative AI assistant

How it works:

  1. Inbound call arrives
  2. System plays welcome message
  3. System asks caller for questions
  4. Voice recording starts, stopping when silence is detected
  5. Parallel flows begin:
    • First flow
      1. Plays some music while the caller is on-hold
    • Second flow
      1. Transcribes the recording using Amazon Transcribe
      2. Sends transcribed question to the Amazon Nova Micro model in Amazon Bedrock
      3. Upon receiving the response, stops the on-hold music
  6. Text-to-speech plays the model’s answer
  7. System asks for additional questions and loops to Step 4 or ends the call

 Expanded capabilities and optimizations

These are potential improvements, additional functionalities, and advanced features that can enhance the demo application:

  • The transcription component is interchangeable with any speech-to-text generative AI model (including Whisper Large V3 Turbo on Amazon Bedrock Marketplace)
  • The PSTN audio service RecordAudio Action can be tuned to adjust silence duration and background noise levels
  • Enabling the PSTN audio service VoiceFocus feature to improve call clarity by reducing background noise and enhancing voice quality
  • PSTN audio service Session Initiation Protocol (SIP) media applications can also handle calls through SIP trunking by using Amazon Chime SDK Voice Connector, streamlining integration with existing phone systems
  • The UpdateSipMediaApplicationCall API is a PSTN audio service feature that lets you regain call control and apply new actions during active calls
  • Parallel workflow states allow user-friendly handling of API service calls by playing music during processing
  • PSTN audio service provides pay-per-minute rates with serverless, scalable telephony infrastructure

Deploying the solution

 The following steps allow you to deploy the voice communication interface workflow (Figure 1) together with the supporting serverless architecture for Step Functions and PSTN audio service integration. In a previous blog, we demonstrated how combining Step Functions and Amazon Chime SDK PSTN audio service streamlines the development of reliable telephony applications through a visual workflow design.

 Prerequisites:

  1. AWS Management Console access
  2. Node.js and npm installed
  3. AWS Command Line Interface (AWS CLI) installed and configured
  4. Enable access to the Amazon Nova Micro model through the Amazon Bedrock console

 Walkthrough:

The AWS Cloud Development Kit (AWS CDK) project on the AWS GitHub repository will deploy the following resources:

  • phoneNumberBedrock – Provisioned phone number for the demo application
  • sipMediaApp – SIP media application that routes calls to lambdaProcessPSTNAudioServiceCalls
  • sipRule – SIP rule that directs calls from phoneNumberBedrock to sipMediaApp
  • lambdaProcessPSTNAudioServiceCalls – AWS Lambda function for call processing
  • roleLambdaProcessPSTNAudioServiceCalls – AWS Identity and Access Management (IAM) Role for lambdaProcessPSTNAudioServiceCalls
  • stepfunctionBedrockWorkflow – Step Functions workflow for the telephony application
  • roleStepfuntionBedrockWorkflow – IAM Role for stepfunctionBedrockWorkflow
  • s3BucketApp – Amazon Simple Storage Service (Amazon S3) bucket for storing customer questions recordings
  • s3BucketPolicy – IAM Policy granting PSTN audio service access to s3BucketApp
  • lambdaAudioTranscription – Lambda function for audio transcription
  • lambdaLayerForTranscription – Lambda layer required for lambdaAudioTranscription
  • roleLambdaAudioTranscription – IAM Role for lambdaAudioTranscription

Follow these steps to deploy the CDK stack:

  1. Clone the repository.
git clone https://github.com/aws-samples/sample-chime-sdk-bedrock-voice-interface
cd sample-chime-sdk-bedrock-voice-interface
npm install
  1. Bootstrap the stack.
#default AWS CLI credentials are used, otherwise use the –-profile parameter
#provide the <account-id> and <region> to deploy this stack
cdk bootstrap aws://<account-id>/<region>
  1. Deploy the stack.
#default AWS CLI credentials are used, otherwise use the –-profile parameter
#phoneAreaCode: the United States area code used to provision the phone number
cdk deploy –-context phoneAreaCode=NPA
  1. Call the provisioned phone number to test the sample application.

Cleaning up:

To clean up this demo, execute:

cdk destroy

Conclusion

We demonstrated how organizations can add voice capabilities to their existing generative AI implementations using Amazon Bedrock. The solution enables customers to interact with AI assistants through traditional phone calls, expanding accessibility and user engagement. The demo application showcases an architecture combining AWS Step Functions and Amazon Chime SDK PSTN audio service, delivering natural voice conversations with AI models through quick deployment using visual workflows.

Organizations benefit from cost optimization with pay-per-minute pricing, enterprise-ready telephony integration through PSTN or SIP trunking, and automatic scaling to match customer demand. This foundation enables businesses to build practical AI applications ranging from all day customer service agents, to multi-language support services, and knowledge base assistants. By following this solution, you can quickly extend your generative AI investments to voice channels, providing more value to your customers while maintaining operational efficiency.

Contact an AWS Representative to know how we can help accelerate your business.

Improving email security with Amazon SES Mail Manager and Hornetsecurity’s Vade Advanced Email Security Add On

Post Syndicated from Zip Zieper original https://aws.amazon.com/blogs/messaging-and-targeting/improving-email-security-with-amazon-ses-mail-manager-and-hornetsecuritys-vade-advanced-email-security-add-on/

Email continues to be a critical communication channel for businesses, powering essential communications across time zones and locations. But as cyber threats grow more sophisticated, how can organizations protect their most vulnerable communication channel? With the increasing complexity of email-based security risks, businesses need robust solutions to safeguard their digital communications. Today, we’re excited to announce the launch of Hornetsecurity’s Vade Advanced Email Security Add On for Amazon Simple Email Service (SES) Mail Manager, a powerful new tool in the fight against email-borne threats.

Amazon SES: Powering email communication at scale

Amazon SES is a cloud-based email service that helps you automate high-volume email communications seamlessly. In May 2024, we launched Mail Manager, introducing email relay and gateway features that help you manage email traffic, ensure compliance and enforce corporate policies. The launch also included an introduction to Mail Manager Email Add Ons which provides optional access to a collection of powerful security tools from certified providers that help you manage and filter incoming emails. Add Ons from our partners deliver advanced email security with flexible, meter-based pricing that is easily activated and integrated into your email workflows directly from the Mail Manager console or Mail Manager APIs.

In this blog, we’ll introduce Hornetsecurity’s Vade Email Add On for Amazon SES Mail Manager, and demonstrate how to enable its advanced email security capabilities to help protect your critical email communications.

Introducing the Vade Email Add On by Hornet Security

Hornetsecurity, a global leader in email security, produces next-generation cloud-based security, compliance, backup, and security awareness solutions that help companies and organizations of all sizes around the world. Its email filters process billions of emails daily, using a vast global email database to power their artificial intelligence (AI) engine. This approach allows the Vade Email Add On to continuously refine and adapt to the latest email threats and filter-bypassing techniques.

The Vade Email Add On brings Vade’s expertise directly to you, providing a seamless and powerful email security solution within the familiar AWS environment:

“Enhance your email service with advanced cybersecurity capabilities by integrating Vade Email Security’s state-of-the-art filtering solution. This Add On empowers users with automated, real-time defense against spam, malware, and phishing—ensuring safer communication. Vade’s AI-powered technology employs a multi-layered approach—combining heuristics, behavioral analysis, and natural language processing—to analyze messages in real time. Strengthen your platform by ensuring ongoing protection against evolving cyber threats.”

Advanced Email Security with the Vade Add On for Mail Manager

Hornetsecurity’s Vade Add On for Mail Manager provides automated, real-time defense against spam, malware, and phishing, which help ensure safer communication, including:

  • Advanced Threat Detection: Identifies and blocks sophisticated phishing attempts, malware, and ransomware, providing comprehensive protection against a wide range of cyber threats.
  • Behavioral Analysis: Examines the behavior patterns of message senders and content based on over 130 potential data points in each message to detect anomalies and potential threats.
  • Patented AI Technology: Leverages proprietary AI algorithms to analyze communication patterns and detect misuse of your service’s digital assets. This technology is powered by our global network of over 1 billion protected mailboxes.
  • Real-Time Scanning: Instantly analyze attachments without delaying delivery, thanks to its real time code interpreter.
  • Ease of Use: Seamless integration with Mail Manager rules, scanning only messages that meet specific criteria.

The Vade Email Add-On integrates with Mail Manager’s rules engine. This engine routes messages based on Vade’s scan results and optional detailed verdicts. These verdicts enable precise categorization and handling of incoming emails, improving security and email management.

Configure the Vade Email Add On

In the following example, we’ll walk thru the steps needed to subscribe and configure a rule set with two rules that are processed in priority order:

  • Rule 1 – drop-all-malicious-emails This rule has a condition that uses Vade to scan all incoming email and identify messages that are malicious (contain malware or phishing). These messages are then processed by Rule 1’s “Drop action“. Messages that are deemed “safe” are passed to Rule 2 after automatically being inspected and marked as “likely to be spam”, or “not-spam”.
  • Rule 2 – forward-to-mailbox Messages passed into Rule 2 are immediately forwarded to the user’s mailbox. In our example, we’re using Amazon WorkMail and Mail Manager’s built-in “Deliver to mailbox” action.
    • The Vade Add On also distinguishes between spam and clean email, and automatically adds a corresponding header to each message (see below) that can be used to route spam into the user’s “junk” folder.
      • X-SES-Vade-Advanced-Email-Security-AddonVerdict: spam:high
    • Thanks to the seamless integration between Mail Manager Add Ons and WorkMail, messages marked as spam are automatically sent to the user’s Junk folder, enhancing both security and user experience.

Vade Email Add On workflow

Follow the steps below to configure the Vade Email Add On using the Amazon SES console for the simple mail flow described above (note – the SES Mail Manager API can be used in lieu of the console).

  1. Open the Amazon SES console and in the left navigation rail, expand Mail Manager and click Email Add Ons.
  2. Select the Vade Add On, read the description. Click Subscribe and read the Terms and Conditions. Click Subscribe again to activate the Vade Advanced Email Security Add On in your SES account.
    • Pricing is detailed in the Email Add On description page. When this blog was published the price per 1,000 emails processed = $0.415 USD (subject to change, please refer to SES Pricing for the most up to date information).

Vade Email Add On

  1. In the left navigation rail under Mail Manager, click Rule Sets.
  2. Create a new Rule set ( process-via-vade ) (or modify an existing Rule set).
    1. Create a rule ( drop-all-malicious-emails )
    2. Under Rule conditions, click select property and select Vade Advanced Email Security Category from the drop-down menu (note the property modifiers allow for increasingly detailed inspection / results for the scan).
    3. Click the Select operator drop-down and select Equals from the menu.
    4. Click the Value drop-down and select Phishing and Malware.
    5. Under Actions, select Drop action to stop processing and discard messages that are found to be malicious.

Rule 1 - drop-all-malicious-emails

  1. Create rule ( forward-to-mailbox ) to process messages that were passed along by Rule 1.
  2. Under Actions, select Deliver to mailbox (note – if not using Amazon WorkMail, you would select a previously configured SMTPRelay action to send messages to your inbox provider. See this blog for more info).
    1. Provide your WorkMail ARN
    2. Select an IAM role that has permission for SES Mail Manager to access to your WorkMail mailbox

Rule 2 - forward-to-mailbox

  1. Save the Rule set (it will look like this):

New Vade Rule Set

  1. To use this new Rule set, add it to an active Mail Manager Ingress endpoint. When you click save, the Ingress endpoint will begin using the new Rule set immediately.

The Vade Add-On’s rule conditions (below) enable granular control of email routing. When combined with customizable actions, these rules create an automated email handling system that matches your business needs.

VADE result mapping

Conclusion

Hornetsecurity’s Vade Email Add On for Amazon SES Mail Manager represents a significant step forward in email security for Amazon SES Mail Manager customers. By combining an advanced artificial intelligence (AI)-driven security engine with the powerful management capabilities of Mail Manager, you can enhance your defense against email-borne threats while maintaining precise control over your email workflows.

Get started today and take your email security to the next level with the Vade Add On for Amazon SES Mail Manager

We encourage you to try the Vade Add On for Amazon SES Mail Manager and experience the benefits of enhanced email security firsthand. To learn more about implementation details and best practices, please visit:

Join the Conversation:
Connect with other administrators and security professionals on the AWS re:Post community to share insights and learn best practices.