Какова хорошая стратегия подсети для 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 прекрасно подойдут.
И помните - группы безопасности - ваши друзья:)