Y

Project · Advanced · about 16 hours

A cloud cost review with savings you can prove

Estimate and measure the cost of running a demo shop, find the biggest savings, implement three of them, and present the trade-offs to a budget owner.

Skills:Cloud platforms (AWS, Azure, Google Cloud), Monitoring and observability, Stakeholder management

Part of: Cloud and Network Engineer

Data and licences

Brief

Cloud cost is an engineering problem: the biggest savings come from architecture and usage, not discounts. Online Boutique gives you a realistic mix of services to analyse. Cost warning: this project uses paid cloud resources. Set a budget alert before you start, stay in the free tier where you can, and destroy everything at the end of each session.

What to build

  1. Deploy the app and run its load generator on a realistic daily pattern for a few days

  2. Build the cost model: compute, storage, load balancers, NAT and data transfer, idle and overnight capacity

  3. Collect utilisation from monitoring and find over-provisioned resources

  4. Implement three savings with Terraform or Kubernetes changes and measure the effect on cost and on your SLOs

  5. Write the recommendation, including savings you chose not to make and why

Deliverables

  • Repository with cost-model/, utilisation data, the changes and RECOMMENDATION.md

How it is graded

Reviewers check that every claimed saving is backed by data and that reliability did not suffer.

Stretch

Add tagging and a weekly cost report per service.

Deliverables

  • A cost model of the architecture with the provider's pricing calculator and real billing data where available
  • Utilisation data for compute, storage and network from monitoring
  • Three implemented savings (for example rightsizing, autoscaling to zero out of hours, storage lifecycle rules) with measured effect
  • A one-page recommendation for a non-technical budget owner

How a reviewer grades it

CriterionWeightWhat good looks like
Cost model is complete, including data transfer and idle resources25%
Savings are based on utilisation data, not guesses30%
Implemented changes keep reliability targets25%
Recommendation is clear about trade-offs20%