About Expertise Work Managed Apps
Business Website Online Store Sales CRM Team Drive Online Academy Newsletter System Booking System Shared Inbox Knowledge Base Short Links Business Manager Photo Gallery Survey Platform Community Forum Project Boards Estate Agency Car Workshop Restaurant Clinic Photography Studio
AWS
Assess & advise Build & migrate Automate & operate Secure & comply Urgent & go-live
Projects
Hosted Monitoring & Dashboards Self-Hosted Observability Stack Bulk Document Data Extraction Email Deliverability Diagnosis & Repair SEO Migration Recovery AWS Security Review VPS Hardening & ModSecurity Cloud Architecture & Resilience Review SSL & Server Configuration Container Security Review DNS & Email Troubleshooting DevOps Deployment & Rollback Review WordPress Hardening Retainer Data Pipeline Rerun Review Metric Reconciliation
Free Tools
Website Health Check Email Domain Health Check DNS Health Check SSL Certificate Checker Redirect Chain Checker Robots.txt Checker XML Sitemap Validator Docker Compose Checker WordPress Security Check AWS IAM / S3 Policy Checker Domain Registration Lookup Uptime Monitoring Trial Downtime Cost Calculator AWS Cost Estimator Cloud Architecture Self-Assessment DevOps Engagement Builder Self-Managed VPS vs Managed AWS
Blog Certifications Hire Me

Amazon ECS / Fargate Deployment

Containers that deploy without downtime, and that stop deploying when the new version is broken.

Price and scope

From $649

Typically $649–$1,599, fixed in writing before anything starts.

3–7 days
Working days, counted from the moment I have access — not from the day you agree.

What moves it up

  • More than one service, which have to find each other and start in a sensible order
  • Autoscaling that has to be tuned against real traffic rather than guessed
  • A private subnet layout, where tasks reach AWS services through endpoints rather than NAT
The ECS replacement loopA cycle of four steps: a task starts, a shallow health check reports success because the process is running, the application cannot reach its database, ECS stops the task and starts an identical one, and the cycle repeats.task startshealth check: 200the process is upcannot reach the DBECS replaces itidentical taskand again
Amazon ECS / Fargate Deployment

What actually goes wrong

The first ECS deployment nearly always works. The second one is where it goes wrong, and it goes wrong in a particular way: a task that fails its health check is stopped and replaced by another task that fails in exactly the same way, forever, while the load balancer keeps draining and re-registering targets. The underlying cause is almost always a health check pointed at something that returns 200 as soon as the process starts, so ECS is being told the container is healthy by a check that cannot tell.

How I find it

  • aws ecs describe-services --query 'services[].events[:10]' — the loop is written out in plain English here
  • aws ecs describe-tasks --query 'tasks[].containers[].[lastStatus,reason]'
  • The target group health check path requested directly against a running task IP
  • aws logs tail /ecs/<service> --follow during a deploy, not after it

What you get

  • A cluster, task definitions and services, defined as code rather than clicked
  • A health check that exercises the application's real dependencies, so a broken release fails it
  • Rolling deploys with circuit breaker and automatic rollback, so a bad version stops itself
  • Autoscaling on a metric that reflects load, with the minimum set to survive one task dying
  • Logs and container insights in CloudWatch, with retention set

Questions

Fargate or EC2 launch type?

Fargate unless you have a reason — no instances to patch, no capacity to manage, and for small workloads the price difference is smaller than the time you would spend on the alternative. EC2 launch type earns its place at sustained scale, with GPUs, or with a daemon that has to run on the host.

How do my containers reach the database privately?

Tasks run in private subnets with a security group that the database's own group allows by id. Nothing has a public address, and outbound access to AWS APIs goes through VPC endpoints rather than a NAT gateway wherever that is possible.

What happens if a deploy is broken?

The deployment circuit breaker stops it and rolls back to the previous task definition automatically, and the old tasks keep serving throughout because they are not stopped until the new ones pass. That is the specific thing this setup buys over restarting containers on a box.

Can I run scheduled jobs on this?

Yes — as scheduled tasks rather than a cron container that is always running, which means you pay for the minutes they execute rather than for a container sitting idle waiting for a clock.

Want this done?

Tell me what you are running and I will come back with a fixed price and a date. If it turns out you do not need this, I will say that instead.

Prefer to talk? Book a free call ↗  ·  Or hire me on Upwork ↗  ·  Typical reply within one business day.

When I answer

Sunday to Thursday, 09:00–18:00 EET. Outside that I will still look, but I will not promise a time.

No 24/7 desk, and I will not pretend otherwise

One person, one time zone. If round-the-clock cover is what you need, you need a team, and I will say so rather than sell you a plan that cannot deliver it.

Your AWS bill stays yours

You pay Amazon directly and you keep control of the account. Nothing here resells your infrastructure or sits between you and your own billing.

A price that starts with "from" is a starting price

Every service page lists exactly what pushes a quote above it, before you ask. You get a fixed number in writing before any work begins.