Старый vs Новый — Урок 05

1. On-Premises vs Cloud

Старый подход: On-Premises

Покупка физических серверов (капитальные затраты)
Развёртывание занимает недели (доставка, монтаж, настройка)
Масштабирование — покупка дополнительного оборудования
Простой при аварии оборудования
Неиспользуемые ресурсы «простаивают», но платите за них

Современный подход: Cloud

Pay-as-you-go: платите за фактическое потребление
Развёртывание занимает минуты через API или консоль
Auto Scaling: ресурсы добавляются автоматически под нагрузку
Высокая доступность через несколько AZ
Не нужно платить за простаивающие мощности

2. EC2-Classic (лекция) → EC2 in VPC (современно)

В лекции упоминается EC2 без явного указания на VPC — это соответствует старой архитектуре EC2-Classic, которая существовала с 2006 года. В 2022 году AWS официально прекратила поддержку EC2-Classic.

Старое: EC2-Classic (из лекции — устарело)

# EC2-Classic: все инстансы
# в одной плоской сети AWS
# Нет изоляции между аккаунтами
# Security Groups работали иначе
# Нет контроля IP-адресации

aws ec2 run-instances \
  --image-id ami-xxxxx \
  --instance-type t2.micro
# Без --subnet-id = EC2-Classic (недоступно с 2022)

Современное: EC2 in VPC (правильно)

# Каждый аккаунт имеет Default VPC
# Ресурсы изолированы в подсетях
# Полный контроль IP-адресации

aws ec2 run-instances \
  --image-id ami-xxxxx \
  --instance-type t3.micro \
  --subnet-id subnet-xxxxxxxx \
  --security-group-ids sg-xxxxxxxx
# --subnet-id = явно в VPC

Итог: сегодня при создании EC2 всегда указывайте subnet (или оставьте Default VPC). EC2-Classic больше недоступен для новых аккаунтов.

3. Access Keys в коде → IAM Roles

Старое (опасно): хардкод Access Keys

# app/config.py — НИКОГДА ТАК НЕ ДЕЛАТЬ

import boto3

# Хардкод ключей в коде — критическая уязвимость
s3 = boto3.client(
    's3',
    aws_access_key_id='AKIAIOSFODNN7EXAMPLE',
    aws_secret_access_key='wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',
    region_name='us-east-1'
)

Риски: ключи утекают в git, видны в CI/CD логах, не ротируются.

Современное: IAM Role для EC2

# app/config.py — правильно

import boto3

# Без явных ключей: boto3 автоматически
# берёт временные credentials из IAM Role
# назначенной EC2-инстансу
s3 = boto3.client('s3', region_name='eu-west-1')

# Boto3 проверяет:
# 1. EC2 Instance Metadata Service (IMDS)
# 2. ~/.aws/credentials (локально)
# 3. Переменные окружения

Temporary credentials ротируются автоматически каждые ~1 час.

4. Reserved Instances (сложные) → Savings Plans (гибкие)

Старое: Reserved Instances (2006–2017 основная модель)

Привязка к конкретному типу инстанса (t2.micro, m5.large)
Привязка к конкретному региону и AZ
Конвертируемые RI — менее гибкие
Сложно планировать при изменении требований

Современное: Savings Plans (с 2019)

Обязательство тратить $X/час (не на конкретный тип)
Compute Savings Plans: любой EC2, Lambda, Fargate
Автоматически применяется к наиболее дорогим ресурсам
Гибкость: поменяли тип инстанса — скидка сохраняется

5. Ручное управление → Infrastructure as Code

Этот переход подробнее рассматривается в уроке 07 (Terraform + AWS).

Старое: ClickOps (ручное управление)

Создание ресурсов вручную через консоль
Нет истории изменений
Воспроизвести среду «как было» невозможно
Конфигурации в головах людей, не в документации

Современное: IaC (Terraform, AWS CDK, CloudFormation)

Инфраструктура описана в коде (версионируется в git)
Воспроизводимые окружения (dev = staging = prod, только параметры разные)
Code review для изменений инфраструктуры
Автоматическое применение через CI/CD

6. IAM без MFA → IAM с MFA + принцип наименьших привилегий

Устаревшая практика

Работа через root-аккаунт
Политика AmazonEC2FullAccess + AmazonS3FullAccess всем разработчикам
Нет MFA на аккаунте
Access Keys с долгосрочным сроком действия

Современная практика

Root аккаунт заблокирован, MFA включена
Каждый пользователь — только нужные права
MFA обязательна для всех IAM пользователей
AWS IAM Identity Center (SSO) для управления доступом через организации