Network and host controls in the cloud

Why this matters

This lesson assembles the defensive controls into a layered design, and it is the natural capstone for the security domain: the network constructs from objective 1.3 used as security controls, the hardening ideas from objective 4.3 applied to instances, and the identity work from objective 4.2 applied to administrative access.

The theme is defence in depth. No single control is sufficient, and the design question is what still holds when one fails. A security group is a good control; a security group as the only thing between the internet and a database is a bad design.

The other theme is that the cloud's best network controls are the ones that remove reachability entirely, rather than filtering it.

The lesson

Segmentation with subnets, security groups and network policy, in layers

Segmentation limits what a compromise can reach, and in a cloud it operates at several levels which should all be used.

Account or subscription separation. The coarsest and strongest boundary, because the platform enforces it absolutely. Separate production from non-production, and separate high-sensitivity workloads from the rest. Nothing crosses without explicit configuration, which also makes billing and quotas cleaner.

Virtual network and subnet separation. Public subnets hold only what must face the internet — load balancers, NAT gateways, bastions. Application tiers and data tiers sit in private subnets with no route out except through a NAT gateway, and ideally with private endpoints so they need none at all. The classic three-tier layout is still the right default.

Security groups as the fine-grained layer. The most useful cloud-specific technique is referencing one security group from another: the database group permits the application group, by identity rather than address. That survives scaling, re-addressing and rebuilds, and it expresses intent in a way an address range never does.

Network ACLs for coarse subnet-level rules and explicit denies, which security groups cannot express.

Network policy inside clusters, per objective 4.3, because a flat cluster network defeats all of the above for anything containerised.

Micro-segmentation is the direction all of this points: isolate down to the individual workload, allowing only the specific flows required. Combined with identity-based rules this approaches zero trust inside the network, where nothing is trusted merely for being adjacent.

The single most valuable habit: design egress as deliberately as ingress. Most estates control inbound carefully and allow all outbound, which is exactly the path used to download a second stage, reach a command channel, or exfiltrate data. Restricting egress to known destinations is high-value and more work, and it is what a mature design does.

Web application firewalls, DDoS protection and where each one sits

Three protections in front of an application, with different jobs.

Web application firewall. Inspects HTTP requests and blocks application-layer attacks — injection, cross-site scripting, path traversal — using managed rule sets plus your own. It sits at the edge, in front of the load balancer or in the CDN. Two things to know: run it in detection mode first and tune, or legitimate traffic will be blocked on day one; and it is compensating, not curative — it reduces exposure to a vulnerability without fixing it, which is the "mitigate" outcome from objective 4.1 and is a perfectly legitimate answer when a fix is not yet available.

DDoS protection. Absorbs volumetric attacks. Providers give baseline protection at the network layer automatically; enhanced tiers add application-layer detection, faster response and cost protection against the scaling bill an attack generates. Two design points: put the CDN in front, since it absorbs volume across a large distributed network; and hide the origin — an attacker who can reach your origin addresses directly can bypass the edge entirely, which is a reason for private origins and for restricting the origin to accept traffic only from the CDN.

CDN. Primarily performance, and a security control as a side effect: it terminates connections at the edge, absorbs volume, and keeps the origin out of reach.

Order, front to back: DNS → DDoS protection → CDN → WAF → load balancer → application. A scenario asking where to place a control is usually testing whether you know that the WAF belongs at the edge and the origin should not be directly reachable.

API gateways deserve a mention as the equivalent for APIs: authentication, rate limiting, request validation and throttling in one place, which is both a security and an availability control.

Host hardening, baselines and the image that starts compliant

Instances need hardening, and in a cloud the leverage is that it should be done once, in the image, rather than repeatedly on running machines.

A hardened baseline typically means: unnecessary services and packages removed, secure configuration applied from a recognised benchmark, host firewall configured, logging and the monitoring agent installed and shipping, SSH or RDP configured for key- or certificate-based access with password authentication disabled, automatic security updates where appropriate, and file integrity monitoring for sensitive systems.

Doing this in the image (objective 2.4) means every instance starts compliant, and compliance is verified by checking the image version rather than by scanning each machine and hoping.

Two properties follow from objective 3.1's immutability:

• Do not harden running instances by hand. The change is lost at the next replacement, and the fleet is inconsistent in the meantime.
• Rebuild the image to change the baseline, then roll the fleet. The baseline becomes a versioned artefact with a history.

Measure it: a compliance score against the benchmark, reported continuously by the posture tooling from objective 4.1, turns "are we hardened?" into a number with a trend. And keep images fresh on a schedule — an image pipeline that rebuilds weekly means most vulnerability remediation happens without anyone opening a ticket.

Endpoint detection on cloud workloads, and the agent's cost in an autoscaling group

Endpoint detection and response watches process execution, file changes, network connections and memory for malicious behaviour, and allows response — isolate, kill, collect evidence.

It is valuable on cloud workloads for the same reasons as anywhere, with cloud-specific considerations that are the examinable part:

• The agent must be in the image, or new instances are unprotected exactly when a scaling event brings them into service. An agent installed by hand is an agent that will be missing.
• It consumes resources, and across a large autoscaling fleet that overhead is multiplied and appears in the bill.
• Licensing is often per-endpoint, and an elastic fleet can produce a licence count nobody budgeted for — with short-lived instances consuming licences for a few minutes each.
• Ephemeral instances produce noisy inventories, with thousands of hosts appearing and disappearing. The tooling needs to handle that or the console becomes unusable.
• Containers need a different approach. A traditional endpoint agent inside every container is wasteful; container-aware runtime detection (objective 4.3) observes at the node or kernel level instead.

The decision is genuine: for immutable, short-lived, minimal workloads, runtime detection at the platform level plus strong network controls may be a better allocation than an agent in every image. For long-lived instances, especially those handling sensitive data, the agent earns its cost.

Bastions and just-in-time access to replace permanently open management ports

Administrative access is a control worth designing rather than inheriting, and the progression here is the clearest example in the course of the cloud replacing a network control with an identity one.

Never expose management ports to the internet. SSH and RDP open to the world are scanned continuously and are a standard entry point. This is one of the most common findings in any posture scan.

The options, weakest to strongest:

1. Bastion / jump host. One hardened, heavily monitored host in a public subnet; everything else accessible only from it. Traditional, well understood, and it is a host you must patch, harden and monitor — and a single point of both failure and compromise.
2. Managed bastion services. The provider's equivalent, with no host to maintain, integrated with identity and logging.
3. Agent-based session access. No inbound port at all: an agent on the instance establishes an outbound connection to the provider's service, and administrators connect through that service with cloud identity and full session logging. This is the strongest common answer — there is nothing listening to attack, access is authorised by IAM, sessions are recorded, and it works for instances in fully private subnets.
4. Zero-trust access services, evaluating identity and device posture per connection.

Layer just-in-time access on top (objective 4.2): nobody holds standing administrative access; elevation is requested, approved, time-boxed and logged. Combined with option 3 the result is that there is no open port, no standing privilege, and a recording of every session.

Two supporting controls: session recording for privileged access, which is both a deterrent and forensic evidence; and alerting on administrative sessions, since in a well-automated estate a human logging into a production instance should be unusual enough to be worth a notification. If it is not unusual, that is itself a finding — it means work is being done by hand that should be in code.

What to take into the exam

• Segment at account, network, subnet, security group and cluster policy levels. Reference security groups from each other rather than addresses.
• Control egress deliberately — it is the path for second-stage downloads and exfiltration.
• Order at the edge: DNS → DDoS → CDN → WAF → load balancer → application. Hide the origin, or the edge is bypassed. A WAF is compensating, not curative, and is tuned in detection mode first.
• Harden in the image, not on running instances, and verify by image version.
• The EDR agent must be baked into the image; expect per-endpoint licence and resource costs in an elastic fleet, and prefer container-aware runtime detection for containers.
• No management ports open to the internet. Prefer agent-based session access with no inbound port, plus just-in-time elevation and session recording.