# Ensure there are no internet-facing Classic Load Balancers

- Source: https://support.icompaas.com/support/solutions/articles/a_1793292209551744-ensure-there-are-no-internet-facing-classic-load-balancers
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224)
- Last updated: 2026-10-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that Classic Load Balancers use the internal scheme rather than internet-facing. An internet-facing load balancer has a public DNS name that resolves to public IP addresses, so its listeners and the backend instances behind it can be reached from the Internet. Every internet-facing Classic Load Balancer fails, with no exception: a load balancer that is intentionally public will still fail and must be accepted as a documented exception.

**Rationale**

An internet-facing load balancer that is not meant to be public exposes backend applications to the Internet. Attackers can use it for reconnaissance, credential stuffing and exploitation of application vulnerabilities, which can lead to data exposure, unauthorized changes and denial of service. Private services should use internal load balancers, and any load balancer that must stay public should be protected with restrictive security groups, TLS and additional DDoS protection.

**Impact**

-   Removes direct Internet access to applications that are meant to be private
    
-   Reduces the attack surface for reconnaissance, exploitation and DDoS attacks
    
-   The scheme of an existing load balancer cannot be changed, so a new load balancer must be created and clients moved to its DNS name
    
-   Clients that connect from the Internet lose access to the application
    

**Default Value**

When a load balancer is created, the scheme is internet-facing unless internal is selected.

**Pre-Requisites**

-   IAM permissions: elasticloadbalancing:DescribeLoadBalancers, elasticloadbalancing:CreateLoadBalancer, elasticloadbalancing:RegisterInstancesWithLoadBalancer and elasticloadbalancing:DeleteLoadBalancer
    
-   Confirmation from the application owner that the load balancer does not need to be reachable from the Internet
    
-   Access to update the DNS records or client settings that point to the load balancer
    
-   Private subnets and security groups for the new internal load balancer
    

**Remediation**

**Test Plan**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon EC2 console and select **Load Balancers** under **Load Balancing**.
    
3.  For each load balancer of type **classic**, check the **Scheme** value.
    
4.  Repeat for each region in use.
    
5.  If any Classic Load Balancer has the scheme **internet-facing** and is not meant to be public, follow the implementation steps.
    

**CLI:**

List the scheme and DNS name of each Classic Load Balancer:

aws elb describe-load-balancers --region <REGION> --query "LoadBalancerDescriptions\[\].\[LoadBalancerName,Scheme,DNSName\]" --output table

A load balancer fails if its Scheme is internet-facing.

**Implementation Steps**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon EC2 console and select **Load Balancers** under **Load Balancing**.
    
3.  Choose **Create load balancer** and create a new load balancer with the scheme **Internal**:
    
    -   select private subnets in at least two Availability Zones,
        
    -   select a security group that allows traffic only from trusted sources,
        
    -   recreate the listeners, health check and backend targets of the existing load balancer.
        
4.  Confirm that the new load balancer reports its targets as healthy.
    
5.  Update the DNS records and client settings that point to the old load balancer so that they use the DNS name of the new internal load balancer.
    
6.  After traffic has moved, delete the old internet-facing load balancer.
    
7.  If a load balancer must remain internet-facing, restrict its security group to the required ports and sources and protect it with TLS and AWS Shield. This is risk reduction, not remediation: the load balancer will still fail and must be accepted as a documented exception.
    
8.  Repeat for each affected load balancer in each region in use.
    

**Backout Plan**

Before deleting the old load balancer, save its configuration:

aws elb describe-load-balancers --region <REGION> --load-balancer-names <LOAD\_BALANCER\_NAME> > elb-backup.json

To roll back:

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Point the DNS records and client settings back to the DNS name of the old internet-facing load balancer.
    
3.  If the old load balancer was already deleted, create a new internet-facing load balancer with the listeners, health check, security groups and instances from the saved backup, and point DNS to it.
    

Note: rolling back exposes the application to the Internet again.

**Reference**

-   [https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html)
    
-   [https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internet-facing-load-balancers.html](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internet-facing-load-balancers.html)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html](https://docs.aws.amazon.com/cli/latest/reference/elb/describe-load-balancers.html)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.