Вещи выглядят разумно вплоть до шага 6. Нет необходимости искать ближайшую базу данных MySQL, потому что ваши экземпляры уже знают, где она находится - она находится в локальном регионе.
Шаг 7 проблематичен, поскольку ELB нельзя использовать для балансировки экземпляров RDS. Однако с Aurora / MySQL вы получаете одно имя хоста конечной точки «считывателя» кластера с коротким TTL, который балансирует нагрузку между вашими репликами Aurora. Если реплика умирает, она автоматически удаляется из DNS.
Шаг 8 Использование шлюза API строго не обязательно - экземпляры могут напрямую вызывать функции Lambda через API Lambda.
Кроме того, есть Lambda @ Edge, который позволяет запускать функции Lambda непосредственно из CloudFront - хотя, если необходимая вам функция Lambda имеет большой размер (зависимости) или ее необходимо запускать внутри VPC, вам необходимо каскадировать две из них - функция пограничного уровня (не в VPC) вызывает региональную функцию (большую или в VPC), но обычно она все же дешевле, чем API-шлюз. Пограничные функции автоматически реплицируются глобально и запускаются в области, ближайшей к краю CloudFront, обрабатывающей отдельный запрос, и в рамках любого конкретного вызова функции это можно определить путем проверки process.env.AWS_REGION. Краевые функции также можно использовать для изменения источника, обслуживающего контент, например, например, если ваша функция видит, что она была вызвана в регионе ЕС, она может переписать запрос, чтобы CloudFront отправлял запросы S3 в корзину ЕС.
Если ваш сайт находится на вершине домена, например, example.com вместо, скажем, www.example.com, ваш домен должен быть размещен в Route 53, а не в Go Daddy, поскольку ограничения в стандартах DNS не допускают динамического поведения, требуемого CloudFront на вершине. Вы все еще можете зарегистрировать свой домен в них, но не размещать их.