Cloud security is not achieved by installing a single firewall or selecting a secure service. It is an architectural discipline in which identity, network boundaries, workloads, data flows, monitoring, resilience and governance are designed as an integrated system. A cloud environment must assume that failures will occur, credentials may be compromised, software may contain vulnerabilities and attackers may operate inside an apparently trusted network.
This chapter examines how to design a segmented and resilient cloud architecture. It focuses on secure landing zones, virtual networks, firewalls, private connectivity, API gateways, web application firewalls (WAFs), DNS security, micro-segmentation and defense in depth. The discussion applies principally to infrastructure and platform services, although the underlying principles are relevant across major cloud providers.
A central design principle is that security controls should be placed according to risk and data flow rather than according to an arbitrary network diagram. A public-facing web service, an internal application service and a database have different exposure, trust and monitoring requirements. Treating them as one flat network creates unnecessary blast radius.
Learning Objectives
By the end of this chapter, learners should be able to:
Explain the purpose and components of a secure cloud landing zone.
Design segmented virtual networks and controlled traffic paths.
Distinguish security groups, network firewalls, WAFs and API gateways.
Select suitable private connectivity options for hybrid and multi-cloud environments.
Apply DNS security, micro-segmentation and zero-trust principles.
Evaluate resilience, operational visibility and defense-in-depth controls.
Analyse an architecture and recommend risk-based improvements.
1. Architectural Foundations
1.1 Shared responsibility and architectural accountability
In a cloud environment, the provider generally secures the physical facilities, hardware, foundational networking and managed-service infrastructure. The customer remains responsible for configuration, identities, data, operating systems where applicable, network policies, application security and compliance obligations. The exact boundary varies by service model:
Service model
Provider commonly manages
Customer commonly manages
IaaS
Physical infrastructure and virtualization
Operating systems, network rules, applications and data
PaaS
Infrastructure, runtime and much of patching
Application code, identities, data and configuration
SaaS
Application platform and infrastructure
Users, access settings, data governance and integrations
A secure architecture therefore begins with an explicit responsibility matrix. “The provider secures the cloud” does not mean that a permissive storage policy, exposed management port or over-privileged identity is safe.
1.2 Security objectives
Network architecture should preserve four related objectives:
Confidentiality: only authorized subjects and services can access information.
Integrity: traffic, configurations and transactions cannot be changed without authorization.
Availability: services remain usable despite faults, attacks or demand variation.
Accountability: actions can be attributed through reliable logs and identity records.
These objectives may conflict. Deep inspection can improve detection but add latency; strict egress controls can reduce exfiltration risk but complicate operations. Professional design makes these trade-offs explicit.
1.3 Trust boundaries and attack surface
A trust boundary is a point at which assumptions about identity, control or exposure change. Examples include the boundary between the internet and a load balancer, between an application tier and a database, and between a corporate network and a cloud virtual network.
Attack surface includes public IP addresses, open ports, management interfaces, APIs, DNS records, remote-access paths, third-party integrations and administrative identities. A useful design question is: If this component is compromised, what can it reach, and what evidence will reveal the compromise?
2. Secure Cloud Landing Zones
A landing zone is a pre-engineered cloud foundation into which workloads can be deployed consistently. It is not merely a subscription, account or project. A mature landing zone combines organizational structure, identity, network topology, policy, logging, security services and operational processes.
2.1 Core components
A secure landing zone commonly includes:
Organization hierarchy: separate production, non-production, security, logging and shared-services environments.
Central identity: federation, multifactor authentication, privileged access management and role-based access control.
Policy guardrails: restrictions on locations, public exposure, encryption, approved services and administrative actions.
Central logging: immutable or access-controlled audit logs, network flow logs, DNS logs and security findings.
Network architecture: address planning, hub-and-spoke or transit design, controlled ingress and egress, and private service access.
Security tooling: key management, vulnerability management, security information and event management (SIEM), and incident response integration.
Automation: infrastructure as code, policy as code and continuous compliance testing.
The landing zone should be version-controlled and reproducible. Manual configuration creates drift: two environments that were intended to be identical gradually acquire different routes, firewall rules or logging settings.
2.2 Account and environment separation
Separate accounts, subscriptions or projects reduce blast radius and clarify ownership. Production should not share unrestricted administrative paths with development. A security or logging environment should be protected from ordinary workload administrators so that an attacker cannot erase evidence by compromising an application account.
Separation is not automatically secure. If all environments share a permissive transit route or a common administrator, the practical boundary may be weak. Logical separation must be reinforced by identity policy, network policy and monitoring.
2.3 Address planning
Private address ranges should be planned before deployment. Address overlap complicates peering, routing, VPNs and mergers. The plan should reserve space for future regions, acquired networks, containers and managed services. Subnet size must account for provider-reserved addresses, scaling, replacement instances and peak deployment requirements rather than current population alone.
3. Virtual Networks and Segmentation
A virtual network is a logically isolated network defined by address space, subnets, routes and security policies. A typical application architecture separates public ingress, application processing, data services and management functions.
Segmented cloud network architecture
Figure: Segmented cloud network architecture
Figure: A segmented application architecture with progressively restricted trust zones.
3.1 Subnets and route tables
Subnets create address-level zones, while route tables determine where packets are sent. A subnet being labelled “private” is insufficient: it is private only if routes and security controls prevent unsolicited internet access. A private workload may still require controlled outbound access through a NAT service or inspection firewall.
Routes should be explicit and minimal. Common patterns include:
Internet gateway only for genuinely public ingress or egress.
No direct route from a database subnet to the internet.
Central inspection for sensitive outbound traffic.
Separate management paths using a bastion, privileged access service or provider-managed session service.
Explicit routes between application zones and shared services.
3.2 Security groups and network ACLs
A security group or equivalent stateful workload firewall is usually attached to a network interface or service. It commonly evaluates connection state and permits traffic based on source, destination, port and protocol. Network ACLs or subnet firewalls operate at a broader boundary and may be stateless, requiring return traffic to be allowed separately.
A robust rule should identify a service or security group rather than rely on a broad address range where the platform permits it. For example, a database should allow the database port from the application tier, not from the entire virtual network. Administrative ports should be restricted to a controlled management source.
4. Firewalls and Defense in Depth
Defense in depth uses independent or partially independent controls so that failure of one control does not produce total compromise. A typical sequence is:
Identity and device verification.
DNS filtering and domain protection.
DDoS and edge protection.
Load balancing and WAF inspection.
Network firewall and routing controls.
Workload security groups.
Host and container controls.
Application authorization and data-layer controls.
Monitoring, detection and response.
The controls should not be treated as identical. A WAF understands HTTP semantics; a network firewall evaluates network connections; an API gateway manages API publication, authentication and quotas; a host firewall protects an operating system. Layering is effective when each layer addresses a different failure mode.
4.1 Network firewalls
A network firewall can enforce stateful rules, network address translation, domain filtering, intrusion prevention and centralized egress policy. It is valuable at hub boundaries and for traffic that must be inspected between environments. However, routing all traffic through a central firewall may introduce latency, throughput limits and a single failure domain. High-availability pairs, capacity planning and bypass analysis are necessary.
Rules should be ordered, documented and owned. Temporary exceptions require expiry dates. Logging should capture accepted and denied flows at a level that supports investigation without creating unmanageable cost.
4.2 WAF
A WAF protects HTTP and HTTPS applications against attacks such as common injection patterns, malicious request manipulation, protocol violations and automated abuse. Managed rule sets are useful but can generate false positives. Effective operation combines vendor rules, application-specific rules, rate limiting, bot controls and tuning based on observed legitimate traffic.
A WAF does not replace secure coding, authentication, authorization, patching or database controls. Encrypted traffic must terminate at a component capable of inspection, and certificate management must be carefully governed.
5. Private Connectivity and Hybrid Architecture
Private connectivity reduces exposure and can improve predictability, but “private” does not automatically mean trusted. A private circuit or tunnel still requires authentication, route filtering, segmentation and monitoring.
5.1 Connectivity options
Site-to-site VPN: encrypted tunnels over the public internet; comparatively rapid and flexible, but performance depends on internet conditions and device capacity.
Dedicated private connection: provider or carrier connectivity that avoids ordinary internet paths; useful for predictable throughput and regulatory requirements, but more expensive and slower to provision.
Private service endpoint: access to a managed cloud service through private addressing rather than a public endpoint.
Peering or transit hub: connects virtual networks; transit designs simplify large topologies but require careful route control.
Zero-trust remote access: grants authenticated users access to specific applications rather than placing devices broadly on the network.
5.2 Routing and failure considerations
Hybrid designs should document primary and backup paths, route advertisements, asymmetric routing risks, maximum transmission unit issues and failover behaviour. A backup VPN that has never been tested is not a dependable control. Connectivity health should be measured through synthetic transactions, not only interface status.
6. API Gateways and Service Exposure
An API gateway is a controlled front door for APIs. It can provide authentication integration, authorization enforcement, request validation, schema checks, throttling, quotas, version routing, transformation, caching and audit logging.
A secure API path typically includes:
TLS with managed certificate rotation.
Strong client and user authentication.
Authorization based on resource and action, not merely successful login.
Input validation and payload-size limits.
Rate limits appropriate to users and operations.
WAF and threat-detection integration.
Correlation identifiers and centrally searchable logs.
Backend isolation so that services are not directly exposed.
Rate limiting can be expressed conceptually as a maximum permitted request rate, but its implementation depends on a token-bucket or leaky-bucket policy, burst allowance, identity key and time window. A simple fixed-window limit can create boundary bursts and should not be assumed equivalent to a smooth traffic limit.
API gateways also create risks: a compromised gateway policy can expose many services, and excessive transformation can obscure the original request. Administrative access must therefore be tightly controlled and changes reviewed.
7. DNS Security
DNS is a control plane and an attack surface. A compromised DNS record can redirect users to a phishing site even when application servers are secure.
Important practices include:
Separate authoritative and recursive DNS responsibilities.
Use private hosted zones for internal names and control their association.
Restrict who can change records and require approval for sensitive zones.
Enable DNSSEC where supported and appropriate; it provides authenticity and integrity of DNS data, not confidentiality.
Monitor unusual query volumes, newly registered domains, algorithmically generated domains and requests for blocked destinations.
Use protective DNS filtering for malware, command-and-control and known phishing domains.
Prevent unauthorized zone transfers and expose only required records.
Establish low TTL values only where rapid change is genuinely required; very low TTLs increase resolver traffic and do not guarantee instantaneous global change.
DNS logs can help identify compromised hosts, but encrypted DNS and resolver architecture may reduce visibility. The organization should define where trusted resolution occurs and prevent workloads from bypassing approved resolvers.
8. Micro-Segmentation and Zero Trust
Traditional segmentation often divides networks into broad zones. Micro-segmentation applies policy at workload, identity, application or process level. It limits east-west movement after an attacker gains an initial foothold.
Zero trust is a security model based on continuous verification rather than implicit trust from network location. Its practical principles include:
Verify user, device, workload and requested resource.
Apply least privilege and minimize session scope.
Assume breach and limit blast radius.
Collect telemetry continuously.
Make policy dynamic when risk, device state or workload identity changes.
Micro-segmentation can be implemented through workload firewalls, identity-aware proxies, service meshes, labels or policy engines. A service mesh may provide mutual TLS and service authorization, but it adds operational complexity, certificate dependencies and possible performance overhead. It should not be adopted simply because it is fashionable.
A useful policy model is “who may call what, using which protocol, under which conditions?” Policies should be expressed in terms of application relationships, tested in observation mode and then enforced gradually. Overly broad emergency rules tend to become permanent; exception management is therefore essential.
9. Resilience, Availability and Recovery
Security architecture must continue operating during failures. Resilience includes redundant components, fault isolation, tested recovery and graceful degradation.
Key design practices include:
Deploy critical components across independent availability zones.
Avoid a single firewall, transit gateway, DNS resolver or identity dependency where feasible.
Use health checks that test real service function.
Separate control-plane and data-plane failure analysis.
Back up configurations, certificates, keys and policy definitions securely.
Test restoration and failover at realistic scale.
Define recovery time objective (RTO) and recovery point objective (RPO).
RTO is the targeted maximum time to restore a service after disruption. RPO is the targeted maximum tolerable age of recovered data. They are business requirements translated into technical design; they are not automatically guaranteed by multi-zone deployment.
A design that routes all traffic through one inspection appliance may be secure in normal operation but fragile under appliance failure. Conversely, bypassing inspection during failure may preserve availability while creating unacceptable security exposure. The correct answer depends on risk appetite and documented fail-safe or fail-secure requirements.
10. Observability and Security Operations
Network protection without evidence is difficult to validate. A minimum telemetry set may include:
Flow logs and firewall decisions.
Load balancer, WAF and API gateway logs.
DNS query and response metadata.
VPN, private-link and routing events.
Identity and administrative audit logs.
Workload, container and endpoint telemetry.
Configuration changes and policy violations.
Logs should be time-synchronized, protected against alteration, retained according to legal and operational requirements and connected to alerting. Detection engineering should focus on meaningful behaviours: unexpected administrative access, lateral movement, unusual egress, sudden DNS changes, repeated denied requests and deviations from known service relationships.
Metrics can also support capacity and risk decisions. For example, firewall utilization, dropped packets, WAF challenge rates, API error rates and route convergence time reveal whether a control is both effective and operationally healthy.
11. Worked Design Example
An online retailer operates a public web application, order-processing services and a customer database. Developers currently place all components in one virtual network with public addresses. Database access is allowed from the network address range, and administrators use a shared VPN account.
Analysis
The architecture has excessive lateral movement, weak accountability, unnecessary public exposure and a large blast radius. A stolen web-server credential could potentially reach the database. The shared VPN account prevents reliable attribution.
Recommended design
Establish separate production and non-production accounts under a governed organization.
Place the public load balancer and WAF in an ingress subnet.
Place application services in private subnets with no inbound internet route.
Place the database in isolated data subnets with no direct internet route.
Permit database traffic only from the application security group on the required database port.
Send controlled outbound traffic through a managed egress firewall and DNS filter.
Publish APIs through an API gateway with authentication, schema validation and rate limits.
Use private endpoints for managed database and storage services where available.
Replace the shared VPN account with federated identities, multifactor authentication and privileged, time-limited access.
Centralize flow, DNS, WAF, gateway and administrative logs in a protected logging account.
Deploy across multiple availability zones and test database recovery and network failover.
Outcome
The design reduces public exposure, restricts east-west communication, improves attribution and creates multiple detection opportunities. It does not eliminate risk: vulnerable application code, compromised identities or a malicious authorized user remain possible. Continuous patching, access review, application testing and incident response are still required.
12. Governance, Ethics and Regulatory Considerations
Network architecture may process personal, financial, health or employee information. Governance should address data residency, cross-border transfer, retention, lawful monitoring, segregation of duties and access to security logs. Privacy principles require collecting and retaining only information necessary for a legitimate purpose; extensive traffic inspection can itself create sensitive records.
Security teams should communicate monitoring transparently, protect analyst access and avoid using security data for unrelated employee surveillance. Automated threat scoring and AI-assisted detection can prioritize alerts, but models may generate false positives, encode bias or expose sensitive content to external services. Human review, data minimization, model governance and documented escalation remain necessary.
Regulatory frameworks differ by jurisdiction, but common expectations include least privilege, risk assessment, incident reporting, change control, evidence preservation and demonstrable testing. Compliance should be treated as a baseline rather than proof of security.
13. Challenges and Limitations
Cloud network security is difficult for several reasons:
Provider terminology and feature behaviour differ.
Managed services may hide infrastructure details.
Multi-cloud policy equivalence is difficult.
Central inspection can create bottlenecks and cost.
Excessive segmentation can impede delivery and encourage bypasses.
Dynamic IP addresses and autoscaling challenge address-based rules.
Encryption can reduce inspection visibility.
Legacy systems may not support modern identity-aware controls.
Security controls themselves require patching, permissions and monitoring.
Architects should prefer simple, testable policies over elaborate diagrams. Every rule should have a business owner, purpose, source, destination, protocol, review date and removal condition where possible.
14. Best-Practice Design Method
A repeatable design process is:
Identify business services, data classifications and regulatory constraints.
Map users, workloads, dependencies and trust boundaries.
Define failure scenarios and likely attack paths.
Plan accounts, address ranges, regions and environments.
Design the minimum required traffic flows.
Select controls by function: identity, routing, firewall, WAF, gateway, DNS and monitoring.
Automate deployment and policy validation.
Test positive paths, denied paths, failure modes and recovery.
Measure operational performance and detection quality.
Review architecture as applications, threats and provider services change.
Security architecture is an iterative process. Threat modelling, penetration testing, configuration assessment and incident lessons should feed back into design rather than occur only before initial launch.
Chapter Summary
Secure cloud architecture combines segmentation, identity, controlled connectivity, application-aware protection, resilience and observability. A landing zone establishes governed accounts, policies, logging, networking and automation. Virtual networks and subnets create useful boundaries, but routes and security rules determine whether those boundaries are real. Network firewalls control broader flows; security groups protect workloads; WAFs inspect web requests; API gateways govern API exposure; DNS security protects name resolution; and micro-segmentation limits east-west movement.
Defense in depth is effective when controls address different failure modes and are monitored for both security and availability. Private connectivity reduces exposure but still requires authentication and route control. Resilient designs remove single points of failure and test recovery. Finally, architecture must remain aligned with privacy, governance, regulatory and operational requirements. The goal is not a perfectly isolated network, but a manageable system in which compromise is difficult, limited, detectable and recoverable.
Key Terms
Landing zone: Governed cloud foundation for deploying workloads consistently.
Trust boundary: Point where assumptions about access or exposure change.
Virtual network: Logically isolated cloud network with address, route and security configuration.
Subnet: Smaller address range within a virtual network.
Route table: Rules determining the next destination for network traffic.
Network ACL: Subnet-level access control, often stateless.
Network firewall: Central control for inspecting and filtering network traffic.
WAF: Web application firewall that evaluates HTTP and HTTPS requests.
API gateway: Managed entry point that governs API authentication, validation and traffic.
Private endpoint: Private path from a network to a managed cloud service.
Micro-segmentation: Fine-grained policy separating workloads or service relationships.
Zero trust: Security model requiring continuous verification rather than implicit network trust.
Defense in depth: Use of multiple complementary security controls.
DNSSEC: Extension providing authenticity and integrity for DNS responses.
East-west traffic: Traffic between internal workloads.
North-south traffic: Traffic entering or leaving an environment.
RTO: Target maximum time to restore a service.
RPO: Target maximum tolerable age of recovered data.
Blast radius: Scope of systems affected by a compromise or failure.
Review Questions
Short Answer Questions
What is the purpose of a secure cloud landing zone?
How does a WAF differ from a network firewall?
Why should a database normally lack a direct internet route?
What does micro-segmentation attempt to limit?
Distinguish RTO from RPO.
Long Answer Questions
Explain how accounts, identity, policy, networking and logging combine to form a secure landing zone.
Compare security groups, network ACLs, network firewalls and WAFs, including their appropriate use cases.
Discuss the benefits and limitations of VPNs, dedicated private connections and private service endpoints.
Explain how API gateways and DNS security contribute to defense in depth.
Describe how resilience requirements can conflict with security requirements and how an architect should manage that conflict.
Analytical / Application Questions
A company permits all application servers to access all databases over any protocol. Analyse the risks and propose a least-privilege segmentation model.
During a firewall outage, operations proposes bypassing inspection permanently to preserve availability. Evaluate this proposal and recommend a resilient alternative.
A newly deployed service generates frequent DNS requests to previously unseen domains and sends large outbound transfers. Design an investigation and containment response using landing-zone controls, DNS security, flow logs and identity data.
Multiple Choice Questions with Answers
Question 1
Which component is primarily intended to provide a governed and repeatable foundation for cloud workloads?
A. Secure landing zone
B. Web application firewall
C. DNS resolver cache
D. Database index
Correct Answer: A. Secure landing zone
Question 2
Which control is most specifically designed to inspect HTTP request patterns such as injection attempts?
A. Route table
B. WAF
C. VPN tunnel
D. Network ACL
Correct Answer: B. WAF
Question 3
What is the strongest reason for allowing database traffic only from the application security group?
A. It increases public accessibility
B. It limits the database trust relationship to the required tier
C. It removes the need for authentication
D. It guarantees that application code is vulnerability-free
Correct Answer: B. It limits the database trust relationship to the required tier
Question 4
Which statement about DNSSEC is correct?
A. It encrypts all DNS queries
B. It provides authenticity and integrity for DNS data
C. It replaces application authorization
D. It prevents every form of phishing
Correct Answer: B. It provides authenticity and integrity for DNS data
Question 5
What is the principal security benefit of micro-segmentation?
A. It eliminates the need for logging
B. It limits east-west movement between workloads
C. It guarantees zero network latency
D. It makes all services publicly reachable
Correct Answer: B. It limits east-west movement between workloads
Question 6
Which technology is most directly associated with API schema validation, quotas and API version routing?
A. API gateway
B. Subnet route table
C. Disk snapshot
D. DNSSEC
Correct Answer: A. API gateway
Question 7
A private subnet is best described as a subnet that:
A. Has no addresses
B. Uses only IPv6
C. Lacks an unrestricted direct route to the internet
D. Automatically trusts every internal workload
Correct Answer: C. Lacks an unrestricted direct route to the internet
Question 8
Which practice most improves accountability for administrative access?
A. One shared VPN account
B. Permanent anonymous credentials
C. Federated individual identities with multifactor authentication
D. Disabling audit logs
Correct Answer: C. Federated individual identities with multifactor authentication
Question 9
RPO primarily specifies:
A. The maximum acceptable age of recovered data
B. The number of firewall rules
C. The maximum API request size
D. The time required to rotate a certificate
Correct Answer: A. The maximum acceptable age of recovered data
Question 10
Why can routing all cloud traffic through one central inspection appliance create a risk?
A. It prevents any form of encryption
B. It can become a bottleneck or single failure domain
C. It automatically disables identity controls
D. It makes DNSSEC impossible in every design
Correct Answer: B. It can become a bottleneck or single failure domain