[SAA-C03] #1 Глобальная инфраструктура AWS и IAM

Большая часть AWS кажется сложной не из-за отдельных сервисов, а из-за количества сущностей и уровней абстракции. На старте легко запомнить, что EC2 — это виртуальные машины, S3 — объектное хранилище, а RDS — управляемая база данных, но при этом не понимать, почему одни ресурсы создаются в конкретном регионе, другие зависят от зоны доступности, а права доступа вообще живут на уровне аккаунта.

Для подготовки к AWS Certified Solutions Architect – Associate (SAA-C03) такой подход быстро перестает работать. На экзамене проверяется не знание определений, а способность выбрать архитектуру под требования к доступности, безопасности, стоимости и операционной сложности.

Поэтому первая тема посвящена двум фундаментальным областям:

глобальной инфраструктуре AWS;
системе управления идентификацией и доступом AWS Identity and Access Management (IAM).

Они связаны сильнее, чем может показаться. Глобальная инфраструктура определяет, где работают ресурсы и какие отказы система должна переживать, а IAM определяет, кто и что может с этими ресурсами делать.

---

1. Как устроена инфраструктура AWS

Для начала полезно построить простую иерархию.

На верхнем уровне существует аккаунт AWS (AWS Account). Внутри аккаунта создаются ресурсы: виртуальные машины, базы данных, очереди, функции, сети и другие сущности. Многие из этих ресурсов находятся в конкретном регионе AWS (AWS Region), а часть ресурсов внутри региона дополнительно привязана к зоне доступности (Availability Zone, AZ).

Упрощенно инфраструктуру можно представить так:

AWS Account
│
├── IAM
│
├── Region: eu-central-1
│   ├── Availability Zone A
│   ├── Availability Zone B
│   └── Availability Zone C
│
└── Region: eu-west-1
    ├── Availability Zone A
    ├── Availability Zone B
    └── Availability Zone C

Эта схема важнее, чем кажется. Если не понимать, на каком уровне существует ресурс, легко ошибиться в вопросах про отказоустойчивость, репликацию, доступ и стоимость.

---

2. Регион AWS (AWS Region)

Регион AWS — это отдельная географическая область инфраструктуры AWS. Например:

eu-central-1
eu-west-1
us-east-1
ap-southeast-1

Каждый регион изолирован от других и содержит несколько зон доступности.

Когда вы запускаете виртуальную машину EC2, создаете VPC или разворачиваете базу данных RDS, вы обычно выбираете конкретный регион. Это означает, что ресурс физически и логически относится к этой части инфраструктуры.

Выбор региона влияет как минимум на четыре группы требований.

Задержка сети

Пользователям из Европы обычно выгоднее обращаться к приложению, развернутому в европейском регионе, чем к приложению в Азии или Северной Америке. Чем дальше находятся клиент и сервер, тем выше физическая задержка.

Для обычного backend API разница в десятки или сотни миллисекунд может быть заметна. Для распределенных систем, репликации баз данных или синхронного взаимодействия между сервисами она может стать архитектурным ограничением.

Требования к размещению данных

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

При этом учитывать нужно не только основную базу данных, но и резервные копии, логи, реплики и системы аварийного восстановления.

Доступность сервисов

Не каждый сервис и не каждая новая возможность AWS появляются одновременно во всех регионах. Поэтому редкий или новый сервис стоит проверять перед тем, как принимать архитектурное решение.

Стоимость

Стоимость вычислений, хранения и сетевого трафика между регионами может отличаться. Поэтому выбор региона — не только вопрос географии.

---

3. Зона доступности (Availability Zone)

Регион AWS состоит из нескольких зон доступности (Availability Zones, AZ).

Зона доступности — это отдельная изолированная часть инфраструктуры внутри региона. Она создается так, чтобы проблемы в одной зоне не обязательно приводили к отказу других зон того же региона.

Внутри региона зоны соединены высокоскоростными каналами с низкой задержкой, что позволяет строить системы, распределенные между несколькими зонами.

Представим приложение:

                 Load Balancer
                      │
             ┌────────┴────────┐
             │                 │
             ▼                 ▼
           AZ-A              AZ-B
             │                 │
          EC2 #1            EC2 #2

Если одна зона становится недоступной, трафик может продолжать обслуживаться экземплярами во второй зоне.

Именно здесь появляется важное для SAA понятие высокой доступности (High Availability).

---

4. Почему несколько серверов не всегда означают высокую доступность

Представим, что приложение работает на трех виртуальных машинах:

AZ-A
├── EC2 #1
├── EC2 #2
└── EC2 #3

На первый взгляд система выглядит надежной: отказ одного сервера не приведет к полной остановке.

Но все три сервера находятся в одной зоне доступности. Если недоступной станет сама зона, перестанут работать все три экземпляра одновременно.

Это пример того, почему важно учитывать область отказа (fault domain).

Несколько экземпляров защищают от отказа экземпляра. Несколько зон доступности защищают от отказа зоны.

Поэтому архитектура:

AZ-A                 AZ-B
 EC2 #1               EC2 #2

часто надежнее, чем:

AZ-A
 EC2 #1
 EC2 #2
 EC2 #3

хотя во втором случае серверов больше.

На экзамене SAA это встречается постоянно. Если в условии сказано, что приложение должно пережить отказ целого дата-центра или одной зоны доступности, увеличение числа EC2 в одной AZ не решает задачу.

---

5. Multi-AZ и Multi-Region — разные уровни надежности

Архитектура, распределенная между несколькими зонами одного региона, называется Multi-AZ.

Она используется прежде всего для высокой доступности внутри региона.

Region: eu-central-1

AZ-A                       AZ-B
 ├── API #1                 ├── API #2
 └── DB node                └── DB standby

Multi-AZ хорошо подходит, когда нужно пережить отказ:

отдельного сервера;
сетевого сегмента;
оборудования;
целой зоны доступности.

Но она не защищает от полного отказа региона.

Если бизнес требует пережить недоступность всего региона, приходится рассматривать архитектуру Multi-Region:

Region A                    Region B
   │                           │
   ├── Application             ├── Application
   └── Database  ───────────►  └── Replica

С точки зрения надежности это сильнее, но архитектура становится значительно сложнее.

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

Для backend-разработчика это уже напрямую связано с теорией распределенных систем. Например, PostgreSQL между двумя зонами одного региона и PostgreSQL между двумя регионами — технически очень разные ситуации. Во втором случае сеть медленнее и менее предсказуема, а задержка репликации становится гораздо заметнее.

Поэтому Multi-Region нельзя считать «улучшенной версией» Multi-AZ, которую нужно использовать всегда. Это отдельный архитектурный инструмент для отдельного класса требований.

---

6. Что находится в регионе, а что является глобальным

Большинство вычислительных и сетевых ресурсов AWS являются региональными.

К таким сервисам относятся, например:

Amazon EC2;
Amazon RDS;
AWS Lambda;
Amazon VPC.

Если экземпляр EC2 создан в eu-central-1, он не существует в eu-west-1. Для второго региона нужно создать отдельный ресурс.

IAM устроен иначе. Это глобально управляемая служба в пределах аккаунта: пользователей и роли IAM не нужно создавать заново в каждой зоне доступности.

Это важно понимать концептуально, но не стоит превращать правило «regional vs global» в механическую таблицу. У некоторых сервисов глобальная панель управления может сочетаться с региональными ресурсами или региональными ограничениями. В реальной работе область действия конкретного ресурса всегда лучше проверять в документации.

---

7. Аккаунт AWS как граница изоляции

Аккаунт AWS — не просто контейнер для ресурсов и платежная учетная запись. Это одна из ключевых границ безопасности и управления.

В небольшой учебной системе можно хранить development и production в одном аккаунте. В серьезной инфраструктуре это часто не лучший вариант.

Например:

AWS Organization
│
├── Development Account
├── Staging Account
├── Production Account
└── Security Account

Такой подход уменьшает последствия ошибок. Если разработчик получил слишком широкие права в development, это не должно автоматически означать аналогичные права в production.

Позже этот принцип будет расширен через AWS Organizations, Organizational Units и Service Control Policies. На первом этапе важно понять саму идею: аккаунт является сильной границей изоляции и часто используется для разделения окружений и зон ответственности.

---

8. IAM: кто и что может делать в AWS

AWS Identity and Access Management (IAM) отвечает за идентификацию и авторизацию в AWS.

Полезно разделять два вопроса:

Аутентификация (authentication) — кто обращается к AWS?

Авторизация (authorization) — что этому субъекту разрешено сделать?

Например, EC2-приложение хочет прочитать объект из S3. AWS должен определить, какая сущность выполняет запрос, есть ли у нее разрешение s3:GetObject и относится ли это разрешение к нужному объекту.

Упрощенная модель выглядит так:

Principal
   │
   │ Action
   ▼
Resource

Например:

EC2 application
   │
   │ s3:GetObject
   ▼
S3 object

---

9. Пользователь IAM (IAM User)

Пользователь IAM — это постоянная идентичность внутри аккаунта AWS.

У пользователя могут быть данные для входа в AWS Console и программные учетные данные.

Исторически IAM User часто использовался и для людей, и для приложений. Сегодня для приложений постоянные access keys считаются плохой моделью, если можно использовать временные учетные данные.

Проблема постоянного ключа понятна любому backend-разработчику. Если в .env лежит:

AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...

этот секрет можно случайно отправить в Git, записать в лог, встроить в Docker image или забыть на старом сервере.

Даже если секрет не утек, его нужно регулярно менять и отслеживать.

---

10. Роль IAM (IAM Role)

Роль IAM — один из самых важных механизмов безопасности AWS.

В отличие от пользователя, роль обычно не представляет постоянного конкретного человека или приложение. Ее принимает (assume) доверенная сущность, после чего получает временные учетные данные.

Например:

EC2
 │
 │ assumes
 ▼
IAM Role
 │
 │ temporary credentials
 ▼
Amazon S3

Если FastAPI работает на EC2 и ему нужно писать файлы в S3, правильная архитектура обычно не требует хранить AWS access key внутри приложения.

Вместо этого экземпляру EC2 назначается роль с нужными разрешениями. AWS SDK получает временные учетные данные автоматически.

Код остается простым:

import boto3

s3 = boto3.client("s3")

s3.upload_file(
    "report.csv",
    "aws-cloud-tasks-files",
    "reports/report.csv",
)

В приложении нет постоянного AWS-секрета.

Для разработчика это можно сравнить с переходом от хранения логина и пароля стороннего сервиса к временному токену доступа. В обоих случаях уменьшается ценность украденного секрета и упрощается управление его жизненным циклом.

---

11. AWS STS и временные учетные данные

Важную роль в этой модели играет AWS Security Token Service (AWS STS).

Когда субъект принимает IAM Role, он получает временный набор учетных данных:

Access Key ID
Secret Access Key
Session Token
Expiration

Ключевое слово здесь — Expiration.

Если такой набор данных будет украден, злоумышленник сможет использовать его только до истечения срока действия. Это не отменяет риски, но значительно уменьшает последствия по сравнению с бессрочным access key.

Именно поэтому на SAA вопросы вида «как безопасно дать EC2 доступ к S3» почти всегда ведут к IAM Role, а не к IAM User.

---

12. Политика доверия и политика разрешений

У IAM Role есть две разные стороны, которые легко перепутать.

Политика доверия (Trust Policy) определяет, кто имеет право принять роль.

Политика разрешений (Permissions Policy) определяет, что роль сможет делать после того, как ее приняли.

Например:

EC2
 │
 │ Trust Policy permits AssumeRole
 ▼
ReportUploaderRole
 │
 │ Permissions Policy
 ▼
s3:PutObject

Это разделение принципиально.

Если роль разрешает s3:PutObject, это еще не означает, что любой пользователь или сервис может стать этой ролью. Для этого отдельно должна выполняться политика доверия.

---

13. Политики IAM (IAM Policies)

Разрешения IAM описываются JSON-политиками.

Например, приложению нужно только читать и записывать объекты в определенный bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::aws-cloud-tasks-files/*"
    }
  ]
}

Здесь важны три поля.

Effect задает результат правила: разрешить (Allow) или запретить (Deny).

Action определяет операции AWS API.

Resource задает ресурсы, к которым применяется правило.

В данном случае разрешение относится только к объектам внутри bucket aws-cloud-tasks-files.

---

14. ARN — адрес ресурса внутри AWS

AWS использует Amazon Resource Name (ARN) для однозначного обозначения ресурсов.

Пример ARN bucket:

arn:aws:s3:::aws-cloud-tasks-files

ARN объектов:

arn:aws:s3:::aws-cloud-tasks-files/*

Для IAM важно понимать, что bucket и объекты внутри него могут иметь разные ARN. Это типичная причина ошибок в S3 policies.

Например, s3:ListBucket применяется к ARN bucket:

arn:aws:s3:::aws-cloud-tasks-files

а s3:GetObject — к ARN объектов:

arn:aws:s3:::aws-cloud-tasks-files/*

К этому различию мы еще вернемся при подробном разборе S3.

---

15. Принцип минимальных привилегий

Одна из центральных идей AWS Security — принцип минимальных привилегий (Principle of Least Privilege).

Смысл простой: приложение, пользователь или сервис должны получать только те разрешения, которые им действительно нужны.

Если worker читает сообщения из одной очереди SQS и получает файлы из одного bucket S3, ему не требуется AdministratorAccess.

Даже managed policies вроде AmazonS3FullAccess могут быть слишком широкими.

Лучше выдать только необходимые действия:

sqs:ReceiveMessage
sqs:DeleteMessage
sqs:ChangeMessageVisibility
s3:GetObject

и ограничить их конкретными ресурсами.

Это напрямую уменьшает последствия компрометации. Если злоумышленник получит возможность выполнять код внутри worker, IAM ограничит набор ресурсов, к которым он сможет обратиться.

---

16. Как IAM принимает решение Allow или Deny

По умолчанию доступ запрещен. Это называется неявным запретом (Implicit Deny).

Если существует подходящее правило Allow, операция может быть разрешена.

Но если одновременно существует применимый явный Deny, он имеет приоритет.

Упрощенная логика:

Нет подходящего Allow
        │
        ▼
       Deny

Есть Allow
        │
        ▼
Нет Explicit Deny
        │
        ▼
       Allow

Есть Allow + Explicit Deny
        │
        ▼
       Deny

Например:

Policy A: Allow s3:*
Policy B: Deny s3:DeleteObject

Результат:

s3:GetObject       разрешено
s3:PutObject       разрешено
s3:DeleteObject    запрещено

Для SAA достаточно твердо помнить: Explicit Deny имеет приоритет над Allow.

В реальном IAM evaluation существуют и дополнительные механизмы: Service Control Policies, permissions boundaries, session policies и условия. Их мы будем разбирать отдельно, когда дойдем до AWS Organizations и более сложных сценариев безопасности.

---

17. Политики идентичности и политики ресурсов

IAM permissions могут задаваться с разных сторон.

Политика идентичности (identity-based policy) прикрепляется к IAM User, Group или Role.

Например:

IAM Role
   └── Allow s3:GetObject

Политика ресурса (resource-based policy) прикрепляется непосредственно к ресурсу.

Классический пример — S3 Bucket Policy.

S3 Bucket
   └── разрешить чтение определенному AWS Account

Политики ресурсов особенно важны для cross-account доступа.

Позже эта тема станет гораздо интереснее на примере S3, SQS, SNS и KMS, потому что у разных сервисов есть свои особенности взаимодействия identity-based и resource-based policies.

---

18. Корневой пользователь (Root User)

После создания аккаунта AWS существует корневой пользователь.

Он обладает чрезвычайно широкими возможностями и предназначен прежде всего для отдельных действий на уровне аккаунта.

Для обычной работы root использовать не следует.

Минимальная безопасная настройка аккаунта:

включить MFA;
не использовать root в повседневной работе;
не создавать root access keys без реальной необходимости;
надежно хранить данные восстановления доступа.

Ошибкой будет считать root «главным администратором, под которым удобнее работать». В AWS это скорее аварийный владелец аккаунта, доступ к которому должен использоваться редко.

---

19. Как это связано с обычной backend-разработкой

Представим учебный проект aws-cloud-tasks.

Пользователь отправляет файл в FastAPI:

POST /jobs

FastAPI должен сохранить его в S3.

Наивный вариант:

FastAPI
  │
  ├── AWS_ACCESS_KEY_ID
  └── AWS_SECRET_ACCESS_KEY
          │
          ▼
         S3

Такая схема технически работает, но секрет нужно хранить и обслуживать.

AWS-native вариант:

Client
  │
  ▼
FastAPI on EC2
  │
  ▼
IAM Role
  │
  ▼
temporary credentials
  │
  ▼
Amazon S3

В коде нет постоянных ключей. Права ограничены только нужным bucket.

Если позднее FastAPI переедет с EC2 в ECS или Lambda, принцип сохранится: вычислительная среда получает IAM Role, а приложение использует временные учетные данные.

Это одна из тех идей AWS, которую стоит понять не ради экзамена, а ради реальной архитектуры.

---

20. Надежность и безопасность — разные измерения

Иногда начинающие архитекторы смешивают эти две области.

Например, приложение может иметь идеальную IAM-конфигурацию и при этом работать на одной EC2 в одной зоне доступности. Оно будет хорошо защищено от лишних AWS permissions, но плохо защищено от инфраструктурного отказа.

Обратная ситуация тоже возможна: приложение распределено между тремя зонами доступности, но каждая EC2 имеет AdministratorAccess. С точки зрения отказоустойчивости все хорошо, с точки зрения безопасности — нет.

Поэтому архитектуру стоит оценивать отдельно по нескольким направлениям:

безопасность;
доступность;
производительность;
стоимость;
операционная сложность.

Это соответствует подходу AWS Well-Architected Framework и логике экзамена SAA.

---

21. Компромиссы: надежность не бывает бесплатной

Multi-AZ обычно дороже Single-AZ, потому что требуется больше ресурсов.

Multi-Region еще сложнее: появляются дополнительные экземпляры, реплики, межрегиональный трафик, DNS failover и операционные сценарии.

Именно поэтому правильный ответ на архитектурный вопрос — не всегда «самый надежный вариант».

Если условие требует пережить отказ одной зоны доступности, Multi-Region может быть избыточным.

Экзамен часто формулирует требования через слова:

most cost-effective;
least operational overhead;
highly available;
most secure.

Они важны не меньше, чем техническая часть вопроса. Два решения могут работать, но одно лучше соответствует требуемому компромиссу.

---

22. Что особенно важно для SAA-C03

Из этой темы для экзамена стоит вынести несколько устойчивых моделей мышления.

Если приложение должно продолжить работу при отказе одной зоны доступности, решение должно распределять компоненты между несколькими AZ.

Если приложение на EC2, Lambda или ECS должно обращаться к другому AWS service, в первую очередь стоит думать об IAM Role и временных учетных данных, а не о permanent access keys.

Если несколько policies дают конфликтующие результаты, применимый Explicit Deny имеет приоритет.

Если workload нужны только несколько API actions, широкая политика вроде AdministratorAccess противоречит принципу минимальных привилегий.

Если требуется пережить отказ всего региона, Multi-AZ внутри одного региона недостаточно — нужно рассматривать Multi-Region или другой вариант Disaster Recovery.

---

23. Экзаменационные вопросы

Ниже вопросы даны полностью на английском языке, чтобы формулировки были ближе к реальному экзамену. После блока вопросов идет подробный разбор на русском.

Question 1

A company runs a Python application on an Amazon EC2 instance. The application uploads reports to a specific Amazon S3 bucket. The company wants to minimize the risk associated with credential leakage.

Which solution is the MOST secure?

A. Create an IAM user, generate an access key, and store the credentials in environment variables on the EC2 instance.

B. Store IAM user credentials in a configuration file encrypted with an application-level encryption key.

C. Attach an IAM role with the required Amazon S3 permissions to the EC2 instance.

D. Use the AWS account root user credentials and rotate them regularly.

Question 2

A web application runs on four Amazon EC2 instances. All instances are deployed in the same Availability Zone. The application must continue operating if an entire Availability Zone becomes unavailable.

What should a solutions architect do?

A. Increase the EC2 instance size.

B. Deploy the EC2 instances across at least two Availability Zones.

C. Create additional IAM roles for the EC2 instances.

D. Store EC2 backups in Amazon S3.

Question 3

An IAM role has two applicable policies. One policy allows s3:*. Another policy explicitly denies s3:DeleteObject.

Can an application using this role delete an S3 object?

A. Yes, because s3:* includes s3:DeleteObject.

B. Yes, because Allow takes precedence over Deny.

C. No, because an explicit Deny overrides an Allow.

D. It depends on the AWS Region.

Question 4

A worker application consumes messages from one Amazon SQS queue and reads objects from one Amazon S3 bucket.

Which permissions model best follows AWS security best practices?

A. Attach AdministratorAccess.

B. Attach AmazonSQSFullAccess and AmazonS3FullAccess.

C. Create a custom policy that grants only the required SQS actions and s3:GetObject for the required resources.

D. Use the AWS account root credentials.

Question 5

A company runs an application across two Availability Zones in a single AWS Region. The business now requires the application to be recoverable after a complete outage of that Region.

Which solution should the company evaluate?

A. Add more EC2 instances to the existing Availability Zones.

B. Use a Multi-Region disaster recovery architecture.

C. Add additional IAM roles.

D. Increase the size of the existing EC2 instances.

Question 6

A company wants developers to access several AWS accounts without maintaining long-lived IAM user access keys in every account.

Which solution is most appropriate?

A. Create identical IAM users in every AWS account.

B. Share one administrator IAM user between all developers.

C. Use centralized federated access, such as IAM Identity Center, with temporary credentials.

D. Use the root user of each AWS account.

---

24. Ответы и разбор

Question 1 — C

Правильный ответ — C.

Для EC2 workload безопаснее назначить IAM Role. Экземпляр получает временные учетные данные автоматически, поэтому постоянный access key не хранится внутри приложения или на диске.

Вариант A технически работает, но создает долгоживущий секрет. Environment variables уменьшают риск случайного попадания секрета в код, но не решают проблему самого permanent credential.

Вариант B немного усложняет кражу секрета, но по-прежнему основан на постоянных credentials.

Вариант D неприемлем: root credentials не должны использоваться приложением.

---

Question 2 — B

Правильный ответ — B.

Требование касается отказа целой Availability Zone. Поэтому workload должен быть распределен между несколькими зонами.

Увеличение размера instance помогает с производительностью, но никак не защищает от отказа AZ.

IAM Roles относятся к безопасности доступа, а S3 backups помогают восстановлению данных, но не обеспечивают доступность работающего приложения.

---

Question 3 — C

Правильный ответ — C.

Allow s3:* действительно включает s3:DeleteObject, но применимый Explicit Deny имеет более высокий приоритет.

Это одно из базовых правил IAM evaluation, которое часто используется в экзаменационных сценариях.

---

Question 4 — C

Правильный ответ — C.

Worker должен получить только те permissions, которые ему нужны.

Например:

sqs:ReceiveMessage
sqs:DeleteMessage
sqs:ChangeMessageVisibility
s3:GetObject

Причем разрешения должны быть ограничены конкретной очередью и конкретным bucket.

AdministratorAccess очевидно слишком широк. Managed policies AmazonSQSFullAccess и AmazonS3FullAccess лучше root, но по-прежнему дают значительно больше прав, чем требуется.

---

Question 5 — B

Правильный ответ — B.

Multi-AZ защищает от отказа одной зоны доступности, но все зоны находятся внутри одного региона.

Если требование прямо говорит о полном отказе региона, необходимо рассматривать архитектуру аварийного восстановления между регионами.

Это не обязательно означает active-active. Возможны разные стратегии Disaster Recovery, от резервных копий в другом регионе до полностью работающего второго региона. Они будут разобраны отдельно.

---

Question 6 — C

Правильный ответ — C.

Для доступа людей к нескольким AWS accounts лучше использовать федеративный вход и временные credentials.

Создание IAM users с permanent access keys в каждом аккаунте усложняет rotation, удаление доступа и аудит.

Общий administrator user — еще хуже, потому что исчезает персональная идентификация действий.

Root user не предназначен для повседневного доступа разработчиков.

---

Заключение

Глобальная инфраструктура AWS определяет границы отказа и размещения ресурсов. Регион AWS — это географическая область, а зоны доступности внутри региона позволяют строить высокодоступные системы без необходимости сразу переходить к сложной Multi-Region архитектуре.

Multi-AZ и Multi-Region решают разные задачи. Первая модель в первую очередь защищает от отказа зоны доступности, вторая может использоваться для аварийного восстановления при отказе региона или для глобального размещения приложения, но требует гораздо более сложной работы с репликацией, сетью и согласованностью данных.

IAM отвечает за вторую фундаментальную часть архитектуры — контроль доступа. Для приложений AWS предпочтительны IAM Roles и временные учетные данные, а permissions должны соответствовать принципу минимальных привилегий. Постоянные access keys внутри приложений стоит рассматривать как исключение, а не как стандартный способ подключения к AWS API.

Если после этой темы уверенно понятны различия между Region и Availability Zone, Multi-AZ и Multi-Region, IAM User и IAM Role, Trust Policy и Permissions Policy, а также логика Implicit Deny → Allow → Explicit Deny, фундамент для следующих тем уже сформирован.

Следующая статья будет посвящена Amazon EC2: жизненному циклу instance, AMI, семействам instance types, User Data, Instance Metadata, моделям оплаты, Security Groups и подключению IAM Role к реальному FastAPI-приложению.