Иван Шумов

Может быт что угодно. Единственный способ - изучить платформу ДО ее использования. Желательно не на уровне "я могу запустить виртуалку"

AWS Cloudwatch Logs, конечно, никто даже не подумал использовать?

В SNS будет несколько Topic Subscription. Ну то есть да, каждый subscription - свой отдельный platform application

Я бы не стал так делать по тому что это дорого. Чтобы нативно использовать данный функционал надо подключить Direct Connect, который стоит конских денег. Не у всех энтерпрайзов есть столько.

Стоит задуматься в чем смысл размещать сервера у себя в ДЦ есть AWS предоставляет лучшие условия (за цену не говорю). А если это разные приложения или на разных роутах то можно просто закрыть через Cloudfront

Кто-то делает что-то через всем известное место. Перестаньте пользоваться ip и начните использовать доменное имя. К тому же VPC это натурально виртуальная сеть. Нельзя перенести виртуальную машину из одной сети в другую. Возьмите route53 и направляйте доменное имя в нужное место, а уж через publicIP, ElasticIP или Load Balancer это делать - дело третье

Справедливого вывода не будет. В Serverless огромное количество подводных камней не все на нем можно сделать. Кроме того Serverless требует понимания как устроен мир с принципе чтобы эффективно его использовать. В принципе, есть успешные примеры как это работает, на примере ACloud Guru. Но надо понимать что если плохо просчитать то Serverless может оказаться очень дорогим.

В любом случае я бы советовал познакомиться с этими подходами на примере курса The Complete Serverless от тех же ACG

Из SSM параметры могут не прогрузиться только в том случае если нет доступов или нет ключа. Если деплой производится через CloudFormation то в этих случаях он должен упасть с ошибкой.

Это не имеет смысла, во-первых. А во-вторых невозможно. RDS работает с KMS