若干ペースダウンし始めていますが、とりあえずやりきれるところまではやりきりたいと思います。 当初予定していたサービスをかなりスキップしていたりもしますが、今日からは「セキュリティ、ID、およびコンプライアンス」のカテゴリに入ります。
●調査リスト
①公式サイト
https://aws.amazon.com/jp/ram/?c=sc&sec=srv
②ユーザーガイド
https://docs.aws.amazon.com/ja_jp/ram/latest/userguide/what-is.html
③BlackBelt
-
④DevelopersIO記事一覧
https://dev.classmethod.jp/referencecat/ram/
⑤リリースノート
https://aws.amazon.com/jp/new/?whats-new-content-all.sort-by=item.additionalFields.postDateTime&whats-new-content-all.sort-order=desc&awsf.whats-new-security-id-compliance=general-products%23aws-resource-access-manager
⑥ドキュメント更新履歴
https://docs.aws.amazon.com/ja_jp/ram/latest/userguide/doc-history.html
●温度感調査
Developers IO パラメータ
記事数：3
最終更新日Top3：2019.12.02 → 2019.07.30 → 2018.11.27
サービスアップデート状況
サービス提供開始：****
2020/10/16 Resource Access Manager のサポートが AWS Outposts で利用可能に
2020/07/02 AWS Resource Access Manager が欧州 (ミラノ) リージョンで利用可能に
2020/07/02 AWS Resource Access Manager がアフリカ (ケープタウン) リージョンで利用可能に
2020/03/12 AWS Resource Access Manager が中東 (バーレーン) リージョンで利用可能になりました
2020/03/11 AWS Resource Access Manager がアジアパシフィック (香港) リージョンで提供開始
2020年内のサービスアップデートアナウンス：5
ドキュメントアップデート状況
https://docs.aws.amazon.com/ram/latest/userguide/doc-history.html
https://docs.aws.amazon.com/ja_jp/ram/latest/userguide/doc-history.html
2020/12/10 Support for sharing AWS Transit Gateway resources
2020/11/17 Support for sharing AWS Network Firewall resources
2020/10/15 Outposts およびローカルゲートウェイルートテーブルの共有のサポート
2020/09/07 クエリログの共有のサポート
2020/08/17 ACM Private CAプライベート認証機関 (CA) の共有のサポート
2020年内ドキュメントアップデート回数：9回
●AWS Resource Access Manager サマリ
AWSのアカウント間でリソースの共有ができるサービス。
異なるアカウント間でアカウントIDを指定して共有し、受け側で承認すれば共有元のソースを使うことができるし、Organizations配下であればOrganization Unitや組織全体のレベルで共有すれば受け側での承認不要でリソースを共有できる。
2021年１月13日現在、共有できるリソースは下記の通り。
- AWS App Mesh
- Amazon Aurora
- AWS Certificate Manager Private Certificate Authority
- AWS CodeBuild
- Amazon EC2
- Amazon EC2Image Builder
- AWS Glue
- AWS License Manager
- AWS Outposts
- AWS Resource Groups
- Amazon Route 53
- Amazon VPC
共有リソースによってはOrganizations配下のアカウントに対してのに共有が可能なものがあるので注意が必要。
Transait Gatewayの共有
TransitGatewayをRAM経由で他のアカウントに共有が可能です。
これにより組織内でのネットワークルーティングを集約させるようなことができるようになり、たとえば社内ネットワークの接続ポイントを集約したり、外部接続面を作ってインターネットとの界面を共通化したりといった、ネットワーク経路の集約管理ができるようになります。
Shared VPC(VPC Sharing)
RAMの機能を使うことで、VPCの中にあるSubnetそのものを他のVPCに共有させることができる機能。TransitGatewayの共有がネットワーク経路の集約だとすれば、こちらは組織内の共通機能提供のネットワークへの接続をSubnetで実現できるようにさせるというもの。
これを使えば、たとえばOrganizations配下にある共通機能を提供するアカウントで、あるVPC内のSubnetに共通機能/標準機能を実装しておき、これを配下のアカウントに共有して、各ユーザー側のVPCから直接それらの機能を使うことができるようになる。
ただしリージョンを跨いでの共有が出来ないので、シングルリージョンに限定されることや、リソース競合やアクセス上限制御などの考慮が必要になるので注意が必要。
深堀りの有無
実施しない
●所感
現在もレガシーなシステム運用を行っているエンタープライズ企業にとっては、非常に有用に映るこの機能。前述したVPC SharingやTransitGateway共有は、オンプレの世界でいう情シス部門／ネットワーク管理部門が提供したい「共通基盤」の機能であり、ネットワークルーティングや共通機能を単一の経路や物理ホストで提供したいニーズにはマッチするといえるでしょう。
しかし、そもそも現代のWebシステムはmicro serviceで構成されAPIを介してアクセスされるのがデファクトになっているので、このような共通基盤の提供の仕方そのものがすでにナンセンスなのではないかと個人的には感じます。
たとえばネットワーク経路を１本に絞ってしまうことは一見効率的であるように見えますが、実はここを通過するすべてのトラフィックを考慮して運用する必要があります。また共通機能を提供するのであればAPIを用意して叩かせればよく、もしそれが同じAWS内部での提供であるならPrivateLink経由で承認した相手にとだけ通信させればよいので、わざわざVPC SharingでSubnetごと共有し、レガシーな時代のホスト運用を維持したまま共通機能提供させる必要性がありません。
せっかくクラウドでこのあたりを考慮しなくて良くなっていく時代にあって、それとはまったく逆行する使い方に見えなくもないですが、それはあくまでサービス・プロバイダとなるシステムがすべてAWS上で構築されていれば、の話。まだまだオンプレミスで構築した/すべきシステムが多数残っているだとか、運用部門の体制や運用フローがクラウドに寄せたものに出来ない企業なども多いでしょうから、そういった組織にとってはオンプレの考え方をクラウドの中で提供できるという意味では選択肢の一つとしてアリなのではないかと思います。
RAMの機能は一見、非常に有用であるように見えますが、このような課題がある点を理解した上で、適用する場合には運用コストも考慮に入れた十分な比較検討を行う必要があると思います。
●参考情報
↓20190130 AWS Shared VPCを前提としたネットワークとセキュリティの設計
https://www.slideshare.net/AmazonWebServicesJapan/20190130-aws-shared-vpc
↓新機能VPC Sharing(Shared VPC)のドキュメントを読んでみる - サーバーワークスエンジニアブログ
https://blog.serverworks.co.jp/tech/2018/12/03/post-67594/
↓クロスアカウントな AWS Transit Gateway を、絵で見て（完全に）理解する。 | Developers.IO
https://dev.classmethod.jp/articles/transitgateway-cross-account-diagram/#toc-6
