Cloud Infrastructure Cost Optimization for SaaS Startups in MENA

AWS bills can grow quietly and fast when a SaaS product scales without intentional cost architecture. Here is how we approach infrastructure cost optimization for startups in Lebanon and MENA, from compute to storage to data transfer.

Why cloud costs spiral without a plan

Most SaaS products start with a reasonable AWS setup. A few ECS tasks, an RDS instance, maybe an ElastiCache cluster. At a few thousand dollars per month, the bill is manageable and nobody looks too closely. Then traffic grows, the team adds services, and twelve months later the bill is seven times higher than expected and nobody can explain why.

The growth is usually not from one big decision. It is from dozens of small ones: an RDS instance provisioned at multi-AZ when single-AZ is fine for a staging system, data transfer charges from an S3 bucket in a different region than the ECS cluster, a CloudWatch log group retaining logs forever at $0.03 per GB per month, an idle Fargate task left running through a weekend because nobody remembered to scale it down.

Cost optimization is not about being cheap. It is about understanding what you are paying for and ensuring each dollar is buying real value.

Right-sizing compute before anything else

Fargate task sizing is the largest single optimization lever for most early-stage SaaS products. The default tendency is to provision more CPU and memory than needed because it feels safe. In practice, most Go services run comfortably on 0.25 vCPU and 512 MB.

The correct approach is to provision small, measure, and increase only if metrics show CPU or memory pressure:

# Check actual CPU utilization for a service over the last two weeks
aws cloudwatch get-metric-statistics \
  --namespace AWS/ECS \
  --metric-name CPUUtilization \
  --dimensions Name=ServiceName,Value=api-service Name=ClusterName,Value=production \
  --start-time 2026-05-16T00:00:00Z \
  --end-time 2026-05-30T00:00:00Z \
  --period 86400 \
  --statistics Average Maximum

If average CPU is 8% and maximum is 22%, a 0.5 vCPU task can probably run on 0.25 vCPU. At $0.04048 per vCPU-hour on Fargate (us-east-1), halving task CPU saves $354 per year per task on a continuously running service.

For RDS, the same principle applies. A db.t3.medium at $0.068 per hour may be running at 5% CPU during normal operation. A db.t3.small at $0.034 per hour may be sufficient. The difference is $298 per year for a single instance.

Fargate Spot for non-critical workloads

Fargate Spot uses spare capacity and costs 70% less than standard Fargate. Spot tasks can be interrupted with two minutes notice. For workloads that can tolerate interruption, this is a straightforward saving.

Suitable workloads for Fargate Spot:

• Background job processors
• Report generation services
• Data export jobs
• Batch processing pipelines
• Development and staging environments

Production API services usually cannot tolerate interruption without care, but a background job worker that processes queue messages is a natural fit. If a task is interrupted mid-job, the message returns to the queue and another task picks it up.

resource "aws_ecs_service" "worker" {
  name    = "worker"
  cluster = aws_ecs_cluster.main.id

  capacity_provider_strategy {
    capacity_provider = "FARGATE_SPOT"
    weight            = 100
  }
}

For a background worker running 24/7 on a 0.5 vCPU / 1 GB task, switching to Spot saves roughly $420 per year.

RDS storage and backup costs

RDS charges for storage provisioned, not storage used. If you provision 100 GB and use 12 GB, you pay for 100 GB. Automated backups also consume storage at the same rate as the database.

For early-stage SaaS products with modest data volumes, provisioning exactly what you need and monitoring with a CloudWatch alarm on free storage is better than over-provisioning defensively.

RDS automated backup retention defaults to 7 days. For most SaaS products, 3 days is sufficient for operational recovery. Reducing from 7 to 3 days cuts backup storage costs by roughly 57%.

For snapshots taken before major releases: delete them after 30 days unless there is a regulatory requirement to retain longer.

CloudWatch logs: the hidden cost

CloudWatch Logs charges $0.03 per GB for ingestion and $0.03 per GB per month for storage. A busy service logging at INFO level generates significant data. Logs retained indefinitely at production log volumes cost hundreds of dollars per year for a mid-sized SaaS product.

The changes that matter:

1. Set log group retention to 30 days for production application logs. Use S3 for longer archival if needed, at $0.023 per GB per month versus $0.03.
2. Review log verbosity. INFO level logging for every HTTP request is common but expensive. Log only errors, warnings, and explicitly useful operational events in production.
3. Use structured logging and filter in CloudWatch Insights rather than logging verbose context at every level.

For a service generating 50 GB of logs per month, moving from perpetual retention to 30-day retention and reducing verbosity by 40% saves roughly $450 per year.

Data transfer charges

Data transfer within the same AWS region is free between services. Data transfer out to the internet is charged at $0.09 per GB after the first GB per month.

The most common unexpected data transfer charges for SaaS products in MENA:

• An S3 bucket in us-east-1 serving user uploads while the application runs in ap-southeast-1. Cross-region data transfer between S3 and EC2/Fargate is charged.
• CloudFront not being used for static assets. Direct S3 downloads from the internet hit the $0.09 rate. CloudFront's first 1 TB per month is free on most plans and thereafter is cheaper than direct S3 egress.
• RDS in a different availability zone than the application. Cross-AZ data transfer is $0.01 per GB in each direction.

For SaaS products serving users in Lebanon and the MENA region, the nearest AWS region is ap-southeast-1 (Singapore) or eu-west-1 (Ireland). Putting all resources in the same region and using CloudFront eliminates most unexpected transfer charges.

Scheduled scaling for predictable workloads

Many SaaS products serving business clients in Lebanon and MENA have predictable traffic patterns: high during business hours (9 AM to 7 PM AST), quiet overnight, very quiet on Fridays and Saturdays.

ECS Application Auto Scaling with scheduled scaling reduces capacity during quiet periods:

# Scale down at midnight
aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/production/api-service \
  --scheduled-action-name scale-down-midnight \
  --schedule "cron(0 21 * * ? *)" \
  --scalable-target-action MinCapacity=1,MaxCapacity=2

# Scale up at 7 AM AST (4 AM UTC)
aws application-autoscaling put-scheduled-action \
  --service-namespace ecs \
  --resource-id service/production/api-service \
  --scheduled-action-name scale-up-morning \
  --schedule "cron(0 4 * * ? *)" \
  --scalable-target-action MinCapacity=2,MaxCapacity=8

For a service running 4 tasks during peak and 1 task overnight for 10 hours, scheduled scaling saves approximately 25% of total compute cost.

Savings Plans for committed usage

AWS Compute Savings Plans offer up to 66% discount on Fargate and EC2 in exchange for a 1-year or 3-year compute commitment. For SaaS products that have been running for six months or more and have a predictable baseline compute spend, Savings Plans are the single largest cost reduction available.

The process:

1. Look at the last 30 days of compute spend in AWS Cost Explorer.
2. Identify the consistent baseline: the amount spent every day regardless of peaks.
3. Purchase a Savings Plan for that baseline amount only. Variable peaks above the baseline stay on on-demand pricing.
4. Review quarterly and increase the commitment as the product grows.

A $200/month Savings Plan commitment on Fargate at the 1-year rate saves approximately $100/month against on-demand pricing. Over 12 months, that is $1,200 saved on a $2,400 commitment.

Key lessons from production

The cost optimizations that deliver the most value for SaaS startups in MENA:

• Right-size compute based on actual metrics, not comfortable estimates.
• Move background workers to Fargate Spot; the savings are large and the operational change is minimal.
• Set CloudWatch log retention to 30 days and reduce log verbosity in production.
• Ensure all services run in the same region to eliminate cross-region data transfer.
• Use scheduled scaling for predictable business-hours traffic patterns.
• Buy a Compute Savings Plan once the baseline spend is stable.

Cost optimization is a quarterly practice. The product grows, new services get added, and without regular review the bill climbs. Schedule a cost review every three months and compare against the previous quarter.