Мережа
Навіщо це
Section titled “Навіщо це”Помилки в мережі дорогі двічі. Хибне правило маршрутизації лишає базу даних відкритою в інтернет або, навпаки, відрізає застосунок від неї. А правильна за логікою схема може коштувати кілька сотень доларів на місяць лише за те, що байти проходять через NAT-шлюз і між зонами доступності.
Друге зазвичай дивує більше. У хмарі вхідний трафік безкоштовний, а вихідний оплачується за кожен гігабайт: від $0.087 до $0.12 за ГБ у інтернет. Через це схема мережі визначає й витрати: від неї залежить, де розумно ставити сервіси, щоб трафік між ними не виходив за межі зони.
Передумови. Регіони й зони доступності (модуль 1), ролі (модуль 3), інстанси й сервіс метаданих (модуль 4). Мережеві принципи (IP, TCP, порти) вважаються відомими.
Віртуальна мережа
Section titled “Віртуальна мережа”Віртуальна мережа є ізольованим адресним простором, у якому живуть ваші ресурси: AWS називає її VPC (Virtual Private Cloud), Azure VNet (Virtual Network), GCP теж VPC. Ви вибираєте діапазон адрес із приватних блоків (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) у нотації CIDR, ділите його на підмережі й підключаєте ресурси.
Головна відмінність між провайдерами полягає в межах мережі.
| AWS | Azure | GCP | |
|---|---|---|---|
| Віртуальна мережа | VPC, регіональна | VNet, регіональна | VPC, глобальна |
| Підмережа | в одній зоні доступності | в межах регіону, охоплює всі зони | регіональна, охоплює всі зони регіону |
| Маршрути | таблиці маршрутів на підмережу | таблиці маршрутів (UDR) на підмережу | глобальні на мережу |
| Резервує адрес у підмережі | 5 | 5 | 4 |
У GCP одна VPC охоплює весь світ: підмережі в us-central1 і europe-west1 належать
одній мережі, бачать одна одну за внутрішніми адресами й не потребують пірингу.
В AWS і Azure мережа прив’язана до регіону, і з’єднання двох регіонів треба
будувати окремо (див. розділ про пірінг). Тому «одна мережа на компанію» в
GCP природна, а в AWS і Azure зазвичай означає десятки мереж.
Діапазони треба планувати заздалегідь. Дві мережі з перетинними CIDR не можна з’єднати пірингом, тож 10.0.0.0/16 у кожному новому проєкті дає проблему тоді, коли їх доведеться об’єднати. Практика: єдиний реєстр діапазонів на компанію і блок під кожне середовище й регіон.
Підмережі і маршрутизація
Section titled “Підмережі і маршрутизація”Підмережу називають публічною, якщо її таблиця маршрутів відправляє
0.0.0.0/0 у шлюз в інтернет, і приватною, якщо ні. Ніякого прапорця
«публічна» в ресурсу немає: різницю створює маршрут. Щоб ресурс справді
був досяжним з інтернету, потрібні ще й публічна адреса та дозвіл у правилах
фільтрації, тому «публічна підмережа» ще нічого не відкриває.
Маршрутизація однакова скрізь: пакет іде за найспецифічнішим збігом.
Маршрут до власної мережі (10.0.0.0/16 → local) створюється автоматично, а
0.0.0.0/0 збирає все решта. У GCP маршрут за замовчуванням до інтернету
створюється разом із мережею, а видимість вирішують зовнішні адреси ВМ.
В AWS і Azure явна конфігурація потрібна для кожної підмережі.
Вихід в інтернет і NAT
Section titled “Вихід в інтернет і NAT”Ресурсу в приватній підмережі з інтернетом часто треба поговорити самому: завантажити оновлення, викликати зовнішній API. Публічної адреси в нього немає, тому потрібна трансляція адрес (NAT). NAT-шлюз (NAT gateway) замінює приватну адресу відправника на свою публічну, а відповіді повертає назад. Ініціювати з’єднання ззовні через нього не можна.
- AWS NAT gateway розміщується в публічній підмережі конкретної зони, потребує
Elastic IP, і приватна таблиця маршрутів веде на нього
0.0.0.0/0. Одна зона доступності не має користуватися шлюзом іншої: збій зони вимкне все. Тому для стійкості шлюз ставлять у кожній зоні. - Azure NAT Gateway прив’язується до підмережі й отримує публічні IP. Раніше нові ВМ мали «неявний вихідний доступ»; для нових VNet, створених через API версії після 31 березня 2026, підмережі приватні за замовчуванням, і вихід потрібно налаштовувати явно (Terraform на старій версії API поводиться по-старому).
- GCP Cloud NAT не є пристроєм у мережі: це програмна функція на маршрутизаторі (Cloud Router), що виконується в самій інфраструктурі. Окремого вузла, який би міг стати вузьким місцем, немає, а обмеженням служать порти на кожну ВМ.
NAT коштує як за час існування, так і за кожен гігабайт, який через нього пройшов, тому дешевше уникати його там, де можна. Найчастіший спосіб — приватні ендпоінти до сервісів провайдера (нижче).
Фільтрація трафіку
Section titled “Фільтрація трафіку”Фільтри мережі відрізняються тим, чи пам’ятають вони з’єднання.
Stateful-фільтр (з відстеженням стану) запам’ятовує дозволений вхідний запит і автоматично дозволяє відповідь. Достатньо відкрити порт 443 на вхід: відповіді клієнтові підуть самі. Stateless-фільтр перевіряє кожен пакет окремо, тому для відповіді потрібне окреме правило на зворотний шлях, зазвичай на тимчасові порти клієнта (1024–65535).
| AWS security group | AWS NACL | Azure NSG | GCP firewall rules | |
|---|---|---|---|---|
| Стан | stateful | stateless | stateful | stateful |
| Прив’язка | до інтерфейсу ресурсу | до підмережі | до підмережі або інтерфейсу | до мережі; ціль за тегом або сервісним акаунтом |
| Дозвіл і заборона | лише дозволи | і те, і те | і те, і те | і те, і те |
| Порядок | усі правила разом | за номером, перший збіг | за пріоритетом (100–4096) | за пріоритетом, менше значення важливіше |
| Типова поведінка | вхід закрито, вихід відкрито | стандартна NACL дозволяє все | вхід із мережі дозволено, з інтернету закрито | вхід закрито, вихід відкрито |
Особливість security group в тому, що джерелом правила може бути інша група: «застосунок приймає 8080 лише від групи балансувальника». Адреси при цьому не згадуються, тож правило переживає масштабування. У GCP цю роль виконують мережеві теги або сервісні акаунти, в Azure групи безпеки застосунків (application security groups).
Стандартна практика: основна фільтрація на stateful-рівні, NACL лишають за замовчуванням або використовують як грубу межу підмережі. Помилка stateless-правила виглядає як «з’єднання зависає»: SYN пройшов, SYN-ACK на тимчасовий порт повернутися не може.
З’єднання мереж
Section titled “З’єднання мереж”Пірінг (peering) з’єднує дві мережі за приватними адресами через магістраль провайдера, без шлюзів і VPN. Він не транзитивний: якщо A з’єднано з B, а B з C, то A з C не з’єднано. Число пар зростає квадратично, тому для десятків мереж використовують хаб: AWS Transit Gateway, Azure Virtual WAN або hub-and-spoke із Virtual Network Manager, GCP Network Connectivity Center. Хаб бере плату за кожне приєднання й за оброблений трафік.
З’єднання з власним датацентром йде через VPN (шифрований тунель через інтернет) або виділену лінію: AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect. Виділена лінія дає стабільну затримку й дешевший вихідний трафік, але її встановлення займає тижні.
Приватні ендпоінти
Section titled “Приватні ендпоінти”Сервіси провайдера (сховище, черги, API) за замовчуванням мають публічні адреси. Ваш застосунок у приватній підмережі дістається їх через NAT, тобто через інтернет і за гроші. Приватний ендпоінт (private endpoint) дає такому сервісу адресу всередині вашої мережі.
- AWS: gateway endpoint для S3 і DynamoDB безкоштовний і додається в таблицю маршрутів; interface endpoint (PrivateLink) коштує за годину на кожну зону й за гігабайт.
- Azure: Private Endpoint (Private Link) є мережевим інтерфейсом із приватною адресою сервісу; service endpoints дешевші, але адреса сервісу лишається публічною.
- GCP: Private Google Access дозволяє ВМ без зовнішньої адреси звертатися до API Google безкоштовно; Private Service Connect дає адресу всередині вашої мережі.
Ендпоінт до сховища одночасно закриває шлях витоку даних (див. модуль 6) і прибирає трафік із NAT.
Кожна мережа має вбудований розпізнавач імен. Він розв’язує внутрішні імена
ресурсів (ip-10-0-1-5.ec2.internal, у GCP vm.us-central1-a.c.проєкт.internal) і
передає решту публічному DNS. Адреса розпізнавача в AWS — друга адреса
підмережі (VPC+2), в Azure 168.63.129.16, в GCP 169.254.169.254.
Власні імена задаються зонами. Публічна зона відповідає всьому інтернету,
приватна лише з вибраних мереж: так db.internal.example.com веде на внутрішню
адресу, а поза мережею не існує (split-horizon). Сервіси: Route 53, Azure DNS з
Private DNS zones, Cloud DNS. Окрім записів, DNS уміє маршрутизувати: зважені,
геолокаційні записи й failover за перевіркою стану; на цьому будується
перемикання між регіонами.
DNS кешується за TTL. Зміна запису поширюється не миттєво, і «переключення DNS» під час аварії займає TTL, а часом і довше, бо клієнти ігнорують малі TTL. Тому для швидкого перемикання використовують балансувальник, а DNS лишають на грубі рішення.
Балансувальники
Section titled “Балансувальники”Балансувальник навантаження (load balancer) розподіляє запити між кількома бекендами й перевіряє їхній стан. Рівень визначає, що він бачить.
Балансувальник L4 працює з TCP і UDP: швидкий, підходить для будь-якого протоколу, зберігає адресу клієнта. Балансувальник L7 працює з HTTP: завершує TLS, маршрутизує за хостом і шляхом, переписує заголовки, підключає WAF.
| AWS | Azure | GCP | |
|---|---|---|---|
| L4, регіональний | Network Load Balancer | Load Balancer | Network Load Balancer |
| L7, регіональний | Application Load Balancer | Application Gateway | regional external Application Load Balancer |
| L7, глобальний | CloudFront + ALB, Global Accelerator (L4, anycast) | Front Door | global external Application Load Balancer |
| Балансування на DNS | Route 53 routing policies | Traffic Manager | Cloud DNS routing policies |
Знову різниця GCP: глобальний Application Load Balancer має одну anycast-адресу, приймає клієнтів у найближчій точці Google і спрямовує на найближчий регіон із вільними бекендами. У AWS і Azure аналог складається з кількох сервісів.
CDN (content delivery network) кешує відповіді в edge-локаціях біля користувача. Перший запит іде на джерело (origin), наступні віддає кеш. Виграш подвійний: менша затримка для клієнта й менший вихідний трафік із джерела, за який ви платите. Сервіси: Amazon CloudFront, Azure Front Door, Cloud CDN. Кеш працює за ключем (URL і вибрані заголовки): зайві варіації в ключі, як-от cookie, руйнують частку влучань, і CDN перестає економити.
Вихідний трафік як архітектурне обмеження
Section titled “Вихідний трафік як архітектурне обмеження”Ціна залежить від того, куди йде трафік.
| Напрямок | AWS us-east-1 | Azure eastus | GCP us-central1 |
|---|---|---|---|
| Вхід із інтернету | $0 | $0 | $0 |
| В межах зони | $0 | $0 | $0 |
| Між зонами одного регіону | $0.01 у кожному напрямку | $0 | $0.01 |
| Між регіонами США | $0.02 | $0.02 | $0.02 |
| В інтернет, перший ТБ | $0.09 | $0.087 | $0.12 |
Ціни за ГБ (у GCP за ГіБ), станом на вересень 2026. У AWS і Azure перші 100 ГБ на місяць безкоштовні, у GCP перший ГіБ. AWS бере плату за міжзонний трафік із обох сторін, тож 1 ГБ між зонами коштує $0.02, GCP бере $0.01 лише з відправника.
Це дає обмеження, які видно в архітектурі:
- Сервіси, що багато спілкуються, вигідно тримати в одній зоні, але це суперечить відмовостійкості. Компроміс залежить від обсягу: 10 ТБ на місяць між двома сервісами в різних зонах AWS коштує близько $200, в GCP близько $100.
- Дані «мають масу»: далеко переносити їх дорого, тому обчислення ставлять до даних.
- Публічні відповіді вигідно віддавати через CDN, а не напряму з інстансів.
- Логи й метрики, які експортуються до стороннього сервісу, також є вихідним трафіком.
- Система на двох хмарах платить вихідний тариф за кожну міжхмарну взаємодію.
Як це в трьох хмарах
Section titled “Як це в трьох хмарах”| Функція | AWS | Azure | GCP |
|---|---|---|---|
| Віртуальна мережа | VPC | Virtual Network | VPC (глобальна) |
| Вихід у інтернет | Internet Gateway, NAT Gateway | NAT Gateway, публічні IP | Cloud NAT, зовнішні IP |
| Фільтр, stateful | security group | NSG | firewall rules |
| Фільтр, stateless | NACL | немає окремого (NSG stateful) | немає (правила stateful) |
| Пірінг | VPC Peering | VNet Peering | VPC Network Peering |
| Хаб | Transit Gateway | Virtual WAN | Network Connectivity Center |
| Приватний доступ до сервісів | PrivateLink, gateway endpoints | Private Link | Private Service Connect, Private Google Access |
| DNS | Route 53 | Azure DNS | Cloud DNS |
| CDN | CloudFront | Front Door | Cloud CDN |
Чим це відрізняється і що з цього випливає. Глобальна VPC у GCP означає, що багаторегіональну систему можна будувати в одній мережі з одним набором правил, тоді як в AWS і Azure кожен регіон потребує власної мережі, пірингу чи хаба й окремих правил. Друга різниця стосується фільтрів: в AWS два рівні (security group на ресурсі, NACL на підмережі), в Azure і GCP один рівень stateful-правил із пріоритетами. Третя різниця в NAT: AWS і Azure беруть за годину роботи шлюзу й за гігабайт, GCP бере плату за кількість ВМ, тому для малої системи Cloud NAT дешевший.
Приклад нижче будує мережу з двома підмережами й NAT. В AWS і Azure це по сім типів ресурсів, у GCP чотири, і мережа GCP при цьому одразу охоплює два регіони.
resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" enable_dns_support = true enable_dns_hostnames = true
tags = { Name = "main" }}
resource "aws_subnet" "public" { vpc_id = aws_vpc.main.id cidr_block = "10.0.1.0/24" availability_zone = "us-east-1a" map_public_ip_on_launch = true}
resource "aws_subnet" "private" { vpc_id = aws_vpc.main.id cidr_block = "10.0.2.0/24" availability_zone = "us-east-1a"}
resource "aws_internet_gateway" "igw" { vpc_id = aws_vpc.main.id}
resource "aws_eip" "nat" { domain = "vpc"}
resource "aws_nat_gateway" "nat" { allocation_id = aws_eip.nat.id subnet_id = aws_subnet.public.id depends_on = [aws_internet_gateway.igw]}
resource "aws_route_table" "public" { vpc_id = aws_vpc.main.id
route { cidr_block = "0.0.0.0/0" gateway_id = aws_internet_gateway.igw.id }}
resource "aws_route_table" "private" { vpc_id = aws_vpc.main.id
route { cidr_block = "0.0.0.0/0" nat_gateway_id = aws_nat_gateway.nat.id }}
resource "aws_route_table_association" "public" { subnet_id = aws_subnet.public.id route_table_id = aws_route_table.public.id}
resource "aws_route_table_association" "private" { subnet_id = aws_subnet.private.id route_table_id = aws_route_table.private.id}resource "azurerm_resource_group" "net" { name = "rg-net-demo" location = "eastus"}
resource "azurerm_virtual_network" "main" { name = "vnet-main" address_space = ["10.0.0.0/16"] location = azurerm_resource_group.net.location resource_group_name = azurerm_resource_group.net.name}
resource "azurerm_subnet" "public" { name = "public" resource_group_name = azurerm_resource_group.net.name virtual_network_name = azurerm_virtual_network.main.name address_prefixes = ["10.0.1.0/24"]}
resource "azurerm_subnet" "private" { name = "private" resource_group_name = azurerm_resource_group.net.name virtual_network_name = azurerm_virtual_network.main.name address_prefixes = ["10.0.2.0/24"] default_outbound_access_enabled = false}
resource "azurerm_public_ip" "nat" { name = "pip-nat" location = azurerm_resource_group.net.location resource_group_name = azurerm_resource_group.net.name allocation_method = "Static" sku = "Standard"}
resource "azurerm_nat_gateway" "nat" { name = "natgw" location = azurerm_resource_group.net.location resource_group_name = azurerm_resource_group.net.name sku_name = "Standard"}
resource "azurerm_nat_gateway_public_ip_association" "nat" { nat_gateway_id = azurerm_nat_gateway.nat.id public_ip_address_id = azurerm_public_ip.nat.id}
resource "azurerm_subnet_nat_gateway_association" "private" { subnet_id = azurerm_subnet.private.id nat_gateway_id = azurerm_nat_gateway.nat.id}resource "google_compute_network" "main" { name = "main" auto_create_subnetworks = false}
resource "google_compute_subnetwork" "us" { name = "us" region = "us-central1" network = google_compute_network.main.id ip_cidr_range = "10.0.1.0/24" private_ip_google_access = true}
resource "google_compute_subnetwork" "eu" { name = "eu" region = "europe-west1" network = google_compute_network.main.id ip_cidr_range = "10.1.1.0/24" private_ip_google_access = true}
resource "google_compute_router" "us" { name = "us-router" region = "us-central1" network = google_compute_network.main.id}
resource "google_compute_router_nat" "us" { name = "us-nat" router = google_compute_router.us.name region = google_compute_router.us.region nat_ip_allocate_option = "AUTO_ONLY" source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"}Тепер правило фільтрації: застосунок приймає порт 8080 лише від балансувальника, а балансувальник приймає 443 з інтернету.
variable "vpc_id" { type = string}
resource "aws_security_group" "lb" { name = "lb" vpc_id = var.vpc_id}
resource "aws_security_group" "app" { name = "app" vpc_id = var.vpc_id}
resource "aws_vpc_security_group_ingress_rule" "lb_https" { security_group_id = aws_security_group.lb.id cidr_ipv4 = "0.0.0.0/0" from_port = 443 to_port = 443 ip_protocol = "tcp"}
resource "aws_vpc_security_group_ingress_rule" "app_from_lb" { security_group_id = aws_security_group.app.id referenced_security_group_id = aws_security_group.lb.id from_port = 8080 to_port = 8080 ip_protocol = "tcp"}
resource "aws_vpc_security_group_egress_rule" "app_all" { security_group_id = aws_security_group.app.id cidr_ipv4 = "0.0.0.0/0" ip_protocol = "-1"}variable "resource_group_name" { type = string}
variable "subnet_id" { type = string}
resource "azurerm_network_security_group" "app" { name = "nsg-app" location = "eastus" resource_group_name = var.resource_group_name
security_rule { name = "allow-https" priority = 100 direction = "Inbound" access = "Allow" protocol = "Tcp" source_port_range = "*" destination_port_range = "443" source_address_prefix = "Internet" destination_address_prefix = "*" }}
resource "azurerm_subnet_network_security_group_association" "app" { subnet_id = var.subnet_id network_security_group_id = azurerm_network_security_group.app.id}variable "network" { type = string}
resource "google_compute_firewall" "allow_https" { name = "allow-https" network = var.network direction = "INGRESS" priority = 1000 source_ranges = ["0.0.0.0/0"] target_tags = ["lb"]
allow { protocol = "tcp" ports = ["443"] }}
resource "google_compute_firewall" "app_from_lb" { name = "app-from-lb" network = var.network direction = "INGRESS" source_tags = ["lb"] target_tags = ["app"]
allow { protocol = "tcp" ports = ["8080"] }}В Azure приклад демонструє лише правило для інтернету; правило «лише від балансувальника»
задається джерелом із групи безпеки застосунків (source_application_security_group_ids).
Побачити правила, які реально діють на ресурс, можна командами:
aws ec2 describe-security-groups \ --query 'SecurityGroups[].{Name:GroupName,Id:GroupId}' --output tableaws ec2 describe-route-tables \ --query 'RouteTables[].Routes[].[DestinationCidrBlock,GatewayId,NatGatewayId]' --output tableaz network nsg list --query '[].{Name:name,Rules:securityRules[].name}' -o jsonaz network nic list-effective-nsg --resource-group RG --name NIC_NAMEgcloud compute firewall-rules list \ --format='table(name,network,direction,priority,sourceRanges.list(),targetTags.list())'gcloud compute routes list --format='table(name,destRange,nextHopGateway,nextHopInstance)'Скільки це коштує
Section titled “Скільки це коштує”Станом на вересень 2026, з офіційних сторінок цін провайдерів (Amazon VPC, Elastic Load Balancing, Transit Gateway, Azure Retail Prices API, Google Cloud VPC network pricing і Cloud NAT). Регіони: us-east-1, eastus, us-central1.
| Позиція | AWS | Azure | GCP |
|---|---|---|---|
| NAT-шлюз, за годину | $0.045 | $0.045 | $0.0014 за ВМ, стеля ≈ $0.045 при 32 ВМ |
| NAT-шлюз, за оброблений ГБ | $0.045 | $0.045 | $0.045 (за ГіБ) |
| NAT-шлюз, за місяць без трафіку (730 год) | $32.85 | $32.85 | $1.02 за 1 ВМ, $32.70 за 32 |
| Публічна IPv4, за годину | $0.005 | $0.005 (Standard static) | $0.005 (IP Cloud NAT) |
| L7-балансувальник, за годину | ALB $0.0225 + $0.008 за LCU-год | Application Gateway v2 $0.20 + $0.008 за CU-год | $0.025 за 5 правил пересилання |
| L4-балансувальник, за годину | NLB $0.0225 + $0.006 за NLCU-год | Load Balancer Standard $0.025 | те саме правило пересилання |
| Приватний ендпоінт, за годину | $0.01 на зону | $0.01 | $0.01 (Private Service Connect) |
| Приватний ендпоінт, за ГБ | $0.01 | $0.01 | без плати за дані для API Google |
| Transit-хаб | TGW: $0.05 за приєднання-год, $0.02 за ГБ | Virtual WAN | Network Connectivity Center |
| DNS, публічна зона | $0.50 за місяць, $0.40 за млн запитів | не звірено | не звірено |
Плата за оброблений трафік балансувальників і інші дрібні складники залежать від профілю навантаження, і для оцінки потрібен калькулятор провайдера. Ціни вихідного трафіку — у таблиці розділу «Вихідний трафік як архітектурне обмеження» вище.
Мінімальна мережа з одним NAT-шлюзом в AWS коштує $32.85 за місяць лише за годину роботи шлюзу і $3.65 за його публічну адресу. Якщо шлюз стоїть у кожній із трьох зон, як радять для стійкості, це $98.55 плюс $10.95 за адреси, до першого байта трафіку.
Розбір: 1 ТБ через NAT
Section titled “Розбір: 1 ТБ через NAT”Розглянемо застосунок AWS у приватній підмережі, який щомісяця завантажує 1 ТБ (1000 ГБ) з S3 і відправляє 1 ТБ у зовнішній API. Схема проста, і рахунок за неї складається так.
Завантаження з S3 через NAT. Передача даних із S3 до EC2 в тому самому регіоні безкоштовна, але шлях іде через NAT-шлюз. Шлюз бере $0.045 за кожен оброблений ГБ: 1000 ГБ × $0.045 = $45 на місяць за трафік, який без шлюзу не коштував би нічого. Gateway endpoint для S3 безкоштовний і прибирає цю суму повністю: у таблицю маршрутів підмережі додається префікс S3, і запити йдуть повз NAT.
Вихід у зовнішній API через NAT. Тут NAT потрібен. 1000 ГБ × $0.045 = $45 за обробку, і додатково 1000 ГБ × $0.09 = $90 за вихідний трафік (без урахування 100 ГБ безкоштовного обсягу). Разом $135 за трафік і $32.85 за шлюз: близько $168 на місяць. Той самий трафік із публічної підмережі з публічною адресою коштував би $90 плюс $3.65 за адресу, але відкрив би інстанс для інтернету. Приватність тут має конкретну ціну: близько $75 на місяць за 1 ТБ.
Що з цього випливає. Від приватної підмережі через ціну не відмовляються, але ціну знижують. Трафік до сервісів провайдера виводять на ендпоінти, а трафік до зовнішніх систем стискають і кешують. Шлюз у кожній зоні додає постійну плату, і її треба закладати в оцінку. Друга пастка того самого роду: 10 ТБ на місяць між сервісами в різних зонах AWS коштують 10 000 ГБ × $0.02 = $200, хоча жоден байт не покинув регіон.
Типові помилки розуміння
Section titled “Типові помилки розуміння”«Публічна підмережа має прапорець». Її робить маршрут 0.0.0.0/0 у шлюз
в інтернет. Без публічної адреси у ресурсу й без відкритого порту в правилах
інтернет його не побачить.
«Security group і NACL — те саме». Група безпеки stateful, діє на ресурс і має лише дозволи. NACL stateless, діє на підмережу, має заборони й вимагає правил для відповідей.
«Пірінг транзитивний». A, з’єднана з B, не бачить C, з’єднану з B. Для багатьох мереж потрібен хаб.
«Трафік усередині хмари безкоштовний». Безкоштовний лише в межах зони. Між зонами й регіонами, через NAT і через приватні ендпоінти є плата.
«NAT-шлюз — це безкоштовна дрібниця». Шлюз бере $0.045 за годину й за ГБ, і найбільше коштують випадки, коли через нього ходить трафік до сервісів провайдера.