Networking fundamentals

The OSI model and where AWS’s responsibility sits

Layer	Name	Example	Responsibility
7	Application	HTTP, a web browser	Customer
6	Presentation	TLS, compression	Customer
5	Session	Setup, negotiation, teardown	Customer
4	Transport	TCP, UDP	Customer
3	Network	IP, ARP	Customer
2	Data link	MAC addressing	AWS
1	Physical	Cabling, optics, radio	AWS

The line falls between layers 2 and 3: AWS owns the physical plant and the link layer, and the customer configures everything from IP addressing upwards. The boundary is not perfectly sharp — virtual constructs such as an Elastic Network Interface have a MAC address you can see but not choose, and a load balancer terminates TLS on your behalf.

TLS sits on top of TCP rather than replacing it. A request travels down as application data, then TLS records, then TCP segments, then IP packets.

Protocols

TCP is connection-oriented and stateful. The endpoints establish a session, every segment is acknowledged, and lost segments are retransmitted. Web traffic, database connections and SSH all use it.

A typical exchange: a server listens on port 80. A client opens a connection from an ephemeral source port — say 56784 — to port 80. The server replies to port 56784. The session stays open, so a second request from the same client reuses it rather than repeating the handshake.

UDP is connectionless and stateless. Datagrams are sent without acknowledgement and may arrive out of order or not at all. Streaming media, DNS and QUIC-based traffic use it, because a late packet is worth less than a missing one is costly.

A typical exchange: the client asks over TCP for a video stream, and the server then pushes a continuous run of UDP datagrams to the client’s port with no per-packet reply.

ICMP carries control and diagnostic messages between network devices. ping and traceroute are built on it, as is Path MTU Discovery. Security groups and network ACLs treat ICMP as a protocol in its own right, so blocking “all traffic except TCP” silently breaks path MTU discovery.

Ephemeral ports

An ephemeral port is the short-lived source port a client picks for an outbound connection. The exact range depends on the operating system; Linux commonly uses 32768–60999, Windows and many other stacks use 49152–65535, and Elastic Load Balancing uses 1024–65535.

This matters for network ACLs, which are stateless: an inbound rule allowing port 443 is not enough, because the reply leaves from port 443 to the client’s ephemeral port and needs a matching outbound rule. Security groups are stateful and handle the return traffic automatically. Because the range varies by client, a network ACL that must allow return traffic generally has to allow 1024–65535.

Reserved addresses in a subnet

Five addresses in every VPC subnet are reserved and cannot be assigned. In a subnet 10.0.0.0/24 they are 10.0.0.0 (network address), 10.0.0.1 (the VPC router), 10.0.0.2 (the Amazon DNS resolver), 10.0.0.3 (reserved for future use) and 10.0.0.255 (broadcast). The positions are relative to the subnet, so in 10.0.4.0/24 the reserved five are 10.0.4.0 to 10.0.4.3 and 10.0.4.255. Only the .2 address of the VPC’s primary CIDR block actually answers DNS — in a 10.0.0.0/16 VPC that is 10.0.0.2, whichever subnet the query comes from; 10.0.4.2 is reserved but is not a resolver. See network and broadcast addresses.

Availability Zone names are per account

The mapping from an Availability Zone name such as us-west-2a to the physical data centre it denotes is chosen independently for each AWS account. Two accounts that both deploy to us-west-2a may well be in different buildings.

AWS does this so that customers who default to the first zone in the list do not all land in the same facility. The consequence is that you cannot coordinate placement across accounts by zone name. Use the Availability Zone ID (usw2-az1 and similar) instead, which is consistent across every account.

Certificate validation

Validating a TLS certificate is more than checking the signing chain. A complete check covers:

1. Chain of trust — verify the signing hierarchy.
2. Expiry — is the certificate still within its validity window?
3. Revocation — has it been revoked, via CRL or OCSP?
4. Hostname — does a name in the certificate match the host being contacted?
5. Cryptographic verification — are the signatures valid?
6. Key usage — is the certificate authorised for this purpose?

The chain of trust step walks upwards:

Website certificate
    signed by
Intermediate CA certificate
    signed by
Root CA certificate
    trusted by
Browser or OS trust store

The client checks that the site certificate was signed by the intermediate, that the intermediate was signed by the root, that the root is present in the trust store, and that every signature in the chain verifies. A server that presents its own certificate but omits the intermediate produces the classic “works in one browser, fails in another” symptom, because some clients cache intermediates and others do not.