Включение логов ALB.

#ALB #logs #alb_logs

Завести #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

При использовании #DNS #Alias нужно учитывать, что #HostedZoneId разный для разных Alias Target.
Для #CloudFront он фиксированный Z2FDTNDATAQYW2:

aliasSite:
  Type: AWS::Route53::RecordSet
  Properties:
    HostedZoneName: !Join ['', [!Ref MainDomain, '.']]
    Name:           !Ref MainDomain
    Type:           A
    AliasTarget:
      DNSName:      !Ref CnameSite
      HostedZoneId: Z2FDTNDATAQYW2

Для #LoadBalancer нужно получать его через #GetAtt, для #ELB это:

HostedZoneId1:
Value: !GetAtt [elbExt, 'CanonicalHostedZoneNameID']

Для #ALB это:

HostedZoneId1:
Value: !GetAtt [albExt, 'CanonicalHostedZoneID']

Для #alias на другую #RecordSet нужно получать #HostedZoneId домена:

def Result = sh( script: 'aws route53 list-hosted-zones-by-name --dns-name '+gos.MainDomain, returnStdout: true )
def ResultJson = readJSON ( text: Result )
Stack['dns']['params']['HostedZoneIdDomain'] = ResultJson['HostedZones'][0]['Id'].split('/')[2]

При использовании #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). Решение "с перебором" (и более дороже), но может оказаться быстрым "на попробовать" и где-то более удобным в поддержке.

⁠Least Outstanding Requests (LOR) балансировка для ALB

При распределении запросов за ALB используется обычный Round-Robin. Теперь же можно задать Least Outstanding Requests (LOR) - маршрутизировать запросы сначала к тем, кто лучше пингуется:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#modify-routing-algorithm

То есть запросы будут получать инстансы с учётом значений RequestCount, TargetConnectionErrorCount и TargetResponseTime.

Не на всех типах нагрузки это отразится, однако денег лишних не просит, а первые результаты очень положительные (см. картинку), потому точно стоит попробовать.

Включается в консоли в Target Groups или с помощью #aws_cli:

https://docs.aws.amazon.com/cli/latest/reference/elbv2/modify-target-group-attributes.html

Удачных экспериментов!

#ALB

​​Least Outstanding Requests в действии

В конце прошлого года к стандартному Round-Robin алгоритму раздачи трафика лоадбалансером добавился ещё и Least Outstanding Requests. Кто сие пропустил или просто интересно взглянуть, что это и как работает — очень хорошая статейка:

https://medium.com/dazn-tech/aws-application-load-balancer-algorithms-765be2eca158

Тестирование у автора показало местами кратный прирост скорости. Так что очень стоит взглянуть и попробовать у себя.

#ALB

​​ALB + Static IP

Получить статический айпишник для ALB можно в пару кликов, включив поддержку Global Accelerator во вкладке Integrated services (на картинке).

https://docs.aws.amazon.com/global-accelerator/latest/dg/about-accelerators.alb-accelerator.html

Конечно, этот айпишник будет у Global Accelerator, который добавит некоторые расходы ко всей конструкции, но также и даст ускорение при работе с клиентами по всему миру за счёт того, что запросы будут ходить на ALB через ближайшие к клиенту Edge точки Амазона (далее внутри по инфраструктуре AWS, а не через интернет).

#ALB #Global_Accelerator

Один ALB балансер для всех ингрессов:

https://aws.amazon.com/blogs/containers/introducing-aws-load-balancer-controller/

Раньше на каждый ингресс создавался отдельный ALB, теперь же можно использовать один (общий для разных/нескольких ингрессов), как для ELB (Classic балансера).

#ALB #EKS

ALB + HTTP/2 + gRPC:

https://aws.amazon.com/blogs/aws/new-application-load-balancer-support-for-end-to-end-http-2-and-grpc/

#ALB

Подробности причин возникновения Error 502 при работе с ALB:

https://www.tessian.com/blog/how-to-fix-http-502-errors/

#ALB

Направляем трафик напрямую от 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

​​Multiple applications on EKS using a single ALB:

https://aws.amazon.com/blogs/containers/how-to-expose-multiple-applications-on-amazon-eks-using-a-single-application-load-balancer/

▫️ In this blog post, we demonstrated, in a step-by-step procedure, how to implement a microservices architecture in a simple and cost-effective way using EKS with a single ALB.
▫️ If you wish, you could also achieve the same results by using several Ingress objects pointing to the same ALB using the annotation “alb.ingress.kubernetes.io/group.name”. In this case, you would create individual Ingresses and add a common name to this annotation.
▫️ By using this approach, different teams can be completely independent from each other because they can deploy and manage their own services and ingresses while relying on the ALB.

#EKS #ALB

​​ALB + TLS 1.3: 🎉

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies

🔹 ELBSecurityPolicy-TLS13-1-2-2021-06 security policy is the default policy for HTTPS listeners created using the AWS Console. This security policy includes TLS 1.3, which is optimized for security and performance, and backward compatible with TLS 1.2.
🔸 ELBSecurityPolicy-2016-08 policy is the default security policy for listeners created using the AWS CLI.

#ALB