aws-support-tools is a folder per service, not a package

The unit of this repository is one diagnostic

The README describes the project as a curated collection of diagnostic and troubleshooting tools for AWS services, with each tool living in its own folder and organized by the service it targets. The repository root is a directory listing of service names: `EC2/`, `EKS/`, `Lambda/`, `RDS/`, `S3/`, `SES/`, `SNS/`, `Systems Manager/`, `Cognito/`, `EMR/`, `MWAA/`, `WAF/`, and more.

Most tools are scripts in Python, Bash or PowerShell, and the README's framing is that they help you investigate, fix, or automate something specific. There is no root package.json, no pyproject.toml and no setup script in the top-level entries. There is nothing to `pip install`.

That is the design, and it has a real consequence. A script here is not a dependency you pin and upgrade; it is a file you read, decide whether you trust, and adapt to your account's naming, regions and resource IDs. For a support engineer arriving at a known failure mode, that is faster than writing the diagnostic. For a platform team wanting a maintained tooling layer, it is not what you are looking for.

The audience is stated plainly: these are the tools and sample code provided by AWS Premium Support, which tells you the failure modes they cover are the ones support engineers actually encounter.

The two EKS tools show what good looks like here

The most instructive entries are the two under `EKS/`, because each names a specific error and a specific verification.

`subnet-fragmentation` diagnoses /28 block fragmentation in VPC subnets used for EKS prefix delegation. The failure it explains is the one that wastes an afternoon: a subnet with free IP addresses still fails prefix allocation with InsufficientCidrBlocks, because address space was fragmented earlier and cannot be reassembled. A tool that explains why a counter says there is room while allocation still fails is worth more than a general health check.

`eks-addon-upgrade-check` is a pre-upgrade compatibility check for EKS managed add-ons. It grades an add-on upgrade across multiple signals and emits a Markdown or JSON report with a CI gate exit code. The exit code is the detail that matters: this is built to run in a pipeline and fail the job, not just to print something a human reads.

Both share a shape worth copying in your own tooling. A named error string, a narrow scope, and a defined exit behaviour. That is the difference between a diagnostic and a demo.

The rest is a spread of narrow scripts and samples

The breadth across the root is worth scanning because it shows the range of shapes a support tool takes.

Some are pure inspection. `Lambda/CheckFunctionConcurrency` checks concurrency configuration for functions in a region, and `Lambda/FindEniMappings` answers which functions use a specific ENI, which is the question you have when a networking change broke something. `EBS/VolumeLimitCalculator` computes the maximum available IOPS and throughput for a volume, and `EC2/EC2EBSThroughput` measures and reports EC2-to-EBS throughput rather than inferring it from settings.

Some are remediation. `EC2/EnableIPv6`, `EC2/AutomateDnsmasq`, which handles installation and configuration on Amazon Linux 1 and 2, and `S3/Setup_Replication` for cross-region replication all change your account rather than describe it.

Some are monitoring samples. `SES/CheckSESQuota` checks daily sending quota and notifies through SNS once usage passes 80%, which is a threshold you would otherwise write yourself.

And some are integrations with a human in the loop. `DeviceFarm/TestOutputDownloader` pulls logs, videos and artifacts from a Device Farm console URL specifically so you can share them with AWS Support. `Cognito/decode-verify-jwt` decodes and verifies Cognito JWT tokens. The SNS directory carries four push notification sample projects, APNs for iOS and FCM and GCM for Android, plus `SNSFastPublish` and `SNSReflect`, the latter useful for reaching SMS in regions without SMS support.

Two entries show the lifecycle. `Cognito/identity-pool-integrator-onelogin` tests an identity pool integration against OneLogin SAML, and the MGN Toolkit is marked as moved to the separate awslabs/mgn-toolkit repository.

What you give up by not having a shared layer

Because there is no shared abstraction, every script solves its own problems. Authentication setup, region handling, error formatting and logging are reimplemented per tool, so the ergonomics vary. Windows support is uneven: `Systems Manager/SSMAgent-Toolkit-Windows` is a PowerShell set of checks, `MGNDRS/MGNDRS-Linux-System-Details-Tool` is Linux-specific, and the FSx for NetApp ONTAP diagnostic data collection tool states it is Linux only.

Scripts also age against the service. `EC2/NitroInstanceChecks` checks pre-requisites such as the NVMe module and ENA driver before a migration to a Nitro instance type, and `EC2 Auto Scaling/` covers groups with multiple ENIs, both of which describe a world that has moved on since those situations were common.

That is not a criticism so much as the shape of an artifact built by people solving incidents. The scripts are correct as of when they were written, and the failure modes they cover are the ones that keep recurring.

Running them is also a decision with account consequences. Several of these create, modify or delete resources in your account, and the ones that gather system details collect data you may then be sending to a support case. Read each script before you run it.

Maintenance signals and the licence

The last push was on 2026-09-15 and the repository is not archived. The tags show recent work on the repository itself rather than on the tools: v1.6.0 on 2026-07-10, v1.5.0 on 2026-07-09, and v1.4.0 on 2026-07-08 with a title describing cleanup that removed empty stubs and added cross-references. Three tags in three days suggests someone tidying the index, not a wave of new scripts.

That points to a maintenance model where the collection is curated and the scripts are treated as historical artifacts. Expect cross-references and moved links to keep changing, and expect individual tools to lag behind service changes.

The repository does carry the governance files you would expect: `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `SECURITY.md` and a `CHANGELOG.md` at the root, plus a `.github/` directory.

On licensing, the project is Apache-2.0. For scripts you copy into your own codebase that is a permissive grant with a notice requirement, and for scripts you run unmodified it does not affect what they do in your account.

Editorial conclusion

Adopt aws-support-tools as a source of scripts to read and copy when you hit one of the specific failures it targets, such as a subnet that fails EKS prefix allocation with InsufficientCidrBlocks despite free IPs. Do not expect a maintained library: there is no package to install, no shared abstraction layer, and each script's assumptions age with the service. Verify first that the tool you want still matches your account layout, read it before running it since these scripts act inside your AWS account, and check CHANGELOG.md since tools move, as the MGN Toolkit already did to awslabs/mgn-toolkit.

Frequently asked questions

Official sources

1. awslabs/aws-support-tools on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases