What's the difference between serverless and containers? Explained using AWS services, including their mechanisms and how to choose between them.

Since both serverless and container technologies aim to "abstract infrastructure management," the boundary between them tends to be blurred. However, choosing between AWS Lambda and Amazon ECS/EKS based on a vague impression can lead to operational rigidity and unexpected cost increases later on.

The key to shifting technology selection from "intuition" to "strategy" is to re-evaluate them not as opposing forces, but by measuring them using two criteria: "boundaries of management responsibility" and "implementation models." If you can correctly define these differences, you'll be able to confidently select the optimal platform for each use case.

This article will explain in detail the decision-making criteria required in the field, using Amazon Web Services (AWS) main services (AWS Lambda, Amazon ECS/EKS, AWS Fargate) as examples.

What is the difference between serverless and containers?

Both serverless and containers are technologies that "abstract the application execution environment," but their approaches are fundamentally different.

The key differences lie in two aspects: the "smallest unit of execution" and the "depth of management borne by the user." Serverless architecture uses "processing (functions)" in response to events as its unit, entrusting most of the management to the cloud vendor. In contrast, containers use the "entire execution environment" as their unit, allowing for flexible customization while maintaining consistency.

What is serverless?

Serverless computing is a system that executes programs triggered by specific events (such as requests or file uploads) without requiring users to be aware of the existence of a server. This model, exemplified by AWS Lambda, can be described as taking "operational abstraction" to the extreme.

The main design features are as follows:

• Event-driven execution
  • Resources are allocated only when needed, rather than being constantly running.
• Automated Auto Scaling
  • The platform instantly increases or decreases the execution environment depending on the number of requests.
• Minimizing the scope of management
  • AWS handles OS patching and runtime updates, allowing users to focus on "defining in the cloud" such as code, permissions (IAM), and network configuration.

What is a container?

A container is a technology that packages the application itself, along with the libraries and configuration files necessary for it to run, into a single "image." Its greatest feature is that it maximizes the "portability of the environment."

On the other hand, container technology itself is for creating "boxes (images)," and mechanisms to control them are essential for actual production operation.

• Environmental consistency
  • It is possible to run the application with the exact same configuration from the developer's PC to the production environment.
• The necessity of orchestration
  • As the number of containers increases, mechanisms (such as Amazon ECS or EKS) are needed to control deployment, scaling, health checks, and load balancing.
• Design freedom and responsibility
  • Fine-grained runtime tuning and control of resident processes are possible.
  • On the other hand, the scope of operational design, such as vulnerability management and resource allocation within containers, becomes broader than with serverless architectures.

Five comparison axes directly relevant to design decisions

Choosing between serverless and container architectures isn't about which model is superior in terms of functionality, but rather a puzzle of "which model best suits the system's characteristics." To eliminate inconsistencies in your decision, we'll organize both models from five practical perspectives.

Differences in Management Scope: "Ease of Operation" or "Depth of Control"?

The biggest difference lies in how much control you have over (or relinquish) of the three layers: infrastructure, OS, and runtime (execution environment).

• Serverless (e.g., AWS Lambda)
  • Users' concerns are concentrated on application code and trigger settings. OS patching and runtime maintenance are abstracted to AWS, but this means that fine-tuning at a lower level is not possible.
• Containers (e.g., Amazon ECS/EKS)
  • While the management burden of the OS itself can be reduced with tools like AWS Fargate, users remain responsible for the "environment itself" in which the application runs, including addressing vulnerabilities in container images, configuring middleware, and designing resource allocation.

Differences in Execution Models: Event-Driven vs. Resident Process

The prerequisites for "when and how" a process starts fundamentally influence the architecture design.

• Event-driven (serverless)
  • It is triggered by "activations" such as requests or file uploads. While it is robust against intermittent loads and sudden bursts, it has a time limit for processing (15 minutes for AWS Lambda) and requires a "stateless" design that does not maintain any state.
• Resident processes (containers)
  • It is suitable for applications that require processes to "keep running," such as API servers. It is ideal for processes that need to run for a long time, applications that need to retain data in memory, and systems with complex dependencies.

Scaling | Per Request or Per Task?

Both offer high scalability, but they differ in the "granularity" of scaling and their "design philosophy."

• Serverless
  • The execution environment proliferates in parallel according to the number of requests. While it has extremely high responsiveness to spikes, it requires a design that takes into account limitations on the number of concurrent executions and the overhead (cold start) during the initial startup.
• コ ン テ ナ
  • Scaling is achieved by increasing or decreasing the number of "tasks" or "pods." Since the speed of scaling depends on the container startup time, it is important to have a robust auto-scaling configuration and to design integration with load balancing (load balancers).

Cost Structure | "Request-Based" or "Resource Allocation"?

It's more practical to consider the difference not in terms of "which is cheaper," but in terms of "what you're paying for."

• Serverless
  • The charges are based on the "number of requests" and the "actual execution time." If there are zero requests, the cost will be close to zero, giving systems with long idle times a significant cost advantage.
• コ ン テ ナ
  • The basic cost is determined by "allocated resources (CPU/memory) × uptime." In systems with a constant load, it's easier to predict costs, and in many cases, the cost per request can be kept lower than with serverless architecture.

The concepts of customization and vendor lock-in

There is a trade-off between flexibility and operational efficiency.

• コ ン テ ナ
  • Because middleware and libraries can be freely combined, migrating existing assets and addressing complex requirements is easy. Using standard container technology makes it easier to ensure "portability," reducing over-reliance on specific cloud vendors.
• Serverless
  • By tightly coupling with AWS peripheral services, you can maximize the speed of development and operations. While this does involve vendor lock-in, it can be seen as a strategic choice to "focus on business logic" by abandoning infrastructure management.

Which should I choose: serverless or containers?

The choice between serverless (AWS Lambda) and containers (Amazon ECS/AWS Fargate) is not based on technical curiosity, but rather on the intersection of "workload characteristics" and "acceptable operational costs."

Cases where "agility" is paramount and serverless architecture should be prioritized.

If many of the following conditions apply to your situation, a serverless architecture centered around AWS Lambda will provide you with the greatest benefits in terms of both development speed and cost efficiency.

• Event-driven is the main focus.
  • Processes that are triggered by specific events, such as API requests, file uploads to S3, DynamoDB updates, and scheduled executions.
• Irregular load
  • Workloads that experience sudden spikes in requests, or those with periods of zero requests, such as late at night.
• Stateless short-time processing
  • The design ensures that processing is completed reliably within 15 minutes and does not require data to be stored in the execution environment.
• Minimizing operational resources
  • This is ideal when you want to focus on implementing business logic without spending time on OS and runtime patching or scaling design.

Cases where "continuity and control" are important and containers should be chosen.

Conversely, if the following requirements are included, container operation using Amazon ECS (AWS Fargate/Amazon EC2) or EKS will allow for more sustainable system maintenance in the long term.

• Always-on service
  • This applies to situations where there is a constant baseline load, such as with API servers or worker processes that are always listening for requests.
• Long-term heavy processing
  • Workloads that exceed the limitations of AWS Lambda, such as batch processing exceeding 15 minutes, machine learning inference, and video encoding.
• Advanced environment customization
  • When specific middleware, custom binaries, and complex library configurations are required, and OS-level environment control is essential.
• Migration of existing assets
  • This is for situations where you want to migrate containerized applications running on-premises or on another company's cloud to AWS without significantly changing the architecture.

Key architectural points that serve as criteria for judgment

If you're unsure which to choose, evaluate your workload using the following three filters.

You don't need to be limited to a simple choice between "serverless or containers." A scalable, phased approach, such as "starting with AWS Lambda and migrating to AWS Fargate when constraints (time, environment, cost efficiency) become an issue," is also a valid strategy in practice.

Mapping execution platforms in AWS

Applying these theoretical differences to AWS services clarifies the design choices. AWS offers execution platforms with distinct characteristics: "AWS Lambda," which is purely serverless; "Amazon ECS/EKS," which acts as the command center for container operations; and "AWS Fargate," which runs containers with a serverless feel.

AWS Lambda | The smallest unit of event-driven computing (FaaS)

AWS Lambda is a "Function as a Service (FaaS)" that directly links code to specific events (requests or state changes).

• No provisioning required
  • It provides a near-"no-ops" experience where you can deploy only the code and it will work without having to worry about infrastructure preparation or scaling design.
• Short-duration, high-density execution
  • Although there is a 15-minute time limit, its millisecond-by-millisecond billing and instant scaling make it incredibly efficient for API backends and asynchronous data processing.
• role
  • This is the optimal solution when you want to completely abstract away infrastructure management and dedicate all your resources to implementing business logic.

Amazon ECS / Amazon EKS | Container Control (Orchestrator)

Amazon ECS and EKS are "management systems" for running multiple containers in coordination. The key choice here is whether to "adapt to AWS's philosophy or to standard specifications."

• Amazon ECS
  • AWS's proprietary container management service. It offers deep integration with other AWS services (IAM, VPC, etc.), making it suitable for quickly setting up container environments while minimizing the learning curve.
• Amazon EX
  • We provide an industry-standard Kubernetes (K8s) environment. It's a choice for those who want to avoid vendor dependency and fully leverage the K8s ecosystem and tools, even if it means sacrificing operational complexity.

AWS Fargate | Freedom from Server Management

AWS Fargate is a serverless container execution engine that is used in conjunction with Amazon ECS and EKS.

• EC2 instance concealment
  • AWS takes over the heavy workload of building host machines (EC2) for running containers, applying patches, and scaling them.
• Container flexibility
  • This enables a "best of both worlds" operation, free from the execution time constraints of AWS Lambda and eliminating the burden of server management.
• Standing position
  • It resolves the dichotomy between "serverless" and "containers," and is key to bringing the level of operational abstraction closer to AWS Lambda while maintaining the flexibility of containers.

A configuration combining serverless and container architectures.

Serverless and containers don't have to be one or the other. Rather, the true appeal of AWS lies in a "hybrid configuration," where the optimal execution platform is deployed according to the system's role. Let's look at three typical patterns and how to choose between them.

Pattern 1: A "fully serverless" system that is resistant to spikes.

This is a classic event-driven architecture combining API Gateway, AWS Lambda, and DynamoDB.

• Main uses
  • Backend APIs for web/mobile applications, microservices for internal tools.
• Strength
  • Even with a surge in access, AWS Lambda functions are instantly executed in parallel, keeping idle costs to zero. By completely entrusting infrastructure operations to AWS, you can concentrate resources on developing your business logic.
• The turning point
  • This approach is suitable for processes that can be completed within 15 minutes and are scaled to match the number of database connections (Connections) in parallel with AWS Lambda.

Pattern 2: "Container Microservices" for stable operation

This configuration uses Amazon ECS on Fargate running behind an ALB (Application Load Balancer), with RDS as the database.

• Main uses
  • Web applications that maintain long-term connections, and core systems with complex business logic.
• Strength    
  • Because the process is always resident, there is no startup overhead for each request, ensuring a stable response. Since library and middleware versions can be fixed on an image-by-image basis, applications with complex dependencies can run reliably.
• The turning point
  • This option is chosen when there is a constant level of traffic, or when you want to optimize performance by precisely specifying memory and CPU resources.

Pattern 3: Strategic "Hybrid Type"

The configuration is based on the principle of "using the right tool for the job," with containers handling front-end reception and serverless architecture for back-end asynchronous processing.

• Main uses
  • A web service involving large-scale image and video conversion and heavy data aggregation.
• The essence of the design
  • Frontend APIs that require immediate responses to users are run stably on Amazon ECS, while time-consuming processes are passed via SQS (queues) to AWS Lambda or other AWS Fargate tasks.
• Strength
  • By separating resource-intensive processes from the main process, the overall system availability is improved. For example, it structurally prevents situations where a heavy process slows down the entire website.

Summary: Where to place the leadership in management

The choice between serverless and containers boils down to one thing: "Who will have the control over management?" rather than which technology is superior. Should you entrust operations to AWS with AWS Lambda, or control the environment yourself with Amazon ECS? There's no need to pit these two against each other. A hybrid perspective, where you work backward from the characteristics of your workload and your team structure to place the right tool in the right place, is the goal of strategic technology selection in practice.