Пока готовил материалы для демонстрации CI/CD в AWS, вдоволь наигрался с CodePipeline и Fargate.

На что обратил внимание:
1. CodeBuild использует похожую с TravisCI и Gitlab модель настроек. Если в Teamcity и Jenkins вы можете задать цепочку тестирования через пользовательский интерфейс, то в CB нужно прописать инструкции в buildspec.yml. Файл интуитивно понятный, но понадобится некоторое время покорпеть над документацией, чтобы не ошибиться с параметрами.
2. Сам CB не имеет в себе возможности сборки нескольких проектов. Если вам нужно прогнать тесты с несколькими приложениями (например интеграционные тесты), то нужно делать два отдельных проекта в СВ и связывать их с CodePipeline.
3. Fargate же построен типично по модели Kubernetes. Когда вы создаете task definition, вы задаете лимиты по ресурсам, а внутри него можно запустить несколько контейнеров (читай тот же Pod). Создавая сервисы, вы можете выбрать варианты развертывания REPLICA и DAEMON, что тонко намекает на концепцию Кубера (replicaset и daemonset).
4. CodePipeline позволяет связать все сервисы сборки и развертывания в одну цепочку, связываясь с GitHub по hook’ам, которые служат триггером для начала цепочки (что в принципе и есть основное ядро CONTINUOUS integration).
5. А вот с чем не понравилось работать, так это с CodeDeploy. Мало того, что appspec.yml (инструкции по развертыванию) гораздо сложнее “вкурить” чем buildspec, так еще очень много приходится возиться с ролями и настройками инстансов, на которые нужно разворачивать приложение. Изначально я хотел провести демо связки CodePipeline (CodeBuild + CodeDeploy G/B) + ASG, но после плюнул и решил уйти поглубже в контейнеры.

И все же, Fargate - one love. Буду топить за переезд на него в следующем году.

Я уже говорил, что у меня на работе есть коллега-архитектор?

Дядечка с 30+ лет опыта работы, помнит UNIX, съел собаку на AWS и нежно любит Bash. Я зову его ласково «Дед» (не в лицо разумеется, иначе поймают на эйджизме).
У меня порой бывали комплексы по поводу своего возраста, особенно потому что некоторые товарищи считали и до сих пор считают, что я не «дорос» до своей должности, но с Дедом никогда проблем не было.
Прикольнее всего смотреть, как Дед работает. Человек отпахал немало лет в Philips и прекрасно знает, как надо делать архитектуру уровня Enterprise.
Но поскольку я гораздо моложе его, то мое преимущество в скорости мышления. Поэтому с Дедом у нас этакий тандем. Дед рисует «скелет» любого проекта, а я, этакий Медведев на минималках, подкидываю туда всяких новомодных плюшек в лице всяких инфраструктур-как-код с этими вашими пайплайнами.
Ну и вишенка на торте - исправлять за дедом опечатки и прочие косяки. Ощущение, как учишь бабушку пользоваться Телеграмом.

Когда я работал в Coolblue в моей команде появилось вакантное место тимлида.

“Почему бы и нет?”- подумал я и подготовил небольшое эссе, которое было тестовым заданием для этой позиции. На одной странице нужно было указать, что по моему мнению есть команда, и какие цели преследует тимлид.

Для меня команда всегда была, есть и будет небольшим отрядом отмороженных ублюдков, пожирающих души своих врагов и тянущей продукт наверх, к Луне.

Что я в принципе и написал в своем эссе. Команда - отряд, а тимлид в ней - сержант, главной целью которого является даже не миссия, а сплоченность и здоровье его команды.
Что об этом подумала комиссия, которая оценивала эссе? Что я хренов милитарист и люблю строгую субординацию и подчинение. Голландцы, как вы помните, крайне демократичные и очень любят свое право голоса. Разумеется, я не прошел.

Что написал мой коллега, который тоже претендовал на эту должность? Он сравнил тимлида с Царем Леонидом, а команду с 300 спартанцев.

Мораль: военщина - плохо, 300 спартанцев и другие псевдоисторические аналогии - хорошо.

Опять же многоуважаемый @CarrolCox балует меня крутым контентом.

Очень классная лекция о том, почему у ИТшников едет крыша (Спойлер: вы в числе этих безумных.) - https://youtu.be/K6oZuB8_dU8

Для себя вынес полезный совет:
Делайте сами все правильно и исправляйте коллектив. Давайте другим звездюлей, будьте проактивными.

Всем, оплатившим вебинар, было выслано приглашение. Если вы оплатили, а письмо никакое не прилетело, пишите в личку.

Тем, кто еще не оплатил, но все равно хочет поучаствовать - не волнуйтесь, время еще есть.

Ребятки, из тех, кому выслал приглашение, зарегистрировались не все.
Потратьте пару минуток, чтобы пройти по ссылочке, чтобы я успел всех “подтвердить".

Для работы мне нужно было написать один “умный” скрипт по развертыванию наших приложений в DCOS.
Раньше наша система сборки попросту отправляла HTTP вызов в DCOS и фиксировала развертывание, как прошедшее успешно. Если приложение по каким-то причинам валилось или вовсе не поднималось, мы об этом узнавали только из мониторинга.

Другой проблемой были разные конфиги приложений. DCOS использует небольшой spec-файл в формате JSON, и в наших репах лежало по одному (или более) файлику для каждого приложения. От такого тоже нужно было уйти, поскольку разные json-чики порождали комплексную инфраструктуру конфигов, которую нам (Ops) было тяжело отслеживать и управлять.

Написав и протестировав свой скрипт, я выкатил его в промышленное использование, перенастроил пайплайны, да так и оставил все это дело на пару месяцев.

Время шло, мы стали выкатывать не только http микросервисы, но и TCP приложения с несколькими портами, и настало время обновить скрипт.
Когда я открыл проект, я понял всю боль программистов, которые месяц не трогали свой код. Куча велосипедов, костылей и “грязно” написанных строчек вызывали у меня страшную фрустрацию. “Кто мог написать такое говно?!” - думал я и сокрушенно смотрел на имя автора коммита.

Спустя полчаса самобичевания, я познал дзен (наверное уже 6-ой раз за этот месяц) и принялся переписывать свое творение. Через пару часов мой скрипт был переделан, а новая структура создания конфига позволяла добавлять новые “фичи” без надобности переписывать все с нуля.

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

Любите рефакторинг.

Чем больше я работаю в ИТ, тем больше я понимаю, что ничего не знаю.

У нас два build агента, оба клонируют репозитории для сборки, используя ключи SSH.
В какой-то момент у нас случилась проблема с SCM (Bitbucket), и нам пришлось заменить ключи на агентах. В итоге Агент 2 может клонировать репозитории, а Агент 1 не может. Валится по SSH auth.

Полез проверять, ключи одинаковые, с правами на файлики все в порядке. Оказалось в .ssh лежал еще публичный ключ id_rsa.pub, который сервер отправлял как публичную часть, и естественно публичная часть ключа была вообще не с тех степей. Убрал публичный ключ из директории, и все заработало. Почему он берет отдельный файл, и отправляет его как публичную часть ключа - вообще не понимаю.

Я знаю, что ничего не знаю.

Спасибо всем пришедшим на вебинар.

Надеюсь, это было интересно и познавательно. Я приобрел ценный опыт, понял, что гарнитуру надо менять, и похоже сорвал голос.
Материалы по вебинару были разосланы его участникам по почте. Если вы по какой-то причине не получили письмо, свяжитесь со мной.

Кстати, пока подчищал свой амазоновский аккаунт, нарвался на то, что не могу удалить Private Hosted Zone .local, который создается автоматом, когда мы поднимаете сервис в Fargate. Причина этому - этой зоной “владеет” подсервис ServiceDiscovery (один из компонентов ECS), который не дает вам его удалить. В принципе, логично.

Но если вы больше не используете Fargate и не хотите лишний раз тратить 50 центов, то нужно удалять сервисы и namespace через AWS CLI. Через консоль это сделать нельзя.

Подробнее о том, как это дело подчистить, написано тут: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/delete-service.html

Чуть позже продублирую информацию по тренировочной программе, о которой я говорил на вебинаре и тут https://t.me/manandthemachine/282.

Теперь по поводу программы тренировок (или менторства - кому как проще), о которой я говорил ранее.

Я уже говорил, что обладаю желанием и возможностью помочь своим молодым читателям (и не только молодым, и не только читателям) в карьерном, профессиональном и личностном росте. Целью вебинара было показать свой опыт и навыки, чтобы потенциальные “ученики” могли оценить для себя, нужно им это или нет.

Что я буду делать:
1. Я помогу вам определиться со своими среднесрочными и долгосрочными целями.
2. На базе этого я подготовлю для каждого “ученика” план развития.
3. Этот план развития затем будет обрастать направлениями на прохождение курсов (разумеется онлайн), чтение различной литературы, выполнение всякого рода домашних заданий.
4. Я со своей стороны буду этот процесс регулировать контролировать.

Воспринимайте это как найм персонального тренера для фитнеса.

Чего же я не буду делать (и обещать тоже):
1. Я не буду гарантировать вам трудоустройство во время или после прохождения программы. Я не обладаю административным ресурсом, чтобы проталкивать людей на нужные им должности, равно как и не являюсь авторизованным центром обучения с гарантированным трудоустройством (Хотя буду помогать в подготовке к собеседованию и выполнению технического задания)
2. Делать вашу работу. Я заинтересован помогать вам в решении своих рабочих проблем, но делать это придется вам сами. Я смогу только направить в нужную точку.
3. Я так же не буду вам помогать, если вы сами этого не хотите. Тут, я думаю, очевидно почему.

По условиям.

Программа будет длится либо 6 месяцев, либо 12 с возможностью продления. За 6 месяцев - 20 000 рублей, за 12 - 30 000 рублей.
Способы и расписание оплаты, а так же прочие условия прохождения программы будут обсуждаться с каждым индивидуально.

Заранее предвкушая вопрос “Почему так дорого?” - просто потому, что для плодотворного сотрудничества нужна жесткая мотивация. И практика показывает, что мотивация “рублем” - самая надежная. Отдав левому анониму из Телеграмма 20 или 30 тысяч рублей, вы будете гораздо более мотивированы грызть гранит науки, проходить обучение и развиваться.

Для того, чтобы стать участником, нужно будет отправить мне на почту (thomas.storm@protonmail.com) свое резюме (без указания персональных данных - я не подписывался ни под ФЗ 152, ни под GDPR) и сопровождающее письмо, в котором надо ответить на два вопроса: чего вы хотите достичь, и почему вы этого еще не достигли.


Как я писал ранее - эта программа больше подходит для молодых (с точки зрения опыта, а не возраста) специалистов, которые либо только начали, либо вообще не начали осваивать DevOps.

На данный момент всего свободно 5 мест. Если я пойму, что “потяну” больше людей, я сообщу об этом в отдельном сообщении.

Если есть вопросы - смело пишите.

Отдельно от миграционных проектов мне нравится браться за исследовательские задачи.

Сейчас, с развитием общих стандартов (a.k.a “Суем Кубер повсюду и переписываем все, что есть, на Golang”), таких проектов в компаниях становится все меньше и меньше. Причины тому просты - то, что вы только задумались сделать, сделали за вас во многих фирмах не один раз. И пусть не все исследования попадают в production, изучать что-то новое всегда полезно (даже если в результате исследования выясняется, что от какого-то продукта лучше держаться подальше).

По умолчанию исследовательские задачи ставятся перед архитекторами или инженерами из R&D групп. Под это дело выделяется определенный бюджет или выдается карт-бланш, резервируются необходимые ресурсы, и люди приступают к изысканиям.
Первое, что попадается на глаза во время исследования - предмет оказывается совсем не rocket science, и вместо полноценного изучения, Proof-of-Concept или Minimal Viable Product делаются по очеркам из интернета и всяких блогов исследователей-энтузиастов.
На выходе получается годная заготовка, которая неожиданно валится во время промышленной эксплуатации.

Во избежание такого, нужно планировать весь проект, словно речь идет не о разведке terra incognita, а о написании новой фичи для бизнеса.
Обычно я разбиваю исследование на следующие этапы:
1. Суть проблемы. Когда запрос на исследование приходит от stakeholder’ов, то входных данных очень мало для подробного анализа. Всегда стоит пообщаться с бизнесом пару лишних раз, чтобы понять какую именно проблему они хотят решить. Даже если к вам приходит СТО и просит рассмотреть переезд с MySQL на PostgreSQL, вне зависимости от компетенций человека надо от него добиться “Почему”.
2. Потенциальные решения. Их всегда должно быть несколько. Если вы решили “запаковаться” в Докер, то нужно выделить несколько систем контейнерной оркестрации под изучение.
3. Составление критериев исследования. Такое чаще всего надо делать, когда вы изучаете инструментарий под одну конкретную цель (например мониторинг). Сядьте с коллегами по цеху, набросайте критерии, поставьте “тяжесть” напротив каждого. Благодаря этому сможете составить стандартизированный сценарий исследования и максимально объективно оценить предмет изучения.
4. Новое должно быть лучше. Именно лучше, а не “не хуже”, иначе вы никогда не защитите свое исследование перед бизнесом. Преимущества нового должны лежать не только в технологической среде, но и экономической - “доход” (или ликвидация риска финансовых потерей за простой) не должна быть ниже стоимости обслуживания (под которую попадает и железо, и поддержка, и лицензии, и человеко-часы на управление).

Опять же, берясь за любое исследование, не стоит “влюбляться” в новый продукт. За несколько лет работы над исследовательскими задачами из моих проектов только 5-10% PoC увидели свет. Оставшиеся были завернуты по причине смены приоритетов, либо были слишком дорогими для внедрения и последующей эксплуатации.
И это на самом деле не плохо! Гораздо хуже, когда в вашей конторе используют хрупкий DCOS, потому что он ну очень понравился разработчикам.

Дорогие читатели, небольшой анонс.

В период с 23 августа по 4 сентября я буду находится в Москве. Если среди ваших кругов планируются какие-то занятные вечерние митапы, дайте знать. Буду непротив на них появиться и послушать умных людей.

Надеюсь, в этот раз проблем с Телеграммом испытывать не буду и продолжу пилить для вас годный контент.

Я тут для себя сделал вчера 3 открытия.

1. Doom 2016 является не перезапуском, а полноценным продолжением оригинальной дилогии. То есть Doom Slayer это тот самый Doomguy, что объясняет почему он так комфортно чувствует себя на Марсе, только вылезев из саркофага.
2. Оригинальный Doom был настолько пропитан насилием, что был не только запрещен в некоторые странах, но и получил рейтинг M от немало известной организации ESRB. Открытием для меня стало то, что ESRB создали как раз из-за Doom
3. Для популярного в России и СНГ 1С существует скриптовый язык OneScript.

Между “митапами” в Нидерландах и в России, да и вообще встречами с коллегами по цеху есть, все-таки, большая разница.

Зачем люди идут на встречи профессионалов в Нидерах? Чтобы лицом засветить. Развивать свою сеть в надежде отломить себе в будущем кусочек побольше. Сколько я ни гонял по конференциям или митапам, итог везде один - посмотрите на меня, я классный.
Встреча с экспертами в России запоминается другим - она душевная. То есть нет уже понтов в стиле: “А вот у нас так сделано, мы клевые”. Есть смехуечки и курьезы с работы. Эти дебилы, тут идиоты, здесь позвонили, тут я нафиг послал.

Западный человек такого не может сказать. Никто не хочет иметь дел с работником, который заказчика нафиг шлет. Даже если разговор идет в курилке или около кулера с водой. Улыбаемся и машем.
“Свои” в этом плане попроще. Разные ситуации бывают у всех, и очень здорово, что можно снять маску “опытного до хрена” и быть честным с людьми.

Больше спасибо всем причастным за сегодняшнюю встречу. Я давно так не смеялся.

Но не все мне о моем своеобразном отпуске писать, поговорим снова о миграции.

Миграционные проекты могут быть краткосрочными и долгосрочными. Все это зависит от размера компании и продукта, а также от требований по uptime и методов переезда (переписываем продукт или lift-and-shift).

Так, например, наш проект GSMG в виду статуса бета-тестирования мог спокойно «полежать» час-другой, пока я не перенес базу и не запустил backend на стороне AWS.

А вот что касается моей основной работы, то тут имеются свои сложности.
Первое - приложение многокомпонентное и нельзя перетащить все сразу. Поэтому сначала мы хотели перенести RabbitMQ (очередь сообщений), затем базу и только в самом конце само приложение.

С «кроликом» пришлось вдоволь намучиться, потому что некоторые микросервисы выступали одновременно и producer’ами сообщений и consumer’ами, что усложняло порядок переключения приложений.
В итоге нам пришлось немного пострадать, но этот вопрос удалось закрыть.

Затем мне поставили задачу унести базу на Амазон. Обьем потерянных данных должен быть равен 0, допустимый downtime - 10 минут на отрезке с часу до двух ночи.

Под это дело я задействовал Database Migration Service (о чем я по приезду напишу в Medium), успешно перенес базу, убедился, что репликация работает без проблем (речь идет о тестовом окружении).
И после этого я получаю письмо от руководителя, что проект замораживается на неопределенный срок, потому что CTO малость надоели конфликты в планировании между Ops и Dev. Потрясающе.

По этому поводу хочу сказать следующее.

Когда вы столкнетесь с похожим проектом, решите все рабочие конфликты со смежными командами. Разберитесь с техническим долгом в максимально сжатые сроки. Приостановите разработку нового функционала. Сделайте все возможное, чтобы запланировать переезд на срок МАКСИМУМ полгода.
Объясните все бизнесу, убедитесь, что верхушка в курсе о рисках и последствиях.

Сделайте свою работу.

У меня все.

Кстати, не существует единого мнения, должен ли DevOps уметь программировать.

С одной стороны, каждый блог или видеокурс по DevOps скажет вам, что программировать необязательно, главное уметь работать с тулингом (Они лукавят и говорят так, чтобы не спугнуть студента).
С другой - в каждой вакансии DevOps просят знать минимум 1-2 языка, если еще и не тот язык, на котором пишут продукт.

Люди, которым программирование не нужно, смотрят на DevOps со стороны Ops, то есть это вчерашние админы, которые освоили нужный инструментарий и умеют разговаривать с разработкой. Вроде бы все правильно, но в DevOps не только из сисадминов приходят, и вчерашний разраб смотрит на DevOps со своего угла.
ИТ менеджеры, добавляющие внушительный список языков в описание вакансии, тоже лукавят. Такие скорее хотят, чтобы нанятый человек не только работал над DevOps составляющей проекта, но и пилил продукт вместе с остальными (Автор лично с таким менеджером встретился на собеседовании в Рамблер).

Однако это все еще не отвечает на вопрос, нужно ли уметь кодить или нет. На мой взгляд нужно, потому что:
1. Не все задачи можно решить с помощью готовых инструментов. Иногда придется писать малюсенький велосипед.
2. Язык продукта стоит знать ради того же SRE. Можно будет потом сделать продукт отказоустойчивым.
3. Знать язык и структуру продукта стоит для понимания, что вы собираете. Это очень упрощает жизнь.

Но есть еще одна, хоть и неявная, причина. Некоторые DevOps’ы очень ответственно подходят к своей работе. Настолько ответственно, что когда ищут что-то для продукта и находят OpenSource решение, то заходят в GitHub проекта и долго его изучают. Как написан, где явные косяки и так далее.

У компаний, особенно небольших, практикующих Agile, очень часто присутствуют проблема с документированием продукта и процессов.

Это распространенная болячка, и в интернете очень много разных How-To о том, как это решать.
Хуже, когда люди ссылаются на Agile Manifesto, дескать, работающий софт важнее документации.

Позволю себе процитировать Манифест: “Working software over comprehensive documentation”

Все, в целом, верно. Вот только речь идет о проектной документации, а не продуктовой или технической.

Вчера довелось попасть на митап по DevSecOps.

Тема неочень новая, но есть пара интересных моментов, которыми хотелось бы поделиться.

1. По волшебной статистике, предоставленной в презентации, на 100 разработчиков приходится 10 DevOps’ов и всего 1 безопасник. Чтобы решить проблему understaffing’а предлагается в каждой команде разработки иметь такого убер-программиста с медалькой “Security Champion”. То есть этот разраб умеет не только писать код, но и писать его “безопасно”.

2. В качестве основной ступени внедрения Sec в DevOps предполагается в CI/CD pipeline добавить два новых “шага” - SAST (Static Application Security Testing) и DAST (Dynamic Application Security Testing). Основная разница между этими подходами в том, что статический анализ кода проходит по самому, собственно, коду и ищет в нем CVE и прочие косяки с безопасность. DAST же пытается взломать уже запущенное приложение, поэтому DAST держат и как часть тестирования в Build системе, и периодически запускают на Production.

Продолжаю радоваться скорости ребят из AWS.

Сначала они запилили Аврору (собственная разработка, совместимая с MySQL и PostgreSQL), а теперь (точнее не теперь, а в августе) сделали Aurora Serverless.
В чем разница? В том, что главная головная боль в работе с облаком - правильно просчитать ресурсы. “Безсерверная” Аврора дает возможность выбрать минимальные и максимальные пороги по ресурсам и будет выдавать ровно столько, сколько нужно. Радость для каждого ИТ менеджера - сэкономить пару лишних сотен долларов.

Пока это совместимо только с MySQL, но принцип работы схож с обычными AutoScaling группами. Задаете границы ресурсов, и Амазон автоматом докинет ресурсов в допустимых границах по мере необходимости.

Но прежде чем лезть во все новое, надо помнить о такой страшной штуке, как “технический долг”.

Любой более менее опытный инженер не раз сталкивался с ситуацией, когда нужно сделать работу “грязно”. Например, отключить Puppet agent и руками настроить firewall, пообещав себе сделать “как надо” на следующей неделе. Или договорившись делать все строго по Infra-as-Code, создать часть ресурсов под новый проект “руками”. Потому что “временно”. Потому что “сейчас надо дать хоть что-нибудь, поправим чуть позже”.

Кривые конфигурации, забытые и неустановленные обновления, недокументированные изменения - все это копится тяжким грузом, который со временем очень сложно разгрести и проще устроить катарсис, начав все с чистого листа.
От этого никуда не уйти, и небольшое количество технического долга будет вас преследовать вплоть до пенсии. Чтобы как-то жить с этим, можно применять то же “золотое” правило 80/20. Если вы работаете в проектной группе, выделяйте на проект 80% ресурсов и 20 на “выплату” долга.

Кредитором и плательщиком здесь выступаете вы сами, и если пропустите пару “платежей” (и абсолютно неважно по каким причинам), то попадете в кабалу, когда, уже наоборот, 80% времени уходит на решение технического долга и всего 20% на проект.

А менеджер-коллектор с паяльником уже стучится вам в дверь и шлет смски с угрозами.
Для тех, кто дружит с английским и/или Google Translate, есть полезная статейка о причинах, последствиях и способах избежания технического “дефолта”, что в твоем 98-ом: https://www.extremeuncertainty.com/technical-debt-technical-bankruptcy/

Долгое время мне приходилось по-разному изворачиваться, чтобы настроить автоматический redirect с HTTP на HTTPS на балансировщике AWS.
Официальная документация, равно как и разные бложики, советовали следующее: поставить балансировщик прослушивать 80 и 443 порт (HTTP и HTTPS соответственно), а на backend сервере настроить redirect таким образом, чтобы он перенаправлял входящий трафик с 80 порта и на 443-ий.

У такого подхода был один жирный и неприятный недостаток. Допустим у вас есть веб-сервер, на котором вы настроили redirect на HTTPS. На балансировщике стоит “прослушка” на 443 порт с последующим переводом трафика на 80 порт на target group’е. Поскольку SSL терминируется на балансировщике, после него идет самый обычный HTTP трафик. Поскольку ALB так же меняет header’ы, вы рискуете поймать следующую ситуацию: трафик приходит на балансер на 80 порт - балансер пропускает трафик на backend - backend видит, что трафик пришел на http и редиректит на https - трафик снова приходит на балансер на 443 порт - балансер пропускает трафик на 80 порт на бэкенде, терминируя SSL - backend видит, что трафик пришел на http и редиректит на http - трафик снова приходит на балансер на 443 порт… Догадались, что вы увидите в браузере?

Это очень геморойная тема, поэтому 25 июля Амазон наконец-то анонсил адекватное решение (https://aws.amazon.com/about-aws/whats-new/2018/07/elastic-load-balancing-announces-support-for-redirects-and-fixed-responses-for-application-load-balancer/). Теперь на правиле прослушивания на 80 порту можно просто поставить правило Redirect. Подробнее можно узнать здесь: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#listener-rules

Соответственно помним, что балансировщик должен также слушать HTTPS с правильно установленными сертификатами.