Какова хорошая стратегия подсети для AWS VPC?

В настоящее время у меня есть каждый VPC на кластер (stg, prd, tst, misc), а стандартные кластеры (stg, prd) имеют эти подсети:

  • elb: для публичных elb(s), которые будут получать прямой публичный трафик
  • elb-int: для внутренних elb(s), которые будут получать сервисную связь
  • svc: для службы приложений
  • дБ: для базы данных
  • dmz: для шлюзов nat, прокси и т. д.
VPC (stg, prd).110.100.0.0 / 16 аз-1
|.110.100.0.0 / 20 эльб
|.110.100.16.0/20 elb-int
|.110.100.32.0/20 svc
|.110.100.48.0/20 svc
|.110,100,64,0 / 20 дБ
| 10,100,80,0 / 20 дмз
|.110.100.96.0 / 20 <зарезервировано>| ├...
|.110,1–0,240,0 / 20 <зарезервировано>.110.101.0.0 / 16 аз-2
|.110.101.0.0 / 20 эльб
|.110.101.16.0/20 elb-int
|.110.101.32.0/20 svc
|.110.101.48.0/20 svc
|.110,101,64,0 / 20 дБ
|.110,101.80,0 / 20 дмз
|.110.101.96.0 / 20 <зарезервировано>| ├...
|.110.101.240.0/20 <зарезервировано>.1010.102.0.0 / 16 аз-3.1010.102.0.0 / 20 эльб.1010.102.16.0/20 elb-int.1010.102.32.0/20 svc.1010.102.48.0/20 svc.1010,102,64,0 / 20 дБ.1010.102.80.0 / 20 дмз.1010.102.96.0 / 20 <забронировано>
   ├....1010.102.240.0 / 20 <зарезервировано>

Я знаю, что этот вопрос является широким, вроде "это зависит от ситуации", своего рода вопрос. Но я искал в Интернете и не нашел разумного руководства по этому вопросу.

Поэтому я задал этот вопрос, чтобы узнать, как системные администраторы выбирают стратегию для своих подсетей. Пожалуйста, поделитесь своим и, если можете, разместите небольшое заявление, объясняющее, почему вы выбрали такой подход.

1 ответ

Боюсь, что ServerFault - это не место для проведения опросов или получения ответов на основе мнений.

В любом случае, ваши настройки кажутся слишком сложными.

Поскольку в AWS безопасность и брандмауэр выполняются преимущественно с использованием групп безопасности, на самом деле не имеет значения, есть ли у вас 6 уровней подсетей, как вы описали в вопросе, или только 2 на VPC - публичный и частный.

  • Ресурсы в общедоступных подсетях имеют публичные / эластичные IP-адреса и могут быть доступны из Интернета, если позволяют правила SG

    Например - общедоступный ELB/ALB, хосты перехода и т. Д.

  • К ресурсам в частных подсетях нельзя получить доступ извне и использовать NAT для общения

    Например - кластеры RDS, кластеры ECS, веб-серверы (скрытые за ELB) и т. Д.

  • При желании вы можете иметь частные подсети без доступа к Интернету - это иногда используется для баз данных (RDS), но почти так же часто они просто помещаются в обычные частные подсети.

Конечно, для достижения высокой доступности ваши уровни общедоступной и частной подсетей должны охватывать несколько АЗ, но не переусердствовать. Используйте максимум 2 или 3 AZ, этого обычно достаточно, даже если в некоторых регионах их может быть намного больше.

Технически, конечно, вы не можете охватить подсеть между AZ, но вы можете иметь priv-a 172.31.0.0/24 в AZ "a" и priv-b 172.31.1.0/24 в AZ "b" и развертывать ELB и ASG в обоих и относиться к нему как к одному.

Обратите внимание, что все вышеперечисленное относится к каждому VPC - обычно у вас будет несколько VPC, например. по одной на этап (dev, test, ..) и даже несколько учетных записей AWS на проект (например, dev и prod) для большего разделения рабочих нагрузок на производство и разработку / тестирование.

Все это, конечно, не жесткие правила. Некоторым клиентам требуется больше уровней подсети или больше AZ на VPC, но это исключения.

Для большинства VPC общедоступные + частные подсети в 3 AZ прекрасно подойдут.

И помните - группы безопасности - ваши друзья:)

Другие вопросы по тегам