ANS-C01: Securing AWS Network Access Across Accounts

A network can be perfectly routed and still expose the wrong application to the wrong audience. That is the awkward truth behind many AWS security incidents: connectivity is not authorization. A private address, an encrypted tunnel and a restrictive-sounding policy can each provide useful protection, yet none proves that a particular principal should reach a particular resource. Large AWS environments add another complication. The team that controls the network path may not own the account, endpoint, workload identity or data policy at the destination.

For candidates working toward AWS Certified Advanced Networking – Specialty (ANS-C01), the useful question is not simply which security feature to enable. It is how access decisions combine across identity, routing, name resolution, packet filtering and organizational controls. That distinction matters both on the exam and in the operational review that follows an incident.

Start with the principal, resource and permitted flow

Consider a shared analytics application hosted in an AWS account used by several business units. Two teams need its read-only interface, a third manages it, and a vendor should reach only a narrowly defined API. Saying that every consumer belongs to a trusted VPC obscures these different privileges. The access model must identify people, workloads and services separately; define what each can do; and record the paths on which those interactions should occur. Network segmentation supports the design, but it cannot replace those permissions.

A useful diagram therefore contains more than VPC boxes. Show the owning account, source principal, destination resource, expected protocol, authentication method, DNS resolution path and the actual routing attachment. Distinguish traffic that uses an interface endpoint from traffic that reaches a public service endpoint. Identify which teams can change route tables and which can alter resource policies. An engineer who can add a route is not necessarily authorized to change the application permissions; conflating those roles creates dangerous blind spots.

Risk reviews should include failure cases: a new account joins the organization, a shared subnet gains another workload, credentials are compromised, or an endpoint policy becomes broader during troubleshooting. If a network diagram says “only approved users” but the design relies entirely on an IP address range, it has left the most important requirement unanswered. The principles behind role-based access control help explain why privilege should follow responsibilities rather than mere network placement.

Separate IAM decisions from network enforcement

AWS Identity and Access Management establishes what an AWS principal may request from services and resources. Security groups, network ACLs, route tables, gateways and firewalls address different questions: whether packets can reach interfaces, which flows pass through boundaries and where traffic goes. Treating all of these as interchangeable is a common design error. A security group permitting TCP 443 does not grant permission to retrieve an object from Amazon S3; an IAM Allow decision does not create a route to a private endpoint.

Suppose a workload cannot call a service through an interface VPC endpoint. An effective investigation does not start by opening the security group to the internet. Verify the service hostname and endpoint DNS response. Confirm the caller’s authentication and the relevant identity and resource policies. Review the endpoint policy, then inspect the network route, inbound and outbound filtering, and any centralized inspection layer. Test one hypothesis at a time while collecting evidence about the request and path. This ordering helps avoid a broad temporary permission that later becomes permanent.

The subtle point is that access frequently depends on several independent Allow conditions and the absence of an explicit Deny. An endpoint policy provides another control surface, but it does not replace identity or resource policies. For an exam scenario, identify which layer is actually failing before selecting a remedy. For a production design, assign change ownership and auditability to each layer so that future engineers can reconstruct why a request succeeded.

Design cross-account sharing without accidental trust expansion

AWS Organizations and AWS Resource Access Manager make multi-account networking practical, but the ability to share infrastructure is not equivalent to permission to consume every workload behind it. A shared Transit Gateway gives accounts a managed connectivity attachment; route propagation and association decisions still determine reachable networks. A VPC shared across accounts introduces its own responsibility boundaries between the VPC owner and participant accounts. These designs solve administration problems when their ownership rules are explicit.

Imagine a platform account providing inspection and DNS services to several application accounts. The organization wants standard connectivity without allowing production workloads to reach development databases. A central transit fabric can support segmentation through carefully separated route tables and attachments. The policy should distinguish traffic sent to shared services from traffic allowed between spokes. Make the default route and any route propagation rules visible in the review, because an innocuous new attachment can change effective reachability.

Overlapping CIDR blocks require additional care. You cannot repair conflicting address spaces by assuming all prefixes will be routed correctly. Sometimes a service-level connection using PrivateLink reduces exposure and avoids the need for broad network routing. In other cases, renumbering or narrowly scoped translation is a better long-term answer. The right choice follows actual application traffic, operational cost and tenant isolation. Understand CIDR addressing before assessing whether a proposed network map is feasible.

Protect private services without confusing private with safe

Private endpoints are valuable because they restrict the connectivity pattern through which a service can be reached. Yet a private path can still carry an unauthorized request, and internal DNS can still direct a client to an unintended endpoint. Design authorization at the resource or application layer, then use private connectivity to reduce exposure and control ingress. For a consumer-facing service, verify whether the application truly needs broad access or a tightly scoped service endpoint.

When selecting between VPC peering, Transit Gateway and PrivateLink, ask how much of the destination should be visible. Peering and transit routing create network reachability between address spaces, subject to routes and filters. PrivateLink generally presents a service through endpoint interfaces without establishing general routing access to the provider VPC. That difference is decisive when a central security service or partner API should be callable but no other provider resources should be reachable.

DNS must be designed as part of this boundary. A private hosted zone associated with one set of VPCs may not resolve as intended in another. Split-horizon DNS, Resolver rules and conditional forwarding become critical in hybrid environments. Troubleshooting only the route table when a name resolves to the wrong address wastes time and can lead to dangerous bypasses. Record the expected resolution path and test from each relevant source. Treat private connectivity as one layer of defense, not a declaration that every internal caller is trustworthy.

Put inspection where the routes actually send traffic

Centralized inspection is often proposed as a security improvement, but it works only if the routing design ensures relevant flows traverse the enforcement point. Symmetric paths matter for stateful appliances. If traffic takes one route outbound and another on return, sessions can fail unpredictably even when the individual controls look correct. In multi-AZ or multi-Region architectures, availability requirements further affect where inspection capacity belongs.

AWS Network Firewall, gateway-attached appliances and AWS WAF address different traffic types and operating models. WAF is appropriate for specific HTTP(S) application-layer protections; it is not a general substitute for routing and network-layer inspection. Network Firewall can apply centrally managed filtering where traffic is directed through it. An appliance-based pattern may support specialized policy requirements, but it introduces lifecycle, scaling and failure-domain responsibilities. Choose according to real traffic and compliance requirements, not a vague instruction to “add a firewall.”

For reviewers, the important evidence is the actual packet path: source subnet, next-hop target, transit attachment, inspection waypoint, destination and return route. Pair that path with policy intent and exception ownership. A detailed explanation of network access control lists is useful when deciding where stateless filters help, but do not confuse subnet NACL behavior with stateful security-group behavior. Each adds a different operational burden.

Build network evidence into the design

A policy that cannot be tested or audited is difficult to defend after an outage or security event. Network teams should define expected flow records, metrics, routing change records and access logs before rollout. VPC Flow Logs help investigate traffic at network interfaces but do not provide the complete application authorization outcome. CloudTrail records many control-plane API activities, while service logs and identity logs provide other necessary context. No single log source can tell the full story.

Set up questions before looking at a dashboard. Should a source account be able to contact the API? Did the route change after a new attachment was created? Is the destination rejecting an authenticated request or is the TCP handshake failing? Has DNS returned a public rather than intended private address? Select evidence accordingly. Reachability Analyzer can examine supported configuration paths, while traffic captures and endpoint logs may be required for runtime behavior and application failures.

Observability must also respect data sensitivity. Capturing every packet can reveal application payloads, while leaving no metadata makes incident reconstruction impossible. Define retention, permissions, filtering and investigative procedures. Include a known-good path test in the change pipeline so engineers can detect an unintended exposure or routing regression before it affects users. When a failure occurs, evidence-driven narrowing is faster and safer than temporarily allowing all traffic.

Read exam scenarios as layered-control problems

ANS-C01 spans network design, implementation, management and network security, compliance and governance. The security domain is not a separate island; it depends on DNS, routing, shared services and multi-account design choices. Practice drawing a boundary diagram for each scenario. Mark identity controls, reachability controls, inspection controls and logging. Then ask what fails if any one control is removed.

One case might describe an AWS workload requiring private access to a service owned by another team, while its broader VPC must stay unreachable. That points toward service-scoped connectivity, carefully configured DNS and appropriate policies, not automatic transitive peering. Another may describe a routed path that works until stateful inspection is added; investigate asymmetric routing rather than assuming the IAM role is wrong. The ability to separate cause from symptom makes advanced networking judgment useful beyond the test.

Candidates who also study AWS security specialization will recognize overlapping principles of least privilege and evidence collection. The networking emphasis, however, is on mapping controls to concrete packet paths and operational boundaries. A good network security design is one whose authorization, connectivity and observability can each be explained without relying on the others as a substitute.