Да, по умолчанию S3 → SQS и S3 → SNS → SQS приведут к двум различным структурам / форматам данных внутри тела сообщения SQS.
Это связано с тем, что подписка SNS предоставляет метаданные с каждым доставленным сообщением - SNS MessageId, Signature для проверки подлинности, Timestamp, когда SNS первоначально принялсообщение и другие атрибуты.Исходное сообщение кодируется в виде строки JSON внутри атрибута Message этой внешней структуры JSON.
Таким образом, с помощью SQS direct вы извлекаете событие S3 с помощью (псевдокода) ...
s3event = JSON.parse(sqsbody)
... но с SNS до SQS ...
s3event = JSON.parse(JSON.parse(sqsbody).Message)
Вы можете отключить дополнительные структуры и заставить SNS отправлять только исходную полезную нагрузку, включив необработанную доставку сообщений вподписка SQS на тему SNS.
https://docs.aws.amazon.com/sns/latest/dg/sns-large-payload-raw-message-delivery.html
При включенной доставке необработанных сообщений содержимое становится одинаковым как для S3 → SQS, так и для S3 → SNS → SQS.
Недостатком необработанной доставки сообщений является то, что вы теряете потенциально полезную информацию для устранения неполадок с доставкой необработанных сообщений, например идентификатор сообщения SNS и выданную SNS временную метку.
С другой стороны, если получатель получаетслужба (потребитель SQS) предполагает, что сообщения всегда поступают через SNS, и ожидает найти структуру данных SNS в теле сообщения SQS, тогда отправка прямой S3 → SQS приведет к тому, что потребитель обнаружит, что тело сообщения из SQS не соответствует егоожидания.