【CLI版】Azure経験者がAWS ECSで同じ構成を作ってみる① ～基盤準備編～

今回はAWS ECSサービスに関する記事です。
Azure のコンテナサービス(App Service)をAWSへ移植するために必要な構成を解説していきます。

本記事はシリーズ構成の第一弾として、設計やIAM準備の部分を解説します。

元のマネコン版はコチラ⇩

【マネコン版】Azure経験者がAWS ECSで同じ構成を作ってみる① ～基盤準備編～

今回はAWS ECSサービスに関する記事です。Azure のコンテナサービス(App Service)をAWSへ移植するために必要な構成を解説していきます。本記事はシリーズ構成の第一弾として、設計やIAM準備の部分を解説します。CLI版も作…

addache.net

2026.07.24

【CLI版】Azure経験者がAWS ECSで同じ構成を作ってみる① ～基盤準備編～

構成図

モデル構成を提示します。
左のAzure構成を、AWS構成（右のイメージ）へ
変換します。

画像の通り、Azureで構成したほうが部品は少なく済みます。
ただコレだけで「コンテナ展開はAzureのほうが向いている」とは言えません。

AWS構成は複雑になる代わり、
部品を細かくチューニングできる

コンテナ周りは両クラウドそれぞれ一長一短とお考えください。

Azure ⇔ AWS の技術変換表

Azureではナチュラルに利用できていたものが
AWSでは個別定義が必要なケースがあります。
　※代表的なものとして、コンテナのDNS名

以下の変換表に沿って実装していきます。

Azure	AWS
App Service	ECS Fargate
Storage Account Static Website	S3 Static Website
Table Storage	DynamoDB
EntraID アプリの登録	IAM User AccessKey
Managed Identity	IAM Role
App Service URL	ALB + Route53

実装内容

以下のサービスおよび機能の設定を行っていきます。

1. Route53
2. IAMロール
3. DynamoDB
4. ECR
5. S3
6. IAMユーザー
7. GitHub
8. SEG
9. ECSクラスター
10. ECSタスク定義
11. ECS Service
12. ALB
13. DynamoDB項目追加

長くなるので記事を分割します。
今回は事前準備にあたる部分(1-5)を設定していきます。

イメージは以下。

各種構築

Route53

サブドメインをAWSへ移譲し、今後ECSやS3を独自ドメインで公開できるようにします。

後でALBを利用するので、何かしらRoute53のドメインが必要となります。

本記事では新たにドメインを取得するのではなく、
元々持っているドメインへ「サブドメイン」を作成して、
今回の検証に利用します。

新たにドメイン取得するなら「サブドメイン権限移譲」は不要です。
クラウドSEとして
自分用ドメインをひとつ持っておくと
以下手順のように使いまわしが出来るので重宝しますよ！

■AWS内でのサブドメイン移譲設定　～サブドメイン作成～

• 元のホストゾーン：blog.addache.jp
• サブドメインのホストゾーン名：test.blog.addache.jp
  ※上記は筆者環境でのみ利用できるものです。
  　皆さまの環境へと置き換えてください
• タイプ：パブリックホストゾーン
• ホストゾーン作成後、払い出された NSレコード を控えます。

また画像のようにDNSの有効確認を行うためのAレコードをひとつ作成しておきます。
※サンプルはaaa.test.blog.addache.jp です。
　IPアドレスは適当な値(例：192.168.1.1)でOK。

■AWS内でのサブドメイン移譲設定　～サブドメイン権限委譲～

続いて、元のホストゾーンへも設定を行っていきます。

• レコード種別：NS
• ホスト名：test
• 値：Route53ホストゾーン作成時に払い出された4つのネームサーバ

設定を行ったら、コマンドプロンプトなどで名前解決ができるかチェックします。

# コマンド例 GoogleのDNSへ問い合わせを投げる
nslookup aaa.test.blog.addache.jp 8.8.8.8

このように、応答が返ってきたらサブドメイン権限委譲成功です。

CloudShellで構築するための準備

AWS CloudShellの Bash を使用します。
画面右上のリージョンは東京 (ap-northeast-1) を選択します。

IAM／DynamoDB／ECR／S3の作成、ポリシーの設定と参照ができる権限を持つユーザーで
AWSへログインしてください。
一括実行SHでは、設定するアカウントIDとログイン中のアカウントを照合してから実行します。

本記事ではAWSリソースを作成し、サンプルのWeb画面を公開するところまでを
ハンズオン形式で進めます。

構築用ファイルを取得する

CloudShellを開き、Bashへ切り替えてから以下を実行します。
まずは構築用の資材を入手します。(筆者のGithub上に格納しています)

# 資材用のディレクトリ作成
mkdir -p ~/aws-ecs-11/web
cd ~/aws-ecs-11
umask 077

# 資材のダウンロード
BASE_URL='https://raw.githubusercontent.com/addache/addache-blog-assets/main/aws-ecs-11'
curl -fSLo setup.sh "$BASE_URL/setup.sh"
curl -fSLo settings.example.sh "$BASE_URL/settings.example.sh"
curl -fSLo web/index.html "$BASE_URL/web/index.html"
curl -fSLo web/app.js "$BASE_URL/web/app.js"

取得したファイルは以下の4つです。

ファイル	用途
setup.sh	リソース作成・権限設定などを行うスクリプト
settings.example.sh	設定値のサンプル
web/index.html	S3へ配置するHTMLファイル
web/app.js	Web画面からAPIを呼び出すJavaScriptファイル

☆GitHubでファイル一式を確認する☆

続いて、AWSアカウントIDを取得して、設定ファイルへ記述します。

# AWSアカウントIDを取得
if [[ ! -f settings.local.sh ]]; then
  cp settings.example.sh settings.local.sh
fi
chmod 600 settings.local.sh
(
  set -euo pipefail
  ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text --no-cli-pager)"
  [[ "$ACCOUNT_ID" =~ ^[0-9]{12}$ ]] || { echo '12桁のAWSアカウントIDを取得できませんでした。' >&2; exit 1; }
  [[ "$(grep -c '^AWS_ACCOUNT_ID=' settings.local.sh)" == 1 ]] || { echo '設定ファイルのAWS_ACCOUNT_ID行を確認してください。' >&2; exit 1; }
  sed -i "s|^AWS_ACCOUNT_ID=.*$|AWS_ACCOUNT_ID='$ACCOUNT_ID'|" settings.local.sh
  printf '設定ファイルへAWS_ACCOUNT_ID=%sを保存しました。\n' "$ACCOUNT_ID"
) && nano settings.local.sh

「REPLACE_WITH_12_DIGIT_AWS_ACCOUNT_ID」部分が
AWSアカウントIDに置き換わっていることを確認してください。

nanoでは Ctrl＋O → Enter で保存、Ctrl＋X で終了します。

設定値を編集する

パラメータを変更する場合は、エディタを開いて編集します。

nano settings.local.sh

初期値は以下のようになっています。
ロール名などを変更する場合は、コチラを参考に編集してください。

# AWS CloudShell (Bash). Copy to settings.local.sh and edit that copy.
# The preparation commands fill AWS_ACCOUNT_ID using STS and sed.
AWS_ACCOUNT_ID='REPLACE_WITH_12_DIGIT_AWS_ACCOUNT_ID'
AWS_REGION='ap-northeast-1'

# Use unused names. Existing resources are not overwritten by this sample.
EXECUTION_ROLE_NAME='ecs-task-execution-role'
TASK_ROLE_NAME='ecs-task-role'
DYNAMODB_TABLE='ecs-sample-messages'
ECR_REPOSITORY='ecs-sample-api'
S3_BUCKET_PREFIX='ecs-sample-web'

# Part 1 only displays the website. Replace with the actual API URL in part 3.
API_URL='http://api.example.invalid/api'

一括実行SHでは、ログイン中のAWSアカウントと設定値を照合します。
途中で作業を中断した場合は、再開時に設定した変数を再度読み込みしてください。

リソース名はGUI版と合わせています。
GUI版の検証リソースが残っている場合は未使用名へ変更してください。

API_URL は仮の値となっていますが、後続回でALBのDNS名などが決まった段階で置き換え、
app.js を再配置します。

またS3バケット名は S3_BUCKET_PREFIX にアカウントID＆リージョン＆-an
を付けて組み立てます。接尾辞は手で入力する必要はありません。

構築スクリプトを実行する

一発自動生成するスクリプト

コレを実行すると、
AWSリソースの作成からウェブサイトのURL取得・確認までをまとめて実行できます。

構築の流れを確認しながら進めたい方は、次の「ひとつずつ順番に作成していく手順」
へ進んでください。

（実行する場合）同じ作業フォルダで以下を実行します。

bash setup.sh

リソースの作成や設定の反映に、数分かかる場合があります。

一括実行した場合、以下の個別手順を重ねて実行する必要はありません。
最後の「ウェブサイトをブラウザーで開いて確認する」へ進んでください。

ひとつずつ順番に作成していく手順

まずは設定した変数を読み込みします。

source ./settings.local.sh
export AWS_REGION
export AWS_DEFAULT_REGION="$AWS_REGION"

(1)IAMロールを作成する

役割の異なる2つのロールを作成します。

ロール	用途
タスク実行用ロール	ECSがコンテナイメージを取得し、ログを出力するために使用
アプリ用タスクロール	コンテナ内のアプリがDynamoDBへアクセスするために使用

JSONの保存先を用意する

このあと作成するポリシーのJSONを、作業フォルダー内の .generated へ保存します。既にフォルダーがある場合は、そのまま使用します。

mkdir -p .generated

ECSがロールを使用できるようにする設定を作る

まず、「誰がこのロールを使えるか」を定める 信頼ポリシー を作成します。
今回はECSのタスクがロールを引き受けられるようにします。
両方のロールで同じ信頼ポリシーを使用します。

jq -n はJSONを新規作成するコマンドです。
GUI版と同じく、ECSのタスクがロールを引き受けられるように設定します。

jq -n \
  '{
    Version: "2012-10-17",
    Statement: [{
      Effect: "Allow",
      Principal: {Service: "ecs-tasks.amazonaws.com"},
      Action: "sts:AssumeRole"
    }]
  }' > .generated/ecs-trust-policy.json

JSONはファイルへ保存するため、このコマンドでは画面に結果を表示しません。

タスク実行用ロールを作成する

create-role でロールを作成し、先ほどの信頼ポリシーを指定します。
–query は、作成結果からロール名とARNだけを表示する指定です。

aws iam create-role --role-name "$EXECUTION_ROLE_NAME" \
  --assume-role-policy-document file://.generated/ecs-trust-policy.json \
  --query 'Role.{Name:RoleName,Arn:Arn}' --output table

設定したロール名と、arn:aws:iam:: で始まるARNが表示されることを確認します。

イメージ取得・ログ出力の権限を付ける

作成したロールへ、AWSが用意している管理ポリシー AmazonECSTaskExecutionRolePolicy を付けます。ECRからのイメージ取得やCloudWatch Logsへのログ出力に使う権限です。

aws iam attach-role-policy --role-name "$EXECUTION_ROLE_NAME" \
  --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

正常終了時は結果を表示しません。次の参照コマンドで、付与したポリシーを確認します。

aws iam list-attached-role-policies \
  --role-name "$EXECUTION_ROLE_NAME" --output table

一覧に AmazonECSTaskExecutionRolePolicy が表示されれば、タスク実行用ロールの設定は完了です。

アプリ用タスクロールを作成する

続いて、アプリが使うロールを作成します。
コンテナを起動するための権限と、アプリがDynamoDBを操作する権限を分けて管理します。

aws iam create-role --role-name "$TASK_ROLE_NAME" \
  --assume-role-policy-document file://.generated/ecs-trust-policy.json \
  --query 'Role.{Name:RoleName,Arn:Arn}' --output table

アプリ用ロールの名前とARNが表示されることを確認します。
※DynamoDBへの操作権限はこのあと付与します

アプリ用ロールへ権限を付ける

attach-role-policy で、AWS管理ポリシーをアプリ用ロールへ付与します。
ポリシー名は AmazonDynamoDBFullAccess_v2 とします。

aws iam attach-role-policy --role-name "$TASK_ROLE_NAME" \
  --policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBFullAccess_v2

正常終了時は結果を表示しません。次のコマンドで登録内容を確認します。

aws iam list-attached-role-policies \
  --role-name "$TASK_ROLE_NAME" --output table

一覧に AmazonDynamoDBFullAccess_v2 が表示されれば、アプリ用タスクロールの設定は完了です。

(2)DynamoDBテーブルを作成する

後続回でアプリが使うテーブルを作成します。
今回は文字列のパーティションキー id と、
利用量に応じて課金されるオンデマンド方式を指定します。

テーブルを作成する

–attribute-definitions はキーの名前と型、–key-schema はそのキーの役割を指定します。
S は文字列型、HASH はパーティションキーを表します。

aws dynamodb create-table --table-name "$DYNAMODB_TABLE" \
  --attribute-definitions AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --query 'TableDescription.{Name:TableName,Status:TableStatus}' --output table

テーブル名と状態が表示されます。作成直後は CREATING の場合があります。

作成完了を待つ

次のコマンドは、テーブルが使用可能な状態になるまで待ちます。
正常終了時は結果を表示せず、コマンド入力へ戻ります。

aws dynamodb wait table-exists --table-name "$DYNAMODB_TABLE"

テーブルの設定を確認する

aws dynamodb describe-table --table-name "$DYNAMODB_TABLE" \
  --query 'Table.{Name:TableName,Status:TableStatus,Keys:KeySchema,BillingMode:BillingModeSummary.BillingMode}' --output json

• Status : ACTIVE
• キー: id／HASH
• BillingMode : PAY_PER_REQUEST

になっていることを確認します。
サンプル項目の投入は後続回で行うため、今回は空のテーブルで構いません。

(3)ECRリポジトリを作成する

ECRはコンテナイメージの保存先です。
次回作成するイメージをPushするため、先にリポジトリを用意します。

リポジトリを作成する

aws ecr create-repository --repository-name "$ECR_REPOSITORY" \
  --query 'repository.{Name:repositoryName,Uri:repositoryUri}' --output table

設定したリポジトリ名と、
アカウントID.dkr.ecr.ap-northeast-1.amazonaws.com/リポジトリ名
の形式のURIが表示されることを確認します。この段階ではイメージが入っていなくても正常です。

保存先のURIを取得する

作成したリポジトリを参照し、URIを変数へ保存します。
末尾のリソース情報保存でもこの値を使用します。

ECR_URI="$(aws ecr describe-repositories --repository-names "$ECR_REPOSITORY" --query 'repositories[0].repositoryUri' --output text)"
printf 'ECR_URI=%s\n' "$ECR_URI"

作成時に表示されたURIと同じ値であることを確認します。

(4)S3バケットを作成し、Webファイルを配置する

ここではWeb画面の配置先を作成し、取得済みの index.html と app.js をアップロードします。
設定ファイルや .generated フォルダー全体はアップロードしません。

S3バケット名を組み立てる

元記事と同じアカウントリージョナル名前空間を使用します。
バケットを作成する直前に、接頭辞・アカウントID・リージョン・-an をつないで
完全な名前を組み立てます。

S3_BUCKET="${S3_BUCKET_PREFIX}-${AWS_ACCOUNT_ID}-${AWS_REGION}-an"
printf 'S3_BUCKET=%s\n' "$S3_BUCKET"

例：ecs-sample-web-123456789012-ap-northeast-1-an のような名前になります。

バケットを作成する

–bucket-namespace account-regional で名前空間を、
LocationConstraint で作成するリージョンを指定します。
その他はデフォルト値を使用します。
公開の許可は後のバケットポリシーで設定します。

aws s3api create-bucket --bucket "$S3_BUCKET" \
  --bucket-namespace account-regional \
  --create-bucket-configuration "LocationConstraint=$AWS_REGION"

エラーがないことを確認してから、次の手順へ進みます。

バケットが利用できるまで待つ

aws s3api wait bucket-exists --bucket "$S3_BUCKET" \
  --expected-bucket-owner "$AWS_ACCOUNT_ID"

正常終了時は結果を表示しません。
–expected-bucket-owner は、対象バケットの所有者が指定したアカウント
であることを確認する指定です。

作成先のリージョンを確認する

aws s3api get-bucket-location --bucket "$S3_BUCKET" \
  --expected-bucket-owner "$AWS_ACCOUNT_ID" --output json

LocationConstraint が ap-northeast-1 になっていることを確認します。

JavaScriptへAPIのURLを設定する

取得した web/app.js には、APIのURLを入れるための __API_URL__ という文字列があります。
sed で設定値へ置き換え、配置用のファイルを .generated/app.js へ保存します。元のファイルは残します。

sed "s|__API_URL__|$API_URL|g" web/app.js > .generated/app.js

今回はまだAPIを作成していないため、設定ファイルの仮URLのままで構いません。
このコマンドはファイルへ保存するため、画面には結果を表示しません。

HTMLファイルをアップロードする

put-object でファイルを配置します。
–key はS3上のファイル名、
–body はアップロード元です。
ブラウザーがHTMLとして扱えるよう、Content-Typeも指定します。

aws s3api put-object --bucket "$S3_BUCKET" \
  --key index.html --body web/index.html \
  --content-type 'text/html; charset=utf-8' \
  --expected-bucket-owner "$AWS_ACCOUNT_ID" --output json

エラーなくアップロード結果が表示されることを確認します。

JavaScriptファイルをアップロードする

JavaScriptは、先ほどAPIのURLを設定した .generated/app.js を使用します。

aws s3api put-object --bucket "$S3_BUCKET" \
  --key app.js --body .generated/app.js \
  --content-type 'application/javascript; charset=utf-8' \
  --expected-bucket-owner "$AWS_ACCOUNT_ID" --output json

こちらもアップロード結果が表示されれば、Webファイルの配置は完了です。
まだ公開設定をしていないため、続けてホスティングとアクセス許可を設定します。

(5)静的ウェブサイトホスティングと公開アクセスを設定する

S3でWeb画面を表示するための設定と、ファイルの読み取り許可を設定します。
GUI版と同じく、バケット内の全ファイルを読み取り対象にします。

最初に表示するHTMLを指定する

put-bucket-website で静的ウェブサイトホスティングを設定します。
IndexDocument は、URLを開いたときに最初に表示するファイルです。

aws s3api put-bucket-website --bucket "$S3_BUCKET" \
  --website-configuration '{"IndexDocument":{"Suffix":"index.html"}}' \
  --expected-bucket-owner "$AWS_ACCOUNT_ID"

正常終了時は結果を表示しません。
この設定だけでは、まだ匿名のブラウザーからファイルを読み取れません。

バケットポリシーによる公開を許可する

S3の「パブリックアクセスをブロック」の設定を変更します。
GUI版と同じく、4項目すべてを無効にします。

設定	値	今回の意味
BlockPublicAcls	false	この項目による公開ACLの設定ブロックを無効にする
IgnorePublicAcls	false	この項目による公開ACLの無視を無効にする
BlockPublicPolicy	false	公開を許可するバケットポリシーを設定可能にする
RestrictPublicBuckets	false	公開ポリシーを持つバケットへの匿名アクセスを制限しない

aws s3api put-public-access-block --bucket "$S3_BUCKET" \
  --public-access-block-configuration 'BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false' \
  --expected-bucket-owner "$AWS_ACCOUNT_ID"

正常終了時は結果を表示しません。
実際の読み取り許可は、次のポリシーで指定します。

公開するファイルと操作を定義する

jq でバケットポリシーのJSONを作成します。Principal: “*” は匿名の閲覧者を含む利用者、s3:GetObject はファイルの読み取り、Resource は対象ファイルです。

jq -n --arg bucket "$S3_BUCKET" \
  '{
    Version: "2012-10-17",
    Statement: [{
      Sid: "PublicRead",
      Effect: "Allow",
      Principal: "*",
      Action: "s3:GetObject",
      Resource: ("arn:aws:s3:::" + $bucket + "/*")
    }]
  }' > .generated/s3-website-policy.json

このポリシーでは、バケット内の全ファイルの読み取りを許可します。
バケットの一覧表示やファイルの書き込みは許可しません。

バケットへポリシーを設定する

aws s3api put-bucket-policy --bucket "$S3_BUCKET" \
  --policy file://.generated/s3-website-policy.json \
  --expected-bucket-owner "$AWS_ACCOUNT_ID"

正常終了時は結果を表示しません。

ホスティング設定を確認する

aws s3api get-bucket-website --bucket "$S3_BUCKET" \
  --expected-bucket-owner "$AWS_ACCOUNT_ID" --output json

IndexDocument の Suffix が index.html になっていることを確認します。

パブリックアクセスの設定を確認する

aws s3api get-public-access-block --bucket "$S3_BUCKET" \
  --expected-bucket-owner "$AWS_ACCOUNT_ID" --output json

先ほどの表と同じく、4項目すべてが false になっていることを確認します。

ウェブサイトのURLを表示して確認する

ウェブサイトのURLを組み立てる

東京リージョンのS3ウェブサイトエンドポイントと、今回のバケット名を組み合わせます。

WEBSITE_URL="http://${S3_BUCKET}.s3-website-ap-northeast-1.amazonaws.com"
printf 'Website URL: %s\n' "$WEBSITE_URL"

http:// で始まるURLが表示されます。このURLを後から確認できるよう、TXTへ保存します。

printf '%s\n' "$WEBSITE_URL" > .generated/website-url.txt

HTMLを取得できることを確認する

curl で、認証情報を付けずにWebファイルを取得します。
HTTPエラーの場合は –fail で失敗扱いとし、設定反映の待ち時間を考慮して再試行します。
接続・処理の待ち時間にも上限を設けています。

curl --fail --show-error --silent --retry 5 --retry-delay 3 \
  --connect-timeout 10 --max-time 30 "$WEBSITE_URL/" \
  -o .generated/website-check.html

取得したHTMLはファイルへ保存するため、正常終了時は画面に結果を表示しません。エラーの場合は、メッセージとS3の公開設定を確認してから進んでください。

JavaScriptを取得できることを確認する

HTMLから読み込むJavaScriptも同じように確認します。

curl --fail --show-error --silent --retry 5 --retry-delay 3 \
  --connect-timeout 10 --max-time 30 "$WEBSITE_URL/app.js" \
  -o .generated/app-check.js

この確認はファイルを取得できることの確認です。画面の表示とボタンの動作は、次のブラウザー確認で確かめます。

ウェブサイトをブラウザーで開いて確認する

保存したURLを表示します。

cat .generated/website-url.txt

表示された HTTPのURL をブラウザーで開いてみます。
CloudShellからご自身のブラウザーを自動起動する処理は含めていません。

この状態だとアプリの設定がないので、APIは反応しませんが、
以下のようにブラウザが表示できるはずです。

「Azure → AWS ECS Sample」と「API呼び出し」ボタンが表示されれば、
今回の基盤準備は完了です。この時点ではAPIを作成していないため、
ボタンを押すと「API接続失敗」になります。

後続回で使うリソース情報を保存する

一括実行SHを使用した場合は、この保存も完了しています。以下は個別手順で進めた場合に実行してください。

作成したリソースの情報を、後から参照できるよう .generated/resources.json へまとめます。ここではAWSリソースを変更しません。

タスク実行用ロールのARNを取得する

ロールを参照し、ARNだけを変数へ保存します。

EXECUTION_ROLE_ARN="$(aws iam get-role --role-name "$EXECUTION_ROLE_NAME" --query Role.Arn --output text)"
printf 'EXECUTION_ROLE_ARN=%s\n' "$EXECUTION_ROLE_ARN"

アプリ用タスクロールのARNを取得する

同じように、アプリ用ロールのARNを取得します。

TASK_ROLE_ARN="$(aws iam get-role --role-name "$TASK_ROLE_NAME" --query Role.Arn --output text)"
printf 'TASK_ROLE_ARN=%s\n' "$TASK_ROLE_ARN"

それぞれの末尾が、設定したロール名になっていることを確認します。

リソース情報をJSONへ保存する

ここまでに設定・取得した値を jq へ渡し、ファイルへ保存します。ECR_URI はECRの節で取得した値です。

jq -n --arg account "$AWS_ACCOUNT_ID" --arg region "$AWS_REGION" \
  --arg executionRole "$EXECUTION_ROLE_ARN" --arg taskRole "$TASK_ROLE_ARN" \
  --arg table "$DYNAMODB_TABLE" --arg ecr "$ECR_URI" \
  --arg bucket "$S3_BUCKET" --arg website "$WEBSITE_URL" \
  '{
    accountId: $account,
    region: $region,
    executionRoleArn: $executionRole,
    taskRoleArn: $taskRole,
    dynamodbTable: $table,
    ecrUri: $ecr,
    s3Bucket: $bucket,
    websiteUrl: $website
  }' > .generated/resources.json

保存した内容を表示します。

cat .generated/resources.json

これで、一括実行SHと同じ場所にリソース情報が保存されます。CloudShellを再起動するとBashの変数は失われるため、続きは設定値を読み込み、必要な値をファイルや各サービスの参照コマンドから取得して進めてください。

Image Push編へ続く

次回はコンテナイメージを作成し、今回のECRへPushするところへ進みます。
CLI版②の公開予定URLは https://addache.net/aws-ecs-12/ です。
(編集中)

途中で失敗した場合の再開、後片付け対象、AWS公式資料は README を参照してください。

またECSの設定とあわせて、本記事では以下の設定について解説いたしました。

• サブドメイン権限委譲 設定方法
• S3 静的ウェブサイトホスティング

関連記事のご紹介

シリーズ2回目記事、主にGitHubの設定方法解説

Azure経験者がAWS ECSで同じ構成を作ってみる② ～Image Push～

今回はAWS ECSサービスに関する記事です。Azure のコンテナサービス(App Service)をAWSへ移植するために必要な構成を解説していきます。本記事はシリーズ構成の第二弾として、ECS Fargateの設定準備に向けコンテナイ…

addache.net

2026.07.25

シリーズ3回目記事、ECSデプロイして動作検証まで実施

Azure経験者がAWS ECSで同じ構成を作ってみる③ ～ECS Fargate構築～

今回はAWS ECSサービスに関する記事です。Azure のコンテナサービス(App Service)をAWSへ移植するために必要な構成を解説していきます。本記事はシリーズ構成の第三弾として、いよいよECS Fargateの構築と、接続周り…

addache.net

2026.07.25

シリーズ4回目記事、ECS ExpressModeでデプロイして動作検証まで実施

Azure経験者がAWS ECSで同じ構成を作ってみる④ ～ECS ExpressMode展開～

今回はAWS ECSサービスに関する記事です。Azure のコンテナサービス(App Service)をAWSへ移植するために必要な構成を解説していきます。本記事はシリーズ構成の第四弾として、ECS ExpressModeの構築と、接続周り…

addache.net

2026.08.01