3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Bitbucket PipelinesとCodePipelineを活用したECS(Fargate)自動デプロイ環境の構築

3
Last updated at Posted at 2026-09-30

Bitbucket PipelinesとCodePipelineを活用したECS(Fargate)自動デプロイ環境の構築

概要

株式会社Kaienで社内SEとして働いています。
現在、弊社ではオンプレミス環境や既存環境からAWSへの移行を進めており、私はその中で開発環境のCI/CDパイプライン設計を担当することになりました。

本記事では、Bitbucketでソースコードを管理し、マージをトリガーにしてAmazon ECS (Fargate) へ自動的にデプロイする一連のアーキテクチャについてご紹介します。

対象読者

  • AWSへの移行やECS (Fargate) の導入を検討している方
  • Bitbucket Pipelinesを使ったCI/CD環境を構築したい方
  • IAMアクセスキーを使わず、OIDCを利用したセキュアなAWS連携に興味がある方

アーキテクチャの全体像

設計したCI/CD環境のアーキテクチャは以下の通りです。

image.png

開発者が main ブランチにコードをマージすると、BitbucketからAWS環境へのデプロイが自動で実行される仕組みとなっています。

処理の流れ

大きく分けて「Bitbucket側でのビルド・プッシュ」と「AWS側での自動デプロイ」の2つのフェーズで構成されています。

1. Bitbucket PipelinesによるECRへの自動プッシュ

  1. コードのマージ
    Developerがソースコードを変更し、Bitbucketの main ブランチへマージします。これをトリガーにBitbucket Pipelinesが起動します。
  2. OIDCを利用したAWS認証
    パイプラインからAWS環境へアクセスする際、アクセスキー(長期クレデンシャル)を持たせるのではなく、OIDC (OpenID Connect) を利用した一時的な認証を行います。これにより、シークレット漏洩のリスクを減らし、セキュアな連携を実現しています。
  3. ECRへのイメージプッシュ
    アプリケーションのコンテナイメージをビルドし、AWSのフルマネージドコンテナレジストリである Amazon ECR へ自動でプッシュします。

2. AWS CodePipelineによるFargateへの自動デプロイ

  1. EventBridgeによる更新検知
    ECRに新しいイメージがプッシュされたことを、Amazon EventBridge がイベントとして検知します。
  2. CodePipelineの起動
    EventBridgeの検知をトリガーとして、AWS CodePipeline が自動的に起動します。
  3. Fargate (ECS) へのデプロイ
    CodePipelineは、アーティファクトの保存先としてS3を利用しつつ、VPC内のPrivate subnetに配置された Amazon ECS (Fargate) に対して最新のコンテナをデプロイ(ローリングアップデート)します。
  4. CloudWatchによる監視
    Fargate上で稼働するアプリケーションのログやメトリクスは、Amazon CloudWatch に集約され、開発者がいつでも確認・監視できる状態になっています。

設計のポイント

  • セキュリティの強化: BitbucketとAWSの連携において、近年推奨されているOIDC連携を採用しました。アクセスキーのローテーション管理の手間が省け、セキュリティも向上します。
  • 完全マネージドサービスの活用: Fargateを利用することでEC2インスタンスのホスト管理(OSのパッチ当てなど)から解放され、インフラ運用コストを最小限に抑えつつスケーラブルな環境を構築できました。

導入してみての所感と今後の課題

この仕組みを導入したことで、デプロイ自体は完全に自動化され、属人化の排除やミスの削減といった大きなメリットを得ることができました。

一方で、実際に運用を開始してみると、デプロイにかかる手間とコストが意外と大きいという新たな課題にも気づきました。具体的には以下のような点です。

  • 時間的なコスト(手間): コンテナイメージのビルドや、ECSでのタスクの切り替え(ローリングアップデート)に想定以上の時間がかかり、ちょっとした修正での頻繁なデプロイが少し億劫に感じることがあります。
  • 金銭的なコスト: Pipelineの実行時間やデータ転送料、増え続けるECRの保存容量など、CI/CD環境を維持・実行するための従量課金コストが、塵も積もればで無視できない額になってきます。

自動化の恩恵は確実に受けているものの、今後は「Dockerビルドのキャッシュ最適化による時短」や「ECRのライフサイクルポリシー設定による不要イメージの削除」など、パフォーマンスとコストの両面から継続的なチューニングを図っていく必要があると感じています。

おわりに

今回は、BitbucketとAWSを組み合わせたECS (Fargate) への自動デプロイパイプラインの全体像と、実際の導入所感について解説しました。

おわりに

今回は、BitbucketとAWSを組み合わせたECS (Fargate) への自動デプロイパイプラインの全体像と、実際の導入所感について解説しました。

私自身、実務でAWS環境の設計や構築に携わる中で、より体系的な知識を深めたいと感じ、先日 AWS Certified Developer - Associate (DVA) を受験し、無事に合格することができました!

次回の記事では、このAWS DVA試験合格までの学習法や、試験の振り返りについてまとめたいと考えています。

同様のAWS移行やCI/CD環境の構築に悩んでいる方の参考になれば幸いです。もし、より良い構成案やコストダウンのベストプラクティスなどがあれば、ぜひコメントでご意見をいただけると嬉しいです!

3
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?