Compliance

Stream Elastic Beanstalk logs to CloudWatch

Security Hub ElasticBeanstalk.3 — when a Beanstalk environment scales in or replaces an instance, its logs vanish with it; streaming to CloudWatch keeps the evidence even after the box is gone.

11 min·10 sections·AWS

Last reviewed 27 May 2026

Remediates AWS Security Hub: ElasticBeanstalk.3

Streaming Beanstalk logs: the basics

Why logs on a Beanstalk instance are written in disappearing ink

Elastic Beanstalk runs your application on EC2 instances it provisions, scales, and replaces for you. That convenience has a sharp edge for logging: eb-activity.log, the nginx or Apache access logs, and your application's own logs all live on the instance's local disk. When Beanstalk scales in during a quiet hour, swaps an unhealthy instance, or rolls a platform update, that instance is terminated — and every log file on it is destroyed along with the EBS volume. The evidence of what happened just before the failure goes with the box.

ElasticBeanstalk.3 checks whether the environment is configured to stream those instance logs to CloudWatch Logs. It fails if streaming is off. The control is rated High because PCI DSS 10.4.2 and most logging-control frameworks require that audit trails survive the system that produced them — and an ephemeral instance is exactly the system that won't survive. Without streaming, your retained record of a security or availability event is whatever happened to still be running when you went looking.

It's flagged because the default is off, and because the failure mode is silent. Everything works fine until the day you actually need the logs — an incident, a customer dispute, an auditor's sample request — and you discover the instance that held them was recycled three weeks ago. There's no error, no alarm; there's just an empty /var/log on a machine that no longer exists.

In this lesson you'll learn why Elastic Beanstalk's ephemeral instances make local log files unreliable, exactly what ElasticBeanstalk.3 checks, and how to turn on CloudWatch log streaming through the aws:elasticbeanstalk:cloudwatch:logs option namespace. You'll see the AWS CLI commands to inspect an environment's current logging settings and apply the fix, the role of the StreamLogs, DeleteOnTerminate, and RetentionInDays options, the IAM permissions the instance profile needs, and how to bake the setting into .ebextensions so new environments are compliant by default.

Fun fact

The logs that scaled themselves into oblivion

A payments startup chasing PCI certification got hit with a finding mid-assessment: the auditor asked for the access logs covering a specific 48-hour window six weeks earlier. The team confidently opened the Beanstalk environment — and found nothing. An auto-scaling event had terminated the three instances that served traffic that day, and with StreamLogs switched off, the only copies of those logs went to the bit bucket along with the EBS volumes. The remediation took one CLI command and cost about $3 a month in CloudWatch storage. The delay it caused to their certification cost a great deal more than that.

Turning on log streaming in action

Dev is the platform engineer on call when Security Hub raises ElasticBeanstalk.3 against the payments-prod environment. The finding is High, tied to PCI DSS 10.4.2, and the audit window is three weeks out — so this is a fix-today item, not a backlog ticket.

He first inspects the environment's current settings to confirm streaming really is off, reading the aws:elasticbeanstalk:cloudwatch:logs option namespace. StreamLogs comes back false. He checks the instance profile too — the EC2 role attached to the environment needs logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents, which the managed AWSElasticBeanstalkWebTier policy already grants, so no IAM change is needed.

He applies the fix with a single update-environment call, setting StreamLogs=true, a 90-day RetentionInDays to match the audit retention requirement, and DeleteOnTerminate=false so the CloudWatch log group survives even when the environment is later torn down. Beanstalk performs a rolling configuration update; within a few minutes the /aws/elasticbeanstalk/payments-prod/var/log/... log groups appear in CloudWatch and the next Security Hub evaluation flips the control to PASSED. Then he opens a PR adding the same setting to the team's shared .ebextensions so every future environment is born compliant.

First, inspect the environment's current logging configuration to confirm streaming is off before you change anything.

$ aws elasticbeanstalk describe-configuration-settings --application-name payments --environment-name payments-prod --query 'ConfigurationSettings[].OptionSettings[?Namespace==`aws:elasticbeanstalk:cloudwatch:logs`]' --output table

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

| DescribeConfigurationSettings |

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

| Namespace | OptionName | Value |

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

| aws:elasticbeanstalk:cloudwatch:logs | StreamLogs | false |

| aws:elasticbeanstalk:cloudwatch:logs | DeleteOnTerminate| true |

| aws:elasticbeanstalk:cloudwatch:logs | RetentionInDays | 7 |

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

# StreamLogs=false means logs die with the instance — this is the finding.

Read the cloudwatch:logs namespace first; StreamLogs=false is exactly what ElasticBeanstalk.3 fails on.

Turn streaming on, set a retention window that matches your audit requirement, and keep the log group after teardown.

$ aws elasticbeanstalk update-environment --environment-name payments-prod --option-settings Namespace=aws:elasticbeanstalk:cloudwatch:logs,OptionName=StreamLogs,Value=true Namespace=aws:elasticbeanstalk:cloudwatch:logs,OptionName=DeleteOnTerminate,Value=false Namespace=aws:elasticbeanstalk:cloudwatch:logs,OptionName=RetentionInDays,Value=90

{

"EnvironmentName": "payments-prod",

"Status": "Updating",

"Health": "Grey",

"Tier": { "Name": "WebServer", "Type": "Standard" }

}

# Rolling config update; log groups appear under /aws/elasticbeanstalk/payments-prod/

# DeleteOnTerminate=false keeps the logs even after the environment is torn down.

One update-environment call sets all three options; RetentionInDays should match your documented audit window.

Beanstalk log streaming under the hooddeep dive

Log streaming is controlled entirely through the aws:elasticbeanstalk:cloudwatch:logs configuration option namespace. Three options matter: StreamLogs (boolean, default false) turns streaming on; RetentionInDays (default 7) sets how long CloudWatch keeps the events before expiring them — the allowed values mirror CloudWatch's own retention enum (1, 3, 5, 7, 14, 30, 60, 90, 120, 150, 180, 365, 400, 545, 731, 1827, 3653); and DeleteOnTerminate (default false) decides whether the log groups are deleted when the environment is terminated. For an audit trail you almost always want DeleteOnTerminate=false so the evidence outlives the environment.

When StreamLogs is enabled, Beanstalk installs the CloudWatch Logs agent on each instance and creates log groups named under /aws/elasticbeanstalk/<environment-name>/, with separate streams for eb-activity.log, the proxy server access logs (nginx or Apache), and the platform-specific application logs. The streaming is per-instance, so when auto-scaling adds a node its logs flow into the same group automatically, and when it removes a node the already-streamed events remain in CloudWatch even though the instance and its EBS volume are gone. That decoupling of log lifetime from instance lifetime is the entire point of the control.

The instance profile attached to the environment must carry logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents, and logs:DescribeLogStreams. The AWS-managed AWSElasticBeanstalkWebTier and AWSElasticBeanstalkWorkerTier policies already include these, so if your environment uses the default service-role setup no IAM change is needed; if you've replaced the managed policy with a custom one, add those actions or the agent silently fails to publish.

# Verify the instance profile can actually publish to CloudWatch Logs.
# Find the instance profile attached to the environment.
aws elasticbeanstalk describe-configuration-settings \
  --application-name payments --environment-name payments-prod \
  --query 'ConfigurationSettings[].OptionSettings[?OptionName==`IamInstanceProfile`].Value' \
  --output text

# Confirm the role grants the logs:* actions the agent needs.
aws iam list-attached-role-policies \
  --role-name aws-elasticbeanstalk-ec2-role \
  --query 'AttachedPolicies[].PolicyName' --output table

# Watch the log groups appear after enabling StreamLogs.
aws logs describe-log-groups \
  --log-group-name-prefix /aws/elasticbeanstalk/payments-prod/ \
  --query 'logGroups[].[logGroupName,retentionInDays]' --output table

What is the impact of not streaming Beanstalk logs?

The primary impact is an audit-trail gap. Frameworks like PCI DSS (clause 10.4.2 specifically, which this control maps to), SOC 2, HIPAA, and ISO 27001 all require that log records be retained for a defined period and be available for review. Elastic Beanstalk's instances are ephemeral by design — auto-scaling, instance replacement, and managed platform updates all destroy instances routinely — so without streaming, your effective log retention is 'until the next scaling event,' which could be hours. That is almost never long enough to satisfy a control that assumes days or months.

The second impact is incident response. When something goes wrong — a spike in 5xx errors, a suspected intrusion, a customer disputing a transaction — the access logs and application logs are the first place responders look. If the instance that served the traffic has since been recycled, those logs are gone, and the investigation stalls before it starts. You're left reconstructing events from CloudTrail and metrics alone, which tells you what API calls happened but not what your application actually did.

The third impact is the silent-failure nature of the gap. Nothing breaks when streaming is off. The application serves traffic, dashboards look green, and the only symptom is an empty /var/log on instances that no longer exist — which you discover only when you go looking, typically under pressure during an audit or an incident. By then the window to capture the missing data has long closed; you cannot retroactively recover logs from a terminated instance.

The cost side is genuinely minor and worth naming so it never becomes an excuse: CloudWatch Logs ingestion runs about $0.50 per GB and storage about $0.03 per GB-month in US-East, so a typical web environment streaming activity and access logs costs a few dollars a month, less if you set a sensible retention period. The trade is a few dollars against a failed audit or a blind incident response — which makes this one of the cheapest High-severity findings to remediate.

How do you remediate ElasticBeanstalk.3 safely?

Remediation is a four-step loop: confirm the current setting, verify the instance profile can publish, enable streaming with the right retention and teardown behaviour, then bake it into your environment templates so new environments are compliant from day one.

1. Inspect the current cloudwatch:logs configuration

Read the aws:elasticbeanstalk:cloudwatch:logs namespace on the environment with describe-configuration-settings. Check StreamLogs (the control fails if it's false), RetentionInDays (default 7 is rarely enough for an audit window), and DeleteOnTerminate (default behaviour you'll want to override to keep evidence). Do this per environment across every account and region in scope — the finding is per-environment.

2. Verify the instance profile has CloudWatch Logs permissions

The EC2 instance profile attached to the environment needs logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents, and logs:DescribeLogStreams. The managed AWSElasticBeanstalkWebTier and AWSElasticBeanstalkWorkerTier policies already grant these, so default setups need no change. If you run a custom instance role, add these actions first — otherwise streaming silently fails to publish and the control stays failed even after you flip StreamLogs.

3. Enable streaming with a deliberate retention and teardown policy

Set StreamLogs=true, choose a RetentionInDays from the allowed enum that matches your audit obligation (90 is a common PCI-aligned choice), and set DeleteOnTerminate=false so the log groups survive when the environment is later destroyed. Apply with a single update-environment call; Beanstalk performs a rolling configuration update with no application downtime, and the log groups appear under /aws/elasticbeanstalk/<env>/ within minutes.

4. Bake it into .ebextensions so new environments inherit it

Add the three options to a .ebextensions/*.config file (or a Saved Configuration) in source control so every environment created from that application is compliant at launch. This converts the control from a recurring per-environment chore into a one-time template change, and it means a freshly spun-up environment never spends time in a failed state waiting for someone to remember the manual step.

# .ebextensions/cloudwatch-logs.config — commit this so every new env is compliant.
cat > .ebextensions/cloudwatch-logs.config <<'EOF'
option_settings:
  aws:elasticbeanstalk:cloudwatch:logs:
    StreamLogs: true
    DeleteOnTerminate: false
    RetentionInDays: 90
EOF

# Or remediate an existing environment in place with one call.
aws elasticbeanstalk update-environment \
  --environment-name payments-prod \
  --option-settings \
    Namespace=aws:elasticbeanstalk:cloudwatch:logs,OptionName=StreamLogs,Value=true \
    Namespace=aws:elasticbeanstalk:cloudwatch:logs,OptionName=DeleteOnTerminate,Value=false \
    Namespace=aws:elasticbeanstalk:cloudwatch:logs,OptionName=RetentionInDays,Value=90

# Confirm the log groups now exist before closing the finding.
aws logs describe-log-groups \
  --log-group-name-prefix /aws/elasticbeanstalk/payments-prod/ \
  --query 'logGroups[].logGroupName' --output table

Quick quiz

Question 1 of 5

An Elastic Beanstalk environment fails ElasticBeanstalk.3. You enable streaming by setting StreamLogs=true but leave the other options at their defaults. What's the remaining risk?

Keep learning

Dig deeper into Elastic Beanstalk logging, the control itself, and the CloudWatch options behind it.

You've completed Stream Elastic Beanstalk logs to CloudWatch. You now know why Beanstalk's ephemeral instances make local log files unreliable, exactly what ElasticBeanstalk.3 checks, and how to remediate it through the aws:elasticbeanstalk:cloudwatch:logs namespace — setting StreamLogs, a deliberate RetentionInDays, and DeleteOnTerminate=false, then baking it into .ebextensions so it never recurs. Next time this finding appears, you'll have a one-command fix and a template change that closes it for good.

Back to the library

Streaming Beanstalk logs: what it means for the books

An audit-evidence gap that only shows up when it's too late to fix

Elastic Beanstalk is a managed way to run web applications where AWS automatically creates and destroys the underlying servers as traffic changes. The catch is that the logs those servers produce — the record of who did what and when — are stored on the server itself. When AWS retires a server, those logs are deleted with it. This control checks whether the environment is set up to copy logs to a durable, central store (CloudWatch) before the server disappears.

From a finance and audit standpoint, this isn't a cost line — it's a control gap. PCI DSS, SOC 2, and similar frameworks all require that you can produce an audit trail covering a defined retention window. If a server holding the only copy of those logs is recycled before the window is up, you have a finding, and findings of this kind can stall an audit, trigger remediation costs, or in regulated settings carry penalties far larger than the few dollars a month CloudWatch storage actually costs.

The reason it lands on a finance or compliance radar at all is that the fix is cheap and the failure is expensive in a category money doesn't normally measure. Turning on streaming costs cents to low dollars per environment per month in CloudWatch ingestion and storage. The cost of not having the logs during an audit or a breach investigation is measured in auditor time, delayed certifications, and reputational risk — none of which appear on the cloud bill but all of which appear on the business.

This lesson is for the finance or compliance partner who needs to understand why an empty CloudWatch console is an audit finding rather than a cost saving. It covers what the control checks, why log retention is a framework requirement (PCI DSS 10.4.2 in particular), what the fix costs versus what the gap costs, and the three governance levers — making streaming a baseline standard, setting a retention period that matches your audit window, and tracking the control's pass rate — that keep this from recurring. No commands, no implementation detail.

Fun fact

The logs that scaled themselves into oblivion

How a finance partner closes the loop

Priya is the finance and compliance partner working with the platform team ahead of the annual PCI assessment. Security Hub shows a High finding — ElasticBeanstalk.3 — against the production payments environment. She doesn't need to know what CloudWatch is at a technical level; she needs to know one thing: can we produce the logs the auditor will ask for, going back as far as our retention policy requires?

The answer today is no, and that's the conversation she opens at the weekly sync. She frames it not as a cost item — the fix is a few dollars a month — but as an audit-readiness gap with a hard deadline. She asks engineering for two commitments: turn streaming on for every in-scope environment this week, and set the retention window to match the documented audit requirement, which for this control is 90 days. Both are confirmed and the finding clears within days.

The follow-through is what she actually owns. She adds 'percentage of in-scope environments streaming logs to CloudWatch' as a standing line on the pre-audit readiness pack, so the gap can't quietly reopen the next time a new environment is spun up. The dollar amount never enters the discussion — the metric is the control's pass rate, and the goal is one hundred percent before the auditor arrives.

Why this matters to compliance, not the budget

This control has almost no direct cost dimension — the fix costs a few dollars a month per environment in CloudWatch storage. Its importance is entirely on the compliance and risk side, which is precisely why it can be overlooked by teams optimising for the cloud bill: there's nothing here to save, only something to protect.

The exposure is an audit-evidence gap. The frameworks that govern regulated workloads — PCI DSS in particular for anything touching cardholder data — require a retained, retrievable audit trail. An environment that doesn't stream logs fails that requirement the moment its instances are recycled, which happens routinely and automatically. A finding of this kind during an assessment can delay a certification, trigger costly remediation under deadline, or in the most regulated settings carry contractual or regulatory penalties.

The right way to value this is as an insurance question, not a cost question. The premium — CloudWatch storage — is trivial. The covered loss — the inability to produce required logs during an audit or breach — is large, uncertain, and falls in a category the cloud bill never shows. For finance, the lever is to ensure log streaming is treated as a standard control with a tracked pass rate, and that the retention period is set deliberately to match the documented audit obligation rather than left at the seven-day default.

What finance can actually do about this

Finance can't change a Beanstalk configuration, but it can make durable log retention a standard and keep it from slipping. Three levers, used at the compliance and budget cadence.

1. Treat log streaming as a baseline control, not a per-team choice

Make 'all in-scope environments stream logs to CloudWatch' a documented standard tied to budget or environment approval, the same way you'd treat encryption at rest. When the control is a precondition rather than a discretionary setting, teams enable it at creation instead of being chased after an audit finding.

2. Set the retention window to match the audit obligation

The seven-day default rarely satisfies a compliance requirement. Agree a retention period with the audit and security teams — 90, 180, or 365 days depending on the framework — and require that RetentionInDays matches it everywhere. This is a one-line policy decision finance can own and that closes the gap between 'logs exist' and 'logs exist long enough to matter.'

3. Track the control's pass rate on the pre-audit pack

Add 'percentage of in-scope environments passing ElasticBeanstalk.3' to the readiness reporting. The target is one hundred percent before any assessment window. Because the fix is cheap and fast, anything short of full coverage is a process gap, not a budget one — and tracking the rate makes the gap visible before the auditor finds it.

4. Price the trade-off correctly in any cost conversation

If anyone proposes leaving streaming off to save money, the answer is the math: a few dollars a month per environment versus a delayed certification or a blind incident investigation. This is an insurance premium, not a cost centre. Naming the asymmetry once usually ends the debate.

Quick quiz

Question 1 of 5

An auditor asks whether you can produce 90 days of application logs for your production payments environment. ElasticBeanstalk.3 currently passes but RetentionInDays is set to 7. As the finance/compliance partner, what's the right read?

Keep learning

Dig deeper into Elastic Beanstalk logging, the control itself, and the CloudWatch options behind it.

You've finished the finance and compliance view of ElasticBeanstalk.3. You know why an empty CloudWatch console is an audit finding rather than a cost saving, why this maps to retention requirements like PCI DSS 10.4.2, and what the three governance levers are — making streaming a baseline standard, matching retention to the audit window, and tracking the pass rate. Next time this control shows up, you'll ask 'can we produce the logs for the full window?' rather than 'what does this cost?'

Back to the library

Streaming Beanstalk logs: the headline

Keeping the evidence after the server is gone

Elastic Beanstalk automatically replaces the servers running your applications. When it does, the logs on those servers — the record auditors and incident responders rely on — are deleted unless the environment is configured to copy them somewhere durable first. This control flags environments where that copy isn't happening.

This is a compliance and resilience issue, not a cost one. The fix is inexpensive and largely a one-time configuration change. The exposure is the opposite: a missing audit trail during a PCI assessment or a security incident, where the cost is measured in failed audits, regulatory findings, and an inability to reconstruct what happened. The leadership question is simply whether log retention is being enforced as a standard, not chased environment by environment.

A short read for the leader who wants the headline and the one question to ask. You'll get why ephemeral infrastructure makes log retention a deliberate choice rather than a default, what this control says about logging discipline more broadly, and what 'good' looks like — every environment streaming logs by standard, with a retention window that matches the compliance obligation. No commands, no implementation.

Fun fact

The logs that scaled themselves into oblivion

What it looks like when the org gets this right

At one fintech, the CISO used to find out about logging gaps the same way everyone does — during an audit, at the worst possible moment. A single High finding on a payments environment could stall a certification for weeks while the team scrambled to explain why the evidence wasn't there.

The shift wasn't technical. The exec sponsor stopped treating log streaming as something each team decided per environment and made it a non-negotiable baseline: every production environment streams its logs to a durable store with a retention window matching the compliance obligation, enforced at provisioning time, not discovered at audit time. The change was written once into the standard deployment templates.

Within a quarter the finding category went to zero and stayed there. The audit conversation moved from 'can you produce these logs?' to 'here is the retention policy and here is the dashboard showing every environment compliant with it.' The cost of the change was negligible; the value was turning an audit risk into a checkbox the team never had to think about again.

Why this is on the report at all

The dollar figure attached to this finding is close to zero. It's on the report because of what it protects: the audit trail that regulators, customers, and your own incident responders depend on. Elastic Beanstalk replaces its servers automatically, and unless the environment is configured to keep the logs elsewhere, that replacement quietly destroys the evidence. The risk is invisible until the day someone needs the logs and they aren't there.

Treat this as a compliance-posture signal rather than a cost item. A clean pass across all in-scope environments means logging discipline is being enforced as a standard. A recurring finding means environments are being provisioned without the control baked in — the same gap that produces audit delays and prolonged incident investigations. The leadership move is to make durable log retention a provisioning standard, not a per-team decision, and to track the pass rate rather than the negligible dollar amount.

The leadership move on this control

The handle for an executive isn't to chase findings — it's to make durable log retention an enforced provisioning standard so the finding stops occurring.

1. Make durable log retention a non-negotiable baseline

Every production environment streams its logs to a durable store, enforced in the standard deployment templates rather than decided per team. This is the single change that takes the finding to zero and keeps it there, and it costs almost nothing to implement.

2. Set retention to match the compliance obligation

Direct that the retention window be set deliberately to match whatever the governing framework requires, not left at the short default. 'Logs exist' and 'logs exist for as long as the auditor will ask about' are different states; only the second one passes.

3. Track posture, not dollars, at the review

Ask for the control's pass rate across in-scope environments, not its cost. 'Is every production environment retaining logs to standard?' is a one-minute item that tells you whether logging discipline is working — and a clean answer for a few quarters means leadership attention belongs elsewhere.

Quick quiz

Question 1 of 5

Security Hub shows ElasticBeanstalk.3 passing on production today, but a brand-new environment spun up last week is already failing it. What's the right leadership response?

Keep learning

Dig deeper into Elastic Beanstalk logging, the control itself, and the CloudWatch options behind it.

That's the lesson. Two takeaways: ephemeral infrastructure destroys its own logs unless you deliberately keep them elsewhere, and this finding is a compliance-posture signal, not a cost line. The leadership move is to make durable log retention a provisioning standard with a retention window that matches the obligation — then track the pass rate, not the dollars.

Back to the library

Stream Elastic Beanstalk logs to CloudWatch

Streaming Beanstalk logs: the basics

The logs that scaled themselves into oblivion

Turning on log streaming in action

Beanstalk log streaming under the hooddeep dive

What is the impact of not streaming Beanstalk logs?

How do you remediate ElasticBeanstalk.3 safely?

1. Inspect the current cloudwatch:logs configuration

2. Verify the instance profile has CloudWatch Logs permissions

3. Enable streaming with a deliberate retention and teardown policy

4. Bake it into .ebextensions so new environments inherit it

Quick quiz

Keep learning

Streaming Beanstalk logs: what it means for the books

The logs that scaled themselves into oblivion

How a finance partner closes the loop

Why this matters to compliance, not the budget

What finance can actually do about this

1. Treat log streaming as a baseline control, not a per-team choice

2. Set the retention window to match the audit obligation

3. Track the control's pass rate on the pre-audit pack

4. Price the trade-off correctly in any cost conversation

Quick quiz

Keep learning

Streaming Beanstalk logs: the headline

The logs that scaled themselves into oblivion

What it looks like when the org gets this right

Why this is on the report at all

The leadership move on this control

1. Make durable log retention a non-negotiable baseline

2. Set retention to match the compliance obligation

3. Track posture, not dollars, at the review

Quick quiz

Keep learning

Related compliance lessons