今日はこれをやっていきます

まず AWS のリージョンについて
https://aws.amazon.com/jp/about-aws/global-infrastructure/regions_az/

AWS にはリージョンという概念が存在します。これは、データセンターが集積されている世界中の物理的ロケーションのことです

AWS はアカウント作成時点で多くの Region がデフォルトで有効となっており、追加設定無く利用出来るようになっています（もちろん利用した分だけ請求は来ますが）

世界中のデータセンターから自在にリソースを調達できるのはクラウドの一つの醍醐味。しかしだからといって AWS でデフォルトで有効化されている Regions は数多く、ガバナンスやセキュリティ面から考えると「逆に自在過ぎて心配」になってきたり致します。とくに数十ものメンバーアカウントを抱える Organization ですとなおさらです

例えば「使うのは日本国内と米国東海岸系だけ」といった場合、それ以外の、例えば欧州、カナダ、オーストラリア等は蛇足であるばかりか、放置しておくことで意図しない課金やセキュリティリスクを懸念することになります。
でもいくらセキュリティリスクに対処したいと言って、使いもしない Region なのに Securit Hub 等を入れたりすれば余計な課金や管理負荷が生じてしまい割に合いません。 Region 毎の課金をいちいち監視したりするのもイヤ

そこで「不要なリージョンをそもそも使えないようにさせる」という手段が用意されており、これが SCP による Region 規制となります。

SCP は Organizations のマスターアカウントで設定し、任意の OU またはメンバーアカウントに対してトップダウンで作用します。この機能を通じてマスターアカウント側から「この操作は禁止」と指定したら、いくらメンバーアカウント側で頑張っても逆らえません。たとえメンバーアカウント側の AdministratorAccess 権限であってもです。規制解除のためにはあくまでもマスターアカウント上で SCP を操作できないといけないので、前述のリスクを排除するための手段として、十分強力だと言えるでしょう

※ ここからは AWS Organizations や SCP について基本的な知識がある前提で進めていきます

導入

では早速導入していきます。次の前提条件が満たされているものとします

SCP そのものについて十分理解できていること
- 先程強力だと書きましたが、大いなる力には大いなる責任が伴います。 SCP による影響を十分理解・検証した上で適用することをお勧めいたします（とくに本番環境）
SCP が対象の organization で利用可能になっている

ポリシーのソースをカスタマイズする

今回は公式の例を少し改造したこちらを使います
公式との差分はこちらです
必要な（=規制対象から除外させたい） Region(s) を明示的に列挙する必要があります。自組織に必要な Region(s) に書き換えましょう

施行

あとはこのソースで SCP を作成し任意の OU またはメンバーアカウントに対してアタッチするだけ

動作確認

試しに対象のメンバーアカウントに管理者権限でアクセスしてみます。
このように規制したい Region(s) でエラー表示が出ていれば成功

これと同時に、当然ですが、必要な Region(s) では問題なく操作できなければいけません。規制から除外したリージョン（この場合 us-east-1, ap-northeast-1）にも行き、同様のエラーが出ていないことを確認します
さらにこの辺の CloudFormation を試しに走らせてみて確かめるとよいでしょう。これとかこれが丁度いいかもしれませんね

グローバルサービスを網羅的に列挙する必要がある

実は当組織では最初、規制対象外となる Region を書き換えただけで施行していましたが、これだと意図せず AWS Chatbot を規制してしまっていました。原因は Chatbot がグローバルサービスであったのに、施行した SCP 内の Statement.NotAction に明示されていなかったから。施行後、ある開発チームから「AWS Chatbot を使いたいが、エラーが出てしまうので規制解除してほしい」というリクエストが来て気付きました。これを受けて SCP をアップデートしたところ解決となりました

(Optional) AWS SSO Custom permission set で規制をバイパスする

今回施行した SCP では Statement.Condition.ArnNotLike.aws:PrincipalARN も書き換えていますがその理由を説明します

まず、ドキュメントに書いてあるこれですが

この例では、指定した 2 つの管理者ロールのいずれかによって行われたリクエストを除外する方法も示しています。

これは次の部分が該当するようです

 "ArnNotLike": {
                    "aws:PrincipalARN": [
                        "arn:aws:iam::*:role/Role1AllowedToBypassThisSCP",
                        "arn:aws:iam::*:role/Role2AllowedToBypassThisSCP"
                    ]
                }

Role1AllowedToBypassThisSCP, Role2AllowedToBypassThisSCP という名称の Role であればこの SCP を回避できることになります（名称がそのまんまですが）

けれどもよくよく考えてみれば、これらの Role さえ作成すれば容易に規制をかいくぐることができてしまう、という重大な注意点にもなるのではないでしょうか。
実際、 Role1AllowedToBypassThisSCP はメンバーアカウント側の権限で任意に作成できてしまいました

せっかく中央集権的に施行した規制なのに、現場サイドに簡単な抜け道を与えてしまっているわけですね。
これを良しとするかは組織の方針にもよりますが、当組織ではこれはなじまない、と判断しました。単純に Condition.ArnNotLike を削除してしまう手もありますが、もしかしたら何らかの理由でこの回避策が緊急に必要となる場面もあるかもしれません。そのときになって、一時的に SCP をデタッチするという手もありますが乱暴だし対象が OU だった場合は影響範囲がみだりに広がるし、後でアタッチし直すのを忘れたなどのミスによる影響の大きさも心配です。
要は一応この回避策は留保しつつ、メンバーアカウント側の独断では利用できないように安全にしておきたいわけです。

そこで、 AWS SSO で専用の custom permission set を用意し、これに対応する Role 名を指定してはどうかと考えました。 SSO を通じてメンバーアカウント上に自動的に作成される Permission sets 由来の role は、 arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_* みたいになっており、メンバーアカウントのユーザでは任意作成することができないようです
Permission sets もまた Organizations マスターアカウントの SSO で制御する必要があるため、この名称の role を作成できるのはマスターアカウントだけということになり、メンバーアカウント側からは作成できないはず

AdministratorAccessWRR は筆者が任意に追加した専用の Custom Permission set で、 Administrator Access Without Region Restriction のつもりです。この名称は aws:PrincipalARN で指定したものと一致していれば何でも構いません

あとはこの Permission set をきちんと管理出来ていれば安心というわけ。ただ今のところは、当組織でこれが必要な状況は直ちには思い浮かびませんので、当面出番は無いかなと思います
※EC2 インスタンスや Lambda Function 等にアタッチする用の非属人的な role も、、となると別途考える必要はありそうですが、基本的な実現方法は今回を通じて理解できましたのでもし必要になったら検討することにします

現在 sandbox アカウントでこの SCP を試用していますが、前掲の Chatbot 以外には、とくに問題は聞こえてきません。~~今後、他のアカウント群にも施行していければと考えております~~
2021/06/15 追記: 対象を 9 アカウント（何れも non-production）に拡大し、引き続き運用中です