The previous lesson ended with a question somebody on the team was going to ask that very week: 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 there are plenty of people who know how to use it. If MercadoFresco has just moved its whole shop onto containers and has settled on ECS, is it getting this wrong?

This lesson answers with data. You will see what Kubernetes really is and what it solves that ECS does not, what Amazon EKS manages and what is still your job, how MercadoFresco's shop is deployed with complete manifests, and what the cost is that almost never appears in the comparisons: the recurring work of version upgrades. At the end, MercadoFresco's reasoned decision and the objective criteria that would change it. And with it, the close of the module and the jump to module 11.

Cost warning. The EKS control plane costs 0.10 USD per hour per cluster, around 73 USD a month, regardless of size. With extended support — when the Kubernetes version leaves standard support — it goes to 0.60 USD per hour, around 438 USD a month, and it is an automatic charge that catches a lot of people out. On top of that come the nodes (EC2 or Fargate), the load balancer and the add-ons. A forgotten test cluster is one of the most expensive leftovers in the course: follow the cleanup section at the end. Fictitious data and identifiers.

1. What Kubernetes is and what it solves that ECS does not
2. The bare minimum vocabulary, properly understood
3. The declarative model and the reconciliation loop
4. What EKS manages and what is still yours
5. Compute options: nodes, Fargate and Auto Mode
6. Creating a cluster with eksctl and with CDK
7. kubectl and access to the cluster
8. Authentication: access entries versus aws-auth
9. IRSA and EKS Pod Identity: AWS permissions for a pod
10. The manifests for MercadoFresco's shop
11. Ingress and the AWS Load Balancer Controller
12. Auto scaling: HPA, Cluster Autoscaler and Karpenter
13. Add-ons: why an empty EKS is no use at all
14. Version upgrades: the hidden cost
15. Observability: Container Insights, Prometheus and Grafana
16. ECS versus EKS: the honest comparison
17. MercadoFresco's decision and what would change it
18. Cost and cleanup
19. Common mistakes and tips
20. Exercises
21. Module wrap-up and transition to module 11

Kubernetes is an open-source container orchestrator, born at Google and donated to the Cloud Native Computing Foundation. It does the same as ECS — keeping containers running, spreading them across machines, replacing them, exposing them over the network — with one fundamental difference in design: Kubernetes is an extensible platform with an API of its own, not a vendor's service.

That difference produces three capabilities ECS does not have:

• Real portability. A Kubernetes manifest works on EKS, on Google Kubernetes Engine, on Azure Kubernetes Service, on a cluster of your own and on Luis's laptop with kind. An ECS task definition only works on AWS. For MercadoFresco this is not urgent today, but it is the weightiest argument in favour of EKS.
• An ecosystem that solves problems you do not want to solve. There are thousands of components ready to install: certificate management (cert-manager), progressive delivery (Argo Rollouts, Flagger), GitOps (Argo CD, Flux), service meshes (Istio, Linkerd), operators that manage databases, queues or search engines as if they were native resources. On ECS, almost all of that is either provided by AWS or written by you.
• Extensibility through the API. With CRDs (Custom Resource Definitions) and operators you can create your own resource types. That is what allows you to run kubectl apply against a file declaring "I want a Kafka cluster with three replicas" and have an operator build it and keep it running. ECS has no equivalent.

And it produces a cost that has to be named with equal clarity: Kubernetes is substantially more complex. There are more concepts, more pieces to install, more configuration that can be wrong and more versions to upgrade. The right question is not "which is better?" but "does the problem I have justify that complexity?".

These are the objects you need to know to read a manifest without getting lost. The right-hand column anchors each one to what you already know from earlier modules.

Two warnings about that table, because they are a constant source of errors:

• A Kubernetes Secret is not encrypted by default. It is base64-encoded, which is not encryption: anyone with read permission on the namespace sees it in the clear. It is solved with etcd encryption using KMS and, better still, with the secrets CSI driver that brings the values in from Secrets Manager (see below).
• The Deployment is not the service and the Service is not the Deployment. The Deployment manages the pods; the Service gives them a stable name. In ECS, both things live inside the "service" object, and that merging is one of the reasons ECS is simpler and less flexible.

Kubernetes does not execute orders: it compares states. You declare the desired state and a set of controllers works continuously so that the actual state matches it.

The practical consequence is that deleting a pod by hand achieves nothing: the ReplicaSet notices replicas are missing and creates another one within seconds. It is the same logic as the desiredCount in ECS, generalised to every object in the system and exposed as an API anyone can extend.

And the cultural consequence is more important: in Kubernetes the manifest is the infrastructure. This fits naturally with what you learned in module 9 and leads to GitOps: a Git repository is the source of truth and an agent in the cluster (Argo CD or Flux) applies whatever is in it, reverting any manual change. It is a more rigorous way of working than module 8's, and also one more piece to install, upgrade and operate.

Amazon EKS is managed Kubernetes: AWS operates the control plane and you operate everything else. The concrete list matters, because almost every disappointment with EKS comes from expecting more than it offers.

The sentence to remember: EKS manages the control plane, not the cluster. A freshly created EKS cluster cannot deploy anything useful: it is missing the load balancer controller, the autoscaler, the secrets controller and the metrics. That distance between "cluster created" and "cluster operational" is where most of the work lives.

The pods have to run somewhere, and EKS offers four models.

EKS on Fargate works with Fargate profiles: you declare which namespaces or labels make a pod run without a node. It has important limitations you need to know about before relying on it: it does not support DaemonSets, nor persistent storage other than EFS, nor hostPort, nor privileged pods, and it runs one pod per Fargate task with the resource rounding that implies. The practical consequence is that many add-ons — which are installed as DaemonSets — cannot run on Fargate, so you almost always need at least a small node group for them.

EKS Auto Mode is AWS's answer to the argument in this lesson: it manages the nodes, the scaling, the patching and several essential add-ons, recycling the nodes automatically at intervals. It cuts operational work considerably in exchange for a surcharge on the compute price and less control. What it does not remove is the part that weighs most: you still decide and carry out the Kubernetes version upgrades and you are still responsible for your manifests being compatible.

eksctl is the community's official tool and the quickest route. It is declarative: you give it a file and it builds the VPC — or uses yours — the control plane, the node groups and the add-ons.

Four decisions in that file deserve attention:

• publicAccessCIDRs restricted. By default the API server endpoint is reachable from any IP on the internet — protected by authentication, but exposed. Restricting it to the corporate network, or moving to private access only, is one of the first things an audit looks at.
• privateNetworking: true. Nodes in private subnets, consistent with everything MercadoFresco did in module 3 and with what you learned in 10-02 about VPC endpoints. The same endpoints from the previous lesson are needed here.
• withOIDC: true. Without the OIDC provider there is no IRSA, and without IRSA the only way to give a pod AWS permissions is the node role, which is a serious flaw: every pod on that node would inherit those permissions.
• ENABLE_PREFIX_DELEGATION. Without this, each pod consumes a secondary IP on the node's ENI and the pods-per-node limit is reached long before CPU or memory runs out. It is the EKS equivalent of awsvpcTrunking from 10-01, and it catches people out just as much.

In CDK (09-02), the equivalent is shorter but demands the same understanding:

kubectl is the client. It is configured with one command that writes the context into ~/.kube/config using the current AWS credentials:

The last command looks trivial and is not: kubectl points at the last cluster configured, and kubectl delete deployment tienda does not ask which environment you are in. It is the cdk destroy --all of 09-02 in another shape. The discipline that prevents it is twofold: separate accounts per environment (09-04), so that development credentials cannot touch the production cluster, and an indicator of the active context in the terminal prompt.

Kubernetes has its own permission system, RBAC, with Role, ClusterRole, RoleBinding and ClusterRoleBinding. EKS connects that system to IAM: IAM says who you are, RBAC says what you can do inside the cluster.

Historically that connection was made through a ConfigMap called aws-auth, and it was a notorious source of incidents: one syntax error while editing it could lock everybody out of the cluster irreversibly, with no way out but to recreate it. Today the correct approach is access entries, which are an AWS API: they are created with the CLI or with CDK, audited in CloudTrail and do not depend on editing YAML by hand.

The permission sets are the ones from 09-04: AdministracionPlataforma, DesarrolloCompleto and AnalisisDatos. The correspondence comes out clean: the same identity mechanism that governs the five accounts also governs the cluster, with no parallel Kubernetes users and no separate credentials. It is one of the genuine advantages of EKS over self-managed Kubernetes.

The exact equivalent of the ECS task role (10-01). A shop pod needs to send to cola-mercadofresco-pedidos and read mercadofresco-carritos, and it needs to do so with its own permissions, not the node's.

With Pod Identity, which is the recommended option today:

And the role's trust policy, which is what changes compared with a normal role:

The permissions policy is literally the same as the ECS task role's in 10-01: sqs:SendMessage on the queue, dynamodb:*Item on the carts table and s3:GetObject on the catalogue photos. The same least-privilege principle, a different way of anchoring it to the workload.

Here is what in ECS was a task definition plus a service. We start with the Namespace, the ServiceAccount and the ConfigMap:

The Deployment, which is the heart of the deployment:

The points to understand in that manifest:

• The three probes are three different questions and confusing them causes incidents. startupProbe answers "has it finished starting?" and suspends the other two until it succeeds. readinessProbe answers "can it take traffic now?" and its failure takes the pod out of the load balancing without killing it. livenessProbe answers "is it hung?" and its failure restarts the container. The classic mistake is pointing livenessProbe at a /salud that queries Aurora: when the database is slow, Kubernetes restarts every pod at once and turns a latency problem into a total outage.
• requests and limits are not the same thing. requests is what the scheduler reserves in order to decide which node the pod fits on; limits is the ceiling. If CPU goes over the limit, the pod is throttled (it slows down); if memory goes over it, the kernel kills it with OOM and you will see OOMKilled in the events. Setting requests far below real usage produces overcommitted nodes that fall over together.
• maxUnavailable: 0 with maxSurge: 2 is exactly ECS's 100/200: there is never less healthy capacity than desired, at the price of paying for a few minutes of double capacity during the deployment.
• preStop with a short wait solves the same problem as target group draining: when Kubernetes decides to terminate a pod, the ALB can take a few seconds to stop sending it traffic. Without that wait, requests are lost on every deployment.
• The referenced Secret is not written by hand. MercadoFresco uses the secrets CSI driver with the AWS provider, which mounts mercadofresco/produccion/rds/mfadmin from Secrets Manager and optionally syncs it as a Kubernetes Secret. That way the secret does not live in Git or in etcd in base64.

The Service, which gives the pods a stable name:

An Ingress on its own does nothing: it is a declaration that needs a controller to translate it into a real load balancer. On EKS, that controller is the AWS Load Balancer Controller, which creates and configures a genuine ALB (03-03) from the annotations.

Three observations that connect back to earlier modules. target-type: ip makes the ALB send traffic straight to the pod's IP, without going through the node's NodePort: it is the exact equivalent of the ip-type target group from 10-01, and it saves a network hop. group.name lets several Ingresses share a single ALB, which matters because each ALB costs around 17 USD a month in fixed cost and creating one per service adds up fast. And the WAF and certificate annotations show that, underneath, it is still the same ALB from module 3 with the same protections from module 4: EKS changes how it is declared, not what you get.

In Kubernetes there are two kinds of scaling and they are independent: pod scaling and node scaling. Confusing them is the cause of the complaint "I have configured auto scaling and it does not scale".

The HorizontalPodAutoscaler is the equivalent of ECS service auto scaling:

Scaling on requests per target — which 10-01 showed to be better than CPU — additionally requires installing KEDA or the CloudWatch metrics adapter here, because the native HPA only understands CPU and memory. It is a small, representative example of the general pattern: what in ECS is a parameter, in Kubernetes is usually one more component to install and maintain.

For the nodes there are two options:

Karpenter is the recommended option today and it is genuinely good: it watches the pods that do not fit, decides which instance would host them best, launches it and, when there is spare capacity, consolidates the workloads and shuts nodes down. But it is worth seeing the whole picture: to get in EKS what comes built into Fargate — capacity appearing when it is needed and disappearing when it is not — you have to install, configure, upgrade and watch over one more controller. And even with Karpenter, the new pod waits for an EC2 instance to start: the two minutes MercadoFresco wanted to eliminate reappear whenever there is no room.

A freshly created cluster has three things and is missing many. This is the real minimum list needed to run MercadoFresco's shop:

The five marked "No" are software MercadoFresco would have to install with Helm, version, test and upgrade, each with its own life cycle and its own compatibility matrix against the Kubernetes versions. None of them is hard on its own. The sum of them is, and it is the part of EKS that never appears in an afternoon's comparison.

On ECS, the equivalent of that entire table is: nothing. The load balancer is a service parameter, the secrets are a field in the task definition, the scaling is Application Auto Scaling and the metrics come with Container Insights.

This is the central argument of the lesson and the one that weighs most in the final decision.

Kubernetes releases about three minor versions a year. EKS gives standard support for about 14 months per version; after that it automatically enters extended support, which lasts about 12 months more and costs 0.60 USD per hour instead of 0.10, that is, around 438 USD a month per cluster instead of 73. When extended support ends, AWS upgrades the cluster itself.

What that means in real work, three or four times a year and per cluster:

1. Read the release notes and spot the retired APIs. Kubernetes retires API versions between minor releases, and a manifest that used to work stops applying. Tools such as kubent help find them, but the review is yours.
2. Check the compatibility of every add-on: the load balancer controller, Karpenter, the secrets CSI, KEDA, the CNI. Each has its own matrix, and sometimes the add-on has to be upgraded before the cluster.
3. Upgrade the control plane, which takes around 25-40 minutes and cannot be rolled back.
4. Upgrade the nodes, replacing instances in batches and draining pods, with the usual risk that a badly set PodDisruptionBudget blocks the drain.
5. Test all of it in a pre-production cluster first, which means maintaining that cluster, with its 73 USD a month control plane and the same add-ons.

Twenty or thirty days a year is more than a month of one person's time. That is the hidden cost of EKS, and Auto Mode does not remove it: Auto Mode takes care of the nodes, but the Kubernetes versions, the compatibility of your manifests and the add-ons you install are still yours.

On ECS that work simply does not exist. There is no ECS version to upgrade; AWS evolves the service without anyone planning anything. It is the most honest comparison you can make between the two, and for a small platform team it is decisive.

Everything from module 5 still applies; what changes is the ecosystem's native tooling.

• Container Insights is enabled with the CloudWatch observability add-on and gives cluster, node, pod and container metrics, plus the container logs in /aws/containerinsights/eks-mercadofresco/application. It is the most direct route and the one that adds the fewest pieces.
• Amazon Managed Service for Prometheus is managed Prometheus, compatible with PromQL. It fits well because most of the ecosystem's components — the load balancer controller, Karpenter, KEDA — already expose metrics in Prometheus format. It is collected with the CloudWatch agent or the OpenTelemetry collector, and you pay per sample ingested and stored.
• Amazon Managed Grafana is managed Grafana, with access through IAM Identity Center (09-04) and data sources pointing at Prometheus, CloudWatch and X-Ray. You pay per active user per month.
• The control plane logs — api, audit, authenticator — are enabled on the cluster and go to CloudWatch Logs. The audit one is what answers "who deleted that Deployment", and it is worth enabling from day one because it is not retroactive.

The honest observation: the Prometheus plus Grafana combination is more powerful than CloudWatch for Kubernetes metrics, with better querying and a catalogue of ready-made dashboards. And it is also more pieces: two more services to configure, two more bills and two more places to look during an incident. For MercadoFresco, with the mercadofresco-produccion and -negocio dashboards already built in 05-01, the gain does not justify the fragmentation.

Neither column is "the good one". The correct reading is: EKS buys flexibility, portability and ecosystem, and pays for them with complexity, people and recurring work. If you need what it buys, the price is reasonable. If you do not need it, you have bought yourself work.

MercadoFresco stays on ECS with Fargate. And the reason should be written down, because a decision with no written arguments gets revisited every six months depending on the last conference somebody went to.

The arguments, in order of weight:

1. The platform team is Marta and half of Luis. Twenty or thirty days a year of upgrades across two people who also handle the network, security, the pipeline and on-call is not an affordable cost: it would be 10-15 % of their total capacity spent maintaining the orchestrator rather than the shop.
2. There is no requirement ECS does not cover. The shop is an HTTP service with external state, some workers that consume queues and some event-driven functions. None of that needs CRDs, operators, service meshes or advanced pod scheduling.
3. There is no multi-cloud requirement. MercadoFresco is on AWS and there is no plan and no commercial pressure to change that. Kubernetes portability is insurance, and insurance that is never going to be used is just a premium.
4. Speed matters. Module 10 has taken the shop from EC2 to containers in weeks. With EKS, those same weeks would have gone on standing up the cluster, the add-ons and the team's learning, without having moved the shop yet.
5. The direct cost counts too, even if it is the smallest argument: 73 USD a month per cluster per environment is around 220 USD a month for development, pre-production and production, against 0 USD for ECS. It is little money compared with the cost of people, but it is not zero.

And the objective criteria that would change the decision, written in advance so that any future review is a check rather than a debate:

As long as none of those thresholds is met, the answer to "should we move to Kubernetes?" is no, and here is why. The day two of them are met, the answer changes, and this table says exactly when.

With one nuance that avoids the opposite mistake: Luis should learn Kubernetes anyway. It is a marketable skill and it gives you the judgement to assess other people's architectures. Learning it does not oblige you to adopt it, and adopting it without knowing it is the worst possible combination.

Multiplied by three environments, an EKS setup equivalent to MercadoFresco's current one would cost in the order of 800 USD a month against roughly 250 USD for ECS with Fargate and arm64 — and that comparison does not include the 20-30 platform days a year, which is the larger cost.

Cleanup, and here the order matters more than in any other lesson: the AWS resources created from inside the cluster — the Ingress's ALB, the EBS volumes of the PersistentVolumeClaims — are not deleted when the cluster is deleted and are left orphaned and billing.

If you delete the cluster before the Ingresses, the controller that knew how to delete the ALB disappears with it and the load balancer carries on billing indefinitely. It is the most expensive and most frequent leftover in EKS.

Mistake: a livenessProbe that queries the database. When Aurora is slow, Kubernetes restarts every pod at once and a degradation turns into an outage. Tip: liveness should only check that the process responds; dependencies belong in readiness.

Mistake: not setting a startupProbe. An application that takes 40 seconds to start is restarted by liveness before it finishes, in a loop. Tip: a startupProbe with a generous failureThreshold; it suspends the other two until it succeeds.

Mistake: requests far below real usage. The nodes end up overcommitted and several pods fall over together. Tip: requests close to the real 95th percentile and limits with headroom, measured with Container Insights.

Mistake: granting AWS permissions through the node role. Every pod on the node inherits everything. Tip: Pod Identity or IRSA always, even in development, because what is done in development gets copied into production.

Mistake: editing aws-auth by hand. One syntax error locks everybody out of the cluster with no way back. Tip: use access entries (AuthenticationMode: API) and do not touch that ConfigMap.

Mistake: storing Kubernetes Secret objects in Git. Base64 is not encryption. Tip: the secrets CSI driver with Secrets Manager, and etcd encryption with KMS enabled when the cluster is created.

Mistake: deleting the cluster before the Ingresses. The ALB is left orphaned and billing. Tip: the cleanup order above, with verification between steps.

Mistake: letting the cluster drift into extended support unnoticed. The bill multiplies by six in silence. Tip: a calendar alarm at 12 months for each version and a per-account budget (11-04) that catches the jump.

Mistake: one ALB per Ingress. Ten services, ten load balancers, 170 USD a month. Tip: alb.ingress.kubernetes.io/group.name to share one ALB between Ingresses.

Mistake: choosing EKS for the CV. It is a real and sincere reason, and a bad technical one. Tip: if the team wants to learn Kubernetes, let them stand up a lab cluster with its own budget; production is decided with the criteria in the table.

Tip: if you choose EKS, choose Karpenter and Auto Mode from the start too. Starting with Cluster Autoscaler and migrating later is duplicated work.

Tip: enable the control plane audit logs on day one. They are not retroactive, and they are the only thing that answers "who deleted that Deployment".

Tip: set topologySpreadConstraints by zone on every production Deployment. Without them, the scheduler can put all three replicas in the same AZ and one zone going down leaves you with no service.

The cola-mercadofresco-pedidos workers run today on Fargate with 0.5 vCPU and 1 GB, scaling from 2 to 8 tasks according to queue backlog, with a 1:4 split between on-demand and Spot. Write the Kubernetes equivalent: (a) the complete Deployment, with the probes appropriate to a process with no HTTP server and with graceful shutdown; (b) how you solve auto scaling on queue depth, saying which additional component is needed and why the native HPA is not enough; (c) how you achieve the equivalent of the split between on-demand and Spot capacity; and (d) list every piece you have had to add to the cluster to achieve what in ECS were three parameters.

On a Friday at 19:20, with the peak under way, Aurora suffers a degradation and queries go from 20 ms to 900 ms. Two minutes later the whole shop disappears: every pod is in CrashLoopBackOff, the ALB has no healthy targets and mercadofresco-alb-latencia-alta has given way to a total failure. The database, meanwhile, is still responding — slow, but alive. Explain (a) the exact causal chain that turned a degradation into a total outage; (b) which specific piece of manifest configuration is to blame and why on ECS, with the target group health check, the outcome would have been different; (c) how the three probes are redesigned so that this incident is a degradation and not an outage; (d) what mechanism you would add in the shop's code to degrade gracefully; and (e) which alarm would have warned sooner.

Eighteen months have passed. MercadoFresco has grown: it operates in four cities, it has 22 services instead of 3, the platform team is now 4 people of whom 2 have worked with Kubernetes in a previous job, and its largest wholesale customer requires by contract that its instance of the orders service can run in its own data centre. On top of that, the data team wants to use a Kubernetes operator to manage its processing pipelines. Apply the criteria table from the lesson and answer: (a) which thresholds are met now; (b) what your recommendation is and with what level of confidence; (c) if you recommend migrating, how you would do it without repeating the mistakes of the 09-04 migration plan; (d) what stays on ECS even if you migrate; and (e) what total annual cost you would estimate for the decision, including people.

Solution 1

(a) The Deployment.

There is no readinessProbe and that is deliberate: readiness decides whether a pod receives traffic from a Service, and nobody sends traffic to a queue worker. Adding one would be noise with no effect. liveness is essential, for the same reason as in 10-01: a hung worker does not die, it stops consuming the queue and nobody notices. Graceful shutdown is the same SIGTERM handler from that exercise, with terminationGracePeriodSeconds: 120 as the equivalent of the stopTimeout.

(b) Auto scaling on queue depth. The native HPA only understands CPU and memory from the resource metrics, and you have already seen that the CPU of a queue consumer does not reflect the backlog. You need KEDA, which installs an external metrics adapter and brings a specific scaler for SQS:

The alternative without KEDA is the CloudWatch metrics adapter plus an HPA with an external metric, which is more hand-rolled. Either way, it is one more component to install, version and upgrade in order to get what in ECS was one Application Auto Scaling policy.

(c) The equivalent of the on-demand / Spot split. There is no capacityProviderStrategy; you get there with Karpenter, declaring two NodePool objects, one with capacity-type: on-demand and another with spot, and using a preferred nodeAffinity towards Spot in the Deployment plus topologySpreadConstraints on the karpenter.sh/capacity-type label to guarantee that at least one replica lands on on-demand. You also need the interruption handler, which Karpenter includes: it listens for EC2's two-minute notice and drains the node. Result: what in ECS were two lines of --capacity-provider-strategy here are two NodePools, affinity rules, topology constraints and a controller.

(d) The pieces added. To match three ECS parameters you have needed: Karpenter (nodes and Spot), KEDA (queue-based scaling), Metrics Server (the basis for the HPA), EKS Pod Identity Agent (the pod's SQS permissions) and, if you want equivalent observability, the CloudWatch Observability add-on. Five components, each with its version, its compatibility with the Kubernetes version and its own upgrade cycle. That is exactly the arithmetic of the add-ons section.

Solution 2

(a) The causal chain. Aurora degrades to 900 ms. The shop's /salud queries the database, so it starts taking longer than the 3 seconds of timeoutSeconds. The livenessProbe accumulates 3 consecutive failures — about 60 seconds with periodSeconds: 20 — and Kubernetes restarts the container. On restarting, the pod has to start up again, preload the catalogue cache and reconnect to the same slow Aurora, so the start-up fails as well. Since all the pods query the same database, this happens to all three at once and in lockstep. The repeated restarts lead to CrashLoopBackOff, with growing waits between attempts. And there is an aggravating factor: the mass restarts open and close connections against an already saturated Aurora, making the root cause worse. A complete feedback loop.

(b) The culprit and the difference with ECS. The culprit is the livenessProbe pointing at a /salud that checks external dependencies. In ECS, the target group health check has a different effect: an unhealthy target is taken out of the load balancing, and the service only replaces tasks if the task dies or if the deployment requires it. The ECS equivalent of liveness is the container's healthCheck, which most people configure more loosely or do not set at all. In other words: Kubernetes is more aggressive by default and gives you a more dangerous tool, and that is why it demands understanding. The difference is not that ECS is better, it is that Kubernetes lets you shoot further.

(c) Redesigning the three probes.

• livenessProbe → /vivo, an endpoint that only confirms that the process responds and the event loop is not blocked. Without touching Aurora, without touching the cache, without touching the network. With periodSeconds: 20 and failureThreshold: 5, so that a transient spike does not cause a restart.
• readinessProbe → /listo, which does check the dependencies: connections to Aurora and to ElastiCache. Its failure takes the pod out of the load balancing but does not kill it, so when Aurora recovers the pod goes back to receiving traffic without having restarted. Here failure is reversible and cheap.
• startupProbe → /listo with a wide failureThreshold (12 × 5 s = 60 s), covering the catalogue preload and suspending the other two in the meantime.

With that design, the Friday incident would have been: every pod marked not ready, the ALB returning 503 on the requests that need the database, the pods alive and with their cache warm, and immediate recovery once Aurora recovered. A degradation, not an outage.

(d) Graceful degradation in the code. Have /listo distinguish between "I can do nothing" and "I can do part of it". The shop can serve the catalogue from mercadofresco-catalogo in ElastiCache even if Aurora is slow; what it cannot do is confirm orders. With a circuit breaker (07-05) around the calls to Aurora, the shop stops trying after N failures, returns a clear message at the checkout step and carries on serving browsing. The customer sees "we cannot confirm orders right now" instead of a blank page, and Aurora stops receiving the avalanche of retries that was preventing its recovery.

(e) The alarm that would have warned sooner. The Aurora latency one, ReadLatency and WriteLatency, with the threshold on the 99th percentile and not on the average — the average takes far too long to move. It would have fired a minute into the degradation, before the first livenessProbe had accumulated its three failures, giving real room to act. In addition, an alarm on pod restarts (pod_number_of_container_restarts in Container Insights) would have identified the feedback loop immediately, which is the piece of information that was missing to diagnose it in the heat of the moment.

Solution 3

(a) Thresholds now met. Four of the six:

(b) Recommendation. Yes, migrate to EKS, with high confidence. The decisive criterion is the second one: the contractual hybrid requirement is the only thing ECS cannot satisfy in any way, and it is not a preference but an obligation to a customer. The other three reinforce that the cost is now affordable: there is experience, there is a team and there is a concrete ecosystem need. The decision taken eighteen months ago was not wrong: it was correct given the data available then, and that is precisely the value of having written the criteria down in advance.

(c) How to migrate. By applying the lessons of 09-04 and of module 10 itself:

1. A new cluster, not a conversion. The development cluster first, with Auto Mode or Karpenter from the start so as not to duplicate work.
2. A non-critical service first. The reporting or notifications service, not the shop. You learn on something whose failure does not cost orders.
3. The add-ons before the workloads, with their versions pinned in Git and deployed with Helm from the pipeline, never by hand.
4. Real, extended coexistence. ECS and EKS side by side for months, with the ALB splitting by weights just as in 10-01 and 10-02. No overnight cutover.
5. The shop last, and with the same 90/10 split used to move from EC2 to Fargate.
6. An explicit deadline per phase, which is the mistake 09-04 pointed out: half-finished migrations last years if nobody sets milestones.
7. The wholesale customer's installation at the end, once the team already operates EKS comfortably, not as the first project.

(d) What stays on ECS even if you migrate. Whatever gains nothing from the change: the Lambdas (-cobrar-pago, -reservar-stock, -generar-miniaturas, -asignar-reparto), which are not containers and remain the best option for sporadic work; the scheduled tasks that load into Redshift, which work perfectly with EventBridge Scheduler; and probably the workers on the less critical queues for quite some time, because migrating them adds nothing and does consume attention. Migrating everything for aesthetic consistency is an expensive mistake: consistency is measured in criteria, not in technologies.

(e) Estimated annual cost. Infrastructure: 3 clusters × 73 USD × 12 = 2,628 USD of control planes, plus the node differential against Fargate, which with Karpenter and Spot used well may even be favourable — call it neutral. People: 25 days a year of platform work on upgrades and cluster maintenance, plus a one-off cost of 2-3 person-months for the migration. With an estimated internal cost of 400 USD a day, the recurring part is around 10,000 USD a year and the migration around 20,000-25,000 USD one-off. Total for the first year: in the order of 35,000 USD. That is the number to put in front of management alongside the wholesale customer's contract, because the decision is not a technical one: it is an investment with a concrete commercial justification.

MercadoFresco has finished the module with the shop off the machines and with a reasoned answer to the Kubernetes question.

You understand Kubernetes properly: an extensible orchestrator with an API of its own, whose real value lies in portability, the ecosystem and extensibility with CRDs and operators; its minimum vocabulary — Pod, ReplicaSet, Deployment, Service, Ingress, Namespace, ConfigMap and Secret, with the warning that a Secret is base64 and not encryption; and the declarative model with its reconciliation loop that explains why deleting a pod by hand achieves nothing and why GitOps fits so naturally. You are clear on what EKS manages — a control plane across three AZs, etcd, the upgrade mechanism and the IAM integration — and on the sentence that avoids most disappointments: EKS manages the control plane, not the cluster.

You have the four compute options with their real limits — including the fact that EKS on Fargate does not support DaemonSets, which forces you to keep nodes for the add-ons — cluster creation with eksctl and with CDK, aws eks update-kubeconfig and the discipline of checking the context before typing a delete. And modern authentication: access entries instead of aws-auth, with the permission sets from 09-04 governing the cluster too, and Pod Identity as the exact equivalent of the ECS task role.

You have the complete manifests for the shop: a Deployment with the three probes properly separated — startup to get going, readiness to receive traffic, liveness to restart — requests and limits as distinct concepts, spreading across AZs with topologySpreadConstraints, preStop so as not to lose requests and an unprivileged security context; the Service; and the Ingress with the AWS Load Balancer Controller, which creates the same ALB from module 3 with the WAF from module 4, with target-type: ip and group.name so as not to pay for one load balancer per service. Plus auto scaling on two planes: HPA for the pods, Karpenter for the nodes, and the observation that matching three ECS parameters took five components.

And you have the argument almost nobody writes down: the hidden cost of upgrades. Three versions a year, 14 months of standard support, an automatic jump from 73 to 438 USD a month on entering extended support, and 20-30 platform working days a year reviewing retired APIs, compatibility matrices and node drains. On ECS that work does not exist. Together with the honest comparison between the two — EKS buys flexibility, portability and ecosystem, and pays for them with complexity, people and recurring work — and MercadoFresco's decision: it stays on ECS with Fargate, because of a two-person platform team, the absence of requirements ECS does not cover, the absence of any multi-cloud need and speed; with the six objective criteria, written in advance, that would change that decision the day they are met.

What has changed for MercadoFresco in this module. There is no longer an AMI to rebuild when a dependency changes: there is an image in mercadofresco/tienda versioned per commit and deployed by digest. There is no longer an operating system to patch: the host belongs to AWS and Inspector's continuous scanning warns about what is genuinely yours. And there are no longer two-minute start-ups: there are tasks that take traffic in forty seconds, with scheduled scaling that also has them ready before the Friday peak arrives.

And here comes the question nobody has asked yet and that the manager will ask on Monday morning. The architecture is complete: it is elastic, secure, observable, deployable from a pipeline, described in code and spread across five accounts. But how much does all this cost? Is it money well spent? How does it break down between production, pre-production and development, and between the four cities? Is there anything switched on that nobody uses? And what could be committed to in advance to pay less?

In module 11, "Best practices and cost management", that is answered methodically. 11-01 reviews the complete architecture with the Well-Architected Framework and its six pillars, which is the structured way to audit what has been built. 11-02 brings order to tagging and cost allocation, turning the five mandatory tags into reports somebody can actually read. 11-03 analyses the real bill with Cost Explorer. 11-04 sets limits and alerts with Budgets. 11-05 commits capacity with Savings Plans and reserved instances, which is where the Fargate versus EC2 comparison from 10-02 is finally settled. And 11-06 closes the course with the final project: designing, justifying and budgeting a complete architecture for MercadoFresco, with everything learned across eleven modules.