AWS EC2でGitを使いこなす！連携から開発まで完全解説

EC2におけるGit/GitHub/GitLab連携の全体像と効率的な導入パス

クラウド時代の開発ワークフローとGitの重要性

現代のソフトウェア開発において、クラウドサービスの利用は不可欠な基盤となっています。日本企業におけるクラウドサービス利用率は2024年時点で80.6%に達しており（総務省「令和7年版 情報通信白書」）、AWS EC2はその中心的な存在です。EC2インスタンス上でGitやGitHub/GitLabを連携させることは、開発チームの生産性向上、コードのバージョン管理、共同作業の効率化に直結します。特に、大規模なプロジェクトや分散開発においては、コードの変更履歴を確実に追跡し、競合を解決するためのGitの役割は極めて重要です。

この連携により、開発者はEC2上でテストやデプロイを行いながら、コードベースを一元的に管理し、複数のメンバーが同時に作業を進めることが可能になります。また、Gitのブランチ戦略を活用することで、新機能の開発とバグ修正を並行して行い、安定したリリースサイクルを維持できます。クラウドとGitの組み合わせは、現代の開発ワークフローにおいて最も基本的な要素の一つと言えるでしょう。

セキュアなEC2-Git連携の進化：SSHからIAM/OIDCへ

EC2とGit/GitHub/GitLabを連携させる際、かつてはSSH鍵を使った認証が主流でした。しかし、この方法は鍵の管理が煩雑であり、誤って公開鍵を露出させてしまうとセキュリティリスクにつながる可能性があります。現在のベストプラクティスは、IAMロールやOIDC（OpenID Connect）を活用した「認証情報を持たないセキュアな連携」への移行です。

特に、GitHub ActionsのようなCI/CDツールからAWS EC2へアクセスする際には、OIDCを使用することで、長期的な認証情報を発行することなく、一時的な認証情報のみでAWSリソースを操作できるようになります（GitHub Changelog / 2021年10月27日）。これにより、セキュリティリスクを大幅に低減し、認証情報の漏洩や不正利用の可能性を最小限に抑えることが可能です。また、EC2インスタンスへの直接SSHアクセスを制限するため、AWS Systems Manager (SSM) Session Managerを利用することが推奨されます。SSMを用いることで、パブリックIPを持たないインスタンスにも安全に接続し、管理の簡素化も実現します。

導入パスの選択：小規模開発からCI/CDまで

EC2とGitの連携には、プロジェクトの規模や目的に応じて複数の導入パスが考えられます。小規模な開発や個人プロジェクトであれば、EC2インスタンスにGitをインストールし、SSH鍵を使ってGitHub/GitLabに手動で接続するアプローチから始めることができます。この場合も、SSH鍵のパーミッション管理や、EC2インスタンスのセキュリティグループ設定には十分な注意が必要です。

一方、チーム開発や本格的なCI/CD（継続的インテグレーション/継続的デリバリー）パイプラインを構築する場合は、OIDCを利用したGitHub ActionsやAWS CodeBuild/CodePipelineとの連携を検討すべきです。これにより、コードの変更がトリガーとなって自動的にテスト、ビルド、デプロイが実行されるようになります。いずれのパスを選択するにしても、初期段階からセキュリティを意識した設計を行うことが、長期的な運用における安定性と安全性を確保する上で非常に重要となります。

出典：総務省

EC2へのGit導入からGitHub/GitLab連携までステップバイステップ

Gitのインストールと初期設定

EC2インスタンス上でGitを使用するためには、まずGitのインストールが必要です。Amazon Linux 2などの一般的なOSでは、以下のコマンドで簡単にインストールできます。

sudo yum update -y
sudo yum install git -y

インストール後、Gitの初期設定を行います。これにより、コミット履歴に正しい開発者情報が記録されるようになります。

git config --global user.name "あなたの名前"
git config --global user.email "あなたのメールアドレス"

これらの設定は、今後の共同作業において誰がどの変更を加えたかを明確にするために不可欠です。適切な設定を怠ると、コミット履歴が不正確になり、後々の問題追跡が困難になる可能性があります。必ず最初に実施するようにしてください。

リモートリポジトリとの基本的な連携手順

Gitのインストールと設定が完了したら、GitHubやGitLabなどのリモートリポジトリと連携します。最も基本的な連携方法は、既存のリポジトリをクローンすることです。

git clone [リポジトリのURL]

もし新しいリポジトリを作成する場合は、以下の手順でEC2上のローカルリポジトリを初期化し、リモートリポジトリに追加、プッシュします。

mkdir my-project
cd my-project
git init
echo "Hello, Git on EC2!" > README.md
git add README.md
git commit -m "Initial commit"
git remote add origin [リモートリポジトリのURL]
git push -u origin master

リポジトリのURLは、GitHubやGitLabのWebインターフェースで確認できます。通常はHTTPSまたはSSH形式ですが、EC2から接続する場合は、HTTPSが一般的です。HTTPSの場合、初回プッシュ時にユーザー名とパスワード（またはPersonal Access Token）が求められます。SSHの場合、事前にSSH鍵の設定が必要です。

IAMロールとOIDCによるセキュアな認証設定

EC2インスタンスがGitHub/GitLabのリポジトリにアクセスする際、そしてGitHub ActionsなどのCI/CDツールがAWSリソースにアクセスする際、最も推奨されるのはIAMロールとOIDCを活用したセキュアな認証です。EC2インスタンスにIAMロールをアタッチすることで、インスタンスは一時的な認証情報を使用してAWSサービスにアクセスできるようになります。これにより、長期的なアクセスキーをインスタンス内に保存する必要がなくなり、セキュリティが大幅に向上します。

例えば、EC2がS3バケットにアクセスする必要がある場合、S3への読み書き権限を持つIAMロールを作成し、EC2インスタンスに紐付けます。Gitとの連携においては、GitHub ActionsからAWSリソースへのアクセスにOIDCを設定することが非常に有効です。これにより、ActionsはAWSとの信頼関係に基づいて一時的な認証情報を取得し、アクセスキーなしでデプロイなどの操作を実行できます。

目的別EC2活用術：CI/CDと開発環境構築の具体例

CI/CDパイプラインとEC2の連携

EC2はCI/CDパイプラインにおいて、ビルド、テスト、デプロイのステージを担う重要な役割を果たします。例えば、GitHub ActionsやAWS CodePipelineと連携させることで、コードがリポジトリにプッシュされるたびに、EC2インスタンス上で自動的にビルドが実行され、テストが走り、問題がなければ本番環境へのデプロイが行われるといったフローを構築できます。

この連携のポイントは、EC2インスタンスに適切なIAMロールを付与し、必要なAWSリソース（S3、ECS、Lambdaなど）へのアクセス権限を与えることです。また、ビルドやテストの実行環境として、DockerコンテナをEC2上で動かす構成も一般的です。これにより、開発環境とCI/CD環境の差異をなくし、再現性の高いビルド・テストを実現できます。セキュリティグループの設定も重要で、CI/CDツールからのアクセスに必要なポートのみを開放し、不要な通信は厳しく制限することが求められます。

開発環境としてのEC2：ベストプラクティス

EC2を開発環境として活用するメリットは、OS、メモリ、CPUなどのリソースを柔軟に選択できる点にあります。特に、複数の開発者が同じスペックの環境を必要とする場合や、特定のOSが必要な開発において非常に有効です。ベストプラクティスとしては、以下の点が挙げられます。

1. AMIの活用： 事前に必要なミドルウェアやツールをインストールしたAMI（Amazon Machine Image）を作成し、開発者ごとに同じ環境を迅速にプロビジョニングできるようにします。
2. Session Managerの利用： SSH鍵管理の負担を減らし、セキュアにEC2インスタンスへアクセスするために、AWS Systems Manager (SSM) Session Managerを使用します。これにより、インバウンドポートを開放せずに接続が可能です。
3. EBSの分離： コードやデータはEBSボリュームとして分離し、インスタンスの停止や再起動、AMI作成時にもデータが永続的に保持されるようにします。
4. セキュリティグループ： 開発者のIPアドレスからのアクセスのみを許可するなど、最小限のアクセスに制限します。

これらのプラクティスを導入することで、開発環境の構築と管理が効率化され、セキュリティリスクも低減されます。

環境分離とリソース最適化の考え方

開発環境、ステージング環境、本番環境といったように、目的別にEC2インスタンスを分離することは、堅牢なシステム運用において極めて重要です。各環境は異なるセキュリティグループ、ネットワークACL、IAMロールを持つべきです。これにより、ある環境での問題が他の環境に波及するリスクを最小限に抑えられます。

リソース最適化の観点からは、EC2インスタンスのタイプとサイズを適切に選択することが重要です。開発環境では、コストを抑えるために小規模なインスタンスタイプを選び、必要な時にのみ起動する運用モデルを検討できます。CI/CDのビルドエージェントであれば、短期間に高い処理能力が必要となるため、一時的に高性能なインスタンスを使用し、タスク完了後に停止するといった戦略が有効です。また、オートスケーリンググループを導入することで、負荷に応じてインスタンス数を自動調整し、コストとパフォーマンスのバランスを取ることが可能です。

出典：AWS Documentation

EC2 Git連携で避けたい落とし穴とトラブルシューティング

認証情報の管理ミスとセキュリティリスク

EC2とGitの連携において、最も危険な落とし穴の一つが認証情報の不適切な管理です。SSH秘密鍵やGitHub/GitLabのPersonal Access Token（PAT）をEC2インスタンスに直接ハードコーディングしたり、不適切なパーミッションで保存したりすると、情報漏洩のリスクが高まります。もしインスタンスが侵害された場合、これらの認証情報が悪用され、リポジトリへの不正アクセスやAWSリソースの乗っ取りにつながる可能性があります。

このリスクを避けるためには、前述のIAMロールやOIDCの活用が不可欠です。やむを得ず認証情報をEC2インスタンス内に置く場合は、AWS Secrets ManagerやAWS Systems Manager Parameter Storeのようなセキュアなサービスに保存し、インスタンスから必要な時に動的に取得する仕組みを構築すべきです。また、SSH秘密鍵のパーミッションはchmod 400など、所有者のみが読み取り可能な状態を厳守してください。

ネットワーク設定とセキュリティグループの罠

Git/GitHub/GitLabへのアクセス、または外部からのEC2へのアクセスにおいて、ネットワーク設定とセキュリティグループは頻繁にトラブルの原因となります。特に、以下のような状況は注意が必要です。

• アウトバウンドルールの不足： EC2インスタンスからGitHub/GitLabへのHTTPS（ポート443）またはSSH（ポート22）接続が、セキュリティグループのアウトバウンドルールで許可されていない場合、git cloneやgit pushが失敗します。
• インバウンドルールの過剰な開放： 開発環境のEC2インスタンスにSSHでアクセスするため、セキュリティグループのポート22を0.0.0.0/0（全許可）にしてしまうと、インターネットからの攻撃に晒される危険性が高まります。AWS Systems Manager (SSM) Session Managerを使用するか、特定のIPアドレスからのアクセスのみを許可するよう厳格に設定してください。
• VPCエンドポイントの誤設定： プライベートネットワーク内でGitHub EnterpriseやGitLab CE/EEを利用している場合、VPCエンドポイントの設定ミスにより、Git操作ができないことがあります。DNS解決やルーティングテーブルを確認する必要があります。

トラブルシューティングの際は、まずセキュリティグループとネットワークACLのインバウンド/アウトバウンドルールを徹底的に確認することが重要です。

一般的なエラーメッセージとその解決策

Git連携で遭遇しやすい一般的なエラーとその解決策をいくつか紹介します。

1. Permission denied (publickey)： SSHキーでの認証に失敗しています。EC2インスタンスに正しい秘密鍵が配置されているか、ssh-agentに鍵が追加されているか、鍵のパーミッションが400になっているかを確認してください。また、GitHub/GitLab側で公開鍵が正しく登録されているかも確認が必要です。
2. fatal: repository '...' not found： リポジトリURLが間違っているか、アクセス権限がありません。URLが正しいか、プライベートリポジトリであればIAMロールやSSHキー、Personal Access Tokenによる認証が正しく行われているか確認してください。
3. fatal: unable to access '...': Could not resolve host: ...： DNS解決に失敗しています。EC2インスタンスからインターネットへの接続が許可されているか、DNS設定が正しいかを確認してください。一時的なネットワークの問題の可能性もあります。

これらのエラーメッセージは、問題を特定するための重要な手がかりとなります。メッセージの内容をよく読み、一つずつ確認作業を進めていくことが解決への近道です。

【ケース】権限不足によるクローン失敗から学ぶIAMロール設計

架空のケーススタディ：権限不足でプロジェクトが停止

とある開発チームで、新しくデプロイ用のEC2インスタンスを立ち上げ、GitHubから最新のアプリケーションコードをクローンしようとしたところ、fatal: repository 'my-application' not foundというエラーが発生し、クローンに失敗しました。このEC2インスタンスは、デプロイ後のアプリケーションがS3バケットにログを書き込むためのIAMロールが付与されていましたが、GitHubへのアクセス権限は考慮されていませんでした。チームは急遽デプロイを進める必要があり、誤ってインスタンス内にGitHubのPersonal Access Tokenを直接記述してしまい、一時的に解決したものの、後にそのトークンが漏洩するリスクを抱えることになりました。

この架空のケースでは、プロジェクトの進行を優先するあまり、セキュリティと適切なIAMロール設計が見落とされた結果、トラブルと潜在的なリスクを生んでしまいました。権限不足によるクローン失敗は、プロジェクトの停止だけでなく、焦りから不適切な対応につながる典型的な例です。

IAMロールの適切な設計と最小権限の原則

このケースから学ぶべきは、IAMロールの適切な設計と最小権限の原則です。EC2インスタンスに付与するIAMロールは、そのインスタンスが実行するタスクに必要な最小限の権限のみを持つべきです。上記のケースでは、S3への書き込み権限は適切でしたが、GitHubからコードをクローンする権限が不足していました。

具体的な解決策としては、GitHubへのアクセス方法に応じた権限をIAMロールに追加することが考えられます。もしGitHub ActionsとOIDCを組み合わせてEC2へデプロイする場合、EC2自体はGitHubに直接アクセスする必要がないため、IAMロールにGitHubアクセス権限は不要です。しかし、EC2上でビルドを行い、そのビルド結果をGitHubにプッシュするような特殊なケースでは、SSHキーの管理やHTTPSでのPAT利用を検討し、それらをセキュアに管理するための権限（例: Secrets Managerから認証情報を取得する権限）をIAMロールに含める必要があるかもしれません。

重要なのは、インスタンスの「役割」を明確にし、その役割を果たすために必要な最小限の権限だけを付与することです。不要な権限を与えてしまうと、万が一インスタンスが乗っ取られた際の被害範囲が拡大する可能性があります。

トラブル発生時の原因究明と対策

IAMロールに関するトラブルが発生した場合、原因究明と対策は以下のステップで行うことができます。

1. エラーメッセージの確認： Gitのエラーメッセージがrepository not foundなのか、Permission deniedなのか、あるいはネットワーク関連なのかをまず確認します。
2. IAMロールの確認： EC2インスタンスにアタッチされているIAMロールのポリシーを確認し、GitHub/GitLabへのアクセスや、関連するAWSサービスへの権限が不足していないかを確認します。例えば、GitHub ActionsでOIDCを使用している場合、AWS側のIAMロールとGitHubのワークフローでの設定が正しく紐付いているかを確認します。
3. セキュリティグループの確認： EC2インスタンスからGitHub/GitLabへのアウトバウンド通信（HTTPS/SSH）が許可されているかを確認します。
4. 認証情報の確認： もしSSHキーやPersonal Access Tokenを使用している場合、それらがEC2インスタンスに正しく配置され、パーミッションが適切に設定されているか、有効期限切れではないかを確認します。
5. AWS CloudTrailの活用： AWSサービスへのAPIコール履歴をCloudTrailで確認することで、どの権限でアクセスが拒否されたか、具体的なエラーイベントを特定できる場合があります。

これらの手順を通じて、問題の根本原因を特定し、最小限の権限でセキュアな解決策を適用することが、安全かつ効率的な運用につながります。

出典：AWS Documentation