約20分で分かる実AWS検証
認証して構築し、
動作確認後に撤収する。
用途別の一時権限へ切り替え、Terraformで実AWS環境を構築し、認証から監査までのE2Eとlogで動作を確認する。さらにdestroy後も27カテゴリを調べ、残存0件を確かめます。 ReactorFront（リアクターフロント）が公開するPortfolioで実行した一連の検証です。
約20分で読めます
この記事で確認できること
環境構築、利用者操作、log、
撤収をまとめて検証する。
このシステムは、Cognito、API Gateway、ECS/Fargate、RDS、S3、Amazon MQ、CloudWatch Logsなど、担当する仕事が異なるAWS serviceで構成しています。 環境構築では、それらの接続順と権限の境界を、コードで構成を管理するIaCから再現します。
構築後は外部HTTPSからログイン、文書登録、非同期推論、人による確認、監査記録までを通し、AWS側の状態とlogを照合しました。 E2E完了後は直ちに撤収し、Terraformの管理記録（state）だけに頼らずAWS APIから残存リソースを再確認しています。
この記事は、AWSを再現するための手順書ではありません
実際のAWS設定と公開リポジトリを根拠にしていますが、コマンド、アカウント固有値、完全なIAMポリシー、環境変数、秘密情報は掲載しません。 操作手順ではなく、権限設計、検証条件、コスト管理、障害復旧の判断を説明します。
認証から残存確認までの一連の工程
認証、構築、動作確認、撤収を、
同じworkflowで管理する。
環境構築やE2Eだけを個別の成功とは扱いません。事前の権限取得から、撤収後に別経路で行う残存確認まで完走して、1回の検証完了とします。
- 01認証
日常作業用のIAMユーザーで本人を確認する
日常作業ではAdministratorAccessを使わず、AWSリソースを直接操作する権限を持たないIAMユーザーから開始します。
- 02権限切替
用途別のIAM Roleへ一時的に切り替える
設定閲覧、費用確認、環境構築の用途ごとにRoleを分け、STSが発行する期限付きの認証情報へ切り替えます。
- 03構築
Terraformで一時環境を構築する
ネットワーク、ECS、Cognito、RDS、S3、Amazon MQなどを、コードで構成を管理するIaCから構築します。
- 04動作確認
認証から監査までの利用者操作を通す
外部HTTPSからログイン、PDF登録、非同期推論、人による確認、監査記録までを端から端まで試すE2Eを実行します。
- 05証拠確認
AWSの状態とログで結果を確かめる
画面上の成功だけで判定せず、serviceの状態、アプリケーションlog、workflowの実行要約を確認します。
- 06撤収・残存検査
環境を撤収し、残り物がないか別経路で調べる
terraform destroy後に27カテゴリをAWS APIで別に棚卸しし、一時リソースと実行データの残存0件を確認します。
用途別の一時権限と権限上限
Administrator権限を、
日常作業に使わない。
AWSへのアクセスを管理するIAMでは、アカウント管理者と日常作業用の利用者を分離しています。 日常作業用のIAMユーザーはリソースを直接操作せず、用途別のIAM Roleへ切り替えるAssumeRoleを実行し、期限付きの認証情報を取得します。
2026年8月14日の実環境確認では、作業用IAMユーザーがAssumeRoleできるのは設定参照、費用参照、環境構築の3 Roleだけでした。 環境構築用Roleには1時間の利用期限と、許可できる権限の上限（Permissions Boundary）を設定しています。
AWSへ配置する各要素の役割
AWSのマネージドサービスへ、
責務を分割して配置する。
Terraformモジュールで各サービスの構成と依存関係を定義し、同じコミットから検証環境を再構築できます。
WebとAPIへ振り分ける
外部HTTPSを受け付け、WebとAPIを見つける仕組みへ接続する。
API Gateway / Cloud Map認証とtoken発行
利用者の認証とtoken発行を担当し、APIが権限を確認できる情報へ接続する。
Cognitocontainerを個別に動かす
Web、API、MLワーカーを独立したtask定義とECS serviceで実行する。
ECS / Fargate時間のかかる処理をqueueへ渡す
APIとMLワーカーを分離し、処理依頼の配送と再試行を管理する。
Amazon MQ記録の種類で保存先を分ける
業務状態と監査logはRDS、PDFと生成fileはS3へ分離して保存する。
RDS / S3実行記録を一か所へ集める
各containerとbuildのlogを集約し、workflow IDから処理を追跡する。
CloudWatch LogsFargateを選んだ理由
短期間だけ使う検証環境で、
server管理を対象から外す。
Web、API、MLワーカーのコンテナ分割を実AWSでも維持し、EC2インスタンスのプロビジョニングやOS保守を検証対象から外すため、ECS/Fargateを選びました。E2E完了後に実行環境をまとめて撤収しやすいことも判断理由です。
台数、インスタンスタイプ、OSパッチ、ECS agent、キャパシティ不足時のスケーリングを設計・運用します。
タスク定義にリソースを記述し、検証時だけコンテナを起動します。短命な環境の構築・撤収へ集中できます。
Fargateが常時稼働で常に最安という主張ではありません。EC2の台数や空き容量の管理を対象外とし、build・E2E・destroyの全工程を検証するための選択です。
費用を含めた構成判断
常時稼働ではなく、
月次に作って撤収する検証環境にする。
このAWS環境は公開サービスではなく、デプロイ可能性、認証付きE2E、可観測性、撤収能力を定期確認するための検証環境です。
元画面を原寸で見る ↗ 所有者のCost Explorerを読み取り専用で確認した値です。デプロイ試行から2週間以上追加操作を行わず、請求反映を待って再確認しました。Actions外の実地検証、片付け経路の調整、意図的に残す管理基盤、税、Cost Explorer自身の$0.03も含みます。照会回数は断定せず、アカウント識別子や生の管理画面は公開しません。
Actionsの実行履歴から試行回数を確定する。
公開されたActions記録は8回。そのうちAWS配置の工程へ到達した5回だけをデプロイ試行と数えました。3回は途中失敗後もdestroyと残存確認に成功し、2回はE2Eまで含む全工程を完走しています。
費用の最大要因はAmazon MQ。
短い実証でもAmazon MQだけで当月総額の約65%でした。本番向けの冗長化を足せばさらに増えます。作品の説明だけのために動かし続ける合理性はありません。
月に一度だけ全工程を実行する。
$2.43は24時間稼働の月額試算ではなく、5回のデプロイ試行後に2週間以上の反映期間を置いて確認した実績です。月に一度だけ環境を構築し、E2E完走後に即時撤収します。Portfolioで証明したいのは常時稼働ではなく、構築から撤収までを再実行できることです。
通常実行と非常時の片付けを別系統にする
月次実行と60分後の安全装置を、
別系統で動かす。
GitHub Actionsが月次検証を起動し、AWS EventBridge Schedulerが60分後の緊急destroyを予約します。片方の実行基盤が停止しても、もう片方から撤収できる構成です。
既定branchから全工程を実行する。
- 01OIDCで一時的なAWS権限を取得長期access keyなし
- 02containerをbuildしTerraformで構築版管理したIaC
- 03認証から監査までのE2Eログイン / PDF / ML / 人の確認
- 04環境を撤収し残存を検査27カテゴリを棚卸し
普段のpushやPull RequestではAWSを起動しません。所有者の手動実行か、既定ブランチの月次予定だけがこの経路へ入ります。
workflow停止に備えて、環境を作る前に緊急撤収を予約する。
課金対象を作成する前に、EventBridge Schedulerへ一度限りのCodeBuild起動を登録し、設定内容を読み戻します。正常系ではE2E直後にdestroyするため、この予約は実行前に解除します。
GitHub Actionsや作業端末が停止した場合だけ、AWS側が独立してdestroy処理を起動します。Schedulerへの登録だけではなく、撤収後の残存確認までを合格条件にしています。
認証から監査までを通すE2E
サービス単体ではなく、
認証付きの操作フローを通す。
この検証を公開資料ではAuthenticated Smokeと呼び、外部HTTPSから認証、同期API、非同期処理、人による確認、監査記録までを一続きで実行します。
- 01ログイン
Cognito認証
試験専用ユーザーでtokenを取得します。
- 02PDF登録
合成文書を保存
公開可能な合成文書をファイル保存領域へ登録します。
- 03処理依頼
非同期配送
Outboxからqueueへ処理依頼が配送されることを確認します。
- 04ML
文書を分類
MLワーカーが採用済みモデルで文書を分類します。
- 05人の確認
推論結果を確認
利用者が推論結果を承認または訂正します。
- 06監査記録
機械と人の判断を保存
推論と人の判断が別の監査記録として保存されることを確認します。
実AWSで確認した証拠
実AWSで3つのECS serviceを起動し、認証から監査までの試験を完走。
DB更新、試験用の合成データ、ログイン、PDF登録、queue配送、ML推論、人による確認、監査記録を確認しました。 入力はrepository所有の合成データだけで、顧客文書や個人を特定できる情報（PII）は使用していません。
障害を調べる3種類の証拠
状態、アプリケーション、工程の
3層で障害を切り分ける。
失敗時に全logを順番なく読むのではなく、AWS serviceの状態、アプリケーションlog、環境構築workflowの順に確認範囲を絞ります。
まず、今の状態を見る
ECS service、task、接続先の正常性、RDS、MQなど、AWSが管理している状態を確認します。
共通の処理IDで流れを追う
CloudWatch LogsでWeb、API、MLワーカー、DB更新を同じ処理ID（correlation ID）から追跡します。
workflowの実行要約を照合する
GitHub Actions、CodeBuild、Terraformの実行要約から、build・構築・E2E・撤収の停止点を確認します。
生ログにはアカウント識別子、内部URL、トークン、文書内容、秘密情報が混ざり得ます。 本サイトでは「どの層を確認し、何が分かったか」だけを公開し、生の画面や出力は掲載しません。
撤収と、その後の残存検査
destroyの成功だけでは、
撤収完了とみなさない。
Terraformの管理記録（state）外のリソースや、AWS serviceが付随して作成したリソースもあり得ます。destroy後にAWS APIを使った別の棚卸しを実行します。
削除も設計・検証の対象
残ったリソースは、
次回障害と予期しない請求につながる。
AWS公式にも予期しない請求の確認手順があります。EC2インスタンスを停止・削除しても、ボリューム、スナップショット、Elastic IP、別リージョンのリソース、他サービスが作成したリソースは別に残る場合があります。
この実装では一つの削除commandの成功を完了条件にせず、作成対象をtagと管理記録から特定し、依存順に削除し、別経路で残存リソースを検出するところまでを検証対象にしました。
リソース作成前に緊急destroyを予約し、Schedulerの設定を読み戻します。
E2E完了後、権限の制限時間を待たず通常workflowで撤収します。
Terraform state、container image、27カテゴリのAWS APIを別々に確認します。
IAM、状態保存用S3、空のイメージ置き場、片付け用CodeBuildなど、次回も使う管理基盤は意図的に残します。 一時リソースと次回も使う管理基盤を混同しないことも、撤収設計の一部です。 AWSの利用額には反映まで時間差があるため、後日の請求も確認します。ただし、請求額だけを「残存ゼロ」の証拠にはしません。
失敗も検証証拠として残す
失敗履歴も、
検証結果として残す。
完成前には、SchedulerからCodeBuildへ渡す自動destroyが7回失敗しています。 その7回を「成功までの途中」として塗り替えず、後の成功記録と分けて残しました。代表的な学びは次の3つです。
同じファイルでも、名前が違えば検証は止まる
ダウンロードしたTerraformのファイル名と、検証側が期待した名前が一致せず、自動片付けが開始前に停止しました。
中身だけでなく、受け渡しの約束まで固定する。入っているPythonと、実際に選ばれるPythonは別物
CodeBuildには目的の版があっても、実行時には別のPythonが先に選ばれました。
『存在する』ではなく『実際に使われた』を確認する。削除権限だけでは、安全な削除はできない
片付け担当が、対象を特定するための小さな管理記録を読めずに止まりました。
消す権限と、正しく対象を確かめる権限をセットで考える。残す管理基盤と撤収する一時環境
管理基盤と、
一時環境を分ける。
再利用する管理基盤
IAM、Terraform state用S3、空のECRリポジトリ、緊急destroy用CodeBuild。
一時環境
VPC、アプリケーション、データベース、キュー、Cognito、一時データとログ。
実行ごとに作るfileと記録
合成文書、テストユーザー、Scheduler、チェックポイント、実行固有のイメージ。
現時点で実証していない範囲
このAWS検証の対象外。
- 常時稼働する本番サービスや、SLAを備えた商用運用ではありません。
- 高可用性、災害復旧、大人数・大容量での性能を証明するものではありません。
- 小さな合成データの結果は、実業務でのAI精度を保証しません。
- 将来のAWS料金、サービス仕様、別アカウントでの再現性を保証しません。
- この記事はAWSアカウント、IAM、Terraform環境を作る操作マニュアルではありません。
参照資料と検証方法
実AWS、Actionsの実行履歴、
公開実装を照合。
本文は、2026年8月14日に確認した実AWSのIAM・Cost Explorerと、同日時点のPortfolio mainを基に再構成しました。秘密情報やアカウント固有値は公開していません。
次に確認できる内容
システム全体、ML設計、
公開リポジトリへ。
概説では文書処理（Document Intelligence）基盤の全体像、ML編ではモデルの評価・採用・復旧、GitHubでは実装と実行履歴を確認できます。