# AWS MTG資料 2021/05/17

大きく分けると以下の議題を確認したい。

- [ ] AWSのフロント設計
- [ ] Route53の設定についてアカウント移行の方法と必要性と難易度
- [ ] URL 正規化したい
- [ ] AWSのバックエンド設計
- [ ] EC2インスタンスのサンプルや例
- [ ] RDSのサンプルや例
- [ ] 認証基盤（Cognito）
- [ ] Cognito緩和申請について

[ネットワーク構成図](https://drive.google.com/file/d/1MCU7sK0tPZfpiEicHAFSr66Ufzslu5ph/view?usp=sharing)

前提：
- 現在システムは３社が関わっていている。アカウントが３つに分かれて管理されている。
- 前回のMTGではインスタンスやサービスが複数アカウントに別れていると懸念があったが、実際には作成したネットワーク構成図のようになっている。

## AWSフロント設計

#### Route53の設定についてアカウント移行の方法と必要性と難易度
- Q1
Route 53が別のアカウントで稼働しており、集約させるための方法のベストプラクティスを知りたい。(3ホスト, 63レコード)
将来的には集約を考えているが、煩雑な作業になるなら今回は見送ろうと思っている。簡単な移行の方法やサービスがあるならば行おうと思っている。移行方法の例などはありますか？

#### Q2
Cloudfront FunctionでのURL正規化の方法の確認。

### 前提
- 前提として、今回構築する暮らしのステーションは (www.happy-bears.com/)の会社コーポレートサイトの配下に(www.happy-bears.com/ec/bears)という形で配置をしたい。
- 既存のサイトの構成はELB配下のEC2にWordpressにて存在している。
- PathはCloudfront（Behavior）で振り分けをしている。
- URL正規化に関してはEC2内のApache（htaccess）にて行っている。

### 確認したいこと。
- 確認のような形になるが、Cloudfront FunctionでURL正規化の定義を設定する。その際にApache（htaccess）の正規化の表現と被らないように定義をすれば（404ページのコンフリクトなど）を解消できるという認識であってますか？
- 具体的には[.htaccess よくあるURL正規化やリダイレクトの書き方 WordPress対応版](https://qiita.com/ejointjp/items/f8e2a6686b3850f836c9)のように（RewriteRuleやRedirect）の正規化表現が被らないように定義すれば新サイトと既存サイトの住み分けができるという方法で大丈夫ですか？

## AWSのバックエンド設計

### EC2のタイプの選択
- Q3
以下のようなアクセス情報を今回のサイトにも適用してEC2のインスタンスタイプの選択をしようと思います。
具体的には繁忙期の２倍程を見越したインスタンスタイプを選択する予定です。
公開している例などがありましたら、比較と参考にしたいと思うので教えていただけますか？
また、ECサイトなのでアクセス数は上下する見込みです。Auto scaling化などを将来的に考えていますが、途中での移行する難点はどのように考えられますか？

ハウスのPV数
デイリーアクセス：2233
繁忙期：3000〜4000
メディア露出：9806
瞬間最大アクセス
2020のMAX：617/min

### RDSの設計について。

- Q4
RDSの設計で、現在Bsysと呼ばれる社内データベースが（db.m5.2xlarge(non multiAZ)）で存在していて、今回のサイトのデータはそこにテーブルを追加することで設計をしようと考えています。
また、既存で動いているRDSを冗長化する方法は何がベストですか？

#### 前提
- バックエンド処理で使用するRDSに懸念を持っている。
- システムが冗長化されていない。（システムのインシデントがあった。）
- RDSの情報量は
Table Rowa: 695312717
Data: 306GB
Free: 40GB
- RDSのインスタンスのリソースは現状CPU専用率20%くらいを使用中

- 負荷分散の方法はリードレプリカを作成して読み込み専用と書き込み専用をする方法を考えてます。それ以外に何が有効例としてありますか？
- リードレプリカの方法と他の方法の例を教えていただきたいです。

## 認証基盤（Cognito）

- Q5 Cognitoの使い方。
- Cognito側で認証が確定するのはどの段階かを詳しく知りたい。
- Cognito APIに問い合わせる方法は？
- Cognitoだけで状態をもつことの制約はあるのか？（サーバでの処理に影響するなど。）
- アクセストークンの使い方。

#### Cognito側で認証が確定するのはどの段階かを詳しく知りたい。

以下のような方法の処理をしていきたいと考えると。
1. フロントエンド(Cognitoの認証)→ Cognito に3つのトークン
2. フロントエンド（認証下のリソースを提供する場合） → バックエンドに「ID トークン（JWT）」送る
3. 公開鍵をCognitoから取ってきて、JWTをデコードしてその中身を検証する。
4. バックエンド → Cognito に電話番号が存在するか聞いて
5. バックエンド → 「Congito パスワード忘れた方の API」を叩いて結果をフロントに返す

まずは、3のところで
具体的には以下の方法で正しくできるのか？
つまり、この後にCognito側に問い合わせて情報を取得してそれをバックエンドで検証する必要性があるのかないのかと考えている。

発行者 (iss) のクレームは、ユーザープールと一致する必要があります。たとえば、ユーザープールはus-east-1リージョンには、次のものがありますiss値:https://cognito-idp.us-east-1.amazonaws.com/<userpoolID>.
[iss値の検証]
(https://github.com/awslabs/aws-support-tools/blob/master/Cognito/decode-verify-jwt/decode-verify-jwt.ts#L93-L101)
何か実装の例を参考にしてどのように検証をしているか比較をしたいです。

#### Cognito APIに問い合わせる方法は？
- Cognitoがリージョンに設置されるのでそこのAPIを叩くのに何か（IAMやクロスアカウントやクレデンシャルの付与をサーバにする必要はあるか？）

[参考](https://github.com/aws/aws-sdk-ruby)
[参考2](https://docs.aws.amazon.com/sdk-for-ruby/v2/api/Aws/CognitoIdentityProvider/Client.html#forgot_password-instance_method)

#### Cognitoだけで状態をもつことの制約はあるのか？（サーバでの処理に影響するなど。）
- [Black Belt Cognitoの資料](https://www.slideshare.net/AmazonWebServicesJapan/20200630-aws-black-belt-online-seminar-amazon-cognito)
- Cognito 固有ユーザ情報
標準属性 (OIDC仕様)を見て
UserStatus Groupsここで状態は持つのか分からない
サーバでセッションの状態を持つのか否か。
- Cognitoだけで状態をもつことの制約はあるのか？（サーバでの処理に影響するなど。）

#### アクセストークンの使い方。
3. バックエンド → Cognito に電話番号が存在するか聞いて
4. バックエンド → 「Congito パスワード忘れた方の API」を叩いて結果をフロントに返す
[主なユーザ操作](https://drive.google.com/file/d/1t_NALC6Vd9Fi8BLOY5xEoyOVxMpvGkHI/view?usp=sharing)
非Admin系での場合Cognitoから上のスライドのFogetpassワードは使える。
- [サーバサイド側でやる操作](https://drive.google.com/file/d/1WYL8TlSb-AkB1XBhXOpnrPE2mS1Ji0SJ/view?usp=sharing)

## 今後の進め方。
ビジネスプランに入っている。
このときに確認とか実例を教えて欲しい場合。
電話で相談できるとあるがこの具体的な方法を聞いておきたい。