こんにちは、JAWS-UG 初心者支部の尾谷です。
AWS ユーザーコミュニティに参加すると、いろんなしくじり話が聴けます。
僕も、今月の最初に作った AWS アカウントのランニングコストが会社と精算できずに困っていますので、速報ベースで Share my lesson させていただきます。
このブログで話すこと
- Identity Center が起動できるケースと、起動できないケース
- AWS Organizations でアカウントの招待が失敗する原因
- Organizations 組織に入っても、入った月の月額ランニンングコストはメンバーアカウント側に請求される
IAM Identity Center には 2 種類のインスタンスがある
とあるプリセールスのタスクがあり、オンプレミス Windows AD サーバー → AWS Managed Microsoft AD / AD Connector → IAM Identity Center → SAML → Cognito を SAML 2.0 で連携する検証が必要でした。
提案書をまとめるために、EC2 インスタンス 2 台と、Directory Service、Identity Center を用意することにしました。
僕が普段利用している検証アカウントは、会社の Organizations に紐づいています。
Identity Center には、組織インスタンスとアカウントインスタンスの 2 種類のインスタンスがあります。
- 組織インスタンス:
- Organizations の管理アカウントで有効化する IAM Identity Center
- 管理ポイント数を最小限に抑えるため、AWS はこちらの起動を推奨
- アカウントインスタンス:
- メンバーアカウント内で作る Identity Center
- メンバーアカウントで起動し、メンバーアカウント内で利用可能
- SAML 2.0 を使用する「顧客管理型アプリケーション」は非サポート
なお、2022 年に Identity Center はメンバーアカウントにて委任管理できるように仕様変更されています。
IAM Identity Center のアカウントインスタンス作成が禁止されている
上記前提のもと、僕の検証アカウント（メンバーアカウント）で、Identity Center のアカウントインスタンスを起動しようとしたところ、以下のメッセージが表示されました。
管理アカウントにサインインして Identity Center の管理タブを確認すると、IAM Identity Center のアカウントインスタンスが無効化されていました。
機能が無効化され Identity Center インスタンスが起動できず、起動できたとしても SAML 2.0 をサポートしていないので手詰まりになりそう、、、ということがわかってきたので、野良アカウントを作ることにしました！
野良アカウントについて
ここで「野良アカウント」について補足の説明をします。
AWS は、複数のアカウントを管理するために AWS Organizations の利用を推奨しています。
全てのアカウントを Organizations のメンバーアカウントとして登録することで、サービスコントロールポリシー（SCP）をはじめとする様々なガバナンスが適用できます。
これにより企業では、従業員が許可されていないリソースを勝手に起動したり、不要なリソースの管理がいつまでも動いているといった状況を管理できたりします。
更に、請求を一本化できるため、誰がどれだけコストを使っているかを俯瞰的に把握できます。
一方で、そうした組織の規制を潜り抜けるために、勝手に作られるアカウントを一般的に野良アカウントといいます。
ちなみに、今回、僕が作ったアカウントは「制限を受けないようにする」ためという部分は「野良」ですが、プリセールスでどうしても必要な検証だったので然るべくタイミングで、社内で事情を説明しながら調整して作りました。
決して「隠れて勝手に作った」わけではないことを弁解させてください！
月初にアカウントをサインアップする
検証には Identity Center に加え、AD サーバーも必要です。
Windows EC2 インスタンスは、無料で利用できる Identity Center と違いランニングコストがかかるため、7 月 1 日にアカウントを作ることにしました。
メールアドレス、住所、電話番号などを登録して、電話とクレジットカードの認証を済ませて利用できる状態にしました。
モックサイトまで完成
後輩エンジニアに Windows の EC2 インスタンスを プライベートに起動してもらい、Active Directory を設定したもらいました。この AD サーバーと Trust で組んだ Microsoft Managed AD と、AD Connector 経由で Identity Center に接続した 2 つの環境を用意し、それぞれを Cognito に SAML 連携して、デモンストレーションできるように S3 と CloudFront でログイン画面を作りました。
Organizations に紐付けすることを決定
お客様への提案も終わったので、環境を削除することにしました。
業務で発生したランニングコストなので、会社の Organizations に紐付けて、リソースを削除しアカウントを閉鎖することにしました。
Organizations の招待エラー
Organizations に野良アカウントを入れ込むことにしました。
会社に報告をして、調整がついたので、作業を進めました。
Organizations の管理アカウントから「既存の AWS アカウントを招待」を選択し、アカウント ID を指定すると、以下のエラーが表示されました。
あなたの提供した値は要求されるパターンに合致していない...？何かよく分からないメッセージです。
アカウント「123456789012」を招待できませんでした。 123456789012: InvalidInputException You provided a value that does not match the required pattern.
ドキュメントを確認する前に、まずは Kiro に聞いてみることにしました。
InvalidInputException: You provided a value that does not match the required pattern. は、Organizations の招待 API にアカウント ID ではなくメールアドレスを渡す必要があるケースか、もしくは入力値にスペースや不正な文字が混ざっている場合に発生します。
よくある原因:
- アカウント ID の前後に余分なスペースが入っている — コピペ時に見えない空白が混入するパターンが多いです
- コンソールの招待フォームでメールアドレス欄にアカウント ID を入力している（またはその逆） — 招待には「アカウント ID」か「メールアドレス」のどちらかを正しいフィールドに入力する必要があります
- アカウントが既に別の Organization に所属している — ただしこの場合は別のエラーメッセージになるので、今回は可能性が低いです
スタンドアロンの AWS アカウントで Identity Center インスタンスを起動する際に、組織インスタンスを選択していたようです。その際、自動的に Organizations が作られたと思われます。勉強になりました。Organizations 組織を削除しました。
その後、10 分ごとに Organizations 参加を試行し続けていったところ、1 時間が経過した頃にようやく招待が成功しました。
Organizations 組織に入っても、入った月の月額ランニンングコストはメンバーアカウント側に請求される
ここまで 2 時間ほど使って野良アカウントを Organizations に紐付けましたが、運用チームのマネージャから「自分のクレジットカードへの請求は止めれない」と教えてもらいました。な、なんと！
公式ドキュメントに記載あり
公式ドキュメントには以下の記載があります。
メンバーアカウントが月の途中で Organizations 組織に参加した場合は、管理アカウントにはその月の後半分の料金のみが請求されます。
通常、AWS は以下の図のように月初から月末までのランニングコストが翌月の早朝に確定し、翌月の月初に請求されます。
なので、Organizations に入ると翌月の月初には、管理アカウントに請求書が届くと思っていたのですが、そうではなく、Organizations 登録前後で分かれて、それぞれ請求されることが分かりました。
今回の検証でかかったランニングコストの内訳
ちなみに、今回の SSO 連携に関してかかったランニングコストは 14 USD 程度でした。完全プライベート環境で検証をしたので、パブリック IP アドレスの課金もなく、意外と安く済みました。
Microsoft Managed AD と AD Connector は、それぞれ 1 ヵ月無料で利用できると思っていたのですが、Directory Service 全体として 1,500 時間/月 の無料枠が割り当てられているのでした。
Microsoft Managed AD は 2 台が冗長して起動します。更に AD Connector の検証も行ったので、半月超えたあたりから課金されていたことが分かりました。
まとめ
通常、Organizations のメンバーアカウントで検証を行う場合は、Sandbox OU 配下にアカウントを移動します。
SCP などのポリシーの影響を受けない OU であれば、ほとんどの検証が行えます。
今回のように、Identity Center でアカウントインスタンスが無効化されていて、検証ができないようなケースは非常に特殊だったと思いますが、野良アカウントは精算が面倒だったので、この経験がどなたかのお役に立てば幸いです。
以上です。
最後までお読みくださりありがとうございました。
