AWS Outputs上のリソースはCDKでどう管理するのか？　サブネット、EBS Volume、ALB、S3 on Outpostにおける、それぞれのポイント

「EBS Volume」はデプロイ先 Outpost を指定するだけ

福田優真氏（以下、福田）：実際にCDKコードを書いて管理してみたので、具体的にどんなコードを書いたかを見ていきたいと思います。

EBS Volumeは、本当にデプロイ先Outpostsを指定するだけでよくなっています。本当はもうちょっと必要な部分もあるのですが、そこらへんを削ぎ落として、Outpostsでデプロイするのに必要な分がどれなのかというと。OutpostArnというプロパティがあって、ここにデプロイ先のOutpostsのARNを指定すると、Volumeが勝手にOutposts上に載る感じになっています。なので、CfnVolume自体の用意はかなり簡単です。

「S3 on Outposts」はバケットとは別に2つをデプロイしなければならない

S3 on OutpostsもL1でサポートされているので楽にはできますが、必要なものがいくつかあります。S3 on Outpostsのバケットとは別に、Outpostsエンドポイントとアクセスポイントという、2つのものをデプロイしなければいけません。

ドキュメントを読むと、Outpostsエンドポイント自体はVPCからS3 on Outpostsへ接続するためのネットワークインターフェイスコレクションらしいです。感触としては、他のVPC上のエンドポイントとあまり変わらないものかなと思います。

また、アクセスポイントは比較的最近追加されたS3の機能です。S3バケットにバケットポリシーをいろいろくっつけるとポリシーがぐちゃぐちゃになって大変だねというのがあって、最近こういうアクセスポイントが導入されました。

バケットに直接ゴチャゴチャとポリシーをつけないで、このアクセスポイントに個々に必要なバケットをつけて、その個々のリソースからそのアクセスポイントに接続すれば、バケットポリシーの管理が楽になる機能があって、これも用意しなければいけません。ドキュメント上にも、ちょうど2つ必須ですよと書いてあるので、必ずこれら2つを用意する必要があります。

バケット自体もAWS S3ライブラリの下にあると思いますが、そちらはパブリックS3だけになっていて、S3 on Outposts用のはまた別にS3 Outpostsというライブラリがあるので、こちらを利用する必要があります。先ほども言いましたが、こちらはプレビュー段階なのでちょっと注意が必要です。

Outpostsエンドポイントとは何か

福田：「Outpostsエンドポイントは具体的にどんなものなの？」「デプロイはどうするの？」というのがあります。こちらは、subnet内にOutpostsごとに用意するエンドポイントになっています。同じsubnet内に2つ作ろうとするとエラーになるので、subnetに必ず1つしか作れないし、subnet内で共有して利用されるようになっているので、特に何もしなくても意外とそのままアクセスポイントを設置するだけでもよかったりします。

これ自体は設定を見ればわかるのですが、バケットに直接ひもづいてはいなくて、どちらかと言うとOutpostsとsubnetにひもづいているものなので、そのsubnetと一緒に管理したほうが粒度としては良さそうという感じです。これを特定するまでにちょっと時間がかかりました。

普通のエンドポイントなので、443のinboundルールを持つセキュリティグループを割り当てなければいけません。L1レベルでしかサポートしていないので、自分で443のinboundルールもセキュリティグループを作ってアタッチするのが必要になります。

たぶんCDK上で扱うのは最近サポートされたみたいです。2021年10月あたりに自分が触った時には、CLI上からしか触れなかったような記憶があります。あとはマネジメントコンソールからも触れたのですが、いつの間にかCDKから触れるようになったという感じですね。

なぜこれがS3 on Outpostsにひもづいてるように見えるのか。S3 on Outpostsと同じ管理画面、S3のマネジメントコンソール上にひもづいていて、最初これはS3 on Outpostsと同じように管理するのかなと思ったら、実はどうもそうじゃないというのをあとで知った感じです。

Outpostsエンドポイントの設置の仕方

福田：具体的にエンドポイントをどう設置するのか。もう本当に、デプロイ先のOutpostsのIDと443 inboundルールを持つセキュリティグループのアタッチと、subnetのIDを指定する感じです。これでデプロイできます。

アクセスポイントを設置する必要があるのですが、その前にバケットを用意しなければいけません。バケットを用意したあとにアクセスポイントをそのバケットに向ける作業が必要なので、バケットも用意します。S3 on Outpostsのライブラリに専用のコンポーネントがあって、こちらにバケットがあるので、これを利用しなければいけません。

S3 on Outposts自体は、Outpostsごとに分離されたもので、パブリックS3とも分離された別のS3のサービスになっています。なので、どこのOutpostsにバケットを用意する、みたいな指定をしなければなりません。CfnバケットもbucketNameだけではなく、デプロイ先のこういうバケット、outpostIdが必要になります。

最後にアクセスポイントを用意します。これ自体はS3の最新の機能の1つですが、バケットに直接ひもづいてバケットポリシーを管理してくれるものです。なので、S3 on Outpostsバケットと一緒に、CDKコードで管理したほうが良さそうだと思っています。これ自体はVPC単位でデプロイするものなので、1個用意しておけばそのバケットに対して1つのアクセスポイントでアクセスできます。

実はこれ、先ほどもちょろっと言ったのですが、アクセスポイントをデプロイすると、Outpostsエンドポイントもデプロイされるようにひもづいているようで、直接Outpostsエンドポイントを管理するメリットは、実はあまりないかもしれないと最近思っています。そこらへんは、ちょっとまだわかりきっていないところですね。

アクセスポイントをどういうコードで用意するか。こんな感じのコードです。ひもづけるバケットと、vpcConfigurationのデプロイ先のVPCのvpcICを指定します。

ただこのvpcConfigurationは現状vpcIdしか指定できません。今後追加する予定なのかもしれませんが、Nexusでobjectを書くのがちょっと微妙かなと思ったりします。あとはアクセスポイント名をつけるのが必須なので、自分でちょっと名前をつける感じですね。

パブリックS3のアクセスポイント自体は、S3がグローバルサービスなので、バケットはbucketNameだけ指定すればいいです。

ただ、S3 on OutpostsはoutpostIdとかがもうARNに入っていて、どのOutpostsのどのバケットをこのアクセスポイントとひもづけるか指定をしないといけないので、バケット名ではなくて、バケットARNのほうを取るところに注意がちょっと必要です。

subnetのデプロイ方法

福田：ここまではS3 on Outpostsについて長々と解説してきましたが、次はsubnetのデプロイ方法について見ていけたらと思います。

これ自体のデプロイはサポート済みなので、L1を使ってデプロイすればいいのですが、先ほど言ったように顧客所有のIPアドレスをつける設定、MapOnCustomerOwnedIpOnLaunchを入れるには、カスタムリソースを使って自前で管理しないといけないところがあります。

デプロイ自体はこういう感じでoutpostArnを指定するだけなのですが、MapOnCustomerOwnedIpOnLaunchは先ほどの設定では設定できなくて、自分でこのModifySubnetAttribute APIを叩いて設定しなければいけません。

ちなみに、CreateSubnet APIにはこの設定がなく、確かそれ以前のCloudFormation側でも設定がないので、たぶんそこが引っかかって設定ができないのかなと考えてはいます。

この設定をくっつけるためには、具体的にこんな感じのHandlerを用意すればいいです。CustomerOwnedIpv4Poolという顧客所有のIPはプールされますが、そのプールにそれぞれIDがついているので、まずそれを設定します。

あとMapCustomerOwnedIpOnLaunchがあるので、これをtrueに設定すると書いて、これをmodifySubnetAttributeに渡して読んであげれば設定できます。

ALBのデプロイ方法

福田：続いて、ALBのデプロイ方法。こちらはOutposts上へデプロイもできないので、カスタムリソースで自前でいろいろと管理する必要があります。普通のものはみなさんもご存じだと思いますが、Outpostsでやるにはカスタムリソースを書かなければいけません。

顧客処理のIPをつける操作もカスタムリソースでついでにつける必要があるので、このALBをOutpostsで扱うのは、そこらへんがつらいです。

subnetと違って、CreateLoadBalancer APIでは設定できますが、ModifyLoadBalancerAttributesにはないので、あそこは不一致があって、ここがちょっとCFnの大変だったところですね。

具体的にどんなHundlerを作ってあげればいいか。こんな感じのパラメーターを用意します。CustomerOwnedIpv4Poolをくっつけて、先ほどの顧客所有のIPアドレスのプールIDをつけて、CreateLoadBalancerを呼ぶといいです。

あとLoadBalancerのあれですね。ここを忘れていますが、確かOutpostsのARNかIDが必要です。忘れていましたね。

カスタムリソースの特徴として、更新時にリソースだけを作っておけば古いものは自動削除されるので、同じように更新時もLoadBalancerを作ればOKです。デリートは、deleteLoadBalancerに消したいLoadBalancerのARNを指定すればOKです。

各リソースをCDKで管理してわかったこと

福田：Outposts上で動くリソースをCDKで管理するというところは話してきましたが、かなり大変だったので最後にまとめます。

サポート状況に関しては、L2が現状Outpostsを扱っていないので、L1サポートのみというところに気をつけなければいけません。他のリソースもL1サポートのみだったりします。

Outpostsへのサポート状況はけっこうリソースごとにバラつきがあり、EBS VolumeやS3 on Outpostsはサポート済みで、subnetの一部機能はサポートしていないとか、ALBでOutposts上にデプロイするのは現状ではサポートしていないとかあって大変でした。

最後に全体のまとめです。オンプレでもクラウドの恩恵を預かれるハイブリッドクラウド製品が近年登場してきたね、というところで。AWSがAWS Outpostsを出していろいろやっていることを理解してもらえればなと思います。

AWS Outpostsに展開するリソースをCDKで管理する方法について紹介しました。現状はまだCDKでやるにはカスタムリソースでちょっとがんばらなきゃいけないねというところで、カスタムリソースに関する知識がいろいろと必要です、というところだけ覚えておいてほしいです。

以上で発表を終わります。ご清聴ありがとうございました。

質疑応答

吉田真吾氏（以下、吉田）：ありがとうございました。新居田さん、質問は来ていますか？

新居田晃史氏（以下、新居田）：はい、いろいろ来ています。Outpostsはみんな気になっている感じですね。1個目が、「Outposts上のEC2と通常のEC2を使う場合と比較すると、どんな制約がありますか。基本的には同じように使えそうですが、気になった点があれば教えてほしいです」ということです。

福田：こちらはまったく変わらないです。パブリック上のEC2 Instanceとぜんぜん変わりません。デプロイも単純にsubnetに載せるだけなので、subnetをOutposts上に用意しておけば勝手に、root volumeにあるEBS VolumeもOutposts上に展開されるようになっています。他のパブリック上のAWSと一切変わらないで、意識することなくOutposts上に載っているみたいな感じになります。

新居田：途中でARNだけOutposts用のARNに変えるみたいなことを言っていたような気がするのですが、そのへんは意識する感じですか？

福田：EC2 Instanceに関しては本当に意識する必要はないです。subnetはデプロイ先のOutpostsを意識しなければいけませんが、EC2自体はsubnet上に載るので、「ここのOutpostsにデプロイしてね」みたいなoutpostArnは特に必要ないです。本当にsubnetに載せるだけです。

新居田：わかりました。ありがとうございます。

2つ目が、「L2、L3のサポートがされる際には、どのような機能や抽象化がされることを要望しますか」というところで、これはもしかしたら中の人からの質問かもしれません（笑）。

福田：あー（笑）、そうかもしれませんね。そうですね。やはりOutposts上にデプロイする部分のプロパティが欲しいなっていうのが今一番です。AWS EC2の下にあるL2のsubnetには、outpostArnという設定後に取り出すプロパティはあるんですが、設定ができないので。L2に入る際には「そこのプロパティとしてこのOutpostsにデプロイするよ」みたいなのがサポートされるといいなと考えています。

新居田：ありがとうございます。では最後です。「ぶっちゃけ、Outposts IaC with CDKの開発体験はどうでしたか」というところですね。

福田：subnetとかそうですが、ある程度デプロイに関してはL1サポートされているので楽っちゃ楽なのですが、ALBに関してはカスタムリソースをガリガリ書かなければいけないので、正直体験が悪いなとは感じますね。なので総体としては、まだちょっと微妙かなというところはあったりします。もう1段階欲しい感じです。

新居田：なるほど、ありがとうございます。今回の発表がそこの開発体験の向上につながっていくといいという感じですかね。

福田：そうですね。