Lebanese startups waste money on cloud infrastructure in predictable ways. They either underinvest and run on a single server with no redundancy, or overengineer a Kubernetes cluster they do not have the team to operate. Both kill startups, just at different speeds.
Lebanese startups waste money on cloud infrastructure in predictable ways. They either underinvest and run on a single server with no redundancy, or overengineer a Kubernetes cluster they do not have the team to operate. Both kill startups, just at different speeds. This guide covers what cloud infrastructure actually looks like for a SaaS product in Lebanon or the MENA region at different stages.
The question no one asks first: which region?
AWS has two options relevant to MENA startups: eu-west-1 (Ireland) and me-south-1 (Bahrain). Most Lebanese startups default to eu-west-1 because of price and service availability, but this is worth examining.
me-south-1 (Bahrain) advantages: Lower latency for users in the Gulf and Lebanon, local data residency for regulated industries, better compliance posture for GCC clients.
me-south-1 disadvantages: Some AWS services are unavailable. Fewer data center options means Availability Zone failure risk is higher. Some services cost more than eu-west-1.
Our recommendation for most Lebanese startups: Start in eu-west-1. The latency difference (50 to 100ms) rarely matters for web applications. Move to me-south-1 or add it as a secondary region when you have specific GCC clients with data residency requirements or when latency becomes a measured product problem.
What infrastructure a 0-to-$10K MRR SaaS actually needs
At early stage, complexity is your biggest enemy. A startup running a SaaS product for Lebanese businesses does not need:
- Kubernetes
- Multiple load balancers
- Redis cluster (single Redis instance is fine)
- Read replicas for PostgreSQL (unless you have specific read-heavy workloads)
- Multi-AZ RDS (start with single-AZ, upgrade when you have customers)
What you actually need:
One ECS cluster with a Fargate task for your Go backend API. Auto-scaling from 1 to 3 tasks based on CPU. This handles significant traffic for a focused SaaS.
RDS PostgreSQL on a db.t4g.medium instance, single-AZ to start. About $50 to $80/month. Take daily snapshots, which RDS handles automatically.
ElastiCache Redis on a cache.t4g.micro for session storage and caching. About $15/month.
ALB (Application Load Balancer) to route traffic to ECS. About $20 to $30/month plus traffic costs.
S3 for file storage. Essentially free until you have significant file volume.
CloudFront in front of your S3 bucket for file delivery. Free tier is generous.
RDS backups to S3 via automated snapshots. Included in RDS cost.
Total infrastructure for a functioning SaaS: $150 to $250/month. For a Lebanese startup with early customers, this is reasonable and right-sized.
The $10K to $50K MRR infrastructure upgrade
At this stage, you have real users who expect reliability. The upgrades that matter:
Multi-AZ RDS. This provides automatic failover if the primary database AZ goes down. Roughly doubles your RDS cost but is worth it once you have customers depending on the product. Budget $120 to $180/month for a db.t4g.medium Multi-AZ.
Read replica for reporting. If you run heavy reports that affect API performance, a read replica separates that load. Add one when you can measure the impact, not speculatively.
ECS Fargate task count minimum of 2. Always run at least two tasks so a single task failure does not take down the service. The ALB handles this transparently.
CloudWatch alarms on key metrics. CPU above 80% for 5 minutes, memory above 85%, error rate above 1%, database connection count approaching limit. These catch problems before customers notice.
Separate staging environment. A smaller version of production where you can test deployments before they go live. One Fargate task, single-AZ RDS, same code.
Total infrastructure at this stage: $400 to $700/month.
Cost optimization that actually moves the needle
For MENA startups watching AWS bills, these are the levers that matter:
Fargate Spot for background jobs. Background workers that can tolerate interruption (email sending, report generation, data imports) should run on Fargate Spot, which costs 70% less than standard Fargate. Your critical API tasks run on standard Fargate.
Reserved Instances for RDS. If you have been running the same database instance type for six months and plan to continue, a 1-year Reserved Instance saves 30 to 40%. Do not reserve speculatively.
S3 Intelligent Tiering. If you store files that users rarely access after 30 days (old reports, archived attachments), S3 Intelligent Tiering automatically moves them to cheaper storage classes.
CloudFront caching for static assets. Your Next.js or React frontend should be deployed to S3 and served via CloudFront. Zero Fargate compute cost for frontend serving.
RDS stop/start for staging. Stop your staging RDS instance when no one is using it. RDS charges by the hour. A staging environment that runs 8 hours a day instead of 24 costs one-third.
IaC from the start: Terraform or AWS CDK
Manual AWS console configuration does not scale and creates environments you cannot reproduce. For Lebanese startups with a single backend developer, Terraform is the pragmatic choice:
- Large community and module library
- AWS-agnostic syntax (useful if you ever use other cloud providers)
- State management with S3 backend is simple to set up
AWS CDK is a strong alternative if your team is primarily Go or TypeScript developers who want to use code instead of HCL. The generated CloudFormation is solid.
Either way, define your infrastructure in code before you have paying customers. Rebuilding a production environment from a Terraform plan after a disaster is possible. Rebuilding it from memory at 3am after a catastrophic failure is not.
Secrets management that does not create problems
Do not store database passwords, API keys, or service credentials in environment variables baked into your container image or ECS task definition. Use AWS Secrets Manager:
// At startup, pull secrets from AWS Secrets Manager
func loadSecrets(ctx context.Context, client *secretsmanager.Client) (*AppSecrets, error) {
result, err := client.GetSecretValue(ctx, &secretsmanager.GetSecretValueInput{
SecretId: aws.String("/voxire/api/production"),
})
if err != nil {
return nil, fmt.Errorf("get secrets: %w", err)
}
var secrets AppSecrets
return &secrets, json.Unmarshal([]byte(*result.SecretString), &secrets)
}
Rotate secrets when needed without redeploying containers. The ECS task role needs permission to read the specific secret, nothing more.
CI/CD for a two-person engineering team
GitHub Actions is the right CI/CD system for Lebanese startups. It is free for public repositories and cheap for private repositories, and it integrates directly with ECR and ECS:
name: Deploy
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build and push Docker image
run: |
aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_REGISTRY
docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$GITHUB_SHA .
docker push $ECR_REGISTRY/$ECR_REPOSITORY:$GITHUB_SHA
- name: Deploy to ECS
run: |
aws ecs update-service \
--cluster production \
--service api \
--force-new-deployment
This deploys every push to main. For a startup, this is the right default. Add a manual approval step when you have a formal QA process.
What Lebanese startups consistently get wrong
Starting with Kubernetes. Kubernetes has operational overhead that a two-person team cannot afford. ECS Fargate gives you containers without the cluster management burden. Migrate to Kubernetes when you have the engineering team to run it.
Not setting up billing alerts. AWS bills can surprise you. Set a billing alarm at $200/month when you start, and raise it as you grow. This catches runaway processes and misconfigured services before they cost thousands.
Using the root account for deployments. Create IAM roles with minimal permissions for your CI/CD pipeline and developers. The root account should have MFA enabled and almost never be used.
No backup testing. RDS automated snapshots are running, but when did you last restore one? A backup you have never restored is a backup you cannot rely on.
Lessons learned running MENA SaaS infrastructure
Right-size before you optimize. The difference between a $150/month infrastructure and a $300/month infrastructure is often reliability, not waste. Optimize costs aggressively after you reach $1,000/month in AWS spend. Before that, spend the time on product.
Need help architecting cloud infrastructure for your startup?
Voxire designs and manages cloud infrastructure for SaaS products and operational systems across Lebanon and the MENA region. If you are building a product and want to start with infrastructure that scales without rewrites, reach out.
https://voxire.com/get-a-quote/
Enjoying this article?
Enter your email and get a clean, formatted PDF of this article - free, no spam.



