Compliance

Enable enhanced health reporting on Elastic Beanstalk environments

Security Hub ElasticBeanstalk.1: basic health tells you the environment is green; enhanced health tells you why, with an agent that reports every ten seconds instead of metrics every five minutes.

11 min·10 sections·AWS

Last reviewed 27 May 2026

Remediates AWS Security Hub: ElasticBeanstalk.1

ElasticBeanstalk.1: the basics

Why basic health reporting isn't enough

Elastic Beanstalk gives every environment a health status (Green, Yellow, Red, or Grey) that you see in the console and that drives load-balancer routing and managed updates. The question is how that colour gets computed. With basic health reporting, Beanstalk infers health from a handful of CloudWatch metrics and the load balancer's view of instance reachability. It's coarse: an environment can be quietly failing requests while still showing green, because the signals basic health watches are too blunt to notice.

Enhanced health reporting changes the source of truth. A health agent baked into the supported Beanstalk AMIs runs on each EC2 instance, reads the web server logs and OS-level metrics directly, and rolls per-instance health up into a single environment status with a descriptive cause. Instead of just "Yellow," you get "Yellow, 12% of requests returning 5xx on instance i-0abc." That's the difference between knowing something is wrong and knowing what is wrong.

Security Hub control ElasticBeanstalk.1 checks whether enhanced health reporting is enabled on your environments and is rated Low severity. It maps to NIST 800-53 CA-7 (continuous monitoring) and SI-2 (flaw remediation), because an environment you can't observe clearly is an environment you can't operate, patch, or recover with confidence. The control is change-triggered: flip the setting and the finding clears on the next evaluation.

In this lesson you'll learn the difference between Elastic Beanstalk's basic and enhanced health reporting, what the on-instance health agent actually measures, and why Security Hub flags environments that stay on basic. You'll see the CLI commands to audit which environments are on which level and to flip an environment to enhanced via its configuration option settings, the IAM role and platform prerequisites that bite, and the operating practice (baking the setting into saved configurations) that keeps new environments compliant by default.

Fun fact

Seven words for unhealthy

Basic and enhanced health share the same four colours (Green, Yellow, Red, and Grey) but enhanced adds seven single-word statuses underneath them, so a colour finally comes with a precise word: OK, Info, Warning, Degraded, Severe, Pending, and Unknown. The grey ones are the interesting pair. Pending means an operation is in progress and the agent is still bootstrapping; Unknown means Beanstalk genuinely isn't receiving enough data to judge, distinct from Red (Degraded/Severe), which is a confident "it's broken." Basic health uses Grey too, but only to say "your environment is being updated"; it can't tell you the agent has actually gone silent. Teams that switch to enhanced are often surprised to see environments sit on Unknown during deploys or when the health agent is starved for resources, a state basic reporting simply can't surface.

Turning on enhanced health in action

Marcus owns the platform team at a logistics startup. Security Hub surfaces ElasticBeanstalk.1 against three of their seven Beanstalk environments; all three are legacy environments created before enhanced health became the default, still running basic reporting.

He confirms the gap with a quick CLI sweep: describe-configuration-settings on each environment shows aws:elasticbeanstalk:healthreporting:system with SystemType=basic. Before flipping it he checks the prerequisites: the service role needs the managed AWSElasticBeanstalkEnhancedHealth policy so Beanstalk can gather instance and environment health, the instance profile needs AWSElasticBeanstalkWebTier (which grants elasticbeanstalk:PutInstanceStatistics) so the on-instance agent can publish, and the platform version has to support the agent. All three are on a recent Amazon Linux 2 platform with the standard roles attached, so they're good.

Marcus runs update-environment to set SystemType=enhanced on the first environment, watches it apply without an instance replacement (it's an environment-level config change, not a rebuild), and confirms the console now shows per-instance causes. He repeats it for the other two, then bakes the setting into the team's saved configuration template so the next environment ships enhanced by default. Security Hub clears all three findings on the next change-triggered evaluation.

First, check which health reporting level an environment is using by reading its configuration settings.

$ aws elasticbeanstalk describe-configuration-settings --application-name orders-api --environment-name orders-api-prod --query 'ConfigurationSettings[].OptionSettings[?Namespace==`aws:elasticbeanstalk:healthreporting:system`]' --output table

-------------------------------------------------------------------

| DescribeConfigurationSettings |

+----------------------------------------------+------------------+

| Namespace | OptionName |

+----------------------------------------------+------------------+

| aws:elasticbeanstalk:healthreporting:system | SystemType |

| Value: basic |

+----------------------------------------------+------------------+

# SystemType=basic: ElasticBeanstalk.1 fails for this environment.

A SystemType of basic is exactly what the control flags; enhanced is the passing value.

Flip the environment to enhanced health reporting by updating the option setting. This is a config change, not an instance rebuild.

$ aws elasticbeanstalk update-environment --environment-name orders-api-prod --option-settings Namespace=aws:elasticbeanstalk:healthreporting:system,OptionName=SystemType,Value=enhanced

{

"EnvironmentName": "orders-api-prod",

"Health": "Grey",

"Status": "Updating",

"HealthStatus": "Pending",

"PlatformArn": "arn:aws:elasticbeanstalk:us-east-1::platform/..."

}

# Status flips to Updating, then the agent reports detailed health within a minute.

update-environment applies the namespace change in place; no new instances are launched.

Enhanced health under the hooddeep dive

Health reporting is controlled by a single option in the aws:elasticbeanstalk:healthreporting:system configuration namespace: SystemType, which is either basic or enhanced. Because it's an environment configuration option, you can set it the same way you set any other Beanstalk option: through update-environment, an .ebextensions config file, a saved configuration, or the EB CLI. The change applies without replacing instances, though the environment briefly reports Grey while the agent comes online.

The data path is what makes enhanced different. Supported platform AMIs ship a health agent process that runs on every instance, parses the web server's access logs and OS metrics (CPU, load, request latency and status-code distribution), and reports per-instance health to the Beanstalk service. Beanstalk combines those instance-level signals with deployment and Auto Scaling state to compute the environment colour and a human-readable cause. Basic reporting has none of this on-instance detail; it leans on CloudWatch alarms and ELB health checks alone.

Two sets of IAM permissions trip people up, and they live on different roles. The service role (the one Beanstalk itself assumes) needs the managed AWSElasticBeanstalkEnhancedHealth policy so the service can gather health from the load balancer, EC2, Auto Scaling, and (for worker tiers) SQS. Separately, the instance profile attached to the EC2 instances needs elasticbeanstalk:PutInstanceStatistics so the on-instance agent can publish its readings; that action is carried by the managed AWSElasticBeanstalkWebTier policy (and AWSElasticBeanstalkWorkerTier for worker environments). Legacy environments built before these were standard sometimes lack one or the other. A third prerequisite: enhanced health is only available on platform versions that include the agent; very old custom platforms or unsupported branches won't offer it, and the fix there is a platform update first. The Security Hub control is backed by the AWS Config rule beanstalk-enhanced-health-reporting-enabled and is change-triggered, so it re-evaluates whenever the environment configuration changes.

# Audit every environment in the region for its health reporting level.
for env in $(aws elasticbeanstalk describe-environments \
  --query 'Environments[].EnvironmentName' --output text); do
  TYPE=$(aws elasticbeanstalk describe-configuration-settings \
    --application-name "$(aws elasticbeanstalk describe-environments \
      --environment-names "$env" \
      --query 'Environments[0].ApplicationName' --output text)" \
    --environment-name "$env" \
    --query 'ConfigurationSettings[0].OptionSettings[?OptionName==`SystemType`].Value' \
    --output text)
  echo "$env -> ${TYPE:-basic}"
done

# Set enhanced via an .ebextensions config file (commit this in source):
# .ebextensions/healthreporting.config
# option_settings:
#   aws:elasticbeanstalk:healthreporting:system:
#     SystemType: enhanced

What is the impact of running on basic health reporting?

The primary impact is detection lag. Basic health infers environment status from CloudWatch alarms and load-balancer health checks, which means a partial failure (a fraction of requests returning 5xx, one instance with climbing latency) can stay invisible while the environment still reports Green. Enhanced health catches that because the on-instance agent reads the web server logs directly and reports per-instance status with a cause. The gap between "something is wrong" and "we noticed" is exactly the window in which a degradation becomes an outage.

The second impact is diagnostic time. When basic health does finally turn the environment Yellow or Red, it tells you the colour but little about why; the team starts the incident by SSHing into instances and grepping logs to reconstruct what enhanced health would have shown on the dashboard from the first second. On a customer-facing application, every minute of that reconstruction is a minute of degraded service, so the cost shows up as longer mean-time-to-resolution, not as a bigger AWS bill.

There's a knock-on effect on automation, too. Beanstalk's managed platform updates and rolling deployments use health status to decide whether a batch succeeded before moving on. With coarse basic health, a deployment can be marked healthy and proceed while it's actually degrading the service; enhanced health's per-instance signal makes that safety check far more reliable. So this isn't only a monitoring concern; it's an input to the safety of every automated change.

Finally there's the compliance dimension the control is actually scored on. ElasticBeanstalk.1 maps to NIST 800-53 CA-7 and SI-2 (continuous monitoring and flaw remediation). An environment you can't observe in detail is one you can't credibly claim to be continuously monitoring, and an open finding here, however low-severity, is a small but real ding against an organisation's monitoring posture in any audit that references those frameworks.

How do you enable enhanced health reporting safely?

Remediation is a short loop: confirm the platform and IAM prerequisites, flip the SystemType option, verify the agent is reporting, and bake the setting into your provisioning templates so it never regresses.

1. Confirm the platform and IAM prerequisites

Enhanced health needs a platform version that ships the health agent, a service role carrying the AWSElasticBeanstalkEnhancedHealth managed policy so Beanstalk can gather health, and an instance profile with elasticbeanstalk:PutInstanceStatistics (granted by AWSElasticBeanstalkWebTier) so the agent can publish. Check the environment's platform ARN, service role, and instance profile before flipping anything. If the platform is too old, do a managed platform update first; if a role is missing the permissions, attach the managed policy. Skipping this is the most common reason the setting appears to apply but the environment then sits stuck on a grey Pending or Unknown status.

2. Set SystemType to enhanced on the environment

Change the single option SystemType to enhanced in the aws:elasticbeanstalk:healthreporting:system namespace, via update-environment, the console's health configuration page, or an .ebextensions config file. This is an in-place configuration change, not an instance rebuild, so it applies without replacing your fleet. The environment will briefly report Grey while the agent initialises, then resolve to a detailed status.

3. Verify the agent is reporting per-instance health

After the update settles, confirm in the console (or via the enhanced health API) that you now see per-instance causes and a non-Grey status. A persistent Grey after a few minutes means the agent can't report, almost always the IAM permission or platform prerequisite from step 1. Don't consider the control remediated until you've seen real instance-level data come through, not just the config value.

4. Bake it into saved configurations and provisioning templates

Add the SystemType=enhanced option to your saved configurations, CloudFormation/Terraform Beanstalk definitions, or committed .ebextensions files so every new environment ships compliant by default. This is what turns a one-time remediation into a durable standard; without it, the next environment someone spins up reintroduces the finding and you're back to chasing it manually.

# Remediate one environment: set SystemType to enhanced.
aws elasticbeanstalk update-environment \
  --environment-name orders-api-prod \
  --option-settings \
    Namespace=aws:elasticbeanstalk:healthreporting:system,OptionName=SystemType,Value=enhanced

# Verify the setting took effect.
aws elasticbeanstalk describe-configuration-settings \
  --application-name orders-api \
  --environment-name orders-api-prod \
  --query 'ConfigurationSettings[0].OptionSettings[?OptionName==`SystemType`].Value' \
  --output text

# Confirm the environment is reporting detailed health (not stuck Grey).
aws elasticbeanstalk describe-environment-health \
  --environment-name orders-api-prod \
  --attribute-names All \
  --query '{Status:Status,Color:Color,Causes:Causes}'

Quick quiz

Question 1 of 5

Security Hub flags ElasticBeanstalk.1 on a production environment running on basic health reporting. You run update-environment to set SystemType=enhanced, but the environment sits stuck on Grey and reports no per-instance data. What's the most likely cause and right next move?

Keep learning

Dig deeper into Elastic Beanstalk health reporting, the Security Hub control, and the Config rule behind it.

You've completed Enable enhanced health reporting on Elastic Beanstalk environments. You now know the difference basic and enhanced health make to detection and diagnosis, the single SystemType option that controls it, the platform and IAM prerequisites that catch people out, and how to bake the setting into provisioning so ElasticBeanstalk.1 never comes back. Next time the control fires, you'll have a verify-flip-confirm-template path from flagged to resolved in minutes.

Back to the library

ElasticBeanstalk.1: what it means for the bill and the risk

A free monitoring upgrade that protects availability

Elastic Beanstalk is the AWS service teams use to run web applications without managing the underlying servers by hand. Every environment reports a health status, but there are two levels of detail. The basic level gives a simple traffic-light colour. The enhanced level adds a running diagnosis (which instances are struggling, why, and how bad it is) produced by a small agent that already ships inside the standard machine images.

This finding flags environments still on the basic level. The important thing for finance to know is that the enhanced level is included in the platform at no additional charge for the feature itself: there's no premium SKU to buy. The only incremental cost is the CloudWatch metrics and any alarms you choose to publish on top of it, which is typically a few dollars a month per environment and often zero in practice.

The reason it matters to the budget isn't the line item, it's the avoided cost. Better health visibility shortens the time to detect and resolve outages, and an outage on a customer-facing application is far more expensive than any monitoring bill. So this is a low-severity compliance item with an asymmetric payoff: negligible cost to fix, meaningful reduction in the cost of the next incident.

This lesson is for the finance partner who wants to understand why an availability-monitoring toggle shows up next to cost work. It covers what the enhanced level adds, what it does and doesn't cost, how it connects to the real expense (incident and downtime cost) and the two governance levers finance can pull: making it a standard in the environment-provisioning checklist, and tracking the open-finding count as a leading indicator of operational discipline. No commands, no AWS internals.

Fun fact

Seven words for unhealthy

How a finance partner frames the decision

Dana is the finance partner working with the platform team at a logistics startup. A compliance summary lists ElasticBeanstalk.1 as an open low-severity finding on three environments. Rather than treat it as an engineering detail, Dana asks the two questions that matter for the budget: does fixing it cost anything, and does leaving it cost anything.

The answer to the first is essentially no: the enhanced level is part of the platform, with only marginal CloudWatch metric charges on top, typically a few dollars a month per environment. The answer to the second is the interesting one: these are customer-facing applications, and the team's last incident took longer to diagnose than it should have precisely because they were working from a coarse health signal. Better visibility is downtime avoided, and downtime on these systems is measured in lost orders, not dollars of monitoring.

Dana doesn't need to understand the agent or the config namespace. She makes enhanced health a line on the environment-provisioning checklist so new environments are compliant from day one, and she asks for the open-finding count to appear on the monthly operational review. When it's zero and stays zero, she stops asking; it's become a non-issue, which is exactly the outcome she wants from a low-severity control.

Why this matters to the budget, not just the bill

The direct cost of this control is close to zero in both directions. Enabling enhanced health adds no platform charge and only marginal CloudWatch metric cost, a few dollars a month per environment at most. So this is never going to move a cloud-spend report, and it shouldn't be evaluated as a cost-saving the way an idle-resource cleanup would be.

The financial case is entirely about avoided cost. These are typically customer-facing applications, and the expense of an outage (lost transactions, support load, reputational drag) dwarfs any monitoring line item. Enhanced health shortens both detection and diagnosis time, which compresses outage duration, which is real money on a revenue-generating service. The right mental model is insurance with a negligible premium, not an optimisation.

There's also a soft cost in audit and compliance overhead. Open NIST-mapped findings, even low-severity ones, generate follow-up work (explanations in audit reviews, remediation tracking, evidence gathering) that consumes time disproportionate to the finding's size. Closing zero-cost findings promptly keeps the compliance backlog clean and frees that attention for the items that genuinely require trade-off decisions.

Finally, treat the open-finding count as a leading indicator. A pile of trivially-fixable, zero-cost compliance findings sitting open month after month usually signals that the provisioning process doesn't bake standards in by default, and that same gap predicts costlier misconfigurations elsewhere. Watch the trend, not the individual dollar.

What finance can actually do about this

Finance can't change an environment setting, but it can make sure this class of finding stops recurring. Two levers, applied at the provisioning and review stages.

1. Make it a standard on the provisioning checklist

The cheapest way to never see this finding again is to require enhanced health as a default in whatever checklist or template governs new environment creation. Fund the one-time work to update the standard templates; after that, compliance is free and automatic rather than a recurring remediation cost.

2. Track open low-severity findings as a backlog metric

Ask for the count of open, zero-cost compliance findings on the monthly operational review. A growing pile of trivially-fixable items is a process signal worth more than its dollar value; it usually means standards aren't being applied by default, which predicts costlier misconfigurations elsewhere.

3. Frame it as incident-cost reduction, not monitoring spend

When the team weighs this against other work, help them frame the value correctly: the payoff is shorter outages on revenue-generating applications, not a smaller AWS bill. That framing gets a zero-cost availability improvement prioritised ahead of work with a flashier dollar figure but lower real impact.

4. Resist treating low severity as low priority

Severity reflects the finding's standalone risk, not the effort-to-value ratio. A Low finding that takes five minutes to close and shortens future outages is a better use of time than many Medium findings that need real trade-offs. Encourage the team to clear the cheap, high-leverage items first.

Quick quiz

Question 1 of 5

ElasticBeanstalk.1 is open on three environments as a Low-severity finding. The engineering lead says it's nil-cost to fix but it keeps getting deprioritised behind items with dollar figures attached. As the finance partner, what's the right move?

Keep learning

Dig deeper into Elastic Beanstalk health reporting, the Security Hub control, and the Config rule behind it.

You've finished the finance partner's view of ElasticBeanstalk.1. You know it's a near-zero-cost toggle whose real value is shorter outages on customer-facing apps, why open low-severity findings carry hidden audit overhead, and the two levers finance owns: making enhanced health a provisioning default and watching the open-finding trend. Next time it appears on the review, you'll frame it as avoided incident cost, not monitoring spend.

Back to the library

ElasticBeanstalk.1: the headline

Turning on the detailed health view for hosted applications

Some of our web applications run on a managed AWS service that reports whether they're healthy. Today some environments use only the basic view: a simple green/yellow/red light. The richer view, which explains why an application is degraded and which servers are affected, is available at effectively no extra cost and is simply switched off.

This is a low-severity hygiene finding with an outsized practical benefit. Enabling the detailed view means the team detects and diagnoses customer-facing problems faster, which directly shortens outages. There is no meaningful trade-off: it's a configuration toggle, not a project.

A short read for the executive who wants the headline and the one question to ask. You'll get why this control exists, what "good" looks like at an org level, and why a low-severity finding can still be worth a sentence at the operational review, without any implementation detail.

Fun fact

Seven words for unhealthy

What it looks like when leadership gets this right

At one company the COO noticed the same low-severity finding sitting open on the compliance dashboard quarter after quarter. The dollar figure attached to it was nil, so it kept getting deprioritised behind everything with a number next to it.

Instead of asking the team to "close the finding," she asked a sharper question: "When one of these applications degrades for a customer, how fast do we know, and do we know why?" The honest answer was "not fast enough, and not always why", and that reframed a zero-cost compliance toggle as an availability decision. The team enabled enhanced health across all environments that week and added it to the standard provisioning template.

The right outcome state here isn't a clean dashboard for its own sake. It's that every customer-facing environment produces a diagnosis, not just a colour, so the next incident is shorter. The compliance finding closing is the side effect; faster recovery is the point.

Why this is on the report at all

The dollar figure on this finding is effectively nil, which is precisely why it's worth understanding rather than ignoring. It's tracked because of what it protects (the speed at which the organisation detects and diagnoses problems in customer-facing applications) and because of what its presence signals about whether monitoring standards are applied consistently by default.

An open low-severity finding like this one is cheap to close and maps to recognised monitoring and remediation controls in NIST 800-53. Leaving it open carries no cost today but quietly weakens the org's monitoring posture and, more tellingly, suggests new environments aren't being provisioned to standard. The pattern matters more than the instance: a tidy compliance baseline is a confidence signal that the operational discipline underneath is healthy.

The leadership move on this category

The handle for an executive isn't to chase one finding; it's to set the expectation that monitoring is on by default and that cheap, high-leverage fixes don't sit in a backlog.

1. Expect detailed monitoring on by default

Set the norm that customer-facing systems are provisioned with the richest available health and observability turned on from the start. Make it a standard, not a remediation; that's the difference between fixing this once and fixing it forever.

2. Judge findings by leverage, not just severity

A Low-severity finding that's free to fix and shortens outages deserves to be closed quickly. Ask the team to clear the cheap, high-impact items rather than letting severity labels alone set the queue order.

3. Use the open-finding trend as a discipline signal

Ask whether the count of open low-severity findings is flat or shrinking. A clean, well-maintained compliance baseline is a one-line confidence indicator that the operational hygiene underneath is sound, no technical depth required to read it.

Quick quiz

Question 1 of 5

Your compliance dashboard shows ElasticBeanstalk.1 has been open and Low-severity for two quarters, with effectively no cost attached. What's the right read and response?

Keep learning

Dig deeper into Elastic Beanstalk health reporting, the Security Hub control, and the Config rule behind it.

That's the lesson. Two takeaways: a Low-severity, nil-cost finding can still be worth closing when it shortens customer-facing outages, and the leadership move is to expect detailed monitoring on by default rather than to chase findings one at a time. Judge these by leverage, not just severity.

Back to the library

Enable enhanced health reporting on Elastic Beanstalk environments

ElasticBeanstalk.1: the basics

Seven words for unhealthy

Turning on enhanced health in action

Enhanced health under the hooddeep dive

What is the impact of running on basic health reporting?

How do you enable enhanced health reporting safely?

1. Confirm the platform and IAM prerequisites

2. Set SystemType to enhanced on the environment

3. Verify the agent is reporting per-instance health

4. Bake it into saved configurations and provisioning templates

Quick quiz

Keep learning

ElasticBeanstalk.1: what it means for the bill and the risk

Seven words for unhealthy

How a finance partner frames the decision

Why this matters to the budget, not just the bill

What finance can actually do about this

1. Make it a standard on the provisioning checklist

2. Track open low-severity findings as a backlog metric

3. Frame it as incident-cost reduction, not monitoring spend

4. Resist treating low severity as low priority

Quick quiz

Keep learning

ElasticBeanstalk.1: the headline

Seven words for unhealthy

What it looks like when leadership gets this right

Why this is on the report at all

The leadership move on this category

1. Expect detailed monitoring on by default

2. Judge findings by leverage, not just severity

3. Use the open-finding trend as a discipline signal

Quick quiz

Keep learning

Related compliance lessons