Я новичок в ELB в стеке AWS, и у меня есть требование, чтобы два компонента, работающие на двух экземплярах EC2, обменивались данными через TLS, и существует аутентификация уровня TLS с помощью компонента 2 из любого входящего сеанса от компонента 1.
В основном мой компонент 2 собирается открыть сертификат входящего запроса на уровне подтверждения SSL, решить, используя EKU / OID, что он исходит из какого-то надежного источника, а затем разрешить успешное рукопожатие.
Теперь два компонента должны располагаться позади ELB, чтобы обеспечить его масштабируемость. Просматривая несколько ресурсов для ELB, я понял, что ELB завершает TLS, а затем может использовать новый сертификат, который ELB может передать по запросу экземпляру, стоящему за ELB.
Во-первых, правильно ли это понимание. В идеале мне нужно, чтобы TLS изначально передавался на машину за ELB, чтобы моя логика аутентификации не нарушалась. Во-вторых, если нет способа сделать это, могу ли я выполнить эту аутентификацию на уровне ELB, для этого необходимо выполнить поиск в БД и, возможно, небольшую программу Java, которая может открыть сертификат, проверить детали, а затем либо отбросить, либо передать сообщение.
Не уверен, что мой вопрос ясен или нет, и для этого, пожалуйста, оставьте любые комментарии, но любой ответ или указатели будут полезны.
-Анураг
Вы можете попробовать использовать Балансировщик нагрузки TCP / SSL. Он работает на уровне TCP (уровень 4), в отличие от уровня приложения, прослушивающего http / https (уровень 7). Протокол прокси также может помочь.
Я думаю, что с балансировщиками нагрузки как SSL, так и HTTPS, ELB завершает TCP-соединение и запускает другое соединение от ELB к серверной службе. Вы можете рассмотреть другие решения для балансировки нагрузки. ELB управляется HAProxy, вы можете запустить экземпляр EC2 с любым балансировщиком нагрузки, который вам нравится, и поместить его в группу автоматического масштабирования размером один, чтобы в случае сбоя он автоматически вернулся к работе.
Взвешенные наборы ресурсов Route 53 могут быть другим подходом к этому. Обычно клиенты направляются на серверы на основе указанного вами веса. Вы просто создаете кучу записей в одном наборе, указывающих на разные экземпляры EC2. Это не совсем масштабируемое решение, оно выполняется вручную, так что это тоже не лучшее решение.
Лучшим вариантом может быть вертикальное масштабирование (т. Е. Получение более крупного экземпляра) и отсутствие необходимости возиться с балансировщиком нагрузки. Если все на одном сервере завершают TCP и аутентификацию, он должен обрабатывать большой трафик. В качестве альтернативы вы можете пересмотреть, как вы выполняете аутентификацию.
Обновить Основываясь на том, что Майкл сказал в комментарии, я прочитал еще немного. Я думаю, что он, скорее всего, прав, Балансировщик нагрузки TCP (не SSL), скорее всего, будут сквозными соединениями без их изменения, как маршрутизатор.
Я предлагаю масштабировать по вертикали, потому что вы можете найти что-нибудь вплоть до m4. 16XL может быть достаточно, если оно соответствует требованиям к емкости и надежности. Было бы проще развернуть один сервер, чем балансировщик нагрузки и несколько серверов, и это сэкономило бы затраты на ELB. Однако это, вероятно, будет менее надежным.