Choose How the Application Runs

Situation and constraints

Maple Tickets is launching a small event-booking application. The team has a traditional web service, one background worker packaged as a container—a deployable unit that carries application code and its dependencies—and a short function that creates thumbnails whenever an image arrives. Traffic is unpredictable because a popular event can cause a sudden burst.

The founders keep asking for “serverless” because it sounds inexpensive. One developer wants Kubernetes, a platform for scheduling and operating containers, because it is familiar from a previous employer. Another wants a single virtual server because it is easy to picture. None of those labels is a complete decision.

Maple must choose where each workload fits while understanding what the team will manage. The application also needs to scale when demand rises, distribute traffic across healthy capacity, and make infrastructure changes repeatable. Cloud Practitioner learners do not need to design a container platform; they need to recognize the compute categories and the operational responsibility each category leaves with the customer.

The decision to make

Maple should match the shape of each workload to the simplest suitable compute model.

• Use Amazon EC2 when the team needs virtual-server control, including operating-system access or software that expects a server.
• Use AWS Elastic Beanstalk when the team wants to deploy a supported web application while AWS provisions and manages much of the surrounding environment.
• Use Amazon ECS when the team wants AWS-native container orchestration, or Amazon EKS when the workload and organization specifically require Kubernetes.
• Use AWS Fargate with a supported container orchestrator when the team wants to run containers without managing the underlying server fleet.
• Use AWS Lambda for event-driven code that fits the function execution model without provisioning servers.

This is not a ranking from worst to best. More abstraction generally reduces infrastructure work, but it may also reduce low-level control or require the application to fit a more specific execution model.

A practical mental model

Imagine choosing a kitchen for a food business.

EC2 is a leased empty kitchen: Maple controls the equipment and setup but also maintains more of it. Elastic Beanstalk is a managed kitchen package: Maple brings a supported recipe and the service arranges much of the equipment, capacity, load balancing, and health monitoring. A container is a standardized food cart that packages an application and its dependencies. ECS or EKS coordinates many carts; Fargate supplies managed places for them to run. Lambda is an on-demand prep station that appears for a bounded task when an event occurs.

The analogy exposes two independent decisions that are often mixed up. Orchestration decides how containers are scheduled and managed; ECS and EKS address that problem. Compute capacity decides where containers execute; Fargate is one managed capacity option. In Kubernetes, this split is described as the control plane, the management layer that schedules and coordinates workloads, and the data plane, the worker capacity where application containers run. EKS manages the Kubernetes control plane, while Maple still defines its workloads and chooses how their worker capacity runs. Saying “Fargate instead of ECS” is usually the wrong comparison because ECS can run tasks on Fargate.

Compare the compute choices

Maple's web service could run on several of these choices. EC2 offers direct control. Elastic Beanstalk offers a simpler deployment path for a supported platform. A containerized version could run through ECS. EKS is justified only if Kubernetes is an actual requirement; familiarity alone may not justify its additional concepts and operating work.

The background container can use ECS with Fargate if the team wants container packaging without an EC2 fleet. The image thumbnail task is a natural Lambda candidate because it starts from an event, performs bounded work, and then stops. Lambda would be a poor fit for software that requires persistent server processes or unsupported execution characteristics.

Scaling, traffic, and repeatability

Choosing compute does not by itself make an application resilient. Automatic scaling adjusts capacity as demand changes. For EC2, an Auto Scaling group can add or remove instances according to policies and can replace unhealthy instances. Managed services such as Lambda scale their execution capacity within service behavior and configured limits. Scaling still needs appropriate limits, monitoring, and downstream capacity.

Elastic Load Balancing distributes incoming traffic across multiple healthy targets such as EC2 instances, IP addresses, or containers. A load balancer does not create capacity; an auto scaling mechanism does not distribute a user's request. The two capabilities often work together.

For deployment, Maple can click through the AWS Management Console for an experiment, but repeated environments benefit from infrastructure as code. AWS CloudFormation uses templates to describe AWS resources and provisions them as a stack. Repeatable templates reduce configuration drift and make review easier. Infrastructure as code does not remove the need to test changes or secure the resources it creates.

Recommended reasoning

Maple should first ask whether the workload is a full server, a container, or a bounded event-driven function. Then it should ask how much infrastructure the team needs to control and operate.

For the existing web service, Elastic Beanstalk may provide the simplest managed deployment if its platform fits. If the service requires operating-system control, EC2 is the clearer choice. If the team standardizes the service as a container, ECS is a straightforward orchestrator; EKS should be selected for a Kubernetes requirement, not because Kubernetes is fashionable.

For the background container, ECS on Fargate removes the need to manage container hosts. For thumbnail creation, Lambda aligns with a short event-triggered job. These choices can coexist inside one application.

Maple should define capacity behavior, place traffic behind an appropriate load balancer when multiple targets serve requests, and express durable infrastructure through CloudFormation. That is enough reasoning for this level. The learner is not expected to select Kubernetes node groups, Lambda concurrency formulas, or load-balancer listener rules.

Where the manifest services fit

Amazon EC2 provides resizable virtual servers. Use the shared Amazon EC2 reference for instance families, networking, and responsibility details.

Amazon ECS orchestrates containers using AWS-native concepts. Amazon EKS provides a managed Kubernetes control plane. AWS Fargate supplies serverless compute capacity for supported container workloads. The Amazon ECS and AWS Fargate reference and compute comparison explain these boundaries more deeply.

AWS Lambda runs code in response to events without Maple provisioning servers. It is serverless, but Maple still owns its code, permissions, configuration, and data handling.

AWS Elastic Beanstalk deploys supported applications and provisions resources such as EC2 capacity, load balancing, scaling, and health monitoring. It is a management layer, not a new kind of compute hardware. See the Elastic Beanstalk reference.

AWS CloudFormation provisions declared resources from templates. The CloudFormation reference covers stacks, change management, and operational considerations.

Common exam confusion

• ECS versus Fargate: ECS orchestrates containers; Fargate is managed compute on which supported container tasks can run.
• ECS versus EKS: Both manage containers. EKS is the Kubernetes choice; ECS uses AWS-native orchestration.
• Serverless versus no servers: AWS operates the underlying servers. The customer still owns workload configuration, code, data, and permissions.
• Elastic Beanstalk versus CloudFormation: Beanstalk is an application deployment service. CloudFormation is general infrastructure as code.
• Auto scaling versus load balancing: Scaling changes capacity. Load balancing distributes traffic across targets.
• EC2 versus managed compute: EC2 provides more operating-system control and therefore more customer management responsibility.
• Console versus infrastructure as code: The console is useful for interactive operations. IaC is useful for repeatable, reviewable provisioning.

Recall prompts

1. Which choice gives Maple direct virtual-server and guest operating-system control?
2. How are ECS, EKS, and Fargate related but different?
3. Why is the thumbnail task a stronger Lambda fit than a persistent server process?
4. What does Elastic Beanstalk simplify?
5. How do automatic scaling and load balancing solve different problems?
6. Why does CloudFormation help with repeatable environments?

Summary

Compute choice is a responsibility and workload-shape decision. EC2 provides virtual servers and control. Elastic Beanstalk simplifies deployment for supported web applications. ECS and EKS orchestrate containers, while Fargate can run containers without customer-managed hosts. Lambda runs event-driven functions without server provisioning.

Maple can use more than one model. It should choose the smallest suitable abstraction, add scaling and traffic distribution where the workload requires them, and use CloudFormation when provisioning must be repeatable. The exam signal is the business requirement, not the trendiest service name.

Official references: CLF-C02 Domain 3, AWS compute decision guide, AWS Elastic Beanstalk, AWS Lambda, and AWS CloudFormation.