You bring a Docker image—we set up infrastructure that scales with load, doesn't sit idle, and doesn't require manual node management. Our certified engineers have migrated over 50 projects to serverless containers since 2018, achieving cost savings of 40–70% versus traditional VMs. Teams often face cold start issues (1–5 seconds on Cloud Run if warm instances aren't kept), network latency when accessing private resources, and resource waste from misconfigured containers. We guarantee a thorough audit and platform selection tailored to your needs.
Serverless computing isn't just a trend—it's a way to cut infrastructure costs by up to 70%. The three major players work differently, and the choice often depends on where your existing infrastructure lives. Let's break down their strengths and pitfalls.
How to choose the right platform for your scenario
AWS Fargate: integration into the ecosystem
Fargate runs through ECS or EKS. You need an ECS/EKS cluster to launch Fargate tasks. Fargate itself doesn't handle HTTP traffic—you need an ALB.
The key advantage of Fargate is native integration with AWS services: IAM Task Roles provide secure access to S3/DynamoDB/Secrets Manager without credentials in environment variables, VPC-native networking, CloudWatch Logs out of the box, and Service Connect for service mesh between services.
For stateful tasks, you can mount EFS to a Fargate task—persistent storage without managing EBS.
Limitations: no privileged containers, no host networking mode, limited GPU support (only on ECS, not EKS). If you need --privileged, use the EC2 launch type.
GCP Cloud Run: the simplest launch
Cloud Run has the lowest barrier to entry. gcloud run deploy myservice --image gcr.io/my-project/myimage --region us-central1—and your service is live with a public HTTPS URL.
A unique feature of Cloud Run is scaling to zero. When there's no traffic, there are no instances; cost is $0. Perfect for dev environments, internal tools, and irregular services. For production with latency requirements under 200ms, consider cold start: the first request to a cold instance takes 1–5 seconds depending on image size and runtime.
To reduce cold start, use --min-instances 1 to keep one warm instance. Idle cost for one Cloud Run instance is small but non-zero.
Cloud Run supports --concurrency—the number of simultaneous requests per instance (up to 1000). This is radically different from Lambda (one request per instance): one Cloud Run instance can handle hundreds of concurrent requests, making it 5 times more efficient for high-throughput APIs.
# cloud-run-service.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: myapp
annotations:
run.googleapis.com/ingress: all
spec:
template:
metadata:
annotations:
autoscaling.knative.dev/minScale: "1"
autoscaling.knative.dev/maxScale: "100"
run.googleapis.com/cpu-throttling: "false" # CPU not throttled outside requests
spec:
containerConcurrency: 80
containers:
- image: gcr.io/my-project/myapp:latest
resources:
limits:
cpu: "1"
memory: "512Mi"
env:
- name: DB_URL
valueFrom:
secretKeyRef:
name: db-credentials
key: urlcpu-throttling: false makes CPU available at all times, not only during request processing. Useful for background tasks (cache cleanup, metric submission) inside the instance.
Azure Container Instances: fast launch, no orchestration
ACI is the simplest of the three—just a container launch without built-in orchestration or autoscaling. No built-in HTTPS, no load balancer, no automatic scaling.
ACI fits scenarios where orchestration isn't needed: one-off batch jobs (run, wait, kill), sidecars in CI/CD pipelines, on-demand dev environments, image testing.
For production HTTP services, ACI without additional components (Application Gateway, AGIC) is unsuitable.
Why serverless containers beat virtual machines
Virtual machines require OS management, patching monitoring, and capacity reservation. Serverless containers save up to 40% on administration costs and 30–50% on compute costs. You pay only for consumed resources—no idle time billing. Overall TCO drops 40–70% compared to VM infrastructure. To estimate savings for your project, order an audit—we'll prepare a detailed calculation with dollar amounts based on your current spend.
Network integration
All three platforms support private networking:
- Fargate: tasks run inside a VPC, get an ENI with a private IP. Security groups control in/out traffic.
- Cloud Run: use VPC Connector or Direct VPC Egress for private resources (Cloud SQL, Memorystore). Inbound traffic via Load Balancer or directly through IAM.
- ACI: virtual network through Azure VNet integration.
Secrets management
Common principle for all: never store secrets in environment variables in deployment configs.
- Fargate: Secrets Manager or SSM Parameter Store via ECS Task Definition secrets field.
- Cloud Run: Secret Manager via volume mount or environment variable reference.
- ACI: Key Vault via managed identity.
How we do it: step by step
- Audit and platform selection. Analyze load, latency requirements, budget, current cloud environment.
- Network design. Set up VPC, private endpoints, security groups, VPC Connector.
- CI/CD setup. Integrate GitLab CI or GitHub Actions with Terraform deployment.
- Deployment and testing. Verify scaling (HPA, concurrency), cold start, network connectivity.
- Monitoring and documentation. Set up Prometheus/Grafana, create runbook, train your team.
More on timelines
Typical setup times: Cloud Run with private VPC and Secret Manager: 1–2 days. Fargate with ECS, ALB, and CI/CD: 2–3 days. ACI for batch jobs: 1 day. Project assessment takes 1 day.What's included in our work
- Current infrastructure audit and platform selection
- CI/CD pipeline setup (GitLab CI, GitHub Actions, Cloud Build)
- Network configuration: VPC, private endpoints, security groups
- Deployment with autoscaling (HPA, concurrency configuration)
- Monitoring integration (Prometheus/Grafana, CloudWatch)
- Runbook documentation and team training
- Post-launch support (SLA on request)
Platform comparison
| Criterion | AWS Fargate (ECS) | GCP Cloud Run | Azure Container Instances |
|---|---|---|---|
| Scaling to zero | No (default) | Yes | No |
| Autoscaling | Via ECS Service | Built-in | Manual |
| Cold start | None (always N instances) | 1–5s | None (no autoscaling) |
| HTTPS out of the box | No (requires ALB) | Yes | No |
| GPU support | Limited | Yes (A100, T4) | No |
| Pricing model | Per vCPU/RAM per second | Per request + idle | Per vCPU/RAM per second |
Cloud Run scales to zero, saving up to 70% compared to Fargate under intermittent load. For steady traffic, Fargate with ALB is 20% more reliable in terms of uptime guarantees (99.95% vs 99.9% for Cloud Run).
Timelines and complexity
| Platform | Setup time (days) | Required expertise |
|---|---|---|
| Cloud Run + private VPC + CI/CD | 1–2 | Familiarity with GCP, Terraform |
| Fargate + ECS + ALB + CI/CD | 2–3 | AWS Networking, ECS, IAM |
| ACI for batch jobs | 1 | Basic Azure knowledge |
We'll assess your project and recommend the best solution. With 5+ years of experience and a track record of 50+ successful migrations, we guarantee a cost-effective and reliable setup. Contact us for a consultation and cost estimate within 1 day. Order an infrastructure audit—we'll match you with the right platform.







