# Architected on AWS@御殿山タワー
日時：11/13(水)～15(金)

へ～となった箇所のみメモ。ほぼ自分用のメモなので整形してないです。。。

## クラウドの利点
1. コストが固定→変動に
2. スケールメリット
3. キャパシティー予測がいらなくなる（必要になったときに調達すればOK）
4. 調達スピードが速くなる
5. 余計な事？仕方なくやってる運用系が不要になる
6. 世界中へのデプロイが容易

## Well-Architectedフレームワーク
AWS Well-Architected Tool
→ 割と最近日本語化されたよ

構築するときに一回だけ、じゃなくてなんらかのタイミングで繰り返しチェックすべき

## リージョン
バックアップとかで明示的にデータの移動をしない限り、データはリージョンから出ない

[cloudping.info](https://www.cloudping.info/)で遅延については確認できる。

## S3
最大サイズは5TBで、5GBを超えるとマルチパートアップロードが必要

バケットポリシーとIAMポリシーは以下のようにイメージするとよい
- バケットポリシーは「バケットが」ユーザに対して許可/拒否
- IAMポリシーは「ユーザが」カギをもってバケットにアクセス

静的ウェブサイトホスティング：一通りファイルを置くとWebページを公開できる。

TransferAccelerarion：エッジロケーションにアップロード→Amazon内のネットワークを経由し目的の場所に保存

ライフサイクルポリシー：保存期間に基づいてオブジェクトの削除/移動が可能

オブジェクトロック：特定のオブジェクトが削除されないようにする。監査のために使用するとよい

## EC2/EBS
[ファミリー名][インスタンス世代].[インスタンスサイズ]

t系は表示スペックをフルで使ってくれるわけではない。（30~40%程度？）
バーストクレジットを消費して表示スペックまで使うことができるようになる。フルで使っていない間にバーストクレジットは勝手に溜まっていく。
→ t系で検証してOKだった場合でも、本番環境に移すとNGみたいなことになる（クレジットを使い切ったら性能不足）ので注意

- ユーザーデータ：起動時に流すコマンドを実行させる
- メタデータ：EC2内で取得できるインスタンスの情報（IPアドレスとかMACアドレスとか）

SavingPlan：RIと同じ割引をEC2だけでなくFargate等でも使えるようにした料金モデル

### ホスト専有系のオプション
- ハードウェア専有インスタンス：実行するホストは分からない
- DedicatedHosts：実行するホストを選択＆特定できる。（BYOLでCPU情報などが必要な場合に選択することがある）

### タグ
少ないより多すぎるほうが良い
例えば？作成者のメールアドレス、Delete YES/NOとか

## EBS
インスタンスストレージは揮発性。停止すると消える。
なぜならインスタンスストレージはインスタンスに物理的に紐づいており、インスタンスは立ち上げるたびに物理的な場所が変わるから。（その代わり、物理的に紐づいているのでIO性能は良い）

EBSはAZをまたいで使用することはできない。使いたかったらスナップショットを取って移動する。

1つのEC2インスタンスに対してEBSは4つまでアタッチ可能。逆に1EBSに対して複数EC2を紐づけることはできない。

## EFS
EFS：Linux用
FSx：Windows用

## RDS
IAMユーザーを使ってDB接続することができる（IAMユーザーと同名のDBユーザーを作成して諸々の準備をする必要はある）

## DynamoDB
プライマリキー：Valueを識別するためのカラム
ソートキー：Valueに加えて、ソート（に付随してフィルタ）するためのカラム

JOINや集計処理はできないので、それらが必要な時は使わない。

## subnet
subnetは指定したAZ内に配置される（AZ内に閉じる）
→ マルチAZにするためには、ちゃんとsubnetを複数作って複数のAZに紐づける

AWSは各サブネットに対して5つのIPを予約している
- 0 ネットワークアドレス
- 1 ルータ
- 2 DNS
- 3 予約(実際は使っていない)
- 255 ブロードキャスト

## ルートテーブル
RouteTableのlocalって？
→ ルーター不要ってこと。
→ でも、subnet切られてるやん？
→ 各サブネット間のルートはすでに出来ているから
→ .1で予約しているルータは？
→ 存在はするが、透過させている。気持ち悪い。。。
→ ちなみに設定は消せないから諦めるしかない。。。

マルチアカウントとマルチVPCが考えられるが、最近はマルチアカウントが主流。
ログインし直さないといけなかったりして面倒だけど、請求が分かれるので楽。上限に引っかかるのを回避する意味でもマルチアカウントのほうが良い。

アカウントが違うと、AZの表記(a,c,d)が同じでも物理的にはAZを指している可能性がある。
AZにはIDがあり(apne1-az4)、これが一致していれば物理的に同じAZにすることができる。

IGWはアドレスは持てない。

## NATゲートウェイ
パブリック-プライベートの変換を行ってくれるやつ。
アウトバウンド方向は通すけど、インバウンド方向は通さない。

ウェブアプリも、ELB経由でトラフィックをさばく設定にすることでプライベートサブネットに入れてもOKになる。というかセキュリティ的にはそっちのほうが良い！

## ElasticNetworkInterface
仮想のNIC。EC2インスタンス間で移動することができる。
EC2間で移動すると、PrivateIP/ElasticIP/MACアドレスが保持される（移動される）

複数枚EC2にアタッチしても、帯域が増えたりすることはないから気を付ける。

## セキュリティグループ
NICに紐づく。複数NICをEC2に紐づけると、それぞれで別のセキュリティグループに紐づけることができる。

## VGW(Virtual Private Gateway)
2つのグローバルIPをもつ。冗長構成にするため（もちろんオンプレ側でも2つ設定が必要）
VGW1つにつき接続先は5つだけ。

## DX(AWS Direct Connect)
DXロケーション：AWSネットワークのエンドポイント。実際にデータセンターまで物理的に引くわけにはいかないので…
実際引くのは大変だから、DXパートナーにお願いすることがほとんど。情報はググれば出る。

## VPCピアリング
推移的な（VPC01->VPC02->VPC03）接続は実現できない…
→ AWS TransitGateway(ハブ的なやつ)を使うことで対処可能

## TransitGateway
TransitGatewayの受け口として、DXも使えるようになった。
ただし、別リージョン間とのハブにすることはできない。この場合はVPCピアリングを使用する。

## エンドポイント
ゲートウェイ型エンドポイント：プライベートアクセスするためのゲートウェイが用意されて、そこにアクセスする。ルーティングが必要。S3とDynamoDBだけ
インターフェイス型エンドポイント：プライベートIPを持ったNICが用意されて、そこにアクセスする。ルーティングは不要。
どっちの型なのか？は「エンドポイント」から確認できる。

専用線で直接S3につなぐことも可能。「S3 パブリック接続」で検索すると情報が出てくる。

## ELB
インスタンス数を増やしてスケールするが、このとき各インスタンスがグローバルIPとプライベートIPをもつ。
このため、ELBを配置するサブネットのアドレスは少なくしすぎない。

ZoneApex：www.example.comのexample.com部分のこと。
Zoneは1DNSが管理している範囲。Apexは頂点。
Zoneの頂点をCNAMEで解決することはできないので、CNAMEではなくエイリアスレコードとして独自ドメインのZoneApexを指定する。

ELBのスケールは少し時間がかかるので、先に申請して増やす（ELBプレウォーム）ことができる。NLBはできない（もともと超高性能）。

ALB:URLの中身まで見て振り先を変えることができる
NLB:グローバルIPを固定化できる。セキュリティグループの設定ができない。

ConnectionDraining：ELB配下のマシンを削除（AutoScaling等）際に、今処理しているマシンを削除しないよう保護する。（保護時間は設定）

## route53
複数リージョンにサービスを用意しておき、同名URLのルーティング先を複数リージョンに設定することができる。
この時、普段どっちに振られるのか？はルーティングポリシーで設定できる（例えばレイテンシ優先とか）

## IAM
ルートユーザーのクレデンシャルは削除するべし

EC2にはポリシーを直接アタッチすることができない。
一旦ロールを作って、ロールをアタッチする必要がある。

ルールが被った場合は原則「Deny」が1つでもあれば拒否と思って大丈夫。
だけど、使っているものによっては優先されるルールが違う場合もあるので注意。

## Cognito
いちいちIAMユーザを作らなくても、自分で作って認可情報を与えてアクセス制御する(?)

## CloudTrail
ほぼすべてのAPIコールを記録して、S3バケットにログを保存する。
全部残るから、実質監査ログとして使える。→ バージョニングやバケットポリシーでS3を強固にすることでさらにセキュアにできる

デフォルトではオフになっているので、必要なら有効化する必要がある。

## AutoScaling
最大数=最小数に設定することで、インスタンスが壊れた時に自動で修復してくれる。（＝Auto healing）

## CloudFormation
先に作ってからテンプレートを作るのもあり。定義書に起こしながら環境を作って、それをテンプレート化するのもあり。
→ 一応、今の環境からエクスポートする方法もあるが、ちょっと使い勝手が悪いので手で作ることをお勧めする。

毎度毎度テンプレートを修正するのは正直大変。テンプレートと本番の差異が発生してくる。。。
あまりにもテンプレートを使って表現するのが難しくなってきたら、そもそもIaCのメリットが享受できてるか？を考えてCloudFormationを離れるのも選択肢としてはあるので頭に入れておくこと。「何のためにIaCをしているんだっけ？」を問うべし。

スタックの更新時、変更セット（何が変わるか？を明らかにする仕組み）

CloudFormationのテンプレートは、アーキテクチャの層(IAM/ネットワーク/共有リソースなど)によって分けると管理が楽になる。

## Systems Manager
オートスケーリンググループなどで増えるとアップデートとかしんどいよね？
→ タグとかでフィルタして、一斉にコマンドを流してくれる。（yum updateしろ！みたいな命令をタグを基準に配布してくれる）

定義ファイル(.ebextension)が膨れ上がってきたら、別のサービスを検討するべし

## CloudFront
コンテンツを失効させる方法
- TTL
- オブジェクト名変更
- オブジェクトの無効化(効率悪いので×)

## Amazon DynamoDB Accelerator(DAX)
DynamoDBより早くなる。
同じレコードに対してのアクセスが著しく集中する場合に恩恵が得られる。

## ECS
利点：コンテナの配置について、AWSが最適化することで効率よく配置できる。

タスクのビジー状態に合わせて、タスク数の調整をしてくれる。
（＋EC2のAutoScalingを組み合わせると、負荷に合わせてどんどんスケールすることが可能）

ALBと連携して、ECS上のどのタスクにトラフィックを流すか？を制御することができる。

## Fargate
コンテナのマネージドサービス：EC2も見えなくなる。(ECSはEC2が見える=管理する必要がある)
↑ SavingPlan RIで買ったインスタンスを、これに割り当てることが可能！！

## Step Functions
ワークフロー的な感じで、ステートを持った動作が可能。
Lambdaの結果が〇〇だったから、次のLambdaの実行はスキップ。などなど