Serverless computing is a cloud-computing approach in which developers build and operate applications without directly managing the servers that execute the workloads. The name is potentially misleading because servers still exist physically and software still executes on compute infrastructure; “serverless” means that server provisioning, capacity management and much of server operation are abstracted away from the application developer. AWS describes serverless principles as including no server management, pay-for-value services, continuous scaling and built-in fault tolerance.
Serverless applications commonly use managed services for compute, storage, databases, messaging, authentication and APIs, with functions or other workloads invoked in response to events. The provider handles the underlying machines, operating systems and scaling mechanisms, allowing developers to concentrate on application logic and service composition.
Function as a service, or FaaS, is one important form of serverless computing. A developer writes a function that performs a defined task and deploys it to a managed execution service. The function may be invoked by an HTTP request, queue message, object-storage event, scheduled event, database change or another trigger. The provider allocates compute resources to execute the function and releases or reuses those resources according to its implementation.
AWS Lambda is a prominent example, but serverless architecture is broader than FaaS. Managed databases, object storage, authentication systems, API gateways, queues, event buses and workflow services can all form parts of serverless applications. AWS's documentation describes serverless applications as combinations of specialised managed services connected through event-driven architectures.
Event-driven architecture is central to many serverless systems. Instead of maintaining a continuously running application process waiting for work, components can respond to events generated elsewhere in the system. An uploaded file can trigger processing; an HTTP request can invoke an API function; a queue message can initiate background processing; a scheduled event can launch a periodic task. Components are often loosely coupled through queues, event buses or notification services.
This can improve scalability and fault isolation because individual components can process workloads independently. It also introduces distributed-systems complexity, including asynchronous execution, retries, duplicate events, ordering issues, idempotency and eventual consistency. Serverless therefore reduces infrastructure management but does not eliminate architectural complexity. In many cases it moves complexity from server administration into application design and distributed-system behaviour.
Automatic scaling is a major characteristic of serverless computing. A provider can create additional execution capacity as invocation rates increase and reduce capacity when demand falls. This can make serverless particularly suitable for workloads with unpredictable or intermittent traffic. Traditional servers may remain provisioned even when idle, whereas serverless services can often charge according to invocations, execution time, requests, storage or other consumption metrics. Nevertheless, serverless pricing is not necessarily universally cheaper. High and sustained workloads can sometimes be more economical on continuously provisioned infrastructure, while excessive invocations, data transfer, managed-service usage or inefficient functions can generate significant costs. Serverless economics therefore depend on workload shape, execution duration, concurrency, architecture and provider pricing.
Serverless systems have characteristic performance behaviours. Some platforms may experience a delay when a new execution environment must be created, commonly referred to as a cold start. Runtime language, package size, initialisation work, memory configuration and platform implementation can influence cold-start behaviour. Providers have introduced features and architectures to reduce such latency, but the issue remains relevant to latency-sensitive workloads. Functions also commonly have limits involving execution duration, memory, concurrency, payload size and temporary storage. Developers must design around these constraints rather than assuming that a serverless function is equivalent to an unrestricted virtual machine. Long-running workloads, specialised operating-system requirements and persistent processes may be better suited to containers or conventional infrastructure.
Serverless security still requires substantial customer responsibility. Although the provider manages the underlying servers, developers remain responsible for application code, identities, permissions, secrets, data handling and service configuration. Fine-grained identity and access management is particularly important because a serverless application can contain many independent functions and managed services. Overly broad permissions can allow a compromised function to access resources unrelated to its purpose. Event sources also need validation and appropriate authorisation, while dependencies must be maintained against vulnerabilities. Infrastructure-as-code can define serverless resources reproducibly and allow configuration to be reviewed through version control. AWS explicitly identifies infrastructure as code as an important serverless concept because infrastructure can be defined in templates and provisioned automatically.
Serverless differs from PaaS and IaaS primarily in how much infrastructure lifecycle management is exposed to the customer. An IaaS customer normally manages virtual machines and their operating systems. A PaaS customer deploys applications to a managed platform while retaining a relatively persistent application environment. A serverless customer can often deploy individual functions or use fully managed services without provisioning servers or continuously managing application instances.
The categories can overlap because providers offer products that combine characteristics of PaaS, containers and serverless execution. “Serverless” therefore describes an operational model and architectural approach more than one universal technical implementation. A serverless application can still use non-serverless components where they are appropriate, and AWS explicitly notes that serverless does not work for every workload.
The development of serverless computing reflects a broader movement toward higher levels of abstraction in cloud computing. Virtual machines abstract physical servers; PaaS abstracts operating systems and runtimes; serverless further abstracts application execution and capacity management. Its advantages include reduced server administration, automatic scaling, rapid deployment, event-driven integration and potentially efficient consumption-based economics. Its limitations include platform-specific dependencies, execution constraints, distributed-system complexity, cold starts in some environments, observability challenges and potentially unpredictable costs.
Serverless is therefore best understood as a method of constructing applications from managed, automatically operated components rather than as computing without servers. The central engineering benefit is that infrastructure operation becomes less visible to the application team, allowing attention to shift towards application behaviour and business logic.
