我们的服务目前使用AWS的SNS SMS向用户发送交易文本(即帐户确认、密码重置等)。我们至少有两个环境——开发和生产——使用相同的SNS短信服务，因为这两个环境都在同一个AWS帐户和区域中运行。
我们正在通过Lambda获取CloudWatch故障日志，将短信反弹信息记录在我们的数据库中；然而，我们无法区分出于测试目的从Dev反弹与基于这些日志从用户在Production中合法反弹。
目标是能够根据环境区分反弹，这样我们就可以在各自的数据库中正确记录它们；然而，除了使用单独的帐户或潜在的其他区域之外，我在SNS或CloudWatch中看不到任何方法可以做到这一点。
有人知道在不必求助于单独的账户甚至地区的情况下实现我们目标的方法吗？
每次通过AWS SNS发送SMS时，都可以将结果存储在PublishResult对象中，该对象包含消息的消息ID，如以下SNS文档中的示例代码所示：
public static void main(String[] args) {
AmazonSNSClient snsClient = new AmazonSNSClient();
String message = "My SMS message";
String phoneNumber = "+1XXX5550100";
Map<String, MessageAttributeValue> smsAttributes =
new HashMap<String, MessageAttributeValue>();
//<set SMS attributes>
sendSMSMessage(snsClient, message, phoneNumber, smsAttributes);
}
public static void sendSMSMessage(AmazonSNSClient snsClient, String message,
String phoneNumber, Map<String, MessageAttributeValue> smsAttributes) {
PublishResult result = snsClient.publish(new PublishRequest()
.withMessage(message)
.withPhoneNumber(phoneNumber)
.withMessageAttributes(smsAttributes));
System.out.println(result); // Prints the message ID.
}
控制台输出：｛消息ID:9b888f80-15f7-5c30-81a2-c4511a3f5229｝
如何使用这些信息取决于许多考虑因素，例如在生产和开发环境中运行代码的主机数量、发送消息后访问这些数据的速度、数据保留期、可扩展性，以及计划如何存储CloudWatch日志。
可能的解决方案：
解决方案将取决于您的需求。AWS有无数的数据存储解决方案，可用于存储您的消息ID；简单存储(S3)、NoSQL数据库(如DynamoDB)，甚至数据仓库集群解决方案(如AWS Redshift)。一个例子是使用Kinesis Firehose将数据流式传输到S3存储桶中，该存储桶将您的消息ID(以及您在发布时可能想要存储的任何其他相关信息)作为序列化的JSON对象。这样做的优点是成本非常低，并且可以使用AWS Athena轻松查询S3对象。
根据您使用和访问CloudWatch日志的方式，其他DB可能更合适。
披露：我在AWS团队负责短信。
坦率地说，你必须通过使用消息ID的代码自己处理它，正如Aws guy所说的那样。
这是一个简单的用例，我不明白为什么AWS可以支持它