Amazon SCS-C02: Networking & VPC Security — Study Guide

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Part of the AWS Security Specialty SCS-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

VPC Endpoints and Endpoint Policies

VPC endpoints keep traffic to AWS services on the AWS network, bypassing the public internet, NAT gateways, and internet gateways. There are two structurally different kinds, and confusing them is one of the most common design errors.

Gateway endpoints exist only for Amazon S3 and DynamoDB. They are route-table entries — you associate the endpoint with route tables, and traffic destined for the service’s prefix list (for example pl-63a5400a for S3 in us-east-1) is silently rerouted through the endpoint. They cost nothing and cannot be reached from outside the VPC they are attached to.

Interface endpoints (powered by AWS PrivateLink) are ENIs with private IP addresses placed into your subnets. They are required for every service that is not S3 or DynamoDB — Secrets Manager, KMS, STS, SSM, CloudWatch Logs, ECR API/DKR, and hundreds of others. If a private-subnet EC2 instance with no NAT gateway needs to GetSecretValue from Secrets Manager, a gateway endpoint will not help; you must create an com.amazonaws.<region>.secretsmanager interface endpoint and enable Private DNS so the standard service hostname resolves to the endpoint’s private IP.

Endpoint policies restrict what can be done through the endpoint, independent of IAM policies on the caller. The two most important condition keys for preventing data exfiltration are aws:PrincipalOrgID (the identity making the call must belong to your Organization) and aws:ResourceOrgID (the S3 bucket, KMS key, etc. being touched must belong to your Organization). Applying both closes the classic exfiltration path where a compromised instance with legitimate S3 permissions writes to an attacker-controlled bucket outside your org — the credentials still work against S3, but the endpoint refuses to forward the request.

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "o-abc123",
        "aws:ResourceOrgID":  "o-abc123"
      }
    }
  }]
}

The default endpoint policy is fully permissive ("Action":"*" on "Resource":"*"), which is why a subnet with only a gateway endpoint and least-privilege IAM can still be abused for exfiltration unless you tighten the endpoint policy itself.

Hybrid Connectivity: VPN and Direct Connect

Site-to-Site VPN establishes two IPsec tunnels between a virtual private gateway (or Transit Gateway) and a customer gateway device. It is fast to provision, encrypted by default, and traverses the public internet — so throughput and latency depend on your ISP path.

AWS Direct Connect provisions a dedicated physical circuit through a Direct Connect location. It provides predictable low latency and high, consistent bandwidth (1/10/100 Gbps), which matters for chatty on-premises database traffic. Direct Connect is not encrypted at layer 3 by itself; the frames run on private fiber. For workloads that require both low latency and IPsec, the canonical answer is Direct Connect plus a Site-to-Site VPN running over a public VIF (or a Transit Gateway with MACsec on newer DX ports). VPN alone is also the recommended encrypted backup for a primary Direct Connect link, giving resilience if the circuit fails.

• Direct Connect only: low latency, private, but unencrypted at the IP layer.
• VPN only: encrypted, quick to deploy, but internet-path latency and jitter.
• Direct Connect + VPN: low latency and IPsec encryption; also the standard HA pattern.

Security Groups, NACLs, DHCP, and Source/Dest Checks

Security groups are stateful: if you allow an inbound request, the response is automatically allowed out. They only support allow rules and are evaluated per ENI.

Network ACLs are stateless and operate at the subnet boundary. Every flow requires two rules — one for the initial direction and one for the return traffic on the ephemeral port range (Linux typically 32768–60999, Windows 49152–65535, and NLBs/ELBs use 1024–65535). A NACL that permits inbound TCP 443 but forgets outbound TCP 1024–65535 will silently break TLS. ICMP is not TCP/UDP: return “echo reply” packets must be permitted explicitly, and Path MTU Discovery relies on ICMP type 3 code 4, which is easy to inadvertently drop. NACL rules are also evaluated in numeric order, first-match wins, with an implicit deny at the end.

DHCP option sets control what a VPC hands to instances at boot: domain-name-servers, domain-name, NTP servers, NetBIOS. Replacing the default AmazonProvidedDNS with a custom on-premises resolver can be legitimate, but it has real security consequences. Services like GuardDuty derive DNS-based findings (for example the “cryptocurrency” and “C&C domain” detections) from queries that traverse the Route 53 Resolver. Once you point instances at a third-party DNS server, GuardDuty stops seeing the queries and those finding types disappear — an easy way to accidentally blind detection.

Source/destination checking is an ENI attribute that drops any packet whose source or destination IP does not match the ENI. That default is correct for ordinary instances but breaks any appliance whose job is to forward traffic — NAT instances, virtual firewalls (Palo Alto, Fortinet, Check Point), transit routers, VPN concentrators. For those ENIs, disable the check:

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --no-source-dest-check

VPC Peering, RAM-Shared VPCs, and NAT Design

VPC peering is a one-to-one, non-transitive layer-3 link. If A peers with B and B peers with C, A cannot reach C — you must peer A–C directly or use a Transit Gateway. Route tables on both sides must contain routes to the peer CIDR, and security groups can reference peer security-group IDs only within a Region.

Shared VPCs via AWS Resource Access Manager (RAM) let a networking account own a VPC and share individual subnets with participant accounts. Participants launch resources into shared subnets but cannot modify the VPC, route tables, or endpoints — the owner keeps control of connectivity policy. This is often cheaper and simpler than peering many VPCs.

For outbound internet from private subnets, deploy a NAT gateway per Availability Zone and route each private subnet to the NAT in its own AZ. A single NAT gateway is a cross-AZ dependency and a scale/availability bottleneck. When your workload calls a third party that IP-allow-lists your egress (a payment processor, for example), the NAT gateway’s Elastic IP is what you register, and because instances behind an Auto Scaling group all egress through that fixed EIP the source IP does not change as the group scales. Placing the EC2 instances and the RDS database in private subnets and terminating only HTTP/HTTPS on the ALB completes the pattern.

Route 53 Resolver: Forwarding and Query Logging

The Route 53 Resolver (the .2 address in every VPC) is the pivot for hybrid DNS. Outbound resolver endpoints forward specified domain names from AWS to on-premises DNS servers via conditional forwarding rules — used, for example, so that corp.example.internal resolves against your Active Directory. Inbound resolver endpoints do the reverse, giving on-premises hosts a private IP in your VPC they can query to resolve *.eu-west-1.compute.internal and Private Hosted Zones.

Resolver query logging writes every DNS query made from the VPC to CloudWatch Logs, S3, or Kinesis Firehose. It is the authoritative record for investigating suspected exfiltration or misuse and complements — but does not replace — GuardDuty. Remember that if a DHCP option set redirects instances to a non-Amazon resolver, both query logging and GuardDuty DNS findings go dark, because the queries never touch the Route 53 Resolver.

Practical Problem: Use-Case Scenario

Scenario: Meridian Financial runs a multi-account AWS environment with a hub-and-spoke network: a RAM-shared shared-services VPC hosts central NAT Gateways, Route 53 Resolver endpoints, and Transit Gateway attachments while multiple application VPCs are peered or attached to the Transit Gateway. On-premises datacenters connect via Direct Connect with VPN failover, and teams rely on centralized DHCP option sets and shared resolver endpoints for hybrid DNS resolution.

Challenge: A recent incident showed sensitive S3 objects being accessed via the public internet because spokes routed to the shared NAT instead of VPC endpoints, DNS queries for internal zones leaked to public resolvers, and an EC2 used as an ad-hoc router (source/dest check disabled) enabled lateral movement.

Recommended Approach:

1. Deploy Gateway VPC Endpoints for S3 and DynamoDB and Interface Endpoints (AWS PrivateLink) for Secrets Manager and KMS in the shared-services VPC, attaching explicit endpoint policies restricting access to named buckets and service principals.
2. Rework NAT design so application subnets use VPC endpoints for AWS APIs and S3; retain NAT Gateways only for genuine internet egress with strict egress security groups and Flow Logs to CloudWatch/ S3.
3. Re-enable source/dest checks on all EC2 instances except documented routing appliances; move routing to Transit Gateway attachments or managed NAT instances and enforce route table least-privilege.
4. Tighten Security Groups and subnet NACLs to a deny-by-default posture, and apply centralized IAM+SG baselines via AWS Organizations SCPs and AWS Config rules.
5. Harden hybrid DNS by deploying Route 53 Resolver inbound/outbound endpoints, configure conditional forwarding and DNS Firewall rules, enable Resolver query logging to CloudWatch Logs, and use DHCP option sets to enforce internal resolvers for all VPCs shared via RAM.

Rationale: This approach removes unnecessary internet egress by using VPC endpoints with endpoint policies, centralizes and controls routing via Transit Gateway/Direct Connect, restores instance-level protections, and prevents DNS leakage with Resolver endpoints and logging—aligning with AWS networking and defense-in-depth best practices.

VPC Endpoints and Endpoint Policies

VPC endpoints allow workloads inside a VPC to reach AWS service APIs without traversing the public internet or a NAT gateway. There are two architectural flavors, and picking the wrong one is a common source of misrouted traffic.

• Gateway endpoints: Used only for Amazon S3 and DynamoDB. They are implemented as a target in a route table (prefix list pl-xxxxxxxx pointing at vpce-xxxxxxxx). No ENI is created, no DNS changes are needed, and there is no per-hour cost.

• Interface endpoints (PrivateLink): Used for KMS, SQS, SNS, Secrets Manager, STS, EC2 API, and most other services. They provision ENIs with private IPs inside chosen subnets and are billed hourly plus per-GB.

For a cross-account batch job where EC2 instances in Account B read from an S3 bucket in Account A encrypted with a KMS key in Account A, the correct design is a gateway endpoint for S3 plus an interface endpoint for KMS. The gateway endpoint keeps s3:GetObject, s3:PutObject, s3:PutObjectAcl, and s3:ListBucket off the internet; the interface endpoint does the same for kms:Decrypt, kms:Encrypt, and kms:GenerateDataKey. Because the KMS key ARN uses the standard kms.<region>.amazonaws.com hostname, the interface endpoint must have Private DNS enabled so the SDK’s unmodified hostname resolves to the endpoint ENI rather than the public KMS service. Without Private DNS (or without VPC-level DNS hostnames and DNS resolution both enabled), the client would still hit the public endpoint — hence the requirement of “no code changes” implicitly demands Private DNS.

Endpoint policies are a second, independent authorization layer. A permissive default policy exists, but hardening for a specific bucket and key looks like this:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
    "Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
  }]
}

Merely creating the endpoint is not enough. Two failure modes recur: (1) the endpoint exists but the private subnet’s route table has no entry for the S3 prefix list, so traffic still egresses via the NAT gateway; (2) the endpoint policy omits an action such as s3:PutObjectAcl or targets the wrong bucket ARN, silently blocking calls that IAM would otherwise allow. Both bucket policy and endpoint policy must permit the request — they are intersected, not unioned.

Security Groups, NACLs, and Rapid Containment

Security groups and NACLs solve overlapping problems at different layers, and the exam often forces a choice between them for incident response.

• Security groups: Stateful, evaluated at the ENI. Return traffic is auto-allowed. Only allow rules exist. Ideal for host-level policy (“web tier can reach app tier on 8080”).

• Network ACLs: Stateless, evaluated at the subnet boundary. Both allow and deny rules exist, processed in rule-number order. Ideal for coarse, subnet-wide blocks — especially blocklisting an IP range or shutting down a specific port across every instance in a subnet.

When a malware outbreak forces you to block outbound TCP/2905 to a set of command-and-control IPs across many instances, a NACL deny rule is the correct instrument. Security groups cannot express “deny” and would require enumerating and modifying every SG referenced by every affected ENI. A single subnet-level NACL deny rule at a low rule number (e.g., 90) covers all instances in that subnet instantly while preserving unrelated traffic evaluated by later allow rules.

Because NACLs are stateless, remember that both directions need rules. Blocking egress on 2905 does not require an ingress rule, but if you also want to reject inbound replies you must add an inbound entry — and inbound allow entries for ephemeral ports (1024–65535) must exist to let legitimate return traffic pass.

NAT Gateways, Routing, and AZ Independence

A NAT gateway is a zonal resource. The canonical pattern is one NAT gateway per Availability Zone with each private subnet’s route table pointing 0.0.0.0/0 at the NAT in the same AZ:

PrivateRouteTable-AZ-a:  0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b:  0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c:  0.0.0.0/0 -> nat-cccc (in subnet public-az-c)

A single NAT shared across AZs looks cheaper but introduces two problems: cross-AZ data transfer charges on every packet, and a hard availability dependency — if that AZ goes down, every private subnet loses internet egress. The zonal-NAT pattern also avoids asymmetric-return oddities when combined with Transit Gateway inspection (see below).

VPC Flow Logs for Investigation

Flow Logs capture 5-tuple metadata (source/dest IP, port, protocol, action ACCEPT/REJECT, bytes, packets) at the VPC, subnet, or ENI level. To hunt instances beaconing to C2 hosts on TCP/2905, enable Flow Logs on the VPC with traffic type set to REJECT (since the NACL is now dropping the traffic) and query in CloudWatch Logs Insights or Athena:

SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;

The srcaddr column reveals infected instance IPs with minimal effort — no packet captures, no host agents. Choosing “ALL” traffic works but produces more data and cost; choosing only “ACCEPT” would miss the dropped attempts entirely, which is precisely what you need to see.

PrivateLink, Transit Gateway, and Network Firewall

PrivateLink extends the interface-endpoint model to your own services: a provider VPC exposes an NLB behind a VPC endpoint service, and consumers create interface endpoints to reach it without VPC peering or route sharing. It is unidirectional and hides the provider’s CIDR entirely.

Transit Gateway (TGW) is the hub for many-to-many VPC and on-premises connectivity. A common pattern is a centralized inspection VPC running AWS Network Firewall or third-party appliances, with TGW route tables steering spoke-to-spoke traffic through the inspection VPC. This design breaks under default TGW behavior because TGW hashes flows across attachment ENIs in different AZs, and the return path may enter a different AZ than the forward path. Stateful firewalls drop the mid-flow packets they never saw the SYN for.

Two corrections are required together. First, enable Appliance Mode on the TGW attachment for the inspection VPC; this pins each bidirectional flow to the same AZ ENI so forward and return traverse the same firewall endpoint. Second, configure TGW route tables so spoke attachments send traffic to the inspection VPC attachment, and a separate post-inspection route table on the inspection VPC returns traffic to the correct spoke. Skipping either — appliance mode alone without the route tables, or route tables alone without appliance mode — leaves asymmetric drops in place.

Network Firewall itself uses Suricata-compatible rules and depends on symmetric routing to maintain flow state; combining it with Flow Logs on both the inspection VPC and spoke VPCs gives the forensic trail needed to prove which spoke initiated a session and whether the firewall permitted or dropped it.

Practical Problem: Use-Case Scenario

Scenario: Meridian Financial runs a multi-account AWS environment with production VPCs across three Availability Zones in us-east-1 connected by an AWS Transit Gateway to a central security VPC. They use NAT Gateways in each AZ for egress, S3 Gateway Endpoints and Interface Endpoints (PrivateLink) for partner SaaS, and a centralized AWS Network Firewall alongside Security Groups and NACLs; VPC Flow Logs stream to CloudWatch for monitoring.

Challenge: A production EC2 instance has been suspected of lateral movement and data exfiltration attempts to an external IP and to S3, and Meridian needs rapid containment across AZs without disrupting other business-critical VPCs.

Recommended Approach:

1. Immediately quarantine the compromised instance by replacing its Security Groups with a restrictive “quarantine” SG that denies all outbound/inbound, and tag the instance for automated remediation via Systems Manager; simultaneously apply subnet-level Network ACL rules to block egress to suspicious external IP ranges.
2. Isolate the VPC on the Transit Gateway by removing or changing the TGW route table attachment for the affected VPC to a quarantine TGW route table (blackhole or no-route to other attachments), stopping lateral movement to other VPCs.
3. Redirect remaining VPC egress through the centralized AWS Network Firewall by updating TGW/route table entries to force inspection and block known-malicious destinations, preserving AZ independence by keeping NAT Gateways per AZ for resilient, inspected egress.
4. Harden data-plane controls by applying restrictive VPC Endpoint policies on S3/DynamoDB Gateway Endpoints to deny Put/Get from non-approved principals and ensure internal APIs use Interface Endpoints (PrivateLink) to avoid internet paths.
5. Use VPC Flow Logs with CloudWatch Logs Insights and AWS CloudTrail to perform forensics, then remediate (reimage, rotate keys) and reintroduce the instance only after validation; enforce rules via AWS Firewall Manager/AWS Config.

Rationale: This sequence provides rapid, least-privilege containment at both host and network layers, centralizes inspection with Network Firewall and Transit Gateway routing to minimize blast radius, preserves AZ resilience with per-AZ NAT, and uses VPC Flow Logs for accountable investigation—aligning with AWS defense-in-depth best practices.

← Data Protection · All domains · Edge →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Amazon →