Cognitoと他の認証を協調させるような作り方はできるか
清水崇之氏（以下、清水）：視聴者のみなさんから1つ質問がきています。「Cognitoと他の認証を協調させるような作り方はできますか」という質問について、いかがですか？
福井厚氏（以下、福井）：はい。これもCognitoがフェデレーションの機能を持っています。例えばFacebookやGoogle ID、あとはSAM認証をサポートしているような他のIdPと連携させて認証することができるようになっています。そういう複合というか、組み合わせで認証させることも可能です。
清水：ありがとうございます。
中村航也氏（以下、中村）：Deletion Policyの話に関係しますが、Cognitoのユーザー情報、DynamoDBに退避させておいて、いざという時に復旧できるようなアプローチがあるとしたら、そのDynamoDBはCognitoのスタックを分離しておくか、もしくはCognitoのスタック内でDeletion Policyで中が削除されないように管理しておくかで言うと、スタックを分けるアプローチが望ましいということですか？
下川賢介氏（以下、下川）：そうですね。スタックを分けるか、実はDynamoDB自体にもS3にバックアップする機能があるので、最終的にはS3に置いておく。S3のほうはすごく堅牢性の高いサービスになっているので、そちらに置いておいて、そこから復元していくことも考えられると思います。
本当に失われてはいけないリソースであればS3で管理しておく。S3自体は堅牢性の高いサービスですが、リージョナル障害にも耐えたいという時にはS3のリージョン間のレプリケーションを使う。例えば東京と大阪をレプリケーションしておいて、他のリージョンにデータを逃がしておくとか。サービスの（中の）どこまでデータを残しておきたいかという要求によって、先の先まで計画することもできるのかなと思います。
清水：ちょっと違うかもしれませんが、バルクヘッドみたいな考え方なのかなと思いますね。やはり大事な部分、サービスをどこまできちんと動かすかというところで、影響を与えたくないのであれば、やはりスタックごとに分けておくというのが1つのプラクティスである気はします。
AWSで認証・認可をすべてGUIで設計・設定できるようなサービスはあるか
清水：もう1つ質問が来ているので読み上げますね。「AWSで認証・認可をすべてGUIで設計・設定できるようなサービスはありますか」。認証・認可をすべてGUIで操作できればいい、設計・設定できればいいという意味かな。
下川：「マネジメントコンソールからすべて設定できますか」という解釈でいいですかね？
清水：それでいいと思います。
下川：CognitoもAPI Gatewayというサービスも、マネジメントコンソールからポチポチとクリックしたりドラッグしたりすることによって設定できます。ただ、2つくらい前の質問にあったとおり、画面を操作する手続きは再現性がなかったり、Excelで手順書を起こさないと同じような環境が作れなかったりするので、できるだけInfrastructure as codeでテンプレートを使ったりするほうがいいんじゃないのかなとは思いますね。
福井：そうですね。
CognitoオーソライザーはFargateと組み合わせた認証・認可は可能か
青山稜河氏（以下、青山）：先ほどのCognitoは、Fargateと一緒に組み合わせて認証・認可みたいなものはできるんですか？
下川：そうですね。先ほどの図にもあったALBが実はCognitoとかに対応しているので、同じようにCognitoベースの認証ができます。
今（スライドには）ALBが書かれていますが、実はお客さまの中ではECSの前、Fargateの前にALBではなくAPI Gatewayを置くというスタイル、アーキテクチャパターンを取ることもできます。API Gatewayベースでやれば、先ほど説明したアーキテクチャを取ることができるのかなと思います。
青山：ありがとうございます。
Amplifyホスティング機能について
福井：この図を見て思い出しました。先ほど言い忘れたんですが、フロントエンドについてはもちろんコンテナで実行してもらってもかまいませんが、もう1つ、Amplifyホスティングという機能を使ってもらうと、簡単にこういうStatic GenerationしたサイトをS3上でホスティングできます。
そうすることによってより管理の工数を削減したりコストを抑えたりできると思うので、そちらを検討してもらってもよいと思います。
青山：そのAmplifyというのは、処理の流れとしてCloud Frontに行って、そのままS3に行く感じですか？
福井：そうです。自動的にS3のホスティングとCloud Frontを構築してデプロイしてくれます。
青山：便利ですね。
福井：はい。試していただければ。もともとAmplifyというサービス自体は、クライアントのアプリケーションを実装するのに便利なライブラリやフレームワークを用意したサービスでした。
例えばReactやAngular、あるいはモバイルアプリケーションであるiOSやAndroidに対応するようなサービスでしたが、今はどんどん拡張されて、ホスティングとかデータのモデリングとか、そういったところまでできるようになっています。見てもらえると便利な機能がたくさんあります。
青山：ありがとうございます。
環境を分けている場合はどのように振り分けするべきか
青山：もう1つ質問がきています。TECH PLAYではもう1つALBがあるじゃないですか。今、これで新しい環境と古い環境を分けているんですよね。パスベースルーティングで移行の真っ最中。
例えば、/blogというパスは新しい環境、/eventというパスは古い環境、EC2の環境と分けていて、S3でホスティングした場合はどうやって振り分けたらいいのかが気になったんですが、どうでしょう？
福井：WebサイトのURLでパスルーティングしているということでよいですか？
青山：そうです。
福井：なるほど。ロードバランサーで振り分けたい場合、どうすればいいですかね。
青山：ロードバランサーじゃなくてもいいんですけれど、今はそういう構成なので。
福井：一応Cloud Frontの中でも分けることはできるので、新しいものはS3のスタティックホスティングして、それ以外のURLに関してはそのオリジンをEC2にしてもらうかたちは取れるかと思います。
青山：あ、なるほど、わかりました。ありがとうございます。
下川：たぶん視聴者の方、CloudFrontとかS3いう単語が初めて出てきたので（わからない方のために説明します）。CloudFrontは、例えばCDNみたいなコンテンツ・デリバリー・ネットワークという役割を果たしていて、そこでキャッシュをしたりエッジからレスポンスを返したり、レイテンシーに貢献できたりするようなサービスです。
S3は何かと言うとオブジェクトストレージで、ここにファイルや何かリソースを登録しておき、そこをCloudFrontからオリジンとしてさすことによって、そのリソース、例えばCSSとかHTMLという静的リソースをユーザーに返すことができる。こんな組み合わせができるようなサービスになっています。
CloudFormation側からSAMに変換はできるのか
清水：ありがとうございます。そろそろお時間ですが、いかがですか。TECH PLAYのみなさんから最後に何か質問があれば。
青山：最初のデプロイの相談に戻りますが、簡単にデプロイする方法。これをSAMでやる方法ですが、逆に、CloudFormationでSAMがCloudFormationに変換する処理をするじゃないですか。
福井：はい。
青山：逆にCloudFormation側から、そのSAMに変換することもできるんですか。
福井：それはないです。
青山：ないですか。
福井：はい。
青山：CloudFormationで全部完結できるのかなと思ったのが（今の質問をした）理由です。
福井：先ほど言ったように、SAMのテンプレートの中にCloudFormationのテンプレートを含めることができるので、過去にあるそのCloudFormationのテンプレートをペタッとSAMのテンプレートに貼ってもらえればそのまま使えます。
青山：ありがとうございます。そうなんですね。
下川：記述の面だけでなく、例えば私がSAMを好きな理由にローカルテストができる・しやすいことがあります。SAMのCLIの中にLambdaのエミュレータやAPI Gatewayのエミュレータをローカルで立ち上げてテストするという機能がある。CloudFormationにないようなデプロイ前にテストがローカルでできてしまう機能があるので、それらを使いたいケースでは、CloudFormationとは考え方を分けておくのがいいのかなと思います。
福井：はい。
青山：ありがとうございます。ローカルでLambdaを動かしたりするということは初めて知りました。
福井：そうですか。
下川：ぜひ。
福井：試してもらえれば。
青山：ありがとうございます。
下川：あくまでもエミュレータなので、Cloudを模倣して動くというかたちです。すべてがCloudの性能や機能を実現しているわけではない点は注意してください。
青山：はい。ありがとうございます。
