AWSとGitHubの連携を徹底解説！成功の秘訣とは？

2025 11/29

2025/11/29

はじめに

本ドキュメントは、AWSとGitHubを連携してCI/CDパイプラインを構築するための手引きです。主にAWS CodeBuild、CodeDeploy、App Runner、Amazon CodeCatalyst、GitHub Actionsなどを使った実装例や設定手順、連携方法、注意点をやさしくまとめています。

目的

GitHubとAWSを安全かつ効率的に連携する方法を理解していただくこと。
自動ビルド・デプロイの基本的な流れを身につけること。

対象読者

開発者や運用担当者で、GitHubとAWSの基本操作ができる方。
これからCI/CDを導入したい方にも分かりやすい内容にしています。

本書の構成と読み方

本書は全8章で構成します。各章は順番に読むとスムーズに理解できますが、必要な章だけ参照することも可能です。第2章で全体像を掴み、第3章以降で具体的な手順や設定、注意点を詳しく解説します。

前提条件

AWSアカウントとGitHubアカウントを用意してください。
最低限の権限（リポジトリ操作とAWSの基本操作）が必要です。

以降の章で具体的な手順と設定例を丁寧に説明します。

GitHubとAWSの連携方法の全体像

概要

GitHubをコードの管理に使い、AWSでビルド・テスト・デプロイを行う流れが一般的です。ここでは代表的な連携方法と役割をやさしく説明します。

主な連携手段

CodeBuild：GitHubのソースを取得してビルドやテストを実行します。例：プルリクの自動テストに利用できます。
CodeDeploy：ビルド済み成果物をサーバやコンテナに自動で配置します。例：EC2やECSへのデプロイに使います。
App Runner：コードやコンテナイメージからアプリを自動で公開します。簡単にサービスを立ち上げたい場面で有効です。
Amazon CodeCatalyst：開発作業を一元管理する環境で、GitHub連携もサポートします。

接続方法の例

GitHub AppsやOAuthを使って認証・接続します。セキュリティのために最小権限の設定が基本です。
WebhookやGitHub Actionsでイベント（pushやPR）を受け、AWS側でビルドやデプロイをトリガーします。

運用上のポイント

権限は最小限にする、シークレットは安全に管理する、ログを残す、の3点を意識してください。

GitHub接続（AWS CodeConnections）の作成手順

前提条件

AWSアカウントとGitHubアカウントを用意します。管理者権限があると手続きがスムーズです。

コンソールでの手順（推奨）

AWS Management Consoleを開き、Developer Tools > Connections（またはCodeStar Connections）に移動します。
「Create connection」をクリックし、ProviderにGitHubを選びます。
「Connect to GitHub」を押すとGitHub側の認可画面が開きます。ここでAWS Connector for GitHub（インストール）が求められます。組織単位かリポジトリ単位かを選んでインストールしてください。
インストール後、コンソールに戻ると接続が作成され、ステータスが”Available”になります。

CLIでの手順

接続を作成する例：
aws codestar-connections create-connection –provider-type GitHub –connection-name my-github-connection
実行後に返る情報でConnectionArnとステータス（通常は PENDING_HANDSHAKE）を確認します。返されたURLでGitHub側の承認を完了するとステータスが”Available”になります。

接続確認と利用方法

コンソールの接続一覧でステータスを確認します。
CodeBuildやCodePipeline作成時にConnectionArnを指定すると、その接続経由でリポジトリを参照できます。

よくあるトラブルと対処

権限不足：GitHubでAWS Connectorのインストール権限を持つアカウントでログインしてください。
ステータスが変わらない：ブラウザで承認URLを再確認し、必要なら接続を削除して再作成してください。
GitHub Enterpriseを使う場合はホストURLやネットワーク設定を確認してください。

CodeBuildプロジェクトの作成と設定

準備

GitHub接続（CodeConnections）を作成済みであることを確認してください。リポジトリとブランチが分かっていると作業が早く進みます。

プロジェクト作成の手順

AWSコンソールで CodeBuild に移動し「プロジェクトを作成」します。
基本設定でプロジェクト名を入力します。
ソース設定
ソースプロバイダに「GitHub（GitHubアプリ）」を選びます。
認証情報タイプで「GitHubアプリ」を選択し、作成済みのCodeConnectionsを指定します。
対象リポジトリとブランチを選びます。
環境設定
マネージドイメージ（例: Ubuntu / standard）を選びます。
サービスロールは新規作成か既存を選択します。
ビルド仕様
ソースにbuildspec.ymlを置くか、インラインで記載します。以下は簡単な例です。

version: 0.2
phases:
  install:
    commands:
      - echo Installing
  build:
    commands:
      - echo Building

その他はデフォルトで作成して問題ない場合が多いです（アーティファクト、ログ、VPC設定など）。

動作確認

作成後にプロジェクトを手動で実行し、ソース取得フェーズのログでコードが取得できているか確認してください。buildspecのコマンドが実行されるかも合わせて確認します。

注意点

GitHubアプリにリポジトリアクセス権が付与されていることを確認してください。
プライベートリポジトリの場合、権限やブランチ指定を間違えないよう注意してください。
buildspec内のコマンドは実行環境に依存するため、環境イメージと整合性を取ってください。

GitHub ActionsとAWSの連携

概要

GitHub ActionsはGitHubのCI/CD機能で、OpenID Connect（OIDC）を使うと短時間の認証トークンで安全にAWSへアクセスできます。長期のアクセスキーを保存せずに済むため、セキュリティが向上します。

基本手順（簡潔）

AWS側でGitHubのOIDCプロバイダーを許可するか、既存の設定を確認します。
GitHubのワークフローから引き受ける実行用IAMロールを作成し、信頼ポリシーでGitHubの発行子（issuer）を指定します。sts:AssumeRoleWithWebIdentityを許可します。
最小権限のIAMポリシーを作成し、作業に必要な権限（例：ECRへのpush、S3、CodeBuild）だけを付与します。
作成したロールのARNをGitHubリポジトリのSecrets（例：AWS_ROLE_TO_ASSUME）に登録します。

ワークフローの例（要点）

例: ワークフロー中でaws-actions/configure-aws-credentialsを使い、role-to-assumeにARNを渡す。これによりアクション内でAWSコマンドやECRへのpushが可能になります。具体的には、checkout → configure-aws-credentials → docker build → docker push の流れになります。

注意点

ロールは最小権限で設計してください。監査ログで動作を確認し、不審なアクセスがないか定期的に確認します。
ワークフローのトークンや秘密情報を不要に増やさないことが安全運用の要です。

Webhookトリガーによる自動ビルド

概要

AWS CodeBuildはGitHubのWebhookを受けて自動でビルドを開始できます。リポジトリへのプッシュやプルリクエスト作成をトリガーにして、継続的なビルドを実行します。手動でのビルド開始が不要になり、変更の検証が速くなります。

設定手順（簡潔）

CodeBuildのプロジェクトを作成し、ソースにGitHub（またはGitHub Enterprise）を選択します。既に接続（CodeConnectionsなど）していると簡単です。
ソース設定で「Webhookを有効にする」をオンにします。ブランチやイベント（push、pull request）を選択してフィルタを設定します。
buildspec.ymlをリポジトリに置くか、プロジェクトでビルドコマンドを指定します。
GitHubへWebhookが自動で作成されるので、実際にコミットやPRを作成して動作を確認します。

トラブルシューティング

ビルドが始まらない場合は、GitHubのリポジトリ設定でWebhook配信履歴を確認してください。配信エラーやステータスコードを元に原因を特定します。
CodeBuildのビルドログはCloudWatchに出力されます。ログで失敗原因を確認します。

セキュリティと運用上の注意

フィルタで対象ブランチを限定してください。不要なビルドを減らせます。
フォークからのPRは機密情報（シークレットやアクセスキー）を扱わないよう注意してください。公開リポジトリや外部貢献者からの入力は特に気を付けてください。

実装時の注意点

要点

CodeBuild単体ではGit Tagなどでトリガーを精密にフィルタする機能がまだ十分ではありません。そのため設計段階で期待値を整理してください。

トリガーフィルタの現状と影響

例：リリースタグ（v1.0.0）だけでビルドを走らせたい場合、CodeBuildのWebhookだけでは直接フィルタできません。ブランチやPRは扱えますが、タグに関する扱いは限定的です。

回避策（具体例）

GitHub Actionsでタグ検出後にCodeBuildを呼ぶ。Actions内で条件分岐できます。
CodePipelineを使うとタグフィルタが使える場面があります。小規模な用途ではオーバーヘッドに注意。
Webhook受信Lambdaでpayloadを解析し、タグならCodeBuildをStartBuildする方法も有効です。

ログ・デバッグ

CloudWatch LogsとCodeBuildのビルドログを必ず有効にしてください。Webhookの受信ログ（API Gateway/Lambda）も残すと問題切り分けが早くなります。

権限とセキュリティ

最小権限のIAMロールを作り、必要なS3/KMS/Logsアクセスだけ与えてください。秘匿情報はSecrets ManagerやParameter Storeで管理します。

テストと段階的導入

まずは開発ブランチやダミータグで動作確認し、本番リポジトリへ段階的に適用してください。

まとめ

振り返り

本記事では、GitHubとAWSを連携するための主要な選択肢と手順を解説しました。例えば、短時間でビルドだけ自動化したい場合はCodeBuild、デプロイまで含めたい場合はCodeDeployやApp Runner、柔軟にワークフローを作りたい場合はGitHub Actionsが向きます。最新機能のCodeConnectionsを利用すると、認証や接続設定を簡単かつ安全に行えます。

選び方のポイント

目的を明確にする：ビルドのみ／デプロイ込み／短期プロジェクトなどで選びます。例：静的サイトならApp Runner、コンテナならCodeBuild＋CodeDeploy。
運用の手間：マネージドサービスほどセットアップは楽です。手元で細かく制御したければActionsを活用します。
セキュリティ：接続は最小権限で設定し、トークンやシークレットは集中管理してください。