Start a project
AWS Cost Optimization

Make your cloud work harder. Not your cloud bill.

An AWS bill is a design document. Read carefully, it tells you exactly which architectural decisions are being paid for every month.

In short

Yes — JANNEX provides AWS cost optimization. The work covers rightsizing, removal of unused and orphaned resources, storage lifecycle and class selection, compute and autoscaling configuration, non-production scheduling, data transfer review, pricing-model selection such as Savings Plans and Reserved Instances, tagging, budgets and alerting, and an ongoing FinOps operating rhythm.

The problem

Where cloud bills go wrong

Rarely one large mistake. Usually a hundred small decisions that were correct at the time and were never revisited.

  • Instances sized for a launch-day estimate that never happened
  • Volumes and snapshots outliving the instances they belonged to
  • Non-production environments running through nights and weekends
  • Logs and backups on the most expensive storage class, indefinitely
  • Cross-AZ and egress traffic nobody has ever attributed
  • On-demand pricing for workloads that have run continuously for two years
  • Load balancers, NAT gateways and IPs attached to nothing
Approach

Architecture → Usage → Waste → Optimization → Monitoring

A review that ends in a spreadsheet changes nothing. The point is a set of changes, sequenced by risk, and a practice that stops the drift returning.

01

Architecture

Read the design and the bill together. Cost is a consequence of architecture; the largest savings are usually structural.

02

Usage

Actual utilisation over a representative period — not peak, not averages that hide a nightly idle.

03

Waste

Orphaned, idle and duplicated resources identified and mapped to an owner before anything is removed.

04

Optimization

Changes sequenced from zero-risk deletions, through rightsizing and scheduling, to commitment purchases and architectural work.

05

Monitoring

Tagging, budgets, anomaly alerts and a monthly review, so the improvement holds.

Capabilities

What this covers

01

Immediate waste

  • Unattached volumes and elastic IPs
  • Orphaned snapshots and AMIs
  • Idle load balancers and NAT gateways
  • Abandoned environments
  • Duplicate data copies
02

Rightsizing & scheduling

  • Compute rightsizing from utilisation data
  • Database instance sizing
  • Autoscaling policy review
  • Non-production start/stop schedules
  • Graviton and modern-family migration
03

Storage & transfer

  • S3 storage class and lifecycle policy
  • Log and backup retention
  • EBS type selection
  • Cross-AZ traffic review
  • Egress and CDN strategy
04

Commercial & practice

  • Savings Plans and Reserved Instance modelling
  • Spot suitability analysis
  • Tagging standard and enforcement
  • Budgets and anomaly alerts
  • Monthly FinOps review
The journey

Architecture → Usage → Waste → Optimization → Monitoring

A review that ends in a spreadsheet changes nothing. The output is a sequenced set of changes, each costed from your own usage data, each with a rollback path.

01

Architecture

Read the design and the bill together. Cost is a consequence of architecture, and the largest reductions are usually structural rather than clerical.

02

Usage

Measured utilisation over a representative period, including peaks and month-end, rather than averages that conceal a nightly idle.

03

Waste

Orphaned, idle and duplicated resources identified and mapped to an owner before anything is removed.

04

Optimization

Changes sequenced by risk: deletions, then scheduling, then rightsizing, then commitment purchases, then architectural work.

05

Monitoring

Tagging enforced, budgets and anomaly alerts routed to an owner, and a short monthly review so the result holds.

On savings figures

We do not publish a percentage. Any number quoted before seeing an account is marketing rather than analysis. A review returns a specific list of changes with the estimated monthly effect of each, calculated from your own Cost and Usage Report.

Stack

Technology

The working set for this capability. Choices are made per engagement, against your constraints and your team's skills.

AWS Cost ExplorerCost and Usage ReportAWS BudgetsCompute OptimizerTrusted AdvisorCloudWatchS3 Storage LensTerraformAthenaTagging policies
Use cases

Where it is typically applied

Patterns we see repeatedly, described generically. Your version will differ in the details, and the details are the work.

A bill that grew faster than traffic

Usually storage lifecycle, log retention and non-production environments — found by attribution, not by guessing.

A migration that cost more than the data centre

Lift-and-shift sizing carried over from physical hardware, corrected against measured utilisation.

Spend nobody can attribute

A tagging standard applied and enforced, so cost can be assigned to a team, product or customer.

Commitment purchases made blind

Savings Plans and Reserved Instances modelled against actual usage patterns before anything is committed for one or three years.

Method

How the engagement runs

The same seven stages, scoped to the size of the problem.

01

Understand

We start with the constraint, not the feature list. What breaks today, who it affects, what it costs.

02

Define

A written scope with the trade-offs made explicit — what is in, what is deferred, what we will measure.

03

Design

Interfaces, data models and system boundaries designed together, because they constrain each other.

04

Build

Short cycles against a working environment. Reviewed code, tests where they earn their keep.

05

Launch

Staged rollout with monitoring in place before traffic, not after the first incident.

06

Learn

Instrumented usage read against the thing we said we would measure at Define.

07

Scale

Performance, cost and operations tuned once real load has told us where the pressure is.

FAQ

Questions we are asked

How much can we save?

We do not publish a percentage, because any number quoted before seeing an account is marketing rather than analysis. A review returns a specific list of changes with the estimated monthly effect of each, calculated from your own usage data.

Will optimization hurt performance?

It should not, and that is the constraint we work under. Changes are sequenced from zero-risk deletions upward, with rightsizing based on measured utilisation including peaks, and with headroom retained deliberately rather than by accident.

What access do you need for a review?

Read-only. A billing and read access role plus the Cost and Usage Report is enough to produce findings. Nothing is changed without your approval and a rollback path.

Is this a one-off exercise?

The clean-up is. Keeping it clean is not. Without tagging, budgets, anomaly alerts and a monthly review, most estates drift back within a year — so the practice is part of the engagement.

Do you take a share of the savings?

We quote for the work. Percentage-of-savings arrangements create an incentive to find large numbers rather than correct ones.

Next

Have something worth building?

Tell us the constraint you are working against. If we are not the right people for it, we will say so.

Or write to connect@jannex.in