Serverless

Serverless describes how infrastructure is operated, not the absence of servers. Physical and virtual servers still execute the workload, but the cloud provider manages their provisioning, maintenance, and replacement. Customers work with higher-level resources such as functions, container tasks, APIs, queues, and databases instead of administering individual hosts. The practical benefit is less infrastructure management, particularly for teams building applications with variable demand.

Serverless is broader than function as a service. Functions are one implementation, but managed container execution and services for messaging, storage, and workflow orchestration also apply the model. Conversely, running an application in a container does not automatically make it serverless. If the team must provision and patch the container hosts, it still manages server infrastructure.

AWS Lambda is appropriate for event-driven functions, such as processing an uploaded image, responding to an API request, or handling messages from a queue. AWS provisions execution environments and scales function execution within configured limits and service quotas. Each invocation has a maximum execution duration of 15 minutes, making Lambda unsuitable for a single uninterrupted job that must run longer. Functions can be packaged as container images, but they still follow Lambda's execution model rather than behaving like continuously running container services.

AWS Fargate is appropriate when an application should run as containers without managing the underlying compute instances. It supplies compute for Amazon ECS tasks and Amazon EKS pods. Examples include a continuously running web service, an existing containerized application, or a batch worker that needs longer execution than a function allows. Engineers still define container images, CPU and memory requirements, networking, permissions, and workload scaling. Fargate does not automatically determine how many application replicas are needed; scaling must be configured through the relevant orchestration mechanisms.

Consider an order-processing application. An API accepts an order and places a message on a managed queue. A Lambda function processes short tasks, while a Fargate task handles a lengthy document-generation job. A managed database stores order status. Durable state belongs in external storage because execution environments can be replaced, and local files should not be treated as durable shared storage. Where event delivery or retries can produce duplicates, handlers should be idempotent so repeated processing does not create duplicate charges or orders.

Serverless does not mean unlimited scaling, guaranteed zero idle cost, or automatic cost savings. Quotas, concurrency settings, database capacity, and downstream dependencies can restrict throughput. Some services can scale to zero, while continuously running containers and reserved execution capacity still incur charges. Compare total costs, including requests, execution time, provisioned resources, networking, logs, and supporting services. Steady, highly utilized workloads may be less expensive on other compute models.

The trade-offs include reduced host-level control, service-specific interfaces, startup latency, and more distributed troubleshooting. Teams must still secure application code, dependencies, identities, data, and configuration. They also need monitoring, retry policies, failure handling, and deployment controls. For exam scenarios, choose Lambda for short event-driven function execution and Fargate for container workloads that need managed compute without host administration; do not assume that every serverless option has the same scaling or billing behavior.