Завести #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 - нужно включать самому.

⁠Проблемы 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 является крайней мерой и просто отражает тот факт, что некоторые сервисы даже спустя годы могут быть не самыми стабильными. А также их стабильность может зависеть от региона.

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