Unit 2: Networking and Connectivity in AWS - Subjective Questions

Amazon VPC is a logically isolated virtual network in AWS in which customers can launch and control AWS resources. It allows control over IP addressing, subnets, routing, gateways, and network security.

Major components include:

• CIDR block: Defines the private or public IP address range assigned to the VPC.
• Subnets: Divide the VPC address range into smaller networks. Each subnet belongs to one Availability Zone.
• Route tables: Determine where network traffic from a subnet or gateway is directed.
• Internet Gateway: Enables communication between resources with public IP addresses and the internet.
• NAT Gateway: Allows resources in private subnets to initiate outbound internet connections without accepting unsolicited inbound traffic.
• Security groups: Stateful virtual firewalls attached to resources such as EC2 instances and network interfaces.
• Network ACLs: Stateless subnet-level filters that support both allow and deny rules.
• VPC endpoints: Provide private connectivity to supported AWS services.
• DHCP options and DNS settings: Control domain-name resolution and related network configuration.

Together, these components create an isolated, routable, and secure AWS network environment.

A /24 network contains:

IPv4 addresses. To create four equal subnets, two additional subnet bits are required because:

Therefore, each subnet has a /26 prefix. A /26 contains:

addresses. AWS reserves the first four addresses and the last address of every subnet, leaving:

usable addresses per subnet.

Subnet plan:

A resilient design could assign these as public and private subnets across two Availability Zones. Future growth must be considered because subnet CIDR blocks cannot be resized after creation.

The classification of a subnet depends primarily on its routing, not simply on whether its resources have public IP addresses.

• Public subnet:

  • Its route table contains a route to an Internet Gateway, commonly 0.0.0.0/0.
  • A resource also requires a public IPv4 address or Elastic IP address to communicate through the Internet Gateway over IPv4.
  • Commonly contains internet-facing load balancers, bastion hosts, or NAT Gateways.

• Private subnet:

  • Does not have a direct route to an Internet Gateway.
  • May use a NAT Gateway for outbound internet access.
  • Commonly contains application servers, containers, and internal load balancers.

• Isolated subnet:

  • Has no route to an Internet Gateway or NAT device.
  • Communicates only through local routes, private connectivity, or explicitly configured endpoints.
  • Commonly contains highly sensitive databases or internal services.

A multi-tier application often places load balancers in public subnets, application servers in private subnets, and databases in isolated subnets.

Route tables contain destination-and-target rules that control the path taken by network traffic. Every subnet is associated with one route table, either explicitly or through the VPC's main route table.

For a public subnet:

• Attach an Internet Gateway to the VPC.
• Add a route such as 0.0.0.0/0 targeting the Internet Gateway.
• Give internet-facing resources public IPv4 addresses or Elastic IP addresses.

For a private subnet:

• Deploy a NAT Gateway in a public subnet and assign it an Elastic IP address.
• Add 0.0.0.0/0 in the private subnet's route table with the NAT Gateway as the target.
• The NAT Gateway forwards outbound traffic through the public subnet's Internet Gateway.
• Unsolicited inbound internet connections cannot be initiated through the NAT Gateway.

For Availability Zone resilience, a common design deploys one NAT Gateway per Availability Zone and routes each private subnet to the NAT Gateway in the same zone. This reduces cross-zone dependency and can reduce cross-zone data processing.

A security group is a stateful virtual firewall associated with supported resources, primarily through their elastic network interfaces.

Important characteristics:

• It operates at the resource or network-interface level.
• It contains separate inbound and outbound rules.
• Rules specify protocol, port range, and source or destination.
• It supports allow rules only; explicit deny rules are not supported.
• It is stateful. If a request is allowed, its response traffic is automatically allowed regardless of outbound rules.
• Multiple security groups can be associated with a resource, and their rules are combined.
• Rules can reference CIDR ranges, prefix lists, or other security groups where supported.

Example: An application server security group may allow TCP port 443 only from the security group of an Application Load Balancer. This is safer than permitting port 443 from all internet addresses.

Security groups should follow the principle of least privilege by exposing only required protocols, ports, and sources.

A Network Access Control List is an optional stateless security layer applied at the subnet boundary. It filters traffic entering and leaving every subnet with which it is associated.

Operation:

• A NACL has separate inbound and outbound rules.
• Rules support both allow and deny actions.
• Rules are evaluated in ascending rule-number order.
• Evaluation stops as soon as a matching rule is found.
• The final asterisk rule denies traffic that has not matched an earlier rule.
• Each subnet is associated with one NACL, while one NACL may be associated with multiple subnets.

Because NACLs are stateless, request and response traffic must both be explicitly permitted. For example, if inbound HTTPS is allowed to a server, the outbound NACL must also allow the relevant client-side ephemeral port range for response traffic.

NACLs are useful for subnet-wide guardrails, such as blocking known malicious IP ranges, but overly restrictive rules can unintentionally interrupt legitimate return traffic.

Defense-in-depth example:

1. A NACL permits web traffic to public subnets but denies traffic from a known malicious CIDR range.
2. The load balancer security group allows HTTPS from approved client networks.
3. The application security group accepts application traffic only from the load balancer security group.
4. The database security group accepts the database port only from the application security group.

This layered approach limits both external exposure and lateral movement. However, each layer must be tested carefully because restrictive NACL return-path rules can cause failures even when security-group rules are correct.

A secure and highly available three-tier design should use at least two Availability Zones.

Recommended design:

• Create one VPC with non-overlapping CIDR space and sufficient room for growth.
• In each Availability Zone, create:
  • A public subnet for an internet-facing Application Load Balancer and NAT Gateway.
  • A private application subnet for EC2 instances, containers, or other application compute.
  • An isolated database subnet for a Multi-AZ database.
• Attach an Internet Gateway and route only public subnets directly to it.
• Route private application subnets through a same-zone NAT Gateway when outbound internet access is required.
• Give database subnets no default route to the internet.

Security controls:

• Load balancer security group: allow HTTPS from approved clients or the internet.
• Application security group: allow the application port only from the load balancer security group.
• Database security group: allow the database port only from the application security group.
• Use restrictive NACLs as subnet-level guardrails where justified.
• Use VPC endpoints for private access to services such as Amazon S3, Systems Manager, and CloudWatch.
• Enable VPC Flow Logs and centralized monitoring.

This design improves availability, separates trust zones, minimizes public exposure, and follows least-privilege principles.

A VPC endpoint enables resources in a VPC to access supported AWS services privately without requiring an Internet Gateway, NAT Gateway, public IP address, VPN, or Direct Connect path to a public service endpoint.

Gateway endpoints:

• Supported for Amazon S3 and Amazon DynamoDB.
• Added as targets in selected subnet route tables.
• Use AWS-managed prefix lists representing the destination service.
• Do not create endpoint network interfaces in subnets.
• Can be controlled with endpoint policies and resource policies.

Interface endpoints:

• Powered by AWS PrivateLink.
• Create elastic network interfaces with private IP addresses in selected subnets.
• Support many AWS services, partner services, and customer-created endpoint services.
• Use security groups to control access to endpoint interfaces.
• Can use private DNS so normal regional service names resolve to private endpoint addresses.
• Generally involve hourly and data-processing charges.

Both endpoint types reduce exposure to the public internet and can simplify private connectivity to managed AWS services.

AWS PrivateLink provides private connectivity through interface endpoints. A gateway endpoint provides private route-table-based connectivity specifically to Amazon S3 or DynamoDB.

Use a gateway endpoint when:

• Workloads need private access to Amazon S3 or DynamoDB.
• Route-table-based access is appropriate.
• The goal is to avoid using NAT for these services.
• Access can be governed through endpoint policies, bucket policies, or DynamoDB policies.

Use PrivateLink or an interface endpoint when:

• The required AWS service supports interface endpoints.
• A service provider wants to expose an application privately without peering entire networks.
• Consumers must access a service using private IP addresses.
• Overlapping consumer and provider CIDR ranges make routed VPC connectivity unsuitable.
• Security-group control on endpoint interfaces is required.

PrivateLink is service-oriented and does not provide general network-to-network connectivity. Gateway endpoints are simpler for S3 and DynamoDB but cannot be used as a general-purpose mechanism for other services.

Private workloads can connect to managed services through several patterns, depending on how the service exposes its endpoint.

For services supporting VPC endpoints:

• Use a gateway endpoint for Amazon S3 or DynamoDB.
• Use an interface endpoint for supported services such as AWS Systems Manager or Secrets Manager.
• Enable private DNS for interface endpoints when appropriate so standard service domain names resolve to endpoint private IP addresses.
• Apply endpoint policies to limit allowed services, resources, and operations.
• Restrict interface endpoint security groups to approved workload sources.

For managed resources deployed in a VPC:

• Services such as Amazon RDS create network interfaces in selected subnets.
• Place them in private or isolated subnets.
• Use security groups to allow traffic only from the application tier.
• Use subnet groups spanning multiple Availability Zones for resilience.

Additional controls:

• Configure resource policies, IAM permissions, and encryption in addition to network controls.
• Avoid broad default routes when a private endpoint is sufficient.
• Use Route 53 Resolver features for hybrid DNS requirements.
• Monitor traffic with VPC Flow Logs and service-specific audit logs.

VPC peering creates private IP connectivity between two VPCs. Resources in the connected VPCs can communicate as if they were part of a broader private network, subject to routes and security controls.

Configuration requirements:

1. The VPC CIDR ranges must not overlap.
2. A peering request must be created and accepted by the peer owner.
3. Route tables on both sides must contain routes to the peer CIDR through the peering connection.
4. Security groups and NACLs must permit the required traffic.
5. DNS resolution options may need to be enabled when private DNS names must resolve across the peer.

Use cases:

• Connecting application and shared-services VPCs.
• Connecting VPCs belonging to different AWS accounts.
• Enabling private inter-Region communication through inter-Region peering.
• Supporting a small number of direct VPC-to-VPC relationships.

Traffic remains on the AWS network. However, peering is a one-to-one relationship and does not provide transitive routing.

VPC peering has several important limitations:

• No transitive routing: If VPC A peers with VPC B and VPC B peers with VPC C, VPC A cannot reach VPC C through VPC B.
• No overlapping CIDRs: Peering cannot be established between VPCs whose primary or relevant secondary CIDR ranges overlap.
• Explicit routing: Each participating route table must contain appropriate routes to the peer CIDR.
• No edge-to-edge routing: A VPC generally cannot use another VPC's Internet Gateway, NAT Gateway, VPN, or Direct Connect gateway merely through a peering connection.
• One-to-one relationships: Every pair requiring direct communication needs its own peering connection.

For VPCs in a full mesh, the maximum number of peer relationships is:

For example, ten fully connected VPCs require peering connections. Route tables, security controls, ownership, and troubleshooting therefore become increasingly complex. AWS Transit Gateway is often preferred when many VPCs require centralized or transitive connectivity.

AWS Transit Gateway is a regional network transit hub that connects multiple VPCs, VPNs, and supported hybrid-network attachments through a centralized routing service.

Transit Gateway characteristics:

• Supports transitive routing between approved attachments.
• Uses Transit Gateway route tables to control connectivity and segmentation.
• Can connect many VPCs without building a full peering mesh.
• Supports Site-to-Site VPN and Direct Connect integration through appropriate architectures.
• Supports inter-Region peering between Transit Gateways.
• Simplifies centralized inspection, shared services, and hybrid connectivity.

Comparison:

VPC peering may be preferred for a small number of VPCs needing direct connectivity. Transit Gateway is generally better for scalable, centralized, and segmented enterprise networks.

AWS Site-to-Site VPN creates encrypted IPsec tunnels between an on-premises network and AWS over the internet.

Main components:

• Customer Gateway: Represents the customer-side VPN device and its public IP address in AWS configuration.
• AWS-side gateway: Typically a Virtual Private Gateway attached to a VPC or a Transit Gateway used as a central hub.
• VPN connection: Contains the tunnel configuration, encryption parameters, and routing details.

Routing options:

• Static routing: Administrators manually define the networks reachable through the VPN.
• Dynamic routing: Border Gateway Protocol exchanges routes automatically and adapts more effectively to topology changes.

High availability:

• Each AWS Site-to-Site VPN connection normally provides two VPN tunnels terminating on separate AWS endpoints.
• The customer should configure and monitor both tunnels.
• Multiple customer devices or VPN connections may be used to reduce dependency on a single on-premises device or ISP.

The VPN provides encryption in transit but its performance and latency are influenced by internet conditions.

AWS Direct Connect provides a dedicated network connection from an organization's premises or colocation environment to AWS. It bypasses the public internet for the data path and provides more consistent network performance.

Key concepts:

• A physical connection is established at a Direct Connect location, directly or through a partner.
• Private virtual interfaces provide access to VPC resources through supported gateway configurations.
• Public virtual interfaces provide access to AWS public service endpoints using public IP addressing.
• Transit virtual interfaces can connect to multiple VPCs through a Direct Connect Gateway and Transit Gateway architecture.
• Border Gateway Protocol is used to exchange routes.

Suitable circumstances:

• Large or predictable data-transfer requirements.
• Applications requiring more consistent latency and bandwidth than internet-based VPNs.
• Hybrid data-center, migration, backup, or analytics workloads.
• Organizations seeking a private, dedicated data path to AWS.

Direct Connect does not encrypt traffic by default. Encryption can be added using mechanisms such as an IPsec VPN over suitable connectivity or MAC Security where supported. Redundant connections and locations are recommended for critical workloads.

Resilient architecture:

1. Provision Direct Connect connections at separate Direct Connect locations where business requirements justify this level of resilience.
2. Use diverse customer routers, providers, and physical paths to reduce correlated failures.
3. Establish virtual interfaces through the required Direct Connect Gateway and gateway architecture.
4. Configure Site-to-Site VPN as an encrypted backup path.
5. Use Border Gateway Protocol route preferences so Direct Connect is normally preferred and VPN routes are used after a failure.
6. Monitor tunnel state, BGP sessions, packet loss, latency, and connection health.
7. Test failover regularly rather than assuming route convergence will work as intended.

For requirements involving encrypted primary connectivity, an organization may use an encryption solution over Direct Connect where supported while retaining VPN paths for backup.

VPC Flow Logs capture metadata about IP traffic going to and from network interfaces in a VPC. They can be created at the VPC, subnet, or network-interface level.

Typical recorded fields include:

• Source and destination IP addresses.
• Source and destination ports.
• Protocol number.
• Number of packets and bytes.
• Start and end times.
• Network-interface identifier.
• Traffic action, such as ACCEPT or REJECT.

Destinations may include:

• Amazon CloudWatch Logs.
• Amazon S3.
• Amazon Data Firehose where supported.

Uses:

• Troubleshooting security-group and NACL rules.
• Identifying rejected connections.
• Detecting unusual communication patterns.
• Supporting incident investigation and traffic analysis.
• Estimating traffic volume between network zones.

Limitations: Flow Logs record metadata rather than packet payloads. They are not a replacement for packet capture, application logs, DNS logs, or intrusion-detection tools. Some traffic types and fields may require special configuration or may not be captured as expected.

An effective strategy combines metrics, logs, configuration analysis, and active testing.

Monitoring tools:

• Amazon CloudWatch: Monitor VPN tunnel status, NAT Gateway metrics, Transit Gateway metrics, load balancer health, packet drops, and other service metrics.
• VPC Flow Logs: Analyze accepted and rejected network flows.
• CloudTrail: Audit changes to route tables, security groups, NACLs, gateways, and endpoints.
• Route 53 Resolver query logs: Investigate DNS requests and resolution issues.
• AWS Config: Detect configuration drift and evaluate network resources against compliance rules.
• Reachability Analyzer: Analyze whether a network path is reachable and identify the blocking component.
• Network Access Analyzer: Identify network paths that violate defined access requirements.
• Transit Gateway Network Manager or related network-management capabilities: Visualize and monitor large hybrid networks where applicable.

Troubleshooting sequence:

1. Confirm DNS resolution.
2. Verify source and destination addresses and ports.
3. Check routes in both directions.
4. Check security-group rules.
5. Check inbound and outbound NACL rules, including ephemeral ports.
6. Inspect Flow Logs and service metrics.
7. Validate gateway, VPN, BGP, or endpoint health.
8. Correlate failures with recent CloudTrail configuration changes.

Alerts and dashboards should be centralized and linked to documented operational runbooks.

A production network should be reviewed across the relevant AWS Well-Architected pillars.

Operational excellence:

• Define the network using infrastructure as code.
• Standardize naming, tagging, IP allocation, and route management.
• Maintain diagrams, runbooks, and automated change validation.
• Test failure and recovery procedures.

Security:

• Apply least-privilege security-group and endpoint policies.
• Separate public, private, and isolated tiers.
• Use private endpoints instead of public paths where practical.
• Enable Flow Logs, CloudTrail, DNS logging, and configuration monitoring.
• Encrypt data in transit and centralize inspection when required.

Reliability:

• Distribute workloads and subnets across multiple Availability Zones.
• Avoid single NAT devices, VPN devices, or physical connections for critical systems.
• Use redundant VPN tunnels and Direct Connect paths.
• Plan non-overlapping CIDR ranges and test route convergence.

Performance efficiency:

• Select appropriate connection types and bandwidth.
• Keep latency-sensitive communication close to workloads.
• Monitor packet loss, latency, throughput, and capacity.

Cost optimization:

• Analyze NAT Gateway, cross-zone, endpoint, Transit Gateway, and data-transfer costs.
• Use gateway endpoints for suitable S3 and DynamoDB traffic.
• Remove unused endpoints, gateways, and connections.

Sustainability:

• Avoid overprovisioned network resources.
• Reduce unnecessary data movement and duplicate processing.
• Prefer managed services and efficient architectures.

The review should produce measurable actions, responsible owners, priorities, and recurring reassessment dates.