ANS-C01 — Frequently Asked Questions

AWS CloudFormation is AWS-native and only manages AWS resources, while Terraform is cloud-agnostic and supports multiple providers (AWS, Azure, GCP, etc.) via plugins. For the ANS-C01 exam, both are relevant, but Terraform is often emphasized for hybrid/multi-cloud networking scenarios. CloudFormation offers deeper AWS integration (e.g., native support for AWS-specific features like VPC Lattice), while Terraform provides consistent syntax across clouds. The debate centers on whether to use CloudFormation for pure AWS environments (better drift detection, stack sets) versus Terraform for organizations with multi-cloud strategies.

Transit Gateway acts as a central hub supporting thousands of VPC attachments and on-premises connections via Direct Connect/VPN, with centralized route tables and multicast support. VPC Peering is a point-to-point connection limited to 125 peering connections per VPC, requiring full-mesh routing for multi-VPC communication. Transit Gateway simplifies routing by eliminating transitive peering limitations and supports route propagation from VPN/DX. The debate involves cost: Transit Gateway incurs hourly attachment fees plus data processing charges, while VPC Peering is free but operationally complex at scale. For ANS-C01, Transit Gateway is typically the correct answer for >10 VPCs or hybrid connectivity.

AWS Network Firewall is a managed, stateful firewall integrated with VPC flow logs and AWS Firewall Manager, ideal for organizations wanting AWS-native management without appliance licensing. Third-party NGFWs (Palo Alto, Fortinet) offer advanced features like SSL decryption, application-aware filtering, and threat intelligence feeds not available in AWS Network Firewall. Use AWS Network Firewall for basic L3/L4 filtering and compliance; use third-party for deep packet inspection, IDS/IPS, or existing vendor investments. The debate centers on operational overhead: AWS Network Firewall reduces management burden but lacks granular control, while third-party requires HA configuration and license management.

Key considerations include: (1) Deploy inbound Resolver endpoints in AWS to allow on-premises DNS servers to resolve AWS private hosted zones, and outbound endpoints for AWS resources to resolve on-premises names. (2) Use conditional forwarding rules to direct specific domain queries to on-premises DNS servers. (3) Ensure security groups allow UDP/TCP port 53 from trusted sources only. (4) Monitor query volume as Resolver endpoints incur per-query charges. (5) Implement DNSSEC validation if required. The debate involves whether to use Resolver endpoints versus running BIND/Windows DNS on EC2—endpoints are managed but less flexible, while self-managed offers customization at higher operational cost.

Use AWS Verified Access (formerly AWS PrivateLink + ZTNA) or third-party ZTNA solutions integrated with AWS IAM Identity Center. Alternatively, deploy AWS Systems Manager Session Manager for secure shell access without SSH ports, or use AWS Client VPN with device posture checks. For web applications, place them behind Application Load Balancers with AWS WAF and require authentication via Cognito or SAML. Never expose RDP/SSH directly. The debate centers on whether to adopt AWS-native ZTNA (Verified Access) versus established vendors (Zscaler, Cloudflare) that offer broader endpoint coverage and existing policy frameworks.

Use AWS Organizations with Organizational Units (OUs) aligned to business units/environments (Dev, Staging, Prod). Apply Service Control Policies (SCPs) to enforce network guardrails: deny creation of public subnets, restrict VPC CIDR ranges, mandate Transit Gateway attachments, and prevent disabling VPC Flow Logs. Use AWS Firewall Manager to centrally deploy Network Firewall policies across accounts. Tag resources consistently for cost allocation and compliance. The debate involves SCP strictness: overly restrictive SCPs block legitimate innovation, while lenient policies fail to prevent shadow IT. Best practice is layered SCPs with exception processes.

Deploy at least two DX connections (preferably to different DX locations) with separate virtual interfaces. Configure BGP with AS_PATH prepending on the backup link to influence inbound traffic, and use LOCAL_PREF for outbound preference. Enable BFD for fast failure detection (<1s). Use DX Gateway for multi-region/multi-account sharing. Advertise only necessary prefixes and apply prefix lists to prevent accidental transit. The debate centers on active-active vs. active-passive: active-active provides better utilization but requires careful load balancing; active-passive is simpler but wastes bandwidth. Most enterprises prefer active-active with weighted routing.

Global Accelerator uses AWS's private backbone to route TCP/UDP traffic to optimal endpoints, reducing latency by 30-60% for non-HTTP protocols (gaming, IoT, APIs). CloudFront caches content at edge locations and optimizes HTTP/HTTPS delivery with Lambda@Edge. Use GA for stateful, low-latency applications; use CloudFront for static/dynamic web content. GA charges per premium IP and data transfer; CloudFront charges per request and data transfer. The debate involves cost-effectiveness: GA is expensive for high-volume web traffic where CloudFront caching would be cheaper, but GA is irreplaceable for real-time applications needing consistent latency.

Enable VPC Flow Logs (sent to CloudWatch Logs or S3) for packet-level metadata. Use Traffic Mirroring to capture full packets for deep inspection (send to analytics tools). Deploy CloudWatch Network Monitor for synthetic testing. Use Reachability Analyzer to validate network paths without sending traffic. Correlate with CloudTrail for API changes. Set up alarms for abnormal flow patterns. The debate centers on cost vs. visibility: continuous mirroring is expensive, so best practice is on-demand mirroring during incidents. Flow Logs at 1-minute intervals balance detail and cost for most troubleshooting.

Use AWS Application Migration Service (MGN) for lift-and-shift with minimal downtime. Extend on-premises network to AWS using DX/Site-to-Site VPN with overlapping CIDRs handled via NAT or AWS Cloud WAN. Migrate in phases: non-production first, then production with blue-green cutover. Maintain DNS TTLs low during migration. Validate connectivity post-migration before decommissioning on-prem. The debate involves whether to refactor networking during migration (recommended but risky) versus lift-and-shift followed by optimization (safer but delays modernization). Most practitioners advocate hybrid approach: migrate as-is, then re-architect within 90 days.

Use VPC Peering with strict route table controls and security group referencing (peer SG IDs instead of CIDRs). Alternatively, deploy AWS PrivateLink to expose services via ENIs without exposing entire VPCs. For service mesh approaches, use App Mesh or Istio for mTLS between microservices. Never use open CIDR ranges (0.0.0.0/0) in peering routes. The debate centers on scalability: peering becomes unmanageable beyond 10 VPCs, making Transit Gateway or Cloud WAN preferable. PrivateLink is ideal for service-to-service but adds per-hour endpoint costs.

Site-to-Site VPN uses encrypted IPsec tunnels over public internet, suitable for backup links, low-bandwidth needs, or quick setup. Direct Connect provides dedicated private connectivity with predictable latency, SLAs, and higher bandwidth (1G-100G), ideal for production workloads, large data transfers, or compliance requiring private links. VPN is pay-per-hour + data; DX has port fees + data transfer. The debate involves ROI: DX is cost-effective above 1Gbps sustained usage; below that, VPN with compression may suffice. Always pair DX with VPN as backup.

Deploy AWS Network Firewall or third-party NGFW in egress VPC with explicit allowlists for required domains/IPs. Use VPC endpoints for AWS services to avoid internet egress. Configure route tables to force all outbound traffic through inspection VPC. Block RFC1918 ranges and known malicious IPs via threat intelligence feeds. Log all denied traffic for forensics. The debate centers on usability vs. security: strict egress breaks applications unexpectedly, so start with monitoring mode, analyze logs for 2 weeks, then enforce. Use DNS filtering (Route 53 Resolver DNS Firewall) as lightweight complement to packet-level filtering.

AWS Cloud WAN is a managed global network service that automates cross-region connectivity, segmentation, and route propagation without manual TGW peering. It supports multicast, segment isolation, and centralized policy management. Transit Gateway requires manual inter-region peering and lacks native segmentation. Use Cloud WAN for global enterprises with >3 regions needing simplified operations; use TGW for single-region or simple multi-region setups. The debate involves maturity: Cloud WAN is newer with fewer integrations, while TGW has broader ecosystem support. Cost-wise, Cloud WAN includes core network hours + attachment fees, often comparable to TGW at scale.

Use AWS IP Address Manager (IPAM) to centrally allocate, track, and audit IP pools across accounts/regions. Define hierarchical pools (global → regional → account-level) with non-overlapping CIDRs. Automate VPC/subnet creation via IPAM-integrated CloudFormation/Terraform. Reserve ranges for on-premises/hybrid use. Monitor utilization dashboards for exhaustion alerts. The debate centers on IPAM vs. spreadsheets/manual tracking: IPAM eliminates human error but adds learning curve. For >50 VPCs, IPAM is essential; smaller environments may use well-documented conventions.

PrivateLink keeps traffic on AWS backbone, avoiding public internet exposure and reducing attack surface. It enables private access to SaaS providers offering PrivateLink endpoints. Internet Gateway routes traffic publicly, requiring TLS encryption and exposing source IPs. PrivateLink incurs endpoint hourly + data charges; IGW has no additional fee. The debate involves cost-benefit: PrivateLink is worth it for sensitive data/compliance; for non-sensitive public SaaS, IGW with WAF may suffice. Always verify SaaS provider supports PrivateLink before designing around it.

Design DR networking with pre-provisioned standby VPCs in secondary region matching production topology. Use Route 53 health checks and failover routing policies for DNS-level switchover. Replicate stateful network configs (security groups, NACLs, route tables) via IaC. Test failover quarterly. For RTO <15 min, use active-active multi-region with Global Accelerator; for RTO >1 hr, pilot light with automated provisioning suffices. The debate centers on cost of idle DR infrastructure: warm standby balances cost and speed; cold standby saves money but risks configuration drift. Always automate DR validation.

Network Access Analyzer continuously evaluates network configurations against defined scopes to detect unintended access paths (e.g., overly permissive security groups, missing NACLs). It identifies risks before exploitation. Complement with VPC Flow Logs (actual traffic), Security Hub (compliance), and GuardDuty (threat detection). NAA is preventive; others are detective/reactive. The debate involves scope definition: poorly defined scopes generate false positives, causing alert fatigue. Start with critical assets, expand gradually. NAA doesn't replace penetration testing but reduces its frequency.

Implement network segmentation isolating regulated workloads in dedicated VPCs/subnets. Encrypt all data in transit (TLS/IPsec) and at rest. Enable comprehensive logging (Flow Logs, CloudTrail) with tamper-proof storage. Restrict administrative access via bastion hosts/SSM. Use AWS Artifact for compliance documentation. Conduct regular audits. The debate centers on shared responsibility: AWS secures the cloud; customers secure workloads. Misconfiguration voids compliance regardless of AWS certifications. Always engage qualified assessors early in design phase.

Challenges include configuration drift, manual errors in route/security group updates, slow change velocity, and inconsistent tagging. Mitigate with IaC (Terraform/CloudFormation), GitOps workflows (ArgoCD), policy-as-code (OPA/Sentinel), and automated testing (terratest). Use AWS Config Rules for continuous compliance. Centralize networking in platform teams with self-service guardrails. The debate involves autonomy vs. control: excessive centralization slows teams; too much freedom causes chaos. Best practice is paved roads with escape hatches for exceptions.