AWS Trusted Advisor acts like your customized cloud expert, and helps you provision your resources by following best practices. The AWS Trusted Advisor inspects your AWS environment and makes recommendations when opportunities exist to save money, improve system performance and reliability, or help close security gaps. AWS Trusted Advisor covers major AWS services, and it has generated more than a million recommendations for customers, helping customers realize over $140 million in cost reductions in 2013. Learn more about how Trusted Advisor works by reading our FAQs.
Trusted Advisor is available to customers with Business-level and Enterprise-level support, and its best-practice recommendations can be integrated into your application through the AWS Support API. Why hire a cloud consultant? Start using AWS Trusted Advisor today!
AWS Trusted Advisor provides best practices in four categories: cost optimization, security, fault tolerance, and performance improvement . You can use over 30 Trusted Advisor checks to monitor and improve the deployment of Amazon EC2, Elastic Load Balancing, Amazon EBS, Amazon S3, Auto Scaling, IAM, Amazon RDS, Route 53, and other services. You can view the overall status of your AWS resource and saving estimation at the dashboard. Resources that you have suppressed are ignored in future reports to provide a more accurate view of your application's health. Learn more about how the suppress function works by readying our FAQs.
See how you can save money on AWS by eliminating unused and idle resources or making commitments to reserved capacity.
Checks your Amazon Elastic Compute Cloud (Amazon EC2) computing consumption history and calculates an optimal number of Heavy Utilization Reserved Instances. Recommendations are based on the previous calendar month's hour-by-hour usage aggregated across all consolidated billing accounts. For more information about how the recommendation is calculated, see "Reserved Instance Optimization Check Questions" in the Trusted Advisor FAQs.
With Reserved Instances you pay a low, one-time fee to receive a significant discount on the hourly charge for the instance. To minimize your costs, the billing system automatically applies Reserved Instance rates first.
Checks the Amazon Elastic Compute Cloud (Amazon EC2) instances that were running at any time during the last 14 days and alerts you if the daily CPU utilization was 10% or less and network I/O was 5 MB or less on 4 or more days. Running instances generate hourly usage charges. Although some scenarios can result in low utilization by design, you can often lower your costs by managing the number and size of your instances.
Estimated monthly savings are calculated by using the current usage rate for On-Demand Instances and the estimated number of days the instance might be underutilized. Actual savings will vary if you are using Reserved Instances or Spot Instances, or if the instance is not running for a full day. To get daily utilization data, download the report for this check.
Checks your Elastic Load Balancing configuration for load balancers that are not actively used. Any load balancer that is configured accrues charges. If a load balancer has no associated back-end instances or if network traffic is severely limited, the load balancer is not being used effectively.
Checks Amazon Elastic Block Store (Amazon EBS) volume configurations and warns when volumes appear to be underused. Charges begin when a volume is created. If a volume remains unattached or has very low write activity (excluding boot volumes) for a period of time, the volume is probably not being used.
Checks for Elastic IP addresses (EIPs) that are not associated with a running Amazon Elastic Compute Cloud (Amazon EC2) instance. EIPs are static IP addresses designed for dynamic cloud computing. Unlike traditional static IP addresses, EIPs can mask the failure of an instance or Availability Zone by remapping a public IP address to another instance in your account. A nominal charge is imposed for an EIP that is not associated with a running instance.
Checks the configuration of your Amazon Relational Database Service (Amazon RDS) for any DB instances that appear to be idle. If a DB instance has not had a connection for a prolonged period of time, you can shut down the instance to reduce costs. If persistent storage is needed for data on the instance, you can use lower-cost options such as taking and retaining a DB snapshot. Manually created DB snapshots are retained until you delete them.
Improve the security of your application by closing gaps, enabling various AWS security features, and examining your permissions.
Checks security groups for rules that allow unrestricted access (0.0.0.0/0) to specific ports. Unrestricted access increases opportunities for malicious activity (hacking, denial-of-service attacks, loss of data). The ports with highest risk are flagged red, and those with less risk are flagged yellow. Ports flagged green are typically used by applications that require unrestricted access, such as HTTP and SMTP.
If you have intentionally configured your security groups in this manner, we recommend using additional security measures to secure your infrastructure (such as IP tables).
Checks security groups for rules that allow unrestricted access to a resource. Unrestricted access increases opportunities for malicious activity (hacking, denial-of-service attacks, loss of data).
Checks for your use of AWS Identity and Access Management (IAM). You can use IAM to create users, groups, and roles in AWS, and you can use permissions to control access to AWS resources.
Checks buckets in Amazon Simple Storage Service (Amazon S3) that have open access permissions. Bucket permissions that grant List access to everyone can result in higher than expected charges if objects in the bucket are listed by unintended users at a high frequency. Bucket permissions that grant Upload/Delete access to everyone create potential security vulnerabilities by allowing anyone to add, modify, or remove items in a bucket. This check examines explicit bucket permissions, but it does not examine associated bucket policies that might override the bucket permissions.
Checks the root account and warns if multi-factor authentication (MFA) is not enabled. For increased security, we recommend that you protect your account by using MFA, which requires a user to enter a unique authentication code from their MFA hardware or virtual device when interacting with the AWS console and associated websites.
Checks the password policy for your account and warns when a password policy is not enabled, or if password content requirements have not been enabled. Password content requirements increase the overall security of your AWS environment by enforcing the creation of strong user passwords. When you create or change a password policy, the change is enforced immediately for new users but does not require existing users to change their passwords.
Checks security group configurations for Amazon Relational Database Service (Amazon RDS) and warns when a security group rule might grant overly permissive access to your database. Recommended configuration for any security group rule is to allow access from specific Amazon Elastic Compute Cloud (Amazon EC2) security groups or from a specific IP address.
Increase the availability and redundancy of your AWS application by take advantage of auto scaling, health checks, multi AZ, and backup capabilities.
Checks the age of the snapshots for your Amazon Elastic Block Store (Amazon EBS) volumes (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.
Checks the distribution of Amazon Elastic Compute Cloud (Amazon EC2) instances across Availability Zones in a region. Availability Zones are distinct locations that are designed to be insulated from failures in other Availability Zones and to provide inexpensive, low-latency network connectivity to other 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.
Checks your load balancer configuration. To help increase the level of fault tolerance in Amazon Elastic Compute Cloud (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.
Checks the number of tunnels that are active for each of your VPNs. A VPN should have two tunnels configured at all times to provide 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 (see the Amazon Virtual Private Cloud Network Administrator Guide). If a VPN has no active tunnels, charges for the VPN might still apply.
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.
Checks for automated backups of Amazon RDS DB instances. By default, backups are enabled with a retention period of 1 day. Backups reduce the risk of unexpected data loss and allow for point-in-time recovery.
Checks for DB instances that are deployed in a single Availability Zone. 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 so that database operations can 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.
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 and not on the application that is running on the instance.
Checks the configuration of Amazon Simple Storage Service (Amazon S3) buckets that have server access logging enabled. 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.
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 and add all four name servers in the Route 53 delegation set. For maximum availability, you must add all four Route 53 name servers.
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, when DNS Failover detects and responds to a failure of one of your endpoints).
Improve the performance of your service by checking your service limits, ensuring you take advantage of provisioned throughput, and monitoring for overutilized instances.
Checks the Amazon Elastic Compute Cloud (Amazon EC2) instances that were running at any time during the last 14 days and alerts you if the daily CPU utilization was more than 90% on 4 or more days. Consistent high utilization can indicate optimized, steady performance, but it can also indicate that an application does not have enough resources. To get daily CPU utilization data, download the report for this check.
Checks for usage that is more than 80% of the service limit. Values are based on a snapshot, so your current usage might differ. Limit and usage data can take up to 24 hours to reflect any changes. In some cases, your usage might be greater than the indicated limit for a period of time.
Checks for Provisioned IOPS volumes that are attached to an Amazon Elastic Compute Cloud (Amazon EC2) instance that is not Amazon EBS-optimized. Provisioned IOPS volumes in the Amazon Elastic Block Store (Amazon EBS) are designed to deliver the expected performance only when they are attached to an EBS-optimized instance.
Checks each Amazon Elastic Compute Cloud (EC2) security group for an excessive number of rules. If a security group has a large number of rules, performance can be degraded.
For more information, see Amazon EC2 Security Groups.
Checks for Amazon Elastic Compute Cloud (EC2) instances that have a large number of security group rules. Performance can be degraded if an instance has a large number of rules.
Checks for resource record sets that route DNS queries to AWS resources; these can be changed to alias resource record sets. An alias resource record set is a special Amazon Route 53 record type that routes DNS queries to an AWS resource (for example, an Elastic Load Balancing load balancer or an Amazon S3 bucket) or to another Route 53 resource record set. When you use alias resource record sets, Route 53 routes your DNS queries to AWS resources free of charge.
Checks for standard Amazon Elastic Block Store (EBS) volumes that are potentially overutilized and might benefit from a more efficient configuration. A standard Amazon EBS volume is designed for applications with moderate or bursty I/O requirements, and the IOPS rate is not guaranteed. It delivers approximately 100 IOPS on average, with a best-effort ability to burst to hundreds of IOPS. For consistently higher IOPS, you can stripe multiple standard volumes or use a Provisioned IOPS volume, which can deliver up to 4,000 IOPS. A Provisioned IOPS volume is designed to deliver within 10% of the specified IOPS performance 99.9% of the time when it is attached to an Amazon EBS-optimized Amazon EC2 instance.
Checks for cases where data transfer from Amazon Simple Storage Service (Amazon S3) buckets could be accelerated by using Amazon CloudFront, the AWS global content delivery service. When you configure Amazon CloudFront to deliver your content, requests for your content are automatically routed to the nearest edge location where content is cached, so it can be delivered to your users with the best possible performance. A high ratio of data transfer out to the data stored in the bucket indicates that you could benefit from using Amazon CloudFront to deliver the data.