Этот вопрос в точности похож на вот этот. Похоже, ОП не получил удовлетворительного ответа - потому что он не принял единственный полученный ответ. В основном мы следуем инструкциям, опубликованным в блоге AWS Startup Collection: Практическое проектирование VPC: руководство уровня 301 от архитектора решений AWS. Однако эта статья была опубликована в июле 2014 года, поэтому я не совсем уверен, устарела ли она или это просто я неправильно понял инструкции.
Я пробовал прикрепить код, но из-за этого я не могу опубликовать свой вопрос - я предполагаю, что здесь работают алгоритмы машинного обучения StackOverflow, поскольку мой код очень похож на код в этом вопросе, и я думаю, что мой вопрос помечен как один у которого уже есть ответ.
Так как мне это сделать? Является ли ответ на этот вопрос лучшей практикой?
ОБНОВИТЬ:
«Хотя то, как автор излагает разбивку CIDR, может создать впечатление, что внутри подсетей есть подсети, в статье ничего не говорится о создании подсетей таким образом».
затем как это сделал автор?
«Вы не можете создавать подсети AWS VPC в подсетях AWS VPC».
Если этот метод не создает подсети AWS VPC в подсетях AWS VPC, тогда какие это?
Как я уже упоминал, этой статье 2 года, и я начал использовать VPC буквально на днях. Был ли этот метод действительным тогда, но недействительным сейчас, или он вообще никогда не действовал в AWS VPC?
Думаю, я понимаю, в чем заключается путаница. Статья подразумевает эта конкретная подсеть объекты создаются для каждого из слоев.
10.0.0.0/18
10.0.32.0/19
10.0.32.0/20 - public
10.0.48.0/20
10.0.48.0/21 - protected
10.0.56.0/21 - spare
Вы не создаете подсеть объекты для каждого элемента на диаграмме вы создаете их только для конечных узлов. В приведенном выше примере это настоящие созданные подсети:
Вот и все. Все остальное, вероятно, находится где-то в электронной таблице планирования подсети и не представлено напрямую в AWS. Остальная часть статьи посвящена тому, почему вам не нужно беспокоиться о представлении всей иерархии адресов в AWS. Вы создаете подсети только в последних подсетях, где все будет работать.
Был ли этот метод действительным тогда, но недействительным сейчас, или он вообще никогда не действовал в AWS VPC?
Да, это было действительно когда написано, и да, это действительно сейчас.
В упомянутом вопросе на самом деле недостаточно информации, чтобы определить, какая ошибка была сделана, но автор почти наверняка делал ошибку, поскольку то, что было предпринято, было правильным в принципе.
Если под «подсетью» мы говорим о смежных блоках пространства IP-адресов, которые могут быть описаны в нотации CIDR, то, конечно, все подсети находятся «внутри» других подсетей. Вот почему мы называем их «подсетями».
Но когда мы говорим, что VPC не имеет подсетей внутри подсетей, мы говорим о том, что VPC имеет простую реализацию маршрутизации, в которой нет концепции (или необходимости или возможности) обеспечение любые подсети, кроме конечных, в которых развернуты системы с сетевыми интерфейсами.
Level 1 192.168.0.0/16 ... VPC supernet
Level 2 192.168.128.0/18 Third AZ in region
Level 3 192.168.130.0/23 Web servers
В этом примере подсеть на уровне 2 является логической / информационной / организационной, но на самом деле она никогда не объявляется и не предоставляется где-либо в VPC. Может быть любое промежуточное количество уровней, но это только для целей вашего планирования. VPC не знает какую-либо иерархию подсетей, которую вы можете использовать, потому что ей не нужно знать.
Сам VPC снабжен блоком CIDR на уровне 1 и единственной «подсетью» - на этот раз я использую этот термин для обозначения Подсеть VPC - отображается на уровне 3 - объявлен как подсеть в VPC.
Эта подсеть VPC теперь имеет идентификатор подсети, метку и существует в VPC в одном регионе AWS, где я могу развернуть экземпляры EC2, экземпляры RDS и т. Д. В этой подсети.
Как только я выделю эти 512 адресов (192.168.130.0/23) в подсеть VPC, это единственное место, где они могут быть использованы в этом VPC.
В таком случае я не могу создать подсеть, например 192.168.130.128/25 в моем VPC, потому что это конфликтует с 192.168.130.0/23, которое уже было выделено.
Он не конфликтует с 192.168.128.0/18, потому что я фактически не предоставлял эту подсеть в VPC. «Подсеть» (блок CIDR) на этом уровне - уровень 2 из приведенного выше примера - по существу только для моих плановых и организационных целей, документация моих намерений, но VPC ничего об этом не знает.
Фактически, хотя я «планировал» использовать этот блок в своей третьей зоне доступности, нет никаких технических ограничений или последствий для производительности, если мне позже понадобится использовать, скажем, 192.168.132.0/22 в совершенно другой зоне доступности в моем VPC. . Организационно небрежно, но функционально не проблема. VPC не понимает, что 192.168.128.0/18 находится «в» моей третьей зоне доступности, потому что на самом деле это не так - такая информация не объявляется и не предоставляется.
Вы также можете легко разделить 192.168.0.0/16 на 256/24 блоков¹ и назначить их подсетям и целям с зоной доступности для каждой подсети, выбранной с помощью генератора случайных чисел. Но не делай этого. Не потому, что это не будет работать так же хорошо с точки зрения пропускной способности ... а потому, что это организационно беспорядочно, и потому что 256 адресов может быть меньше, чем вы хотели бы выделить для каждой подсети.
Последняя часть кажется странной, поскольку 256 адресов кажутся большим количеством, но проблема, с которой вы сталкиваетесь, заключается в предоставлении услуг, которым требуются интерфейсы и адреса - я специально думаю о масштабируемых вещах, таких как автоматическое масштабирование EC2, ECS, спотовые экземпляры, Aurora, Lambda и Elastic Load Balancer (ELB) - процесс подготовки включает указание, в какой подсети (-ах) будут работать эти службы.
В случае ELB для каждой подсети, в которой предоставляется ELB, вам необходимо иметь 2 доступных адреса, как минимум, для каждой подсети, для каждого ELB, чтобы узлы ELB могли заменять себя при необходимости (ELB может прозрачно вызвать второй node, оживите его, а затем удалите первый узел по любой причине - например, при техническом обслуживании под управлением AWS). Конечно, вам также потребуются дополнительные адреса, доступные для ELB, чтобы масштабироваться путем добавления узлов. (Я видел, как они доходили до 8, но я не знаю какого-либо фактического ограничения количества узлов, которые ELB может создавать для обработки увеличенного трафика.)
¹Хорошо, технически нет, так как есть ограничение по умолчанию 200 подсетей в одном VPC, независимо от размера блока. Это предел, который AWS Support может увеличить по запросу, но VPC с более чем 200 подсетями, вероятно, имеет недостатки, заложенные в его конструкцию.