Classic Load Balancer FAQ

                                    Classic Load Balancer
Q: Which operating systems does the Classic Load Balancer support?
The Classic Load Balancer supports Amazon EC2 instances with any operating system currently supported by the Amazon EC2 service.


Q: Which protocols does the Classic Load Balancer support?
The Classic Load Balancer supports load balancing of applications using HTTP, HTTPS (Secure HTTP), SSL (Secure TCP) and TCP protocols.


Q: What TCP ports can I load balance?
You can perform load balancing for the following TCP ports:

• [EC2-VPC] 1-65535
• [EC2-Classic] 25, 80, 443, 465, 587, 1024-65535

Q: Does the Classic Load Balancer support IPv6 traffic?
Yes. Each Classic Load Balancer has an associated IPv4, IPv6, and dualstack (both IPv4 and IPv6) DNS name. IPv6 is not supported in VPC. You can use an Application Load Balancer for native IPv6 support in VPC.


Q: Can I configure my Amazon EC2 instances to only accept traffic from Classic Load Balancers?
Yes.


Q: Can I configure a security group for the front-end of Classic Load Balancers?
If you are using Amazon Virtual Private Cloud, you can configure security groups for the front-end of your Classic Load Balancers.


Q: Can I use a single Classic Load Balancer for handling HTTP and HTTPS requests?
Yes, you can map HTTP port 80 and HTTPS port 443 to a single Classic Load Balancer.


Q: How many connections will my load balanced Amazon EC2 instances need to accept from each Classic Load Balancer?
Classic Load Balancers do not cap the number of connections that they can attempt to establish with your load balanced Amazon EC2 instances. You can expect this number to scale with the number of concurrent HTTP, HTTPS, or SSL requests or the number of concurrent TCP connections that the Classic load balancers receive.


Q: Can I load balance Amazon EC2 instances launched using a Paid AMI?
You can load balance Amazon EC2 instances launched using a paid AMI from AWS Marketplace. However, Classic Load Balancers do not support instances launched using a paid AMI from Amazon DevPay site.


Q: Can I use Classic Load Balancers in Amazon Virtual Private Cloud?
Yes -- see the Elastic Load Balancing web page.


Q: Can I get a history of Classic Load Balancer API calls made on my account for security analysis and operational troubleshooting purposes?
Yes. To receive a history of Classic Load Balancer API calls made on your account, simply turn on CloudTrail in the AWS Management Console.


Q: Do Classic Load Balancers support SSL termination?
Yes you can terminate SSL on Classic Load Balancers. You must install an SSL certificate on each load balancer. The load balancers use this certificate to terminate the connection and then decrypt requests from clients before sending them to the back-end instances.

Q: What are the steps to get a SSL certificate?
You can either use AWS Certificate Manager to provision a SSL/TLS certificate or you can obtain the certificate from other sources by creating the certificate request, getting the certificate request signed by a CA, and then uploading the certificate using the AWS Identity and Access Management (IAM) service.

Q: How do Classic Load Balancers integrate with AWS Certificate Manager (ACM)?
Classic Load Balancers are now integrated with AWS Certificate Management (ACM). Integration with ACM makes it very simple to bind a certificate to each load balancer thereby making the entire SSL offload process very easy. Typically purchasing, uploading, and renewing SSL/TLS certificates is a time-consuming manual and complex process. With ACM integrated with Classic Load Balancers, this whole process has been shortened to simply requesting a trusted SSL/TLS certificate and selecting the ACM certificate to provision it with each load balancer.


Q: How do I enable cross-zone load balancing in Classic Load Balancer?
You can enable cross-zone load balacing using the console, the AWS CLI, or an AWS SDK. See Cross-Zone Load Balancing documentation for more details.


Q: Am I charged for regional AWS data-transfer when I enable cross-zone load balancing in Classic Load Balancer?
No, you are not charged for regional data transfer between Availability Zones when you enable crosss-zone load balancing for your Classic Load Balancer.

Network Load Balancer FAQ

                              Network Load Balancer
Q: Can I create a TCP (Layer 4) listener for my Network Load Balancer?
Yes. Network Load Balancers support only TCP (Layer 4) listeners.


Q: What are the key features available with the Network Load Balancer?
Network Load Balancer provides TCP (Layer 4) load balancing. It is architected to handle millions of requests/sec, sudden volatile traffic patterns and provides extremely low latencies. In addition Network Load Balancer also preserves the source IP of the clients, provides stable IP support and Zonal isolation. It also supports long-running connections that are very useful for WebSocket type applications.


Q: How does Network Load Balancer compare to what I get with the TCP listener on a Classic Load Balancer?
Network Load Balancer preserves the source IP of the client which in the Classic Load Balancer is not preserved. Customers can use proxy protocol with Classic Load Balancer to get the source IP. Network Load Balancer automatically provides a static IP per Availability Zone to the load balancer and also enables assigning an Elastic IP to the load balancer per Availability Zone. This is not supported with Classic Load Balancer. Classic Load Balancer provides SSL termination that is not available with Network Load Balancer.


Q: Can I migrate to Network Load Balancer from Classic Load Balancer?
Yes. You can migrate to Network Load Balancer from Classic Load Balancer using one of the options listed in this document. 


Q: Are there limits on the resources for my Network Load Balancer?
Yes, please refer to Network Load Balancer limits documentation for more information.

Q: Can I use the AWS Management Console to set up my Network Load Balancer?
Yes, you can use the AWS Management Console, AWS CLI, or the API to set up a Network Load Balancer.


Q: Can I use the existing API for Classic Load Balancers for my Network Load Balancers?
No. To create a Classic Load Balancer, use the 2012-06-01 API. To create a Network Load Balancer or an Application Load Balancer, use the 2015-12-01 API.


Q: Can I create my Network Load Balancer in a single Availability Zone?
Yes, you can create your Network Load Balancer in a single availability zone by providing a single subnet when you create the load balancer.


Q: Does Network Load Balancer support DNS regional and zonal fail-over?
Yes, you can use Amazon Route 53 health checking and DNS failover features to enhance the availability of the applications running behind Network Load Balancers. Using Route 53 DNS failover, you can run applications in multiple AWS Availability zones and designate alternate load balancers for failover across regions. In the event that you have your Network Load Balancer configured for multi-AZ, if there are no healthy EC2 instances registered with the load balancer for that Availability Zone or if the load balancer nodes in a given zone are unhealthy, then R-53 will fail away to alternate load balancer nodes in other healthy availability zones.


Q: Can I have a Network Load Balancer with a mix of ELB-provided IPs and Elastic IPs or assigned private IPs?
No. A Network Load Balancer’s addresses must be completely controlled by you, or completely controlled by ELB. This is to ensure that when using Elastic IPs with a Network Load Balancer, all addresses known to your clients do not change.


Q: Can I assign more than one EIP to my Network Load Balancer in each subnet?
No. For each associated subnet that a Network Load Balancer is in, the Network Load Balancer can only support a single public/internet facing IP address


Q: If I remove/delete a Network Load Balancer what will happen to the Elastic IP addresses that were associated with it?
The Elastic IP Addresses that were associated with your load balancer will be returned to your allocated pool and made available for future use.


Q: Does Network Load Balancer support internal load balancers?
Network Load Balancer can be set-up as an internet-facing load balancer or an internal load balancer similar to what is possible with Application Load Balancer and Classic Load Balancer.


Q: Can the internal Network Load balancer support more than one private IP in each subnet?
No. For each associated subnet that a load balancer is in, the Network Load Balancer can only support a single private IP.


Q: Can I set up Websockets with my Network Load Balancer?
Yes, configure TCP listeners that route the traffic to the targets that implement WebSockets protocol (https://tools.ietf.org/html/rfc6455 ). Because WebSockets is a layer 7 protocol and Network Load Balancer is operating at layer 4, no special handling exists in Network Load Balancer for WebSockets or other higher level protocols.


Q: Can I load balance to any arbitrary IP address?
You can use any IP address from the load balancer’s VPC CIDR for targets within load balancer’s VPC and any IP address from RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) or RFC 6598 range (100.64.0.0/10) for targets located outside the load balancer’s VPC (EC2-Classic and on-premises locations reachable over AWS Direct Connect).


Q: What benefit will I get by targeting containers behind a load balancer with IP addresses instead of instance IDs?
Each container on an instance can now have its own security group and does not need to share security rules with other containers. You can attach security groups to an ENI and each ENI on an instance can have a different security group. You can map a container to the IP address of a particular ENI to associate security group(s) per container. Load balancing using IP addresses also allows multiple containers running on an instance use the same port (say port 80). The ability to use the same port across containers allows containers on an instance to communicate with each other through well-known ports instead of random ports.


Q: How can I load balance applications distributed across a VPC and on-premises location?
There are various ways to achieve hybrid load balancing. If an application runs on targets distributed between a VPC and an on-premises location, you can add them to the same target group using their IP addresses. To migrate to AWS without impacting your application, gradually add VPC targets to the target group and remove on-premises targets from the target group.You can also use separate load balancers for VPC and on-premises targets and use DNS weighting to achieve weighted load balancing between VPC and on-premises targets.


Q: How can I load balance to EC2-Classic instances?
You cannot load balance to EC2-Classic Instances when registering their Instance IDs as targets. However if you link these EC2-Classic instances to the load balancer's VPC using ClassicLink and use the private IPs of these EC2-Classic instances as targets, then you can load balance to the EC2-Classic instances. If you are using EC2 Classic instances today with a Classic Load Balancer, you can easily migrate to a Network Load Balancer.


Q: How do I enable cross-zone load balancing in Network Load Balancer?
You can enable cross-zone loading balancing only after creating your Network Load Balancer. You achieve this by editing the load balancing attributes section and then by selecting the cross-zone load balancing support checkbox.


Q: Am I charged for regional AWS data-transfer when I enable cross-zone load balancing in Network Load Balancer?
Yes, you will be charged for regional data transfer between Availability Zones with Network Load Balancer when cross-zone load balancing is enabled. Check the charges in the data-transfer section at Amazon EC2 On-Demand Pricing page.


Q: Is there any impact of cross-zone load balancing on Network Load Balancer limits?
Yes. Network Load Balancer currently supports 200 targets per Availability Zone. For example, if you are in 2 Availability-Zones, you can have up to 400 targets registered with Network Load Balancer. If cross-zone load balancing is on, then the maximum targets reduces from 200 per Availability Zone to 200 per load balancer. So, in the example above when cross-zone load balancing is on, even though your load balancer is in 2 Availability Zones, you are limited to 200 targets that can be registered to the load balancer.

Network Load Balancer Pricing FAQs

Q:How does Network Load Balancer pricing work?
You are charged for each hour or partial hour that a Network Load Balancer is running and the number of Load Balancer Capacity Units (LCU) used by Network Load Balancer per hour.


Q: What is a Load Balancer Capacity Unit (LCU)?
An LCU is a new metric for determining how you pay for a Network Load Balancer. An LCU defines the maximum resource consumed in any one of the dimensions (new connections/flows, active connections/flows, and bandwidth) the Network Load Balancer processes your traffic.


Q: Is new connections/flows per sec same as requests/sec?
No. Multiple requests can be sent in a single connection.


Q: Will I be billed on Classic Load Balancers by LCU?
No. Classic Load Balancers will continue to be billed for bandwidth and hourly charge


Q: How do I know the number of LCUs a Network Load Balancer is using?
We will expose the usage of all three dimensions that constitutes a LCU via Amazon CloudWatch.


Q: Will I be billed on all the dimensions in an LCU?
No. The number of LCUs per hour will be determined based on maximum resource consumed amongst the three dimensions that constitutes a LCU.


Q: Will I be billed on partial LCUs?
Yes.


Q: Is a free tier offered on a Network Load Balancer for new AWS accounts?
Yes. For new AWS accounts, a free tier for a Network Load Balancer offers 750 hours and 15 LCUs. This free tier offer is only available to new AWS customers, and is available for 12 months following your AWS sign-up date.


Q: Can I use a combination of Network Load Balancer, Application Load Balancer and Classic Load Balancer as part of my free tier?
Yes. You can use Application and Network each for 15 LCUs and Classic for 15 GB respectively. The 750 load balancer hours are shared between Application, Network and Classic Load Balancers.

Application Load Balancer FAQ

                 Application Load Balancer
Q: Which operating systems does an Application Load Balancer support?
An Application Load Balancer supports targets with any operating system currently supported by the Amazon EC2 service.


Q: Which protocols does an Application Load Balancer support?
An Application Load Balancer supports load balancing of applications using HTTP and HTTPS (Secure HTTP) protocols.


Q: Is HTTP/2 Supported on an Application Load Balancer?
Yes. HTTP/2 support is enabled natively on an Application Load Balancer. Clients that support HTTP/2 can connect to an Application Load Balancer over TLS.


Q: What TCP ports can I use to load balance?
You can perform load balancing for the following TCP ports: 1-65535


Q: Is WebSockets supported on an Application Load Balancer?
Yes. WebSockets and Secure WebSockets support is available natively and ready for use on an Application Load Balancer.


Q: Is Request tracing supported on an Application Load Balancer?
Yes. Request tracing is enabled by default on your Application Load Balancer.


Q: Will my existing load balancers (Classic Load Balancers) have the same features and benefits of an Application Load Balancer?
While there is some overlap, we do not plan to maintain feature parity between the two types of load balancers. Application Load Balancers are the foundation of our application layer load-balancing platform for the future.


Q: Can I configure my Amazon EC2 instances to accept traffic only from my Application Load Balancers?
Yes.


Q: Can I configure a security group for the front-end of an Application Load Balancer?
Yes.


Q: Can I use the existing APIs that I use with my Classic Load Balancer with an Application Load Balancer?
No. Application Load Balancers require a new set of APIs.


Q: How do I manage both Application and Classic Load Balancers simultaneously? 
The ELB Console will allow you to manage Application and Classic Load Balancers from the same interface. If you are using the CLI or an SDK, you will use a different ‘service’ for Application Load Balancers. For example, in the CLI you will describe your Classic Load Balancers using `aws elb describe-load-balancers` and your Application Load Balancers using `aws elbv2 describe-load-balancers`.


Q: Can I convert my Classic Load Balancer to an Application Load Balancer (and vice versa)?
No, you cannot convert one load balancer type into another.


Q: Can I migrate to Application Load Balancer from Classic Load Balancer?
Yes. You can migrate to Application Load Balancer from Classic Load Balancer using one of the options listed in this document.


Q: Can I use an Application Load Balancer as a Layer-4 load balancer?
No. If you need Layer-4 features, you should use Network Load Balancer.


Q: Can I use a single Application Load Balancer for handling HTTP and HTTPS requests?
Yes, you can add listeners for HTTP port 80 and HTTPS port 443 to a single Application Load Balancer.

Q: Can I get a history of Application Load Balancing API calls made on my account for security analysis and operational troubleshooting purposes?
Yes. To receive a history of Application Load Balancing API calls made on your account, use AWS CloudTrail.


Q: Does an Application Load Balancer support HTTPS termination?
Yes, you can terminate HTTPS connection on the Application Load Balancer. You must install an SSL certificate on your load balancer. The load balancer uses this certificate to terminate the connection and then decrypt requests from clients before sending them to targets.
Q: What are the steps to get a SSL certificate?
You can either use AWS Certificate Manager to provision an SSL/TLS certificate or you can obtain the certificate from other sources by creating the certificate request, getting the certificate request signed by a CA, and then uploading the certificate either using AWS Certification Manager or the AWS Identity and Access Management (IAM) service.


Q: How does an Application Load Balancer integrate with AWS Certificate Manager (ACM)?
An Application Load Balancer is integrated with AWS Certificate Management (ACM). Integration with ACM makes it very simple to bind a certificate to the load balancer thereby making the entire SSL offload process very easy. Purchasing, uploading, and renewing SSL/TLS certificates is a time-consuming manual and complex process. With ACM integration with Application Load Balancer, this whole process has been shortened to simply requesting a trusted SSL/TLS certificate and selecting the ACM certificate to provision it with the load balancer.


Q: Is back-end server authentication supported with an Application Load Balancer?
No, only encryption is supported to the back-ends with an Application Load Balancer.


Q: How can I enable Server Name Indication (SNI) for my Application Load Balancer?
SNI is automatically enabled when you associate more than one TLS certificate with the same secure listener on a load balancer. Similarly, SNI mode for a secure listener is automatically disabled when you have only one certificate associated to a secure listener.


Q: Can I associate multiple certificates for the same domain to a secure listener?
Yes, you can associate multiple certificates for the same domain to a secure listener. For example, you can asoociate
(a) ECDSA and RSA certificates
(b) Certificates with different key sizes (e.g. 2K and 4K) for SSL/TLS certificates
(c) Single-Domain, Multi-Domain (SAN) and Wildcard certificates


Q: Is IPv6 supported with an Application Load Balancer?
Yes, IPv6 is supported with an Application Load Balancer.


Q: How do you set up rules on an Application Load Balancer?
You can configure rules for each of your listeners you configure for the load balancer. The rules include a condition and a corresponding action if the condition is satisfied. The condition will be a path URL path of a service (e.g. /img) and action is forward. Once you have set this up, the load balancer will use the rules to determine the service to which the request must be routed.


Q: Are there limits on the resources for an Application Load Balancer?
Your AWS account has these limits for an Application Load Balancer.


Q. How can I protect my web applications behind a load balancer from web attacks?
You can integrate your Application Load Balancer with AWS WAF, a web application firewall that helps protect web applications from attacks by allowing you to configure rules based on IP addresses, HTTP headers, and custom URI strings. Using these rules, AWS WAF can block, allow, or monitor (count) web requests for your web application. Please see AWS WAF Developer Guide for more information.


Q: Can I load balance to any arbitrary IP address?
You can use any IP address from the load balancer’s VPC CIDR for targets within load balancer’s VPC and any IP address from RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16) or RFC 6598 range (100.64.0.0/10) for targets located outside the load balancer’s VPC (for example, targets in Peered VPC, EC2-Classic and on-premises locations reachable over AWS Direct Connect or VPN connection).


Q: How can I load balance applications distributed across a VPC and on-premises location?
There are various ways to achieve hybrid load balancing. If an application runs on targets distributed between a VPC and an on-premises location, you can add them to the same target group using their IP addresses. To migrate to AWS without impacting your application, gradually add VPC targets to the target group and remove on-premises targets from the target group. If you have two different applications such that the targets for one application are in a VPC and the targets for other applications are in on-premises location, you can put the VPC targets in one target group and the on-premises targets in another target group and use content based routing to route traffic to each target group. You can also use separate load balancers for VPC and on-premises targets and use DNS weighting to achieve weighted load balancing between VPC and on-premises targets.


Q: How can I load balance to EC2-Classic instances?
You cannot load balance to EC2-Classic Instances when registering their Instance IDs as targets. However if you link these EC2-Classic instances to the load balancer's VPC using ClassicLink and use the private IPs of these EC2-Classic instances as targets, then you can load balance to the EC2-Classic instances. If you are using EC2 Classic instances today with a Classic Load Balancer, you can easily migrate to an Application Load Balancer.


Q: How do I enable cross-zone load balancing in Application Load Balancer?
Cross-zone load balancing is already enabled by default in Application Load Balancer.


Q: When should I authenticate users using the Application Load Balancer’s integration with Amazon Cognito vs. the Application Load Balancers’ native support for OpenID Connect (IODC) identity providers (IdPs)?
You should use authentication through Amazon Cognito if:

a. You want to provide flexibility to your users to authenticate via social network identities (Google, Facebook, and Amazon) or enterprise identities (SAML) or via your own user directories provided by Amazon Cognito’s User Pool.

b. You are managing multiple identity providers including OpenID Connect and want to create a single authentication rule in ALB, that can use Amazon Cognito to federate your multiple identity providers.

c. You have a need to actively manage user profiles with one or more social or OpenID Connect identity providers from one central place. For example, you can put users in groups and add custom attributes to represent user status and control access for paid users.

Alternatively, if you have invested in developing custom IdP solutions and simply want to authenticate with a single identity provider that is OpenID Connect-compatible, you may prefer using Application Load Balancer’s native OIDC solution.


Q: What type of redirects does ALB support ?
The following three types of redirects are supported.

Types of redirects	Examples
HTTP to HTTP	http://hostA to http://hostB
HTTP to HTTPS	http://hostA to https://hostB https://hostA:portA/pathA to https://hostB:portB/pathB
HTTPS to HTTPS	https://hostA to https://hostB

Q: What content types does ALB support for the message body of fixed-response action ?
The following content types are supported: text/plain, text/css, text/html, application/javascript, application/json.

 Application Load Balancer pricing FAQ

Q: How does Application Load Balancer pricing work?
You are charged for each hour or partial hour that an Application Load Balancer is running and the number of Load Balancer Capacity Units (LCU) used per hour.


Q: What is a Load Balancer Capacity Unit (LCU)?
An LCU is a new metric for determining how you pay for an Application Load Balancer. An LCU defines the maximum resource consumed in any one of the dimensions (new connections, active connections, bandwidth and rule evaluations) the Application Load Balancer processes your traffic.


Q: Will I be billed on Classic Load Balancers by LCU?
No, Classic Load Balancers will continue to be billed for bandwidth and hourly usage.


Q: How do I know the number of LCUs an Application Load Balancer is using?
We expose the usage of all four dimensions that constitute an LCU via CloudWatch.


Q: Will I be billed on all the dimensions in an LCU?
No. The number of LCUs per hour will be determined based on maximum resource consumed amongst the four dimensions that constitutes a LCU.


Q: Will I be billed on partial LCUs?
Yes.


Q: Is a free tier offered on an Application Load Balancer for new AWS accounts?
Yes. For new AWS accounts, a free tier for an Application Load Balancer offers 750 hours and 15 LCUs. This free tier offer is only available to new AWS customers, and is available for 12 months following your AWS sign-up date.


Q: Can I use a combination of Application Load Balancer and Classic Load Balancer as part of my free tier?
Yes. You can use both Classic and Application Load Balancers for 15GB and 15 LCUs respectively. The 750 load balancer hours are shared between both Classic and Application Load Balancers.


Q: What are rule evaluations?
Rule evaluations are defined as the product of number of rules processed and the request rate averaged over an hour.


Q: Am I charged for regional AWS data-transfer when I enable cross-zone load balancing in Application Load Balancer?
No, you are not charged for regional data transfer between Availability Zones when you enable cross-zone load balancing for your Application Load Balancer.


Q: Is user authentication in Application Load Balancer charged separately?
No. There is no separate charge for enabling the authentication functionality in Application Load Balancer. When using Amazon Cognito with Application Load Balancer, Amazon Cognito pricing will apply

Elastic Load Balancing FAQ

Q: How do I decide which load balancer to select for my application?
Elastic Load Balancing supports three types of load balancers. You can select the appropriate load balancer based on your application needs. If you need flexible application management and TLS termination then we recommend you to use Application Load Balancer. If extreme performance and static IP is needed for your application then we recommend you to use Network Load Balancer. If your application is built within the EC2 Classic network then you should use Classic Load Balancer.


Q: Can I privately access Elastic Load Balancing APIs from my Amazon Virtual Private Cloud (VPC) without using public IPs?
Yes, you can privately access Elastic Load Balancing APIs from your Amazon Virtual Private Cloud (VPC) by creating VPC Endpoints. With VPC Endpoints, the routing between the VPC and Elastic Load Balancing APIs is handled by the AWS network without the need for an Internet gateway, NAT gateway, or VPN connection. The latest generation of VPC Endpoints used by Elastic Load Balancing are powered by AWS PrivateLink, an AWS technology enabling the private connectivity between AWS services using Elastic Network Interfaces (ENI) with private IPs in your VPCs. To learn more about AWS PrivateLink, visit the AWS PrivateLink documentation.

AWS EC2 Auto Scaling FAQ

Amazon EC2 Auto Scaling

Q: Can I automatically scale my Amazon EC2 fleets?

Yes. Amazon EC2 Auto Scaling is a fully managed service designed to launch or terminate Amazon EC2 instances automatically to help ensure you have the correct number of Amazon EC2 instances available to handle the load for your application. EC2 Auto Scaling helps you maintain application availability through fleet management for EC2 instances, which detects and replaces unhealthy instances, and by scaling your Amazon EC2 capacity up or down automatically according to conditions you define. You can use EC2 Auto Scaling to automatically increase the number of Amazon EC2 instances during demand spikes to maintain performance and decrease capacity during lulls to reduce costs. For more information see the Amazon EC2 Auto Scaling FAQ.

Q: What is Amazon EC2 Auto Scaling?

Amazon EC2 Auto Scaling is a fully managed service designed to launch or terminate Amazon EC2 instances automatically to help ensure you have the correct number of Amazon EC2 instances available to handle the load for your application. Amazon EC2 Auto Scaling helps you maintain application availability through fleet management for EC2 instances, which detects and replaces unhealthy instances, and by scaling your Amazon EC2 capacity up or down automatically according to conditions you define. You can use Amazon EC2 Auto Scaling to automatically increase the number of Amazon EC2 instances during demand spikes to maintain performance and decrease capacity during lulls to reduce costs.

Q. When should I use Amazon EC2 Auto Scaling vs. AWS Auto Scaling?

You should use AWS Auto Scaling if you want more guidance on defining your application scaling plan, or if you want to scale multiple resources beyond EC2, such as Amazon DynamoDB tables and indexes, or Amazon ECS tasks. At this time, to use AWS Auto Scaling, you must create your applications via AWS CloudFormation or AWS Elastic Beanstalk. AWS Auto Scaling helps you manage all your scaling policies in one place for your applications making tuning easy and intuitive.

You should use Amazon EC2 Auto Scaling if you only need to scale Amazon EC2 Auto Scaling Groups, or just want to maintain the health of your EC2 fleet.

Q: What are the benefits of using Amazon EC2 Auto Scaling?

Amazon EC2 Auto Scaling helps to maintain your Amazon EC2 instance availability. Whether you are running one Amazon EC2 instance or thousands, you can use Amazon EC2 Auto Scaling to detect impaired Amazon EC2 instances, and replace the instances without intervention. This ensures that your application has the compute capacity that you expect. You can use Amazon EC2 Auto Scaling to automatically scale your Amazon EC2 fleet by following the demand curve for your applications, reducing the need to manually provision Amazon EC2 capacity in advance. For example, you can set a condition to add new Amazon EC2 instances in increments to the Auto Scaling group when the average utilization of your Amazon EC2 fleet is high; and similarly, you can set a condition to remove instances in increments when CPU utilization is low. You can also use Amazon CloudWatch to send alarms to trigger scaling activities and Elastic Load Balancing (ELB) to distribute traffic to your instances within Amazon EC2 Auto Scaling groups. If you have predictable load changes, you can set a schedule through Amazon EC2 Auto Scaling to plan your scaling activities. Amazon EC2 Auto Scaling enables you to run your Amazon EC2 fleet at optimal utilization.

Q: What is fleet management and how is it different from dynamic scaling?

If your application runs on Amazon EC2 instances, then you have what’s referred to as a ‘fleet’. Fleet management refers to the functionality that automatically replaces unhealthy instances and maintains your fleet at the desired capacity. Amazon EC2 Auto Scaling fleet management ensures that your application is able to receive traffic and that the instances themselves are working properly. When Auto Scaling detects a failed health check, it can replace the instance automatically.

The dynamic scaling capabilities of Amazon EC2 Auto Scaling refers to the functionality that automatically increases or decreases capacity based on load or other metrics. For example, if your CPU spikes above 80% (and you have an alarm setup) Amazon EC2 Auto Scaling can add a new instance dynamically.

Q: What is target tracking?

Target tracking is a new type of scaling policy that you can use to set up dynamic scaling for your application in just a few simple steps. With target tracking, you select a load metric for your application, such as CPU utilization or request count, set the target value, and Amazon EC2 Auto Scaling adjusts the number of EC2 instances in your EC2 Auto Scaling group as needed to maintain that target. It acts like a home thermostat, automatically adjusting the system to keep the environment at your desired temperature. For example, you can configure target tracking to keep CPU utilization for your fleet of web servers at 50%. From there, Amazon EC2 Auto Scaling launches or terminates EC2 instances as required to keep the average CPU utilization at 50%.

Q: What is an EC2 Auto Scaling group?

An Amazon EC2 Auto Scaling group contains a collection of EC2 instances that share similar characteristics and are treated as a logical grouping for the purposes of fleet management and dynamic scaling. For example, if a single application operates across multiple instances, you might want to increase the number of instances in that group to improve the performance of the application, or decrease the number of instances to reduce costs when demand is low. Amazon EC2 Auto Scaling will automaticallly adjust the number of instances in the group to maintain a fixed number of instances even if a instance becomes unhealthy, or based on criteria that you specify. You can find more information about Amazon EC2 Auto Scaling groups in the Amazon EC2 Auto Scaling User Guide.

Q: What happens to my Amazon EC2 instances if I delete my EC2 Auto Scaling Group?

If you have an EC2 Auto Scaling group with running instances and you choose to delete the Amazon EC2 Auto Scaling group, the instances will be terminated and the EC2 Auto Scaling group will be deleted.

Q: How do I know when EC2 Auto Scaling is launching or terminating the EC2 instances in an EC2 Auto Scaling group?

When you use Amazon EC2 Auto Scaling to scale your applications automatically, it is useful to know when EC2 Auto Scaling is launching or terminating the EC2 instances in your EC2 Auto Scaling group. Amazon SNS coordinates and manages the delivery or sending of notifications to subscribing clients or endpoints. You can configure EC2 Auto Scaling to send an SNS notification whenever your EC2 Auto Scaling group scales. Amazon SNS can deliver notifications as HTTP or HTTPS POST, email (SMTP, either plain-text or in JSON format), or as a message posted to an Amazon SQS queue. For example, if you configure your EC2 Auto Scaling group to use the autoscaling: EC2_INSTANCE_TERMINATE notification type, and your EC2 Auto Scaling group terminates an instance, it sends an email notification. This email contains the details of the terminated instance, such as the instance ID and the reason that the instance was terminated.

For more information read Getting SNS Notifications when your EC2 Auto Scaling Group Scales.

Q: What is a launch configuration?

A launch configuration is a template that an EC2 Auto Scaling group uses to launch EC2 instances. When you create a launch configuration, you specify information for the instances such as the ID of the Amazon Machine Image (AMI), the instance type, a key pair, one or more security groups, and a block device mapping. If you've launched an EC2 instance before, you specified the same information in order to launch the instance. When you create an EC2 Auto Scaling group, you must specify a launch configuration. You can specify your launch configuration with multiple EC2 Auto Scaling groups. However, you can only specify one launch configuration for an EC2 Auto Scaling group at a time, and you can't modify a launch configuration after you've created it. Therefore, if you want to change the launch configuration for your EC2 Auto Scaling group, you must create a launch configuration and then update your EC2 Auto Scaling group with the new launch configuration. When you change the launch configuration for your EC2 Auto Scaling group, any new instances are launched using the new configuration parameters, but existing instances are not affected. You can see the launch configurations section of the EC2 Auto Scaling User Guide for more details.

Q: How many instances can an EC2 Auto Scaling group have?

You can have as many instances in your EC2 Auto Scaling group as your EC2 quota allows.

Q: What happens if a scaling activity causes me to reach my Amazon EC2 limit of instances?

Amazon EC2 Auto Scaling cannot scale past the Amazon EC2 limit of instances that you can run. If you need more Amazon EC2 instances, complete the Amazon EC2 instance request form.

Q: Can EC2 Auto Scaling groups span multiple AWS regions?

EC2 Auto Scaling groups are regional constructs. They can span Availability Zones, but not AWS regions.

Q: Can I launch different types of EC2 instances in same EC2 Auto Scaling group?

EC2 Auto Scaling groups optimize for the case when all your instance types are the same. You can use the AttachInstances API to attach instances of different types to an Auto Scaling group, and you can also update your launch configuration so that any new instances in the group will be launched with a different instance type. However, this will not affect any of the existing instances.

Q: How can I implement changes across multiple instances in an EC2 Auto Scaling group?

You can use AWS CodeDeploy or CloudFormation to orchestrate code changes to multiple instances in your EC2 Auto Scaling group.

Q: If I have data installed in an EC2 Auto Scaling group, and a new instance is dynamically created later, is the data copied over to the new instances?

Data is not automatically copied from existing instances to new instances. You can use lifecycle hooks to copy the data, or an Amazon RDS database including replicas.

Q: When I create an EC2 Auto Scaling group from an existing instance, does it create a new AMI (Amazon Machine Image)?

When you create an Auto Scaling group from an existing instance, it does not create a new AMI. For more information see Creating an Auto Scaling Group Using an EC2 Instance.

Q: How does Amazon EC2 Auto Scaling balance capacity?

Balancing resources across Availability Zones is a best practice for well-architected applications, as this greatly increases aggregate system availability. Amazon EC2 Auto Scaling automatically balances EC2 instances across zones when you configure multiple zones in your EC2 Auto Scaling group settings. Amazon EC2 Auto Scaling always launches new instances such that they are balanced between zones as evenly as possible across the entire fleet. What’s more, Amazon EC2 Auto Scaling only launches into Availability Zones in which there is available capacity for the requested instance type.

Q: What are lifecycle hooks?

Lifecycle hooks let you take action before an instance goes into service or before it gets terminated. This can be especially useful if you are not baking your software environment into an Amazon Machine Image (AMI). For example, launch hooks can perform software configuration on an instance to ensure that it’s fully prepared to handle traffic before Amazon EC2 Auto Scaling proceeds to connect it to your load balancer. One way to do this is by connecting the launch hook to an AWS Lambda function that invokes RunCommand on the instance. Terminate hooks can be useful for collecting important data from an instance before it goes away. For example, you could use a terminate hook to preserve your fleet’s log files by copying them to an Amazon S3 bucket when instances go out of service.

Visit lifecycle hooks in our Amazon EC2 Auto Scaling User Guide for more information.

Q: What are the characteristics of an “unhealthy” instance?

An unhealthy instance is one where the hardware has become impaired for some reason (bad disk, etc.), or it is not passing a user-configured ELB health check. Amazon EC2 Auto Scaling performs health checks on each individual EC2 instance at regular intervals, and if the instance is connected to an Elastic Load Balancing load balancer, it can also perform ELB health checks.

Q: Can I customize a health check?

Yes, there is an API called SetInstanceHealth that allows you to change an instance's state to UNHEALTHY, which will then result in a termination and replacement.

Q: Can I suspend health checks (for example, to evaluate unhealthy instances)?

Yes, you can temporarily suspend Amazon EC2 Auto Scaling health checks by using the SuspendProcesses API. You can use the ResumeProcesses API to resume automatic health checks.

Q: Which health check type should I select?

If you are using Elastic Load Balancing (ELB) with your group, you should select an ELB health check. If you’re not using ELB with your group, you should select the EC2 health check.

Q: Can I use Amazon EC2 Auto Scaling for health checks and to replace unhealthy instances if I’m not using Elastic Load Balancing (ELB)?

You don't have to use ELB to use Auto Scaling. You can use the EC2 health check to identify and replace unhealthy instances.

Q: Do the Elastic Load Balancing (ELB) health checks work with Application Load Balancers and Network Load Balancers? Will an instance be marked as unhealthy if any target group associated with it becomes unhealthy?

Yes, Amazon EC2 Auto Scaling works with Application Load Balancers and Network Load Balancers including their health check feature.

Q: Is there any way to use Amazon EC2 Auto Scaling to only add a volume without adding an instance?

A volume is attached to a new instance when it is added. Amazon EC2 Auto Scaling doesn't automatically add a volume when the existing one is approaching capacity. You can use the EC2 API to add a volume to an existing instance.

Q: What does the term “stateful instances” refer to?

When we refer to a stateful instance, we mean an instance that has data on it, which exists only on that instance. In general, terminating a stateful instance means that the data (or state information) on the instance is lost. You may want to consider using lifecycle hooks to copy the data off of a stateful instance before it’s terminated, or enable instance protection to prevent Amazon EC2 Auto Scaling from terminating it.