Опишите опыт работы с Amazon AWS

Что проверяют

Умеете ли вы довести сервис на JVM до облака и понимаете ли, чем там отличается эксплуатация: доступы, конфигурация, память контейнера, поведение при выкате. Список сервисов вторичен, важнее, что вы делали руками и что за вас делала платформенная команда.

Как отвечать

Идите от своего приложения, а не от каталога облака:

• запуск: образ в ECR, сервис в ECS или EKS, за балансировщиком, с пробами состояния и автоматическим масштабированием;
• данные: RDS для реляционной базы, S3 для файлов через SDK для Java, SQS для асинхронных задач;
• конфигурация и секреты: Secrets Manager или хранилище параметров вместо паролей в application.yml, значения приезжают переменными окружения;
• доступы: роль у задачи вместо статических ключей, стандартная цепочка поиска учётных данных подхватывает её сама;
• наблюдаемость: логи и метрики в CloudWatch, сквозная трассировка запросов между сервисами;
• тесты: LocalStack и Testcontainers, чтобы интеграция с облаком проверялась локально и в пайплайне.

Отдельно скажите про JVM в контейнере: размер кучи задаётся долей от лимита памяти, а не абсолютным числом; пул соединений к базе умножается на число реплик и упирается в лимит подключений; на выкате нужен корректный ответ на сигнал завершения, иначе часть запросов теряется.

Где спотыкаются

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

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

Забывают про память. Куча по умолчанию считается от памяти хоста, а не от лимита контейнера, поэтому процесс прибивают за превышение, и причину ищут в облаке вместо параметров запуска.