【GitHub】AWS CodeCommit無しでのTEAM for IAM Identity Centerのデプロイ方法とアップデート方法

記事タイトルとURLをコピーする

垣見です。
CodeCommitが使えない環境でのTEAMのデプロイの方法をご紹介します。

初めに

AWS IAM Identity Centerの運用効率化・セキュリティ強化に使えるソリューション、「Temporary elevated access management (TEAM)」ですが、従来のデプロイ手順ではAWS CodeCommitを使用する必要がありました。

※TEAMとは何か?はこちらをご覧ください blog.serverworks.co.jp

しかし2024年7月末頃のアップデート以降、CodeCommitは新規受け入れを停止しております。

blog.serverworks.co.jp

そのため、CodeCommitを使わないデプロイの方法として私が使った手順をご紹介します。

ちなみに、TEAMのバージョン1.2.0で修正された手順となっております。

記事の対象者

  • TEAMソリューションをデプロイしたい人
  • TEAMをCodeCommit無しでデプロイする方法が知りたい人
  • Amplifyを使ったアプリケーションの実例を見てみたい人
  • GitHub経由でデプロイしたTEAMの更新について知りたい方

この手順のゴール

  • 環境にTEAMがデプロイできており、使える状態になっている

※デプロイまでで設定は扱いません。
TEAMデプロイ後の使い方はこちらをご覧ください。 blog.serverworks.co.jp

環境前提

  • Organizations環境で、IAM Identity Center(以下IdC)を利用しており、委任アカウントが存在する(管理アカウントでIAM Identity Centerを管理していない)
  • GitHubのアカウントを持っており、アクセス可能なGithubリポジトリがある
  • VSCodeなどAWS CLIを使ってAWS環境を操作できる状態である

変更が加わるAWSリソース

  • IAM Identity Center委任アカウントがOrganizationsのAWS Account Managementの委任アカウントに設定されます
  • IAM Identity Center委任アカウントがCloudTrailの委任管理アカウントに設定されます
  • IAM Identity Center委任アカウントのAWS IAM Identity CenterのアプリケーションにデプロイされたTEAMが関連付けられます

作成されるAWSリソース

  • Cloudformation・Amplifyを使用したTEAMアプリケーションのデプロイ
    • TEAMアプリを動かすサーバレスリソース:公式Architecture参照
      • ※リンク先の記載リソース以外にも、S3バケットやIAMロールなどが細かく作成されますのでご了承ください
  • CloudTrail Lake:新規イベントデータストアの作成
  • Secrets Manger: GitHub認証情報を入れたシークレットの作成

その他

  • 自分で変更できるGitHub組織にTEAMデプロイ用のリポジトリが作成されます
  • GitHubのpersonal access token(Classic)の発行が必要です
    • 補足:
    • 2024年12月時点でGitHubのアクセストークンはClassicしか使えませんでした……。よりセキュリティ的に安全で推奨とされるFine-grained personal access tokenでは全権限を付与してもアクセスが失敗してしまったので、ご了承ください。(対応すると嬉しいですね。)

手順の概要とポイント

IAM Identity Center委任アカウント内にTEAMがデプロイされます。

従来の手順

  • 本来はCodeCommit上に置いたリポジトリをAmplifyが参照して各サーバレスリソースを作りますが、このCodeCommitを各人のGitHubに置き換えます。
  • そのままではGitHubを参照できないので、AWS Secrets ManagerにGitHubリポジトリURLとアクセストークンを保管してデプロイ時に使うよう指定しておきます。
  • 準備としては自分のGitHubリポジトリに公式のリポジトリをコピーしておく必要があるのと、Secrets Managerシークレット、アクセストークンを払い出す必要があります。

※AWSの公式リポジトリとそこからCloneして作った自分用のリポジトリが登場するので混同に注意してください。

あとは基本的にCodeCommit版デプロイ(2025年1月時点でTEAM公式手順に載っている内容と同じです。

また、当時のissueでは自身でtemplate.yamlを書き換えてGitLabを指すようコードを調整した方もいたようです。現行のバージョンとの互換性は保証できませんが、参考になれば幸いです。

準備

※順不同

  1. TEAM のAWS公式GitHubリポジトリをCloneし、自身の新しいリポジトリとして用意しておく
  2. GitHubのアクセストークンを用意
  3. IAM Identity Centerのグループに、監査ペルソナ・管理者ペルソナ用のグループを作っておく
  4. 環境のプロファイルを用意

1. TEAM のAWS公式GitHubリポジトリをCloneし、自身の新しいリポジトリとして用意しておく

AWSのGitHubにあるリソース群を自分のリポジトリに持ってきて触れるようにします。 ※forkでも良いかもしれません。私はPrivateリポジトリを作りたかったのもありclone+pushにしました。

1. 自身のGitHub環境で新しい空のリポジトリを作成する

Private/Publicは任意
2. 以下のTEAM公式リポジトリに移動し、HTTPSのURLをコピーする github.com

3.自分のローカルで2のURLを使い、git cloneする

# 以下ディレクトリ作成は任意
$ mkdir project-team-clone
$ cd project-team-clone

# 公式からCloneする
$ git clone https://github.com/aws-samples/iam-identity-center-team.git <必要ならば任意のディレクトリ名>

基本的には最新版にしてください。(突然エラーでデプロイできなくなったことがあり、それに対応する新バージョンが出されることがありました…)

参考:リポジトリをクローンする - GitHub Docs

4.手順1で作成した空のリポジトリにpushする

※<手順1で作成したリポジトリのURL>は以下からコピーしておく

# ここではGitリポジトリ情報を完全に削除していますが、新たなディレクトリにコピーする方法でも良いです。
$ rm -rf .git  #ディレクトリ間違いに注意

$ git init    # gitの開始
$ git add .    # ステージングエリアに追加
$ git commit -m "first commit"    # ステージングエリアに追加された変更をコミット
$ git branch -M main    # mainという名前のブランチを作成
$ git remote add origin <手順1で作成したリポジトリのURL>    # リモートリポジトリを追加
$ git push -u origin main    # 変更をGitHub上のリポジトリにプッシュ

最終的に自分のGitHubリポジトリに公式と同じようにソースコードがあればよい

2. GitHubのアクセストークンを用意

1. GitHub右上の自分のアイコンから「Settings」を選択

2. 左ペインから「Developer settings」を選択

3. Personal access tokens を展開し、「Tokens(Classic)」を選択する。Generate new token > Tokens(Classic)を押す。

4.アクセスキーの名前と削除期限を入力し、「Select scopes」で「repo」とその配下すべてにチェックを付けて「Generate token」する (※そのほかの権限は不要)

5.ghp_から始まるトークンをメモしておく

3. IAM Identity Centerのグループに、監査ペルソナ・管理者ペルソナ用のグループを作っておく

※Microsoft Entra IDと統合・自動プロビジョニングしている場合はそちらから操作してください

1.AWS IAM Identity Centerコンソール > グループ >グループを作成

2.グループ名を入力(例:TEAM Admins、TEAM Auditors)、各ペルソナにしたいユーザーを割り当てる

3.「グループを作成」

解説

ペルソナごとの挙動解説(折り畳み)

承認ペルソナ、申請ペルソナは後からでも作れますが、この二つは最初から指定する必要があります。

監査ペルソナは以下のようなセッションごとの行動ログを見ることが出来ます。

管理者ペルソナはアカウントへの承認者、申請者の権限をユーザーに割り当てたり、TEAMアプリそのものの設定(通知など)を変更できます。

アプリ上での見える範囲も異なります。

4. 環境のプロファイルを用意

構築

  1. IAM Identity Center委任アカウントをCloudTrailの委任管理アカウントに任命する
  2. CloudTrail Lake EventDataStoreを作成する
  3. SecretsManagerにGitHubアクセス用のシークレットを作成する
  4. TEAMソリューションを環境にデプロイする
  5. TEAMアプリケーションをIAM Identity Centerと統合する
  6. TEAM Cognito ユーザープールの設定を更新

1. IAM Identity Center委任アカウントをCloudTrailの委任管理アカウントに任命する

※もし後述手順「CloudTrail Lake EventDataStoreを作成する」で「組織内のすべてのアカウントについて有効化」したCloudTrail Lake イベントデータストアを作成しない場合(そのアカウントだけのイベントデータストアを作成する場合)はこの手順をスキップ可能です。その場合、デプロイ時の「init.sh」ファイルの実行時に委任の任命が実行されます。

また、非委任状態で「組織内のすべてのアカウントについて有効化」していないイベントデータストアを作成した後に委任して「組織内のすべてのアカウントについて有効化」に設定変更することも可能なため、今は無効で良いが後から有効化したい場合にもスキップ可能です。

1.Organizations管理AWSアカウントのAWSコンソールへログイン・アクセスする

2. CloudTrailコンソールの画面に遷移する

3. 設定に移動

4. 組織の委任された管理者 > 「管理者を登録」をクリック

5. IAM Identity Center委任アカウントの12桁のアカウントIDを入力し、「管理者を登録」をクリック

2. CloudTrail Lake EventDataStoreを作成する

1.IAM Identity Centerを委任したAWSアカウントのAWSコンソールへログイン・アクセスする

2. CloudTrailコンソールの画面に遷移する

3. Lake > イベントデータストア に移動 「イベントデータストアの作成」をクリック

4. 以下の通り入力し、「次へ」をクリック ※以下の項目はすべて任意です。要件に合わせて設定してください。

  • イベントデータストア名:team-log(任意の名前で良いです)
  • 料金オプション:1 年間の延長可能な保持料金
  • 保存期間:1 年 (追加料金なしで取り込み料金に含まれています)
  • 暗号化:自分の AWS KMS キーを使用にチェックを入れない
  • Lake クエリーフェデレーション:有効にしない
  • タグ
    • キー:project
    • バリュー:team

5. 以下の通り入力し、「次へ」をクリック

  • イベントタイプ
    • イベントタイプを選択:AWS イベント
      • AWS イベントのタイプを指定します:CloudTrail イベント
    • CloudTrail イベント
      • 「管理イベント」のみにチェックを入れる
    • オプション
      • 組織内のすべてのアカウントについて有効化:チェックを入れる(※取得したアカウントのみの監査ログをTEAM監査ペルソナが確認することが出来ます)
      • イベントデータストアに現在のリージョン (ap-northeast-1) のみを含める:チェックを入れない
      • イベントを取り込む:チェックを入れない(※ここでチェックを入れるとデータストア作成時点からCloudTrailログの取り込みが開始します。料金がかかりますのでに注意して下さい。
    • 管理イベント
      • Simple event collectionを選択
      • Choose events to log:Only write events
      • Event exclusions - オプション:
        • AWS KMS イベントの除外:チェックを入れない
        • Amazon RDS のデータ API イベントを除外:チェックを入れない
      • Enable Insights events capture:有効にしない

※注意:

  • 項目はすべて任意です。要件に合わせて設定してください。(イベントデータストアのARNさえあればデプロイできる、かつ設定は後から変えられるため、停止状態やログの取り方は自由となっています)
  • なお、以下の設定ではTEAMの監査ペルソナがセッションごとのCloudTrailをすべて見ることが出来る設定にした上で、コスト削減のために「イベントを取り込む」にチェックを入れないことで一時的にイベントデータストアを停止しています。後から有効化することで機能の使用が可能です。
  • CloudTrail Lakeでは2025年1月現在、データストアを作成する1アカウントのみか、Oranizations内のすべてのアカウントか、しか有効化の対象を選べません。(リージョンも同様です。)監査ログでデータを残せるのはデータストアで取得しているイベントのみなので注意してください。

6. 確認画面を見て、問題が無ければ「イベントデータストアの作成」をクリックする

7. 作成したイベントデータストアのステータスが作成中から停止済み(または有効)になるまで画面を更新する

8. 作成したイベントデータストアのARNをコピーしておく

3. SecretsManagerにGitHubアクセス用のシークレットを作成する

1.SecretsManagerコンソールの画面に遷移する

2.「新しいシークレットを保存する」をクリック

3.シークレットのタイプ:その他のシークレットのタイプ(APIキー、OAuthトークン、その他。)を選択

4.キー/値のペア

  • url
    • https://github.com/xxxxxxxxxxxxxxxxx(準備時に自分用にコピーしたTEAMリポジトリのURL)(※クローン元の公式ソースコードの方ではないので注意)
  • AccessToken
    • 準備段階で払い出した個人用アクセストークン(Classic)

URLには準備した自分のTEAMリポジトリのURLを入れる

5.暗号化キー:変更なし(aws/secretsmanager)、またはご自身で用意したカスタマーマネージド KMS キーを選択する

  • カスタマーマネージドキーを使う場合、キーポリシーとSecrets Manager に対象(自分)のIAMロールへのアクセス許可を追加してください。また、TEAMのリソースであることが分かるようなタグを付けておくと良いかと思われます。
  • なお、TEAMデプロイ時にTEAM用のカスタマーマネージドKMSキーが一つ作成されます。(エイリアス名無し、かつDescriptionがTEAM Stepfunction CloudwatchLog Keyになっているリソースです。)TEAM削除時に削除が同時にスケジュールされます。混同しないように注意してください。

6.次へをクリック

7.以下設定(名前以外の項目は任意です)

  • シークレットの名前:TEAM-IDC-APP
  • タグ:
    • キー:project
    • バリュー:team
  • リソースのアクセス許可:任意
  • シークレットをレプリケート:任意

次へをクリック

8.ローテーション設定は触らず(※任意)次へをクリック

9.レビューして「保存」をクリック

10.画面を更新し、TEAM-IDC-APPのシークレットができているか確認する

11.シークレットのARNをメモしておく

4. TEAMソリューションを環境にデプロイする

1.Cloudformationコンソールの画面に遷移しておく

2.事前に設定済みのローカル環境(VSCode)を開き、TEAMデプロイ用の任意のフォルダに移動する

3.コマンドを実行してgitプロジェクトをクローン

(urlには準備で作成した自分のTEAMリポジトリのURLを入れる)

補足:準備と構築が違う人間の可能性を鑑みてこのような手順にしております。

# 以下ディレクトリ作成は任意
$ mkdir project-team-deploy
$ cd project-team-deploy

# 自分のGitHubリポジトリからCloneする
$ git clone https://github.com/XXXXXXXXXXXXXXXXXX <必要ならば任意のディレクトリ名>

4.以下のコマンドを順番に実行し、deploymentディレクトリにparameters.shという名前の新しいファイルを作成。ファイルparameters-template.shの内容を新しいファイルにコピーする

$ cd <githubリポジトリ名>/deployment
$ cp -n parameters-template.sh parameters.sh

このdeploymentの階層下にparameters.shができていればよい

5.次のように parameters.shファイル内のパラメータを更新する

※<>の中身は準備や前述の構築でメモしたものを入れる

IDC_LOGIN_URL=<IAM Identity CenterのログインURL>
REGION=<TEAMデプロイリージョン>
TEAM_ACCOUNT=<IAM Identity Center委任アカウントID>
ORG_MASTER_PROFILE=<IAM Identity Center委任アカウントのProfile>
TEAM_ACCOUNT_PROFILE=<Org管理アカウントのProfile>
TEAM_ADMIN_GROUP="<TEAM管理者ペルソナ用IAM Identity Centerグループ名>"
TEAM_AUDITOR_GROUP="<TEAM監査ペルソナ用IAM Identity Centerグループ名>"
TAGS="project=team"
CLOUDTRAIL_AUDIT_LOGS=<先ほど作成したイベントデータストアのARN>
SECRET_NAME=<先ほど作成したシークレットの名前(TEAM-IDC-APP)>

IAM Identity CenterのログインURLはここにある

6.AWS CLIのプロファイルのAWSアカウントIDを確認する。

$ aws sts get-caller-identity --profile <IAM Identity Center委任アカウントのProfile>
$ aws sts get-caller-identity --profile <Org管理アカウントのProfile>

以下のように返ってきます。プロファイルに間違いがないことを確認してください。

$ aws sts get-caller-identity --profile account-profile
{
    "UserId": "XXXXXXXXXXXXXXXX",
    "Account": "123412341234",
    "Arn": "arn:aws:iam::123412341234:user/Username"
}

7.同じくdeploymentディレクトリで、次のコマンドを実行する

#  IAM Identity Center委任アカウントがIAM Identity Center, OrganizationsのAWS Account Management, CloudTrailの委任アカウントに設定されているか確認し、されていない場合は設定を行う
$ ./init.sh

以下のように返ってくる

123456789101 configured as delegated Admin for AWS Account Manager
123456789101 configured as delegated Admin for cloudtrail
123456789101 configured as delegated Admin for IAM Identity Center

または

123456789101 configured as delegated Admin for AWS Account Manager
123456789101 configured as delegated Admin for cloudtrail
123456789101 configured as delegated Admin for IAM Identity Center

8.同じくdeploymentディレクトリで、次のコマンドを実行する

# デプロイ開始
./deploy.sh

9.AWSコンソールに戻り、デプロイの状況を確認する

スクリプトの実行がSuccessfully created/updated stack - TEAM-IDC-APPと完了してcloudformation スタックが正常に作成されたら、AWS Amplify コンソール>TEAM-IDC-APP に移動して、TEAM アプリケーションのデプロイメントのステータスを監視する。

※Amplifyアプリケーションスタックのビルドとデプロイが完了するまでに約20分かかる。

ちなみに、この過程でTEAM-IDC-APPのスタックとは別にAmplifyによるCloudFormationのネスト構造のスタックが多数できる。

10.Amplifyコンソール -> すべてのアプリ -> TEAM-IDC-APP ->Hosting environmentsで、アプリケーション URL をクリックして、下のようなTEAM画面へ遷移されることを確認する

5. TEAMアプリケーションをIAM Identity Centerと統合する

1.事前に設定済みのローカル環境(VSCode)を開き、デプロイ用ディレクトリ配下の/deploymentに移動する

2.次のコマンドを実行して、integration.shスクリプトをデプロイ

# アプリのアクセス情報を返す
$ ./integration.sh

返ってきたapplicationStartURL、applicationACSURL、applicationSAMLAudienceをメモしておいてください。

3.AWSのIAM Identity Centerコンソール>アプリケーションの割り当て>アプリケーション>アプリケーションの追加 に移動、以下のように設定する

  • 設定するアプリケーションがある > SAML 2.0を選択し、次へをクリック
  • 表示名:TEAM IDC APP
  • アプリケーションの構成セクション:TEAM アプリケーションの説明として「TEAM for IAM Identity Center (<GitHubのURL>)」等を追加

AWS IAM Identity Center SAML メタデータファイル URLの URL をコピーして保存しておいてください。

4.続けて以下のように入力する

  • アプリケーション プロパティセクションのアプリケーション開始 URL:先ほどメモしたapplicationStartURLパラメータの値を入力
  • アプリケーション メタデータセクション:「メタデータ値をマニュアルで入力する」を選択
  • アプリケーション ACS URL:先ほどメモしたapplicationACSURLパラメータの値を入力
  • アプリケーション SAML オーディエンス:先ほどメモしたapplicationSAMLAudienceパラメータの値を入力

[送信]をクリックして設定を保存してください。

5.「アクション」のドロップダウンをクリックし、属性マッピングの編集を選択して、次の値を追加する

  • Subject - ${user:subject} - persistent
  • Email - ${user:email} - basic

変更の保存をクリックしてください。

6.[割り当てられたユーザーとグループ]の下で、 [ユーザーとグループを割り当てる]をクリックしてユーザーを追加する

これにより、割り当てられたユーザーとグループに TEAM アプリケーションにログインするアクセス権が付与されるので、以下を検索窓に入れて追加してください。

  • デプロイ時のparameter.shTEAM_ADMIN_GROUPに指定したグループ
  • デプロイ時のparameter.shTEAM_AUDITOR_GROUPに指定したグループ
  • その他TEAMの承認ペルソナ、申請ペルソナとして使いたいグループ・ユーザー

6. TEAM Cognito ユーザープールの設定を更新

1.事前に設定済みのローカル環境(VSCode)を開き、デプロイ用ディレクトリ配下の/deploymentに移動する

2.TEAM Cognito ユーザープールの設定を更新する

# details-template.jsonファイルの内容をdetails.jsonという名前の新しいファイルにコピー
$ cp details-template.json ./details.json

3. details.jsonファイル内のMetadataURL を、ひとつ前のセクション項番3の「メモ」からコピーしたAWS IAM Identity Center SAML メタデータファイル URLの値に置き換える

{ 
    "MetadataURL": "<AWS IAM Identity Center SAML メタデータファイル URL>"
}

4.自身が/deploymentにいることを確認し、以下のコマンドを実行する

# CognitoのMetadataURLの設定を反映
$ ./cognito.sh

ログイン確認

これでデプロイは完了です!おめでとうございます!

TEAM管理者としてログインできるか確認してみましょう。

自分のIAM Identity CenterユーザーをTEAM Admins(デプロイ時のparameter.shTEAM_ADMIN_GROUPに指定したグループ)に所属させ、IAM Identity Centerアクセスポータルにログインします。

「Application」をクリックするとTEAM IDC APPが追加されています。

クリックすると……ログインできました!おめでとうございます!

※Entra IDを使っていてここでエラーが出る場合は以下も参考にしてください blog.serverworks.co.jp

こちらのブログではこれ以降の設定も進めることができます。 blog.serverworks.co.jp

アップデートについて

以下のようになります。

なお、公式ではなく既にローカルにあるファイルのみ更新したい場合は手順1はいりません。(parameter.shを書き換えてタグやCloudTrail LakeイベントデータストアのARNなどAmplify環境変数を書き換えたい場合が該当します)

  1. 公式からフェッチしたupstream(リモートリポジトリ)の内容を使い、自身のGitHubリポジトリを更新する
  2. 自身のGitHubリポジトリを個人ローカルにクローンし、アクセストークン・URLをSecrets Managerに格納しておく
  3. 必要であればparameter.shを書き換えて保存する
  4. /deployment配下に移動して、./update.shを実行する
  5. 既存の2つのCloudFormationルートスタックがUPDATE_COMPLETEになったら、Amplifyコンソール > TEAM-IDC-APP > main から「このバージョンを再デプロイ」をクリックする(参考:TEAMのデプロイ時の設定を更新したい/TEAM アプリケーションを最新バージョンに更新したい

1. 公式からフェッチしたupstream(リモートリポジトリ)の内容を使い、自身のGitHubリポジトリを更新する

# git開始(ls -laしたときに.gitが追加がない場合に実行)
$ git init

# 各リポジトリと接続
$ git remote add upstream https://github.com/aws-samples/iam-identity-center-team.git
$ git remote add origin <自分のリポジトリURL>  # [remote origin already exists.]の場合気にしなくてよい

# 確認。以下のようになっていればよい。
$ git remote -v
origin  <自分のリポジトリURL> (fetch)
origin  <自分のリポジトリURL> (push)
upstream        https://github.com/aws-samples/iam-identity-center-team.git (fetch)
upstream        https://github.com/aws-samples/iam-identity-center-team.git (push)

# 変更をローカルに取り込み
$ git fetch upstream

# 自身の作業ブランチを更新
$ git checkout main    # main 以外のブランチを使っている場合、そのブランチ名に変更してください
$ git merge upstream/main --allow-unrelated-histories  # コンフリクト(競合)が発生する可能性あり

# コンフリクトの確認
$ git status
On branch main
Your branch is up to date with 'origin/main'.

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both added:      amplify/backend/custom/stepfunctions/stepfunctions-cloudformation-template.json
        both added:      package-lock.json
        both added:      src/components/Navigation/Header.js

no changes added to commit (use "git add" and/or "git commit -a")

上記例だと、以下ファイルに競合が起きています。

  • amplify/backend/custom/stepfunctions/stepfunctions-cloudformation-template.json
  • package-lock.json
  • src/components/Navigation/Header.js

ファイルを見に行き、内容を確認して基本は「入力側の変更を取り込む」ボタンを押してください。

内容を確認し、基本は「入力側の変更を取り込む」ボタンを押してください
VSCodeだと右側のスクロールバーが赤くなっています

# 直したファイルをすべてaddする
$ git add <競合を直したファイル名>    # 今回の例だとamplify/backend/custom/stepfunctions/stepfunctions-cloudformation-template.jsonなど

# マージ完了のコミット
$ git commit -m "Resolve merge conflicts"

# 自分のGitHubリポジトリにpush!これで反映されます
$ git push origin main

こんな感じ。競合していない更新は公式と同じコミットメッセージが付与される

2. 手順1で更新した自身のGitHubリポジトリを個人ローカルにクローンし、アクセストークン・URLをSecrets Managerに格納しておく

デプロイと同様の手順

3. 必要であればparameter.shを書き換えて保存する

デプロイと同様の手順

4. /deployment配下に移動して、./update.shを実行する

5. Amplifyから再デプロイ

既存の2つのCloudFormationルートスタックがUPDATE_COMPLETEになったら、Amplifyコンソール > TEAM-IDC-APP > main から「このバージョンを再デプロイ」をクリックする

参考:TEAMのデプロイ時の設定を更新したい/TEAM アプリケーションを最新バージョンに更新したい

終わりに

TEAMはGitHub上で今も頻繁に改善が続けられています。
便利なのですがなかなか知られていないのが玉に瑕…

このブログで少しでも知名度が上がり、より注目されてさらに多機能になればいいなあと思います。

皆様をお助けできたなら幸いです!

垣見(かきみ)(執筆記事の一覧)

2023年新卒入社 エンタープライズクラウド部所属

図解するのが好き。「サバワク」のアイキャッチ作成も担当しています