AWS Elastic Load Balancing Connecting Internet-Facing Load Balancer to Private IP Address Targets: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
(Created page with "=Internal= * AWS Elastic Load Balancing Concepts =Overview= <font color=darkgray> This must be researched, because...")
 
No edit summary
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
=External=
* https://aws.amazon.com/premiumsupport/knowledge-center/public-load-balancer-private-ec2/
* https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-securely-publish-internet-applications-at-scale-using-application-load-balancer-and-aws-privatelink/
=Internal=
=Internal=


* [[AWS_Elastic_Load_Balancing_Concepts#Internet-Facing|AWS Elastic Load Balancing Concepts]]
* [[AWS_Elastic_Load_Balancing_Concepts#Internet-Facing|AWS Elastic Load Balancing Concepts]]
* [[AWS_Elastic_Load_Balancing_Operations#Connecting_Internet-Facing_Load_Balancer_to_Private_IP_Address_Targets|AWS Elastic Load Balancing Operations]]


=Overview=
=Overview=


<font color=darkgray>
The essential configuration pieces that puts an Application Load Balancer in the position to take publicly issued requests and forward them to targets running in private subnets is to:
# Declare the application load balancer as '''internet-facing'''
# Associate the application balancer with '''two public subnets'''. We need two, deployed in different availability zones, for high availability purposes:
 
<syntaxhighlight lang='yaml'>
Resources:
  ...
  ApplicationLoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: !Sub ${Color}-public-alb
      Scheme: internet-facing
      Type: application
      IpAddressType: ipv4
      Subnets:
        - !Ref PublicSubnet1
        - !Ref PublicSubnet2
      SecurityGroups:
        - !Ref ApplicationLoadBalancerSecurityGroup
      LoadBalancerAttributes:
        - Key: access_logs.s3.enabled
          Value: false
</syntaxhighlight>
 
After being declared as such, the Application Load Balancer gets a dynamically generated publicly routable IP address, and the packets sent to the load balancer are routed to it by the virtue of the fact it is associated with public subnets.
 
The association between the Application Load Balancer and its target processes is done via a Target Group:
<syntaxhighlight lang='yaml'>
Resources:
  ...
  TargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    #
    # the "DependsOn" is important, I've seen race conditions
    #
    DependsOn: ApplicationLoadBalancer
    Properties:
      Name: !Sub ${Color}-themyscira-tg
      VpcId: !Ref VPC
      Protocol: HTTP
      Port: !Ref ApplicationPort
      TargetType: ip
      HealthCheckProtocol: HTTP
      HealthCheckIntervalSeconds: 60
      HealthCheckTimeoutSeconds: 10
      HealthyThresholdCount: 3
      UnhealthyThresholdCount: 3
      HealthCheckPath: '/actuator/health'
</syntaxhighlight>
 
The Target Group is referred by the Service definition, which is the configuration element that specifies the fact that the target tasks will be deployed in private subnets, in its Network Configuration section.
 
<syntaxhighlight lang='yaml'>
Resources:
  ...
  ServiceDefinition:
    Type: AWS::ECS::Service
    Properties:
      ServiceName: !Sub ${Color}-themyscira
      LaunchType: FARGATE
      Cluster: !Ref Cluster
      TaskDefinition: !Ref TaskDefinition
      DesiredCount: 1
      HealthCheckGracePeriodSeconds: 60
      LoadBalancers:
        - ContainerName: !Sub themyscira-container
          ContainerPort: !Ref ApplicationPort
          TargetGroupArn: !Ref TargetGroup
      NetworkConfiguration:
        AwsvpcConfiguration:
          AssignPublicIp: DISABLED
          SecurityGroups:
            - !Ref ServiceSecurityGroup
          Subnets:
            - !Ref PrivateSubnet1
            - !Ref PrivateSubnet2
</syntaxhighlight>


This must be researched, because of "You can specify either subnets or subnet mappings, not both (Service: AmazonElasticLoadBalancingV2; Status Code: 400; Error Code: ValidationError; Request ID: b2aabbb6-6b75-11e9-9307-b1a4f8a4d3a4)"
The full CloudFormation stack that can be used to experiment with this is available here:


Subnet mapping becomes relevant when the load balancer is "[[#Internet-Facing|internet facing]]", and it has to be configured to handle traffic from the internet. While "Subnets" configuration specifies subnets for targets, "SubnetMappings" configuration specifies the public subnets the internet packets are routed from. Note that simply declaring a load balancer "internet-facing" does not automatically make it publicly accessible. The load balancer must be associated with at least two public subnets, in two different availability zones. This is what Subnet Mappings is for.
{{Internal|CloudFormation_Network_Experimentation_Stack#Internal|CloudFormation Network Experimentation Stack}}


For application load balancers, subnets from at lest two availability zones must be specified. Specific Elastic IP addresses cannot be used - because the application load balancer may use different dynamically allocated IP addresses during its life time. For network load balancers, subnets from one or more availability zones can be specified. A specific Elastic IP addresses can be specified, by its allocation ID.
Note that if the application load balancer is "internal" and not "internet-facing", the "Subnets" configuration element can be used to specify the private subnets, directly.
</font>

Latest revision as of 21:03, 1 May 2019

External

Internal

Overview

The essential configuration pieces that puts an Application Load Balancer in the position to take publicly issued requests and forward them to targets running in private subnets is to:

  1. Declare the application load balancer as internet-facing
  2. Associate the application balancer with two public subnets. We need two, deployed in different availability zones, for high availability purposes:
Resources:
  ...
  ApplicationLoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Name: !Sub ${Color}-public-alb
      Scheme: internet-facing
      Type: application
      IpAddressType: ipv4
      Subnets:
        - !Ref PublicSubnet1
        - !Ref PublicSubnet2
      SecurityGroups:
        - !Ref ApplicationLoadBalancerSecurityGroup
      LoadBalancerAttributes:
        - Key: access_logs.s3.enabled
          Value: false

After being declared as such, the Application Load Balancer gets a dynamically generated publicly routable IP address, and the packets sent to the load balancer are routed to it by the virtue of the fact it is associated with public subnets.

The association between the Application Load Balancer and its target processes is done via a Target Group:

Resources:
  ...
  TargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    #
    # the "DependsOn" is important, I've seen race conditions
    # 
    DependsOn: ApplicationLoadBalancer
    Properties:
      Name: !Sub ${Color}-themyscira-tg
      VpcId: !Ref VPC
      Protocol: HTTP
      Port: !Ref ApplicationPort
      TargetType: ip
      HealthCheckProtocol: HTTP
      HealthCheckIntervalSeconds: 60
      HealthCheckTimeoutSeconds: 10
      HealthyThresholdCount: 3
      UnhealthyThresholdCount: 3
      HealthCheckPath: '/actuator/health'

The Target Group is referred by the Service definition, which is the configuration element that specifies the fact that the target tasks will be deployed in private subnets, in its Network Configuration section.

Resources:
  ...
  ServiceDefinition:
    Type: AWS::ECS::Service
    Properties:
      ServiceName: !Sub ${Color}-themyscira
      LaunchType: FARGATE
      Cluster: !Ref Cluster
      TaskDefinition: !Ref TaskDefinition
      DesiredCount: 1
      HealthCheckGracePeriodSeconds: 60
      LoadBalancers:
        - ContainerName: !Sub themyscira-container
          ContainerPort: !Ref ApplicationPort
          TargetGroupArn: !Ref TargetGroup
      NetworkConfiguration:
        AwsvpcConfiguration:
          AssignPublicIp: DISABLED
          SecurityGroups:
            - !Ref ServiceSecurityGroup
          Subnets:
            - !Ref PrivateSubnet1
            - !Ref PrivateSubnet2

The full CloudFormation stack that can be used to experiment with this is available here:

CloudFormation Network Experimentation Stack

Note that if the application load balancer is "internal" and not "internet-facing", the "Subnets" configuration element can be used to specify the private subnets, directly.