SCS-C03 · Domain 3 · Infrastructure Security (18%) · Day 3 of 5
Hybrid connectivity and finding unneeded network access
Day 2 controlled traffic inside AWS with security groups, NACLs, Network Firewall and segmentation. Today the network reaches outside AWS: Site-to-Site VPN design, Direct Connect and its virtual interfaces, encrypting Direct Connect with MACsec or private IP VPN, transit gateway route tables for segmentation and inspection, Verified Access for hybrid and TCP workloads, and the three tools that find network paths you never meant to open.
Skill 3.3.2 hybrid and multi-cloud linksSkill 3.3.3 hybrid workload requirementsSkill 3.3.5 unnecessary network access~90 min read + 30 min lab
01
Site-to-Site VPN design
Skill 3.3.2 asks you to design secure connectivity between your own data center (or another cloud) and AWS. The quickest option is AWS Site-to-Site VPN: IPsec tunnels over the internet between your router and AWS. Data Protection Day 4 covered Client VPN for people; this is network to network, and the exam tests the design details: two tunnels, where they end, how fast they go and how to make them faster.
A VPN connection ends on a virtual private gateway (one VPC), a transit gateway (many VPCs and other connections) or AWS Cloud WAN. The newer features (accelerated VPN, Large Bandwidth Tunnels, ECMP, private IP VPN) need a transit gateway or Cloud WAN, so for most multi-VPC exam stories the transit gateway is the right end point.
Concept profile
AWS Site-to-Site VPN connection
often confused with AWS Client VPN
?What is it?
A managed IPsec connection between a customer gateway device in your network and AWS. Each connection has two tunnels, each with its own public IP address and each ending in a different Availability Zone.
⚙How does it work?
You create a customer gateway resource (your device’s IP and BGP ASN), then a VPN connection to a VGW, transit gateway or Cloud WAN, and download a device-specific configuration file.
Routing is static or dynamic (BGP). Use both tunnels: if one goes down, traffic fails over to the other.
Tunnel options let you restrict IKE versions, encryption and integrity algorithms and DH groups; AWS starts with the lowest configured value, so remove weak options with modify-vpn-connection-options.
Bandwidth: up to 1.25 Gbps per tunnel by default; a Large Bandwidth Tunnel gives up to 5 Gbps on a transit gateway or Cloud WAN. For more, use ECMP over several connections (needs BGP).
Accelerated VPN sends traffic into the AWS network at the nearest edge location through Global Accelerator.
{ }Structure
Two tunnels in two AZs, ending on a transit gateway that routes to many VPCs.
⇄Site-to-Site VPN vs AWS Client VPN
Site-to-Site VPN
Client VPN
Connects
A whole network (router to AWS)
One person’s device to a VPC
Client side
Customer gateway device
OpenVPN-based client app
Authentication
Pre-shared keys or certificates
Certificates, Active Directory, SAML
Ends on
VGW, transit gateway, Cloud WAN
Client VPN endpoint in a VPC
Exam hint
“data center”, “branch office”
“remote employees”, “laptops”
!Common mistakes the exam tests
Configuring only one tunnel: AWS tunnel maintenance then causes an outage. Always set up both.
Choosing accelerated VPN or a Large Bandwidth Tunnel with a virtual private gateway: both need a transit gateway (LBT also works on Cloud WAN).
Trying to turn on acceleration for an existing connection: you must create a new VPN connection.
Expecting ECMP with static routing: ECMP on a transit gateway needs BGP.
Leaving the default proposal list in place when policy says “IKEv2 and AES-256 only”: restrict the tunnel options.
Forgetting that LBT and accelerated VPN can’t be used together.
✓Benefits and use cases
Fast, cheap hybrid link that can be live in minutes.
Encrypted backup path for a Direct Connect connection.
Connecting branch offices or another cloud provider’s VPN gateway.
Accelerated VPN and tunnel logs
An accelerated VPN connection uses AWS Global Accelerator so packets enter the AWS network at the edge location closest to your customer gateway, instead of crossing the whole public internet. Rules: it works only on a transit gateway, NAT-T is required, the customer gateway must start IKE, and it can’t be used over a Direct Connect public VIF. For troubleshooting, turn on Site-to-Site VPN tunnel logs to CloudWatch Logs to see IKE and IPsec negotiation and dead peer detection events.
Think of it like · a private tunnel between two buildings
Two offices connected under a busy city street.
AWS concept
Familiar thing
Customer gateway device
≈
The door on your building’s side of the tunnel
Two tunnels in two AZs
≈
Two tunnels to two different entrances, so roadworks on one don’t stop you
IKE / IPsec options
≈
The kind of lock on the tunnel doors; you can refuse old, weak locks
Large Bandwidth Tunnel
≈
A wider tunnel that fits more people at once
ECMP
≈
Opening several tunnels side by side and sharing the crowd
Accelerated VPN
≈
Walking to the nearest underground station and taking the private train, not the city streets
Real AWS example · a hardened, accelerated VPN to a transit gateway
IKEv2 and AES-256 only, tunnel logs on, acceleration set at creation.
Two outside IPs, both UP: the router uses both tunnels. One DOWN tunnel is a resilience finding even if traffic still flows.
Exam-style scenario
A company connects its data center to 30 VPCs through a transit gateway with a Site-to-Site VPN. Users far from the AWS Region complain about jitter over the internet path. The security team also requires IKEv2 with AES-256 only. What should the network team do?
A. Turn on acceleration on the existing VPN connection and keep default tunnel options.
B. Create a new accelerated VPN connection on the transit gateway with tunnel options limited to IKEv2 and AES-256, move the customer gateway to it, then delete the old connection.
C. Attach the VPN to a virtual private gateway in each VPC.
D. Replace the VPN with VPC peering.
Show the worked answer
Answer: B
Acceleration can only be chosen at creation and only on a transit gateway; tunnel options enforce the crypto policy.
Why not the others
A: Acceleration can’t be switched on for an existing connection, and defaults allow weaker options.
C: VGWs don’t support acceleration and don’t scale to 30 VPCs.
D: Peering connects VPCs, not a data center.
How the exam tests this
“Data center to many VPCs over IPsec”→ VPN to a transit gateway.
“Lower jitter for far-away sites”→ Accelerated VPN (TGW, new connection).
“More than 1.25 Gbps per tunnel”→ Large Bandwidth Tunnel (5 Gbps, TGW or Cloud WAN).
“Aggregate bandwidth across tunnels”→ ECMP + BGP on the TGW.
“Only strong crypto may be negotiated”→ Restrict tunnel options.
AWS Direct Connect is a private, dedicated network link from your data center to AWS through a Direct Connect location. It gives steady bandwidth and latency because it doesn’t cross the public internet. The security point the exam loves: a private link is not an encrypted link. Direct Connect traffic is not encrypted by default; you add MACsec or a VPN (next section).
Concept profile
Direct Connect virtual interface (VIF)
often confused with Site-to-Site VPN
?What is it?
A VIF is a logical connection (an 802.1Q VLAN with its own BGP session) on a Direct Connect connection. There are three kinds: private (to VPCs with private IPs), public (to AWS public service endpoints) and transit (to transit gateways through a Direct Connect gateway).
⚙How does it work?
Dedicated connection: a physical port for you. Hosted connection: a partner provisions a slice of their port for you.
Private VIF: attaches to a virtual private gateway directly or to a Direct Connect gateway.
Public VIF: reaches public AWS endpoints such as S3 using public IPs; you advertise your public prefixes over BGP.
Transit VIF: always goes through a Direct Connect gateway to one or more transit gateways; works on dedicated or hosted connections of any speed.
Jumbo frames: private VIF up to 9001 bytes; transit VIF up to 8500 bytes.
{ }Structure
One physical link, three kinds of VIF, and the global Direct Connect gateway.
⇄Direct Connect vs Site-to-Site VPN
Direct Connect
Site-to-Site VPN
Path
Private circuit via a DX location
Public internet
Encrypted
No, unless MACsec or VPN on top
Yes, IPsec
Setup time
Weeks (physical cross-connect)
Minutes
Performance
Consistent bandwidth and latency
Varies with internet
Exam hint
“consistent”, “dedicated”, “large transfers”
“quick”, “encrypted”, “backup path”
!Common mistakes the exam tests
Calling Direct Connect “encrypted” because it is private: it isn’t. Add MACsec or a VPN.
Using a public VIF plus a public VPN to reach VPCs when the goal is “no public IPs”: use private IP VPN over a transit VIF.
Expecting a Direct Connect gateway to route VPC A to VPC B: it blocks traffic between its own associations (with a narrow supernet exception).
Forgetting that VPCs on transit gateways associated to the same DX gateway can talk via the TGW; block them with TGW route tables (blackhole).
Building one DX with no backup: add a second connection at another location, or a VPN as backup.
✓Benefits and use cases
Large, steady data transfers and hybrid apps that need predictable latency.
One link that reaches VPCs in many Regions through a DX gateway.
Lower data transfer out cost for heavy hybrid traffic.
Direct Connect gateway
A Direct Connect gateway is a global resource. Associate it with virtual private gateways, transit gateways or a Cloud WAN core network in any Region except the China Regions, so one VIF can reach VPCs in many Regions. It can belong to a central network account; other accounts send association proposals that the owner accepts, and the owner sets allowed prefixes per association, which limits which VPC CIDRs are advertised to on premises. It doesn’t let two of its associations send traffic to each other (for example VGW to VGW).
Think of it like · a private road to a business park
Instead of public streets, your company builds its own road.
AWS concept
Familiar thing
Direct Connect connection
≈
A private road from your office to the business park gate
Dedicated vs hosted
≈
Building your own road, or renting one lane of a partner’s road
Private VIF
≈
A lane that goes to one tenant’s building
Public VIF
≈
A lane to the park’s shared shops, open to everyone’s address
Transit VIF + DX gateway
≈
A lane to the park’s central roundabout, which leads to every building in every town
Not encrypted
≈
A private road still has no walls: anyone at the gate can see the cars
Real AWS example · associate a transit gateway with a DX gateway
For a transit gateway association, the allowed prefixes are exactly what is advertised to on premises, so keep the list tight.
Exam-style scenario
A company has one 10 Gbps Direct Connect connection in Frankfurt. It must give its data center private access to VPCs in eu-central-1 and us-east-1, attached to transit gateways in each Region, without any traffic using the internet. Which design meets this?
A. A public VIF and a Site-to-Site VPN in each Region.
B. A transit VIF to a Direct Connect gateway associated with both transit gateways, with allowed prefixes for the VPC ranges.
C. A private VIF directly to a VGW in each Region.
D. VPC peering between the Regions and a private VIF in Frankfurt only.
Show the worked answer
Answer: B
A transit VIF reaches transit gateways through a global DX gateway, which spans Regions.
Why not the others
A: A public VIF exposes public endpoints and the VPN adds public IPs.
C: A private VIF attached directly to a VGW reaches only that VGW in its Region.
D: Peering isn’t transitive for on-premises traffic.
How the exam tests this
“Private access to VPCs in several Regions over one DX”→ DX gateway.
“DX to transit gateways”→ Transit VIF via DX gateway.
“Reach S3 public endpoints over DX”→ Public VIF.
“Is Direct Connect encrypted?”→ No, add MACsec or VPN.
“Limit which VPC CIDRs on-prem learns”→ Allowed prefixes on the association.
Must remember
Three VIFs: private, public, transit.
Transit VIF needs a DX gateway.
DX gateway: global, not China.
DX is private, not encrypted.
DX gateway doesn’t route association to association.
Encrypting Direct Connect: MACsec and private IP VPN
When an exam story says “Direct Connect” and “encryption in transit”, there are two answers. MACsec encrypts the link at Layer 2, at line rate, between your router and the AWS device. Private IP VPN runs IPsec tunnels over Direct Connect, end to end from your device to a transit gateway, using private IP addresses only. Knowing what each one protects, and what each one needs, is the whole skill.
Concept profile
MACsec on Direct Connect
often confused with IPsec VPN over Direct Connect
?What is it?
IEEE 802.1AE MAC Security: point-to-point, Layer 2 encryption between your edge router and the Direct Connect device over the cross-connect. It protects that one hop, not every Ethernet segment end to end.
⚙How does it work?
Supported on dedicated connections and LAGs at 10, 100 and 400 Gbps at selected locations; not on hosted connections. Dedicated connections pay nothing extra for MACsec.
Cipher suites: GCM-AES-256 or GCM-AES-XPN-256 at 10 Gbps; GCM-AES-XPN-256 only at 100 and 400 Gbps. Only 256-bit keys.
You generate a CKN/CAK pair (64 hex characters each, static CAK mode) and associate it with associate-mac-sec-key; AWS stores it in Secrets Manager. Keychains hold up to three pairs for rotation.
Encryption mode: should_encrypt (default; falls back to clear text if MACsec fails) or must_encrypt (no traffic without MACsec).
On a LAG, every member must be MACsec-capable and the same bandwidth.
{ }Structure
MACsec protects the link; private IP VPN protects the path to the transit gateway.
⇄MACsec vs IPsec VPN over Direct Connect
MACsec
Private IP VPN over DX
Layer
2 (Ethernet frames)
3 (IPsec)
Protects
Your router ↔ AWS DX device
Your device ↔ transit gateway
Speed
Line rate on 10/100/400 Gbps
Per-tunnel limits (1.25 or 5 Gbps), ECMP
Needs
Dedicated, MACsec-capable port
Transit VIF, DX gateway, transit gateway
Hosted connection
Not supported
Works
!Common mistakes the exam tests
Choosing MACsec for a hosted connection or a 1 Gbps port: not supported.
Leaving the mode at should_encrypt when policy says traffic must never be sent unencrypted: set must_encrypt.
Thinking MACsec gives end-to-end encryption to the instance: it covers one hop; use TLS or IPsec for the rest.
Building “VPN over DX” with a public VIF when the requirement is no public IPs: private IP VPN uses a transit VIF.
Overlapping the private IP CIDR for the VPN with other transit gateway attachments.
✓Benefits and use cases
Regulated industries that need encryption on a 100 Gbps link without losing throughput.
Compliance rules that forbid public IP addresses on VPN endpoints.
Layered defence: MACsec on the link plus TLS in the application.
Private IP VPN over Direct Connect
To build it: a transit gateway with a private IP CIDR block for the VPN, a Direct Connect gateway associated with that transit gateway (with the transit gateway CIDR in the allowed prefixes), a transit VIF, and private addresses (RFC 1918 or RFC 6598) on both tunnel ends. Then you create a VPN connection that uses the DX attachment as transport. You can give the VPN attachment a different transit gateway route table from the DX attachment, so some traffic is encrypted and some isn’t. It also raises route scale: AWS lists 5,000 outbound and 1,000 inbound routes, compared with 200 and 100 for Direct Connect alone.
Multi-cloud links
For another cloud, the classic answers are a Site-to-Site VPN to that cloud’s VPN gateway (on a transit gateway) or Direct Connect plus the other provider’s dedicated link at a shared colocation. A newer option is AWS Interconnect (multicloud): a managed private link from a Direct Connect gateway to another cloud, encrypted with MACsec by default. It became generally available on 14 April 2026 with Google Cloud, Oracle Cloud Infrastructure followed in July 2026, and Microsoft Azure is in preview. It attaches to a Direct Connect gateway, so one VPC can use a VGW, many VPCs a transit gateway, and global networks Cloud WAN. Each cloud provider still encrypts its own backbone, so check that the whole path meets your compliance rules. Because it is new, older exam questions will still expect VPN or Direct Connect answers.
Think of it like · a delivery van between two warehouses
Two ways to protect goods on the road.
AWS concept
Familiar thing
MACsec
≈
A locked steel cage on the loading dock bridge between the two buildings
must_encrypt
≈
The dock refuses to load anything if the cage isn’t locked
should_encrypt
≈
Load anyway if the lock is broken, just carry on
Private IP VPN
≈
Locked boxes that stay locked from your shelf to the receiver’s shelf
CKN/CAK in Secrets Manager
≈
The cage key kept in the company safe
Hosted connection
≈
A shared dock you don’t control, so you can’t add your own cage
Real AWS example · turn on MACsec with must_encrypt
Configure the same CKN/CAK on your router first. With must_encrypt, a key mismatch stops all traffic, so plan the change window.
Exam-style scenario
A bank has a hosted 1 Gbps Direct Connect connection from a partner. Regulators require all traffic between the data center and its VPCs to be encrypted, and the bank’s policy forbids public IP addresses on VPN endpoints. What should it do?
A. Enable MACsec with must_encrypt on the hosted connection.
B. Create a transit VIF to a Direct Connect gateway associated with a transit gateway, and build a private IP Site-to-Site VPN over it.
C. Create a public VIF and a standard Site-to-Site VPN over it.
D. Rely on Direct Connect being a private circuit.
Show the worked answer
Answer: B
Private IP VPN encrypts over DX without public IPs and works on hosted connections.
Why not the others
A: MACsec isn’t supported on hosted connections or 1 Gbps ports.
C: Uses public IPs and opens access to AWS public services.
D: Private doesn’t mean encrypted.
How the exam tests this
“Encrypt a 100 Gbps DX link at line rate”→ MACsec.
“No traffic if encryption fails”→ must_encrypt.
“IPsec over DX without public IPs”→ Private IP VPN over a transit VIF.
“Hosted connection needs encryption”→ VPN over DX (not MACsec).
Transit Gateway route tables: segmentation and inspection
Once many VPCs and on-premises links meet at one transit gateway, it becomes your most important network control. By default, every attachment can be associated with and propagate to one default route table, which means everything can reach everything. Skill 3.3.2 (and Day 2’s segmentation skill) expects you to split that into separate route tables and to send traffic through an inspection VPC.
Concept profile
Transit gateway route table
often confused with VPC route table
?What is it?
A routing table inside a transit gateway. Each attachment (VPC, VPN, Direct Connect gateway, peering, Connect) is associated with exactly one route table, and can propagate its routes to one or more route tables.
⚙How does it work?
Association: the table the transit gateway uses to route traffic coming from that attachment.
Propagation: which tables automatically learn the attachment’s CIDRs (VPC CIDRs, or BGP routes from VPN and DX).
Static routes override or add paths, for example 0.0.0.0/0 to the inspection VPC attachment. A blackhole route drops traffic to a CIDR.
Turn off default association and propagation for strict designs, so new attachments don’t join the shared table.
For stateful firewalls in an inspection VPC, enable appliance mode on that VPC attachment so both directions of a flow use the same AZ.
{ }Structure
Three route tables: prod and on-prem go through inspection, dev is kept apart.
⇄TGW route table vs VPC route table
TGW route table
VPC route table
Lives in
The transit gateway
A VPC, linked to subnets
Chooses
Which attachment next
Which target (IGW, NAT, TGW, endpoint)
Learns routes by
Propagation from attachments
Static, or VGW route propagation
Segments
VPCs, VPNs, DX from each other
Subnets inside one VPC
Exam hint
“isolate dev from prod across VPCs”
“send subnet traffic to the firewall endpoint”
!Common mistakes the exam tests
Leaving default association and propagation on: every new VPC can reach prod.
Forgetting the return path: the prod table needs a route back, or traffic is dropped.
Inspecting with a stateful firewall without appliance mode: replies come back through another AZ and are dropped.
Using security groups to separate whole environments across VPCs when route tables can stop the traffic before it arrives.
Peering instead of a transit gateway for dozens of VPCs: peering isn’t transitive and can’t force inspection.
✓Benefits and use cases
Keep dev, test and prod VPCs apart while sharing services.
Send all on-premises and egress traffic through Network Firewall.
Give each business unit its own routing domain.
Think of it like · a train station with signboards
The transit gateway is the central station.
AWS concept
Familiar thing
Attachment
≈
A platform where a train line arrives
Association
≈
The departure board each platform’s passengers must read
Propagation
≈
Adding a new line’s stops to chosen departure boards
Blackhole route
≈
A board entry that says: this destination is closed
Inspection VPC
≈
The security check every passenger on some lines must pass first
Appliance mode
≈
Making sure you come back through the same security check you left through
Real AWS example · split dev from prod and force inspection
A route table for dev that can’t reach prod, and appliance mode on the inspection attachment.
Dev learns only the shared services routes; the blackhole makes the “no prod” rule explicit even if someone adds a propagation later.
Exam-style scenario
A company has 40 VPCs and a Direct Connect gateway on one transit gateway that uses the default route table. Auditors found dev VPCs can reach prod databases, and all traffic between on premises and prod must pass through AWS Network Firewall. What should the network team do?
A. Add NACL deny rules in every prod subnet for dev CIDRs.
B. Create separate route tables for prod, dev and on-premises attachments, disable default association and propagation, route on-premises and prod traffic to an inspection VPC with Network Firewall and appliance mode, and blackhole prod CIDRs in the dev table.
C. Replace the transit gateway with VPC peering.
D. Use security groups that reference dev security groups.
Show the worked answer
Answer: B
Route table segmentation stops dev to prod at the hub; static routes and appliance mode force symmetric inspection.
Why not the others
A: Hard to maintain across 40 VPCs and gives no inspection.
C: Peering can’t force traffic through a firewall.
D: Security group references don’t work across a transit gateway and don’t inspect.
How the exam tests this
“Isolate environments across many VPCs”→ Separate TGW route tables.
“Stateful firewall drops return traffic via TGW”→ Enable appliance mode.
“Explicitly drop traffic to a CIDR”→ Blackhole static route.
Skill 3.3.3 is about the security requirements of the workloads that cross the hybrid link: who may reach which app, from which device, and how you prove it. A VPN gives a user a route into a whole network. AWS Verified Access gives a user access to one application after checking identity and device on every request, with no VPN. Data Protection Day 4 introduced it for web apps; here we use it for hybrid and non-HTTP workloads.
Concept profile
AWS Verified Access
often confused with AWS Client VPN
?What is it?
A zero trust access service. It evaluates each request against policies using trust data from an identity trust provider and optional device trust providers, and only then forwards it to the application endpoint.
⚙How does it work?
An instance has one identity trust provider (IAM Identity Center or an OIDC provider) and can add device trust providers (for example CrowdStrike, Jamf, JumpCloud).
Endpoints represent apps: load balancer, network interface, network CIDR or Amazon RDS. A CIDR endpoint can reach apps on premises over your VPN or Direct Connect.
Groups hold endpoints with similar needs; the group policy is inherited, and an endpoint can add its own policy. Policies are written in Cedar.
HTTP(S) apps work from a browser. Non-HTTP (TCP) apps such as SSH, RDP or databases use the Connectivity Client on Windows or macOS.
Default deny; every access attempt is logged (CloudWatch Logs, S3 or Firehose). AWS WAF can protect HTTP endpoints.
{ }Structure
Identity + device data → Cedar policy → one application, checked on every request.
⇄Verified Access vs AWS Client VPN
Verified Access
Client VPN
Grants
One application per policy
A network route into the VPC
Checks
Every request, identity + device posture
At connection time
Client
Browser, or Connectivity Client for TCP
OpenVPN-based client
Lateral movement
Very limited
Possible inside allowed CIDRs
Exam hint
“zero trust”, “device posture”, “without a VPN”
“full network access for remote staff”
!Common mistakes the exam tests
Choosing Client VPN when the story says “without a VPN” or “per-application access based on device posture”.
Expecting more than one identity trust provider per instance: it is one identity provider plus multiple device providers.
Forgetting that no policy means deny: endpoints work only after a group or endpoint policy allows access.
Assuming Verified Access is only for web apps: TCP endpoints with the Connectivity Client cover SSH, RDP and databases.
Opening security groups to 0.0.0.0/0 behind Verified Access: allow only the Verified Access endpoint’s security group.
✓Benefits and use cases
Contractors reach one internal app, with device checks, and nothing else.
Replacing bastion hosts and VPNs for SSH or RDP access.
Giving on-premises staff zero trust access to apps in AWS and in the data center.
Designing hybrid workload requirements
Write the requirement first, then pick the control. “Only managed laptops may reach the payroll app” → device trust provider + Cedar policy. “Payroll still runs on premises” → network CIDR endpoint whose traffic travels over Direct Connect or VPN. “Traffic must be encrypted end to end” → TLS to the app, plus MACsec or IPsec on the hybrid link. “Prove who accessed what” → Verified Access logs. For machine-to-machine traffic (servers, not people), Verified Access isn’t the tool: use Site-to-Site VPN or DX with security groups and TGW route tables.
Think of it like · a hotel key card
How a modern hotel controls who enters which room.
AWS concept
Familiar thing
Verified Access
≈
A key card checked at every door, not just at the front entrance
Identity trust provider
≈
Reception checking your passport
Device trust provider
≈
Checking you aren’t carrying anything forbidden
Cedar policy
≈
The rule: guests on floor 5 may open room 512 and the gym, nothing else
Connectivity Client
≈
A card that also works on the side doors (non-web services)
Client VPN
≈
Getting a master key to the whole floor once you’re inside
Real AWS example · a Cedar group policy with identity and device checks
Only the finance group, with a verified email, on a low-risk device.
oidc and jamf are the policy reference names you give the trust providers. Attach this to the group so every endpoint in it inherits it.
Exam-style scenario
A company lets 300 contractors reach an internal billing app on premises and an RDS database in AWS through Client VPN. A review found contractors could scan other servers in the VPC. The company wants per-application access, a check that each laptop is managed by Jamf, and no VPN. What should it do?
A. Tighten the Client VPN authorization rules.
B. Use Verified Access with an OIDC identity provider and Jamf device trust, a network CIDR endpoint for the on-premises app reached over Direct Connect, an RDS endpoint for the database, and the Connectivity Client for the TCP database access.
C. Put the app behind a public ALB with AWS WAF.
D. Give each contractor an IAM user and Session Manager access.
Show the worked answer
Answer: B
Verified Access checks identity and device per request and exposes only the named apps, including TCP and on-premises ones.
Why not the others
A: Still a VPN with network-level access and no device check.
C: Exposes the app to the internet without device posture.
D: Session Manager is for instance shells, not app access for contractors with device checks.
How the exam tests this
“Zero trust access to one app, no VPN”→ Verified Access.
“Allow only compliant devices”→ Device trust provider + policy.
Skill 3.3.5 asks you to identify unnecessary network access. Rules pile up: an old security group rule, a forgotten internet gateway route, a peering connection nobody uses. Three AWS tools find them, and the exam checks that you pick the right one: Network Access Analyzer (all paths that break a rule), VPC Reachability Analyzer (one path, A to B) and Amazon Inspector network reachability findings (open ports on EC2, automatically).
Concept profile
Network Access Analyzer
often confused with VPC Reachability Analyzer
?What is it?
A VPC feature that finds unintended network access to your resources. You describe what must not happen in a Network Access Scope; the analysis returns every network path that matches.
⚙How does it work?
A scope has MatchPaths (paths you consider a violation) and ExcludePaths (approved exceptions). Findings = paths that match MatchPaths and no ExcludePaths.
You can describe resources by ID, type (for example AWS::EC2::InternetGateway), tags, IP ranges, ports and protocols.
Amazon-created scopes to start with: All-IGW-Ingress, AWS-IGW-Egress, AWS-VPC-Ingress and AWS-VPC-Egress.
It analyzes configuration within the account and Region where you run it; you pay per network interface analyzed.
Use it to prove compliance (“only the web tier is reachable from the internet”) and run it regularly.
{ }Structure
Three tools, three questions.
⇄Network Access Analyzer vs VPC Reachability Analyzer
Network Access Analyzer
Reachability Analyzer
Question
Which paths exist that shouldn’t?
Can this source reach this destination?
Input
A scope (rules about many resources)
One source, one destination, port
Output
All matching paths (findings)
Reachable path, or the blocking component
Typical use
Audit and compliance
Troubleshooting one connection
Pricing
Per ENI analyzed
Per analysis run
!Common mistakes the exam tests
Using Reachability Analyzer to “find all resources reachable from the internet”: that is Network Access Analyzer.
Using Network Access Analyzer to debug why one instance can’t reach one database: Reachability Analyzer names the blocking component.
Thinking any of these tools sends test traffic: they analyze configuration.
Expecting Inspector network reachability findings for Lambda or containers: they are for EC2 instances only.
Forgetting ExcludePaths, then drowning in findings for approved paths such as the public ALB.
✓Benefits and use cases
Prove that data subnets have no path from any internet gateway.
Find unused or unexpected paths through peering, VPN and transit gateways.
Turn security network rules into a repeatable check.
Inspector network reachability and Reachability Analyzer
Amazon Inspector creates network reachability findings when TCP or UDP ports on an EC2 instance are reachable from VPC edges: an internet gateway (also through an ALB or Classic Load Balancer), a VPC peering connection, or a VPN through a virtual private gateway. It evaluates security groups, NACLs, route tables, gateways and endpoints and runs every 12 hours once Inspector is on, with no extra setup. Findings go to the Inspector console, Security Hub and EventBridge, so you can automate a fix. VPC Reachability Analyzer answers one question: can source A reach destination B on this port? If yes, it shows the hop-by-hop path; if no, it names the blocking component, for example a security group, NACL, route table or load balancer. Combining Inspector package findings with a reachability finding on the same instance tells you which vulnerable hosts are actually exposed.
Think of it like · a building safety inspection
Different checks for different questions.
AWS concept
Familiar thing
Network Access Analyzer
≈
An inspector with a rule book: list every door that opens from the street into the server room
MatchPaths / ExcludePaths
≈
The rule (no street doors to secure rooms) and the approved exception (the reception lobby)
Reachability Analyzer
≈
Asking: can I walk from room A to room B, and if not, which locked door stops me?
Inspector reachability
≈
A guard who walks the building every 12 hours and reports any outside door left open
Automated reasoning
≈
Reading the floor plan instead of trying every door handle
Real AWS example · a scope: no internet path to the data tier
Match IGW → ENIs tagged tier=data; exclude nothing; then read findings.
FindingStatus: true means at least one forbidden path exists; the findings list each hop (IGW, route table, NACL, security group, ENI). Inspector finding titles are illustrative.
Exam-style scenario
A security team must prove every quarter that no network interface in the database subnets of 12 VPCs can be reached from any internet gateway, except the approved bastion path, which is being removed next year. They want a repeatable check that lists every violating path. What should they use?
A. VPC Reachability Analyzer from each internet gateway to each database instance.
B. Network Access Analyzer with a scope that matches internet gateways to the database resources and excludes the bastion path.
C. Amazon Inspector package vulnerability findings.
D. VPC Flow Logs queried in Athena.
Show the worked answer
Answer: B
A scope with MatchPaths and ExcludePaths returns every violating path in one repeatable analysis.
Why not the others
A: One source and destination per run: hundreds of runs and easy to miss paths.
C: Package findings show CVEs, not network paths.
D: Flow logs show traffic that happened, not paths that are possible.
How the exam tests this
“List all paths that break a network rule”→ Network Access Analyzer.
“Why can’t A reach B? Which component blocks it?”→ Reachability Analyzer.
“Automatic open-port findings on EC2”→ Inspector network reachability.
“Approved exception in a scope”→ ExcludePaths.
“Which vulnerable hosts are exposed?”→ Inspector package + reachability findings.
One DX, VPCs in several RegionsDirect Connect gateway
Encrypt dedicated 100 Gbps DX at line rateMACsec with must_encrypt
Encrypt a hosted DX, no public IPsPrivate IP VPN over a transit VIF
Dev VPCs must not reach prod through the hubSeparate TGW route tables + blackhole
Firewall drops return traffic via TGWAppliance mode on the inspection attachment
Per-app access with device posture, no VPNVerified Access
Prove no internet path to data subnetsNetwork Access Analyzer scope
Which component blocks A from reaching B?Reachability Analyzer
Day 3 in one sentence
Build the hybrid link with two of everything, encrypt it because private is not secret, segment it at the transit gateway, let people in one app at a time, and keep checking for paths you never meant to open.
08
Must-remember cheat sheet
1. VPN: 2 tunnels, each in a different AZ.
2. Tunnel 1.25 Gbps; Large Bandwidth Tunnel 5 Gbps.
3. Accelerated VPN: TGW only, NAT-T, set at creation.
4. ECMP on TGW needs BGP.
5. Restrict crypto with tunnel options (IKEv2, AES-256).
6. VIFs: private, public, transit.
7. Transit VIF always goes via a DX gateway.
8. DX gateway: global, no assoc-to-assoc traffic.
9. Direct Connect is not encrypted by default.
10. MACsec: dedicated 10/100/400 Gbps, not hosted.
16. NAA = all bad paths; RA = A→B; Inspector = EC2, 12 h.
09
Core quiz
Check the basics first. Pick an answer, then press Check.
10
Hard quiz
Harder than most real exam questions on purpose, with one “choose two” and one matching question. Aim for 9 out of 12 before Day 4.
11
Practice test questions (from your mock exams)
These 9 questions come from your own SCS-003 mock exams (the last 1 are new questions added in the October 2026 review for features AWS changed in 2025–2026), matched to today’s topics. Each one was checked against current AWS behaviour: where a mock answer used old features (OAI, Classic Load Balancer, Inspector Classic) the wording was updated, and the explanation says so. The source is shown at the end of each explanation, for example “(Mock 5 · Q12)”.
12
Hands-on lab (30 minutes, low cost)
In a test VPC with an internet gateway, launch a small EC2 instance with a security group that allows SSH (22) from 0.0.0.0/0. Tag its security group tier=data.
Open VPC → Network Access Analyzer, select the Amazon-created scope All-IGW-Ingress and run an analysis. Open the finding and read each hop: internet gateway, route table, NACL, security group, network interface.
Open Reachability Analyzer and create a path from the internet gateway to the instance on TCP 22. Note that it is reachable, then remove the SSH rule and run it again: the result now names the security group as the blocking component.
If you have never used Amazon Inspector in this account, activate it (new accounts get a free trial) and, after it has scanned, filter findings by type Network reachability. Compare with the package vulnerability findings for the same instance.
Optional, a few cents: create a transit gateway and a Site-to-Site VPN to it using any public IP as a dummy customer gateway. Open the tunnel options and restrict them to IKEv2 and AES-256, look at the two outside IPs, and download a sample configuration. The tunnels will stay DOWN, which is expected.
Clean up: delete the VPN connection, the transit gateway attachment and the transit gateway (both charge per hour), terminate the instance, and deactivate Inspector before the trial ends. Network Access Analyzer and Reachability Analyzer charge per run, so don’t schedule them in a personal account. Don’t order a Direct Connect connection for practice: port hours and partner fees are real money.