⁠Минимальная схема не является рекомендованной, т.к. поднятие ресурсов в мастер-аккаунте не есть #best_practices. Согласно оным мастер-аккаунт должен быть пустым и страшно защищённым.

Правда пока сам Амазон не способствует такой реализации - отдельные сервисы (#CloudTrail, #Config, #SSO и др.) до сих пор завязаны некоторым своим функционалом на использование именно мастера. В результате для соблюдения архитектурной чистоты приходится плодить костыли и с нетерпением ждать, когда же эти косяки будут исправлены.

Однако делать нужно правильно, несмотря на некоторые текущие моменты. Как минимум знать и стремиться.

Здесь и далее всё будет подразумевать использование AWS #Organizations, что и есть реализация #multi_account_strategy.

===
Рекомендуемая схема
===

В рекомендуемой схеме мастер аккаунт пустой (с поправкой на то, что пока ещё требует запуска в нём) - как минимум, никакие виртуалки в нём точно не запускаем, а наш #devops становится суб-аккаунтом и смещается по иерархии ниже.

Для различных функций, в том числе связанных со всей организацией, некоторая часть мух из предыдущей "мухо-котлетной" схемы выделяются в отдельный аккаунт с расплывчатым названием Secure. Туда переезжают ключи шифрования, домены (только регистрации, а не Hosted zones), бэкапы, #CloudTrail-логи и прочие сущности с особой важностью для организации в целом.

Современные фичи Амазона изменяют некоторые архитектурные элементы.

• Bastion выбрасываем - появление #SSM #Session_Manager закрывает его функционал.

• Для #VPC_peering используем #Transit_Gateway.

• В Devops-аккаунте добаляется #Shared_VPC, которая используется для окружений без жёстких требований по безопасности (условно dev-test), хотя, в принципе, можно и для всех окружений.

Также в Devops-аккаунте появился #Jenkins как CI-инструмент - это может быть любой другой вам привычный (я же использую Jenkins, как говорил Портос, потому, что я использую Jenkins).

⁠Дальнейшее усложнение AWS #Organizations происходит по мере увеличения количества проектов, команд, требований и т.д.

===
Расширенная схема
===

• Общие ресурсы (ECR, снэпшоты, AMI и др.) вместе с #Shared_VPC выделяются в Shared аккаунт.

• Централизованный мониторинг и логи (ELK/Prometheus/Grafana/Sentry и т.д.) занимают свой аккаунт Monitoring (логи прода могут отправляться туда же или в отдельные - тут чисто условно).

• Бэкапы переезжают в DR (Disaster Recovery) аккаунты своих проектов.

• Наборы окружений dev-test-stg-prod-dr объединяются в #OU (Organization Units) для возможности применения к ним групповых SCP политик (объединение может быть и как Dev OU, DR OU etc - тоже чисто условно).

• Если ваша контора хочет целиком переехать в AWS, то выделяется отдельный аккаунт Organization для "организационных" вещей (название не самое удачное, речь об организации-фирме-компании, где, видимо, вы работаете :) ) — AD (Active Directory) для юзеров (самих работников), используемые для #SSO как единой точки входа, а также финансы, биллинги и прочие бухгалтерии, которые совсем не про код - всё будет там.

Процесс детализации #multi_account_strategy можно продолжать дальше - например, добавить OU для #HIPAA и прочих #compliance, где посредством #SCP будут отрабатывать их требования. Многие используеют Sandbox и/или личные аккаунты для разработчиков. И так далее и тому подобное — основные типы уже были перечислены и это уже лишь детали.

При попытке восстановить #RDS #Snapshot в #Shared_VPC получаем такую ошибку:

The specified VPC vpc-04bee1a347f431036 is a shared VPC, please explicitly provide an EC2 security group.

Пока через #AWS_Console это невозможно, т.к. нет возможности выбрать security group (её просто нет в параметрах).

Потому только через #aws_cli:

aws rds restore-db-instance-from-db-snapshot \
    --db-instance-identifier mydb \
    --db-snapshot-identifier my-snapshot \
    --db-instance-class db.t2.micro \
    --availability-zone us-east-1c \
    --db-subnet-group-name my-dbsubnetgroup \
    --no-multi-az \
    --no-publicly-accessible \
    --auto-minor-version-upgrade \
    --vpc-security-group-ids sg-0cf1206653f75d50d

Всё из-за последней строчки, которая появилась в последних версиях aws-cli, потребовавшейся с приходом Shared VPC.

Главное на Амазоне за 2017-2018-2019 — Networking

От организации к сетевой составляющей. За это время в плане подходов к проектированию и обслуживанию сети организации на Амазоне поменялось ПОЛНОСТЬЮ ВСЁ — в 2018-м году появились сервис AWS Transit Gateway и фича Shared VPC:

https://aws.amazon.com/transit-gateway/

https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-a-new-approach-to-multiple-accounts-and-vpc-management/

Сервис Transit Gateway позволяет глобально упорядочить сетевую инфраструктуру самой высокой сложности, а для работы с On-Prem без него теперь теперь Амазон просто не рассматривается.

VPC Sharing позволяет кардинально упростить сетевую инфраструктуру в тех многих случаях, когда нет повышенных требований по её изоляции. Для средних и больших проектов подход с использованием Shared VPC даёт возможность уменьшить количество VPC на порядок при сохранении параметров безопасности и уменьшении расходов.

Если у вас используется VPN или Direct Connect доступ в Амазон, если у вас есть филиалы по миру или вы лишь планируете это сделать — обязательно разберитесь с возможностями, которые даёт Transit Gateway, это принципиально новый набор возможностей, это новый, совсем другой — глобальный Амазон. Вот хорошее видео по его работе и возможностям с последнего реинвента:

https://www.youtube.com/watch?v=9Nikqn_02Oc

Если у вас большое количество однотипных VPC, в которых крутится небольшое количество сервисов, то для упрощения и экономии их можно поднимать в общих Shared VPC. Это позволяет обуздать постоянно усложняющуюся архитектуру сети компании, сделать её понятной, управляемой и эффективной. Вот хорошее видео по Shared VPC с последнего реинвента:

https://www.youtube.com/watch?v=S9NMA3ACZDM

И Transit Gateway, и Shared VPC плотно увязаны с мульти-аккаунт подходом, который, как говорилось ранее, теперь есть базовая сущность Амазона и потому неотрывно подразумевается и интегрирован в них.

Итого по планированию и работе с сетевой инфраструктурой компании — Shared VPC упрощает, а Transit Gateway упорядочивает и глобализирует. Это важно понять — Амазон давно стал глобальным, но теперь с помощью Transit Gateway он позволяет стать глобальным и вам, напрямую используя возможности AWS по глобализации своей сетевой инфраструктуры.

#главное #Transit_Gateway #Shared_VPC #networking

Разбор падения Slack от 4 января:

https://slack.engineering/slacks-outage-on-january-4th-2021/

Весьма полезное чтиво – хронология, детали, выводы. Кроме ставшего классическим /proc/sys/fs/file-max, есть и специфичные амазоновские причины.

Масштабирование AWS Transit GateWay (TGW)

TGW менеджится Амазоном, потому повлиять на него мы не можем. В то время, как часть проблем у Slack возникла из-за того, что резко возросший трафик через их корневой TGW, через который завязаны их окружения, давал ошибки, не успевая масштабироваться, добавляя проблем во время падения Slack. Амазоновцы вручную боролись с этой ситуацией:

However, our TGWs did not scale fast enough. During the incident, AWS engineers were alerted to our packet drops by their own internal monitoring, and increased our TGW capacity manually.

Чтобы такого избежать, нужно "прогревать" TGW, аналогично тому, как такое предусмотрено для ELB:

https://aws.amazon.com/articles/best-practices-in-evaluating-elastic-load-balancing/#pre-warming

Shared VPC vs different VPCs

Другой момент – отрицательные стороны от использования отдельных VPC. Если бы у Slack использовалась Shared VPC – и для окружения, и для мониторинга, то трафик бы не упёрся бы в узкое горлышко TGW (его скорости масштабирования), через который и соединяются отдельные VPC.

#TGW #Shared_VPC #design

🆕 Shared Security Group 🎉

https://docs.aws.amazon.com/vpc/latest/userguide/security-group-sharing.html

Что ж, свершилось. С момента появления Shared VPC 6 лет назад, это первое, чего хотелось бы иметь в комплекте.

Как круто было пошарить VPC сразу на многие аккаунты! Но каждый раз нужно было решать проблему с Security Groups, которые при этом не шарились. Приходилось писать костыли, создающие Security Groups в каждом аккаунте вручную.

Топил за #Shared_VPC все эти годы, теперь же вместе с Shared Security Group это вообще круто. Шаринг VPC уже давно стал best practices, а вместе с шарингом Transit Gateway это вообще ключевые элементы для построения современной сетевой архитектуры в AWS.

#SecurityGroup #VPC #RAM