【AWS移行】ECS/Fargateでアプリ運用・バッチ・DBマイグレーションまで一括解決。開発環境のアーキテクチャ設計まとめ

Last updated at 2026-07-29Posted at 2026-07-29

この記事の対象読者

はじめまして

株式会社Kaienで社内SEとして働いているエンジニアです。

現在弊社では、既存システムからAWSへの移行プロジェクトを推進しており、今回私は開発環境のインフラ設計を担当しました。

設計にあたり、運用負荷の軽減と柔軟性を重視して AWS Fargate（Amazon ECS）を採用しました。本記事では、作成した構成図をもとに、セキュリティや運用の工夫、そしてFargateをフル活用するためのポイントをご紹介します。

今回設計した開発環境のアーキテクチャは以下の通りです。
ユーザーアクセス経路のセキュリティ確保、デプロイフロー、各種AWSマネージドサービスとの連携、さらには外部SaaS（kintone）との通信までをまとめています。

AWS Fargate (Amazon ECS)
- プライベートサブネット内に配置し、インターネットから直接アクセスできない安全な環境でタスクを稼働させています。
Amazon ECR
- 開発者がビルドしたコンテナイメージを格納。Fargateは適切なIAM Role権限を用いてイメージをプルします。
Amazon Aurora PostgreSQL
- データベースもプライベートサブネット内に配置し、Fargateからの通信のみを許可する構成としています。
AWS Secrets Manager & AWS KMS
- DB接続情報やAPIキーなどの機密情報をKMSで暗号化して保管し、Fargateタスク起動時に安全に取得します。
Amazon CloudWatch
- コンテナの標準出力ログやパフォーマンスメトリクスを一元収集・監視します。

NAT Gateway
- プライベートサブネット内のFargateから、外部サービスである kintone 等へアウトバウンド通信を行うため、パブリックサブネット経由で安全に接続できる経路を確保しています。

今回の設計で一番こだわったのは、「AWS Fargateにマルチな役割を持たせた」点です。

Fargateを単なるWebサーバーとして使うだけでなく、同じ基盤上で以下の3つの用途をすべてカバーできるように設計しました。

用途	設計・実行アプローチ
Webアプリケーション運用	`ALB` の後段で常駐タスクとしてリクエストを処理
バッチ処理	定期実行やオンデマンド処理の際、必要な時だけFargateタスク（単発タスク）として起動・実行
DBマイグレーション	アプリのデプロイ前や環境構築時に、マイグレーション用のコンテナタスクを一時的に実行

導入の効果
コンテナ基盤をECS/Fargateに統一したことで、「バッチ用に別のEC2インスタンスを立てる」「マイグレーション用の踏み台サーバーを用意する」といった無駄なリソースや運用コストを大幅に削減できました。

EC2ベースのECSではなく、サーバーレス構造である AWS Fargate を選択したメリットは非常の大きさがあります。

インフラ・OSの管理コストがゼロ（運用負荷の軽減）
- 社内SEとして最も嬉しいポイントです。EC2のOSパッチ適用、キャパシティ計画、セキュリティ管理などの保守業務から解放され、本質的な業務に集中できます。
高いセキュリティ性
- タスクごとに独立した実行環境が割り振られるため、プライベートサブネット内での安全な運用が容易です。
無駄のないコストパフォーマンス
- 特にバッチ処理やマイグレーション処理において、タスクが実行されている「時間・リソース分」しか課金されないため、開発環境における無駄なコストを最小限に抑えられます。

第一弾となる本記事では、AWS移行に伴う開発環境インフラのアーキテクチャ設計について解説しました。

AWS Fargateを中心とした構成にしたことで、以下のメリットを実現できました。

社内SEとして運用負担を増やさずに、開発者が快適かつ安全に扱える環境が整ったと感じています。

続く第二弾では、Bitbucket Pipelinesを利用したデプロイメント機能について執筆する予定です。

上記について詳しく解説しますので、次回もぜひご覧ください！

これからAWSへの移行やコンテナ化（ECS/Fargate）を検討されている方の参考になれば幸いです。