Episode 19: Container vs Lambda vs EC2: The AWS Compute Decision | SAA-C03 Interactive

Hey everyone, Balu here, welcome back to TechTalk with Balu, your complete guide to async the AWS Solutions Architect Associate Exam. Today we are tackling episode 90 and we are diving into the world of containers on AWS. We are covering ECS, EKS, and fogate, the three services that are increasingly important on the exam, and absolutely essential for modern application architectures. Here's the story I want you to keep in mind. You have already learned two ways to run code on AWS, EC2 instances back in episode 1 and 2, where you manage servers and lambda functions back in episode 11, where AWS runs your code without any servers. Today we complete that story with containers, the middle ground. You get more control than lambda, but less operational overhead than EC2. Modern applications increasingly live in containers and knowing when to use them is a critical architecture skill. By the end of this episode, you will understand the difference between ECS and EKS, no when to use fogate versus EC2 launch type, and be able to choose between containers, lambda, and EC2 for any workload. And you will handle the container questions on the exam more confidently. This episode, by the way, continues the interactive format that's called pulse checks, trap spotlights, and memory hooks, so let's get started. Section 1, why containers? Let's start with the basics. What is a container and why do developers love them? A container is a lightweight portable package that includes your application code and everything it needs to run, the runtime, libraries, dependencies, configurations, etc. You build a container once and it runs the same way anywhere on your laptop, on a co-workers laptop, on a test server, or on production. That runs the same everywhere promise is huge here. It eliminates the classic it works on a machine problem. Containers are different from virtual machines, by the way. A VM includes an entire operating system. It's like packaging your whole house. A container, on the other hand, only includes your application and dependencies. It's like packaging just your furniture. Containers start in seconds instead of minutes. They use less memory and CPU. You can run many more containers on one server than you can run VMs. The dominant container technology is Docker. When people say containers in AWS context, they usually mean Docker containers. AWS has full Docker support. Now the question becomes, once you have containers, how do you run them at scale? Running one container on your laptop is easy. Running hundreds of containers across multiple servers, restarting failed ones, scaling based on loads, connecting them together. That is the hardest part. That's where container orchestration comes in. AWS gives you two main orchestration options. They are called ECS and EKS. A serverless compute option that works with both is called Fugget. That's what we're diving into today. A memory hook here, think of containers like shipping containers. A container of goods can go on any truck, any ship, any train, it's standardized. The same idea in software, your container of code runs the same everywhere it's standardized. And ECS and EKS are just the port authorities that manage where these containers must go. On to section 2, Amazon ECS fundamentals. Let's now start with Amazon ECS elastic container service. This is AWS's own container orchestration service. It's proprietary to AWS, that's it's tightly integrated with other AWS services and designed to be simple. ECS has three core concepts you need to understand. First, the cluster. A cluster is a logical grouping of resources where your containers can run. Think of it as your container playground. You can have a production cluster and a development cluster each isolated. Second, there is a task definition. This is a JSON blueprint that describes how to run your containers. It defines which container you may just use, how much CPU and memory to allocate, what ports to expose, environmental variables, networking mode, IAM roles and so on. Task definitions are versioned. When you update one, you create a new revision. The third is the service. A service takes a task definition and runs it. It maintains a desired number of tasks running, replaces failed tasks automatically and integrates with load balances. If you want five copies of your application running, you create a service with a desired count of five. Now here's where ECS gets interesting. There are two launch types for running your containers. The EC2 launch type? Your containers run on EC2 instances that you manage. You choose the instance types, patch the operating systems, handle scaling of the EC2 fleet and pay for the EC2 instances, whether the containers are using them or not. You get maximum control and it can be cost effective if you have consistently high container utilization. The Fargate launch type? This is the serverless option. You don't manage any EC2 instances here. AWS runs your containers for you. You specify how much CPU and memory each task needs and Fargate provisions the compute. You pay only for the resources your containers actually use per second. This is by far the simpler option operationally. ECS integrates natively with tons of AWS services. Application load balancer for distributing traffic, auto scaling for scaling based on CPU or custom metrics. I am for granular permissions. Each task can have its own IAM role. CloudWatch for logs and metrics, systems manager parameter store for configuration and secrets manager for secrets. It's a first class AWS citizen. One important thing to know, ECS supports rolling updates by default. When you update a service, ECS gradually replaces all tasks with new ones ensuring that there is no downtime. You can also configure blue or green deployments using code deploy for zero downtime deployments with instant rollback capability. One for a pulse check here, quick question. Your team wants to run containerized applications on AWS but doesn't want to manage any service patch operating systems or worry about capacity. They just want to define their containers and have them run, which combination of AWS services fits. Let's pause and think. The answer is ECS with Fargate launch type. ECS orchestrates the containers. Fargate provides the serverless compute. Your team defines the task definitions and services and do nothing else. AWS will handle everything else. There is zero server management. This is one of the most common exam scenarios, by the way. One for a craft spotlight. Watch for the keywords in ECS questions that say no server management or no infrastructure to manage. Almost always means it's Fargate. Cost optimize with consistent load or need full control over instances on the other hand points to easy to launch type. Don't default to one, mash the correct answer to the requirements. For a memory hook here, think of easy to launch type like renting a whole moving truck to hold your shipping containers, while Fargate is like paying for exactly the shipping container space you use on a share truck. Same containers but different infrastructure model. Now let's move on to section 3, AWS Fargate deep type. Let's dig deeper into Fargate because it's heavily tested on the exam. Fargate is AWS's serverless compute engine for containers. When you use Fargate, you never touch an EC to instance. You never patch an operating system, you never manage capacity. You basically just tell AWS run my container with this much CPU and this much memory and it just runs. Here's the key mental model with Fargate. You're paying for the resources your containers consume and not for the underlying service. If your container uses one virtual CPU and two gigabytes of memory for 10 minutes, that's then exactly what you pay for per second billing. When your containers aren't running, you're not paying. Fargate works with both ECS and EKS. When we talk about ECS on Fargate, it means using Fargate as the compute for your ECS tasks. And when we talk about ECS on Fargate, which uses Fargate profiles, it means using Fargate as the compute for your Kubernetes ports. The tradeoff of Fargate versus the EC2 launch type comes down to three factors. Number one cost. For low utilization or spiky workloads, Fargate is often cheaper because you only pay when containers are running. For consistently high utilization, EC2 launch type can be cheaper if you use reserved instances or savings plans on the EC2 fleet. Number two control. Fargate abstracts away the underlying infrastructure. You can't access it into the host, install monitoring agents at the host level or use certain networking features. The EC2 launch type gives you full control if you need those things. Number three operational overhead. Fargate is essentially zero operational overhead. EC2 launch type requires you to manage the EC2 fleet that's patching, scaling, monitoring the host and so on. For most modern applications, Fargate is the right default choice. Unless you have specific requirements that Fargate doesn't support or unless you have very high consistent utilization, that justifies the operational overhead. Go with Fargate. Now let's compare Fargate with Lambda since both our serverless compute and this comparison shows up always on the exam. Lambda is for functions short-lived code executions triggered by events. Maximum 15 minutes runtime. Grade for event driven workloads, APIs and data processing pipelines. Whereas Fargate is for containers that's long running application processes. There's no time limit. It's great for web servers, background workers, applications that need to run continuously. and workloads. that needs specific runtime environments or third-party libraries that don't fit Lambda's constraints. If you have a Python web server that needs to run 24/7 and handle requests, Fargate is typically right fit. If you have a function that runs when a file is uploaded to S3 and finishes in 30 seconds, Lambda is the right fit. On for a pulse check, a scenario. Your team is running a machine learning training job that takes two hours to complete. They want serverless compute with GPU support. To use Fargate or Lambda, let's pause and think. The answer is neither directly, but if you had to pick between them, Fargate would be closer. Lambda is out because of the 15 minute limit and no GPU requirement. Fargate doesn't natively support GPU, so for this specific use case, you had actually used something like SageMaker or EC2 with GPU instances. But for the long-running serverless container pattern, Fargate is the answer, so watch for these edge cases on the exam. A memory hook here, think of Lambda as a microwave, quick heat, small portions, and then done. Fargate, more like a slow cooker, runs for hours, there's more capacity, there's no time pressure, same serverless kitchen, different use cases. On to section 4, Amazon EKS Overview. Now let's talk about EKS Elastic Kubernetes Service. This is AWS's Managed Kubernetes offering. First, what is Kubernetes? Kubernetes often abbreviated KAS is the open source industry standard container orchestration platform. It was originally developed by Google, open source, and is now managed by the Cloud native computing foundation. Every major cloud provider has a Kubernetes service, it's the de facto standard for container orchestration in enterprises. EKS is AWS's Managed Kubernetes. AWS runs the Kubernetes control plan for you, the master nodes, the database, and API server. You just provide the worker nodes where your containers actually run. This dramatically simplifies operating Kubernetes on AWS. So when would you choose EKS over ECS? The main reason is Kubernetes standardization. If your organization uses Kubernetes elsewhere on premise, in other clouds or as a corporate standard, you want to use EKS. Your existing Kubernetes YAML files, tools, and workflows all work with EKS. You don't lock into AWS specific patterns. Another reason is the ecosystem. Kubernetes has a massive ecosystem of tools, operators, and third party integrations. Multi-cloud portability is another factor. Applications built on EKS can typically move to other Kubernetes services with minimal changes. The trade-off here is complexity. Kubernetes has a steeper learning curve than ECS. There is more to configure, more to understand, and more to go wrong. If a team doesn't have Kubernetes expertise, and you're all in on AWS, ECS is usually simpler. Now EKS has similar node type options to ECS. EKS Managed node groups. This is very easy to instances running as Kubernetes worker nodes. You choose the instance types, and AWS handles provisioning and lifecycle management. You still pay for the easy to instances even when idle. Then there is the self-managed nodes. You fully manage easy to instances yourself. You have EKS on Fargate. That's using Fargate profiles. You can run Kubernetes ports on Fargate. Same benefits as ECS on Fargate. That is, there is no infrastructure to manage here, and you pay only for what you use. This is increasingly popular. Under the hood, EKS on Fargate schedules your ports on Fargate compute rather than easy to nodes. From an application perspective, it's still Kubernetes. Yoriamel Manifest works the same way. One for a top spotlight. The exam loves ECS versus EKS questions. The key words matter here. Kubernetes or KS or OpenStandard or hybrid cloud portability. That's EKS. Simple AWS native container service or tight AWS integration or no Kubernetes expertise required. Think ECS. Don't overthink here. The key words tell you the answer. One for a memory hook. Think of ECS like taking Uber. It symbol works well in AWS, but you are using AWS system. EKS on the other hand is like driving your own car. There's more complexity, but works anywhere and gives you standard controls that transfer between roads. Now let's go on to the next section 5, Amazon ECR. Let's briefly cover ECR, which stands for elastic container registry. ECR is AWS's managed container image registry. You know how to push code to GitHub, right? ECR is where you push container images. It's like Docker Hub, but hosted in AWS with tight integration to ECS and EKS. You build a container image locally or in a CI/CD pipeline, then push it to ECR. When ECS or EKS needs to run your container, they'll pull the image from ECR. This keeps your container images secured, versioned and geographically close to where they will run. There are a few key features to remember here. Number one, private repositories. They are by default. ECR repositories are private to your AWS account. You can share access with other accounts using resource-based policies. Then there is public repositories. You can also create these public repositories using ECR public. It's useful generally for open-source projects. Then there is image scanning. ECR integrates with Amazon Inspector to automatically scan your images for vulnerabilities. When you push an image, Inspector analyzes it for known CVEs. Finding appears in your ECR console and can trigger alerts via even bridge. Then there is cross-region replication. You can configure ECR to automatically replicate images to other regions. It's useful for multi-region deployments where you want containers running close to the users. Then there is life cycle policies. Very similar to S3 life cycle policies. You can automatically delete old unused images to save storage costs here. For example, delete images older than 90 days that aren't tagged with the keyword protection. ECR uses IM for access control. Your ECS task or EKS pod needs an IM role with permissions to pull from the specific repository to remember that. On for a memory hook here, think of ECR as a container warehouse. You build your images, store them there and ECS or EKS grabs them when they need to run something like Amazon warehouses stocking products for delivery. Alright, now let's move on to the next section. Number 6 container versus lambda versus easy to decision. Let's tackle one of the most important decisions you will ever make as an AWS architect and once that's heavily tested on the exam. When do you use containers versus lambda versus easy to? Now, let me give you a clear decision framework. You want to use lambda when your workload is event driven and short running. These are for functions that complete in under 15 minutes. You don't need specific runtimes or heavy libraries here. You want to use zero infrastructure management. You want per invocation pricing. Use grade for API backends behind API gateway, even processing from S3 or SQS for schedule tasks and lightweight data transformations. On the other hand, you want to use containers that's ECS or EKS when your application needs to run continuously. Run time exceeds lambda's 15 minute limit. You need specific runtime environments or dependencies. You want portability across clouds or on premise. You have complex applications with multiple components communicating. You need long live processes. It's great for web servers, background workers, microservices and traditional applications being modernized. Finally, you want to use EC2 when you need full OS level control. You have a specific licensing requirements that require dedicated host or you need GPU or specialized hardware. You're running legacy applications that can't easily be contained right? You have specific compliance requirements that mandate infrastructure control. And remember, it's also good when you have consistently high utilization that justifies the operational overhead. So here's a mental model that helps. Think of these three services on Spectrum for most abstract to the most controlled. Lambda. This is where AWS handles everything except your function code. Containers on Fargate. This is where AWS handles everything except your container definitions. Containers on ECS easy to launch type. This is where AWS handles orchestration. You handle the EC2 host. Then you have the EC2 where AWS handles the hardware and hypervisor and you handle everything about. More abstraction here means less operational work, but less flexibility. More control means more operational work, but more flexibility. The right choice, it depends on the specific requirements. Right, on for a pulse check to try the scenario. Your company has a Python Django web application that currently runs on premise. They want to migrate this to AWS with minimal application changes and no need to manage service. The application runs 24/7 and handles user requests continuously. What's the best target service? The answer here is ECS with Fargate or ECS with Fargate. And here's why. Lambda is out because Django is a long running web application. It's not even driven. EC2 works but requires managing service. The requirement here specifically says no server management. So containers on the Fargate is the fit. ECS is simpler. EKS if a company wants Kubernetes standardization for other reasons. One for a trap spotlight. Remember that the exam sometimes give you scenarios where any of this could work, but only one is clearly the best. So watch for these keywords. If you see even driven plus short lived, then think Lambda. If you see long running plus web application, then think containers. if you see The full OS control plus specific hardware, then you know it's easy to. No server management narrows it down to Lambda or Fagate. On from memory hook here, think of three ways to eat meal. Think of Lambda as a food truck, it's quick, it's single dish and minimal effort. Think of containers as meal prep services, it's continuous, it's portable, and there's more variety. And think of easy to as your own kitchen, there's full control, there's more work you need to do, and there's unlimited options though. Mash the meal to the situation. Let's now move on to section number seven, exam traps and coaches. Let's cover the common container traps that catch people on the exam. Trapped number one, ECS versus EKS. Look for Kubernetes specific keywords, Kubernetes, KATS, Open standard, portable across clouds, well that's all EKS. AWS native, simple, tight integration, that points to ECS, don't overthink it. Not number two, Fagate versus EC2 launch type. If you see no server management, no infrastructure to manage, pay only for what you use, that stands for Fagate. If you see consistent high utilization, specific instances types need to SSH access to the host, then that stands for EC2 launch type. Trapped number three, Lambda versus Fagate for serverless containers. Remember, Lambda is 15 minutes maximum runtime and no true containers, it functions within a container runtime. Fagate runs actual containers with no time limit at all, for containerized workloads over 15 minutes, Fagate is the answer. Trapped number four, ECS task definition versus service. Task definitions are the blueprint, they define how to run containers. Services actually run the tasks and maintain the desired count. If a question asks about defining the container configuration, that's task definitions. If it asks about maintaining running count or replacing failed containers, that's services. On to Trapped five, I am for containers. ECS task can have their own I am rules, called task rules, that's separate by the way from the underlying EC2 instance rule. This is important for security, each container gets exactly the permissions it needs. On to Trapped number six, ECR image scanning. ECR integrates with Amazon Inspector for automatic vulnerability scanning of container images on push. If a question describes scanning containers for security issues, that's Inspector plus ECR. Trapped number seven, ECS with auto scaling. Remember there are two types of scaling for ECS, service auto scaling, that scaling the number of tasks and cluster auto scaling, that scaling the underlying EC2 fleet if using EC2 launch type. Target handles cluster scaling automatically. Trapped number eight, EKS control plane costs money. Unlike ECS, which has no control plane fee, EKS charges you for the Kubernetes control plane, that's about 73 dollars per month per cluster, plus you pay for the worker notes that's whether it's EC2 or Fargate. Remember, cost sensitive scenarios might favor ECS. Trapped number nine, ECS on Fargate networking. Net tasks always get their own ENI elastic network interface and their own private IP. This is called AWS VPC network mode. This affects security group configuration and IP address planning in your VPC. And finally Trapped number ten, LB integration with containers. Both ECS and EKS integrate natively with application load balancer. Target groups automatically update as containers start and stop. For network protocols beyond HTTP or HTTPS, use network load balancer. And finally let's cover section number eight exam quick tips. Let me give you the rapid fire summary to lock all of what we've learned in. Containers are lightweight packages that include your app and dependencies. They run consistently everywhere. ECS is AWS proprietary container orchestration. It's simple, it integrates well to AWS, there's no control plane cost. It's a good default for AWS only shops. EKS on the other hand is managed Kubernetes. It's open standard, it's portable, it's more complex. It costs about $73 per month control plane cost. It's good for Kubernetes standardization. Fargate is serverless compute for containers. There's no infrastructure management, it's paper use. It works well with both ECS and EKS and it's the default choice for most workloads. Easy to launch types give you full control over the underlying instances. There is more operational work, but it's potentially cheaper at high utilization. ECR stores your container images, it integrates with inspector for scanning, supports cross-region replication. And the decision framework to remember, if it's even driven, short-lived, no runtime constraints, think lambda. If it's long-running applications, you need specific runtime and it's portable, think containers on Fargate. If you need OS level control or specific hardware control, think easy to. If you need Kubernetes, think EKS, if it's AWS only simplicity, think easy as. If you need no server management, think Fargate or lambda. If you want full control over instances, think easy to launch type. All right, so that is for episode 90 on containers. We covered by containers matter, easy to fundamentals and it's two launch types, Fargate for serverless containers, EKS for Kubernetes on AWS and easier for container image storage. We then built a clear decision framework for choosing between lambda, containers and easy to and then we worked through 10 common exam traps. The big takeaway is this, containers are the middle ground between lambda simplicity and easy to full control. Fargate makes containers serverless, ECS keeps you AWS native, EKS gives you Kubernetes portability, match the service to the requirements and you'll handle the container questions on the exam with full conference. We have now completed 19 main episodes, your coverage of core AWS is really comprehensive now. We learned compute in all its forms, storage, databases, networking, serverless, messaging, content delivery, monitoring, disaster recovery and security. Adding containers today completes the how to run my application story. If this episode helped containers finally click for you, please do consider to leave a five star rating on this podcast and please do share with anyone studying for the exam. It genuinely helps this channel grow. So please do let me know what you've thought about the slightly shorter format. Was it easier to follow than the longer deep dives? Your feedback definitely shapes future episodes. Okay, so until next time, keep building, keep containerizing and I will see you in the next episode. This is Baloo signing off, bye.