Спроектируйте базовую сетевую схему VPC для трёхуровневого веб-приложения (веб, приложение, база данных), размещённого в нескольких зонах доступности.

Короткий ответ

Типовая схема — по одной публичной и как минимум по две приватные подсети (для слоя приложения и слоя БД) в каждой из минимум двух AZ, с балансировщиком в публичных подсетях, инстансами приложения в приватных подсетях с выходом через NAT и базой данных в ещё более изолированных приватных подсетях без исходящего доступа в интернет вообще.

Как это работает подробнее

трафик снаружи попадает на балансировщик в публичной подсети, тот направляет его на инстансы приложения в приватных подсетях; инстансы приложения обращаются к базе данных в отдельных приватных подсетях, доступных только из подсети приложения через security group; каждый слой дублируется минимум в двух AZ.

Пример кода

example.txtКопировать

VPC 10.0.0.0/16
 AZ-a: public 10.0.1.0/24 (ALB), app-private 10.0.11.0/24, db-private 10.0.21.0/24
 AZ-b: public 10.0.2.0/24 (ALB), app-private 10.0.12.0/24, db-private 10.0.22.0/24
DB security group: inbound TCP 5432 from App security group only

Что использовать на практике

• Рекомендация. для каждого слоя создают отдельную security group с точечными правилами (например, DB security group разрешает вход только с App security group на порту БД); NAT gateway размещают в каждой используемой AZ, чтобы избежать единой точки отказа.
• Проверка. при тестировании подключение к БД напрямую из публичной подсети или извне VPC должно быть отклонено, а подключение из инстанса app-слоя — успешным.

Подводные камни

• Риск. размещать базу данных в публичной подсети «для простоты подключения»
• Риск. создавать единственный NAT gateway на весь VPC без резервирования по зонам
• Риск. разрешать доступ к БД с 0.0.0.0/0 или со всей VPC CIDR вместо узкой security group приложения.