AWS SysOps Networking: Complete Study Guide

Q: What's the difference between Security Groups and Network ACLs, and when should I use each?

Security Groups and Network ACLs both provide network-level security but operate differently. Security Groups are stateful firewalls at the instance level. If you allow inbound traffic, responses flow automatically without explicit rules. They default to deny-all inbound and allow-all outbound. NACLs are stateless firewalls at the subnet level. You need explicit rules for both inbound and outbound traffic. They default to allow-all. Security Groups are more commonly used for most workloads. Their stateful nature simplifies rule creation significantly. Use NACLs for blocking specific traffic at the subnet level. Use them when you need explicit control over all traffic directions. For the SysOps exam, remember that Security Groups are the primary security mechanism. NACLs provide an additional security layer. Most production architectures rely on Security Groups for security control, using NACLs only when specific subnet-level restrictions are needed.

Q: Which load balancer should I use for my application, and how do I configure health checks properly?

Choose the load balancer based on your requirements. Use ALB for HTTP/HTTPS applications needing path or hostname-based routing. This includes web apps, APIs, and microservices. Use NLB for extreme performance, millions of requests per second, or non-HTTP protocols. Examples include gaming, IoT, and DNS. Use CLB only for legacy applications needing basic load balancing. Health checks are critical for automatic failover. Configure them with: Healthy protocol and port Path for HTTP/HTTPS checks Interval between checks (default 30 seconds) Timeout for response (default 5 seconds) Healthy/unhealthy thresholds A target becomes unhealthy after consecutive failed checks equal to the unhealthy threshold. It returns to healthy after consecutive successful checks equal to the healthy threshold. Example: A web server health check uses HTTP protocol on port 80 with path /health every 30 seconds, timing out after 5 seconds, with thresholds of 2 unhealthy and 3 healthy checks. Ensure your application responds quickly to health checks. Avoid expensive operations in health check paths, as frequent checks can impact performance if not configured properly.

Q: What are VPC Flow Logs and how do I use them to diagnose network problems?

VPC Flow Logs capture metadata about network traffic flowing through your VPC. They enable deep troubleshooting of connectivity issues. Flow Logs record: Source IP and destination IP Source port and destination port Protocol type Number of bytes and packets Timestamps Accept/reject status for each flow You can enable Flow Logs at the VPC, subnet, or elastic network interface level. They deliver data to CloudWatch Logs or S3. The logs show whether traffic was accepted or rejected. This helps identify whether Security Groups, NACLs, or routing is causing issues. For example, rejected ACCEPT entries indicate successful connections. REJECT entries show blocked traffic. Analyze log patterns to identify unexpected traffic sources or destinations. Use CloudWatch Insights to query Flow Logs efficiently with commands like filtering for rejected packets or counting traffic by port. Flow Logs typically appear within minutes but aren't real-time. They're invaluable for security investigations, capacity planning, and troubleshooting multi-tier application communication. Remember that Flow Logs incur CloudWatch or S3 charges based on data volume. Plan accordingly for high-traffic environments.

Q: How does Route 53 failover work, and how do I implement disaster recovery with it?

Route 53 failover routing enables automatic redirection to secondary resources when primary resources become unhealthy. Configure a primary resource with a health check. If the health check fails, Route 53 automatically directs new DNS queries to the secondary resource. Health checks can monitor: HTTP/HTTPS endpoints TCP connections Calculated health based on other health checks CloudWatch alarms Set up the primary as a failover routing policy with a resource identifier. Set health check to an HTTP endpoint on your primary application server. Then create a secondary failover record pointing to your backup resource. When the primary health check fails a specified number of times (typically 1-3 checks), DNS queries redirect to the secondary. This enables active-passive disaster recovery where traffic automatically fails over. For more sophisticated scenarios, use failover with weighted routing to gradually shift traffic. Implement active-active failover with latency-based routing across regions. Test failover by simulating primary resource failure to verify secondary activation. Remember that DNS failover has latency. Clients cache DNS responses, so TTL values affect failover speed. Use lower TTLs for faster failover, understanding that lower TTLs increase DNS query volume.

By FluentFlash Research Team·Updated 2026-04-30

AWS SysOps networking is essential for the AWS Certified SysOps Administrator exam. You'll master Virtual Private Clouds (VPCs), load balancing, DNS management, and network security.

Networking forms the backbone of AWS infrastructure management. Understanding these concepts directly impacts your ability to deploy, manage, and operate AWS systems at scale.

This guide covers fundamental networking concepts, real-world applications, and why flashcard learning works for complex configurations. You'll learn troubleshooting procedures and architectural best practices that matter in production environments.

Key Takeaways

•VPC architecture forms the networking foundation: master CIDR blocks, subnets, route tables, Internet Gateways, and NAT Gateways to design scalable and secure networks
•Security Groups and NACLs provide complementary security layers: Security Groups are stateful instance-level firewalls while NACLs are stateless subnet-level firewalls requiring explicit bidirectional rules
•Choose load balancers based on requirements: ALB for Layer 7 application routing, NLB for extreme performance and non-HTTP protocols, and configure health checks with appropriate intervals and thresholds
•Route 53 enables intelligent traffic management through multiple routing policies including failover for disaster recovery, geolocation for regional targeting, and latency-based routing for optimal user experience
•VPC Flow Logs provide critical visibility into network traffic for troubleshooting connectivity issues, security investigations, and capacity planning by capturing source/destination IPs, ports, and accept/reject status
•Connect multiple VPCs and on-premises networks using VPC Peering for same-region connectivity, Site-to-Site VPN for encrypted hybrid connections, or Direct Connect for dedicated high-performance links

Understanding VPC Architecture and Components

A Virtual Private Cloud (VPC) is your isolated network environment in AWS. You have complete control over IP addressing, subneting, routing, and security within your VPC.

VPC Fundamentals

Each VPC is defined by a CIDR block, such as 10.0.0.0/16. This determines the range of private IP addresses available to you. You divide the VPC CIDR block further into subnets. For example, 10.0.1.0/24 and 10.0.2.0/24 are two separate subnets.

Spread subnets across different Availability Zones for redundancy and high availability.

Connectivity and Traffic Management

Internet Gateways (IGWs) enable communication between your VPC and the internet. NAT Gateways allow instances in private subnets to initiate outbound connections without exposing them to inbound internet traffic.

Route tables define how traffic flows within your VPC. A route table entry specifies a destination CIDR block and where traffic should go. Local traffic stays within the VPC. Traffic for the internet goes through the IGW.

Security Layers

Network Access Control Lists (NACLs) provide stateless firewall rules at the subnet level. Security Groups operate at the instance level with stateful rules. Both work together to protect your infrastructure.

Multi-Tier Architecture Pattern

Typical production setups use three tiers:

Public subnets for web servers (connected to IGW)
Private subnets for application servers (use NAT for outbound)
Isolated subnets for databases (no internet access)

Mastering these components and their interactions is fundamental to passing the SysOps exam and managing production AWS environments effectively.

Load Balancing Strategies and Application Delivery

AWS offers three primary load balancing services. Each serves different use cases and operates at different network layers.

Choosing the Right Load Balancer

The Application Load Balancer (ALB) operates at Layer 7. It routes based on hostnames, paths, and HTTP headers. This makes it ideal for microservices and containerized applications. Route requests to api.example.com to one target group and www.example.com to another, both behind the same ALB.

The Network Load Balancer (NLB) operates at Layer 4. It handles millions of requests per second with ultra-high performance and low latency. Use it for gaming, IoT, and real-time applications.

The Classic Load Balancer (CLB) is the older option. It's still relevant for legacy applications requiring basic load balancing across instances.

Health Checks and Target Management

Each load balancer uses target groups containing EC2 instances, containers, or IP addresses. Health checks determine whether targets are healthy and receive traffic.

Configure health check parameters:

Path for the health check endpoint
Check interval (how often to test)
Timeout (how long to wait for response)
Healthy threshold (consecutive passes to mark healthy)
Unhealthy threshold (consecutive failures to mark unhealthy)

Traffic Distribution Features

Sticky sessions maintain connection affinity to specific targets. This is useful for applications with session state.

Cross-Zone Load Balancing distributes traffic evenly across all Availability Zones. This improves fault tolerance significantly.

For the SysOps exam, understand when to use each load balancer type. Learn how to configure health checks, manage target groups, and troubleshoot common issues like unhealthy targets or uneven traffic distribution. Proper load balancing ensures high availability and fault tolerance in production environments.

DNS Management with Route 53 and Network Resolution

Amazon Route 53 is AWS's managed DNS and domain registration service. It controls how traffic reaches your applications and is essential for production systems.

Routing Policies for Traffic Control

Route 53 supports multiple routing policies beyond simple round-robin:

Simple routing directs traffic to a single resource
Weighted routing distributes traffic by percentage across resources
Latency-based routing sends users to the geographically closest endpoint
Geolocation routing directs based on actual user location
Failover routing automatically redirects to a secondary resource when primary fails
Traffic flow policies create complex routing rules visually
Multivalue answer routing provides load balancing without a load balancer

Health Checks and Failover

Understanding health checks within Route 53 is vital for the SysOps exam. You configure health checks to monitor endpoints and trigger failover automatically when issues arise.

Internal DNS and Service Discovery

DNS resolution within VPCs uses Amazon-provided DNS resolvers by default. You can associate custom Route 53 private hosted zones for internal DNS.

This enables service discovery in microservices architectures. Applications find dependencies by hostname rather than hardcoded IP addresses.

VPC DNS resolution settings control behavior:

enableDnsHostnames allows instances to receive public DNS names
enableDnsSupport enables DNS resolution

Integration and Performance

Route 53 integrates with ALBs and NLBs through alias records. Alias records map to AWS resources without additional charges.

Understand DNS caching and TTL (Time To Live) values. Changing TTLs affects failover scenarios significantly. Lower TTLs enable faster failover but increase DNS query volume.

Network Security: Security Groups and NACLs

Network security in AWS operates at two levels: Security Groups and Network Access Control Lists (NACLs). Both are essential for protecting your infrastructure.

Security Groups: Stateful Instance-Level Firewalls

Security Groups are stateful firewalls at the instance level. If you allow inbound traffic on port 443, the corresponding outbound response is automatically allowed without explicit rules.

Each Security Group contains inbound and outbound rules specifying:

Protocol type
Port range
Source or destination

An example inbound rule allows TCP traffic on port 80 from 0.0.0.0/0 (anywhere). Another allows SSH on port 22 from a specific IP range.

You can reference other Security Groups in rules. This enables dynamic security based on application tiers.

NACLs: Stateless Subnet-Level Firewalls

NACLs operate at the subnet level and are stateless. You need explicit rules for both inbound and outbound traffic.

NACL rules process in order by rule number. The first matching rule applies. Unlike Security Groups that default to deny-all, NACLs include default allow rules for all traffic.

Understanding Ephemeral Ports

When a client initiates a connection, the OS assigns a temporary ephemeral port for the response. NACLs must allow these ephemeral ports (typically 1024-65535) for return traffic to flow correctly.

Troubleshooting with VPC Flow Logs

VPC Flow Logs capture network traffic metadata. They're invaluable for troubleshooting connectivity issues. Flow Logs record:

Source and destination IP
Port information
Protocol type
Bytes and packets transferred
Accept/reject status

For the SysOps exam, design security group rules for multi-tier architectures. Understand NACL stateless behavior versus Security Group stateful behavior. Use Flow Logs to diagnose network problems effectively. This knowledge directly impacts production security posture and incident response capabilities.

Advanced Networking: VPC Peering, VPN, and Direct Connect

As AWS infrastructure grows, connecting multiple VPCs and on-premises networks becomes necessary. AWS provides several connectivity options.

VPC Peering for Direct VPC-to-VPC Connection

VPC Peering creates private connections between VPCs in the same or different AWS regions. Instances communicate using private IP addresses without traversing the internet.

Establish peering connections and update route tables to direct traffic destined for the peer VPC through the peering connection.

Important constraints include no transitive peering (peered VPCs cannot route through each other) and CIDR block overlap prevention. Requires careful route table management at scale.

Site-to-Site VPN for Hybrid Cloud

AWS Site-to-Site VPN creates encrypted connections between your on-premises data centers and AWS VPCs. This enables hybrid cloud architectures.

A VPN consists of:

Virtual Private Gateway (VGW) in the VPC
Customer Gateway on your on-premises network
IPsec tunnels encrypting traffic

AWS recommends having two tunnels for redundancy. You control routing through route propagation or static routes.

Direct Connect for Dedicated Connections

AWS Direct Connect provides dedicated network connections bypassing the public internet entirely. It offers consistent network performance and lower latency for large data transfers or latency-sensitive applications.

Direct Connect involves physical connections at AWS facilities, making setup more complex. However, it provides superior performance and security.

Transit Gateway for Complex Topologies

AWS Transit Gateway serves as a central hub for connecting multiple VPCs, on-premises networks, and remote offices. It simplifies complex network topologies significantly.

For the SysOps exam, understand the differences between these connectivity options. Learn their performance characteristics, use cases, and how to troubleshoot connectivity issues. Real-world production environments often combine these technologies to balance performance, security, cost, and reliability.

Start Studying AWS SysOps Networking

Master VPC architecture, load balancing, DNS management, and network security with interactive flashcards designed specifically for the AWS Certified SysOps Administrator exam. Create custom study decks to focus on your weak areas and study efficiently.

Create Free Flashcards

Frequently Asked Questions

What's the difference between Security Groups and Network ACLs, and when should I use each?

Security Groups and Network ACLs both provide network-level security but operate differently. Security Groups are stateful firewalls at the instance level. If you allow inbound traffic, responses flow automatically without explicit rules.

They default to deny-all inbound and allow-all outbound.

NACLs are stateless firewalls at the subnet level. You need explicit rules for both inbound and outbound traffic. They default to allow-all.

Security Groups are more commonly used for most workloads. Their stateful nature simplifies rule creation significantly.

Use NACLs for blocking specific traffic at the subnet level. Use them when you need explicit control over all traffic directions.

For the SysOps exam, remember that Security Groups are the primary security mechanism. NACLs provide an additional security layer. Most production architectures rely on Security Groups for security control, using NACLs only when specific subnet-level restrictions are needed.

How do I troubleshoot connectivity issues between EC2 instances in different VPCs?

When instances in different VPCs cannot communicate, follow a systematic approach.

First, verify the VPC Peering connection exists and is in the active state. Use the AWS Console or CLI to check.

Second, check route tables in both VPCs. Ensure they have routes directing traffic to the peer VPC CIDR block through the peering connection.

Third, examine Security Group rules on both instances. They must allow traffic on necessary ports from the peer VPC CIDR block.

Fourth, check NACLs on both subnets. Confirm they allow both inbound and outbound traffic.

Fifth, enable VPC Flow Logs to capture actual network traffic and identify where packets are being dropped.

Use the ip route command on Linux instances to verify instance-level routing.

Common mistakes include forgetting to update route tables, using instance IP ranges instead of VPC CIDR blocks in Security Group rules, or having NACLs deny ephemeral port ranges. Document the exact connectivity requirements before troubleshooting to ensure comprehensive rule creation.

Which load balancer should I use for my application, and how do I configure health checks properly?

Choose the load balancer based on your requirements.

Use ALB for HTTP/HTTPS applications needing path or hostname-based routing. This includes web apps, APIs, and microservices.

Use NLB for extreme performance, millions of requests per second, or non-HTTP protocols. Examples include gaming, IoT, and DNS.

Use CLB only for legacy applications needing basic load balancing.

Health checks are critical for automatic failover. Configure them with:

Healthy protocol and port
Path for HTTP/HTTPS checks
Interval between checks (default 30 seconds)
Timeout for response (default 5 seconds)
Healthy/unhealthy thresholds

A target becomes unhealthy after consecutive failed checks equal to the unhealthy threshold. It returns to healthy after consecutive successful checks equal to the healthy threshold.

Example: A web server health check uses HTTP protocol on port 80 with path /health every 30 seconds, timing out after 5 seconds, with thresholds of 2 unhealthy and 3 healthy checks.

Ensure your application responds quickly to health checks. Avoid expensive operations in health check paths, as frequent checks can impact performance if not configured properly.

What are VPC Flow Logs and how do I use them to diagnose network problems?

VPC Flow Logs capture metadata about network traffic flowing through your VPC. They enable deep troubleshooting of connectivity issues.

Flow Logs record:

Source IP and destination IP
Source port and destination port
Protocol type
Number of bytes and packets
Timestamps
Accept/reject status for each flow

You can enable Flow Logs at the VPC, subnet, or elastic network interface level. They deliver data to CloudWatch Logs or S3.

The logs show whether traffic was accepted or rejected. This helps identify whether Security Groups, NACLs, or routing is causing issues.

For example, rejected ACCEPT entries indicate successful connections. REJECT entries show blocked traffic.

Analyze log patterns to identify unexpected traffic sources or destinations. Use CloudWatch Insights to query Flow Logs efficiently with commands like filtering for rejected packets or counting traffic by port.

Flow Logs typically appear within minutes but aren't real-time. They're invaluable for security investigations, capacity planning, and troubleshooting multi-tier application communication. Remember that Flow Logs incur CloudWatch or S3 charges based on data volume. Plan accordingly for high-traffic environments.

How does Route 53 failover work, and how do I implement disaster recovery with it?

Route 53 failover routing enables automatic redirection to secondary resources when primary resources become unhealthy.

Configure a primary resource with a health check. If the health check fails, Route 53 automatically directs new DNS queries to the secondary resource.

Health checks can monitor:

HTTP/HTTPS endpoints
TCP connections
Calculated health based on other health checks
CloudWatch alarms

Set up the primary as a failover routing policy with a resource identifier. Set health check to an HTTP endpoint on your primary application server. Then create a secondary failover record pointing to your backup resource.

When the primary health check fails a specified number of times (typically 1-3 checks), DNS queries redirect to the secondary. This enables active-passive disaster recovery where traffic automatically fails over.

For more sophisticated scenarios, use failover with weighted routing to gradually shift traffic. Implement active-active failover with latency-based routing across regions.

Test failover by simulating primary resource failure to verify secondary activation. Remember that DNS failover has latency. Clients cache DNS responses, so TTL values affect failover speed. Use lower TTLs for faster failover, understanding that lower TTLs increase DNS query volume.