AWS SCS-C03: Network Security Across VPC Boundaries

The architecture diagram says the application is private. Its instances run in private subnets, the database has no internet-facing endpoint, and security groups allow only a handful of ports. Yet the workload fetches an untrusted image from the internet, connects to multiple shared services, and can reach a corporate network through a transit connection. The word private describes only part of the design. AWS network security involves identifying the complete traffic path—entry, internal movement, egress, hybrid connectivity, and the edge services that stand in front of the application. That reasoning is part of SCS-C03 Infrastructure Security, not an optional networking detour.

The current blueprint calls for selecting edge protections, securing compute workloads, and designing or troubleshooting network controls. Security groups, network ACLs, AWS Network Firewall, AWS WAF, AWS Shield, VPN, Direct Connect, and segmentation all appear in plausible design scenarios. Correct answers depend on where enforcement occurs, what a mechanism can observe, and how traffic changes when the architecture evolves.

Draw actual flows before opening or closing a port

List each expected connection: public users to the edge, edge to application, application to data stores, workloads to AWS APIs, administrators to management paths, and systems to partner networks. Mark where addresses change and where encryption starts and ends. Separate north-south traffic crossing the environment boundary from east-west traffic between internal services. Two services may sit in private subnets while an overly broad security group permits lateral movement between them. Conversely, a restrictive subnet route might prevent a required patch repository from being reached even though all instance rules seem correct.

Use a concrete example. An API service must query a payment database, publish events to a queue, and retrieve credentials. Its network design might allow one database port to an identified destination security group, constrain application egress, and use private connectivity for supported AWS services. A problem statement that says “allow outbound HTTPS to everywhere” may be technically sufficient for availability but inadequate for risk control. Write down which endpoints are actually necessary and which network-level restrictions remain feasible without breaking service discovery or normal scaling.

Distinguish stateful security groups from stateless ACLs

Security groups operate at the network interface level and are stateful. Return traffic for permitted connections is generally allowed without a separately mirrored response rule. Network ACLs apply at subnet boundaries and are stateless; both directions and relevant ephemeral ports require deliberate consideration. Confusing these properties causes classic troubleshooting errors: a team tightens inbound NACL rules but forgets the path used by return traffic, or assumes a broad subnet ACL will undo a deny imposed by an instance security group. Route tables add another independent requirement: rules cannot permit traffic along a nonexistent route.

Never make the conclusion depend on a single mechanism when several controls intersect. If two EC2 services fail to communicate, check DNS resolution, destination endpoint, routes, security-group referencing, NACL direction, and the application listener before changing anything. A successful ping is not evidence that the intended TLS application flow works; some systems intentionally deny ICMP. Likewise, a permitted TCP connection does not establish application authentication. The security engineer needs to identify which layer owns the failure and which control can be adjusted without increasing unrelated exposure.

Place inspection at the boundary that actually matters

AWS Network Firewall can apply centrally managed stateful and stateless inspection policies, but it depends on route design and traffic being steered through the correct endpoints. A firewall policy in an inspection VPC does little for paths that bypass it. A centralized egress pattern should therefore define the covered VPCs, transit or routing constructs, failover behavior, DNS implications, and expected logging. Availability design matters: an inspection bottleneck can become an outage even when every rule is theoretically sound.

A firewall cannot make arbitrary encrypted application content visible simply because it sits in the path. Evaluate what metadata or protocol features each tool can inspect and whether decryption is supported, permitted, or operationally appropriate. The difference between a rule’s explicit denial and its default behavior remains useful when investigating apparently unexplained blocked flows. Good policies combine minimal necessary access with an understandable rule order, limited exceptions, and evidence that a prohibited connection is genuinely stopped.

Secure the application edge against the relevant attack

Web-facing services confront requests that have different threat characteristics from raw network flooding. AWS WAF can apply web request inspection and managed or custom rules at supported integration points. AWS Shield focuses on DDoS protections, with service-level distinctions between Standard and Advanced. Amazon CloudFront can reduce direct origin exposure when configured appropriately, but an unprotected public origin may remain reachable if teams forget to constrain it. In short, an application layer control and a network resilience control complement rather than replace each other.

Suppose a login endpoint experiences a burst of requests that resembles credential stuffing. The appropriate analysis may involve request rate, identity signals, business traffic patterns, and the consequences of blocking legitimate customers. A volumetric flood presents different capacity and mitigation concerns. The focused discussion of AWS Shield defenses belongs near this scenario because it clarifies why simply turning on a WAF rule is not an all-purpose availability solution. Practice explaining what evidence would cause you to select, adjust, or roll back an edge control.

Prefer private service paths when they reduce exposure

VPC endpoints can provide supported paths to AWS services without routing the relevant calls through a public internet gateway. Interface endpoints and gateway endpoints differ operationally, including their supported services, endpoint policies, routing or DNS behavior, and cost implications. PrivateLink can expose supported services privately across account boundaries. None of these mechanisms automatically authorizes the application to read every object or invoke every service API. Endpoint connectivity and IAM authorization are separate decisions that should reinforce each other.

For data movement, identify whether the compliance requirement is “must not traverse the public internet,” “must use encrypted transport,” “must remain within defined organizational networks,” or a combination. Those statements are not interchangeable. A network restriction might still allow an unauthorized identity to access sensitive data over the approved private path; a resource policy and logging design should address that risk. Use AWS Route 53 Resolver records and query logs appropriately when diagnosing name resolution. The broader behavior of Route 53 and DNS matters here because private DNS assumptions often explain failures blamed on firewalls.

Account for hybrid links and shared-network blast radius

AWS Site-to-Site VPN and Direct Connect serve different connectivity needs. Private connectivity should be evaluated in terms of encryption, resilience, availability, route propagation, and trust—rather than assumed to provide every security property by default. A dedicated connection does not eliminate the need for workload authorization or secure application protocols. Transit Gateway can simplify communication among many networks, but large shared route domains can also make unintended reachability easier. Inspect who controls attachments, which route tables are associated and propagated, and where segmentation is enforced.

A third-party support network illustrates the problem. It needs to access one maintenance endpoint for a limited period, not every private subnet in the organization. If that partner attaches through a shared routing topology, constrain the relevant routes and destination security policies, and add application-level authentication and an expiration process. The specialized AWS Advanced Networking – Specialty pathway goes further into connectivity engineering; SCS-C03 asks which access and inspection boundaries keep the topology from becoming an uncontrolled lateral-movement channel.

Harden compute paths alongside network paths

An application server with restrictive inbound rules can still be compromised by a vulnerable dependency, an overly privileged instance role, or unsafe administrative access. SCS-C03 includes hardened images, patching, vulnerability discovery, session management, and controls for container and serverless workloads. Where Systems Manager Session Manager meets administrative needs, it may reduce reliance on exposed management ports. The choice still depends on correct IAM permissions, logging, and organizational support for the required access method.

Containerized workloads introduce additional layers: image provenance, runtime privileges, cluster networking, secret retrieval, and lateral movement between services. A pod running with unnecessary privileges may reach paths that were never intended for its business function. Security groups and networking policy are useful, but they are not substitutes for application identity or deployment integrity. The difference between containers and hypervisors also affects which isolation claims are justified. Avoid explaining a compromised application entirely as a missing port rule when the attack may have crossed a separate trust boundary.

Troubleshoot with flow evidence and reversible tests

Build a controlled exercise with a load balancer, application instance, private data service, and one interface endpoint. Record the intended connections before deployment. Introduce one break at a time: a missing route, reversed NACL rule, mismatched endpoint DNS setting, overly broad security group, and a WAF block. For each, predict whether the symptom will be a connection timeout, a policy denial, a TLS problem, or an HTTP error. Then compare the prediction with available flow logs, service logs, configuration, and successful-request traces.

Finally, demonstrate negative assurance. Prove that a workload cannot reach a forbidden peer or bypass a designated inspection route. Positive connectivity tests show that the business application still works; negative tests show whether the intended containment boundary exists. That combination is the real design skill tested by SCS-C03. Secure architecture has to preserve allowed communication while making unintended communication difficult to initiate, easy to notice, and safe to correct during ordinary operations.