Завести #external (internet-facing/#public) #LoadBalancer (#ELB/#ALB/#NLB) на расположенные в #private #subnet виртуалки никаких проблем нет. Просто указываем для него, как и положено, #DMZ #subnet (#public):

albExt:
  Type: AWS::ElasticLoadBalancingV2::LoadBalancer
  Properties:
    Name: externalAlb
    Scheme: internet-facing
    Subnets: # DMZ if public
      - !ImportValue subnetVpc4DmzA
      - !ImportValue subnetVpc4DmzB
    SecurityGroups:
      - !Ref sgAlb

А виртуалкам, расположенным и в #private_subnet добавляем в #security_group правила полного доступа с данного балансера:

sgInstance:
  Type: AWS::EC2::SecurityGroup
  Properties:
    VpcId: !ImportValue vpc4
    GroupDescription: Full access for ALB
    SecurityGroupIngress:
      - IpProtocol: tcp
        FromPort:   0
        ToPort:     65535
        SourceSecurityGroupId: !Ref sgAlb
        Description: All TCP trafic - only for ALB

#CloudFormation #templates

При использовании #ELB (созданного через #CloudFormation) с большим количеством инстансов, стоит помнить про фичу Cross-Zone Load Balancing, которая отключена по умолчанию (при создании балансера через консоль - включена по умолчанию).
Итого: для #ELB её нужно включать для более гладкого распределения трафика. У #ALB всегда включена, у #NLB - нужно включать самому.

В случаях, когда нужно иметь #StaticIP для #ALB обычно используется #NLB перед ним (который имеет статический IP для каждой зоны) и #lambda, которая отрабатывает регистрации текущих IP у ALB в качестве целей для NLB.

https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/

С появлением AWS Global Accelerator можно упростить реализацию ALB Static IP, поставив перед ALB #Global_Accelerator (вместо NLB + Lambda). Решение "с перебором" (и более дороже), но может оказаться быстрым "на попробовать" и где-то более удобным в поддержке.

⁠Проблемы NLB + TCP Health Checks

Когда требуется реализовать end-to-end шифрование, то логично выбирать #NLB для подобной задачи. Т.е. это когда не подходит терминация #SSL трафика на ALB, а вы хотите прямиком доставить ваш #TLS до каждого инстанса.

При реализации такой очевидной схемы с NLB можно наткнуться на нестабильную работу TCP Health Check - у вас точно открыты порты, а Health Check не прокатывает, совершенно случайные ошибки, лаги с ответами и прочие странности.

В таком случае не забывайте про ELB (Classic Elastic LoadBalancer). Он прекрасно умеет TCP forwarding и пока его окончательно не списали с большой долей вероятности решит ваш вопрос. С ним не будет никакой магии с HealthCheck-ами.

Рекомендация использовать #ELB вместо #NLB является крайней мерой и просто отражает тот факт, что некоторые сервисы даже спустя годы могут быть не самыми стабильными. А также их стабильность может зависеть от региона.

В любом случае помните, что большинство задач на Амазоне всегда можно решить несколькими способами и решить хорошо.

⁠NLB + sticky sessions

Теперь и NLB обзавёлся поддержкой Sticky Sessions:

https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#sticky-sessions

Очень интересно отметить, что новая фича доступна лишь в европейских датацентрах Ирландии, Франции (Paris) и Швеции (Stockholm).

Так что не обнаружив NLB Sticky Sessions в как бы дефолтной N.Virginia (us-east-1) — не удивляйтесь, там её нет, европейское подразделение AWS рулит. :)

Кстати, на официальной странице возможностей балансеров у NLB ещё нет галочки (см. картинку), но вскоре поставят.

#NLB

NLB + EKS:

https://aws.amazon.com/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/

#EKS #NLB

​​Столкнулся с некоторой "однократной" проблемой. Если в свежесозданный аккаунт с EKS ставить что-то, использующее NLB, а не ELB, то можно наткнуться на ситуацию как на картинке — NLB не создаётся, сервис зависает в состоянии "pending".

При этом, если поменять тип балансера на обычный ELB, то всё отработает. А если после этого снова поменять на NLB — теперь он создастся без каких-то проблем!

Проблема кроется в наличии в аккаунте сервисной роли AWSServiceRoleForElasticLoadBalancing, которая в новых аккаунтах отсутствует (в то время, как в старых аккаунтах она сразу есть!) и которая должна создаваться автоматически. Что происходит для ELB и не срабатывает для NLB.

Для решения проблемы достаточно однократно выполнить:

aws iam create-service-linked-role --aws-service-name elasticloadbalancing.amazonaws.com

#NLB #EKS

Направляем трафик напрямую от NLB к ALB без дополнительных костылей:

https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/

Today, we are launching ALB as a Target of NLB to simplify this process. This new feature allows AWS customers to directly register an ALB as an NLB target, eliminating the need to actively manage changing ALB IP addresses. This is achieved by making use of a newly introduced Application Load Balancer-type target group for NLB.

#NLB #ALB

​​NLB + Security Groups

https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-security-groups.html

✅ You can associate SG with NLB when you create it.

✅ After you create NLB with associated SG, you can change SG associated with NLB at any time.

👉 If you create NLB without associating any SG, you can't associate them with NLB later on.

⚠️ Health checks are subject to outbound rules, but not inbound rules. You must ensure that outbound rules don't block health check traffic. Otherwise, NLB considers the targets unhealthy.

✅ You can control whether PrivateLink traffic is subject to inbound rules. If you enable inbound rules on PrivateLink traffic, the source of the traffic is the private IP address of the client, not the endpoint interface.

#NLB #SG