Ваш пайплайн разворачивает приложение в AWS. Где хранится YAML — в JSON-определении CodePipeline, которое вы редактируете в консоли, или в .github/workflows/deploy.yml рядом с кодом? Ответ определяет вашу модель IAM, журнал аудита и скорость работы команды. Это сравнение CI/CD для AWS — о том, как сделать этот выбор осознанно, а не по привычке, а затем развить навыки для его грамотной реализации.
Механизм, который действительно отличается
На высоком уровне оба инструмента делают одно и то же: запускаются по коммиту, собирают, разворачивают. Разница в том, где находится идентификатор, когда выполняется шаг развертывания.
CodePipeline работает внутри AWS. Его стадии принимают IAM-роли в вашей учетной записи, вызывают CodeBuild и передают управление CodeDeploy или CloudFormation. Все — триггер, журналы сборки, развертывание — является вызовом AWS API, видимым в CloudTrail.
GitHub Actions работает на раннерах GitHub. Чтобы получить доступ к вашей учетной записи AWS, ему нужны учетные данные. Старый способ — долгоживущий ключ доступа в секретах репозитория. Способ 2026 года — федерация GitHub Actions OIDC AWS: рабочий процесс запрашивает краткосрочный токен у GitHub, AWS STS обменивает его на временные учетные данные через AssumeRoleWithWebIdentity, а политика доверия роли проверяет утверждение sub — например, что только ветка main вашего репозитория может принять эту роль.
Это единственное проектное решение (OIDC вместо статических ключей) устраняет наиболее распространенную проблему безопасности в этой области. Статические ключи в секретах GitHub не ротируются, утекают через форки и журналы и существуют вечно. Токены OIDC истекают через минуты.
Если вам нужна глубокая интеграция с AWS и централизованный аудит
Возьмем команду, работающую с регулируемой нагрузкой. Они развертывают с помощью CodeDeploy blue/green в группе Auto Scaling, подготавливают инфраструктуру с помощью стеков CloudFormation, имеющих сервисные роли и триггеры отката, и им нужно, чтобы каждое развертывание было атрибутировано человеку в CloudTrail для аудитора.
Здесь CodePipeline явно выигрывает:
- Встроенная интеграция с CodeDeploy — перехватчики жизненного цикла, переключение трафика, автоматический откат по тревоге.
- Действия развертывания CloudFormation со встроенным просмотром наборов изменений.
- Единая поверхность аудита — CloudTrail плюс история выполнений CodePipeline, без кросс-вендорной корреляции.
- Отсутствие зависимости от внешнего SaaS — сбой GitHub не блокирует срочное исправление.
Цена: итерации медленнее. Изменение пайплайна — это отдельное обновление ресурса; локальное тестирование определения пайплайна неудобно; кросс-аккаунтные развертывания требуют тщательно продуманного доверия ролей, и ошибка приводит к ошибкам AccessDenied, которые трудно читать.
Если GitHub — ваш источник истины
Теперь возьмем стартап, где каждый инженер открывает PR на GitHub, ревью происходят там, и команда уже пишет YAML рабочих процессов для тестов и линтинга. Добавление CodePipeline означает переключение контекста на вторую систему для половины развертывания того же коммита.
GitHub Actions подходит лучше:
- Один файл, одно ревью — логика развертывания живет рядом с кодом, который она доставляет.
- Действия из Marketplace — уведомления в Slack, сканеры безопасности, помощники аутентификации в облаке.
- Быстрые итерации — редактируй, отправляй, смотри выполнение.
Цена — дисциплина. Многоразовые рабочие процессы и составные действия становятся обязательными после определенного размера команды, иначе вы получите двадцать почти идентичных файлов deploy.yml, которые расходятся. И небрежно написанная политика доверия OIDC — "sub": "repo:org/*" — позволяет любому репозиторию в организации принять вашу роль развертывания. Ограничьте ее repo:org/app:ref:refs/heads/main.
Решающие сигналы, по порядку
| Сигнал | Указывает на CodePipeline | Указывает на GitHub Actions |
|---|---|---|
| Источник истины | CodeCommit, S3, Bitbucket | GitHub |
| Требование аудита | Только CloudTrail, один вендор | GitHub уже принят как система учета |
| Механика развертывания | CodeDeploy, наборы изменений CloudFormation | Контейнеры, ECS, Lambda, синхронизация S3 |
| Кросс-аккаунт / локальная инфраструктура | Много учетных записей, гибридные раннеры | В основном одна учетная запись |
| Навыки команды | Специалисты по AWS | Разработчики, владеющие своими пайплайнами |
Распространенная ошибка: выбрать GitHub Actions ради скорости, а затем обнаружить, что команде комплаенса нужны доказательства развертывания в CloudTrail, а роль OIDC используется совместно пятью репозиториями. Обратная миграция — неделя работы, которую никто не планировал. Принимайте решение с учетом требований аудита с первого дня.
repo:org/*, эквивалентна общему паролю. Ограничьте утверждение sub конкретным репозиторием и веткой, а разрешения роли — только теми действиями, которые рабочий процесс действительно вызывает.
Где это ломается на практике
Оба подхода терпят неудачу одинаково: никто не владеет пайплайном. Развертывание, работавшее в прошлом месяце, падает, потому что роль была ротирована, AMI устарел или версия действия была объявлена устаревшей. Пайплайн — это код, а код требует тестов — дымового развертывания в промежуточной учетной записи при каждом PR, а не только при слиянии.
Если вы хотите углубиться в компромиссы на уровне платформы, лежащие в основе этих решений, разбор Облачная архитектура (AWS/GCP/Azure): как выбрать облако и не привязать себя к нему охватывает рассуждения о привязке к платформе, которые лежат под этим решением. Подробнее — в статье CI/CD как искусство.
Как люди на самом деле этому учатся
Чтение документации дает вам синтаксис. Оно не дает вам суждения, чтобы взглянуть на политику доверия и заметить дыру, или оценить, сколько времени займет настройка кросс-аккаунтного CodeDeploy. Это суждение приходит из создания обоих пайплайнов один раз, их поломки и сравнения режимов отказа.
Самостоятельное обучение работает, если у вас есть песочница и терпение отлаживать ошибки IAM в одиночку. Структурированный курс работает лучше, когда вы хотите получить обратную связь по своим решениям — потому что дорогие ошибки здесь архитектурные, а не синтаксические. Курс AWS DevOps Engineer — Professional (DOP-C02) проходит через CI/CD на AWS с практическими лабораториями и пробными экзаменами, что является одним из способов получить эту обратную связь, не сжигая производственную учетную запись. Подробнее — в статье DevOps и облачная инфраструктура.
Кому это подходит, а кому нет
Этот путь подходит инженерам, которые уже развертывают в AWS и хотят владеть пайплайном от начала до конца, и платформенным командам, стандартизирующим работу между учетными записями. Он не подходит тому, кто никогда не запускал сборку — начните с развертывания одного сервиса, затем вернитесь к сравнению. И если ваша организация уже стандартизировалась на одном инструменте по не зависящим от вас причинам, полезный навык — сделать этот инструмент безопасным, а не переключать его. Подробнее — в статье Платформенная инженерия.
Начните с одного пайплайна, который вы можете сломать намеренно. Создайте роль OIDC, ограничьте политику доверия, разверните hello-world, затем отзовите роль в середине выполнения и посмотрите, что произойдет. Это упражнение учит большему, чем любая сравнительная таблица — и это именно то решение, которое курс AWS DevOps Engineer — Professional (DOP-C02) создан помочь вам пройти, с лабораториями и обратной связью по вашим выборам.