Definition
- Savings Plans / Reserved Instances – commit to one or three years of usage for large discounts (up to ~70% off on-demand) on steady workloads.
- Spot Instances – use spare AWS capacity at up to ~90% off for fault-tolerant, interruptible work; AWS can reclaim with two-minute warning.
- Right-sizing – match instance types to actual utilization using CloudWatch metrics and Compute Optimizer recommendations.
- S3 lifecycle policies – automatically transition aging data to cheaper storage tiers and expire old objects.
- Environment scheduling – shut down non-production environments outside working hours to eliminate idle spend.
- Cost attribution – tag all resources so each team sees its own spend; set budgets and alerts for surprises.
Think of running National Bank of India's branches. Savings Plans are like signing a long-term lease on the branches you always need, getting a big discount versus paying daily rates. Spot Instances are like cheap temporary staff for overflow work you can pause anytime. Right-sizing is noticing a branch has ten tellers but only needs four. S3 lifecycle tiers are moving old files from the expensive front office to a cheap basement. Turning off dev/test at night is switching off the lights in rooms nobody uses.
Understanding the Concepts
What are Savings Plans and Reserved Instances?
On-demand pricing is the most expensive because it is fully flexible. If a workload runs continuously and predictably, I commit to a Savings Plan or Reserved Instances for one or three years and get a large discount, often up to roughly seventy percent. Savings Plans are generally more flexible because they apply across instance families and even to Fargate and Lambda for the compute variety.
// Commitment-based pricing decision
package com.bank.cost;
public class CommitmentDecision {
public static String recommend(int hoursPerDay, boolean predictable) {
if (hoursPerDay == 24 && predictable) {
return "Savings Plan (1yr or 3yr, up to ~70% off on-demand)";
}
if (hoursPerDay > 16 && predictable) {
return "Savings Plan (partial commitment for baseline)";
}
return "On-demand (flexible, no commitment)";
}
}
What are Spot Instances?
Spot uses spare AWS capacity at up to roughly ninety percent off on-demand, but AWS can reclaim it with a two-minute warning. Spot is perfect for batch jobs, data processing, and stateless workers that can be interrupted and resumed. It is wrong for a stateful always-on service.
// Spot Instance suitability check
package com.bank.cost;
public class SpotSuitability {
public static String assess(boolean interruptible, boolean stateless) {
if (interruptible && stateless) {
return "Spot (up to ~90% off, suitable for batch/processing)";
}
return "On-demand or Savings Plan (needs uninterrupted availability)";
}
}
How does right-sizing work?
I look at real CPU, memory, and network utilization over time using CloudWatch metrics. If an instance sits at ten percent CPU, I move it to a smaller instance type, saving money with no performance loss. AWS Compute Optimizer and Cost Explorer's rightsizing recommendations automate much of this analysis.
// Right-sizing analysis
package com.bank.cost;
public class RightSizingAnalyzer {
public static String analyze(double avgCpuPercent, double avgMemPercent) {
if (avgCpuPercent < 15 && avgMemPercent < 30) {
return "OVERSIZED: downgrade to smaller instance type";
}
if (avgCpuPercent > 80 || avgMemPercent > 85) {
return "UNDERSIZED: upgrade or enable auto-scaling";
}
return "RIGHT-SIZED: current instance type is appropriate";
}
public static void main(String[] args) {
System.out.println(analyze(10.0, 25.0)); // OVERSIZED
System.out.println(analyze(85.0, 70.0)); // UNDERSIZED
System.out.println(analyze(45.0, 55.0)); // RIGHT-SIZED
}
}
How do S3 lifecycle policies save money?
Data that is hot now becomes cold later. Lifecycle rules transition objects from Standard to Standard-IA, then to Glacier, and finally expire them. At National Bank of India, old statement data moved through lifecycle tiers, cutting storage cost by over ninety percent for data nobody reads.
// Cost savings from lifecycle tiering
package com.bank.cost;
import java.math.BigDecimal;
public class LifecycleSavingsCalculator {
public static void main(String[] args) {
long dataGB = 50_000;
BigDecimal standardCost = BigDecimal.valueOf(dataGB).multiply(new BigDecimal("0.023"));
BigDecimal deepArchiveCost = BigDecimal.valueOf(dataGB).multiply(new BigDecimal("0.00099"));
BigDecimal savings = standardCost.subtract(deepArchiveCost);
System.out.println("50 TB in Standard: $" + standardCost + "/month");
System.out.println("50 TB in Deep Archive: $" + deepArchiveCost + "/month");
System.out.println("Monthly savings: $" + savings + " (" +
savings.multiply(BigDecimal.valueOf(100)).divide(standardCost, 0, java.math.RoundingMode.HALF_UP) + "%)");
}
}
How does environment scheduling work?
Development and test environments usually do not need to run nights and weekends. A scheduler (Lambda + EventBridge or Instance Scheduler) stops them in the evening and starts them in the morning. Since they only run about 50 hours out of 168 in a week, this cuts their cost by roughly two-thirds.
// Environment scheduling savings
package com.bank.cost;
public class EnvironmentScheduler {
public static void main(String[] args) {
int totalHoursPerWeek = 168;
int runHoursPerWeek = 50; // Mon-Fri 8am-6pm
double savingsPercent = (1.0 - (double) runHoursPerWeek / totalHoursPerWeek) * 100;
System.out.println("Dev/test runs " + runHoursPerWeek + "h out of " + totalHoursPerWeek + "h per week");
System.out.println("Savings: ~" + (int) savingsPercent + "% of compute cost");
}
}
What is cost attribution with tagging?
Tag all resources so each team sees its own spend. Without tags, cost is a single undifferentiated bill and nobody owns the waste. With tags, teams see their impact and can optimize. Set budgets and alerts in AWS Budgets to catch surprises early.
// Tagging strategy
package com.bank.cost;
import java.util.Map;
public class CostTaggingStrategy {
public static Map<String, String> requiredTags() {
return Map.of(
"Team", "payments",
"Environment", "production",
"CostCenter", "CC-1234",
"Application", "transfer-service"
);
}
public static void main(String[] args) {
System.out.println("Required tags for all resources:");
requiredTags().forEach((k, v) -> System.out.println(" " + k + ": " + v));
}
}
What about cleaning up waste?
Beyond the main levers, delete unattached EBS volumes, idle load balancers, unused Elastic IPs, and old snapshots. These are small individually but add up over time. AWS Trusted Advisor and Cost Explorer flag these.
// Waste cleanup checklist
package com.bank.cost;
import java.util.List;
public class WasteCleanupChecklist {
public static final List<String> ITEMS = List.of(
"Unattached EBS volumes (paying for storage nobody uses)",
"Idle load balancers (hourly charge with no traffic)",
"Unused Elastic IPs (charged when not attached to a running instance)",
"Old EBS/RDS snapshots beyond retention policy",
"Stopped EC2 instances (EBS volumes still charged)"
);
public static void main(String[] args) {
System.out.println("Waste cleanup checklist:");
ITEMS.forEach(i -> System.out.println(" - " + i));
}
}
What should a senior engineer know?
Cost optimization is a continuous discipline, not a one-time cleanup, and it must never silently trade away reliability. I combine levers: commit to the steady baseline with a Savings Plan, burst on Spot or on-demand above it, right-size continuously, and tier storage. I tie the baseline commitment to a well-understood steady load so I do not over-commit. And I always verify that cost-saving changes do not degrade production reliability.
Visual Overview
AWS Cost Optimization Levers ┌──────────────────────────────────────────────────────┐ │ Monthly AWS Bill │ │ │ │ ┌───────────────────────────────────────────────┐ │ │ │ 1. Savings Plans / RIs (steady baseline) │ │ │ │ Commit 1-3yr -> up to ~70% off on-demand │ │ │ └───────────────────────────────────────────────┘ │ │ ┌───────────────────────────────────────────────┐ │ │ │ 2. Spot Instances (interruptible batch) │ │ │ │ Spare capacity -> up to ~90% off │ │ │ └───────────────────────────────────────────────┘ │ │ ┌───────────────────────────────────────────────┐ │ │ │ 3. Right-sizing (match type to actual usage) │ │ │ │ CloudWatch + Compute Optimizer │ │ │ └───────────────────────────────────────────────┘ │ │ ┌───────────────────────────────────────────────┐ │ │ │ 4. S3 Lifecycle (tier aging data) │ │ │ │ Standard -> IA -> Glacier -> Deep Archive │ │ │ └───────────────────────────────────────────────┘ │ │ ┌───────────────────────────────────────────────┐ │ │ │ 5. Environment scheduling (off at night) │ │ │ │ Dev/test: ~70% savings │ │ │ └───────────────────────────────────────────────┘ │ │ ┌───────────────────────────────────────────────┐ │ │ │ 6. Waste cleanup + tagging + budgets │ │ │ │ Visibility, attribution, alerts │ │ │ └───────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────┘
Key Takeaway
Cost optimization on AWS is about matching supply to real demand and paying the lowest appropriate price for each workload without hurting performance or reliability. For steady, predictable workloads I commit to a Savings Plan for up to roughly seventy percent off on-demand. For fault-tolerant, interruptible batch work I use Spot Instances at up to ninety percent off. For everything running, I right-size continuously using CloudWatch metrics and Compute Optimizer. For storage, S3 lifecycle policies move aging data to cheaper tiers automatically.
Beyond compute and storage, I schedule dev/test environments to shut down nights and weekends (cutting their cost by about two-thirds), tag all resources for cost attribution so each team sees its own spend, and set budgets and alerts to catch surprises early. I also clean up waste like unattached EBS volumes and idle load balancers.
The senior point is that cost optimization is a continuous discipline, not a one-time cleanup, and it must never silently trade away reliability. I combine levers: commit to the steady baseline, burst above it on Spot or on-demand, and keep right-sizing as usage changes.
At National Bank of India I applied this mix. The always-on core ledger went onto a Savings Plan. The nightly fraud-analysis batch ran on Spot. I right-sized a fleet of web servers that CloudWatch showed running at ten percent CPU. Old statement data moved through S3 lifecycle tiers into Deep Archive. Dev/test environments switched off every evening and weekend. Together these cut our monthly bill substantially with no impact on production reliability.
Remember one sentence: optimize AWS costs with Savings Plans for steady workloads, Spot for batch, right-sizing from metrics, S3 lifecycle tiering, and environment scheduling -- it is a continuous discipline, not a one-time project.
---