Cost Optimization #

In the world of cloud computing, Cost Optimization is often misunderstood as merely aggressively cutting IT budgets. Many organizations make the mistake of randomly stopping critical servers to push down monthly bill figures, which ultimately damages application performance and user service availability. The true philosophy of cost optimization is maximizing software engineering unit efficiency — getting the highest possible business value from every rupiah we pay to cloud providers. Expensive infrastructure resources that successfully process millions of business transactions smoothly are highly productive investments. Conversely, small virtual machines never used by anyone are pure waste. This article presents a stack of practical strategies for finding waste, aligning capacity with real consumption, and keeping our cloud architecture lean without sacrificing system reliability.

Framework: Identify, Prioritize, Optimize, Verify, Iterate #

Cloud cost efficiency can’t be achieved through momentary panic when bills spike. We need a structured, repeatable framework for managing cloud spending periodically:

              COST EFFICIENCY HANDLING CYCLE
              
   1. IDENTIFY   --> Find waste (idle VMs, orphaned disks) via
                     Cost Explorer dashboard & billing log analysis.
         |
   2. PRIORITIZE --> Sort findings by savings level and technical 
                     effort (focus on quick-wins).
         |
   3. OPTIMIZE   --> Execute fixes safely (rightsizing,
                     tier migration, or scheduling additions).
         |
   4. VERIFY     --> Monitor billing in the next cycle to ensure
                     savings occurred without negative side effects.
         |
   5. ITERATE    --> Repeat the audit process periodically because
                     cloud infrastructure systems always change dynamically.

1. Identify #

We scan the entire cloud ecosystem using built-in cloud analysis tools (like AWS Trusted Advisor or GCP Recommender) to detect resources with low or completely unused utility.

2. Prioritize #

Not all optimization recommendations must be completed at once. We divide findings using an impact vs effort matrix:

• High Impact, Low Effort (Quick Wins): Deleting empty disks not connected to servers or shutting down abandoned sandbox VMs. These scenarios should be completed within 24 hours.
• High Impact, High Effort: Transforming monolithic database architecture into distributed databases. These scenarios must be structurally planned in engineering sprints.

3. Optimize #

Engineering teams execute changes safely in staging environments first before releasing rightsizing configurations to production environments.

4. Verify #

We ensure server specification downgrades truly cut financial spending on the next invoice, without causing user-facing service latency degradation.

5. Iterate #

Cloud environments are dynamic — new code keeps releasing, infrastructure keeps scaling. Therefore, we must run this audit cycle routinely (e.g., every quarter).

Compute Optimization #

Compute is the largest waste area and simultaneously the fastest potential savings contributor in the cloud. The two main strategies in this area are Rightsizing and Orphaned Resource Cleanup.

1. Rightsizing — Matching Capacity to Workloads #

Rightsizing is the action of downgrading virtual machine type or size specifications to match our application’s real consumption needs.

• Detecting Over-provisioned Instances: If a VM runs 24/7 for 2 consecutive weeks with average CPU utility below 10% and RAM usage below 20%, that server is a strong candidate for specification downgrade.

• Savings Simulation: Suppose we run an application server on an m5.4xlarge instance (16 vCPU, 64 GB RAM) priced at $0.768 per hour. Monitoring proves average CPU usage is only 5%. We decide to rightsize to the m5.large type (2 vCPU, 8 GB RAM) priced at $0.096 per hour.

  $$\text{Savings Percentage} = \frac{$0.768 - $0.096}{$0.768} \times 100% = 87.5%$$

  Just by downgrading one overly loose server specification, we save 87.5% of compute costs on that instance.

• Safe Rightsizing Strategies:

  • Downgrade specifications gradually (one level down first, e.g., from xlarge to large).
  • Focus on peak usage statistics, not just monthly averages, to guarantee servers have traffic spike handling room (headroom).

2. Cutting Off Orphaned Resources #

Orphaned resources are cloud infrastructure components no longer connected to any application but still active and continuously triggering financial bills.

flowchart TD
    subgraph Audit ["Resource Audit Process"]
        Scan["1. Scan Infrastructure (Cron Job)"]
        VerifyIdle{"2. Is the Resource Idle / Untagged?"}
    end

    subgraph Remediasi ["Automatic Cleanup Actions"]
        Alert["3. Send Warning to Slack Owner\n(Give 48-Hour Deadline)"]
        CheckClaim{"4. Did the Owner Claim / Update Tags?"}
        Keep["5. Keep the Resource"]
        Terminate["6. Destroy the Resource (Auto-Terminate)\n- Delete VM & volumes\n- Release Elastic IP"]
    end

    Scan --> VerifyIdle
    VerifyIdle -- Yes --> Alert
    VerifyIdle -- No --> Keep

    Alert --> CheckClaim
    CheckClaim -- Yes --> Keep
    CheckClaim -- No / Expired --> Terminate

Based on the cleanup automation flowchart above, we must comb through the following components:

• Unattached Disk Volumes: When we delete a VM, its storage disks (block storage) often remain with Available status. These disks are still fully billed per GB/month. We must create automated scripts detecting empty disks and deleting them if idle for more than 7 days.
• Unassigned Elastic IPs: Reserved static public IP addresses not connected to active VMs incur hourly penalty fees from cloud providers to prevent global IP allocation waste.
• Empty Load Balancers: Load balancers with no healthy target instances behind them still incur running hourly costs.

Storage Optimization #

Cloud data storage can be optimized without sacrificing data retention through intelligently applied object lifecycle policies.

• Object Storage Lifecycle: We must configure automatic storage transitions based on data age. Newly written application log data goes to Hot Storage (Standard Tier) for fast analysis. After 30 days, that log data automatically moves to Warm Storage (Infrequent Access Tier) saving up to 50%. After 90 days, data moves to Cold Storage (Glacier/Archive) for 80% savings, and is automatically destroyed after passing 7 years for legal regulation compliance.
• Delete Incomplete Multipart Uploads: When our application uploads large files to object storage and connections break midway, those failed file fragments remain stored in buckets and get billed. Configure bucket lifecycle policies to automatically delete incomplete multipart upload remnants after 7 days.

Network & Data Transfer Optimization #

Outbound (egress) data transfer costs to the internet can be reduced by designing cost-aware cloud network topologies.

1. Use Content Delivery Networks (CDNs) #

Reading static files (like image assets, CSS files, JavaScript, or PDF documents) directly from our application servers triggers expensive regular egress costs ($0.09/GB). By placing a CDN (like Cloudflare or CloudFront) in front of our web applications, that data gets cached on networks closest to users. Besides speeding up page load times, CDN egress rates are generally far cheaper (saving up to 60%) compared to direct cloud origin server egress rates.

2. Apply VPC Endpoints for Internal Traffic #

By default, if our VM instances in private subnets want to upload files to Object Storage buckets (S3), data traffic must traverse NAT Gateways toward the public internet before re-entering the S3 bucket. This process triggers NAT Gateway data processing costs of $0.045 per processed GB.

Architectural Solution: We must install a VPC Gateway Endpoint for S3 inside our subnet. VPC Endpoints act as direct private tunnels from VMs to S3 through the cloud provider’s internal network. By diverting data traffic to VPC Endpoints, we completely eliminate NAT Gateway costs (processing cost = $0.00).

Database Optimization #

Databases are often the second most expensive component after compute. We can optimize them through rightsizing and query code efficiency improvements:

• Aurora Serverless for Fluctuating Workloads: For non-production database environments (like dev/staging) rarely intensively accessed, we should use serverless database types. Aurora Serverless scales CPU capacity down when quiet and instantly up when queries arrive. This eliminates wasted static database VM rental costs idle at night.
• Use Read Replicas to Avoid Scale-Ups: When primary database performance slows due to high read query loads, bad architectures immediately scale up primary instances to giant sizes. Correct Solution: Add several cheap Read Replica instances, then route all analytical and data-reading query traffic to those replicas. Keep primary database instances exclusively for data write query operations.
• Implement Caching Layers (Redis/Memcached): Repeatedly reading data directly from primary databases (like product catalog data) wastes database compute resources. By installing caching layers using Redis or Memcached, we cut IOPS query loads on databases. This allows downgrading primary database instance specifications to much smaller, cheaper types.
• Data Archiving Strategies (Data Purging & Archiving): Storing historical transaction data older than 1 year inside primary operational relational databases (like MySQL/PostgreSQL) slows query times and increases premium SSD storage costs. We should archive that historical data to Object Storage (like AWS S3) in compressed Apache Parquet format, then access it using on-demand serverless queries (like AWS Athena) whenever needed.

Resource Scheduling #

For instances in testing environments (development and test environments), servers don’t need to run 24 hours a day, 7 days a week. Our engineering team members generally only work during regular office hours.

Let’s calculate potential savings from automatic server shutdown scheduling policies:

• 24/7 Running Machine Scenario:

  $$\text{Monthly Operational Hours} = 24 \text{ hours} \times 30 \text{ days} = 720 \text{ hours/month}$$

• Scheduled Running Machine Scenario (Active Monday - Friday, 08:00 - 18:00): Active 10 hours per day, over 20 workdays a month.

  $$\text{Scheduled Operational Hours} = 10 \text{ hours} \times 20 \text{ days} = 200 \text{ hours/month}$$

• Financial Savings Percentage Calculation:

  $$\text{Savings Percentage} = \frac{720 \text{ hours} - 200 \text{ hours}}{720 \text{ hours}} \times 100% \approx 72.2%$$

By applying automatic server on-off policies outside office hours, we directly cut sandbox/dev environment financial spending by 72.2% without disrupting team daytime comfort. We can implement this automation using built-in tools like AWS Instance Scheduler or simple AWS Lambda cron job triggers.

Cost Optimization Myths and Anti-Patterns #

To avoid common mistakes that can damage system quality, we must correct several myths and avoid the following anti-patterns:

1. Myth: Rightsizing Means Cutting Server Headroom #

• Rebuttal: Rightsizing doesn’t mean running servers at 99% CPU limit boundaries that can crash during sudden traffic spikes. Healthy rightsizing targets keeping average utility in the 40% - 60% CPU range, leaving safe spike room combined with responsive autoscaling.

2. Anti-Pattern: Aggressively Deleting Backups #

• DON’T: Delete backup snapshot repositories or disable production database Multi-AZ features to save storage costs. Sacrificing data durability and availability for a few dozen dollars is a huge carelessness. Disaster recovery data restoration costs far exceed those backup snapshot storage costs.

3. Myth: Cost Optimization Is Only DevOps/SRE Teams’ Job #

• Rebuttal: DevOps/SRE only provides infrastructure and alarms. The biggest waste causes are often at the application code level written by developers — like inefficient N+1 database queries, asynchronous loops with typos triggering CPU spikes, or failing to close TCP connections.

4. Anti-Pattern: Ignoring Software License Costs #

• ✗ DON’T: Use paid-OS virtual machines (like Windows Server) or commercial databases (like MS SQL Server/Oracle) without calculating open-source alternatives (like Linux and PostgreSQL). Commercial CPU license costs in the cloud often far exceed the physical hardware rental costs themselves.

Summary #

• Apply optimization frameworks systematically — Namely Identify (find), Prioritize (sort), Optimize (execute), Verify (confirm), and Iterate (repeat periodically).
• Rightsizing is the fastest efficiency step — Monitor CPU and RAM utility, then gradually downgrade over-provisioned instance specifications.
• Automatically clean up orphaned components — Create scheduled scripts deleting empty disks, targetless load balancers, and idle elastic IPs.
• Use object lifecycle policies — To automate old data storage class downgrades to more economical cold storage classes.
• Install VPC Endpoints in private subnets — To avoid expensive NAT Gateway data processing bills when accessing object storage internally.
• Schedule automatic shutdowns for non-production servers — Shutting down dev/test instances outside office hours and weekends can save up to 72% of costs.