顧客フロントSEのIT勉強ブログ

2022 Japan AWS Top Engineer / 2022-23 Japan AWS Certifications Engineer。AWS認定12冠、情報処理試験全冠。顧客フロントSEがなるべく手を動かしながらIT技術を学んでいくブログです。

トップ > AWS Tips > AWS RAM: マルチアカウント運用の必須サービス

AWS RAM: マルチアカウント運用の必須サービス

AWS Tips

こんにちは、大石（@se_o_chan）です。
AWSをマルチアカウントで運用する事例が増えてきているようです。AWS Organizationsはマルチアカウント運用において必須サービスですが、個人的にはAWS Resource Access Manager（AWS RAM）も同様に必須だと考えています。
今回は私が実際に活用しているAWS RAMのユースケースをいくつかご紹介したいと思います。

この記事を書こうと思ったきっかけ

　2024年2月15日にJAWS-UG東京「AWSライトニングトークNight」が開催されました。そこで「大規模マルチアカウント環境を運用する時の悩みと解決法」というタイトルで登壇させていただいたのですが、聴講者から
　・RAMの有効活用が重要そう
　・知らない情報がいっぱいあった
というコメントをいただきました。案外AWS RAMって目立たないのかも？と感じたのですが、個人的にAWS RAMはマルチアカウント運用における中心サービスの1つだと考えているので、啓蒙活動もかねてRAMのユースケースをご紹介したいと思いました。

　JAWS-UG東京で触れた内容に加えて、時間の関係上、LTに含められなかったユースケースもご紹介していきます。ちなみにLTの登壇資料はこちらです。

speakerdeck.com

AWS Resource Access Managerとは

　AWS Resource Access Manager（AWS RAM）とは、クロスアカウントでAWSリソースを共有できるサービスです。共有先のAWSアカウントを個別に指定することもできますが、AWS Organizationsを使用している環境だと組織単位（OU）で共有先を指定できるため、より運用負荷を軽減できます。

ユーザガイドのリード文はこちら。

AWS Resource Access Manager (AWS RAM) を使用すると、AWS アカウント 全体、組織または組織単位 (OU) 間、およびサポートされているリソースタイプの AWS Identity and Access Management (IAM) ロールやユーザーと安全にリソースを共有できます。
複数の AWS アカウント がある場合、リソースを 1 回作成し、AWS RAM を使用してそのリソースを他のアカウントで使用できるようにすることができます。

2024年3月現在、共有可能なリソースは次の通りです。

私のAWS RAMユースケース

　では実案件で私がAWS RAMをどのように使っているかご紹介します。その案件ではオンプレミスから大規模にシステム群をAWSへマイグレーションしており、約100のAWSアカウントをOrganizations＋RAMで運用しています。

ケース①：Transit Gatewayでクロスアカウント通信

　もっともスタンダードなAWS RAMの使い方かと思います。VPCが数十個になるとVPC Peeringで相互に接続するのは管理負荷が高くなりますが、Transit GatewayでVPC・オンプレミスの中継ハブを作れば運用が簡略化できます。

ただTransit Gatewayを定義・保持するのは1アカウントになるので、マルチアカウント運用だとそのTransit Gatewayをアカウントをまたいで共有しないといけません。そこでRAMを使います。

Transit Gatewayは多くのシステムの共有リソースですので専用アカウントに分離したほうが、システム開発者が間違ってもTransit Gatewayを誤削除しなくなりますし、利用料も管理しやすくなるでしょう。

ケース②：プレフィックスリストで通信制御を一元化

　オンプレミスだとファイアウォールを使って「本番LAN」「開発LAN」のようにネットワークセグメントを分離するケースが多いのではないでしょうか。同じような運用をAWSで実現しようとするとセキュリティグループで通信制御することになると思いますが、マルチアカウント運用だとセキュリティグループの定義が点在してしまうことになります。

ここで困るのが「本番LAN・開発LANの定義が変わった場合」で、数十個のセキュリティグループを修正しないといけません。

　そこでプレフィックスリストをRAMで共有します。プレフィックスリストとはIPレンジをグルーピングできる機能で、VPCコンソール内で設定できます。S3のゲートウェイ型VPCエンドポイントを作成した時に、ルートテーブルに「pl-61a54008」へのルートが自動生成されているのを見たことがないでしょうか？あれはAWSが管理してくれているマネージドプレフィックスです。S3のパブリックエンドポイント（52.219.136.0/22など）をグルーピングしてくれているんですね。

　このプレフィックスリストをRAMでクロスアカウントに共有し、それを使ってセキュリティグループを定義します。するとオンプレミス運用のように本番LAN、開発LANの定義が一か所に集約されるため、定義変更時も一か所だけ修正すればよくなります。

ケース③：Route 53 Resolverで独自ドメインの名前解決

　オンプレミスでサーバ運用している場合、Active Directoryなどで独自のドメインを管理していることもあるでしょう。EC2から独自ドメインに対して名前解決するにはどうすればよいでしょうか？

1つはDHCPオプションセットで独自ドメインのDNSサーバを指定することです。シンプルな方法ですが、これだとRDSなどAWSリソースに払い出されるDNS名の名前解決ができません（DNSサーバがパブリックDNSにフォワーダ設定されていれば名前解決できますが）。さらにマルチアカウント運用の場合、DHCPオプションセットの定義が点在するため、DNSサーバのIPアドレスが変わる際に修正量が多くなってしまうデメリットがあります。

　それらの問題を解決するのが、Route 53 ResolverのアウトバウンドエンドポイントをRAMで共有する方法です。Route 53 Resolverとは、オンプレミスとAＷS環境間で、DNSクエリを相互に応答できるようにするサービスです。AWS側からオンプレミスのDNSサーバに名前解決しに行く場合は、Route 53 Resolverのアウトバウンドエンドポイントを作成することになります。

さらにこのアウトバウンドエンドポイントに紐づくフォワーダルールをRAMで共有します。するとVPCデフォルトのDNSサーバ（＝Amazon DNSサーバと呼ぶそうです）に対してオンプレミスのDNSサーバへのフォワーダ設定が適用されるので、EC2はAmazon DNSサーバを参照したまま、独自ドメインの名前解決もできるようになります。使っているのはAmazon DNSサーバですから、当然AWSリソースのDNS名も解決できますし、Route 53 Resolverのアウトバウンドエンドポイントを修正するだけでオンプレDNSサーバのIPアドレス変更にも対応できます。

ケース④：Route 53 ResolverでVPCエンドポイントを共有

　VPC数が増えて各々でVPCエンドポイントを作っていると、VPCエンドポイントの利用料がバカにならなくなります。下図の例だと100アカウントで1,400個のエンドポイントができ、月額200万円もかかってしまう計算になります。

　そこで、まずVPCエンドポイントをとあるアカウント（ケース①でTransit Gatewayを作成したアカウントがよいかもしれません）で作成します。次にケース③でも使ったRoute 53 Resolverで、今後はインバウントエンドポイントを作成します。さらにアウトバウンドエンドポイントに「VPCエンドポイントに対するDNSクエリはインバウンドエンドポイントに転送」というルールを紐づけ、そのルールをRAMで共有します。

そうするとVPCエンドポイントを作成するのは1か所のみでよくなるので、月額2万円に削減できます。ただし、Transit Gatewayを通じて通信が流れるため、0.02USD/GB（2024年3月現在）のデータ送信料が別途かかるのに注意です。転送量が多いアカウントは例外的に自身のVPC内にエンドポイントを作るなど、調整するのがよいでしょう。

ケース⑤：IP Access ManagerでIPアドレスを統合管理

　大規模マルチアカウント環境になると、VPCの数も数十～百以上になり得ます。そこで避けたいのは「IPアドレスの重複」です。IPアドレスが重複しているVPCをTransit Gatewayの管理下に配置することはできないため、ExcelなどスプレッドシートでIPアドレス管理表を作っている方もいらっしゃるのではないでしょうか。

そこで便利なのがAmazon VPC IP Access Mangager（通称IPAM）です。あらかじめIPレンジをプールとして定義しておき、VPC作成時に「IPAM割り当てのIPv4 CIDRブロック」を選択すれば、プール内の空きから自動的にIPアドレスを割り当ててくれます。

ここまでくれば想像つくと思いますが、マルチアカウント環境でIPAMのプールを共有するためにRAMを使います。するとExcelでのIPアドレス管理も不要になり、作業ミスや不注意によるIPアドレスの重複もなくなります。

まとめ

　実際に私が活用しているAWS RAMのユースケースをご紹介しました。数個程度のAWSアカウントならRAMを使わないでも運用できるかもしれませんが、数十個の規模になると避けて通れない必須サービスです。ぜひぜひ皆さんも有効活用して、快適なマルチアカウント運用を実現しましょう！

参考

ケース①： トランジットゲートウェイの共有に関する考慮事項 - Amazon VPC
ケース②： プレフィックスリストとResource Access Managerを使用したオンプレミスNW情報の一括管理 - NRIネットコムBlog
ケース③：ネットワークへのアウトバウンド DNS クエリの転送 - Amazon Route 53
ケース④：複数の VPC から中央のAWS のサービスエンドポイントにプライベートにアクセスする - AWS 規範ガイダンス
ケース⑤：AWS RAM を使用して IPAM プールを共有する - Amazon Virtual Private Cloud

se_o_chan 読者になる

広告を非表示にする
読者になる
コメントを書く