Networking and the Bill: Where the Surprises Live

The first surprise of AWS is that compute does not arrive connected to anything useful. You are given a virtual network to lay out, and the layout determines what can reach what for the life of the system.

The primitives are few, and they map onto physical networking closely enough to reason about:

• VPC. Your private network within a region, with an address range you choose. Nothing outside it reaches inside except through something you place deliberately.
• Subnets. Slices of that range, each pinned to one availability zone. This is where AZ redundancy becomes concrete: multi-AZ means subnets in several zones.
• Route tables. What each subnet may reach and by which path. The distinction between a public and a private subnet is entirely a routing decision, not a property of the subnet itself.
• Internet gateway. Attached to a VPC to allow traffic to and from the internet.
• NAT gateway. Lets instances in private subnets make outbound connections without being reachable inbound.

Key idea: the default posture is deny. A resource cannot be reached until something you configured permits it, which is the opposite of a physical office network and the reason cloud misconfigurations tend to be things left open on purpose rather than things forgotten.

Traffic control happens at two levels, and knowing which is which saves hours of confused debugging.

Statefulness is the practically important row. With a security group, permitting inbound traffic on a port is enough, because the response is understood to belong to that conversation. With a network ACL, an allowed request whose reply is not separately permitted produces a connection that opens and then hangs, which is one of the more baffling failures in cloud networking until you know to look for it.

In practice: the pattern that scales is to reference security groups from each other rather than listing IP ranges. Saying "the database group accepts traffic from the application group" survives instances being replaced, scaled and re-addressed, whereas a hardcoded list of addresses is stale the moment autoscaling does its job.

One pattern covers the majority of production designs, and recognising it makes most architecture diagrams immediately readable.

The VPC spans a region and contains subnets in at least two availability zones. Public subnets hold only the things that must be reachable from the internet, typically a load balancer. Private subnets hold the application instances or containers, which have no route from the internet at all. A further private tier holds the database, reachable only from the application tier.

Inbound traffic arrives at the load balancer in a public subnet and is forwarded to applications in private subnets. Outbound traffic from those private instances, fetching a package or calling an external API, leaves through a NAT gateway, which permits the connection out without permitting anything in.

The security property is that compromising the application gives an attacker no direct route to the internet and no route to anything the application's security group does not permit. The cost property, which the next step is about, is that the NAT gateway sits in the path of every outbound byte and charges for the privilege.

Cloud pricing has one structural feature that drives more architecture than any other: data moves at wildly different prices depending on which boundary it crosses.

The ordering, which holds across providers even as specific rates change:

• Inbound from the internet: typically free. Providers are happy to receive your data.
• Within one availability zone: typically free or negligible.
• Between availability zones in a region: charged per gigabyte, in both directions.
• Between regions: charged more.
• Out to the internet: the most expensive, and the one that scales with your product's success.

Key idea: in cloud economics, computation is priced roughly as you expect and movement is not. Any design that shuffles large volumes across boundaries has a cost consequence that will not appear in a load test, only in an invoice a month later.

Cost surprises cluster into a short list, and none of them is the compute line people expect to dominate.

The last one has an irony worth noting: observability, which the catalogue covers as its own discipline, is frequently among the largest line items, and cardinality is usually the reason.

In practice: three controls catch most of it. Turn on cost anomaly alerting so an unexpected shape is a notification rather than a month-end discovery. Tag resources by team and environment from the beginning, because retrofitting attribution across an untagged estate is genuinely miserable. And schedule non-production environments off outside working hours, which is often the single largest saving available and requires no architectural change at all.

The useful reframing is that cloud pricing is a set of incentives, and reading it that way lets you predict the shape of a good design rather than memorising rates.

What the pricing model rewards:

• Elasticity, because you pay for what runs. Anything that idles is pure waste, which is why autoscaling and scheduled shutdowns pay so reliably.
• Locality, because movement costs more than storage. Processing data where it already lives beats shipping it somewhere convenient.
• Commitment where demand is predictable, because reserved capacity and savings plans discount steeply for a forecast you were confident about anyway.
• Caching and content delivery, because serving a byte from an edge cache is cheaper than serving it from origin, repeatedly.

And what it punishes: idle provisioned capacity, chatty cross-boundary architectures, storing everything at the hottest tier forever, and estates nobody attributes to a team.

Key idea: treat the bill as a design signal rather than an accounting artefact. A line item growing faster than usage is telling you something about the architecture, most often that data is crossing a boundary more times than the design intended, and it is frequently the earliest available warning that a system's shape has drifted from its plan.

Four lessons, and one repeated pattern: the platform gives you primitives plus defaults, and the defaults are chosen for getting started rather than for the system you are actually building.

What carries over regardless of which services you end up using:

• Regions and availability zones decide latency, resilience and legal exposure, and the region choice is the hardest one to revisit.
• Accounts and IAM decide blast radius, and default-deny with roles rather than long-lived keys is the posture that holds up.
• The compute spectrum trades control for operational relief, and the right answer is the most managed option that does not remove something you need.
• Storage shape follows access pattern, and durability guarantees cover hardware failure while every other loss mechanism is a permissions and process problem.
• Movement costs more than storage, so the network layout is a cost decision as much as a security one.

In practice: the most valuable habit for anyone new to a cloud is to ask, for each new service, what happens when this fails, who can reach it, and what it charges for. Those three questions place a service faster than any documentation tour, and they are the same three questions whichever provider's console you are looking at.