AWS Edge, Network & Compute Security

#Edge Protection — CloudFront, WAF and Shield

#What is this?

The edge is where internet traffic first touches your application. CloudFront is AWS's content delivery network: hundreds of locations that cache content and terminate TLS close to users. AWS WAF (web application firewall) inspects HTTP requests and blocks bad ones. AWS Shield absorbs DDoS (distributed denial-of-service) floods. Together they let you stop attacks before they reach your servers.

#Why it matters

Most internet-facing attacks are either application-layer (SQL injection, credential stuffing, scraping) or volumetric (floods). Stopping them at the edge is cheaper and safer than stopping them at the origin, and the origin must be locked so attackers cannot simply go around the edge.

#How it works

Client ──► CloudFront edge ──► AWS WAF web ACL ──► (Shield absorbs floods) ──► Origin
              │                    │                                            │
              │ TLS, geo-restrict  │ rules evaluated in priority order:          │ ALB / S3 / API GW
              │ signed URLs        │ allow / block / count / CAPTCHA / challenge │ accepts traffic
              │                    │                                            │ ONLY from CloudFront

#AWS WAF building blocks

#AWS Shield

#Locking the origin

In practiceA WAF rate-based rule that limits login attempts per session cookie rather than per IP, starting in count mode:

{ "Name": "login-rate-limit", "Priority": 10,
  "Statement": { "RateBasedStatement": {
      "Limit": 20, "EvaluationWindowSec": 300,
      "AggregateKeyType": "CUSTOM_KEYS",
      "CustomKeys": [ { "Cookie": { "Name": "session", "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } ],
      "ScopeDownStatement": { "ByteMatchStatement": { "FieldToMatch": { "UriPath": {} }, "SearchString": "/login",
          "PositionalConstraint": "STARTS_WITH", "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } } },
  "Action": { "Count": {} },                                   ← switch to Block after reviewing the logs
  "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "login-rate" } }

📰

Real incident — HTTP/2 Rapid Reset (2023, CVE-2023-44487). Attackers abused a feature of HTTP/2 — opening and immediately cancelling streams — to generate record-breaking floods; Google reported a peak of 398 million requests per second. Providers mitigated at their edges within days. Application-layer DDoS now outsizes most origins, which is why mitigation has to happen at the edge.

📰

Real incident — Capital One (2019). A misconfigured web application firewall running on EC2 could be tricked into making requests on the attacker's behalf (SSRF). It fetched its own instance-metadata credentials, which had broad S3 access, and over 100 million records were copied. A security control at the edge became the way in, because of what it was allowed to reach.

🎯

On the job. Review WAF logs weekly for the top blocked and top counted rules; counted rules that would have blocked legitimate traffic tell you what to tune before switching to block.

#Security angle

• An edge with an open origin is decoration: always check whether the ALB or bucket is reachable directly.
• Start new WAF rules in count mode, review the logs, then switch to block; blocking blind causes outages.
• Rate limits per IP are weak against botnets and residential proxies; combine rate limits keyed on session or API key with fingerprinting and Bot Control.
• AWS Firewall Manager deploys WAF and Shield Advanced across every account in an organisation; see governance.

#Network Security Controls — Hybrid Links, Segmentation and Zero Trust

#What is this?

How traffic is allowed or blocked inside AWS and between AWS and your other networks: on-prem data centres, other clouds and remote users.

#Why it matters

Flat networks turn one compromised host into a compromised estate. Hybrid links are often the forgotten path: a VPN that trusts the whole on-prem range bypasses every cloud control.

#How it works

#Hybrid connectivity

#Zero-trust access — AWS Verified Access

Verified Access gives users access to internal applications without a VPN. Every request is evaluated against policy written in Cedar, using signals from an identity trust provider (IAM Identity Center or any OIDC provider) and optionally a device trust provider (device posture from an endpoint management or EDR tool). Access is per application, not per network, so a compromised laptop does not get a route to the whole VPC. Requests are logged for every decision.

#Segmentation

#Finding unintended access

In practiceThe security-group finding every cloud review turns up, and the fix:

$ aws ec2 describe-security-groups --filters Name=ip-permission.cidr,Values=0.0.0.0/0 \
    --query "SecurityGroups[].{id:GroupId,name:GroupName,ports:IpPermissions[].FromPort}"
[ { "id": "sg-0a1b", "name": "legacy-admin", "ports": [22, 3389] } ]    ← SSH and RDP open to the internet

📰

Real incident — Ivanti Connect Secure (2024). Two chained vulnerabilities (CVE-2023-46805 and CVE-2024-21887) in a widely used VPN appliance were exploited by a state-linked group before patches existed, and then by many others. US agencies ordered federal networks to disconnect the devices. The VPN that protects the network was the way into it — the core argument for per-application zero-trust access.

🎯

On the job. Inventory internet-facing appliances (VPN, firewall, file-transfer) and treat their vulnerabilities as emergency patches; they are among the most exploited initial-access points year after year.

#Security angle

• Security groups are stateful and allow-only; NACLs are stateless and support deny. Use NACLs for coarse subnet-level blocks, not as the main control.
• Watch for 0.0.0.0/0 on admin ports, VPC peering that makes two environments one network, and transit gateway route tables that connect everything to everything.
• Direct Connect is private, not secret: anyone on the path at the colocation facility sees cleartext unless you use MACsec or IPsec.

#Compute Security — Images, Patching, Access and Scanning

#What is this?

Keeping EC2 instances, containers and Lambda functions secure from build to run: start from a hardened image, patch continuously, give admins access without open SSH, and scan for known vulnerabilities.

#Why it matters

Unpatched, internet-reachable compute is still the most common initial access path. Long-lived SSH keys and bastion hosts are a credential-theft magnet.

#How it works

#Hardened images — EC2 Image Builder

Image Builder runs a pipeline: start from a base AMI or container image, apply components (install the CloudWatch and SSM agents, apply CIS or STIG hardening), run tests, scan with Inspector, then distribute the image to accounts and regions on a schedule. Teams launch only from approved, recently rebuilt images ("golden AMIs"); an SCP or Config rule can deny instances launched from anything else. See Linux hardening for what the hardening itself contains.

#Patching — Systems Manager Patch Manager

• Patch baselines define which patches are approved, for example "critical security updates auto-approved after 3 days."
• Patch policies (through Quick Setup) apply scanning and installation across an organisation on a schedule.
• Maintenance windows control when patching may reboot instances.
• Compliance results flow to Systems Manager and Security Hub; Inspector re-scans after patching for continuous validation.
• For immutable infrastructure, "patching" means rebuilding the image and replacing instances rather than patching in place.

#Admin access without SSH

Session Manager is the usual "most secure, least overhead" exam answer.

#Workload identity

Instance profiles, ECS task roles, Lambda execution roles and EKS IRSA or Pod Identity give each workload its own temporary credentials; see how compute gets credentials.

#Vulnerability scanning

#Generative-AI workloads

Treat a model endpoint like any other app plus the OWASP LLM Top 10: Amazon Bedrock Guardrails filter harmful content, block denied topics, redact PII (personally identifiable information) and detect prompt-injection attempts; IAM scopes which models and agents can be invoked; model invocation logging records prompts and responses; and agents get least-privilege tool permissions so a prompt injection cannot become a data breach.

In practiceWhat replacing SSH with Session Manager looks like for an admin, and what it leaves behind:

$ aws ssm start-session --target i-0abc123def
Starting session with SessionId: alice-0f1e2d3c4b
sh-5.2$ sudo systemctl restart nginx

# Later, in the session log bucket (s3://acme-ssm-logs/alice-0f1e2d3c4b.log):
sh-5.2$ sudo systemctl restart nginx                    ← every command, tied to an IAM identity

📰

Real incident — MOVEit Transfer (2023, CVE-2023-34362). The Cl0p group exploited a zero-day SQL injection in an internet-facing file-transfer product and stole data from over two thousand organisations, including governments, airlines and payroll providers, before most could patch. One unpatched internet-facing server per victim was enough. Scanning and fast patching of exposed compute is not optional.

🎯

On the job. Report patch compliance for internet-facing instances separately from everything else, and alert on any instance launched from an AMI older than your maximum image age.

#Security angle

• SSM access is powerful: ssm:StartSession on * is effectively root on every managed instance. Scope it by tag and log sessions.
• Golden images go stale; enforce a maximum image age.
• Scanning without ownership produces backlog, not security; route findings to the owning team with SLAs (service-level agreements) by severity.