Amazon Aurora DB Instance Accessibility Amazon Comprehend Endpoint Access Risk Amazon EBS Snapshots Amazon EC2 Availability Zone Balance AWS CloudHSM clusters running HSM instances in a single AZ Amazon ElastiCache Multi-AZ clusters Amazon MemoryDB Multi-AZ clusters Amazon RDS Backups Amazon RDS Multi-AZ AWS Resilience Hub policy breached AWS Resilience Hub resilience scores Amazon Route 53 Deleted Health Checks Amazon Route 53 Failover Resource Record Sets Amazon Route 53 High TTL Resource Record Sets Amazon Route 53 Name Server Delegations Amazon S3 Bucket Logging Amazon S3 Bucket Versioning Auto Scaling Group Health Check Auto Scaling Group Resources AWS Direct Connect Connection Redundancy AWS Direct Connect Location Redundancy AWS Direct Connect Virtual Interface Redundancy AWS Lambda VPC-enabled Functions without Multi-AZ Redundancy AWS Well-Architected high risk issues for reliability ELB Connection Draining ELB Cross-Zone Load Balancing Load Balancer Optimization VPN Tunnel Redundancy

Fault tolerance

You can use the following checks for the fault tolerance category.

Check names

Amazon Aurora DB Instance Accessibility

Description

Checks for cases where an Amazon Aurora DB cluster has both private and public instances.

When your primary instance fails, a replica can be promoted to a primary instance. If that replica is private, users who have only public access would no longer be able to connect to the database after failover. We recommend that all the DB instances in a cluster have the same accessibility.

Check ID

xuy7H1avtl

Alert Criteria

Yellow: The instances in an Aurora DB cluster have different accessibility (a mix of public and private).

Recommended Action

Modify the Publicly Accessible setting of the instances in the DB cluster so that they are all either public or private. For details, see the instructions for MySQL instances at Modifying a DB Instance Running the MySQL Database Engine.

Additional Resources

Fault Tolerance for an Aurora DB Cluster

Report columns

Status
Region
Cluster
Public DB Instances
Private DB Instances
Reason

Amazon Comprehend Endpoint Access Risk

Description

Checks the AWS Key Management Service (AWS KMS) key permissions for an endpoint where the underlying model was encrypted by using customer managed keys. If the customer managed key is disabled, or the key policy was changed to alter the allowed permissions for Amazon Comprehend, the endpoint availability might be affected.

Note

Results for this check are automatically refreshed several times daily, and refresh requests are not allowed. It might take a few hours for changes to appear. Currently, you can’t exclude resources from this check.

Check ID

Cm24dfsM13

Alert Criteria

Red: The customer managed key is disabled or the key policy was changed to alter the allowed permissions for Amazon Comprehend access.

Recommended Action

If the customer managed key was disabled, we recommend that you enable it. For more information, see Enabling keys. If the key policy was altered and you want to keep using the endpoint, we recommend that you update the AWS KMS key policy. For more information, see Changing a key policy.

Additional Resources

AWS KMS Key Encryption Permissions

Report columns

Status
Region
Endpoint ARN
Model ARN
KMS KeyId
Last Updated Time

Amazon EBS Snapshots

Description

Checks the age of the snapshots for your Amazon Elastic Block Store (Amazon EBS) volumes (either available or in-use).

Even though Amazon EBS volumes are replicated, failures can occur. Snapshots are persisted to Amazon Simple Storage Service (Amazon S3) for durable storage and point-in-time recovery.

Check ID

H7IgTzjTYb

Alert Criteria

Yellow: The most recent volume snapshot is between 7 and 30 days old.
Red: The most recent volume snapshot is more than 30 days old.
Red: The volume does not have a snapshot.

Recommended Action

Create weekly or monthly snapshots of your volumes. For more information, see Creating an Amazon EBS Snapshot.

Additional Resources

Amazon Elastic Block Store (Amazon EBS)

Report columns

Status
Region
Volume ID
Volume Name
Snapshot ID
Snapshot Name
Snapshot Age
Volume Attachment
Reason

Amazon EC2 Availability Zone Balance

Description

Checks the distribution of Amazon Elastic Compute Cloud (Amazon EC2) instances across Availability Zones in a Region.

Availability Zones are distinct locations that are insulated from failures in other Availability Zones. This allows inexpensive, low-latency network connectivity between Availability Zones in the same Region. By launching instances in multiple Availability Zones in the same Region, you can help protect your applications from a single point of failure.

Check ID

wuy7G1zxql

Alert Criteria

Yellow: The Region has instances in multiple zones, but the distribution is uneven (the difference between the highest and lowest instance counts in utilized Availability Zones is greater than 20%).
Red: The Region has instances only in a single Availability Zone.

Recommended Action

Balance your Amazon EC2 instances evenly across multiple Availability Zones. You can do this by launching instances manually or by using Auto Scaling to do it automatically. For more information, see Launch Your Instance and Load Balance Your Auto Scaling Group.

Additional Resources

Amazon EC2 Auto Scaling User Guide

Report columns

Status
Region
Zone a Instances
Zone b Instances
Zone c Instances
Zone e Instances
Zone f Instances
Reason

AWS CloudHSM clusters running HSM instances in a single AZ

Description

Checks your clusters that run HSM instances in a single Availability Zone (AZ). This check alerts you if your clusters are at risk of not having the most recent backup.

Check ID

hc0dfs7601

Alert Criteria

Yellow: A CloudHSM cluster is running all HSM instances in a single Availability Zone for more than 1 hour.
Green: A CloudHSM cluster is running all HSM instances in at least two different Availability Zones.

Recommended Action

Create at least one more instance for the cluster in a different Availability Zone.

Additional Resources

Best practices for AWS CloudHSM

Report columns

Status
Region
Cluster ID
Number of HSM Instances
Last Updated Time

Amazon ElastiCache Multi-AZ clusters

Description

Checks for ElastiCache clusters that deploy in a single Availability Zone (AZ). This check alerts you if Multi-AZ is inactive in a cluster.

Deployments in multiple AZs enhance ElastiCache cluster availability by asynchronously replicating to read-only replicas in a different AZ. When planned cluster maintenance occurs, or a primary node is unavailable, ElastiCache automatically promotes a replica to primary. This failover allows cluster write operations to resume, and doesn't require an administrator to intervene.

Check ID

ECHdfsQ402

Alert Criteria

Green: Multi-AZ is active in the cluster.
Yellow: Multi-AZ is inactive in the cluster.

Recommended Action

Create at least one replica per shard, in an AZ that is different than the primary.

Additional Resources

For more information, see Minimizing downtime in ElastiCache for Redis with Multi-AZ.

Report columns

Status
Region
Cluster Name
Last Updated Time

Amazon MemoryDB Multi-AZ clusters

Description

Checks for MemoryDB clusters that deploy in a single Availability Zone (AZ). This check alerts you if Multi-AZ is inactive in a cluster.

Deployments in multiple AZs enhance MemoryDB cluster availability by asynchronously replicating to read-only replicas in a different AZ. When planned cluster maintenance occurs, or a primary node is unavailable, MemoryDB automatically promotes a replica to primary. This failover allows cluster write operations to resume, and doesn't require an administrator to intervene.

Check ID

MDBdfsQ401

Alert Criteria

Green: Multi-AZ is active in the cluster.
Yellow: Multi-AZ is inactive in the cluster.

Recommended Action

Create at least one replica per shard, in an AZ that is different than the primary.

Additional Resources

For more information, see Minimizing downtime in MemoryDB with Multi-AZ.

Report columns

Status
Region
Cluster Name
Last Updated Time

Amazon RDS Backups

Description

Checks for automated backups of Amazon RDS DB instances.

By default, backups are enabled with a retention period of one day. Backups reduce the risk of unexpected data loss and allow for point-in-time recovery.

Check ID

opQPADkZvH

Alert Criteria

Red: A DB instance has the backup retention period set to 0 days.

Recommended Action

Set the retention period for the automated DB instance backup to 1 to 35 days as appropriate to the requirements of your application. See Working With Automated Backups.

Additional Resources

Getting Started with Amazon RDS

Report columns

Status
Region/AZ
DB Instance
VPC ID
Backup Retention Period

Amazon RDS Multi-AZ

Description

Checks for DB instances that are deployed in a single Availability Zone (AZ).

Multi-AZ deployments enhance database availability by synchronously replicating to a standby instance in a different Availability Zone. During planned database maintenance, or the failure of a DB instance or Availability Zone, Amazon RDS automatically fails over to the standby. This failover allows database operations to resume quickly without administrative intervention. Because Amazon RDS does not support Multi-AZ deployment for Microsoft SQL Server, this check does not examine SQL Server instances.

Check ID

f2iK5R6Dep

Alert Criteria

Yellow: A DB instance is deployed in a single Availability Zone.

Recommended Action

If your application requires high availability, modify your DB instance to enable Multi-AZ deployment. See High Availability (Multi-AZ).

Additional Resources

Regions and Availability Zones

Report columns

Status
Region/AZ
DB Instance
VPC ID
Multi-AZ

AWS Resilience Hub policy breached

Description

Checks Resilience Hub for applications that don't meet the recovery time objective (RTO) and recovery point objective (RPO) that the policy defines. The check alerts you if your application doesn't meet the RTO and RPO objectives you've set for an application in Resilience Hub.

Note

Results for this check are automatically refreshed, and refresh requests are not allowed. Currently, you can’t exclude resources from this check.

Check ID

RH23stmM02

Alert Criteria

Green: The application has a policy and meets the RTO and RPO objectives.
Yellow: The application hasn't been assessed yet.
Red: The application has a policy but doesn’t meet the RTO and RPO objectives.

Recommended Action

Sign in to the Resilience Hub console and review the recommendations so that your application meets the RTO and RPO objectives.

Additional Resources

Resilience Hub concepts

Report columns

Status
Region
Application Name
Last Updated Time

AWS Resilience Hub resilience scores

Description

Checks if you have run an assessment for your applications in Resilience Hub. This check alerts you if your resilience scores are below a specific value.

Note

Results for this check are automatically refreshed, and refresh requests are not allowed. Currently, you can’t exclude resources from this check.

Check ID

RH23stmM01

Alert Criteria

Green: Your application has a resilience score of 70 or greater.
Yellow: Your application has a resilience score of 40 through 69.
Yellow: The application hasn't been assessed yet.
Red: Your application has a resilience score of less than 40.

Recommended Action

Sign in to the Resilience Hub console and run an assessment for your application. Review the recommendations to improve the resilience score.

Additional Resources

Resilience Hub concepts

Report columns

Status
Region
Application Name
Application Resilience Score
Last Updated Time

Amazon Route 53 Deleted Health Checks

Description

Checks for resource record sets that are associated with health checks that have been deleted.

Route 53 does not prevent you from deleting a health check that is associated with one or more resource record sets. If you delete a health check without updating the associated resource record sets, the routing of DNS queries for your DNS failover configuration will not work as intended.

Hosted zones created by AWS services won't appear in your check results.

Check ID

Cb877eB72b

Alert Criteria

Yellow: A resource record set is associated with a health check that has been deleted.

Recommended Action

Create a new health check and associate it with the resource record set. See Creating, Updating, and Deleting Health Checks and Adding Health Checks to Resource Record Sets.

Additional Resources

Report columns

Hosted Zone Name
Hosted Zone ID
Resource Record Set Name
Resource Record Set Type
Resource Record Set Identifier

Amazon Route 53 Failover Resource Record Sets

Description

Checks for Amazon Route 53 failover resource record sets that have a misconfiguration.

When Amazon Route 53 health checks determine that the primary resource is unhealthy, Amazon Route 53 responds to queries with a secondary, backup resource record set. You must create correctly configured primary and secondary resource record sets for failover to work.

Hosted zones created by AWS services won't appear in your check results.

Check ID

b73EEdD790

Alert Criteria

Yellow: A primary failover resource record set does not have a corresponding secondary resource record set.
Yellow: A secondary failover resource record set does not have a corresponding primary resource record set.
Yellow: Primary and secondary resource record sets that have the same name are associated with the same health check.

Recommended Action

If a failover resource set is missing, create the corresponding resource record set. See Creating Failover Resource Record Sets.

If your resource record sets are associated with the same health check, create separate health checks for each one. See Creating, Updating, and Deleting Health Checks.

Additional Resources

Amazon Route 53 Health Checks and DNS Failover

Report columns

Hosted Zone Name
Hosted Zone ID
Resource Record Set Name
Resource Record Set Type
Reason

Amazon Route 53 High TTL Resource Record Sets

Description

Checks for resource record sets that can benefit from having a lower time-to-live (TTL) value.

TTL is the number of seconds that a resource record set is cached by DNS resolvers. When you specify a long TTL, DNS resolvers take longer to request updated DNS records, which can cause unnecessary delay in rerouting traffic. For example, a long TTL creates a delay between when DNS Failover detects an endpoint failure, and when it responds by rerouting traffic.

Hosted zones created by AWS services won't appear in your check results.

Check ID

C056F80cR3

Alert Criteria

Yellow: A resource record set whose routing policy is Failover has a TTL greater than 60 seconds.
Yellow: A resource record set with an associated health check has a TTL greater than 60 seconds.

Recommended Action

Enter a TTL value of 60 seconds for the listed resource record sets. For more information, see Working with Resource Record Sets.

Additional Resources

Amazon Route 53 Health Checks and DNS Failover

Report columns

Status
Hosted Zone Name
Hosted Zone ID
Resource Record Set Name
Resource Record Set Type
Resource Record Set ID
TTL

Amazon Route 53 Name Server Delegations

Description

Checks for Amazon Route 53 hosted zones for which your domain registrar or DNS is not using the correct Route 53 name servers.

When you create a hosted zone, Route 53 assigns a delegation set of four name servers. The names of these servers are ns-###.awsdns-##.com, .net, .org, and .co.uk, where ### and ## typically represent different numbers. Before Route 53 can route DNS queries for your domain, you must update your registrar's name server configuration to remove the name servers that the registrar assigned. Then, you must add all four name servers in the Route 53 delegation set. For maximum availability, you must add all four Route 53 name servers.

Hosted zones created by AWS services won't appear in your check results.

Check ID

cF171Db240

Alert Criteria

Yellow: A hosted zone for which the registrar for your domain does not use all four of the Route 53 name servers in the delegation set.

Recommended Action

Add or update name server records with your registrar or with the current DNS service for your domain to include all four of the name servers in your Route 53 delegation set. To find these values, see Getting the Name Servers for a Hosted Zone. For information about adding or updating name server records, see Creating and Migrating Domains and Subdomains to Amazon Route 53.

Additional Resources

Working with Hosted Zones

Report columns

Hosted Zone Name
Hosted Zone ID
Number of Name Server Delegations Used

Amazon S3 Bucket Logging

Description

Checks the logging configuration of Amazon Simple Storage Service (Amazon S3) buckets.

When server access logging is enabled, detailed access logs are delivered hourly to a bucket that you choose. An access log record contains details about each request, such as the request type, the resources specified in the request, and the time and date the request was processed. By default, bucket logging is not enabled. You should enable logging if you want to perform security audits or learn more about users and usage patterns.

When logging is initially enabled, the configuration is automatically validated. However, future modifications can result in logging failures. This check examines explicit Amazon S3 bucket permissions, but it does not examine associated bucket policies that might override the bucket permissions.

Check ID

BueAdJ7NrP

Alert Criteria

Yellow: The bucket does not have server access logging enabled.
Yellow: The target bucket permissions do not include the root account, so Trusted Advisor cannot check it.
Red: The target bucket does not exist.
Red: The target bucket and the source bucket have different owners.
Red: The log deliverer does not have write permissions for the target bucket.

Recommended Action

Enable bucket logging for most buckets. See Enabling Logging Using the Console and Enabling Logging Programmatically.

If the target bucket permissions do not include the root account and you want Trusted Advisor to check the logging status, add the root account as a grantee. See Editing Bucket Permissions.

If the target bucket does not exist, select an existing bucket as a target or create a new one and select it. See Managing Bucket Logging.

If the target and source have different owners, change the target bucket to one that has the same owner as the source bucket. See Managing Bucket Logging.

If the log deliverer does not have write permissions for the target (write not enabled), grant Upload/Delete permissions to the Log Delivery group. See Editing Bucket Permissions.

Additional Resources

Report columns

Status
Region
Bucket Name
Target Name
Target Exists
Same Owner
Write Enabled
Reason

Amazon S3 Bucket Versioning

Description

Checks for Amazon Simple Storage Service buckets that do not have versioning enabled, or that have versioning suspended.

When versioning is enabled, you can easily recover from both unintended user actions and application failures. Versioning allows you to preserve, retrieve, and restore any version of any object stored in a bucket. You can use lifecycle rules to manage all versions of your objects, as well as their associated costs, by automatically archiving objects to the Glacier storage class. Rules can also be configured to remove versions of your objects after a specified period of time. You can also require multi-factor authentication (MFA) for any object deletions or configuration changes to your buckets.

Versioning can't be deactivated after it has been enabled. However, it can be suspended, which prevents new versions of objects from being created. Using versioning can increase your costs for Amazon S3, because you pay for storage of multiple versions of an object.

Check ID

R365s2Qddf

Alert Criteria

Green: Versioning is enabled for the bucket.
Yellow: Versioning is not enabled for the bucket.
Yellow: Versioning is suspended for the bucket.

Recommended Action

Enable bucket versioning on most buckets to prevent accidental deletion or overwriting. See Using Versioning and Enabling Versioning Programmatically.

If bucket versioning is suspended, consider re-enabling versioning. For information on working with objects in a versioning-suspended bucket, see Managing Objects in a Versioning-Suspended Bucket.

When versioning is enabled or suspended, you can define lifecycle configuration rules to mark certain object versions as expired or to permanently remove unneeded object versions. For more information, see Object Lifecycle Management.

MFA Delete requires additional authentication when the versioning status of the bucket is changed or when versions of an object are deleted. It requires the user to enter credentials and a code from an approved authentication device. For more information, see MFA Delete.

Additional Resources

Working with Buckets

Report columns

Status
Region
Bucket Name
Versioning
MFA Delete Enabled

Auto Scaling Group Health Check

Description

Examines the health check configuration for Auto Scaling groups.

If Elastic Load Balancing is being used for an Auto Scaling group, the recommended configuration is to enable an Elastic Load Balancing health check. If an Elastic Load Balancing health check is not used, Auto Scaling can only act upon the health of the Amazon Elastic Compute Cloud (Amazon EC2) instance. Auto Scaling will not act on the application running on the instance.

Check ID

CLOG40CDO8

Alert Criteria

Yellow: An Auto Scaling group has an associated load balancer, but the Elastic Load Balancing health check is not enabled.
Yellow: An Auto Scaling group does not have an associated load balancer, but the Elastic Load Balancing health check is enabled.

Recommended Action

If the Auto Scaling group has an associated load balancer, but the Elastic Load Balancing health check is not enabled, see Add an Elastic Load Balancing Health Check to your Auto Scaling Group.

If the Elastic Load Balancing health check is enabled, but no load balancer is associated with the Auto Scaling group, see Set Up an Auto-Scaled and Load-Balanced Application.

Additional Resources

Amazon EC2 Auto Scaling User Guide

Report columns

Status
Region
Auto Scaling Group Name
Load Balancer Associated
Health Check

Auto Scaling Group Resources

Description

Checks the availability of resources associated with launch configurations and your Auto Scaling groups.

Auto Scaling groups that point to unavailable resources cannot launch new Amazon Elastic Compute Cloud (Amazon EC2) instances. When properly configured, Auto Scaling causes the number of Amazon EC2 instances to increase seamlessly during demand spikes, and decrease automatically during demand lulls. Auto Scaling groups and launch configurations that point to unavailable resources do not operate as intended.

Check ID

8CNsSllI5v

Alert Criteria

Red: An Auto Scaling group is associated with a deleted load balancer.
Red: A launch configuration is associated with a deleted Amazon Machine Image (AMI).

Recommended Action

If the load balancer has been deleted, either create a new load balancer and then create a new Auto Scaling group with the new load balancer, or create a new Auto Scaling group without the load balancer. For information about creating a new Auto Scaling group with a new load balancer, see Set Up an Auto-Scaled and Load-Balanced Application. For information about creating a new Auto Scaling group without a load balancer, see Create Auto Scaling Group in Getting Started With Auto Scaling Using the Console.

If the AMI has been deleted, create a new launch configuration using a valid AMI and associate it with an Auto Scaling group. See Create Launch Configuration in Getting Started With Auto Scaling Using the Console.

Additional Resources

Report columns

Status
Region
Auto Scaling Group Name
Launch Type
Resource Type
Resource Name

AWS Direct Connect Connection Redundancy

Description

Checks for AWS Regions that have only one AWS Direct Connect connection. Connectivity to your AWS resources should have two Direct Connect connections configured at all times to provide redundancy in case a device is unavailable.

Note

Results for this check are automatically refreshed several times daily, and refresh requests are not allowed. It might take a few hours for changes to appear.

Check ID

0t121N1Ty3

Alert Criteria

Yellow: The AWS Region has only one AWS Direct Connect connection.

Recommended Action

Configure an additional Direct Connect connection in this AWS Region to protect against device unavailability. For more information, see Configure Redundant Connections with AWS Direct Connect. To protect against site unavailability and add location redundancy, configure the additional Direct Connect connection to a different Direct Connect location.

Additional Resources

Report columns

Status
Region
Time Stamp
Location
Connection ID

AWS Direct Connect Location Redundancy

Description

Checks for AWS Regions with one or more AWS Direct Connect connections and only one AWS Direct Connect location. Connectivity to your AWS resources should have Direct Connect connections configured to different Direct Connect locations to provide redundancy in case a location is unavailable.

Note

Results for this check are automatically refreshed several times daily, and refresh requests are not allowed. It might take a few hours for changes to appear.

Check ID

8M012Ph3U5

Alert Criteria

Yellow: The Direct Connect connections in the AWS Region are not configured to different locations.

Recommended Action

Configure a Direct Connect connection that uses a different Direct Connect location to protect against location unavailability. For more information, see Getting Started with AWS Direct Connect.

Additional Resources

Report columns

Status
Region
Time Stamp
Location
Connection Details

AWS Direct Connect Virtual Interface Redundancy

Description

Checks for virtual private gateways with AWS Direct Connect virtual interfaces (VIFs) that are not configured on at least two AWS Direct Connect connections. Connectivity to your virtual private gateway should have multiple VIFs configured across multiple Direct Connect connections and locations. This provides redundancy in case that a device or location is unavailable.

Note

Results for this check are automatically refreshed several times daily, and refresh requests are not allowed. It might take a few hours for changes to appear.

Check ID

4g3Nt5M1Th

Alert Criteria

Yellow: A virtual private gateway has less than two virtual interfaces, or the interfaces are not configured to multiple Direct Connect connections.

Recommended Action

Configure at least two virtual interfaces that are configured to two Direct Connect connections to protect against device or location unavailability. See Create a Virtual Interface.

Additional Resources

Report columns

Status
Region
Time Stamp
Gateway ID
Location for VIF
Connection ID for VIF

AWS Lambda VPC-enabled Functions without Multi-AZ Redundancy

Description

Checks for VPC-enabled Lambda functions that are vulnerable to service interruption in a single Availability Zone. It is recommended for VPC-enabled functions to be connected to multiple Availability Zones for high availability.

Note

Check ID

L4dfs2Q4C6

Alert Criteria

Yellow: A VPC-enabled Lambda function connected to subnets in a single Availability Zone.

Recommended Action

When configuring functions for access to your VPC, choose subnets in multiple Availability Zones to ensure high availability.

Additional Resources

Report columns

Status
Region
Function ARN
VPC ID
Average daily Invokes
Last Updated Time

AWS Well-Architected high risk issues for reliability

Description

Checks for high risk issues (HRIs) for your workloads in the reliability pillar. This check is based on your AWS-Well Architected reviews. Your check results depend on whether you completed the workload evaluation with AWS Well-Architected.

Note

Check ID

Wxdfp4B1L4

Alert Criteria

Red: At least one active high risk issue was identified in the reliability pillar for AWS Well-Architected.
Green: No active high risk issues were detected in the reliability pillar for AWS Well-Architected.

Recommended Action

AWS Well-Architected detected high risk issues during your workload evaluation. These issues present opportunities to reduce risk and save money. Sign in to the AWS Well-Architected tool to review your answers and take action to resolve your active issues.

Report columns

Status
Region
Workload ARN
Workload Name
Reviewer Name
Workload Type
Workload Started Date
Workload Last Modified Date
Number of identified HRIs for Reliability
Number of HRIs resolved for Reliability
Number of questions answered for Reliability
Total number of questions in Reliability pillar
Last Updated Time

ELB Connection Draining

Description

Checks for load balancers that do not have connection draining enabled.

When connection draining is not enabled and you deregister an Amazon EC2 instance from a load balancer, the load balancer stops routing traffic to that instance and closes the connection. When connection draining is enabled, the load balancer stops sending new requests to the deregistered instance but keeps the connection open to serve active requests.

Check ID

7qGXsKIUw

Alert Criteria

Yellow: Connection draining is not enabled for a load balancer.

Recommended Action

Enable connection draining for the load balancer. For more information, see Connection Draining and Enable or Disable Connection Draining for Your Load Balancer.

Additional Resources

Elastic Load Balancing Concepts

Report columns

Status
Region
Load Balancer Name
Reason

ELB Cross-Zone Load Balancing

Description

With cross-zone load balancing turned off, there is a risk of service unavailability due to uneven distribution of traffic or backend overloading. This problem can occur when clients incorrectly cache DNS information. The problem can also occur when there are an unequal number of instances in each Availability Zone (for example, if you have taken down some instances for maintenance).

Check ID

xdeXZKIUy

Alert Criteria

Yellow: Cross-zone load balancing is not enabled for a load balancer.

Recommended Action

Confirm that the Amazon EC2 instances registered with the load balancer are launched in multiple Availability Zones, and then enable cross-zone load balancing for the load balancer. For more information, see Availability Zones and Regions and Enable or Disable Cross-Zone Load Balancing for Your Load Balancer.

Additional Resources

Report columns

Status
Region
Load Balancer Name
Reason

Load Balancer Optimization

Description

Checks your load balancer configuration.

To help increase the level of fault tolerance in Amazon Elastic Compute Cloud (Amazon EC2) when using Elastic Load Balancing , we recommend running an equal number of instances across multiple Availability Zones in a Region. A load balancer that is configured accrues charges, so this is a cost-optimization check as well.

Check ID

iqdCTZKCUp

Alert Criteria

Yellow: A load balancer is enabled for a single Availability Zone.
Yellow: A load balancer is enabled for an Availability Zone that has no active instances.
Yellow: The Amazon EC2 instances that are registered with a load balancer are unevenly distributed across Availability Zones. (The difference between the highest and lowest instance counts in utilized Availability Zones is more than 1, and the difference is more than 20% of the highest count.)

Recommended Action

Ensure that your load balancer points to active and healthy instances in at least two Availability Zones. For more information, see Add Availability Zone.

If your load balancer is configured for an Availability Zone with no healthy instances, or if there is an imbalance of instances across the Availability Zones, determine if all the Availability Zones are necessary. Omit any unnecessary Availability Zones and ensure there is a balanced distribution of instances across the remaining Availability Zones. For more information, see Remove Availability Zone.

Additional Resources

Report columns

Status
Region
Load Balancer Name
# of Zones
Zone a Instances
Zone b Instances
Zone c Instances
Zone d Instances
Zone e Instances
Zone f Instances
Reason

VPN Tunnel Redundancy

Description

Checks the number of tunnels that are active for each of your VPNs.

A VPN should have two tunnels configured at all times. This provides redundancy in case of outage or planned maintenance of the devices at the AWS endpoint. For some hardware, only one tunnel is active at a time. If a VPN has no active tunnels, charges for the VPN might still apply. For more information, see AWS Client VPN Administrator Guide.

Check ID

S45wrEXrLz

Alert Criteria

Yellow: A VPN has one active tunnel (this is normal for some hardware).
Yellow: A VPN has no active tunnels.

Recommended Action

Be sure that two tunnels are configured for your VPN connection, and that both are active if your hardware supports it. If you no longer need a VPN connection, you can delete it to avoid charges. For more information, see Your Customer Gateway or Deleting a VPN connection.

Additional Resources

Report columns

Status
Region
VPN ID
VPC
Virtual Private Gateway
Customer Gateway
Active Tunnels
Reason

Warning Javascript is disabled or is unavailable in your browser.

To use the Amazon Web Services Documentation, Javascript must be enabled. Please refer to your browser's Help pages for instructions.

Document Conventions

Security

Service limits