Lesson 2: The Standard Connectivity Profile

Why you need a profile before you pick a service

In Level 1 you saw the whole AWS networking catalogue on one page. The catalogue doesn't tell you which service to use. Experienced network engineers don't start a design by asking "Transit Gateway or peering?" They start by asking what the workload actually needs. The connectivity profile is one written page that answers that question. In every later lesson you'll score a service against it, so time spent here pays back for the rest of the course.

You can treat the profile like a building survey. You don't choose beams until you know the loads, the span and the local regulations.

The fields, and what makes them useful

Each field needs a measurable target. A target like "fast" can't be tested. A target like "p95 under 120 ms from London" can.

Gotcha: an availability figure only means something once you turn it into minutes. A 730-hour month has 43,800 minutes. At 99.9% you're allowed about 43.8 minutes of downtime a month. At 99.99% you're allowed about 4.4 minutes, which rules out manual failover.

North-south vs east-west

• North-south traffic crosses the edge of your environment: users reaching your app, your servers calling outside APIs, on-premises links.
• East-west traffic stays inside: app server to database, one service calling another, VPC to VPC.

The split matters because the two directions are priced differently and are protected by different tools. Here's a worked example for ShopFast, a two-AZ web shop:

# shopfast-profile.yaml: keep this in the repo next to the IaC
workload: shopfast
regions: [eu-west-2]
azs: 2                       # app and database are spread across 2 AZs
flows:
  - name: users-to-web       # north-south, inbound
    direction: north-south
    protocol: HTTPS/443
    monthly_gb_out: 2000     # pages and images sent back to users
  - name: app-to-payments-api  # north-south, outbound via NAT
    direction: north-south
    protocol: HTTPS/443
    monthly_gb_processed: 300
  - name: app-to-db          # east-west, about half of it crosses AZs
    direction: east-west
    protocol: TCP/5432
    monthly_gb_cross_az: 500
targets:
  latency_p95_ms: 120
  availability: "99.9%"
  failover: "lose 1 AZ, no manual action"

How do you get the GB numbers? For an existing system, read VPC Flow Logs or last month's bill. For a new one, multiply: requests per month × average response size. For example, 4 million page views × 0.5 MB is about 2,000 GB.

The three buckets of a networking bill

Almost every networking charge on AWS fits into one of three buckets:

1. Hourly charges. You pay these for something existing, even when it's idle: NAT gateways, Transit Gateway attachments, VPN connections, public IPv4 addresses.
2. Per-GB processing charges. You pay these for data passing through a managed device, such as a NAT gateway or a Transit Gateway.
3. Data transfer charges. You pay these for data moving somewhere: out to the internet, or across AZs or Regions.

One gigabyte can land in more than one bucket. Traffic leaving through a NAT gateway is charged for processing and for internet egress.

Example list prices (us-east-1, checked October 2026; other Regions differ):

Here's the ShopFast estimate as a script you can rerun whenever the profile changes:

HOURS = 730  # average hours in a month

hourly = {
    "nat_gateways": 2 * HOURS * 0.045,   # one per AZ for resilience
    "public_ipv4":  4 * HOURS * 0.005,   # 2 NAT EIPs + 2 load balancer IPs (example)
}
processing = {
    "nat_data": 300 * 0.045,             # payments API traffic
}
transfer = {
    "internet_egress": (2000 - 100) * 0.09,  # after the 100 GB free allowance
    "cross_az": 500 * 0.01 * 2,              # billed on both send and receive
}
for name, bucket in [("hourly", hourly), ("processing", processing), ("transfer", transfer)]:
    print(f"{name:<11} ${sum(bucket.values()):8.2f}")

hourly      $   80.30
processing  $   13.50
transfer    $  181.00

In this example, data transfer is the biggest bucket, which is common for anything that serves users. The NAT gateways cost $65.70 before they move a single byte. (Load balancer charges come in a later lesson.)

Check your estimate against the real bill

Once the workload is running, group last month's costs by usage type and compare them with the profile:

# Group last month's EC2-Other costs (where NAT and data transfer appear) by usage type
aws ce get-cost-and-usage \
  --time-period Start=2026-09-01,End=2026-10-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["EC2 - Other"]}}' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE

Usage types containing NatGateway-Hours are hourly charges. NatGateway-Bytes is processing. DataTransfer-Regional-Bytes is cross-AZ transfer. If the real numbers are far from your estimate, your flow table is wrong, so fix the profile first.

Best practice: date every price in the profile and record the Region. Prices change, and a profile without dates leads to stale decisions.

Trade-off: a second NAT gateway doubles the hourly charge, but it's what makes "lose one AZ, no manual action" true. Availability targets and cost targets pull against each other. The profile makes that tension visible so you can decide it on purpose.

Key takeaways

• The connectivity profile is a one-page, reusable record that every later service choice is scored against.
• Every field needs a measurable target: a percentile and location for latency, Mbps and GB/month for bandwidth, a percentage and failover behaviour for availability.
• North-south traffic crosses your edge; east-west traffic stays inside. Estimate monthly GB for each flow.
• Every networking bill splits into hourly, per-GB processing and data transfer charges, and one GB can be charged in more than one bucket.
• Turn availability into minutes: 99.9% is about 43.8 minutes a month.
• Date and Region-tag every price, and check the estimate against Cost Explorer once the workload runs.