先日、まったくの新規 AWS アカウントに社内検証で利用する Backend API を複数デプロイする機会がありました。一時的な利用であり CI / CD など凝ったものは必要なかったので App Runner や EC2 に直接展開するなどで対応しました。その数週間後 ECS Express Mode が発表され、またひとつ AWS 上でコンテナワークロードを運用する選択肢が増えたことで、ふと思いました。ECS Express Mode の登場も踏まえて、先日のように全くの新規の状態かつコンテナで動くアプリのみがある場合に、どの AWS サービスを使うと一番早く・楽に構築できるのだろうか、と。
ということでサービスのおさらいも兼ねて実際に動かして確認してみましたので、軽い読み物として見ていただけると幸いです。
前提
- 今回対象とするアプリケーションは、golang で書かれた Backend API とする
- Dockerfile とアプリケーションソースコードがある状態からスタートする
- データベース（RDS）は用意しないが、あとで簡単に接続できるかどうかは評価に含める
- 頻繁にアクセスされない（恒常的にアクセスがあるわけではない）
- 本番の運用は想定しない（CI / CDやIaC、モニタリングなどは考慮しない）
- 料金は2025/12現在のオレゴンリージョンの価格で計算する
検証するサービス
今回は以下のサービスで検証してみます。
- ECS Express Mode
- App Runner
- Elastic Beanstalk
- Lightsail
他にもコンテナアプリケーションを運用できるサービスはありますが、EKS や ROSA は明らかに too much であること、Lambda はコードの書き方が変わってしまうので今回除外しています。
評価軸
早さだけではなくそのまま本番運用するには...みたいな視点もあるといいかもしれませんが、今回はあくまで早い安いうまい（？）にこだわります。
- 早い（時間）
- 利用できるようになるまでの時間（目安）
- 早い（手数）
- 利用できるようになるまでの操作数（目安）
- 安い
- 1日あたりのコスト
- うまい
- 他のサービスとの連携のしやすさ
結果
先に結果です。諸々主観が含まれる点ご注意ください。RDS と接続する想定があるのであれば ECS Express Mode、なければ App Runner がよさそうです。
| サービス名 | 早い（時間） | 早い（手数） | 安い | うまい |
|---|---|---|---|---|
| ECS Express Mode | ○（約11分） | ◎（一番すくない） | △（$2） | ○（拡張性あり） |
| App Runner | ◎（約9分） | ○（シュッとできる） | ○（$0.4） | △（RDS周りがネック） |
| Elastic Beanstalk | △（約18分） | △（色々必要） | ◎（$0.25） | ○（拡張性あり） |
| Lightsail | △（約22分） | △（色々必要） | ○（$0.32） | ○（Lightsailの仕組みの中では拡張性あり） |
ECS Express Mode
最新機能ですね。最新機能だけど ECS はもうこれがデフォルトになっています。すごい。
構築手順
1. ECR リポジトリ の作成と push（5分）
まずコンテナイメージを ECR に格納する必要があるのでリポジトリの作成とイメージの push を行います。
リポジトリを作成し、プッシュコマンドを表示します。
aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin xxxxxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com
docker build -t golang-api .
docker tag golang-api:latest xxxxxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com/golang-api:latest
docker push xxxxxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com/golang-api:latest
2. サービスの作成（6分）
ECS Express Mode はコンソールで作成する場合はイメージ名だけで作成できてしまいます。
（「画像を選択」になっている...）
コンテナの設定上ポートとヘルスチェックパスだけ指定します。
作成からサービスが利用可能になるまで約6分かかりました。APIが正常に稼働しています。
コスト
デフォルトの構成だと以下で起動します。
- 1vCPU、2GB の Fargate タスクが1つ
- ALB（アクセスはほとんどなし = 稼働時間課金のみの想定）
1日あたり $2 あれば収まりそうです。
出来上がったもの
上記の通り、ECS（Fargate） と ALB が出来上がっています。VPC は指定しなければデフォルトの VPC が使われるので、このあと RDS を追加する場合はプライベートサブネットを作るなどが必要になりそうです。
App Runner
機能強化が望まれている App Runner です。先日初めて使ってみました。
構築手順
1. ECR リポジトリ の作成と push（5分）
ECS Express Mode と同様なので省略します。
2. サービスの作成（4分）
アプリケーション名、ECR のリポジトリだけが最低限必要なパラメータです。
例によってヘルスチェックだけ変更しておきます。
作成からサービスが利用可能になるまで約4分かかりました。ECS Express Mode よりちょっとはやい？
コスト
デフォルトの構成だと以下で起動します。
- 1vCPU、2GB のタスクが1つ
- プロビジョンドの料金
- $0.336
- 実行時間1時間として
- $0.064
- プロビジョンドの料金
1日あたり $0.4 ほどになりそうです。ECS と異なりアクセスがなければ vCPU 料金がかからないんですね。アクセスが少なければ安い、というのはいいですね。
出来上がったもの
ECS Express Mode とは異なり、ALB などは隠蔽されています。利用者から見えるのはあくまで「App Runner のサービス」のみです。
RDS と接続するのには一工夫必要です。送信ネットワークからカスタム VPC コネクタを作成する必要があります。
その他の特徴として、 WAF の設定ができるようになっています。
Elastic Beanstalk
Elastic Beanstalk で Docker コンテナを稼働させる場合、2種類のプラットフォームがあります。
- Docker
- ECS
今回は ECS を使ってやってみます。
構築手順
1. ECR リポジトリの作成と push（5分）
ECS Express Mode と同様なので省略します。
2. Dockerrun.aws.json の作成（3分）
ECS プラットフォームを利用する場合には Dockerrun.aws.json という設定ファイルが必要です。いわゆるタスク定義ですね。Kiro に書いてもらいました。
{
"AWSEBDockerrunVersion": 2,
"containerDefinitions": [
{
"name": "go-api-app",
"image": "XXXXXXXXXXX.dkr.ecr.us-west-2.amazonaws.com/golang-api",
"essential": true,
"memory": 512,
"portMappings": [
{
"hostPort": 80,
"containerPort": 8080,
"protocol": "tcp"
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/aws/elasticbeanstalk/go-api-app",
"awslogs-region": "us-west-2",
"awslogs-stream-prefix": "ecs"
}
},
"environment": [
{
"name": "PORT",
"value": "8080"
}
],
"healthCheck": {
"command": [
"CMD-SHELL",
"wget --no-verbose --tries=1 --spider http://localhost:8080/health || exit 1"
],
"interval": 30,
"timeout": 5,
"retries": 3,
"startPeriod": 60
}
}
]
}
3. 環境の作成（10分）
ここから、Elastic Beanstalk の環境を作っていきます。まずはアプリケーション名を設定します。
次にプラットフォームを選択し、先程の json ファイルをアップロードします。
EC2 インスタンスプロファイルには一工夫必要で、EC2 が ECR にアクセスする権限を別途足してあげる必要があります（ここでは省略します）。
サービスが利用可能になるまでは約4分かかりました。早い方です。
コスト
Elastic Beanstalk 自体の料金はかからないため、EC2 の稼働分だけです。t3.micro 1台なので1日あたり $0.25 です。安い。
出来上がったもの
ECS コンソールにいくとクラスターが出来上がっています。サービスはなく、タスクのみですね。
もちろん、コンテナインスタンスが EC2 で稼働しているのも見られます。
Elastic Beanstalk を使うとこんな感じになるのか、という発見はありましたが今回の用途だけでいうと完全に ECS のラッパーみたいな感じになってしまっており、良さが活かせなかった印象でした。
Lightsail
さてこれも未知のサービスです。ダークホースとなるか？
構築手順
1. ECR リポジトリの作成と push（5分）
ECS Express Mode と同様なので省略します。
2. デプロイメントの作成
さて、Lightsail でコンテナサービスを作成していきます。コンソールがかわいい。
キャパシティにはプリセットが用意されています。他と同様デフォルトの構成でいきます。
ECR のコンテナイメージを指定しようとすると、警告が表示されました。まずはなんでもいいのでデプロイしてサービスを作らないとダメとのこと。
やむなし、Hello World アプリケーションをデプロイします。
最初のデプロイが完了するまで7分ほどかかりました。サンプルアプリが表示されます。
そのあと ECR private repository の設定を行います。
設定が完了するまで5分ほどかかりました。
さて、最初にデプロイしたサンプルアプリを変更して、ECR に格納されているコンテナイメージをデプロイします。
デプロイは5分ほどで完了し、API が利用可能になりました。
コスト
先程の設定通り、デフォルトだと Micro が選択されており、1日あたりだと約 $0.32 になります。
出来上がったもの
Lightsail はその中でコンピュートやデータベースなどを設定できる、ある意味他の AWS サービスと分離したような形になっていそうです。ということでもちろん外からリソースを見ることはできません。この中で完結できる仕組みであればまとまっていてよさそうですね。
まとめ
今回、普段触らないサービスも含めてコンテナを最速でデプロイできるのはどれか、という検証をしてみました。結果としてはやはり ECS Express Mode がデプロイまでの早さと拡張性においてバランスがとれているな、という印象です。今回割と限定的な軸で比較したため、Elastic Beanstalk などデプロイやスケールといった周辺の機能が整えられているサービスが不利になった感覚もあります。軸の内容はさておき、ある基準をもってサービスを比較するとそれぞれの思想が垣間見え今後の選択にも役立ちそう、という学びがありました。