The previous lesson containerised MercadoFresco's shop and got it running on an ECS cluster. The result was good but incomplete: underneath the cluster there are still EC2 instances that have to be sized, whose AMI has to be maintained, that are paid for whether full or empty, and that take two minutes to start when the cluster needs new capacity. We hid the problem behind a capacity provider; we did not remove it.

AWS Fargate removes it. It is the serverless compute engine for containers: you declare how much CPU and how much memory each task needs, and AWS provides the rest — the host, the kernel, the patches, the isolation — with no instance that anybody can see or list. This lesson migrates the shop service to Fargate, tunes its auto scaling to the Friday peak, moves the queue workers onto Fargate Spot and ends with an honest comparison between Fargate, EC2 and Lambda.

Cost warning. Fargate is billed by vCPU-hour and GB-hour consumed by the task, rounded to the second with a one-minute minimum. In eu-west-1 it comes to around 0.047 USD per vCPU-hour and 0.0051 USD per GB-hour on x86, and roughly 20 % less on arm64/Graviton. Fargate Spot discounts around 70 % in exchange for being interruptible. There is no free tier for Fargate: a forgotten task of 1 vCPU and 2 GB costs about 41 USD a month. Follow the cleanup section at the end. Prices are approximate and indicative; the in-depth cost analysis is module 11. Fictitious data and identifiers.

1. What Fargate is and what stops existing
2. The same service on EC2 and on Fargate
3. Resource model: CPU, memory and ephemeral storage
4. x86 and arm64: Graviton and the real saving
5. Operational differences: no SSH, no hostPort, no DaemonSet
6. ECS Exec: debugging with no server to touch
7. Logging with FireLens and Fluent Bit
8. Task start-up and the Friday peak
9. Migrating the shop service to Fargate
10. VPC endpoints: no longer depending on the NAT
11. Auto scaling: target tracking, steps and schedules
12. Fargate Spot and the queue workers
13. One-off and scheduled tasks with EventBridge Scheduler
14. Pipeline integration and blue/green
15. The service in CDK with an L3 construct
16. Fargate versus EC2 versus Lambda
17. App Runner: one more step up the management ladder
18. Cost comparison and cleanup
19. Common mistakes and tips
20. Exercises
21. Conclusion

Fargate is not a service you buy separately, nor a different console: it is a launch type — more precisely, a capacity provider — within the same Amazon ECS from the previous lesson. Task definitions, services, target groups, auto scaling and roles are the same objects. What changes is where the task runs and who is responsible for the machine.

The sentence that sums up the change: Fargate does not remove the work of operating an application, it removes the work of operating a server. Marta still has to decide how many tasks there are on a Friday at 19:00; what she no longer has to decide is the size of the machines that host them.

Technically, each Fargate task runs in its own environment isolated by lightweight virtualisation — the same technology that underpins Lambda — which resolves the warning from 10-01 about the shared kernel: two tasks never share a kernel, not even two tasks of your own.

Both diagrams have the same ALB, the same service and the same tasks. The difference is in the middle layer: in the first there are two boxes representing machines — with their AMI, their agent and their empty, paid-for gap; in the second there are none.

In Fargate, cpu and memory at task level are mandatory and only accept specific combinations. You cannot ask for 1 vCPU with 1 GB, nor 3 vCPUs with anything.

Two practical consequences:

• The combination is chosen before you know the real load, and almost always wrongly. The correct method is the one from module 5: look at CpuUtilized and MemoryUtilized in Container Insights for two weeks, take the 95th percentile and add 30 % of headroom. Over-provisioning in Fargate costs money from the first second, because there is no already-paid-for instance for the excess to hide in.
• The granularity punishes applications with little CPU and a lot of memory. A task that needs 6 GB is forced to ask for at least 1 vCPU, even if it uses 5 % of it. When that happens a lot, it is worth checking whether the application should be a Lambda or whether there is a memory leak.

Ephemeral storage is 20 GB by default, extendable to 200 GB with ephemeralStorage. You are charged only for what exceeds the free 20 GB. It is a temporary disk that disappears when the task ends: it is there to unpack a file or hold a local cache, never for state. When shared persistence is needed, you mount EFS (02-02), which Fargate supports natively.

Fargate runs tasks on two architectures: X86_64 and ARM64, the latter on AWS Graviton processors. The switch is one field in the task definition, but it requires the image to be built for that architecture.

Multi-architecture builds are handled in CodeBuild with docker buildx:

For MercadoFresco the saving is real and measurable: the shop runs 2 base tasks plus up to 2 more at the peak, of 1 vCPU and 2 GB. Moving to Graviton brings the service's monthly cost down from about 85 USD to about 68 USD, 20 % without touching a line of business code. The requirement is to test it: Luis builds the image for both architectures, deploys arm64 to pre-production for a week, compares latency and errors on the mercadofresco-produccion dashboard, and only then changes production.

The concrete risk is dependencies: a Python wheel that only publishes x86 binaries forces you either to compile during the build — which the constructor stage of the 10-01 Dockerfile already allows — or to block the change. Better to find out in CodeBuild than in a deployment.

Fargate imposes restrictions that are not arbitrary: they follow from the host not existing as far as you are concerned.

The restriction that grates most at first is the first one, and the second most is the DaemonSet: plenty of people ran one log-collection container per instance. In Fargate that pattern is replaced by a sidecar inside each task, which costs some CPU and memory per task but removes the coordination between nodes.

ECS Exec opens a command session inside a running container using AWS Systems Manager, with no open ports, no SSH keys and no bastion. It needs three things:

1. The service or task with --enable-execute-command.
2. The task role — not the execution role — with SSM channel permissions.
3. The SSM agent, which Fargate already includes from platform version 1.4 onwards.

Three warnings to internalise before using it in production:

• Everything is audited in CloudTrail (05-03) with the ExecuteCommand event: who, when, on which task and with which command. On top of that, sessions can be required to be logged to CloudWatch Logs or S3 with executeCommandConfiguration on the cluster, encrypted with alias/mercadofresco-datos. At MercadoFresco, using ECS Exec in production fires a notification to alertas-mercadofresco: it is not forbidden, it is watched.
• Changes made inside a container do not survive. Editing a configuration file in the task works until the task is replaced, and then it silently disappears. ECS Exec is for diagnosing, not for fixing.
• With readonlyRootFilesystem: true the file system is read-only, which is exactly what you want: if you need to write in order to debug, the answer is usually that a log is missing.

In practice, 90 % of what people used to go looking for over SSH is already in CloudWatch Logs Insights or in X-Ray. ECS Exec is for the remaining 10 %: checking a DNS resolution, verifying that an environment variable arrived as expected, or confirming that the process is listening on the right port.

The awslogs driver from 10-01 still works and is the right default. When more is needed — routing to several destinations, filtering before sending, rewriting the format or sending a copy to an external system — the answer in Fargate is FireLens: a Fluent Bit sidecar that ECS configures automatically.

The cost of FireLens is one more container per task, some 64 CPU units and 128 MB, which in a four-task service is real money. MercadoFresco's rule: awslogs by default, FireLens only when there is a requirement awslogs does not cover, such as filtering access logs containing personal data before they leave the task.

This is the point the lesson exists for. A Fargate task goes through these phases:

1. Provisioning (PROVISIONING): the ENI is created in the subnet and the security group is attached to it. 3 to 10 seconds.
2. Image pull (PENDING): it authenticates against ECR and pulls the missing layers. 5 to 25 seconds depending on image size and whether there is a VPC endpoint.
3. Container start-up: the ENTRYPOINT runs. 1 to 5 seconds.
4. Health checks: the ALB registers the target and waits for the consecutive successes. 15 to 40 seconds depending on the target group configuration.

What that means for Friday at 19:00 with 900 orders/hour is concrete: when the ALBRequestCountPerTarget alarm crosses the threshold, the new capacity starts serving requests after 40 seconds instead of after two minutes. With the traffic ramp measured at MercadoFresco — from 300 to 900 orders/hour in about eight minutes — those 80 seconds of difference are the boundary between latency rising a little and latency setting off mercadofresco-alb-latencia-alta.

And there is a less obvious, more valuable consequence: with 40-second start-ups you can afford a lower minimum. Before, 2 instances always had to be running to absorb the ASG's reaction time. With Fargate the minimum can still be 2 tasks for availability — never fewer, to survive the loss of an AZ — but the extra headroom kept "just in case" stops being necessary.

The lever that shortens phase 2 is image size and the route to ECR. The shop's 220 MB image takes about 8 seconds from a VPC endpoint and about 20 through the NAT. That is another argument for the carefully written Dockerfile of 10-01 and for the next section.

The change is surprisingly small: the task definition from 10-01 already declared requiresCompatibilities: ["EC2", "FARGATE"] and awsvpc mode, precisely for this.

Step 1: set CPU and memory from data, not from intuition. Container Insights has been measuring for two weeks. The query Marta runs:

The 95th percentile of CPU is 0.62 vCPU and that of memory 1.4 GB, with an absolute maximum of 0.81 vCPU at the Friday peak. The tightest valid combination above that with headroom is 1 vCPU and 2 GB. Dropping to 0.5 vCPU / 2 GB would be tempting — it saves 25 % — but it leaves Friday's task at 160 % of its CPU: latency would degrade exactly when it matters.

Step 2: create the service with the Fargate capacity provider.

Three details of the command:

• assignPublicIp=DISABLED with private subnets. The tasks go in snet-mercadofresco-app-a and -b, with no public IP. That is the correct choice and it is what forces the next section: without a public IP, the task needs a route to ECR, S3, CloudWatch Logs and Secrets Manager, and that route is either an expensive NAT or some cheap endpoints.
• There is no --placement-strategy. Placement strategies belong to EC2. Fargate spreads tasks across the declared subnets, so availability comes from declaring subnets in both AZs, not from a strategy.
• --platform-version LATEST. The platform version is the equivalent of the host AMI, and AWS manages it. Pinning it to a specific version only makes sense if something new breaks, and then it is a temporary measure, not a permanent one.

Step 3: coexistence and cutover. Just as in 10-01, the ALB splits by weights between the EC2 service and the Fargate one: 90/10, then 50/50, then 0/100 over two weeks, watching TargetResponseTime and HTTPCode_Target_5XX. The day the weight reaches 100, the EC2 cluster's ASG is deleted and with it the AMI, the launch template and the patching cycle.

A Fargate task in a private subnet talks to several AWS services just to start. If that communication goes out through the NAT, you pay twice: the NAT's hourly charge and every gigabyte processed.

The S3 one is the most forgotten and the most important: it is a gateway endpoint, it is free, and without it the image pull does not work even if both ECR endpoints are in place. MercadoFresco already had vpce-mercadofresco-s3 from module 3, so that one is sorted.

The saving calculation for MercadoFresco, with 4.8 deployments a week, task replacements and daily scaling:

And here it is worth being honest rather than repeating the slogan: with seven endpoints across two AZs, the endpoints come out more expensive than the NAT in an architecture the size of MercadoFresco's. The argument in their favour is not just price, it is three other things: the traffic never leaves the AWS network, which is a defensible security requirement in front of an auditor; task start-up is faster and more predictable; and the NAT stops being a single point of failure for start-up. Marta's decision is intermediate and reasoned: endpoints for ECR, S3 and Logs — the ones on the critical start-up path, four of them, costing about 64 USD — and keep the NAT for the rest, knowing that module 11 will revisit whether it is worth it.

The three policy types combine, and each solves a different problem.

MercadoFresco's full configuration uses all three. The target tracking on ALBRequestCountPerTarget from 10-01 stays as the baseline. On top of it, the Friday scheduled scaling, which is the missing piece:

Three design decisions in those eight lines:

• The minimum is scheduled, not the desired count. Setting DesiredCount would effectively disable target tracking during the window. By raising the minimum, capacity is guaranteed and target tracking can still grow above it if the Friday turns out better than expected.
• --timezone "Europe/Madrid". Without it the cron is UTC, and in summer the peak arrives an hour before the scheduled action. It is a mistake that only shows up when the clocks change, in October, when nobody remembers touching anything.
• Fifteen minutes before and half an hour after. Before, so the tasks are healthy when the traffic arrives; after, generously, because scaling back too early is what causes the oscillation seen as latency spikes at 21:05.

The cost of that window is easy to calculate and to defend: 4 extra tasks × 5 hours × 4.3 Fridays × 0.057 USD/h ≈ 4.9 USD a month. It is probably the best money MercadoFresco spends.

Fargate Spot runs tasks on spare AWS capacity at a discount close to 70 %, in exchange for AWS being able to reclaim it. When it does:

1. It emits a state-change event to EventBridge and sends SIGTERM to the container.
2. It waits for the task definition's stopTimeout, with a maximum of two minutes.
3. It sends SIGKILL and the task is gone.

Two minutes of notice is a lot or a little depending on the workload:

The right way to apply it is not "all Spot" but a split across capacity providers, which guarantees an on-demand floor:

base=1 on the on-demand provider means the first task is always stable; the weight splits all the rest in a 1 to 4 ratio. With 10 tasks: 1 base plus 9 split as 1.8 on-demand and 7.2 Spot, that is, roughly 3 on-demand and 7 Spot.

The saving from the 1:4 split is almost 50 % and it keeps a floor that survives a mass withdrawal of Spot capacity. The technical requirement that makes it safe is the one from the 10-01 exercise: a SIGTERM handler that finishes the message in flight and does not ask for another, with stopTimeout: 120 and a generous queue visibility timeout.

Not everything is a service. The nightly load that feeds wg-mercadofresco-analitica (06-04) runs once a day and finishes. On EC2 that was either an instance left running or a cron on a machine somebody had to look after; on Fargate it is a scheduled one-off task.

What matters in that configuration: the flexible 30-minute window lets AWS pick the moment within the window, which reduces contention and fits Spot perfectly; the retry policy turns a transient failure into an automatic retry; and the DLQ guarantees that a persistent failure leaves a trace instead of vanishing. It is the same pattern as 07-05 applied to a scheduled task.

For a one-off run — a migration, a data repair — aws ecs run-task with the same network configuration and --launch-type FARGATE is enough. If the job has several steps with dependencies between them, the right tool is Step Functions (07-04), which can launch ECS tasks and wait for them to finish.

The pipeline-mercadofresco-tienda from module 8 changes little: where there used to be a CodeDeploy deployment onto an ASG, there is now a deployment onto an ECS service.

CodeDeploy blue/green on ECS works differently from EC2, and the difference is an improvement: CodeDeploy creates a complete new task set with the new revision, registers it in tg-mercadofresco-verde, lets you run the smoke tests against the ALB's test port with no real traffic, and only then shifts the production listener to the green group. The blue set is kept for the termination wait time, so a rollback is a listener change: seconds.

With the canary deployment configuration ECSCanary10Percent5Minutes, 10 % of traffic goes to the green set for 5 minutes; if mercadofresco-alb-latencia-alta or mercadofresco-pedidos-fallidos fire during that interval, CodeDeploy rolls back on its own. It is the improvement over the 10-01 circuit breaker: that one detects tasks that do not start; this one detects tasks that start and respond badly.

MercadoFresco's DORA metrics improve where you would expect: restoration goes from 4 minutes to under 1, because rolling back no longer means deploying anything, only moving a listener.

All of the above is about twenty lines in the infra-cdk/ project from 09-02, thanks to a level 3 construct that creates the ALB, the target group, the service, the task definition, the roles and the log group.

The warning from 09-02 still applies: run cdk synth and read the template the first time. This construct makes decisions for you — it creates a public ALB, opens its security group to 0.0.0.0/0 on port 80, creates a log group with a default retention — and you have to check they match what you want. In production, MercadoFresco adds the certificate and redirectHTTP: true so nothing is ever served over HTTP.

Note also enableExecuteCommand: config.nombre !== 'produccion': ECS Exec enabled in development and pre-production, and disabled in production unless explicitly turned on during an incident. It is a governance decision expressed in one line of infrastructure.

All three run code without you buying hardware, and the choice is made on objective criteria.

MercadoFresco's reasoned decision, component by component:

The criterion that settles most of the doubts: if the process lives waiting for requests, it is Fargate; if the process wakes up on an event and dies, it is Lambda; if you need control of the machine, it is EC2. And the economic criterion, refined in module 11: below a high sustained utilisation, Fargate beats EC2 because it does not pay for idle time; above it, EC2 with Savings Plans (11-05) regains the advantage.

AWS App Runner goes one step further: you give it a container image or a source repository, and it creates the service, the load balancer, the certificate, the domain and the auto scaling, including scaling to zero. There is no VPC to design, no target group, no task definition.

What matters is where it stops fitting, and that is why MercadoFresco does not use it: it gives far less network control — access to the VPC requires a connector and there are still limitations — it does not support sidecars or multi-container tasks, its deployment model does not offer CodeDeploy's canary blue/green, and its per-unit cost is higher than Fargate's. It is an excellent option for a simple HTTP service or a prototype, and a bad fit for a shop with Aurora in a private subnet, queues, a cache and a pipeline with a quality gate. It is mentioned because it is the question that always comes up: the answer is that the management ladder is not a ranking, it is a trade-off between convenience and control.

The full calculation for the shop service, with approximate eu-west-1 prices:

Fargate x86, a 1 vCPU and 2 GB task: 1 × 0.04656 + 2 × 0.00511 = 0.05678 USD/hour.

MercadoFresco goes from about 158 USD to about 70 USD a month on the shop, with arm64, and gets rid of the work of maintaining AMIs and patches along the way. With the workers on Spot, the module's total saving comes to around 150 USD a month.

With two honest caveats, because the comparison is not complete without them. The first: the EC2 instances could be bought with Savings Plans and drop 30-40 %, which narrows the gap considerably — and Fargate also accepts Compute Savings Plans, the subject of 11-05. The second: if the EC2 cluster were very well packed, with the shop and the workers sharing instances at 85 % occupancy, EC2 would be competitive. The problem is that such packing has to be achieved and maintained, and that is exactly the kind of work Fargate removes.

Cleanup, in strict order:

Step 4 is this lesson's expensive leftover: seven interface endpoints across two AZs cost about 112 USD a month even if not a single byte goes through them. A forgotten endpoint is the most common silent leak after unassociated elastic IP addresses.

Mistake: asking for an invalid CPU and memory combination. RegisterTaskDefinition fails with an unhelpful message. Tip: keep the table to hand; with the CDK, memoryLimitMiB and cpu are validated at synthesis, which is earlier.

Mistake: sizing by intuition. Over-provisioning in Fargate is paid for from the first second. Tip: 95th percentile from Container Insights over two weeks, plus 30 %, and review after a month.

Mistake: private subnets with neither endpoints nor NAT. The task sits in PROVISIONING and dies with CannotPullContainerError. Tip: before migrating, check the route to ECR api, ECR dkr, S3, Logs and Secrets Manager; the S3 one is a gateway, it is free and it is the most forgotten.

Mistake: believing that going without a NAT is always cheaper. Seven interface endpoints across two AZs beat the NAT in a mid-sized architecture. Tip: put endpoints only on the critical start-up path and decide the rest with module 11 data.

Mistake: scheduling DesiredCount instead of the minimum. It effectively disables target tracking during the window. Tip: schedule MinCapacity and let the reactive policy keep working above it.

Mistake: forgetting --timezone in scheduled scaling. The peak shifts by an hour when the clocks change. Tip: explicit Europe/Madrid on every scheduled action, and check the last week of October.

Mistake: putting the shop on Fargate Spot to save money. An interruption with two minutes' notice during the Friday peak is exactly what the course has spent ten modules avoiding. Tip: Spot only where the interruption retries itself, and always with an on-demand base.

Mistake: not handling SIGTERM in the workers. With Spot, every interruption turns into a reprocessed or lost message. Tip: a handler that finishes the message in flight and does not ask for another, stopTimeout: 120 and a generous visibility timeout.

Mistake: using ECS Exec to fix something. The change disappears at the next replacement and leaves a system nobody can reproduce. Tip: ECS Exec to diagnose; the fix goes through the pipeline. And in production, with a notification to alertas-mercadofresco.

Mistake: switching to arm64 without testing. A Python wheel with no arm binary breaks start-up. Tip: docker buildx with both platforms, a week in pre-production and a latency comparison before touching production.

Tip: set --platform-version LATEST and do not pin it. Pinning a platform version means giving up the improvements and the patches, which is exactly what you came to buy.

Tip: keep minimumHealthyPercent: 100 in production. With Fargate there is no longer an instance gap limiting maximumPercent, so 100/200 costs no reserved capacity, only a few minutes of double billing per deployment.

Tip: set an alarm on RunningTaskCount against DesiredTaskCount. It is the earliest signal of a start-up problem, a Fargate quota issue or IP exhaustion in the subnet.

The cola-mercadofresco-pedidos workers process each message in 12 seconds on average, with a peak of 900 messages/hour on Fridays from 17:00 to 21:00 and around 150 messages/hour the rest of the time. Container Insights shows each worker at a 95th percentile of 0.31 vCPU and 780 MB. The internal service agreement is that no order waits more than 3 minutes in the queue. Design: (a) the task's CPU and memory combination, with justification; (b) how many tasks are needed at the peak and off-peak, with the calculation; (c) the complete auto scaling policy, stating which metric you use and why not CPU; (d) the split between FARGATE and FARGATE_SPOT with its base and weight, and what happens if AWS withdraws all Spot capacity during the peak; and (e) the approximate monthly cost of your design.

Luis migrates the shop service to Fargate in pre-production. The tasks sit in PROVISIONING for several minutes and end with ResourceInitializationError: unable to pull secrets or registry auth. He checks the following and everything looks right: the execution role has the ECR and Secrets Manager permissions, the task definition is the same one that worked on EC2, and the subnets are snet-mercadofresco-app-a and -b. Diagnose (a) the three possible network causes, in order of likelihood, with the concrete check for each; (b) why the same role and the same definition did work with the EC2 launch type; (c) which specific VPC endpoint would fix the most likely case and why its type matters; and (d) which two checks you would add to the pipeline so this failure never reaches a deployment again.

Sara comes back from a conference with a proposal: get rid of Fargate and move the whole shop to Lambda behind API Gateway, "because you only pay per request and it scales to zero". She brings the figure that the shop receives about 300 orders/hour off-peak and that at four in the morning there is no traffic. Respond with technical and economic judgement: (a) three concrete technical reasons why MercadoFresco's shop is a poor fit for Lambda; (b) the approximate calculation comparing the cost of both options with the real traffic; (c) which part of her proposal is right and where it is already being applied in the current architecture; (d) what you would measure before ruling it out entirely; and (e) how you would explain it to her in one sentence that does not sound like "no".

Solution 1

(a) The combination. The 95th percentile is 0.31 vCPU and 780 MB. Adding 30 % of headroom: 0.40 vCPU and 1.01 GB. The next valid combination above that is 512 (0.5 vCPU) with 1 GB of memory. Going up to 1 vCPU would double the cost for 20 % of unused CPU, and dropping to 0.25 vCPU is not possible because it does not reach. Cost per task: 0.5 × 0.04656 + 1 × 0.00511 = 0.0279 USD/hour.

(b) How many tasks. One worker processes 3600 / 12 = 300 messages/hour. Off-peak, 150 messages/hour need 1 task, but the minimum must be 2 for availability: a single task means zero capacity while it is being replaced. At the peak, 900 messages/hour need 900 / 300 = 3 tasks just to keep up, and that is exactly the point where the queue does not grow but does not recover from a backlog either. To meet the 3 minutes with headroom and absorb the variability, 5 tasks are used at the peak, giving 1500 messages/hour of capacity and allowing an accumulated backlog to be drained.

(c) The auto scaling policy. CPU is no use: a worker consuming messages is always equally busy, whether the queue holds 10 or 10,000 messages, so CPU does not reflect the backlog. The correct metric is the backlog per task, calculated with a CloudWatch metric maths expression: ApproximateNumberOfMessagesVisible / RunningTaskCount. With a 3-minute objective and 300 messages/hour per task, the target is 300 / 60 × 3 = 15 messages per task.

A scheduled action is added for Fridays, raising MinCapacity to 5 at 16:45 and returning it to 2 at 21:30, with --timezone "Europe/Madrid": scaling up by the clock avoids the first few minutes of backlog that a reactive policy cannot avoid by definition.

(d) The capacity split. capacityProvider=FARGATE,weight=1,base=2 plus capacityProvider=FARGATE_SPOT,weight=3,base=0. The two floor tasks are stable, and of the three extra peak tasks roughly 0.75 go on-demand and 2.25 to Spot. If AWS withdraws all Spot capacity during the peak, the 2 on-demand tasks remain, with capacity for 600 messages/hour against 900 incoming: the queue grows by about 300 messages/hour and the 3-minute agreement is breached in about twenty minutes. The mitigation has two parts: the auto scaling policy detects the backlog and asks for new tasks, which the on-demand provider can serve — the weight split applies to new tasks, and with Spot unavailable ECS launches on-demand; and an alarm on ApproximateAgeOfOldestMessage notifies alertas-mercadofresco if the oldest message passes 3 minutes. What you must not do is set base=0: the stable floor is what turns a Spot withdrawal into a degradation instead of an outage.

(e) Monthly cost. Off-peak: 2 tasks × 0.0279 × (730 − 17) ≈ 39.8 USD. At the peak (4 h × 4.3 Fridays = 17.2 h): 2 on-demand × 0.0279 × 17.2 ≈ 0.96 USD, plus 3 extra tasks mostly on Spot ≈ 3 × 0.0084 × 17.2 ≈ 0.43 USD. Total ≈ 41 USD a month, against the 156 USD of the dedicated worker ASG there used to be.

Solution 2

(a) The three network causes, by likelihood.

1. The ECR and Secrets Manager interface endpoints are missing, and there is no NAT in the pre-production subnet. It is the most likely cause because the error mentions registry auth and secrets, which are exactly the first two outbound calls a task makes. Check: aws ec2 describe-route-tables on the -app-a and -b subnets looking for the 0.0.0.0/0 route, and aws ec2 describe-vpc-endpoints filtered by VPC.
2. The endpoints' security group does not allow inbound traffic from the tasks'. Interface endpoints are ENIs with their own security group: if sg-mercadofresco-endpoints does not accept port 443 from sg-mercadofresco-tienda, they exist but cannot be used. Check: the inbound rules of sg-mercadofresco-endpoints.
3. The endpoint's private DNS is disabled. Without --private-dns-enabled, the name secretsmanager.eu-west-1.amazonaws.com still resolves to the public IP and the traffic tries to leave where there is no exit. Check: the endpoint's PrivateDnsEnabled field.

(b) Why it did work on EC2. Because with the EC2 launch type, what pulls the image and resolves the secrets is the instance's ECS agent, which uses the instance's network route and its security group. If those instances were in a subnet with a NAT or had a more permissive security group, everything worked. On moving to Fargate, connectivity comes to depend on the task's ENI, with the subnets and security group declared in networkConfiguration. It is the same boundary shift that awsvpc was about in 10-01, now visible: the network no longer belongs to the machine, it belongs to the task.

(c) The specific endpoint and why its type matters. For the most likely case three are needed: ecr.api, ecr.dkr and secretsmanager, all three of them interface endpoints (a private ENI with a security group, charged by the hour and by GB). But the one that usually goes missing without showing its face is s3, which is a gateway: it is not an ENI but an entry in the route table, it is free, and without it the image layers — which are stored in S3 — are not downloaded even if both ECR endpoints are perfect. Confusing the two types leads people to put an interface endpoint on S3, which works but costs money unnecessarily in this case.

(d) Two checks in the pipeline. The first, a deployment test in pre-production with the same network configuration as production: the failure shows up where it should. The second, an AWS Config rule (05-04) or a CDK test (09-02) verifying that every subnet used by an ECS service has either a route to a NAT or the five critical-path endpoints. It is an architectural invariant and therefore it is tested as code, not remembered. As a backstop, checking that the circuit breaker is enabled with rollback: true would have turned this incident into an automatic rollback instead of tasks spinning in the void.

Solution 3

(a) Three technical reasons.

1. The Aurora connection. Every concurrent Lambda opens its own connection, and with 300 orders/hour in concurrency spikes that exhausts the aurora-mercadofresco-pedidos pool quickly. It is solved with RDS Proxy, which adds cost and one more piece; on Fargate, each task keeps a stable pool and the problem does not exist.
2. The cold start with warm state. The shop keeps the catalogue cache in memory, preloaded from mercadofresco-catalogo at start-up. On Fargate that cost is paid once per task and lasts hours; on Lambda it would be paid at every cold start, and the first request of each execution environment would be slow just as a peak arrives.
3. The rewrite. The shop is a WSGI application running under Gunicorn; taking it to Lambda requires an adapter or splitting it into functions, plus a change to the session model, the static files and the observability. It is a project of several weeks with dubious benefit, right after finishing the migration to containers.

(b) The calculation. With 300 orders/hour on average and about 8 HTTP requests per order, that comes to around 2,400 requests/hour, that is, 1.75 million a month. Assuming 250 ms on average and 2 GB of memory: 1.75 M × 0.25 s × 2 GB = 875,000 GB-s. At 0.0000167 USD per GB-s that is about 14.6 USD, plus 0.35 USD of invocations, plus API Gateway: 1.75 M × 3.5 USD/million ≈ 6.1 USD. Total ≈ 21 USD, against the 70 USD of Fargate arm64. Sara is right on the raw number. But three items are missing that change the conclusion: RDS Proxy (about 30 USD/month), the cost of the rewrite (weeks of work, which at team cost far exceeds the annual saving of 588 USD) and the risk of latency from cold starts during the Friday peak, which is precisely the problem this module has just solved.

(c) Where she is right and where it is already applied. She is right on the principle: do not pay for idle capacity. And that principle is already applied where it fits: mercadofresco-generar-miniaturas is triggered by an S3 event and nothing is paid between photo uploads; -cobrar-pago, -reservar-stock and -asignar-reparto are short steps of the state machine; and the queue workers scale down to the minimum off-peak. The architecture is already hybrid by design: Lambda where the work is sporadic and short, Fargate where the process lives waiting for requests.

(d) What I would measure before ruling it out. Three concrete things: the real latency distribution of the shop by percentile in X-Ray, to know how much a cold start would weigh at p99; the number of simultaneous connections to Aurora at the Friday peak, to size whether RDS Proxy would be enough; and the real cost of Fargate over a full month with arm64 and the scheduled scaling already in place, because the comparison is being made against a number that has not been measured yet. Without those three figures, both positions are opinions.

(e) The sentence. "You are right on the principle, and that is why we are already applying it: everything that is triggered by an event and dies within seconds is already on Lambda. The shop is the opposite — a process that lives waiting for requests and keeps a cache and connections — and for that, Fargate costs fifty dollars more a month and saves us a rewrite, an RDS Proxy and the cold starts on Friday at seven."

The instances are gone. MercadoFresco's shop now runs on Fargate, and there is no longer any machine for Marta to list, size, patch or leave running.

You are clear on what disappears — the AMI, host patching, cluster scaling, task packing, idle capacity and even the ENI limit per instance — and on what is still yours: the image, the CPU and memory, the network and the permissions. With the sentence that orders the rest: Fargate does not remove the work of operating an application, it removes the work of operating a server. And with the real resource model: the valid CPU and memory combinations, the 20 GB of ephemeral storage extendable to 200, and the decision to size with the 95th percentile from Container Insights plus 30 %, because over-provisioning here is paid for from the first second. Plus arm64 with Graviton, which brings the service down from 88 to 70 USD a month with docker buildx and a week of testing in pre-production.

You have the operational differences and what to do about each: ECS Exec instead of SSH, audited in CloudTrail and with the rule that it is for diagnosing and not for fixing; FireLens with Fluent Bit as a sidecar where there used to be a DaemonSet, with awslogs as the default because the sidecar costs CPU in every task; and awsvpc as the only network mode, which is no longer a restriction but the normal way of working. And you have the number that justifies the whole module: from 120 seconds to 35-45 until a new task takes traffic, with the breakdown by phase and what it means on Friday at 19:00 when traffic goes from 300 to 900 orders/hour in eight minutes.

You have the complete migration: an unchanged task definition because it already declared FARGATE, private subnets snet-mercadofresco-app-a and -b with no public IP, a security group per task, and the VPC endpoints on the critical path — with the honest analysis that seven endpoints across two AZs come out more expensive than the NAT, and the reasoned decision to deploy only the four that matter. The three-layer auto scaling: target tracking as the baseline, and above all the Friday scheduled scaling, which raises the minimum to 6 at 16:45 with an explicit Europe/Madrid and costs 4.9 USD a month. Fargate Spot with the base=1, weight 1:4 split for the workers and the criterion that decides where it belongs: only where an interruption with two minutes' notice retries itself. The scheduled tasks with EventBridge Scheduler for the nightly load into Redshift, with a flexible window, retries and a DLQ. And the pipeline with CodeDeploy's canary blue/green on tg-mercadofresco-tienda and -verde, which brings restoration down from 4 minutes to under 1 because rolling back means moving a listener; all of it in twenty lines of CDK with ApplicationLoadBalancedFargateService.

And you have the honest comparison of Fargate versus EC2 versus Lambda, with the criterion that settles most of the doubts — if the process lives waiting for requests, it is Fargate; if it wakes up on an event and dies, it is Lambda; if you need control of the machine, it is EC2 — and MercadoFresco's component-by-component decision, in which EC2 no longer appears in a single row.

One question remains that somebody on the team will ask this very week, and it deserves a serious answer rather than a shrug: everybody talks about Kubernetes. It is the de facto standard for container orchestration, it has an enormous ecosystem, it works the same on any cloud and a great many people know how to use it. Are we making a mistake by staying with ECS?

In 10-03, "Amazon EKS", that is answered with data rather than preferences. You will see what Kubernetes is and what it solves that ECS does not, its minimal but real vocabulary, what EKS manages and what is still yours, the four compute options including Auto Mode, the complete manifests for deploying the shop with probes, Ingress and the AWS Load Balancer Controller, IRSA and Pod Identity as the equivalents of the task role, Karpenter for the nodes, and the central argument almost nobody writes down: the hidden cost of version upgrades. Together with the ECS versus EKS comparison and MercadoFresco's reasoned decision, along with the objective criteria that would change it.