A developer writes a 40-line function that makes a thumbnail whenever someone uploads a photo. There is no server to patch and no firewall to configure, and the bill is a few dollars a month. There is also an execution role, copied from a tutorial, that lets the function read and delete every storage bucket in the account.
Newer cloud architectures don't remove risk; they move it somewhere else. On the CompTIA Security+ SY0-801 exam these models sit under objective 3.1, which expects you to compare the security implications of different architecture models. This lesson covers four of them: serverless computing, microservices, multicloud, and infrastructure as code (IaC), with what each changes for an attacker and for a defender.
Serverless moves the attack surface from servers to permissions and code
Serverless computing, in its most common form, function as a service (FaaS), lets you upload code and have the provider run it when an event triggers it. AWS Lambda and Azure Functions are the best-known examples. Servers still exist, but the provider runs them, and you typically pay per invocation and for the run time used.
Functions are event-driven. A trigger might be an HTTP request arriving through an API gateway, a file landing in a storage bucket, a message on a queue, a database change or a timer. Each invocation is short-lived: most finish in milliseconds or seconds, and Lambda caps a single run at 15 minutes. The execution environment is then reused for a later call or thrown away.
That model changes the security work in several ways:
- You no longer patch an operating system. The provider patches the hosts and the managed runtime, but you still own your code, its third-party libraries, and the move to a newer runtime version when the old one is retired.
- The function's identity becomes the blast radius. Every function runs with a role, and a code flaw gives the attacker exactly what that role allows.
- Every trigger is untrusted input. A file name, a queue message or an email subject can carry an injection payload just as a web form can, so functions must validate event data.
- Secrets placed in environment variables are readable by anyone who can view the function's configuration; a secrets manager is the safer home.
- Automatic scaling absorbs floods of requests, so a denial-of-service attack can become a "denial of wallet" in which the bill is the damage. Concurrency limits and budget alerts contain it.
- There is no host on which to install a traditional EDR agent, and short-lived environments leave little to examine after the fact. Logging and tracing must be turned on before an incident, because the logs are the evidence.
Here is the kind of policy statement, attached to a function's role, that turns a small bug into an account-wide breach:
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
}
A least-privilege version would allow only s3:GetObject and s3:PutObject on the one upload bucket. On the exam, when a serverless scenario asks for the best control, think permissions and code, not patching or host firewalls.
Microservices turn one application into many network conversations
A traditional monolithic application is one codebase deployed as a unit, where the cart, payment and inventory features call each other as functions inside one process. A microservices architecture splits those features into small, independently deployed services, each doing one job and often owning its own data store. The services talk over the network through APIs, typically HTTP/REST or gRPC, and through message queues. They usually run in containers, whose vulnerabilities are covered in the vulnerability types section.
The security benefits are real. A flaw in the product-recommendation service doesn't have to expose payments, because each service can have its own credentials and its own database permissions. Services can be patched, scaled and rolled back one at a time.
The costs are just as real. Calls that used to stay inside one process now cross the network, so there are many more APIs to protect. Traffic between services, called east-west traffic, often far exceeds the north-south traffic between users and the application. There are more components to inventory, patch and monitor, and a single user request may pass through ten services, so investigators need correlation IDs and distributed tracing to follow it.
North-south traffic usually enters through an API gateway, which authenticates users, enforces rate limits, validates input and terminates TLS. The gateway does nothing for the calls services make to each other once a request is inside.