Two Cloud Cost Reviews, Two Different Answers

Start with application fit—not the cloud catalogue

For each system, we first studied the application architecture and the cloud resources currently in use. We examined whether services could run safely across multiple instances, which workloads consumed the most resources, which tasks ran only periodically, and whether the application was compatible with current managed services.

Existing load-test evidence helped estimate the CPU and memory each workload required.

We then documented the business requirement, current service, proposed replacement, estimated cost, system impact, and migration effort. Because we did not have access to the clients' billing accounts, cloud pricing calculators were used to estimate the relevant costs. Their exported estimates were shared with the clients to make the assumptions and future comparisons clear.

Move the compatible system to managed services

The first application was suitable for a platform-as-a-service architecture.

Its microservices moved from virtual machines to Azure App Service. Static administration interfaces moved to Azure Static Web Apps. Uploaded files used Azure Storage, scheduled work moved to Azure Functions, and queue-based workloads used a managed Azure messaging service.

Application logs and operational telemetry were brought into Application Insights. A lighter request-routing service replaced an oversized gateway component. Managed TLS and private networking protected external and internal communication.

Autoscaling limits were set using current usage and earlier load tests, with explicit minimum and maximum instance counts to balance availability and cost. Resources were organized into groups with consistent names so spending could be monitored and temporary or unused assets could be identified.

The region was selected by considering application needs, service availability, and cost. Every material change was documented and implemented only after client approval. The client was then asked to monitor actual billing for a month and compare it with the estimate.

Right-size the system that could not be modernized

The second application was a legacy system. It was not compatible with the preferred managed platform services, and its architecture did not support safe distribution across multiple application instances.

Rewriting it purely to obtain a lower cloud bill would have introduced cost and business risk that the client had not approved.

Instead, we deployed it on Amazon EC2 and selected the instance family and capacity using available load-test results. A right-sized managed MySQL database and an Application Load Balancer completed the production setup. CloudWatch metrics and notifications provided visibility into resource usage and emerging capacity needs.

This was not the most modern architecture. It was the most responsible option within the application's constraints.

Keep purchasing decisions evidence-based

In both cases, we considered when on-demand pricing was appropriate and when a reservation or savings commitment might reduce cost. Commitments were recommended only when the workload was stable enough to justify the reduced flexibility.

Final provisioning decisions were confirmed through official client communication. Naming conventions also made test resources and previously used assets easier to identify, helping prevent forgotten infrastructure from continuing to generate charges.

The practical lesson is that cloud cost optimization is not a search for the cheapest service. It is the work of matching architecture, demand, migration risk, and commercial commitment—then documenting the decision clearly enough for the business to approve and verify it.