Architecture Models: Cloud, Serverless, and IaC
Not sure you’re ready?
Take the ~3-minute readiness diagnostic and see where you stand.
The modern network is no longer defined by copper cables, blinking server racks, and locked data center doors. Instead, it is defined by logic. Infrastructure has become highly abstracted, transforming firewalls, routers, and servers into lines of code deployed across distributed cloud environments. For the security professional, this abstraction is a double-edged sword. It removes the burden of managing physical security and hardware lifecycle, but it dramatically increases the complexity of identity management, configuration oversight, and application security. Understanding cloud, serverless, and code-based architecture is not merely about learning new terminology; it is about grasping how the attack surface shifts when an entire data center can be spun up—and compromised—in milliseconds.
When you migrate workloads to the cloud, you are fundamentally entering a partnership with a cloud service provider (CSP) like AWS, Azure, or Google Cloud. This partnership is governed by the cloud shared responsibility model, a framework that delineates exactly who is responsible for securing what.
The baseline rule of this model is that the cloud provider manages physical infrastructure security. You no longer need to worry about badges, biometric locks, or HVAC systems for the server room. However, the software layer is where the boundaries shift depending on the service model you choose.
| Cloud Service Model | Your Security Responsibilities | The Provider's Responsibilities |
|---|---|---|
| Infrastructure as a Service (IaaS) | In an Infrastructure as a Service (IaaS) model, the customer is responsible for securing the operating system and installed applications. You configure the firewalls, patch the Windows/Linux OS, and secure the software stack. | Physical hardware, virtualization layer (hypervisor), physical network, and data center facilities. |
| Platform as a Service (PaaS) | You secure your application code, databases, and user access. | In a Platform as a Service (PaaS) model, the cloud provider manages the underlying operating system security, including OS patching and hypervisor configuration. |
| Software as a Service (SaaS) | In a Software as a Service (SaaS) model, the customer remains responsible for data governance and user access management. | Everything beneath the application layer, including the application itself, OS, physical infrastructure, and uptime. |
Crucial Concept: It is highly dangerous to assume the cloud provider handles everything. The cloud customer is always responsible for the security of corporate data regardless of the cloud service model. If a user with weak credentials downloads your entire proprietary database from a SaaS CRM application, the cloud provider will not be held at fault; the failure lies in your access management.
Where you place your infrastructure profoundly alters your security posture. A public cloud provisions infrastructure over the open internet for use by multiple tenants. Because you share the physical hardware with other organizations, you are relying entirely on the provider's logical isolation (the hypervisor) to keep your data segregated.
Conversely, a private cloud limits infrastructure access to a single organization. This can be hosted on-premises or by a third party, but the hardware is dedicated entirely to you. It offers ultimate control but strips away the cost-saving benefits of hyperscale cloud providers.
Most large organizations operate in reality somewhere in the middle. A hybrid cloud architecture combines on-premises infrastructure with public cloud resources. This allows a business to keep highly sensitive legacy databases in a private, on-prem data center while utilizing the public cloud for scalable web front-ends.
However, hybrid models introduce severe complexity for the security administrator. To prevent attackers from exploiting the seams between these environments, hybrid cloud environments require unified identity and access management policies across on-premises and cloud boundaries. A user's privileges must remain consistent whether they are accessing a local server or a cloud-hosted application.
To safely operate within a public cloud, administrators utilize a Virtual Private Cloud (VPC). A Virtual Private Cloud provides an isolated network environment within a public cloud infrastructure. This is your private slice of the public cloud, allowing you to establish subnets, define routing tables, and implement granular network access control lists (NACLs) as if you were wiring a physical network.
Historically, if an IT administrator needed a new web server, they would manually install an operating system, click through configuration menus, and physically type in firewall rules. This "click-ops" approach is prone to human error and nearly impossible to audit.
Enter Infrastructure as Code (IaC). Infrastructure as Code automates the provisioning of computing resources through machine-readable definition files (such as Terraform or AWS CloudFormation). Instead of clicking buttons, you write a script that declares exactly what your network should look like.
Because the infrastructure is just text, Infrastructure as Code enables security teams to version-control infrastructure deployments. You can use tools like Git to track exactly who changed a firewall rule, when they changed it, and why.
However, this automation scales your mistakes just as efficiently as it scales your successes. A misconfiguration in an Infrastructure as Code template will propagate vulnerabilities across all deployed instances. If you accidentally leave port 22 open to the world in a Terraform template, and you use that template to deploy 500 servers, you instantly have 500 critically vulnerable endpoints.
To mitigate this, security engineers rely on automated testing. Static analysis tools can scan Infrastructure as Code templates for security flaws before deployment. These tools analyze the code for overly permissive firewall rules or unencrypted storage buckets before the infrastructure is ever built. Furthermore, developers must avoid embedding plaintext credentials inside Infrastructure as Code configuration files. Hardcoding a database password in a template file pushes that password into your version control system, making it trivial for an attacker to discover.
The Rise of Immutable Infrastructure
One of the most powerful security paradigms enabled by IaC is immutability. Infrastructure as Code facilitates the creation of immutable infrastructure.
When a traditional server gets a malware infection, or just needs a software patch, an administrator logs in and modifies the live environment. Immutable infrastructure replaces existing servers rather than modifying running servers during updates. If a server needs a patch, you simply update the IaC template, destroy the old server, and instantly provision a brand-new, fully patched server. Because no one is allowed to SSH into or modify a running production server, any unauthorized change made by an attacker is immediately overwritten the next time the infrastructure refreshes.
To understand modern application security, you must understand how software engineering has evolved. In the past, applications were "monolithic"—a single massive block of code where the database logic, user interface, and authentication were tangled together.
Today, engineers favor a microservices architecture, which breaks a monolithic application into small, independent, and loosely coupled services. One service handles logging in, another handles the shopping cart, and a third handles processing credit cards.
Containerization is the industry standard packaging method for deploying microservices. Technologies like Docker package the microservice code along with the exact software libraries it needs to run, creating a standardized unit that works perfectly across any environment.
While this modularity is fantastic for developers, it causes a headache for network defenders. Because these pieces are separated, microservices communicate with each other over a network using Application Programming Interfaces (APIs).
The Security Trade-off: A microservices architecture expands the internal network attack surface compared to a monolithic application. In a monolith, functions communicate invisibly inside the server's memory. In a microservices architecture, every function is generating network traffic (often called East-West traffic) that an attacker can potentially intercept or manipulate if they breach the perimeter.
To secure this internal API chatter, we implement Mutual Transport Layer Security (mTLS). Standard TLS only authenticates the server to the client (like when you visit a banking website). Mutual Transport Layer Security provides encrypted and authenticated communication between individual microservices, ensuring that both the sending and receiving containers cryptographically prove their identity to one another before exchanging data.
Furthermore, managing external access to dozens of separate microservices is chaotic. To solve this, organizations deploy an API Gateway, which provides a centralized enforcement point for authentication and rate limiting in a microservices environment. It acts as the bouncer at the front door, verifying tokens and blocking denial-of-service attempts before the traffic is ever routed to the internal microservices.
The ultimate evolution of cloud abstraction is serverless computing. "Serverless" is, of course, a misnomer; there are massive server farms involved, but you never interact with them. Serverless computing abstracts the underlying server management and operating system from the application developer.
Function as a Service (FaaS) (like AWS Lambda or Azure Functions) is a primary implementation of serverless computing architectures. You simply write a snippet of code, upload it to the cloud provider, and the provider executes it whenever a specific event occurs (such as a user uploading an image).
Because you have zero access to the underlying virtual machine, in serverless computing, the cloud provider handles operating system patching and host security. This removes a massive operational burden. Consequently, the security focus in serverless computing centers on application code vulnerabilities and identity permissions. If your code contains an injection flaw, the cloud provider's perfectly patched OS won't save you.
Because FaaS functions are incredibly powerful and modular, serverless functions require strict least privilege execution roles to limit the impact of code exploitation. If a serverless function is designed merely to resize uploaded images, it must be explicitly denied the ability to query the customer database or create new administrative users.
Serverless functions execute in ephemeral, short-lived containers. The container spins up, runs the code for a few seconds (or milliseconds), and immediately destroys itself.
While excellent for cost savings, this poses a massive challenge for incident response. The ephemeral nature of serverless functions complicates traditional digital forensics and incident response. By the time a security operations center (SOC) detects an anomaly, the container—along with the malware, the memory contents, and the file system artifacts—has entirely vanished. Defenders must rely purely on centralized logging rather than traditional hard drive forensics.
While the cloud centralizes processing power, modern demands for ultra-low latency are pushing compute power back out to the physical world. Edge computing processes data closer to the source rather than sending data to a centralized cloud.
If you are operating a fleet of autonomous vehicles or a smart manufacturing plant, you cannot wait the 50 milliseconds it takes for data to travel to a public cloud data center and back; the processing must happen on the factory floor or inside the vehicle itself.
However, leaving the fortress of the cloud data center comes with a cost. Edge computing introduces physical security risks because processing nodes are deployed outside secure data centers. An edge node might sit in a vulnerable utility closet, on a street pole, or in a warehouse, requiring robust physical tampering protections, encrypted local drives, and secure boot mechanisms.
To defend these highly abstracted, distributed architectures, the cybersecurity industry has developed specific tooling platforms. As an IT administrator, you must understand the distinction between these three primary tools:
- Cloud Access Security Broker (CASB): Think of a CASB as the border guard for your users. A Cloud Access Security Broker enforces enterprise security policies between on-premises users and cloud applications. It sits between your employees and SaaS platforms (like Microsoft 365 or Salesforce), ensuring that unauthorized devices cannot access data and sensitive files are not inappropriately shared externally.
- Cloud Workload Protection Platform (CWPP): This is the internal security guard monitoring the actual servers and containers. A Cloud Workload Protection Platform provides threat detection and security monitoring specifically for cloud resources. A CWPP looks inside your virtual machines, Kubernetes clusters, and serverless containers to block malware, monitor for unauthorized registry changes, and stop runtime exploits.
- Cloud Security Posture Management (CSPM): This is the automated building inspector. Cloud Security Posture Management tools automatically identify and remediate misconfigurations in cloud environments. A CSPM continuously queries the cloud provider's APIs to ensure that no storage buckets have been accidentally made public, IAM policies aren't overly broad, and encryption is enabled across all services, ensuring the architecture complies with security baselines.