AWS Trusted Advisor and AWS Health

Support plans answer the question "who do we call?" Two other AWS tools answer the questions that come before the call: "what could go wrong?" and "is AWS itself having a problem?" On November 12, Gwen shows Mateo AWS Trusted Advisor, which inspects an account and recommends improvements, and AWS Health, which reports events in AWS that affect your resources. Both appear in the exam guide as tools that help manage environments and optimize cost.

What Trusted Advisor does

AWS Trusted Advisor continuously checks your AWS environment against best practices that AWS has learned from many customers, and produces a list of checks, each marked as fine (green), worth investigating (yellow) or action recommended (red). Each check explains what it found, why it matters and what to do. Trusted Advisor does not change anything by itself.

Checks are grouped into categories that echo the pillars of the AWS Well-Architected Framework.

What each plan gets

The set of checks depends on the support plan.

• Basic Support: all service limit checks and a selected set of security and fault tolerance checks, often called the core checks, such as open security group ports, root account MFA and public S3 bucket permissions.
• Business Support+, Enterprise Support and Unified Operations: the full set of checks in every category, automatic refreshing of results, programmatic access through the Trusted Advisor API, and events in Amazon EventBridge so results can trigger automation.
• Enterprise Support and Unified Operations: also Trusted Advisor Priority, a prioritized list of recommendations curated by the account team.

Mateo opens Trusted Advisor in the sandbox, which is on Basic Support. The core security checks show two red items: the root user has no multi-factor authentication yet, and a security group from a tutorial allows remote desktop from anywhere. Neither is a cost item, but both matter. He fixes them on the spot. The cost optimization checks that would have flagged the idle server and the unattached volume are not in the core set, which is one more reason production will run on Business Support+.

Using Trusted Advisor for cost

For cost, Trusted Advisor's checks overlap with the recommendations in Cost Explorer, Compute Optimizer and Cost Optimization Hub (lessons 5 and 6). In practice Gwen uses them together. Trusted Advisor gives a quick, broad view across categories; Cost Optimization Hub collects savings recommendations with estimated amounts; Compute Optimizer gives detailed sizing suggestions; and Cost Explorer shows whether the changes actually lowered the bill. In an organization, Trusted Advisor results can be viewed across accounts from the management account with organizational view.

# Illustrative: turning Trusted Advisor-style findings into a savings list.
findings = [("Idle test instance", "cost", 280.00), ("Unattached 1 TB volume", "cost", 80.00),
            ("Idle NAT gateway", "cost", 33.00), ("Root user without MFA", "security", 0.0),
            ("Open remote desktop port", "security", 0.0)]
cost_items = [f for f in findings if f[1] == "cost"]
for name, cat, usd in sorted(cost_items, key=lambda f: -f[2]):
    print(f"{name:26} {usd:7.2f} USD a month")
print(f"{'Total possible saving':26} {sum(f[2] for f in cost_items):7.2f} USD a month")
print("Security items to fix first:", [f[0] for f in findings if f[1] == "security"])

Idle test instance          280.00 USD a month
Unattached 1 TB volume       80.00 USD a month
Idle NAT gateway             33.00 USD a month
Total possible saving       393.00 USD a month
Security items to fix first: ['Root user without MFA', 'Open remote desktop port']

AWS Health

AWS Health tells you about events in AWS that may affect your resources: an operational problem with a service in a Region, scheduled maintenance on the hardware under one of your instances, a required change such as an engine version reaching end of support, or an issue with your account. It is the authoritative source for how AWS events affect you.

The difference between the two dashboard views matters. The public service health page might show that a service in a Region is fine overall, while your account health shows that one of your specific instances is scheduled for retirement next week because its underlying hardware is degraded. The second view is personalized, so it is the one the team watches.

Gwen sets up an EventBridge rule in the sandbox that sends AWS Health events to an SNS topic, which emails the IT list. In production, the same rule will post to the on-call chat channel, so Mateo learns about a scheduled maintenance event before it surprises a clinic.

Reporting abuse: the AWS Trust and Safety team

Sometimes the problem is someone else's AWS resource: a website hosted on AWS that is sending spam, hosting malware, attempting to break into your systems or infringing copyright. The AWS Trust and Safety team handles reports of abuse involving AWS resources. Anyone can report suspected abuse through the AWS abuse reporting form or the abuse contact address, with details such as the IP address, time and logs. Trust and Safety also contacts AWS customers whose resources appear to be involved in abuse, for example when an instance has been compromised and is attacking others, and may ask them to fix it.

Hannah Weiss adds this to Cascade Ridge's security runbook: if logs show attacks against BookVet coming from an AWS IP address, report it to Trust and Safety; if AWS ever reports that one of Cascade Ridge's own resources is involved in abuse, treat it as a security incident at once.

Bringing it together

By the end of the session, Mateo has a short list for each account. For the sandbox: core Trusted Advisor checks reviewed and fixed, Health events routed to email, a budget and anomaly monitor in place. For production, as plans: Business Support+ for the full Trusted Advisor checks and the Health API, Health events to the on-call channel, Trusted Advisor and Cost Optimization Hub reviewed in the monthly cost meeting, and Trust and Safety in the security runbook.

Service limits and quotas

Every AWS account has service quotas, also called limits: the maximum number of a resource, or the maximum rate of requests, allowed by default in each Region. Quotas protect both AWS and customers, for example from a runaway script launching thousands of instances. Trusted Advisor's service limit checks warn when usage approaches a quota, and Service Quotas in the console shows current values and lets you request increases. For Cascade Ridge, the relevant quotas are modest, but Gwen checks the ones that would matter during cutover, such as the number of running instances of a type and Elastic IP addresses, and requests increases weeks in advance.

# Illustrative: flag quotas above a warning level.
quotas = {"Running on-demand standard instances (vCPUs)": (28, 32),
          "Elastic IP addresses": (3, 5),
          "VPCs per Region": (2, 5)}
for name, (used, limit) in quotas.items():
    level = used / limit
    flag = "request increase" if level >= 0.8 else "ok"
    print(f"{name:46} {used:3d} of {limit:3d}  {flag}")

Running on-demand standard instances (vCPUs)    28 of  32  request increase
Elastic IP addresses                             3 of   5  ok
VPCs per Region                                  2 of   5  ok

Trusted Advisor across accounts

In an organization, the management account can turn on organizational view for Trusted Advisor and see check results for all member accounts in one report. Gwen plans to use it in the monthly cost review: one report shows idle resources, open ports and missing backups across production, development and the sandbox. Results can also be delivered through EventBridge to automation, for example to open a ticket whenever a red security check appears.

Reading a Health event

An AWS Health event has a few standard parts: the service and Region, the event type (an issue, a scheduled change or an account notification), its status, the affected resources in your account, a description and, for scheduled changes, the date by which you must act. A typical scheduled change might say that an instance's underlying hardware will be retired on a given date and that stopping and starting the instance before then moves it to healthy hardware. Acting early, in a planned window, is far better than letting the change happen on AWS's date at a busy hour.

Status pages and your own monitoring

AWS Health is not a replacement for monitoring your own systems. It reports AWS events; it does not know whether Cascade Ridge's own code has a bug. Amazon CloudWatch alarms on the application, the database and the load balancer will usually notice a problem first. When they do, the AWS Health account view is the quickest way to answer the next question: is this us, or is it AWS?

Mateo writes the order down for the on-call guide: first check Cascade Ridge's own alarms and recent changes; then check the AWS Health account view; then, if AWS is involved and the system is down, open a support case at the right severity. The order saves time, because most problems turn out to be closer to home than to AWS.