enable agentless for aws metrics

[MichaelKatsoulis]

Proposed commit message

• WHAT: Enable agentless deployment for cloudwatch_metrics, ebs, ec2_metrics, ecs_metrics, s3_daily_storage, s3_request
• WHY: Users won't need to deploy a manual agent

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

Related issues

• [AWS Metrics] Enable agentless mode for AWS metrics Integrations #19283

Screenshots

[github-actions]

Elastic Docs Style Checker (Vale)

Summary: 1 suggestion found

💡 Suggestions (1): Optional style improvements. Apply when helpful.

File	Line	Rule	Message
packages/aws/changelog.yml	7	Elastic.WordChoice	Consider using 'deactivate, deselect, hide, turn off' instead of 'Disable', unless the term is in the UI.

---

The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

[zmoog]

I think we can now also add the release property. Same for all other occurrences of deployment_modes.agentless in this PR.

See #18552 for more details.

[MichaelKatsoulis]

Thanks! Done in fe4fdf9

[MichaelKatsoulis]

I have tested all the datastreams and they work as expected with one exception.

s3_daily_storage integrations keeps throwing those error:

the document timestamp [2026-06-02T00:00:00.000Z] is outside of ranges of currently writable indices [[2026-06-03T07:07:46.000Z,2026-06-03T10:30:49.000Z]]

The aws.s3_daily_storage data stream is configured with index_mode: time_series (TSDS). TSDS must be enforcing a writable time window on each index (default 2h). Documents whose @timestamp is older than now − look_back_time are rejected at ingest.

CloudWatch publishes S3 storage metrics once per day with a timestamp at 00:00 UTC of the each day it measured. There can also be a publication delay. By the time the agent polls and forwards the document, its @timestamp can already be well outside the 2h window . So every document is dropped and no data lands in the index.

This is independent of deployment mode (agentless / managed agent / standalone).

I found that ES has merged this PR
that adds a index.look_back_time index setting that sets the index.time_series.start_time setting for the first backing index when a data stream is created.

But it does not seem to be supported in the package spec https://github.com/elastic/package-spec/blob/5b548159e229eadd65402672145fa55a8417caae/spec/integration/data_stream/manifest.spec.yml#L257

@jsoriano Maybe that is something your team could support!

I manually changed it in Kibana through a custom pipeline.

PUT _component_template/metrics-aws.s3_daily_storage@custom
{
  "template": {
    "settings": {
      "index": {
        "look_back_time": "48h"
      }
    }
  }
}


POST metrics-aws.s3_daily_storage-default/_rollover


GET metrics-aws.s3_daily_storage-default/_settings?filter_path=**.look_back_time

But that is a manual thing the user needs to do.
Until it is supported in the package spec I will go on and remove tsdb from s3_daily_storage as done in the datastreams like AWS Billing

[jsoriano]

But it does not seem to be supported in the package spec https://github.com/elastic/package-spec/blob/5b548159e229eadd65402672145fa55a8417caae/spec/integration/data_stream/manifest.spec.yml#L257

@jsoriano Maybe that is something your team could support!

Issue created for that: elastic/package-spec#1179

Thanks for checking it works with @custom!

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[MichaelKatsoulis]

Issue created for that: elastic/package-spec#1179

Thank you @jsoriano !

[MichaelKatsoulis]

@zmoog , @agithomas and @andrewkroh
Could I get a review on this?

[zmoog]

LGTM.

I think the only thing missing now is the "How do I deploy this integration?" section in the data stream docs.

[MichaelKatsoulis]

I think the only thing missing now is the "How do I deploy this integration?" section in the data stream docs.

Oh yeah! I will add!

@zmoog Done in 278d014

[github-actions]

TL;DR

Two checks failed due to PR-scoped metadata/docs drift, not runtime code execution: check_changelog_entries.sh found stale PR links in packages/aws/changelog.yml, and test_one_package.sh reported generated AWS docs are out of date for ebs.md, ec2.md, ecs.md, and s3.md.

Remediation

• Update the two stale changelog links in packages/aws/changelog.yml from https://github.com/elastic/integrations/pull/19283 to https://github.com/elastic/integrations/pull/19339.
• Rebuild and commit generated AWS docs so checked-in docs match package generation output (the failing step explicitly indicates ebs.md, ec2.md, ecs.md, s3.md are outdated): run elastic-package build and commit the resulting doc updates.

Investigation details

Root Cause

1. Changelog PR link mismatch (configuration/metadata issue)

   • Job :scroll: Check changelog PR links failed in .buildkite/scripts/check_changelog_entries.sh.
   • The script expected all changelog PR links to point to PR #19339, but found two entries still pointing at PR #19283 in packages/aws/changelog.yml.

2. Generated docs drift (documentation generation mismatch)

   • Job Check integrations aws failed in .buildkite/scripts/test_one_package.sh packages/aws ....
   • The package check reports markdown drift and explicitly says the following files are outdated and should be rebuilt: packages/aws/docs/ebs.md, packages/aws/docs/ec2.md, packages/aws/docs/ecs.md, packages/aws/docs/s3.md.

Evidence

• Build: https://buildkite.com/elastic/integrations/builds/44125
• Job/step: :scroll: Check changelog PR links
  • Key excerpt:
    • ERROR: unexpected link: 'https://github.com/elastic/integrations/pull/19283'
    • expected: 'https://github.com/elastic/integrations/pull/19339'
    • --- 2 changelog link(s) do not match this PR
• Job/step: Check integrations aws
  • Key excerpt:
    • ebs.md is outdated. Rebuild the package with 'elastic-package build'
    • ec2.md is outdated. Rebuild the package with 'elastic-package build'
    • ecs.md is outdated. Rebuild the package with 'elastic-package build'
    • s3.md is outdated. Rebuild the package with 'elastic-package build'
    • Error: checking package failed: checking readme files are up-to-date failed: files do not match

Verification

• Not run locally in this workflow; conclusions are based on the failing Buildkite job logs and their explicit mismatch diagnostics.

Follow-up

• After applying the two fixes above, rerun the Buildkite pipeline for PR #19339.

Note

🔒 Integrity filter blocked 3 items

The following items were blocked because they don't meet the GitHub integrity level.

• #19339 pull_request_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• enable agentless for aws metrics #19339 pull_request_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• enable agentless for aws metrics #19339 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

---

What is this? | From workflow: PR Buildkite Detective

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[mrodm]

Changelog link mismatch — expected https://github.com/elastic/integrations/pull/19339 in the following file(s):

• packages/aws/changelog.yml

Tip

Add the changelog-link-check:skip label to skip this check.

View Buildkite build @MichaelKatsoulis

This is a new check that we're giving a try to keep the changelog links in sync with the pull requests.

In this case , it fails because it has been set a pull request link that it does not match with the pull request opened.

    link: https://github.com/elastic/integrations/pull/19283

It looks like that maybe you wanted to use the issue link instead ?https://github.com/elastic/integrations/issues/19283 ?

If it is set that issue link in the changleog entry, this check would run successfully too.

Currently, this check is just informative and it is not blocking.

Updated the message shown in those comments #19379

[MichaelKatsoulis]

This is a new check that we're giving a try to keep the changelog links in sync with the pull requests.

@mrodm That's a very good addition or else such a mistake would have been merged undetected.

[elastic-vault-github-plugin-prod]

✅ All changelog entries have the correct PR link.

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: dffae30

History

• 💚 Build #44137 succeeded a83f196
• 💔 Build #44125 failed 278d014
• 💔 Build #44119 failed 73a4fd1
• 💔 Build #44090 failed bcb058d
• 💚 Build #44008 succeeded 875078f

[elastic-vault-github-plugin-prod]

Package aws - 6.20.0 containing this change is available at https://epr.elastic.co/package/aws/6.20.0/