The Developer Space

0 0

Introduction

In today’s cloud-native world, applications are no longer confined to a single server or data center. They are distributed, scalable, and dynamic. As a developer, understanding how networking works in the cloud is no longer optional; it’s essential. AWS provides a robust set of networking services that empower developers to build secure, high-performance, and resilient applications.

When building on AWS, understanding how your infrastructure communicates is crucial. Every cloud application begins with the network. At the heart of AWS networking is the Virtual Private Cloud (VPC), a logically isolated environment where developers build secure, scalable systems. This part lays the groundwork for everything to come, covering CIDRs, VPCs, Subnets, Route Tables, Security Groups, Network ACLs, Elastic IPs, and Load Balancers. Whether you’re building a monolith or microservices, understanding these components is essential to defining and protecting your infrastructure.

Why Developers Should Care About AWS Networking

As a developer, you might think networking is for DevOps or infrastructure engineers. But in a cloud-first world, understanding AWS networking basics is essential for:

• Designing secure applications
• Debugging connectivity issues
• Setting up CI/CD pipelines correctly
• Scaling applications efficiently

Mastering the AWS networking stack empowers you to build resilient and performant applications with minimal surprises during deployment.

Amazon VPC: Your Virtual Network on AWS

Amazon VPC is the foundational building block of AWS networking, acting as a logically isolated section of the AWS cloud where developers can launch resources in a virtual network they define. Understanding VPC is crucial for developers because every compute resource, whether it’s an EC2 instance, RDS database, or container – resides within a VPC. It allows fine-grained control over networking, including IP address ranges, routing, and access. VPCs interoperate directly with subnets, route tables, internet gateways, and security groups, forming the core of any application deployment on AWS. Without a clear understanding of VPC architecture, developers may run into issues with connectivity, scalability, and security.

An Amazon VPC is region-specific. There is a default VPC in each region in your AWS account. You can create additional VPCs as needed in each of your regions. When you create a VPC, you choose the AWS region in which it resides (e.g., us-east-1, eu-west-1). All the networking resources you create inside the VPC – such as subnets, route tables, and gateways – must also be within the same region. You cannot span a VPC across multiple regions. This regional scope ensures data locality and simplifies regional network architecture.

CIDRs (Classless Inter-Domain Routing)

CIDR defines a block of IP addresses using a combination of an IP and a subnet mask. For example, 10.0.0.0/16. The /16 indicates how many bits are fixed as the network portion, allowing for 65,536 IP addresses in this block. CIDRs are how AWS VPCs and subnets are allocated their IP space, enabling flexible and efficient use of IP addresses. CIDR allows for the aggregation of multiple IP addresses into a single route, which helps reduce the size of routing tables and improves routing efficiency. 

• VPCs are defined using a CIDR block like 10.0.0.0/16.
• Subnets are created by subdividing this block (e.g., 10.0.1.0/24).
• Route tables, Security Groups, and NACLs reference CIDRs to allow or deny traffic.
• CIDRs are crucial in VPC Peering, where overlapping IP ranges are not allowed.
• PrivateLink and Transit Gateway traffic relies on correct CIDR planning to route packets between services and VPCs without collision.

CIDRs are critical when defining your VPC and subnet boundaries. If you misallocate IP ranges, you might run out of usable IPs, block future expansion, or overlap ranges between VPCs, causing routing conflicts. Developers often face deployment issues because of poor CIDR planning. Understanding this helps avoid environment fragmentation and simplifies cross-VPC connectivity.

CIDR Block Reference Table

Note: AWS reserves 5 IPs per subnet (first IP = network, last IP = broadcast, and 3 are reserved by AWS), so always account for this when allocating subnets.

Prefix List

A Prefix List in AWS is a collection of one or more CIDR blocks grouped together under a single, reusable entity. It acts like a named alias for a set of IP address ranges: either AWS-managed or customer-defined, that can be referenced in security groups, route tables, and network ACLs.

Two Types of Prefix Lists:

1. AWS-Managed Prefix Lists
   • Maintained by AWS and updated automatically
   • Represent IP ranges for AWS services like S3, DynamoDB, CloudFront, etc.
   • Example: com.amazonaws.us-east-1.s3 → contains the IPs used by S3 in the US North Virgina region
2. Customer-Managed Prefix Lists
   • Created by users to represent on-premises IPs, partner networks, or shared VPCs
   • Easier to manage multiple firewall rules or route table entries across accounts

Subnets

Subnets are subdivisions of a VPC’s IP address range, enabling developers to logically group resources based on functionality and access requirements.

Subnets are tied to specific Availability Zones within the region of the parent VPC. When creating a subnet, you assign it to one AZ (e.g., us-west-2a). This tight coupling allows developers to distribute resources across multiple AZs for high availability and fault tolerance. A subnet cannot span across multiple AZs or be moved between them.

There are two types of Subnets:

Public Subnets

A public subnet in AWS is a subnet that has a route to an Internet Gateway, allowing resources inside it (like EC2 instances) to communicate directly with the internet. Public subnets are commonly used to host outward-facing services such as web servers, bastion hosts, or load balancers. When you launch an instance in a public subnet and assign it a public IP or Elastic IP, it becomes reachable from the internet – making proper use of Security Groups and Network ACLs essential to avoid exposing vulnerabilities. Developers typically deploy front-end components in public subnets while keeping the rest of the application stack isolated.

Private Subnets

A private subnet, in contrast, is not directly accessible from the internet because it lacks a route to an Internet Gateway. It is used to host backend services like databases, internal APIs, or application servers that shouldn’t be exposed publicly. Instances in a private subnet can still access the internet (for updates or downloading packages) using a NAT Gateway or NAT instance residing in a public subnet. Designing your application with private subnets for sensitive components helps enforce the principle of least exposure, improving overall security posture.

For developers, knowing how to assign resources to the correct subnet ensures that services like RDS, Lambda, and ECS are securely placed and can communicate as intended. Subnets interact with route tables, NAT gateways, and security groups to manage traffic flow and access levels between components.

Recommended Subnet Types for your applications and services

DHCP Option Sets

A DHCP Option Set in AWS is a configuration object that defines how instances in your VPC receive DNS and other network configuration details when they boot up, similar to what a traditional DHCP server provides in on-prem environments.

By default, AWS assigns a DHCP option set to your VPC with:

• domain-name-servers: AmazonProvidedDNS
• domain-name: Region-specific (ec2.internal, us-east-1.compute.internal, etc.)

What It Configures

When an EC2 instance in a VPC starts, it uses the DHCP Option Set to automatically obtain:

Why It Matters for Developers

• Automatic DNS Resolution: Instances use these options to resolve hostnames to IP addresses—crucial for service discovery.
• Custom DNS Support: You can point instances to custom DNS servers (e.g., Active Directory, on-prem DNS) instead of AWS-provided ones.
• Centralized Network Config: Instead of manually configuring each EC2, DHCP options apply automatically across subnets.

Route Tables

Route tables define how traffic is directed within a VPC. Each subnet must be associated with a route table, which contains rules mapping IP ranges to destinations such as internet gateways, NAT gateways, VPC peering connections, or transit gateways. Developers should understand route tables to ensure resources can communicate internally and externally as expected. Misconfigured routes are a common cause of unreachable services. Route tables work in tandem with subnets and gateways to control the flow of data, impacting how microservices, APIs, and third-party services interact in a distributed architecture.

• Each subnet is associated with one route table
• Routes can direct traffic to:
  • Internet Gateway (IGW)
  • NAT Gateway
  • VPC Peering
  • Transit Gateway

Route Table for a Public Subnet

Route Table for a Private Subnet

Key Differences:

• In the private subnet, the default route (0.0.0.0/0) points to a NAT Gateway, not an Internet Gateway.
• This allows outbound internet access (e.g., downloading packages) while preventing direct inbound connections from the internet.

Route tables are region-specific, as they belong to a VPC which is bound to a region. Each subnet in the VPC is associated with a route table that dictates how traffic is routed. While the route table itself is not tied to an AZ, it manages routes for subnets that are.

Security Groups

Security Groups act as virtual firewalls at the instance level, controlling inbound and outbound traffic. They are stateful, meaning if you allow an inbound request, the response is automatically allowed. Developers often configure security groups to control which services or IPs can access application components, databases, or admin interfaces. Misconfiguration here can lead to both security vulnerabilities and inaccessible services. Security Groups work alongside subnets, EC2 instances, load balancers, and even Lambda functions running within a VPC.

Security Groups are regional, scoped to the VPC they are created in. They can be applied to resources (like EC2 or Lambda) in any AZ within that region and VPC. This flexibility allows consistent security policies across distributed resources.

Network ACLs (Access Control Lists)

Network ACLs provide an additional layer of security at the subnet level and are stateless, meaning rules must be explicitly defined for both inbound and outbound traffic. For developers, understanding NACLs becomes important when troubleshooting strange connectivity issues or enforcing stricter security requirements across an entire subnet. They interact with subnets and route tables, ensuring only permitted traffic is allowed at a broader level than Security Groups.

Network ACLs are region-specific and tied to a VPC. They operate at the subnet level, which means they indirectly relate to AZs since each subnet exists in one AZ. You can apply a NACL to multiple subnets across different AZs within the same region.

Security Group vs ACL

Tip: Always start with least-privilege rules and expand based on application needs.

Elastic IPs

Elastic IPs are static public IPv4 addresses that can be associated with EC2 instances, making them accessible from the internet. These are useful when consistent public IPs are required, such as for whitelisting in external systems. Developers must manage EIPs wisely to avoid unnecessary costs or resource limitations. EIPs are commonly used with instances in public subnets, and their accessibility is governed by security groups and route tables.

Load Balancers

Load balancers distribute traffic across multiple targets (like EC2, Lambda, or containers) to increase fault tolerance and scalability. Load balancers often live in public subnets and direct traffic to private ones, bridging the outside world with internal services. They also work closely with target groups, security groups, and auto-scaling groups. Developers should understand how to register targets, configure listeners, and apply rules for routing.

Load balancers are regional, but they span multiple Availability Zones within a region. When you configure a load balancer, you specify which AZs it should operate in. The load balancer then automatically distributes traffic across those AZs for high availability.

AWS offers several load balancing options:

Application Load Balancer (ALB)

An Application Load Balancer (ALB) is a Layer 7 load balancer provided by AWS as part of the Elastic Load Balancing (ELB) service. It is designed to distribute incoming HTTP and HTTPS traffic across multiple targets, such as EC2 instances, containers (ECS), Lambda functions, or IP addresses, based on application-level information like request paths, headers, and query strings.

Key Features of ALB:

• Path-based Routing: Directs traffic to different services based on URL paths (e.g., /api/* vs /images/*).
• Host-based Routing: Routes requests based on the domain name (e.g., api.example.com vs www.example.com).
• Native support for containers: Works seamlessly with ECS (especially with dynamic port mapping).
• HTTP/2 and WebSocket support: Enables modern web communication protocols.
• SSL Termination: Offloads SSL/TLS processing to the ALB to reduce the burden on backend services.
• Sticky Sessions: Maintains session affinity for stateful applications.

Network Load Balancer (NLB)

A Network Load Balancer (NLB) is a Layer 4 load balancer in the AWS Elastic Load Balancing (ELB) family, designed to handle high-performance, low-latency TCP, UDP, and TLS traffic at scale. It operates at the transport layer (OSI Layer 4), routing traffic based on IP address and port rather than application-level information.

Key Features of NLB:

• Preserve Source IP: Unlike ALB, NLB preserves the original client IP, which is essential for applications that require IP-based filtering or logging.
• Ultra-Low Latency: Ideal for applications requiring high-speed packet processing, such as gaming, IoT, or real-time communications.
• Millions of Requests per Second: Designed to handle sudden and volatile traffic patterns at scale.
• Static IP Support: Each NLB can be assigned Elastic IPs per Availability Zone, or use a single DNS name backed by static IPs.
• TLS Termination: Supports TLS offloading at the load balancer to enhance security and reduce backend CPU load.
• Zonal Isolation: Preserves traffic within the same Availability Zone when possible for improved reliability and performance.

Gateway Load Balancer

A Gateway Load Balancer (GWLB) is a specialized type of AWS load balancer that operates at Layer 3 (Network Layer) and is designed to simplify the deployment and scaling of third-party virtual appliances, such as firewalls, intrusion detection/prevention systems (IDS/IPS), deep packet inspection (DPI) tools, and traffic analyzers.

While GWLB is often used by network and security engineers, developers building secure, enterprise-scale cloud applications should understand how it fits into the architecture. If your application traffic must pass through a security stack or be inspected (e.g., for compliance, logging, or policy enforcement), GWLB can be a vital part of the network path. It allows third-party or custom appliances to operate without being tightly coupled to the app code or underlying infrastructure.

What Next?

Grasping the core components of AWS networking equips developers with the tools to design secure and structured cloud environments. From segmenting your workloads with subnets to managing traffic flow using security groups and load balancers, each of these components plays a crucial role. With this foundation, you’re now ready to explore the extended network capabilities AWS offers for hybrid architectures and service integrations – which we’ll cover in the next part.

Related Articles