AWS for Industries

FSI Services Spotlight: Featuring Elastic Load Balancing (ELB)

In this edition of the Financial Services Industry (FSI) Services Spotlight monthly blog series, we highlight five key considerations of Elastic Load Balancing (ELB): achieving compliance, data protection, isolation of compute environments, automating audits with APIs, and operational access and security. Each of the five areas will include specific guidance, suggested reference architectures, and technical code that can help streamline service approval of ELB in your environment. These may need to be adapted to your business, compliance, and security requirements

ELB is a fully-managed load balancer that automatically distributes your incoming traffic across multiple targets, such as Amazon Elastic Compute Cloud (Amazon EC2) instances, containers, and IP addresses, in one or more Availability Zones (AZs). It monitors the health of its registered targets, routing traffic only to the healthy targets. ELB scales your load balancer as your incoming traffic changes over time. Furthermore, it can automatically scale to the vast majority of workloads.

elastic load balancing benefits

ELB supports four types of load balancers: Application Load Balancer (ALB), Network Load Balancer (NLB), Gateway Load Balancer (GWLB), and Classic Load Balancer (CLB). You can select the appropriate load balancer based on your application needs. If you need to load Balancing HTTP requests, then we recommend that you use the ALBs. For network/transport protocols (layer4 – TCP, UDP), load balancing, and for extreme performance/low latency applications, we recommend using the NLB. If you need to deploy and run third-party virtual appliances, then you can use GWLB. If you need to deploy a load balancer for EC2-Classic, then you can use CLB.

ELB is used by various financial services institutions around the world to help achieve better business outcomes through easy, transparent scalability with high availability architecture. Stock Exchange of Thailand (SET) uses ELB to support, at its peak, 100,000 simultaneous logins to its trading platform—without compromising system performance or experiencing any downtime. Refer to the complete SET case study for more information.

Another example is CoinJar. They used AWS to build a fast and reliable digital currency exchange, make sure of financial compliance and security best practices, and scale its platform within five minutes during spikes in API requests. Given the unpredictable nature of digital currency markets, scalability is particularly important for CoinJar. During periods of volatility, the platform experiences a spike in usage when its customers make simultaneous API requests. This can result in thousands of requests per second, which presents a significant technical challenge for small teams. However, by using AWS Auto Scaling and ELB to manage heavy workloads, CoinJar can scale effectively with a team of seven IT and DevOps engineers. Refer to the complete CoinJar case study for more information.

CoinJar case study

Security is a shared responsibility between AWS and our customers. AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud and also provides customers with services that they can use securely. The customer responsibility is determined by the AWS service that they use. On the customer’s side of the shared responsibility model, customers should first determine their requirements for network connectivity, encryption, and access to other AWS resources. We’ll dive deeper into those topics in the upcoming sections.

ELB falls under the scope of the following compliance programs regarding AWS’s side of the shared responsibility mode. In the following sections, we’ll cover topics on the customer side of the shared responsibility model.

  • ISO/IEC 27001:2013, 27017:2015, 27018:2019, 27701:2019, 9001:2015
  • CSA STAR CCM v3.0.1
  • SOC 1,2,3
  • PCI
  • ISMAP
  • FedRAMP Moderate and FedRAMP High
  • DoD CC SRG IL2 through IL6
  • HIPAA BAA
  • IRAP
  • MTCS (check regions)
  • C5
  • K-ISMS
  • ENS High
  • OSPAR
  • HITRUST CSF
  • FINMA
  • GSMA
  • PiTuKri
  • CCCS

Data protection

Data protection is the process of preventing critical information from being corrupted, compromised, or lost. Encryption is a recommended practice for making sure of the confidentiality and integrity of the data being processed, both in transit and at rest. You’ll find considerations in the following section for ELB data at rest and data in transit scenarios.

At-Rest Encryption:

ELB provides access logs that capture detailed information regarding the TLS requests sent to your Elastic Load Balancer. You can use these access logs to analyze traffic patterns and troubleshoot issues. Access logging is an optional feature of ELB that is disabled by default. After you enable access logging for your load balancer, ELB captures the logs as compressed files and stores them in the Amazon Simple Storage Service (Amazon S3) bucket that you specify.

To protect your access logs at rest, customers should enable server-side encryption with Amazon S3-managed encryption keys (SSE-S3), or use AWS Key Management Service (AWS KMS) with Customer Managed Keys (SSE-KMS CMK) for your S3 bucket. Each access log file is automatically encrypted by the ELB service before it’s stored in your S3 bucket and decrypted when you access it.

elb

In-transit Encryption:

ELB simplifies the process of building secure web applications by terminating HTTPS and TLS traffic from clients at the load balancer. The load balancer performs the work of decrypting and re-encrypting the traffic, instead of requiring each EC2 instance to handle the work for TLS termination. When you configure a secure listener, you specify the cipher suites and protocol versions, known as a security policy, that are supported by your application. Then, a server certificate is installed on your load balancer. You can use AWS Certificate Manager (ACM) or AWS Identity and Access Management (IAM) to manage your server certificates. Here is a list of load balancer types and the listeners they support:

Application Load Balancer (ALB) Encryption: With your ALB, you can create an HTTPS listener, which handles encrypted connections (also known as SSL offload). To use an HTTPS listener, you must deploy at least one SSL/TLS server certificate on your load balancer and at least one security policy. The load balancer uses a server certificate to terminate the front-end connection and then decrypt requests from clients before sending them to the targets. It’s worth noting the recommendation that your ALB should be configured to redirect all HTTP requests to HTTPS.

Network Load Balancer (NLB) Encryption: With your NLB, you can create an TLS listener, which terminates the front-end connections before sending them to the targets. To use a TLS listener, you must deploy at least one SSL/TLS server certificate on your load balancer and at least one security policy.

Classic Load Balancer (CLB) Encryption: With your CLB, you can create an HTTPS or TLS listener, which terminates the front-end connections before sending them to the targets. To use an HTTPS or TLS listener, you must deploy at least one SSL/TLS server certificate on your load balancer and at least one security policy.

Gateway Load Balancer (GWLB) Encryption: With your GWLB, there is no TLS termination at the load balancer. Once the traffic hits the GWLB, it gets encapsulated and sent to the target appliance. Then, it gets decapsulated by the appliance, where TLS termination happens.

Note that AWS recommends TLS 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS), such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). Most modern systems such as Java 7 and later support these modes.

Isolation of compute environments

As a managed service, ELB is protected by the AWS global network security procedures that are described in the Amazon Web Services: Overview of security processes white-paper. When creating your load balancer, you must specify one or more subnets for the load balancer nodes to be provisioned at. An Amazon Virtual Private Cloud (Amazon VPC) is a virtual network in your own logically isolated area in the AWS Cloud. A subnet is a range of IP addresses in a VPC. This means that your load balancer is a dedicated resource to your VPC.

When you create a load balancer in a VPC, it can be either internet-facing or internal. An internal load balancer can only route requests that come from clients with access to the VPC for the load balancer. Your load balancer sends requests to its registered targets using private IP addresses. Therefore, your targets don’t need public IP addresses to receive requests from a load balancer.

To restrict network traffic to and from your load balancers, you can use Network ACLs (NACLs) attached to the subnet where the load balancer was deployed. Note that NACLS are stateless and you must configure the inbound and outbound traffic flows. For ALBs, NLBs, and CLBs, you can use security groups in addition to NACLs to accept traffic only from specific clients. These security groups must allow inbound traffic from clients on the listener ports and outbound traffic to the clients. Another option to restrict traffic to ALBs is to use AWS Web Application Firewall (WAF) to allow or block requests based on the rules in a web access control list (web ACL).

You can establish a private connection between your VPC and ELB by creating an interface VPC endpoint. An interface VPC endpoint (interface endpoint) lets you connect to services powered by AWS PrivateLink. These services include some AWS services, services hosted by other AWS customers and Partners in their own VPCs (referred to as endpoint services), and supported AWS Marketplace Partner services.

To use AWS PrivateLink, create an NLB for your application in your VPC, and create a VPC endpoint service configuration pointing to that load balancer. Then, a service consumer creates an interface endpoint to your service. This creates an elastic network interface (ENI) in your subnet with a private IP address that serves as an entry point for traffic destined to the service. The consumer and service aren’t required to be in the same VPC. If the VPC is different, then the consumer and service provider VPCs can have overlapping IP address ranges.

aws cloud

Interface endpoints also enable you to privately access ELB API endpoints without an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Using an interface endpoint, instances in your VPC don’t need public IP addresses to communicate with ELB APIs.

By utilizing resource-based policies, you can restrict API access to your load balancer resources rather than to an IAM identity. You can attach a policy to your VPC endpoint to control access to the ELB API. The policy specifies the principal that can perform actions, the actions that can be performed, and the resource on which the actions can be performed.

The following example allows the user admin from account “account-1-id” to perform any action toward the ELB API.

{
    "Statement": [
        {
            "Action": "*", 
            "Effect": "Allow", 
            "Resource": "*", 
            "Principal": {"AWS": ["arn:aws:iam::account-1-id:user/admin"]}
        }
    ]
}

The example above isn’t an optimal security policy, and you should always follow the least-privilege philosophy. Therefore, how would you create a policy that allows the admin user to only load balancers in “account-2-id”? For that you could use a policy like the following.

{
    "Statement": [
        {
            "Action": "elasticloadbalancing:CreateLoadBalancer", 
            "Effect": "Allow", 
            "Resource": [ "arn:aws:elasticloadbalancing::account-2-id:*" ]
            "Principal": {"AWS": ["arn:aws:iam::account-1-id:user/admin"]} 
        }
    ]
}

For more information on the available actions, resources, and condition keys for ELB, you can reference the documentation.

Another tool that customers have to control access to network resources like Elastic Load Balancers is VPC Sharing. Sharing VPCs is useful when network isolation between teams doesn’t need to be strictly managed by the VPC owner, but the account level users and permissions must be. With Shared VPC, multiple AWS accounts create their application resources (such as EC2 instances) in shared, centrally-managed Amazon VPCs. In this model, the account that owns the VPC (owner) shares one or more subnets with other accounts (participants). After a subnet is shared, the participants can view, create, modify, and delete their application resources in the subnets shared with them. Participants can’t view, modify, or delete resources that belong to other participants or the VPC owner. Security between resources in shared VPCs is managed using security groups, NACLs, or through a firewall between the subnets. For more on VPC Sharing, review this post.

Automating audits with APIs

Customers need services and capabilities to assess their ELB resources’ compliance status. AWS Config monitors the configuration of resources and provides some out-of-the-box rules to alert when resources fall into a non-compliant state. For ELB, there are eight managed AWS Config rules that you should evaluate and consider turning on:

Besides managed rules in AWS Config, customers can build custom config rules using API calls related to ELB recorded by AWS CloudTrail. CloudTrail is an AWS service that helps customers enable governance, compliance, and operational and risk auditing of their AWS account. CloudTrail records API calls made to the ELB service. Monitoring these APIs in CloudTrail makes sure that only appropriate actions are taking place against your ELB resources. For a complete list of ELB APIs, review the ELB API Reference.

The following is an example of what a CloudTrail log looks like for a successful CreateLoadBalancer action:

{
    "eventVersion": "1.03", 
    "userIdentity":{
        "type": "IAMUser", 
        "principalId": "123456789012", 
        "arn": "arn:aws:iam::123456789012:user/Alice", 
        "accountId": "123456789012", 
        "accessKeyId": "AKIAIOSFODNN7EXAMPLE", 
        "userName": "Alice"
    },
    "eventTime": "2016-04-01T15:31:48Z", 
    "eventSource": "elasticloadbalancing.amazonaws.com", 
    "eventName": "CreateLoadBalancer", 
    "awsRegion": "us-west-2", 
    "sourceIPAddress": "198.51.100.1", 
    "userAgent": "aws-cli/1.10.10 Python/2.7.9 Windows/7 botocore/1.4.1", 
    "requestParameters":{
        "subnets": ["subnet-8360a9e7","subnet-b7d581c0"], 
        "securityGroups": ["sg-5943793c"], 
        "name": "my-load-balancer", 
        "scheme": "internet-facing" 
    },
    "responseElements":{
        "loadBalancers":[{
            "type": "application", 
            "loadBalancerName": "my-load-balancer", 
            "vpcId": "vpc-3ac0fb5f", 
            "securityGroups": ["sg-5943793c"], 
            "state": {"code":"provisioning"}, 
            "availabilityZones": [ 
                {"subnetId":"subnet-8360a9e7","zoneName":"us-west-2a"}, 
                {"subnetId":"subnet-b7d581c0","zoneName":"us-west-2b"} 
            ], 
            "dNSName": "my-load-balancer-1836718677.us-west-2.elb.amazonaws.com", 
            "canonicalHostedZoneId": "Z2P70J7HTTTPLU", 
            "createdTime": "Apr 11, 2016 5:23:50 PM", 
            "loadBalancerArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:loadbalancer/app/my-load-balancer/ffcddace1759e1d0", 
            "scheme": "internet-facing" 
        }] 
    }, 
    "requestID": "b9960276-b9b2-11e3-8a13-f1ef1EXAMPLE", 
    "eventID": "6f4ab5bd-2daa-4d00-be14-d92efEXAMPLE", 
    "eventType": "AwsApiCall", 
    "apiVersion": "2015-12-01", 
    "recipientAccountId": "123456789012" 
}

Financial customers can use AWS Audit Manager to continuously audit their AWS usage and simplify how they assess risk and compliance with regulations and industry standards. Audit Manager automates evidence collection and organizes the evidence as defined by the control set in the framework selected, such as PCI-DSS, SOC 2, and GDPR. Audit Manager collects data from sources, including CloudTrail, to compare the environment’s configurations against the compliance controls. By logging all ELB calls in CloudTrail, Audit Manager’s integration with CloudTrail becomes advantageous when needing to make sure that controls have been met. For example, consider the encryption requirement in SOC 2. Rather than querying across all CloudTrail logs to make sure that the S3 bucket for ELB access log output are encrypted, customers can centrally see whether the requirement is being met in Audit Manager. Audit Manager saves time with an automated collection of evidence and provides audit-ready reports for customers to review. The Audit Manager assessment report uses cryptographic verification to help you make sure of the integrity of the assessment report. The following screenshot illustrates the configuration of a custom control for the creation of load balancers.

data source

Operational access and security

Security, Availability, and Confidentiality commitments to customers are documented and communicated in Service Level Agreements (SLAs) and other customer agreements, as well as in the Report on the Amazon Web Services System Relevant to Security, Availability, and Confidentiality. Security, Availability, and Confidentiality commitments are standardized and include, but aren’t limited to, the following:

  • Appropriately restrict unauthorized internal and external access to data and one customer’s data is appropriately segregated from other customers.
  • Safeguard data from within and outside of the boundaries of AWS environments which store a customer’s content to meet the service commitments.

Although AWS provides SLAs for the availability of the ELB service, this doesn’t mean that your overall application availability is guaranteed by that SLA. As a best practice when using ELBs, customers should consider enabling Connection Draining to enhance application availability. Connection Draining enables the load balancer to complete in-flight requests made to instances that are de-registering or unhealthy. When you enable connection draining, you can specify a maximum time for the load balancer to keep connections alive before reporting the instance as de-registered. This will help you avoid breaking open network connections while taking an instance out of service, updating its software, or replacing it with a fresh instance that contains updated software.

In the previous section, we discussed detection methods. However, it’s important to utilize prevention methods to have API calls fail when unauthorized access is occurring. When you’re securing your ELB resources, consider three areas to create Least- Privilege IAM roles:

  • Service users – These are the developers and operations teams that use ELB on a day-to-day basis to build their applications. Their IAM policies are created and scoped by the service administrator depending on their job role and access needs. Typical actions are to add and remove targets from target groups or change listeners.
  • Service administrators – This is typically a team or individual within an organization that is in charge of ELB resources and determines developers’ permissions to ELB. These IAM permissions for service users are created to make sure that the downstream users are following the principle of least privilege. Typical actions also include the creation and deletion of load balancers as well as security policy definitions.
  • Application resources – The application resources that can read from and write to ELB within an AWS environment. Typical examples are EC2 instances, Amazon Elastic Container Service (Amazon ECS) tasks, Amazon Elastic Kubernetes Service (Amazon EKS) pods, and AWS Lambda functions.

There are also managed policies that customers can use if they have basic separation of duties. However, we recommend using the managed policy as a baseline, and modifying them to create your own custom policies based on your business needs.

The following AWS managed policies, which you can attach to users in your account, are specific to ELB:

  • ElasticLoadBalancingReadOnly – Grants read-only access to all ELB resources for the AWS account specified.
  • ElasticLoadBalancingFullAccess – Grants full access to all ELB resources for the AWS account specified.

For a complete list of AWS managed policies for ELB, review AWS managed policies for ELB.

Using Identity-based policies (IAM policies), you can provide rights to a person or group in their account to create, access, or edit an ELB resource, such as creating a load balancer, by attaching a policy to the IAM principal.

The following is an example of an identity-based policy that allows the addition of targets in a target group in US-EAST-1 on account id “account-1-id”.

{
    "Version": "2015-12-01",
    "Statement": [
      {
        "Sid": "RegisterTargets",
        "Effect": "Allow",
        "Action": [
          "elasticloadbalancing:RegisterTargets",
          "ec2:DescribeInstances",
          "ec2:DescribeInternetGateways",
          "ec2:DescribeSubnets",
          "ec2:DescribeVpcs"
          
        ],
        "Resource": [
          "arn:aws:elasticloadbalancing:us-east-1:account-1-id:*"    
        ]
      }
    ]
  }

For reference, here. is a list of IAM permissions that are required for common actions within the ELB service.

It’s important to implement IAM policies that follow the principle of least privilege and enforce separation of duties with appropriate authorization for each interaction with your AWS resources.

Attribute based access control

ELB provides tag-based access controls on your API calls. This gives you the ability to restrict actions based on the resource tag.

The following is an example of a policy statement that allows the DeleteLoadBalancer action for only resources that are tagged with the “dev-test” value in account “account-2-id”.

{
    "Effect": "Allow",
    "Action": [
      "elasticloadbalancing:DeleteLoadBalancer"
      ],
    "Resource": [ "arn:aws:elasticloadbalancing::account-2-id:*" ],
    "Condition": {
      "StringLike": {
        "elasticloadbalancing:ResourceTag/TAGNAME": "dev-test"
      }
    }
  }

Furthermore, customers should consider utilizing Service control policies (SCPs) within AWS Organizations. SCPs offer central control over the maximum available permissions for all accounts in the customer’s organization. Unlike IAM policies, SCPs are guardrails, which allow customers to set the maximum privilege within an account or set of accounts regardless of the IAM roles created within them. An example might be limiting the creation of load balancers to only within a specific region(s) where the customer operates. Another use case would include the creation of listeners only if who is creating has the “group” TAG equals developer. The following SCP shows both of these examples in action.

{
  "Version": "2012-10-17",
  "Id": "ELB-Scp-Example",
  "Statement": [
    {
      "Sid": "DenyNonApprovedRegions",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "elasticloadbalancing:CreateLoadBalancer"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2"
          ]
        }
      }
    },
    {
      "Sid": "DenyListenerCreationWhenTAGIsNotPresent",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "elasticloadbalancing:CreateListener"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestTag/group": "developer"
        }
      }
    }
  ]
}

Conclusion

In this post, we reviewed ELB and highlighted key information that can help FSI customers accelerate the approval of the service within these five categories: achieving compliance, data protection, isolation of compute environments, automating audits with APIs, and operational access and security. Although not a one-size-fits-all approach, the guidance can be adapted to meet your organization’s security and compliance requirements and provide a consolidated list of key areas for ELB.

In the meantime, make sure to visit the AWS FSI Services Spotlight Blog Series and stay tuned for more financial services news and best practices. For more information, visit the AWS Financial Services page, AWS Compliance Center, and read the Security Pillar – AWS Well-Architected.

TAGS: , ,
Brandon Rooks Sr.

Brandon Rooks Sr.

Brandon is a Senior Cloud Security Specialist TAM for AWS Enterprise Support, in which he focuses on helping Enterprise customers proactively improve the security of their cloud applications and workloads. He spends his free time with his family, enjoying sports, gaming, music, volunteering, and traveling.

Diego Soares

Diego Soares

Diego Soares is a Sr. Solutions Architect at AWS with over 20 years of experience in the IT industry. He has a background in infrastructure, security, and networking. He works with large financial institutions to help them achieve their business goals with AWS. He is very passionate about how technology can solve business challenges and provide beneficial outcomes by developing multi-architecture solutions.