Вопросы для собеседования на позицию старшего облачного инженера AWS: Полное руководство

Введение

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

В этом руководстве рассматриваются основные вопросы для собеседования со старшими инженерами AWS Cloud, с упором на архитектуру, расширенные сервисы и стратегические облачные решения.

Архитектура и проектирование

1. Разработайте отказоустойчивое многоуровневое веб-приложение в AWS.

Ответ: Готовая к использованию многоуровневая архитектура требует избыточности, масштабируемости и безопасности:

Loading diagram...

Ключевые компоненты:

1. DNS и CDN:

# Route 53 для DNS с проверками работоспособности
aws route53 create-health-check \
  --health-check-config IPAddress=203.0.113.1,Port=443,Type=HTTPS

# CloudFront для глобальной доставки контента
aws cloudfront create-distribution \
  --origin-domain-name myapp.example.com

2. Балансировка нагрузки и автоматическое масштабирование:

# Создать Application Load Balancer
aws elbv2 create-load-balancer \
  --name my-alb \
  --subnets subnet-12345 subnet-67890 \
  --security-groups sg-12345

# Создать Auto Scaling Group
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --launch-template LaunchTemplateName=my-template \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 4 \
  --target-group-arns arn:aws:elasticloadbalancing:...

3. База данных и кэширование:

RDS Multi-AZ для высокой доступности
Read replicas для масштабирования чтения
ElastiCache для кэширования сессий/данных

Принципы проектирования:

Развертывание в нескольких зонах доступности (AZ)
Использовать управляемые сервисы, когда это возможно
Внедрить автоматическое масштабирование
Разделить уровни с помощью групп безопасности
Использовать S3 для статического контента

Распространенность: Очень часто
Сложность: Сложно

2. Объясните VPC Peering и когда его следует использовать.

Ответ: VPC Peering обеспечивает частное соединение между двумя VPC с использованием сети AWS.

Характеристики:

Частное подключение (без интернета)
Отсутствие единой точки отказа
Отсутствие узких мест по пропускной способности
Поддержка пиринга между регионами
Нетранзитивность (A↔B, B↔C не означает A↔C)

Сценарии использования:

Подключение производственных VPC и VPC управления
Совместное использование ресурсов между VPC
Архитектуры с несколькими учетными записями
Подключение к гибридному облаку

# Создать VPC peering connection
aws ec2 create-vpc-peering-connection \
  --vpc-id vpc-1a2b3c4d \
  --peer-vpc-id vpc-5e6f7g8h \
  --peer-region us-west-2

# Принять peering connection
aws ec2 accept-vpc-peering-connection \
  --vpc-peering-connection-id pcx-1234567890abcdef0

# Обновить таблицы маршрутизации
aws ec2 create-route \
  --route-table-id rtb-12345 \
  --destination-cidr-block 10.1.0.0/16 \
  --vpc-peering-connection-id pcx-1234567890abcdef0

Альтернативы:

Transit Gateway: Топология "звезда", транзитная маршрутизация
PrivateLink: Подключение между сервисами
VPN: Зашифрованное подключение

Распространенность: Часто
Сложность: Средне

Продвинутые вычисления

3. Как работает Auto Scaling и как его оптимизировать?

Ответ: Auto Scaling автоматически регулирует ресурсы в зависимости от спроса.

Политики масштабирования:

1. Target Tracking (отслеживание цели):

{
  "TargetValue": 70.0,
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "ASGAverageCPUUtilization"
  }
}

2. Step Scaling (ступенчатое масштабирование):

{
  "AdjustmentType": "PercentChangeInCapacity",
  "MetricAggregationType": "Average",
  "StepAdjustments": [
    {
      "MetricIntervalLowerBound": 0,
      "MetricIntervalUpperBound": 10,
      "ScalingAdjustment": 10
    },
    {
      "MetricIntervalLowerBound": 10,
      "ScalingAdjustment": 30
    }
  ]
}

3. Scheduled Scaling (масштабирование по расписанию):

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name my-asg \
  --scheduled-action-name scale-up-morning \
  --recurrence "0 8 * * *" \
  --desired-capacity 10

Стратегии оптимизации:

Использовать predictive scaling для известных шаблонов нагрузки
Установить соответствующие периоды cooldown (периоды охлаждения)
Мониторить метрики масштабирования
Использовать смешанные типы инстансов
Внедрить lifecycle hooks для корректного завершения работы

Распространенность: Очень часто
Сложность: Средне-сложно

Serverless и продвинутые сервисы

4. Когда следует использовать Lambda, а когда EC2?

Ответ: Выбор зависит от характеристик рабочей нагрузки:

Используйте Lambda, когда:

Рабочие нагрузки, управляемые событиями
Кратковременные задачи (менее 15 минут)
Переменный/непредсказуемый трафик
Требуется нулевое управление серверами
Оптимизация затрат для эпизодического использования

Используйте EC2, когда:

Длительные процессы
Необходим полный контроль над ОС
Специфические требования к программному обеспечению
Постоянная высокая нагрузка
Приложения с сохранением состояния

Пример Lambda:

import json
import boto3

def lambda_handler(event, context):
    """
    Обработка события загрузки S3
    """
    s3 = boto3.client('s3')
    
    # Получить bucket и key из события
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = event['Records'][0]['s3']['object']['key']
    
    # Обработать файл
    response = s3.get_object(Bucket=bucket, Key=key)
    content = response['Body'].read()
    
    # Сделать что-то с контентом
    process_data(content)
    
    return {
        'statusCode': 200,
        'body': json.dumps('Processing complete')
    }

Сравнение стоимости:

Lambda: Оплата за запрос + продолжительность
EC2: Оплата за время работы (даже если простой)

Распространенность: Часто
Сложность: Средне

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

5. Как оптимизировать затраты AWS?

Ответ: Оптимизация затрат требует постоянного мониторинга и корректировки:

Стратегии:

1. Right-sizing (правильный выбор размера):

# Использовать AWS Compute Optimizer
aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:us-east-1:123456789012:instance/i-1234567890abcdef0

2. Reserved Instances & Savings Plans (зарезервированные инстансы и планы экономии):

Обязательства на 1 или 3 года
Экономия до 72% по сравнению с on-demand
Использовать для предсказуемых рабочих нагрузок

3. Spot Instances (спотовые инстансы):

# Запустить spot instances
aws ec2 request-spot-instances \
  --spot-price "0.05" \
  --instance-count 5 \
  --type "one-time" \
  --launch-specification file://specification.json

4. S3 Lifecycle Policies (политики жизненного цикла S3):

{
  "Rules": [
    {
      "Id": "Move to IA after 30 days",
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        }
      ]
    }
  ]
}

5. Auto Scaling (автоматическое масштабирование):

Уменьшать масштаб в нерабочее время
Использовать predictive scaling

6. Monitoring (мониторинг):

AWS Cost Explorer
Оповещения о бюджете
Тегировать ресурсы для распределения затрат

Распространенность: Очень часто
Сложность: Средне

Безопасность и соответствие требованиям

6. Как реализовать защиту в глубину в AWS?

Ответ: Многоуровневый подход к безопасности:

Уровни:

1. Network Security (сетевая безопасность):

# VPC с частными подсетями
# Группы безопасности (разрешать только необходимые порты)
# NACLs для контроля на уровне подсети
# WAF для защиты приложений

# Пример: Ограничить SSH только bastion host
aws ec2 authorize-security-group-ingress \
  --group-id sg-app-servers \
  --protocol tcp \
  --port 22 \
  --source-group sg-bastion

2. Identity & Access (идентификация и доступ):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

3. Data Protection (защита данных):

Шифрование в состоянии покоя (KMS)
Шифрование при передаче (TLS)
Политики bucket S3
Шифрование RDS

4. Monitoring & Logging (мониторинг и ведение журналов):

# Включить CloudTrail
aws cloudtrail create-trail \
  --name my-trail \
  --s3-bucket-name my-bucket

# Включить VPC Flow Logs
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-12345 \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::my-bucket

5. Compliance (соответствие требованиям):

AWS Config для мониторинга соответствия требованиям
Security Hub для централизованного поиска
GuardDuty для обнаружения угроз

Распространенность: Очень часто
Сложность: Сложно

Сервисы баз данных

7. Объясните RDS Multi-AZ vs Read Replicas и когда что использовать.

Ответ: Оба обеспечивают избыточность, но служат разным целям:

Multi-AZ Deployment (развертывание Multi-AZ):

Цель: Высокая доступность и аварийное восстановление
Синхронная репликация в резервный экземпляр в другой AZ
Автоматический failover (1-2 минуты)
Тот же endpoint после failover
Отсутствие повышения производительности для чтения
Удваивает стоимость (резервный экземпляр)

# Создать Multi-AZ RDS instance
aws rds create-db-instance \
  --db-instance-identifier mydb \
  --db-instance-class db.t3.medium \
  --engine postgres \
  --master-username admin \
  --master-user-password MyPassword123 \
  --allocated-storage 100 \
  --multi-az \
  --backup-retention-period 7

Read Replicas (реплики для чтения):

Цель: Масштабирование операций чтения
Асинхронная репликация
Возможно несколько реплик (до 15 для Aurora)
Разные endpoints для каждой реплики
Может быть в разных регионах
Может быть повышен до автономной БД

# Создать read replica
aws rds create-db-instance-read-replica \
  --db-instance-identifier mydb-replica-1 \
  --source-db-instance-identifier mydb \
  --db-instance-class db.t3.medium \
  --availability-zone us-east-1b

# Повысить read replica до автономной
aws rds promote-read-replica \
  --db-instance-identifier mydb-replica-1

Сравнительная таблица:

Feature	Multi-AZ	Read Replica
Replication	Synchronous	Asynchronous
Purpose	HA/DR	Read scaling
Failover	Automatic	Manual promotion
Endpoint	Same	Different
Regions	Same region only	Cross-region supported
Performance	No read benefit	Improves read performance
Use Case	Production databases	Analytics, reporting

Лучшая практика: Использовать оба вместе

Multi-AZ для высокой доступности
Read replicas для масштабирования чтения

Распространенность: Очень часто
Сложность: Средне-сложно

8. Как реализовать миграцию базы данных с минимальным временем простоя?

Ответ: Стратегии миграции базы данных для производственных систем:

Стратегия 1: AWS DMS (Database Migration Service)

# Создать replication instance
aws dms create-replication-instance \
  --replication-instance-identifier my-replication-instance \
  --replication-instance-class dms.t3.medium \
  --allocated-storage 100

# Создать source endpoint
aws dms create-endpoint \
  --endpoint-identifier source-db \
  --endpoint-type source \
  --engine-name postgres \
  --server-name source-db.example.com \
  --port 5432 \
  --username admin \
  --password MyPassword123

# Создать target endpoint
aws dms create-endpoint \
  --endpoint-identifier target-db \
  --endpoint-type target \
  --engine-name aurora-postgresql \
  --server-name target-db.cluster-xxx.us-east-1.rds.amazonaws.com \
  --port 5432 \
  --username admin \
  --password MyPassword123

# Создать migration task
aws dms create-replication-task \
  --replication-task-identifier migration-task \
  --source-endpoint-arn arn:aws:dms:us-east-1:123456789012:endpoint:source-db \
  --target-endpoint-arn arn:aws:dms:us-east-1:123456789012:endpoint:target-db \
  --replication-instance-arn arn:aws:dms:us-east-1:123456789012:rep:my-replication-instance \
  --migration-type full-load-and-cdc \
  --table-mappings file://table-mappings.json

Этапы миграции:

1. Full Load (полная загрузка):

Копирование существующих данных
Может занять часы/дни
Приложение все еще использует источник

2. CDC (Change Data Capture - захват измененных данных):

Репликация текущих изменений
Поддерживает синхронизацию целевой базы данных
Минимальная задержка (секунды)

3. Cutover (переключение):

# Скрипт переключения миграции
import boto3
import time

def perform_cutover():
    """
    Переключение на новую базу данных с минимальным временем простоя
    """
    # 1. Включить режим обслуживания
    enable_maintenance_mode()
    
    # 2. Дождаться нулевой задержки репликации
    wait_for_replication_sync()
    
    # 3. Обновить конфигурацию приложения
    update_database_endpoint(
        old_endpoint='source-db.example.com',
        new_endpoint='target-db.cluster-xxx.us-east-1.rds.amazonaws.com'
    )
    
    # 4. Перезапустить приложение
    restart_application()
    
    # 5. Проверить подключение
    verify_database_connection()
    
    # 6. Выключить режим обслуживания
    disable_maintenance_mode()
    
    print("Cutover complete!")

def wait_for_replication_sync(max_lag_seconds=5):
    """Дождаться минимальной задержки репликации"""
    dms = boto3.client('dms')
    
    while True:
        response = dms.describe_replication_tasks(
            Filters=[{'Name': 'replication-task-id', 'Values': ['migration-task']}]
        )
        
        lag = response['ReplicationTasks'][0]['ReplicationTaskStats']['FullLoadProgressPercent']
        
        if lag < max_lag_seconds:
            print(f"Replication lag: {lag}s - Ready for cutover")
            break
        
        print(f"Replication lag: {lag}s - Waiting...")
        time.sleep(10)

Стратегия 2: Blue-Green Deployment (сине-зеленое развертывание)

# Создать клон Aurora (мгновенно, copy-on-write)
aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier production-cluster \
  --db-cluster-identifier staging-cluster \
  --restore-type copy-on-write \
  --use-latest-restorable-time

# Протестировать на staging
# Когда будет готово, поменять DNS/endpoints

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

DMS: < 1 минуты (только переключение)
Blue-Green: < 30 секунд (переключение DNS)
Традиционный dump/restore: Часы-дни

Распространенность: Часто
Сложность: Сложно

Мониторинг и устранение неполадок

9. Как устранить высокие затраты AWS?

Ответ: Оптимизация затрат требует систематического анализа:

Этапы исследования:

1. Использовать Cost Explorer:

# Получить разбивку затрат по сервисам
aws ce get-cost-and-usage \
  --time-period Start=2024-11-01,End=2024-11-30 \
  --granularity MONTHLY \
  --metrics BlendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# Получить затраты по тегам ресурсов
aws ce get-cost-and-usage \
  --time-period Start=2024-11-01,End=2024-11-30 \
  --granularity DAILY \
  --metrics BlendedCost \
  --group-by Type=TAG,Key=Environment

2. Выявить аномалии в затратах:

import boto3
from datetime import datetime, timedelta

def analyze_cost_anomalies():
    """
    Выявить необычные скачки затрат
    """
    ce = boto3.client('ce')
    
    # Получить затраты за последние 30 дней
    end_date = datetime.now()
    start_date = end_date - timedelta(days=30)
    
    response = ce.get_cost_and_usage(
        TimePeriod={
            'Start': start_date.strftime('%Y-%m-%d'),
            'End': end_date.strftime('%Y-%m-%d')
        },
        Granularity='DAILY',
        Metrics=['BlendedCost'],
        GroupBy=[{'Type': 'SERVICE', 'Key': 'SERVICE'}]
    )
    
    # Проанализировать каждый сервис
    for result in response['ResultsByTime']:
        date = result['TimePeriod']['Start']
        for group in result['Groups']:
            service = group['Keys'][0]
            cost = float(group['Metrics']['BlendedCost']['Amount'])
            
            # Отметить затраты > $100/день
            if cost > 100:
                print(f"⚠️  {date}: {service} = ${cost:.2f}")
    
    return response

# Общие виновники затрат
cost_culprits = {
    'EC2': [
        'Oversized instances (инстансы с избыточной мощностью)',
        'Idle instances (простаивающие инстансы)',
        'Unattached EBS volumes (неприсоединенные тома EBS)',
        'Old snapshots (старые снимки)'
    ],
    'RDS': [
        'Multi-AZ when not needed (Multi-AZ, когда это не нужно)',
        'Oversized instances (инстансы с избыточной мощностью)',
        'Excessive backup retention (чрезмерное хранение резервных копий)'
    ],
    'S3': [
        'Wrong storage class (неправильный класс хранения)',
        'No lifecycle policies (отсутствие политик жизненного цикла)',
        'Excessive requests (чрезмерные запросы)'
    ],
    'Data Transfer': [
        'Cross-region traffic (межрегиональный трафик)',
        'NAT Gateway usage (использование NAT Gateway)',
        'CloudFront not used (CloudFront не используется)'
    ]
}

3. Скрипт очистки ресурсов:

#!/bin/bash
# Найти и сообщить о неиспользуемых ресурсах

echo "=== Unattached EBS Volumes ==="
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].[VolumeId,Size,CreateTime]' \
  --output table

echo "=== Idle EC2 Instances (< 5% CPU for 7 days) ==="
# Использовать CloudWatch для определения
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time $(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 86400 \
  --statistics Average

echo "=== Elastic IPs not attached ==="
aws ec2 describe-addresses \
  --filters "Name=domain,Values=vpc" \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' \
  --output table

echo "=== Old Snapshots (> 90 days) ==="
aws ec2 describe-snapshots \
  --owner-ids self \
  --query 'Snapshots[?StartTime<=`'$(date -u -d '90 days ago' +%Y-%m-%d)'`].[SnapshotId,StartTime,VolumeSize]' \
  --output table

4. Настроить оповещения о затратах:

# Создать оповещение о бюджете
aws budgets create-budget \
  --account-id 123456789012 \
  --budget file://budget.json \
  --notifications-with-subscribers file://notifications.json

# budget.json
{
  "BudgetName": "Monthly-Budget",
  "BudgetLimit": {
    "Amount": "1000",
    "Unit": "USD"
  },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}

Быстрые победы:

Удалить неприсоединенные тома EBS
Остановить/удалить простаивающие инстансы EC2
Использовать S3 Intelligent-Tiering
Включить политики жизненного цикла S3
Использовать Spot instances для некритичных рабочих нагрузок
Правильно подобрать размер для инстансов с избыточными ресурсами

Распространенность: Очень часто
Сложность: Средне

Продвинутые сети

10. Объясните AWS Transit Gateway и его сценарии использования.

Ответ: Transit Gateway - это сервис сетевой топологии "звезда", который упрощает сетевую архитектуру.

Без Transit Gateway:

Loading diagram...

Проблема: N² соединений (ячеистая топология)

С Transit Gateway:

Loading diagram...

Решение: Топология "звезда" (N соединений)

Ключевые особенности:

Транзитная маршрутизация: A→TGW→B→TGW→C работает
Централизованное управление
Поддержка до 5000 VPC
Межрегиональный пиринг
Таблицы маршрутизации для контроля трафика

Настройка:

# Создать Transit Gateway
aws ec2 create-transit-gateway \
  --description "Main Transit Gateway" \
  --options AmazonSideAsn=64512,AutoAcceptSharedAttachments=enable

# Присоединить VPC
aws ec2 create-transit-gateway-vpc-attachment \
  --transit-gateway-id tgw-1234567890abcdef0 \
  --vpc-id vpc-1234567890abcdef0 \
  --subnet-ids subnet-1234567890abcdef0 subnet-0987654321fedcba0

# Создать маршрут в таблице маршрутизации VPC
aws ec2 create-route \
  --route-table-id rtb-1234567890abcdef0 \
  --destination-cidr-block 10.0.0.0/8 \
  --transit-gateway-id tgw-1234567890abcdef0

# Создать таблицу маршрутизации Transit Gateway
aws ec2 create-transit-gateway-route-table \
  --transit-gateway-id tgw-1234567890abcdef0

# Добавить маршрут
aws ec2 create-transit-gateway-route \
  --destination-cidr-block 10.1.0.0/16 \
  --transit-gateway-route-table-id tgw-rtb-1234567890abcdef0 \
  --transit-gateway-attachment-id tgw-attach-1234567890abcdef0

Сценарии использования:

1. Архитектура с несколькими VPC:

# Пример: Централизованный исходящий трафик
vpc_architecture = {
    'production_vpcs': ['vpc-prod-1', 'vpc-prod-2', 'vpc-prod-3'],
    'shared_services': 'vpc-shared',  # NAT, proxies, etc.
    'on_premises': 'vpn-connection'
}

# Все производственные VPC направляют интернет-трафик через VPC общих сервисов
# Централизованные средства контроля безопасности, ведение журналов, NAT

2. Сегментация сети:

# Отдельные таблицы маршрутизации для разных сред
# Production не может получить доступ к development
# Development может получить доступ к общим сервисам

3. Подключение нескольких регионов:

# Создать Transit Gateway в us-east-1
aws ec2 create-transit-gateway --region us-east-1

# Создать Transit Gateway в eu-west-1
aws ec2 create-transit-gateway --region eu-west-1

# Связать их пирингом
aws ec2 create-transit-gateway-peering-attachment \
  --transit-gateway-id tgw-us-east-1 \
  --peer-transit-gateway-id tgw-eu-west-1 \
  --peer-region eu-west-1

Соображения о стоимости:

0,05 долл. США в час за подключение
0,02 долл. США за ГБ обработанных данных
Может быть дорого при масштабировании

Альтернативы:

VPC Peering: Проще, дешевле для небольшого количества VPC
PrivateLink: Подключение между сервисами
VPN: Прямые подключения

Распространенность: Часто
Сложность: Сложно

Заключение

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

Архитектура: Многоуровневые проекты, высокая доступность, аварийное восстановление
Продвинутые сети: VPC peering, Transit Gateway, PrivateLink
Вычисления: Оптимизация Auto Scaling, выбор Lambda vs EC2
Оптимизация затрат: Правильный подбор размера, зарезервированные инстансы, политики жизненного цикла
Безопасность: Защита в глубину, лучшие практики IAM, шифрование
Операционное совершенство: Мониторинг, ведение журналов, автоматизация

Продемонстрируйте реальный опыт работы с производственными системами, инициативами по оптимизации затрат и внедрением безопасности. Удачи!

Содержание

Вопросы для собеседования на позицию старшего облачного инженера AWS: Полное руководство

Введение

Архитектура и проектирование

1. Разработайте отказоустойчивое многоуровневое веб-приложение в AWS.

2. Объясните VPC Peering и когда его следует использовать.

Продвинутые вычисления

3. Как работает Auto Scaling и как его оптимизировать?

Serverless и продвинутые сервисы

4. Когда следует использовать Lambda, а когда EC2?

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

5. Как оптимизировать затраты AWS?

Безопасность и соответствие требованиям

6. Как реализовать защиту в глубину в AWS?

Сервисы баз данных

7. Объясните RDS Multi-AZ vs Read Replicas и когда что использовать.

8. Как реализовать миграцию базы данных с минимальным временем простоя?

Мониторинг и устранение неполадок

9. Как устранить высокие затраты AWS?

Продвинутые сети

10. Объясните AWS Transit Gateway и его сценарии использования.

Заключение

Ваше следующее собеседование — всего одно резюме

Поделиться этим постом

Еженедельные советы по карьере, которые действительно работают

Еженедельные советы по карьере, которые действительно работают

Похожие посты

Вопросы для собеседования на позицию старшего облачного инженера Azure: Полное руководство

Вопросы для собеседования на позицию Senior Cloud Engineer GCP: Полное руководство

Вопросы для собеседования на позицию старшего инженера по надежности сайта: Полное руководство

Ваше следующее собеседование — всего одно резюме

Поделиться этим постом

Устройтесь на Работу на 50% Быстрее