Knowing what is running is not the same as knowing why
Most tools tell you what is running. The Lens holds why it is built the way it is, the decisions made at onboarding, the intent behind them and what to prioritise or ignore. It then checks every change against that, so nothing quietly drifts.
Ask it about costs, incidents or risks and get charts, tables and recommendations in Slack, in your AI assistant or as a report. Fixes arrive as pull requests your team reviews.
Talk to UsAsk a question, get an answer you can act on
Stay informed about your AWS environment and make better decisions.
@Infrastructure Lens show me the current split of our AWS costs and suggest any savings you can see from our usage patterns
Monthly AWS spend for the last six months, by service. Spend is up 21%, mostly EC2 in production.
| Recommendation | Est. saving / month |
|---|---|
| Rightsize 14 over-provisioned EC2 instances in production | $3,200 |
| Reserve the steady-state RDS instances | $2,100 |
| Turn dev and staging off overnight and at weekendsConfigure Start/Stop | $1,050 |
| Delete 2.1 TB of unattached EBS snapshots | $410 |
| Total | $6,760 |
ECS service checkout-api is down in production
0 of 3 tasks running since 9:38 AM. Tasks are exiting with code 137 (out of memory).
This started 4 minutes after release #482, which added image resizing to checkout. Task memory is 512 MB. The last healthy task definition is revision 56.
Recommended first steps
- Roll back checkout-api to task definition revision 56 to restore service.
- Raise task memory from 512 MB to 1 GB before redeploying release #482.
- Check the image resizing change in release #482 for unbounded memory use.
Approved. Rolling back now.
Rollback sent through your deployment pipeline. ✓ checkout-api is healthy on revision 56, with 3 of 3 tasks running.
@Infrastructure Lens how do we stop this happening again?
I reviewed 90 days of releases, metrics and the checkout-api architecture. This is the third out-of-memory failure since July, and each one followed a release that raised memory use.
checkout-api peak memory, last 90 days
Recommendations
- Add a pre-release check that blocks releases using more than 80% of task memory in staging.
- Turn on the ECS deployment circuit breaker so failed releases roll back automatically.
- Scale checkout-api on memory as well as CPU.
I have opened pull request #491 with these changes for your review.
What you can ask
Answers come from your AWS state, your infrastructure code and the decisions captured at onboarding, so they explain why, not just what.
Where is the money going?
Cost split by service and team, anomalies, rightsizing and scheduling, with estimated savings.
Configure Start/StopIs this alert real, and what do we do first?
Alerts with the context behind them, recent changes, dependencies and recommended first steps.
How do we stop this happening again?
Patterns across releases and incidents, and changes checked against your architecture decisions.
Where are we exposed?
IAM and access analysis, and findings mapped to SOC 2, ISO 27001 and PCI.
Answers, alerts, reports and fixes, in the tools your team already uses
Slack
Ask questions, get alerts and reply in thread. Approve actions before they go through your control path.
Pull requests
Fixes arrive as pull requests in GitHub, with the context behind each change. Your team reviews and merges.
Reports
Environment health, cost and security posture over time, ready for your leadership team and board.
Your AI assistant
Ask from Cursor, Claude Desktop or Claude Code over MCP, signed in as you and read-only.
Connect your AI assistantCLI checks
Run the same analysis against a branch, a stack or a new service before it reaches production.
Your engineers and ours
base2 engineers explain the why, what to fix first and what patterns to break.
Read-only in your AWS accounts, nothing changes without your approval
The Lens reads and recommends. Changes go through the path your team already trusts.
- Read-only accessThe Lens reads your AWS accounts. It does not change them.
- No shared standing keysPeople sign in as themselves, and every request is audited.
- Your approval pathChanges go through pull requests, pipelines, CloudFormation or base2 tools, never around your review.
- ISO 27001 certified operationsRun by base2Services under ISO 27001:2022 controls.
How you start
- 01ConnectGrant read-only access to your AWS accounts. Agents are running within one to two weeks.
- 02Capture intentWe record your architecture decisions and what to prioritise or ignore.
- 03Ask and receiveQuestions, alerts, reports and pull requests start arriving where your team works.
- 04Review togetherOur engineers walk through findings with you and keep the roadmap on track.