Большинство схем архитектуры AWS проваливаются одинаково: кто-то бросает на холст тридцать иконок сервисов, соединяет их стрелками и называет это архитектурой. Выглядит насыщенно, а говорит почти ничего, потому что в архитектуре AWS на самом деле важно не то, какие сервисы вы использовали. Важны границы: что публичное, что приватное, что живёт в какой зоне и где проходят линии доверия. Правильные границы делают схему поучительной. Без них это декорация.
Поэтому стройте схему AWS снаружи внутрь, граница за границей, а сервисы добавляйте в последнюю очередь.
Начните с границ: регион, VPC, зоны доступности и подсети
Представьте схему AWS как набор вложенных контейнеров. Каждый из них: граница, которую читатель должен видеть:
- Регион: самый внешний блок. Всё живёт в одном регионе (или вы рисуете два для мультирегиональной истории).
- VPC: ваша приватная сеть внутри региона.
- Зоны доступности: две или три колонки внутри VPC, потому что так рисуется отказоустойчивость.
- Подсети: публичные и приватные полосы в каждой зоне. Это разделение: самая важная линия на всей схеме.
Нарисуйте их первыми, вложенными прямоугольниками, до того как появится хоть один сервис. Теперь у каждого добавляемого ресурса есть своё место, и его положение несёт смысл: база данных в приватной подсети говорит то, чего никогда не скажет парящая в воздухе иконка.
Расставьте сервисы по своим местам
Только теперь появляются сервисы, и их расположение и есть документация. Балансировщик нагрузки стоит в публичной подсети; серверы приложений в приватной; управляемая база данных глубже всех, приватная и в нескольких зонах. Объектное хранилище или CDN живёт вне VPC, потому что там оно и находится на самом деле. Расположение здесь не украшение; оно кодирует модель безопасности.
На схеме AWS аргументом служит положение. То, где стоит блок, говорит больше, чем иконка на нём.
Иконки AWS: узнаваемые и в меру
Настоящие иконки провайдера помогают читать схему с одного взгляда: читатель замечает базу данных, очередь, балансировщик, не читая подписей. Используйте их, но не делайте их главным. Одна понятная иконка на ресурс, единый размер и много свободного места лучше плотной мозаики. Смысл несут границы; иконки лишь ускоряют узнавание.
Сгенерируйте схему AWS из Terraform
Расставлять всё это вручную долго, и схема устаревает, как только меняется инфраструктура. Если вы управляете AWS через Terraform, структура уже описана: VPC, подсети, инстансы и управляемые сервисы объявлены в коде. Сгенерируйте схему из него, и границы и ресурсы будут взяты из реального определения, а не из ваших воспоминаний о нём. Затем доведите её: поправьте раскладку, сгруппируйте уровни, выделите публичную границу.
Доведите схему для читателя
Перед публикацией пройдитесь по читаемости. Разделение на публичное и приватное безошибочно видно? Можно ли проследить запрос из интернета до базы данных? Зоны доступности видимо разделены, чтобы история отказоустойчивости была очевидна? Уберите всё, что не отвечает на эти вопросы. Сфокусированная схема, которая на них отвечает, лучше полной описи каждого ресурса в аккаунте.
Нарисуйте границы, расставьте сервисы по уровню доверия, не перегружайте иконками и генерируйте черновик из Terraform, чтобы схема оставалась честной. Вот схема AWS, которой люди действительно будут пользоваться.