Separating HTTP and network protection

Skill and boundary

Application protection starts with the request type and the layer at which it can be inspected. A security group controls traffic to a front end or server using addresses, groups, and ports; it cannot parse an HTTP path or request body. AWS WAF evaluates HTTP(S) requests arriving at supported resources through a web ACL and its rules, so it can act on an injection pattern in a query string. AWS Shield adds DDoS protection with different tiers and capabilities. These controls complement each other but do not substitute for one another: blocking a malicious string in WAF does not make a database private, and closing a port in a security group cannot distinguish `/checkout` from `/health` on that same port.

Decision model

Draw the path from client to CloudFront or ALB, then to application service, then database. For each hop record protocol, port, source scope, and destination. At the HTTP edge identify the supported resource for a web ACL and the rule that can run in Count before Block while false positives are assessed. On the network path, permit only the needed port from front-end group to service and from service to database; do not open the database to the client. Record where headers and payload are visible and where they are not. A network-volume attack needs an availability analysis and Shield or architectural capacity decisions, not a text-matching WAF rule alone.

Worked case

Run a staged paper experiment. Define a representative attack request and a legitimate checkout request with a similar character. Write a precise WAF condition and a counter for each. Start in monitoring mode, compare sampled requests with completed transactions, and enable blocking only after the rule's false-positive effect is understood. Observe 4xx rate, latency, and completed bookings after a change. If investigation shows UDP traffic exhausting capacity instead of HTTP requests, switch to DDoS and network protection analysis; an HTTP rule cannot see those packets. If the service is also directly reachable from a public address, repair that bypass route. A WAF associated with the ALB does not automatically close another path to the origin.

The counterfactual matters. If the traffic consists of legitimate requests above application capacity, a malicious-string rule cannot solve the bottleneck; measure capacity and scaling, and consider a carefully evaluated rate policy. If the database accepts internet connections, a web ACL still cannot secure that connection, since database traffic does not traverse the HTTP inspection point. Maintain two distinct measurements: the fraction of edge requests matched by the rule, and the count of database connections accepted from sources other than the application, which should remain zero. A single improving graph is not proof that every access path is protected. The change record needs separate edge and origin tests. At the edge, send one attack-pattern request and a nearby legitimate one, recording web ACL decision and checkout completion. At the origin, try direct unauthorized service and database connections; they must fail even while the trial WAF rule is disabled. Verify that client-identity headers used by a rule come from a trusted proxy. A single request sample is not representative of every legitimate language and checkout field.

Exercise and product

Solution review