私がテストでミスった部分の知識を共有します。

EC2

キーペアは1つのVPCに5000個まで。
停止中にもEBSの料金が発生する。
ストレージはEC2インスタンスストア(停止すると消える)かEBS
-　スポットインスタンス：余ってるEC2使う。同じ性能で、最大90%off。
-　EC2ImageBuilderはAMIの設定更新の自動化
EC2フリートはオンデマンドインスタンスとスポットインスタンスで構成される
インスタンス間のネットワークのレイテンシを最小限に抑える必要がある場合、クラスタープレイスメントグループにて、単一のAZ内のインスタンスを論理的にグループ化
GPU持ってるやつは高速コンピューティング
AMI
- AMIの共有はアカウント番号を指定するだけで他のアカウントに共有可能
- リージョン内のみで利用可能。別リージョンにコピーして別AMIとしても利用可
1つのリージョンで利用できるElasticIPの上限は5
Directed Hostは別IAMグループとは物理サーバは共有せず、物理的にサーバを占有可
スティッキーセッションは同一ユーザーの同じセッションのアクセスを全て同じEC2インスタンスに送信する
Connection Drainingは登録解除されるが、異常が発生したインスタンスへの新規リクエスト送信を中止する機能

route53

レイテンシベースルーティングはレイテンシの低いリソースへルーティング
位置情報ルーティングは、地理的に近いリソースへルーティング

VPC

1リージョン、最大5VPC
VPCエンドポイントはグローバルIPをもつAWSサービスに対し、VPC内から直接アクセスする為の出口
- ゲートウェイ型エンドポイント
  - サービスの宛先とするトラフィックのルートテーブルの宛先として指定できるゲートウェイ
  - DynamoとS3に適応可
VPCフローログはVPC内の通信の解析
ネットワークACLはVPC/サブネット単位で適応。+ステートレスで、インバウンドだけではアウトバウンドは許可されない
- SG→インスタンス単位
- ACL→VPC単位

AutoScaling

クールダウンのデフォルトは300sec
ウォームアップ条件ステップスケーリングポリシー`によって設定

Aurora

3つのAZに配置、6個レプリケート可能
自動で10GBのセグメントに分割
最大15のリードレプリカ

RDS

フェイルオーバーするとDBインスタンスのCNAMEを自動で切り替えられる
Lambdaを連携させたい時、RDS Proxyを使用
シャーディング可能(DB負荷分散)
AutoScalingはストレージ増加させる

lambda

cloud watch logsのログをLambdaへ連携する場合、cloudwatchLogsのサブスク機能
最大一時実行ボリューム512MB
デフォルトタイムアウト3sec、max実行時間は15min

SQS

メッセージサイズ最大 256kb(拡張clientライブラリ利用で、最大2GBまで)
AutoScalingトリガーを構成する場合はSQSのキューサイズを確認
ロングポーリングですぐにメッセージが受信可能

S3

特定のIPアドレスからのアクセスはIAMロールで設定
AccessAnalyzerで不正アクセス確認
ストレージ分析でいつ適切なデータをストレージクラスに移行するか判断
S3 Intelligent-Tieringで低頻度アクセスのオブジェクトを自動的に低頻度アクセスに移動
Glacier Deep ArcheveはS3のアーカイブ、長期バックアップ
- Glacierより優位な点は
  - 3つ以上のAZにまたがって保存
  - 12時間以内に取り出せる
S3 selectはオブジェクトからデータの一部のみを取り出し可
クロスリージョンレプリケーションは異なるAWSリージョン内のS3バケット間でオブジェクトをコピーする機能
暗号方式
- SSE-S3
- SSE-KMS
- SSE-C
ボールドロック：ボールドロックポリシーでファイル削除とか禁止

cloudfront

Gzip圧縮機能でエッジ側でコンテンツを圧縮して高速配信
コスト算出法
- エッジロケーションの場所
- データ転送量
- リクエスト数

ALB

メリット
- L7、パスルーティング
- 1インスタンスに複数ポートを登録可
- ターゲットグループでのヘルスチェック可
デメリット
- リージョン間無理。
- ログファイル分析するには、S3でELBファイル収集、EMRで解析

cloudwatch

3つのステータス
- OK(正常)
- ALARM(警告)
- INSUFFICIENT_DATA(データ足りていない)
拡張：Ec2にcloudwatchAgentをインストール

EBS

DLM(Data Lifecycle manager)定時バックアップが可
最初、フルバックアップその後増分
プロビジョンドIOPS
- I/O負荷の高いワークロード、特にデータベースワークロードのニーズを満たすように設計
- 複数のEC2アタッチ可能
アクセス頻度低いけど、大事なデータの保存のストレージにはEBSのコールドHDDを選択
同一AZ内にアタッチ可
暗号化
- ボリューム内の保存データ
- ボリューム内のインスタンス間で移動されるデータ
- ボリュームから作成されたスナップショット
- スナップショットから作成された全てのボリューム

DynamoDB

1ミリ単位のレイテンシを要求する時
1アイテム400kBまで
リードレプリカ無い

Elastic Cache

ノード：最小単位
シャード：1~6個のノードで構成
- プライマリノード：データの更新と紹介
- レプリカノード：プライマリをコピー、障害時に使う
クラスター：複数のシャードで構成。マルチAZ複数AZに分散可

EFS

NFSv4プロトコル

Elastic BeanStalk

デプロイ、プロビジョニング、ロードバランシングなどできる
Dockerの仕組みを利用

Trusted Adviser

コスト最適化、パフォーマンス、セキュリティ、耐障害性、サービスの制限

EMR

EC2とS3で構成されたHadoopフレームワーク

appSync

GraphQLの開発を容易にする完全マネージド型SB

単発

Storage Gateway、S3 Glacierは標準で暗号化
AD Connector:IAMとオンプレのADを連携
Amazonマルチアップロード：大量のobjectをいくつかに分けて並列でアップロード、基本100MB以上の場所
インスタンスのトラフィック分散はRoute53じゃなくてELB
API Gatewayの処理性能向上は、スロットリング制限設定とキャッシュを有効化
AWSでは/28が最小のCIDR単位
IPフローティング：ELBやRoute53によるDNS情報の伝搬の際の一定のダウンタイムを防止するため、仮想IPアドレスを使って可用性を高めるサービス
コストの可視化はCost Explorer
PCIまたは HIPAA準拠(クレカ処理)の処理を実行している場合、監査のためには過去365日間のCloud Frontの使用状況を記憶すること
Well-Architectedの5つの柱
- 運用の優勢性
- セキュリティ
- 信頼性
- パフォーマンス効率
- コスト最適化
VPN関連
- AWS間のVPN接続の監視：CloudWatch TunnelStateを利用
- オフィスと社内ネットワークとAWSのVPN接続を必要:AWS managed VPN

その他

VMImport/Export：仮想マシン、イメージをEc2に移行したり
AmazonLex；音声、テキストを使用して対話できる
AmazonPolly：文章をリアルな音声に変換
AmazonSageMaker：機械学習モデルを迅速に構築
AmazonRekognition：画像分析、動画分析
Aws Lake Formation：S3を利用したデータレイク構成
AWS SAM(serverless application model)：サーバーレスアプリケーション。cloud formationと連携
Amazon Simple Workflow：分散アプリケーションコンポーネント間での作業調整を用意するサービス
AWS Global Accelerator：アプリケーションの障害による停止時間と割合と応答性能を改善するネットワークサービス
フェイルオーバー：使用不可能になった時に、自動的に切り替わる
Pop3:ローカルに落とす。IMAP4：リモートの内容を見る
パイロットライト：停止した状態の最小限の構成を別リージョンに用意。