Разберём организацию сети внутри вашего облака — раздел VPC (Virtual Private Cloud). Здесь сосредоточено множество важных настроек: организация подсетей, управление белыми IP и таблицами маршрутизации, правила файервола… Честно оговорюсь, что я больше программист, нежели админ. То есть ту же таблицу маршрутизации, я, конечно, настроить могу, но предпочитаю лишний раз её не трогать.
Тема достаточно сложная, так что предлагаю её рассмотреть на примере веб-компании, которая реализует свой SaaS. То есть у каждого клиента будет своё независимое окружение вместе с виртуалками, базой данных, кешей и т.п.
Каждое VPC — своё независимое окружение, недоступное извне, которому присваивается свой блок IPv4/IPv6 адресов (IPv4/IPv6 CIDR), подсети (Subnets), таблица маршрутизации (Route table) и правила файервола (Network ACL). Как правило, делают одно VPC на все ресурсы одного проекта. То есть, если у вас несколько проектов: корпоративный сайт, stage окружение, production окружение — это уже 3 VPC, чтобы они даже не подозревали друг о друге. Однако, это желательно, но отнюдь не обязательно. Вы можете работать в одной сети, созданной по умолчанию, довольно продолжительное время. Даже я бы рекомендовал так и делать, если только начинаете свою практику с AWS, чтобы не разбираться с ошибками, которых можно было бы избежать.
По умолчанию у вас уже созданы подсети для каждой зоны доступности в каждом регионе. На этом уровне можно задать индивидульные настройки маршрутизации и контроля доступа, но смысла в этом я, честно говоря, не вижу. Должна быть достаточно веская причина, чтобы держать разные окружения в разных датацентрах внутри одного региона. Я не зря сделал AZ 1b копией AZ 1a на диаграмме, т.к. Amazon рекомендует дублировать свои ресурсы минимум в 2х зонах доступности, каждая из которых отражает отдельный датацентр в реальном мире. То есть, Load Balancer должен содержать машины из 2х групп, база данных должна быть MultiAZ (да-да, стоимость увеличивается в 2 раза), а если основной кеш в AZ 1a, то обязательно должна быть реплика в AZ 1b.
В этом разделе создаются наборы правил для файерволов конкретных машин. При создании нового инстанса, будь то EC2, RDS или даже ElastiCache, обязательным будет выбор минимум одной Security Group. По умолчанию уже создана группа default, в которой разрешены все входящие и исходящие подключения, но я бы рекомендовал создать ещё по одной группе для каждого сервиса, который виден из интернета. На скриншоте показаны минимальные настройки для веб-сайта.
Здесь вы можете запросить себе новый статичный IP адрес и прикрепить его к EC2 нового клиента. Как вариант, Elastic IP можно назначить сетевому интерфейсу той же RDS, но это не безопасно — лучше всё-таки настроить SSH-туннель. По умолчанию, максимальное кол-во адресов на аккаунт — 5 шт., если нужно больше, то только через запрос на увеличение квоты. Текущую квоту можно посмотреть здесь. Будьте осторожны, потому что плата взимается за каждый НЕиспользуемый IP адрес, не забудьте сделать Release Address после того, как он вам станет не нужен.
Хоть каждое VPC и независимо, но существует способ установить связь между ними с помощью данного раздела. Даже более того — с VPC от другого AWS аккаунта! Разберём более сложный случай, когда каждому своему клиенту вы заводите аккаунт на AWS, но для удобства обновления своего ПО создаёте связь между своим и клиентским аккаунтом AWS. Думаю, создание самой связи вопросов не вызовет, Самое главное — чтобы IP адреса (блоки CIDR) не пересекались! После создания коннект окажется в статусе «Pending Acceptance», то есть надо его подтвердить на другом аккаунте в этом разделе. Осталось только добавить записи в таблицу маршрутизации. Примерно так, как на скриншоте справа.
Позволяет получить доступ к внутренней сети AWS через Elastic IP. Штука платная, причём и по часам, и по гигабайтам трафика, так что надо пользоваться аккуратно, а ещё лучше — реализовать это через какую-нибудь свою виртуалку или VPC Endpoint (что, кстати, рекомендуется в официальной документации).