И ещё вопрос немного вбок, может кто подскажет онлайн ресурсы где можно нарисовать простые схемы приложения в стиле https://docs.aws.amazon.com/AmazonECS/latest/developerguide/images/overview-fargate.png

CloudFront сам средиректит http->https

Не совсем нарисовать, но тоже хорошо

Спасибо, питон не знаю но вроде бы не сильно сложно )

Я стараюсь делать феншуйно как могу в рамках free tier) пока в силу ценника nat gateway сделал без private subnet поэтому дырка есть ) но в теории я видел так что alb делает редирект на хттпс, сама терминейтит и шлёт http трафик в приватный хост. Я в этой схеме не очень понимаю как запилить такое же с cloudfront - по идее форвардить и терминейтить надо там, но тогда если будет доступен где-либо в респонсе паблик адрес alb то будет возможность доступа по хттп они , тк редирект с alb придется убрать.

феншуй, феншую рознь
главное порнимать зачем так или иначе делать
а так любое решение может быть оправданным - с NAT и без, с CloudFront и без, и т.д.

@L0nliL0kli вы также можете если хотите сделать https между cloudfront и ALB

А как это будет выглядеть?  На cloud front терминейтится, потом энкриптиться и снова шлется хттпс на alb? Это кажется уже оверхедом и по скорости будет не очень

Если исходить из задачи сделать gzip/br то похоже в случае AWS есть только опция cloudfront. Либо пытаться переделать с alb -> nlb. Хттпс онли было для меня хотя бы полезным экспериментом )

у многих, например финтех какой-нить это обязательное условие..

Если есть задача трафик всегда держать зашифрованным - то это норм. Оверхедла тут минимум, при соверменных процессорах зашифровать дело простое.
технически будет так что и от клиента до CDN https, дальше развернули и послали на alb опять о https
два разных сертификата будет в такой схеме

Но цель ведь получить прирост в рамках кеширования. Я не уверен что такая схема будет быстрее чем если бы я развернул нгинкс в том же ECS