Memory leak and background process auditor for AWS Marketplace AMIs

A developer or DevOps engineer deploys an AMI from AWS Marketplace, everything looks fine in testing, then in production they start getting OOM kills, sluggish response times under concurrent load, and processes that keep running after sessions close — exactly the pattern described across Tomcat, phpMyAdmin, Apache Drill, and the ECS/EKS AMIs here. They spend hours profiling manually to figure out whether the leak is in their code or in the base image they bought.

The gap persists because AMI vendors have no incentive to surface this information — their listings have no standardized performance disclosure, AWS Marketplace review fields don't capture memory behavior over time, and the buyer (an engineering team) and the user (a developer doing incident response at 2am) are often different people. Nobody loudly complains to the vendor; they just work around it or churn silently.

What's missing is a repeatable, automated baseline: deploy the AMI, run a realistic stress profile (concurrent sessions, large dataset fetches, shutdown and residual process check), and get a report that shows RSS growth over time, GC pause frequency, and what's still running 5 minutes after a clean shutdown. Today engineers either run ad-hoc scripts they wrote themselves or stare at CloudWatch metrics that tell them something is wrong but not what or where.

This is a business and not a feature because the need recurs every time a new AMI version is released, every time an organization evaluates a new Marketplace listing, and every time a production incident makes someone ask 'was this always broken or did something change?' Each of those moments has a concrete cost: engineering hours spent on manual profiling, delayed deployments, or production incidents that could have been caught earlier.

What to build

Build a CLI tool and accompanying web dashboard that deploys any AWS Marketplace AMI into a sandboxed VPC, runs a configurable load profile (concurrent sessions, large dataset operations, clean shutdown), and produces a structured report showing memory growth curves, residual background processes, and GC event frequency — so engineers can compare AMI versions or vendor offerings before committing to production.

Where to start

Start with teams running Apache Tomcat or phpMyAdmin AMIs who have already filed or seen memory leak complaints, where the failure mode is well-documented and you can demonstrate a known issue in a demo environment before the customer runs their first real test.

The hard part

Getting the load profiles realistic enough to surface real leaks without requiring the buyer to hand over application-specific test scripts — too generic and the report is noise, too custom and onboarding is a services engagement.

How it makes money

Usage-based pricing per AMI audit run, with a monthly subscription tier for teams that run audits on every new AMI release or as part of CI/CD pipelines.