DEV Community: Khalid Rasool

AWS Cost Optimization Guide: Clean Up Idle Resources and Save – by Khalid Rasool

Khalid Rasool — Sat, 16 Aug 2025 11:20:15 +0000

AWS is great at scaling up when you need it. But here’s the catch: it doesn’t scale down your bill unless you actively clean up what’s left behind. Idle resources can quietly eat away at your budget every month.

Let’s go through some common culprits, why they get overlooked, and how to deal with them.

1. Idle Elastic Load Balancers (ELB)

Even if there’s no traffic flowing, AWS charges for load balancers.Pricing is based on hours the load balancer is running plus Load Balancer Capacity Units (LCUs).

Why unnoticed? Teams often delete EC2 instances but forget the load balancer that was fronting them.
Action: Regularly audit for load balancers with no registered targets.

🔗 Elastic Load Balancing pricing

2. Unattached Elastic IPs

Since Feb 1, 2024, AWS charges for all public IPv4 addresses, whether attached or not.So leaving an IP lying around will cost you.

Why unnoticed? People assume only “in-use” IPs cost money.
Action: Release unused Elastic IPs and review your IP allocations.

🔗 New AWS public IPv4 address charge

3. Old Auto Scaling Groups & Launch Configurations

Auto Scaling Groups themselves don’t have a separate cost, but here’s the thing:leftover groups, outdated launch configs, or templates often keep stale resources around. CloudWatch alarms linked to them can also keep generating costs.

Why unnoticed? They sit idle after architecture changes or migrations.
Action: Delete unused groups, launch configs, and alarms that are no longer relevant.

🔗 Amazon EC2 Auto Scaling pricing

4. Unused Lambda Functions

The code itself costs nothing. But if a function has Provisioned Concurrency or leaves behind CloudWatch logs and metrics, you’re still paying.

Why unnoticed? Functions pile up after migrations, POCs, or quick experiments.
Action: Delete unused functions and clean up old CloudWatch log groups.

🔗 AWS Lambda pricing🔗 Provisioned Concurrency docs🔗 CloudWatch pricing

5. Route 53 Hosted Zones

Every hosted zone in Route 53 costs money, even if it’s not serving active records.As of today, it’s $0.50 per hosted zone per month.

Why unnoticed? DNS is often set-and-forget, especially for old test domains.
Action: Delete zones you don’t need anymore.

🔗 Amazon Route 53 pricing🔗 Route 53 billing details

Why These Get Missed

Ownership drift: Teams create resources, then people leave or switch projects.
Fear of breaking things: Engineers hesitate to delete “just in case.”
No visibility: AWS doesn’t nag you about idle load balancers or unused IPs.
Ops debt: Cleanup rarely makes it into sprints, so waste accumulates.

How to Stay Ahead

1. Make discovery easy

Use AWS Resource Explorer to find all load balancers, IPs, and other resources across accounts.

2. Tag everything

Apply tags like project, owner, and environment so it’s clear what’s safe to delete.

3. Quarantine before delete

Stop or deregister resources first. If nothing breaks after a couple of days, delete them.

4. Automate guardrails

AWS Config rule: eip-attached flags unattached Elastic IPs.
Trusted Advisor: Core checks (like idle load balancers) are available on all support plans; full checks need Business or Enterprise Support.
Custom scripts: Run periodic jobs in CI/CD or cron to flag orphaned resources.
CloudWatch alerts: Set up notifications for “no registered targets” on load balancers or dormant Auto Scaling Groups.

5. Delete with confidence

Once a resource passes a quiet period, remove it. Document the change. Keep tags, runbooks, and cleanup processes current.

Bottom Line

Cleaning up idle resources is one of the simplest ways to save on AWS.It doesn’t require complex optimization — just consistent housekeeping.

Start with public IPv4 addresses, then load balancers, ASGs, Lambda, and Route 53.Make discovery, tagging, and quarantine part of your regular ops, and you’ll avoid paying for things you don’t even use.

AWS is “pay-as-you-go,” but also “pay-as-you-forget.”Don’t let your budget die from neglect.

References

How to Serve HTTPS on Your Root Domain Using AWS S3 and Cloudflare – by Khalid Rasool

Khalid Rasool — Sat, 05 Jul 2025 22:03:36 +0000

How to Serve HTTPS on Your Root Domain Using AWS S3 and Cloudflare

If you’re hosting a static website on AWS S3 and using Cloudflare for DNS and SSL, you might have noticed a common issue:

Your website works perfectly at https://www.yourdomain.com but fails or shows SSL errors at https://yourdomain.com (root domain).

Why does this happen? And how do you fix it?

The Root Cause

AWS S3 static website hosting provides HTTP-only endpoints for static sites. You can point a www CNAME to the S3 website endpoint and use Cloudflare’s SSL proxy to get HTTPS working smoothly on the www subdomain.

However, when using the root domain (apex domain) like yourdomain.com, you can’t create a CNAME record due to DNS restrictions, so you typically create an A record pointing to a dummy IP like 192.0.2.1 and enable Cloudflare proxy.

Here’s the catch:

The dummy IP doesn’t serve your website content.
Cloudflare can serve HTTPS on the root domain but cannot fetch your actual content from S3 via that dummy IP.
This results in connection timeouts or SSL handshake errors (Cloudflare Error 522 or 525).

Why You Need `www`

By using the www subdomain pointing directly to the S3 website endpoint via a CNAME, Cloudflare proxies your content and provides HTTPS.

This setup is simple, stable, and commonly used.

How to Serve HTTPS on Root Domain Without `www`

To get HTTPS on yourdomain.com itself without www, you need:

An AWS CloudFront distribution configured in front of your S3 bucket.
An SSL certificate issued via AWS Certificate Manager (ACM) for your root domain.
DNS records pointing your root domain to the CloudFront distribution.

CloudFront acts as a secure CDN layer, handling HTTPS connections properly on the root domain and fetching content from S3 behind the scenes.

Summary

Setup	HTTPS on Root Domain?	Complexity
S3 + Cloudflare + www	Yes	Easy
S3 + Cloudflare + root domain	No	-
S3 + CloudFront + root domain	Yes	Moderate (AWS config)

If you’re okay with www, stick to the simple Cloudflare + S3 CNAME setup.

If you want your root domain with HTTPS, invest some time setting up CloudFront in front of S3 — it’s worth it for a professional, seamless experience.

Hope this helps fellow developers understand why HTTPS on root domains with S3 can be tricky, and how to fix it!

Load Balancing AWS RDS MySQL Read Replicas with Route 53 (No Auto Scaling) – by Khalid Rasool

Khalid Rasool — Fri, 04 Jul 2025 19:56:19 +0000

Scaling read-heavy workloads on Amazon RDS for MySQL can be a challenge when your application demands high performance without the complexity of auto scaling. By leveraging AWS Route 53’s weighted routing, you can distribute read traffic across multiple RDS read replicas effectively, ensuring better performance and reliability without auto scaling. In this article, I’ll walk you through how to set up load balancing for MySQL read replicas using Route 53.

Why Use Route 53 for RDS Read Replicas?

Amazon RDS for MySQL supports up to five read replicas per primary instance, which are ideal for offloading read queries from the primary database. However, without auto scaling, you need a manual yet efficient way to distribute traffic across these replicas. Route 53’s weighted routing policy offers a simple, DNS-based solution to balance read traffic without requiring complex proxies like HAProxy or code changes. Here’s why it’s a great fit:

Simplicity: No need for additional infrastructure or application-layer changes.
Flexibility: Easily adjust weights to prioritize certain replicas.
Cost-Effective: Uses existing AWS services without extra overhead.
No Auto Scaling Needed: Works within the fixed limit of read replicas.

Note: Unlike Amazon Aurora, which has built-in load balancing via cluster endpoints, RDS for MySQL requires manual configuration for load balancing, as auto scaling of read replicas is not supported.

Prerequisites

Before you begin, ensure you have:

An AWS account with an RDS MySQL instance and at least one read replica (up to five).
A Route 53 hosted zone for your domain (e.g., db.yourdomain.com).
Your application configured to use a single DNS endpoint for read queries.
Access to the RDS console to retrieve read replica endpoints.

Step 1: Set Up Your RDS Read Replicas

Create Read Replicas:
- In the AWS RDS Console, navigate to “Databases.”
- Select your primary MySQL instance, then choose “Actions” > “Create read replica.”
- Configure the replica (e.g., instance type, region) and repeat for up to five replicas.
- Note each replica’s DNS endpoint (e.g., replica1.xxxxx.ap-south-1.rds.amazonaws.com).
Verify Replicas:
- Connect to each read replica using a MySQL client and run SELECT * FROM your_table to confirm data consistency (replication is asynchronous, so expect slight lag).

Step 2: Configure Route 53 for Weighted Routing

Route 53’s weighted routing policy allows you to assign weights to each read replica, controlling how traffic is distributed. Here’s how to set it up:

Create a Hosted Zone (if not already done):
- In the Route 53 Console, go to “Hosted zones” and click “Create Hosted Zone.”
- Enter a domain name (e.g., db.yourdomain.com) and select “Private Hosted Zone” for the VPC where your RDS instances reside.
Add CNAME Records for Read Replicas:
- In the hosted zone, click “Create record.”
- Set the following for each read replica:
  - Record name: Use a common name, e.g., read.db.yourdomain.com.
  - Record type: CNAME.
  - Value: Enter the DNS endpoint of one read replica (e.g., replica1.xxxxx.ap-south-1.rds.amazonaws.com).
  - Routing policy: Weighted.
  - Weight: For equal distribution, divide 100 by the number of replicas (e.g., 50 for two replicas, 33 for three).
  - TTL: Set to 0 for quick DNS updates.
  - Record ID: Use a unique identifier (e.g., replica1-read).
- Repeat for each read replica, keeping the same record name (read.db.yourdomain.com) but different endpoints and record IDs.
Enable Health Checks (Optional):
- Create Route 53 health checks for each replica’s endpoint to ensure traffic isn’t sent to unavailable replicas. This requires a health check endpoint (e.g., a simple webpage returning “GOOD!”). Health checks cost ~$1/month per check.

Step 3: Update Your Application

Modify your application’s database connection to use the single Route 53 endpoint (read.db.yourdomain.com) for read queries.
Ensure write queries still go to the primary instance’s endpoint (e.g., master.xxxxx.ap-south-1.rds.amazonaws.com).
If your application uses connection pooling, test to avoid DNS caching issues, which can skew traffic distribution.

Step 4: Test and Monitor

Test Traffic Distribution: Run read queries (e.g., SELECT * FROM your_table) and verify they’re hitting different replicas by checking SHOW VARIABLES LIKE 'server_id'; on each replica.
Monitor Performance: Use AWS CloudWatch to track CPU utilization and read IOPS on each replica to ensure balanced load.
Adjust Weights: If one replica has more powerful hardware, assign it a higher weight (e.g., 50 for a high-capacity replica, 25 for others).

Considerations and Limitations

Replication Lag: MySQL read replicas use asynchronous replication, so there may be slight delays in data consistency. Ensure your application can tolerate this.
No Auto Scaling: RDS for MySQL doesn’t support automatic addition/removal of read replicas, so plan your replica count based on expected load.
DNS Caching: Some languages (e.g., Java) cache DNS resolutions, which can lead to uneven traffic distribution. Set a low TTL (e.g., 0 or 10 seconds) to mitigate this.
Alternative Approaches: For more control, consider proxies like ProxySQL or HAProxy, but these require additional setup compared to Route 53’s simplicity.

Why This Works

Route 53’s weighted routing provides a lightweight, DNS-based load balancing solution that evenly distributes read traffic across MySQL read replicas without auto scaling.This approach is cost-effective, easy to configure, and scales within the fixed replica limit of RDS MySQL.

Ready to boost your database performance? Set up Route 53 weighted routing for your RDS read replicas and share your results in the comments!