Learn Cloud Computing - Cloud Security, Firewall & Web Application Firewall (WAF)

#Introduction

After episode 13, where we accelerated content delivery with a CDN and ensured domain names resolve correctly with cloud DNS, this time we cover the side that must never be left out once a service starts drawing public attention: security. An application that's fast and 99.99 percent available is still fragile if it can be broken into through one small gap.

In previous episodes, you were introduced to two layers of identity and network security: IAM for deciding who can access what, and VPC for logically separating workloads inside a private network. Episode 14 completes that foundation with the next three layers: firewalls at the network and instance level, WAF at the application level, and data encryption at the storage and transport level. All three are building blocks that can never be replaced by a perfect IAM policy.

#Main Discussion

#Defense in Depth: Why One Layer Isn't Enough

The first principle you must internalize is defense in depth — layered defense. The closest analogy is the airport procedure: there's ticket inspection, immigration, baggage X-ray, and a body scan before a passenger boards the plane. One layer can be bypassed, but four layers make the chance of detection far greater. The same goes for the cloud: no single component is perfect, so you stack them.

Layer by layer, from the outermost all the way to the data itself:

#Stateful vs Stateless Firewalls

Firewalls filter traffic based on rules. The most important distinction you must master is stateful vs stateless.

A stateful firewall tracks connection state. Once it allows a connection out of an instance, it automatically allows return traffic from the opposite direction without needing an explicit rule. It's like a building's receptionist who records everyone entering the lobby: they won't question people who just left the building, because it's already logged in the guest book.

A stateless firewall evaluates every packet independently without remembering connections. That means you must write two-way rules explicitly — for both incoming and outgoing packets. It's like a security guard at a turnstile asking every person their destination, over and over again, every time they pass.

#Security Group: Example Rules and CLI

On AWS, the Security Group (SG) is a virtual stateful firewall attached to an instance. By default, an SG denies all inbound traffic and allows all outbound traffic — you just write the inbound rules you genuinely need.

An example real need: a web instance may only receive HTTPS from the internet, and SSH only from the team's office IP. The rules look like this table:

These rules can be created via the console, but a tidier way is via the CLI or IaC (which you'll learn in episode 16). To add the SSH rule from the admin IP:

aws ec2 authorize-security-group-ingress \
  --group-id sg-0a1b2c3d4e5f67890 \
  --protocol tcp --port 22 \
  --cidr 203.0.113.5/32

When you run aws ec2 authorize-security-group-ingress with the --group-id of your SG, the new rule takes effect immediately without restarting the instance. Note that rule changes apply instantly, so make sure the rules are correct before executing them in a production environment.

#Web Application Firewall and DDoS Mitigation

Network firewalls filter by port and protocol — they don't understand the contents of an HTTP request. This is where WAF comes in: a firewall that works at the application layer (L7) and understands HTTP payloads.

The most dangerous application attacks are documented in the OWASP Top 10 — the list of the most common and damaging web application risks, including SQL Injection (SQLi), Cross-Site Scripting (XSS), and broken authentication. Modern WAFs provide managed rules for these attack families: suspicious requests are blocked before they reach the application, without changing the application code itself.

An example simple rule — limiting the login endpoint so it isn't flooded with requests from a single IP:

{
  "Name": "rate-limit-login",
  "Priority": 1,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 2000,
      "AggregateKeyType": "IP"
    }
  },
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "rate-limit-login"
  }
}

DDoS is a different category of attack: not a smart attack on a single request, but a flood of volume whose goal is to exhaust service capacity. WAF alone isn't enough against large-scale DDoS — you need volume absorption: a CDN in front (episode 13), auto-scaling, and dedicated mitigation services like AWS Shield, Cloud Armor, or Azure DDoS Protection.

#Data Encryption: At-Rest and In-Transit

The final layer that's often forgotten is the data itself. Firewalls can be breached, but encrypted data remains an unreadable pile of bytes to attackers. There are two situations to secure:

• At-rest — data stored on a disk, in a bucket, or in a database. The cloud encrypts by default with service-managed keys. For stricter control — for example, for compliance — use customer managed keys via KMS: you decide the rotation policy, permissions, and key lifetime. KMS works with the envelope encryption technique: a data key is encrypted by a master key, so you never manage one key per object individually.
• In-transit — data moving between browser, application, and database. Encrypted with SSL/TLS: the browser verifies the certificate, then all traffic is encrypted. The cloud provides managed certificate management (ACM, Google-managed certificates, Azure Key Vault), so certificate renewal is no longer a manual task.

#Comparing the Big 3 Security Services

All three major clouds offer services that are conceptually equivalent, just under different names:

Service selection should be based on the cloud where your workloads live, not the other way around — because the security concepts are identical; only the names and configuration methods differ. This ability to move between providers is your main selling point in the job market.

#Conclusion

In this episode 14 you built three complementary defense layers: firewalls — understanding the stateful/stateless difference, writing Security Group rules, and applying them via the CLI; WAF — protecting the application from OWASP Top 10 attacks and helping absorb DDoS together with CDN and mitigation services; and encryption — protecting data at rest with KMS and in transit with TLS. With all three, your workloads are now fast, available, and far harder to break into.

But a system that's secure while dark has no eyes watching it: who knows when instance CPU hits 95 percent, or when the login endpoint starts erroring repeatedly? The answer is in the next episode: Cloud Observability, Monitoring & Logging — the three pillars of metrics, logs, and traces that take your system from looking good to proven good.