AWS IAM EC2 балансування навантаження: Створіть масштабовані системи

Вступ

Побудова масштабованих і безпечних додатків на AWS вимагає опанування чотирьох фундаментальних сервісів: Identity and Access Management (IAM), Elastic Compute Cloud (EC2), Application Load Balancer (ALB) та Auto Scaling Groups (ASG). Разом ці сервіси формують основу хмарної інфраструктури, забезпечуючи безпечний контроль доступу, гнучкі обчислювальні ресурси, інтелектуальний розподіл трафіку та автоматичне масштабування.

Цей посібник надає комплексний огляд кожного сервісу з практичними архітектурними діаграмами, реальними прикладами коду та перевіреними у виробництві практиками. Чи готуєтесь ви до іспиту AWS Certified Developer Associate, чи будуєте продакшн системи, розуміння взаємодії цих сервісів є необхідним для створення стійких, економічно ефективних хмарних додатків.

Ми дослідимо IAM політики з JSON прикладами, конфігурацію EC2 інстансів зі скриптами user data, стратегії маршрутизації балансувальника навантаження та політики автомасштабування, які адаптуються до реальних патернів трафіку. Наприкінці ви матимете повну ментальну модель архітектури безпечних, масштабованих AWS додатків.

Серія AWS Developer Certification

📚 Переглянути повний посібник AWS Developer Certification - Опануйте всі 7 частин з нашим комплексним шляхом навчання.

Це Частина I (Поточна стаття) нашого комплексного 7-частинного посібника для AWS розробників:

1. Частина I: IAM EC2 та Auto Scaling (Поточна стаття)
2. Частина II: RDS Aurora та DynamoDB
3. Частина III: SQS SNS та Kinesis
4. Частина IV: Lambda API Gateway
5. Частина V: ECS Fargate та IaC
6. Частина VI: Cognito KMS Security
7. Частина VII: CodePipeline та Monitoring

Частина II: RDS Aurora та DynamoDB →

AWS Identity and Access Management (IAM)

Розуміння архітектури IAM

IAM контролює хто може отримувати доступ до чого у вашому AWS акаунті. Замість спільного використання root credentials або створення декількох AWS акаунтів, IAM забезпечує детальний контроль доступу через користувачів, групи, ролі та політики.

Ключові принципи:

1. Ніколи не використовуйте root акаунт для щоденних операцій—лише для налаштування акаунта та біллінгу
2. Одна фізична особа = Один IAM користувач (без спільних credentials)
3. Користувачі успадковують дозволи від груп (простіше управління)
4. Політики визначають дозволи через JSON документи
5. Принцип найменших привілеїв (надавати мінімально необхідні дозволи)

Структура IAM політик

IAM політики — це JSON документи, які визначають дозволи. Розуміння анатомії політики критично важливе для безпеки.

Приклад: S3 політика тільки для читання

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ListBuckets",
      "Effect": "Allow",
      "Action": ["s3:ListAllMyBuckets", "s3:GetBucketLocation"],
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Sid": "AllowS3ReadObjects",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": ["arn:aws:s3:::my-app-bucket", "arn:aws:s3:::my-app-bucket/*"]
    }
  ]
}

Компоненти політики:

• Version: Версія мови політики (завжди використовуйте 2012-10-17)
• Statement: Масив правил дозволів
• Sid: Опціональний ідентифікатор statement (для документації)
• Effect: Allow або Deny (явний deny завжди перемагає)
• Action: Дозволені API виклики (напр., s3:GetObject, ec2:RunInstances)
• Resource: ARN до яких застосовуються дозволи
• Condition: Опціональні обмеження (IP діапазони, MFA, часові вікна)

Приклад з умовами (потрібен MFA):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:TerminateInstances",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        },
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

Ця політика вимагає MFA і запити з певного IP діапазону для завершення EC2 інстансів.

IAM ролі для AWS сервісів

Ролі дозволяють AWS сервісам діяти від вашого імені без збереження credentials у коді.

Створення EC2 ролі (AWS CLI):

# Створити trust policy документ
cat > trust-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "ec2.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}
EOF

# Створити роль
aws iam create-role \
  --role-name EC2-S3-ReadOnly \
  --assume-role-policy-document file://trust-policy.json

# Прикріпити AWS managed політику
aws iam attach-role-policy \
  --role-name EC2-S3-ReadOnly \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Створити instance profile (потрібен для EC2)
aws iam create-instance-profile \
  --instance-profile-name EC2-S3-ReadOnly-Profile

# Додати роль до instance profile
aws iam add-role-to-instance-profile \
  --instance-profile-name EC2-S3-ReadOnly-Profile \
  --role-name EC2-S3-ReadOnly

Найкращі практики безпеки IAM

1. Увімкнути MFA для root акаунту (обов'язково)
2. Створювати IAM користувачів з групами (ніколи не прикріплювати політики безпосередньо до користувачів)
3. Регулярно ротувати credentials (access keys кожні 90 днів)
4. Використовувати IAM ролі замість access keys (для EC2, Lambda, ECS)
5. Увімкнути CloudTrail для аудит логування
6. Встановити політику паролів (мінімальна довжина, складність, ротація)
7. Використовувати IAM Access Analyzer для виявлення надто дозвільних політик

Приклад політики паролів (AWS CLI):

aws iam update-account-password-policy \
  --minimum-password-length 14 \
  --require-symbols \
  --require-numbers \
  --require-uppercase-characters \
  --require-lowercase-characters \
  --allow-users-to-change-password \
  --max-password-age 90 \
  --password-reuse-prevention 5

AWS Elastic Compute Cloud (EC2)

Архітектура EC2 та типи інстансів

EC2 надає масштабовані обчислювальні потужності в хмарі. Розуміння сімейств інстансів критично важливе для оптимізації витрат.

Вибір типу інстансу:

EC2 User Data для автоматизації

User Data скрипти виконуються один раз при запуску інстансу. Використовуйте для bootstrapping.

Приклад: Налаштування Web сервера

#!/bin/bash
# Оновити системні пакети
yum update -y

# Встановити та запустити Apache
yum install -y httpd
systemctl start httpd
systemctl enable httpd

# Створити простий health check endpoint
cat > /var/www/html/health.html <<EOF
<!DOCTYPE html>
<html>
<head><title>Health Check</title></head>
<body>
    <h1>OK</h1>
    <p>Instance ID: $(ec2-metadata --instance-id | cut -d " " -f 2)</p>
    <p>Availability Zone: $(ec2-metadata --availability-zone | cut -d " " -f 2)</p>
</body>
</html>
EOF

# Встановити CloudWatch агент для моніторингу
wget https://s3.amazonaws.com/amazoncloudwatch-agent/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm
rpm -U ./amazon-cloudwatch-agent.rpm

# Налаштувати CloudWatch агент
cat > /opt/aws/amazon-cloudwatch-agent/etc/config.json <<EOF
{
  "metrics": {
    "namespace": "MyApp",
    "metrics_collected": {
      "mem": {
        "measurement": [{"name": "mem_used_percent"}]
      },
      "disk": {
        "measurement": [{"name": "disk_used_percent"}]
      }
    }
  }
}
EOF

# Запустити CloudWatch агент
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -s \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/config.json

EC2 Security Groups

Security Groups діють як віртуальні фаєрволи, контролюючи вхідний/вихідний трафік.

Приклад: Security Group для Web сервера (Terraform)

resource "aws_security_group" "web_server" {
  name        = "web-server-sg"
  description = "Allow HTTP/HTTPS from ALB, SSH from office"
  vpc_id      = aws_vpc.main.id

  # Вхідні правила
  ingress {
    description     = "HTTP from ALB"
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

  ingress {
    description     = "HTTPS from ALB"
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    security_groups = [aws_security_group.alb.id]
  }

  ingress {
    description = "SSH from office IP"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
  }

  # Вихідні правила (дозволити всі)
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name        = "web-server-sg"
    Environment = "production"
  }
}

Найкращі практики Security Group:

1. Посилатися на інші security groups замість IP діапазонів (динамічне масштабування)
2. Deny by default (немає вхідних правил якщо не додано явно)
3. Використовувати описові імена та теги
4. Розділяти security groups по рівнях (web, app, database)
5. Ніколи не відкривати 0.0.0.0/0 для SSH (використовувати bastion hosts або SSM Session Manager)

Варіанти придбання EC2

Коли використовувати кожен:

• On-Demand: Непередбачувані навантаження, короткострокові проєкти, тестування
• Reserved Instances: Стабільні навантаження (бази даних, додатки що працюють постійно)
• Spot Instances: Batch обробка, CI/CD workers, fault-tolerant додатки
• Savings Plans: Гнучкі навантаження з передбачуваним використанням compute

Application Load Balancer (ALB)

Архітектура ALB

ALB працюють на рівні Layer 7 (HTTP/HTTPS), забезпечуючи розширену маршрутизацію на основі вмісту запиту.

Правила маршрутизації ALB

Маршрутизація на основі шляху (Terraform):

resource "aws_lb_listener_rule" "api_routing" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 100

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.api_servers.arn
  }

  condition {
    path_pattern {
      values = ["/api/*"]
    }
  }
}

resource "aws_lb_listener_rule" "host_based_routing" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 90

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.admin_portal.arn
  }

  condition {
    host_header {
      values = ["admin.example.com"]
    }
  }
}

resource "aws_lb_listener_rule" "header_based_routing" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 80

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.mobile_api.arn
  }

  condition {
    http_header {
      http_header_name = "User-Agent"
      values           = ["*Mobile*", "*Android*", "*iOS*"]
    }
  }
}

Health Checks ALB

Health checks визначають доступність targets. Провалені перевірки видаляють інстанси з ротації.

resource "aws_lb_target_group" "web_servers" {
  name     = "web-servers-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  health_check {
    enabled             = true
    path                = "/health"
    protocol            = "HTTP"
    port                = "traffic-port"
    healthy_threshold   = 2
    unhealthy_threshold = 3
    timeout             = 5
    interval            = 30
    matcher             = "200-299"
  }

  deregistration_delay = 30

  stickiness {
    type            = "lb_cookie"
    cookie_duration = 86400
    enabled         = true
  }

  tags = {
    Name = "web-servers-target-group"
  }
}

Параметри Health Check:

• healthy_threshold: Послідовних успіхів потрібно (2-10)
• unhealthy_threshold: Послідовних провалів перед позначенням unhealthy (2-10)
• timeout: Макс час відповіді (2-120 секунд)
• interval: Час між перевірками (5-300 секунд)
• matcher: Очікувані HTTP статус коди (200, 200-299, 200,301)

Auto Scaling Groups (ASG)

Архітектура ASG з ALB

Launch Template

Launch Templates визначають конфігурацію інстансу (наступник Launch Configurations).

resource "aws_launch_template" "web_server" {
  name_prefix   = "web-server-"
  image_id      = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"

  iam_instance_profile {
    name = aws_iam_instance_profile.ec2_s3_access.name
  }

  vpc_security_group_ids = [aws_security_group.web_server.id]

  user_data = base64encode(<<-EOF
    #!/bin/bash
    yum update -y
    yum install -y httpd
    systemctl start httpd
    systemctl enable httpd
    echo "<h1>Hello from $(hostname -f)</h1>" > /var/www/html/index.html
  EOF
  )

  block_device_mappings {
    device_name = "/dev/xvda"

    ebs {
      volume_size           = 20
      volume_type           = "gp3"
      delete_on_termination = true
      encrypted             = true
    }
  }

  metadata_options {
    http_endpoint               = "enabled"
    http_tokens                 = "required"
    http_put_response_hop_limit = 1
  }

  monitoring {
    enabled = true
  }

  tag_specifications {
    resource_type = "instance"

    tags = {
      Name        = "web-server-asg"
      Environment = "production"
    }
  }
}

Політики Auto Scaling

Target Tracking Scaling (Рекомендовано):

resource "aws_autoscaling_group" "web_servers" {
  name                = "web-servers-asg"
  vpc_zone_identifier = [aws_subnet.private_a.id, aws_subnet.private_b.id]
  target_group_arns   = [aws_lb_target_group.web_servers.arn]
  health_check_type   = "ELB"
  health_check_grace_period = 300

  min_size         = 2
  max_size         = 10
  desired_capacity = 4

  launch_template {
    id      = aws_launch_template.web_server.id
    version = "$Latest"
  }

  enabled_metrics = [
    "GroupDesiredCapacity",
    "GroupInServiceInstances",
    "GroupMinSize",
    "GroupMaxSize"
  ]

  tag {
    key                 = "Name"
    value               = "web-server-asg"
    propagate_at_launch = true
  }
}

# Target Tracking Policy - CPU
resource "aws_autoscaling_policy" "cpu_tracking" {
  name                   = "cpu-target-tracking"
  autoscaling_group_name = aws_autoscaling_group.web_servers.name
  policy_type            = "TargetTrackingScaling"

  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 70.0
  }
}

# Target Tracking Policy - Request Count
resource "aws_autoscaling_policy" "request_count_tracking" {
  name                   = "request-count-tracking"
  autoscaling_group_name = aws_autoscaling_group.web_servers.name
  policy_type            = "TargetTrackingScaling"

  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ALBRequestCountPerTarget"
      resource_label         = "${aws_lb.main.arn_suffix}/${aws_lb_target_group.web_servers.arn_suffix}"
    }
    target_value = 1000.0
  }
}

Step Scaling Policy (Розширений контроль):

resource "aws_autoscaling_policy" "scale_up" {
  name                   = "scale-up-policy"
  autoscaling_group_name = aws_autoscaling_group.web_servers.name
  adjustment_type        = "ChangeInCapacity"
  policy_type            = "StepScaling"

  step_adjustment {
    scaling_adjustment          = 1
    metric_interval_lower_bound = 0
    metric_interval_upper_bound = 10
  }

  step_adjustment {
    scaling_adjustment          = 2
    metric_interval_lower_bound = 10
    metric_interval_upper_bound = 20
  }

  step_adjustment {
    scaling_adjustment          = 3
    metric_interval_lower_bound = 20
  }
}

resource "aws_cloudwatch_metric_alarm" "high_cpu" {
  alarm_name          = "web-servers-high-cpu"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "2"
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = "60"
  statistic           = "Average"
  threshold           = "70"
  alarm_description   = "Triggers when CPU exceeds 70%"
  alarm_actions       = [aws_autoscaling_policy.scale_up.arn]

  dimensions = {
    AutoScalingGroupName = aws_autoscaling_group.web_servers.name
  }
}

Найкращі практики для продакшну

Оптимізація витрат

1. Right-size інстанси використовуючи CloudWatch метрики
2. Використовувати Savings Plans або Reserved Instances для базової потужності
3. Змішувати типи інстансів в ASG (Spot + On-Demand для fault tolerance)
4. Увімкнути ALB access logs тільки при troubleshooting (витрати на S3 storage)
5. Видаляти невикористані EBS volumes та AMI

Підвищення безпеки

1. Примусити IMDSv2 (запобігає SSRF атакам):

   aws ec2 modify-instance-metadata-options \
     --instance-id i-1234567890abcdef0 \
     --http-tokens required
   

2. Увімкнути EBS шифрування за замовчуванням:

   aws ec2 enable-ebs-encryption-by-default --region us-east-1
   

3. Використовувати Systems Manager Session Manager замість SSH:

   • Не потрібні bastion hosts
   • Централізоване аудит логування
   • Не потрібні вхідні security group правила

4. Ротувати IAM access keys кожні 90 днів

Моніторинг та усунення проблем

Основні CloudWatch метрики:

• EC2: CPUUtilization, StatusCheckFailed, NetworkIn/Out
• ALB: TargetResponseTime, HTTPCode_Target_5XX_Count, RequestCount
• ASG: GroupDesiredCapacity, GroupInServiceInstances

Поширені проблеми:

Поради для іспиту

Ключові концепції:

1. IAM політики використовують least privilege - починати з deny all, додавати конкретні allows
2. Security Groups є stateful - зворотній трафік автоматично дозволений
3. ALB підтримує SNI - декілька SSL сертифікатів на одному listener
4. Target Tracking найпростіша scaling політика - AWS управляє CloudWatch alarms
5. Health check grace period - дозволяє час для instance bootstrapping
6. Connection draining - завершує in-flight запити перед deregistration

Поширені екзаменаційні сценарії:

• "Інстанси постійно завершуються відразу" → Health check grace period занадто короткий
• "Потрібна різна маршрутизація для mobile vs desktop" → Використовувати header-based routing rules
• "Зменшити витрати для стабільного навантаження" → Reserved Instances або Savings Plans
• "Ділитися файлами між інстансами" → Використовувати EFS, не instance store
• "EC2 потрібен S3 доступ без credentials" → Використовувати IAM ролі, не access keys

Хитрі випадки:

• Default security groups дозволяють весь outbound, deny весь inbound
• ALB потребує мінімум 2 subnets у різних AZ
• User Data виконується як root користувач за замовчуванням
• Spot instance завершення дає 2-хвилинне попередження (interruption notice)
• Launch Templates підтримують версіонування, Launch Configurations ні

Висновок

Опанування IAM, EC2, ALB та ASG забезпечує фундамент для побудови безпечних, масштабованих AWS додатків. IAM контролює доступ, EC2 надає обчислення, ALB інтелектуально маршрутизує трафік, а ASG забезпечує доступність через автоматичне масштабування.

Архітектурні патерни та конфігурації в цьому посібнику відображають перевірені у виробництві практики. Починайте з консервативних scaling політик, уважно моніторте CloudWatch метрики та ітеруйте на основі реальних патернів трафіку. Завжди застосовуйте least-privilege IAM політики, вмикайте MFA та використовуйте ролі замість access keys.

Для іспиту AWS Certified Developer Associate зосередьтесь на розумінні взаємодії цих сервісів, структурі JSON політик, механіці health checks та типах scaling політик. Практикуйте створення ресурсів використовуючи як AWS Console так і Infrastructure as Code (Terraform/CloudFormation) для вироблення м'язової пам'яті для екзаменаційних сценаріїв.

Часті запитання

П: Що таке AWS IAM і чому це важливо?

AWS IAM (Identity and Access Management) це сервіс, який контролює доступ до ресурсів AWS через користувачів, групи та ролі. Він дозволяє управляти дозволами за допомогою політик, впроваджувати MFA для безпеки та слідує принципу найменших привілеїв. IAM є критичним для запобігання неавторизованого доступу до вашої хмарної інфраструктури.

П: Як створити IAM роль для EC2 інстансів?

Створіть IAM роль перейшовши до консолі IAM, виберіть "Roles", натисніть "Create role", оберіть EC2 як довірену сутність та прикріпіть політики. Прикріпіть роль до EC2 інстансів під час запуску або змініть існуючі інстанси. Це забезпечує безпечний доступ до AWS сервісів без прив'язки ключів безпосередньо у коді.

П: Яка різниця між Application Load Balancer та Network Load Balancer?

Application Load Balancer (ALB) працює на рівні 7 (HTTP/HTTPS) та підтримує розширену маршрутизацію на основі URL шляхів, імен хостів та заголовків. Network Load Balancer (NLB) працює на рівні 4 (TCP/UDP) та обробляє мільйони запитів за секунду з надзвичайно низькою затримкою. Обирайте ALB для веб-додатків, NLB для екстремальної продуктивності.

П: Як Auto Scaling Group визначає коли масштабувати?

Auto Scaling Groups використовують CloudWatch alarms та scaling політики для визначення коли додавати або видаляти інстанси. Target tracking політики автоматично регулюють ємність для підтримки метрики на рівні 70% використання CPU. Step scaling надає більш детальний контроль з декількома порогами для різних дій масштабування.

П: Що таке типи EC2 інстансів і як вибрати один?

Типи EC2 інстансів категоризовані за сімействами: T3/T4g для загального призначення, C5/C6i для інтенсивних обчислень, R5/R6i для інтенсивної пам'яті та M5/M6i для збалансованих навантажень. Вибирайте на основі вимог вашого додатку до CPU, пам'яті та мережі. Використовуйте CloudWatch метрики для правильного розміру інстансів та оптимізації витрат.

П: Як працюють ALB health checks?

ALB health checks періодично відправляють запити до зареєстрованих цілей використовуючи вказаний шлях, протокол та порт. Цілі повинні відповідати HTTP 200 статус кодами протягом timeout періоду. Після послідовних збоїв (unhealthy threshold), ALB припиняє маршрутизацію трафіку до цього інстансу. Після послідовних успіхів він знову позначається як здоровий.

П: Яка різниця між Reserved Instances та Spot Instances?

Reserved Instances пропонують до 72% економії за 1-3 річні зобов'язання на стабільні навантаження як бази даних. Spot Instances надають до 90% знижки але можуть бути завершені з 2-хвилинним попередженням коли AWS потрібна ємність. Використовуйте Reserved для продакшну, Spot для fault-tolerant пакетної обробки та CI/CD навантажень.