用語
オーバーヘッド：間接的なコスト。管理のオーバーヘッドを減らしたい→管理にかかる工数を減らたい
バッファリング：複数のソフトウェア間でデータをやり取りするときに、処理速度や転送速度の差を補ったり、通信の減速や中断に備えて専用の記憶領域に送受信データを一時的に保存しておくこと。buffer:緩衝材。Auto Scalingは発生する需要に応じてリソースを増減するが、必ずしも同期的に処理する必要がない場合は、バッファリングの仕組みを利用して、需要を一時的に蓄積しておき処理する側の必要に応じた間隔で非同期に処理を進めるという方法がある。SQSやKinesisなどがバッファリングの仕組みになる。
エフェメラルポート設定：1024-65535のポート番号範囲でSSHを許可する設定。サブネットのアウトバウンドにエフェメラルポートを設定することで、広範囲なポートからのアウトバウンドを許可できる。
CIDR表記：サブネットマスクを指定。/以降の番号がネットワーク部分のアドレス数を示す。/24→IPアドレス256個分（32ビット-24ビット=8で2の8乗）。/32→IPアドレス1個（単一ホスト）255.255.255.255。クラスアドレッシング法より効率的。
SAML：シングルサインオンを実現する仕組み。AWS IAM Identitiy CenterのSMALフェデレーションでMS ActiveDirectoryの認証情報とIAMの認証情報を連携することができる。
openID Connect: webIDフェデレーション・SAMLフェデレーションとは別の方法にあたる。
マルチキャスト：複数のデバイスに対して同一のデータを一斉送信するネットワーク方法。
IPフローティング：Elastic IPアドレスの自動付替
cron：定期実行システム。EC2にcronを仕込んでスクリプトを定期実行するか、AWSのサービスとして定期実行設定するかが問われる。
GiB：1GBは1000^3、GiB（ギビバイト）は1024^3
ポート番号：SSH = 22, HTTP = 80, HTTPS = 443, Microsoft SQL サーバー = 1433, MySQL = 3306
TCP: ssh, ftp, pop3, httpなど
UDP: echoなど（あまり聞いたことないのばっかり、、）
プロキシ：ネットワークの中間となる。APIゲートウェイをつなげる役割などで出てくる。Lmadaプロキシ、RDSプロキシなどがエンドポイントの代わりとなる。
SMB(server message block) ：Windowsコンピュータの間でファイル共有やプリンタ共有などを行うためのプロトコル。FSx for windowsFileServerが主につかわれる。
NFS（Network File System）：UNIXベースのファイル共有プロトコル。EFS系 or FSx for OpenZFS（FSx fot NetApp ONTAPはSMBもNFSもいける）
ピークロード：最大需要量。スケーリングが必要
ROA (Route Origin Authorization)： IPアドレスの組み合わせに対して、 それが正しい組み合わせであることを示す電子署名が施されたデータ
ingress:インバウンド・egress：アウトバウンド。
スループット：コンピューターやネットワークの一定時間内に処理される情報量、データ転送速度、通信速度など。I/O最適化でよく出る。
レイテンシー (遅延時間)」要求されたリソースが目的地に到達するまでにかかるネットワーク時間。
インスタンスタイプ
インスタンスファミリー：インスタンス世代：インスタンスサイズ
例：t3:xlarge
インスタンスファミリーは記号によって、汎用・メモリ最適化・ストレージ最適化などの分類がある。テストはT系、本番はM系。高速コンピューティングはGPUが搭載されている。コンピューティング最適化はarm系（amazon製でintelより早いらしい）
メモリが大きいと大規模データ処理とかキャッシュ利用した定例天使の実現が可能になる。ストレージ最適化ではI/O性能が高く、DB処理が高速化しスループットがよくなる。
インスタンス世代は大きいほど新しい世代で、高性能かつ安価になる
インスタンスサイズはlarge,xlarge,2xlargeなど、サイズを示す。CPU数はlarge:2, xlarge:4, 2xlarge:8,4xlarge:16
インスタンスタイプ覚え方
ネットワーク
パブリックサブネット - インターネットゲートウェイ
プライベートサブネット - NATゲートウェイ or NATインスタンス（非推奨）NATゲートウェイはパブリックにおき、プライベートのルートにNATゲートウェイを設定する。
セキュリティグループ：ステートフル：インスタンス単位：全て拒否：即時反映：インバウンドは必要最低限・アウトバウンドは全て許可が一般的：インバウンド・アウトバウンドどちらも同じ設定が自動で反映される。
ネットワークACL：ステートレス：サブネット単位：全て許可：新規に作成したACL（カスタムネットワークACL）はすべてのトラフィックを拒否する：インバウンド・アウトバウンドそれぞれの設定が必要。egress falseでインバウンド・trueでアウトバウンド：ボートレンジ1024-65535。ルールは番号順に適用
サブネットマスク/32で特定のIPアドレス１つを設定。0.0.0.0/0はフルオープンIP（パブリック）。インターネットゲートウェイのアウトバウンドルールは、宛先は0.0.0.0のフルオープンがよい。
ELBをパブリックサブネットに置き、バックエンドインスタンスをプレイベートサブネットに配置。
ELB Proxy Protocol：HTTPやHTTPS以外の用途でELBを使う場合にも、接続元のIPアドレスとポート番号が取得できる
踏み台サーバー（Bastion）によるアクセス制御
SSH（Linuxサーバー）またはRDP（remote desktop protocol: windowsサーバー）で踏み台サーバーにリモートアクセス
踏み台サーバーはパブリックサブネット。セキュリティグループにSSHやRDPアクセスの許可ルールを設定。特定のIPやサブネットを指定するとよりセキュア
踏み台サーバー経由でEC2にアクセス。セキュリティグループに踏み台サーバーからのSSHやRDPのみ許可を設定するとセキュア
暗号化
SSL/TSLに対応しているのはELB・RDS・CloudFront・API Gateway
AWS Certificate Managerで証明書の購入や登録・更新、期限切れの通知が管理できる。
データの暗号化は、クライアントサイドでやるかサーバーサイドでやるか
自動での暗号化はstorage gatewayとs3が対応
S3に暗号化してアップするか、バケットのデフォルト暗号化オプションを設定するか。この際、S3バケットに保存されるログも暗号化される。
EBSをサーバーサイドで暗号化する場合、RDSと同じようにスナップショットを作成して暗号化を行う
KMSはSDK・CLIで利用するか、S3・EBS・RDS・RedshiftなどのストレージDBサービスと紐づけられる。サーバーサイド暗号化（SSE）もクライアントサイド暗号化（CSE）も可能。自動ローテーション機能あり
KMSキーポリシー：アカウントを登録して、そのアカウントが特定のKMSキーに対してアクセスや操作を行う権限を付与する
AWS CloudHSMは、より厳しいコンプライアンス要件で使える。HSMを占有するユーザーだけアプライアンスに保存される鍵を管理できる。HSMはほかのネットワークから隔離され、国際的なセキュリティ基準に準拠している。RedshiftかRDS for Oracleで使える。
AWS Secrets Managerは認証情報を管理するサービス。APIでアクセスして認証情報を取得する。自動で更新とかもできる。
SSE-S3は監査証跡が取れないが課金なし。SSE-KMSはcloudtraIlにより証跡が取れる。
AWS暗号化SDK：暗号化専用ライブラリ。KMSのリクエスト負荷対策で使える。
監視
AWS CloudTrailはヒトの操作を追跡。AWS Configはモノ（EC2インスタンスなど）の構成変更履歴に特化している。AWS Configでrestricted-ssh：セキュリティグループのSSHトラフィックのIPアドレスを制御できる
ユーザー側でAWSサービスに脆弱性スキャンや侵入テストを行う際は事前申請が必要かつ許可されているサービスは限られている
冗長性
Direct Connectは占有型（物理制御可能）と共有型がある。
オンプレとAWSとのネットワークの冗長性について
DirectConnectで東京・大阪２回線を用意する or DIrectConnectとSite to Site VPNを併用する（DirectConnectのフェイルオーバーにVPNを使う）
通信の質か費用（運用コスト）をとるかで対応が変わる。
インターネットゲートウェイはVPCに設定するため冗長性がある。
NATゲートウェイはサブネットに設定し、異なるAZ間の冗長性はないためユーザーが管理をする必要がある。
DRサイトの構築には、VPCを異なるリージョンに展開できるVPCピアリングを行う。フェイルオーバー時はRoute53で切り替えを行う。
EC2はAuto ScalingとELB、RDSはマルチAZ配置で。lamda, api gateway, dynamoDBはサーバーレスであり、冗長性がある仕組みになっている。
EBSはスナップショット。EFSはスナップショットはないのでAWS Backup。FSxならS3へバックアップ。S3は99.99%の可用性
EC2のバックアップさきにEBSの代わりにEFSを使うことも可能。割高になるが、EBSは一つのEC2インスタンスにしか適用できないところEFSなら複数適用可能。FSxも使用できるがEFSとはプロトコルが異なる。ちなみにEBSのプロビジョンドIOPSなら一応複数接続可能らしい。
AMIはEC2情報とスナップショットでてきている。EC2のリストアはAMIから行うのが一般的.
マルチAZ DB ClusterではマルチAZより迅速なフェイルオーバー切り替え処理ができる。Reader/Writerインスタンスの切り替え。
RDS＝マルチAZ配置（オプション）、DynamoDB=３ヶ所のAZ
RDSのAZ配置とリードレプリカの違い→AZ配置は高可用性：冗長化のためのもの。リードレプリカは拡張性：トラフィックのパフォーマンス向上。可用性も補うことができると公式は言っている。
DR対策のレベル。上ほどコストが高く、切替時間が短い。
マルチサイトアクティブ/アクティブ：ホットスタンバイ。一瞬で切り替えられる
ウォームスタンバイ：再稼働に数分。インスタンスは低容量で実行される。
パイロットライト戦略：ウォームスタンバイとコールドスタンバイの中間。インスタンスは停止される。再稼働に数１０分
バックアップ&リストア：再稼働に数時間
コスト
AWSサービスの中には1年〜3年などの一定期間利用を予約することを前提に割引価格で購入可能になるオプションがある。
EC2リザーブドインスタンス・RDSリザーブドインスタンス・ElastiCacheリザーブドキャッシュノード・DynamoDBリザーブドキャパシティ・Redshiftリザーブドノード
他ノウハウ
開発と本番環境分けるのはタグを使おう
EC2
EC2インスタンスへのログインはキーペア、またはAWS System Manager のSession ManagerでIAMポリシーを使用してCLIから行うことができる
「EC2を別リージョンに複製する方法」 EC2インスタンスのAMIをコピーし複製先に別リージョンを指定→複製されたAMIからEC2インスタンスを起動
EC2の状態はpending,running,stopping,stopped,shutting-down,terminatedがあり、課金対象はrunningのみ
ユーザーデータ：EC2の初回起動時一回だけスクリプトを実行できる機能。起動時にS3からデータをひっぱってくるなど。
インスタンスメタデータ：インスタンスID/プレイベートIPv4アドレス/パブリックIPv4アドレス/ローカルホスト名/公開鍵の情報がある。
プレイスメントグループ：ラックの配置方法。通常よりもEC2インスタンス間の通信が高速化。
クラスタープレイスメントグループ：全て同じラックに格納。
パーティションプレイスメントグループ：パーティション単位のラックで分かれている。一つのラックで障害がおきても他のハードは動作継続できる。分散処理環境としても使える。Hadoopなどの大規模分散ワークロード処理など
スプレッドプレイスメントグループ：EC2インスタンスがそれぞれ個別のネットワークと電源を備えたラックに配置。障害の影響を低減したい時。
リザーブドインスタンス：StandardタイプとConvertibleタイプ（設定を変更可能だけど割高）
オンディマンドキャパシティー予約：起動が必要なEC2を予約できる
スポットインスタンス：スポットブロックは最大６時間まで動作を保証する。スポットフリートは性能キャパシティを満たすようにインスタンス構成をする。
ENI(elastic network interface)：EC2の利用しているIPアドレスやVPN情報が書かれたもので、EC2インスタンスにアタッチされている。デタッチして別インスタンスに付けることも可能。以下のアタッチ方法がある■実行中のアタッチ（ホットアタッチ）■停止中のアタッチ（ウォームアタッチ）■インスタンスが起動中のアタッチ（コールドアタッチ）。
VPCフローログはENIのトラフィックをCloudWatchLogsへキャプチャしている。
Instance Savings PlansはEC2インスタンス間のみ適用。Compute Savings PlanはEC2以外でもlamdaやfargateに適用される。
オンデマンドインスタンスの起動上限がvCPU数ベースの管理になった。インスタンスタイプごとにvCPUが異なっている。
インスタンスメタデータを取得する唯一の方法は、リンクローカルアドレス (169.254.169.254) を使用すること
EBS
EC2とEBS最適化をすることで、通信専用帯域を確保できる。EC2とEBS専用のトラフィックなので、他のEC2のトラフィックに邪魔されない。
EBSはアタッチされたEC2経由でアクセスできる。個別でアクセスするものではない（アクセス制限とかもEC2と同一）
構築するインスタンスタイプによってサポート体制が異なるため注意。
パフォーマンスを上げるにはインスタンスの性能を上げる
汎用SSD(gp2,gp3)、PIOPS SSD（io1,io2）、スループット最適化HDD、コールドHDD、マグネティック
io2BlockExpressが一番IO性能がいい。2.5万IOPS,4000MB/s through put
EBS IOPSの性能の見方：IOPS性能とボリュームサイズ(GiB)は最大50:1。例えば100GiBのボリュームだとプロビジョニング値の最大は5000IOPS。
RAID0構成：パフォーマンス向上。複数のディスクを１台のディスクのように扱う。ストライピング
RAID1構成：冗長性の向上。ミラーリング。
DR対策を安価に済ますならスナップショットを別リージョンにコピーするとよい
EBS delete on termination：デフォだとEC2消したらEBSも一緒に消えるが、これを設定すれば手動で消えるようになる。
Amazon DLM（Data Lifecycle Manager）: EBSのスナップショットライフサイクルポリシーを設定できる
IOPS表
プロビジョンド IOPS SSD：最大 64,000 IOPS
汎用 SSD EBS ボリューム：最大16,000 IOPS
スループット最適化 HDD EBS ボリューム：最大500 IOPS
AutoScaling
EC2 auto scaling・Application auto scaling・aws auto scalingの３つがある。
EC2インスタンス・ECS・DynamoDB・Aurora などが対象
起動設定：AMI・インスタンスタイプ・セキュリティグループ・キーペアなど
Auto Scalingグループ：インスタンス数の最小・最大など、範囲の指定
desired capacityで要望を指定可能
Auto scalingはCPU利用率と連動できる。not メモリ利用率
EC2 auto scalingはデフォルトのクールダウン期間が300秒
ヘルスチェックはEC2とELBとの2タイプある
スケーリングプラン：シンプル（簡易）・ステップ・ターゲット・予測
簡易スケーリングポリシーは一つの閾値で1段階のスケーリング。今はステップスケーリングポリシーで段階的なスケーリングができるのでこっちをよく使う。
ステップスケーリングポリシー：段階的に増やしていく。
ターゲットトラッキングポリシー：CPU平均使用率や平均ネットワーク入力などのしきい値と一緒にスケールできる。ステップスケーリングポリシーより設定が簡単。一定の値にキープしようとスケーリングする。
予測スケーリング：過去のCloudWatchのデータから予測してスケーリングする。
Auto scalingウォームプール：EC2休止状態でメモリを保持できる。起動時間の短縮につながる。
ELB
ALB・NLBに別れる（CLBは昔のclassic）
GLB(レイヤー3：Gateway Load Balancer)もある。ファイアーウォールや侵入検知など
アプリケーション層かネットワーク層か
複数のAZ分散。VPCやリージョンを跨ぐことはできない
AWS Certificate Managerで発行したSSL証明書をリスナー設定にHTTPSの設定できる
NLBのAWS Global Accelerator：標準アクセラレーターのエンドポイントを設定
カスタムルーティングアクセラレーターは同じセッション間でのやり取りが必要な場合。ボイスオーバーIPとかでなければ標準アクセラレーターでオーケー
登録解除プロセス（connection draining）：ターゲットがターゲットグループから削除される際に、処理中のリクエストを完了させるための待機時間を提供する。デフォルトだと登録解除プロセスが完了するまで 300 秒待機して、ターゲットへ処理中のリクエストを完了しやすくしている。インスタンスの実行時間が長い場合は、この待機時間を最大時間分遅延させる。
Internet-facingの有無でパブリックかプライベート選べる。
Lamda
課金は使用するリソースと実行時間。処理が長いのは不向き。
関数ごとに環境変数設定可能。でも環境変数に認証情報を設定するのはセキュリティ的によろしくない。
AWS Secrets ManagerやAWS Ststem Manager Parameter Storeと組み合わせて設定するのがよい。
ExecutionRole： LamdaにアタッチされたIAMロール
Lamda Edge：エッジロケーションでLamdaプログラムを実行する。ユーザーの地域ごとにコンテンツを変えるなどができる。
lamda関数はコンテナ起動後に実行されるためレイテンシーが発生する。起動したらしばらく保たれるが一定時間後にコンテナは停止する。
Lamda関数URL：APIゲートウェイ的なことができる
Lamdaレイヤー：重複する処理を共通化させることができる
「プロビジョニングされた同時実行の設定」をすると設定した数だけコンテナがウォームスタンバイ状態になるので、低レイテンシーを実現できる。使用料金はかかる。
SnapStartという最近の機能もある。
最大10GBのデータ容量。稼働はMAX15分まで
lamda オーソライザー（旧カスタムオーソライザー）：OAuth, SAML、カスタム認証スキームなど。CognitoユーザープールとAPIゲートウェイの紐づけ
APIゲートウェイ
APIエンドポイントタイプは３つ
リージョンAPIエンドポイント：同一リージョン内クライアント
エッジ最適化APIエンドポイント：地理的に分散されたクライアント
プレイベートAPIエンドポイント：VPC内のクライアント
スロットリング制限：高負荷対応。制限を超えたリクエストは429(Too Many Request)を返す。
キャッシュの有効化も効果的
プロキシ統合によってlamdaを呼び出すことができる（lamda関数URLは似たような挙動になるが、これはAPIコールとは異なる）
S3
S3 Standard-IA(Infrequently Access)：低頻度のデータ。取り出しはStandardと変化なしのミリ秒単位。
S3 One Zone-IA：1AZのみ、Standard-IAより重用度の低いデータ。
Galcier Flexible Retrieval：取り出し時間3-5時間。迅速取り出しだと1~5分。
Galcier Instant Retrieval：Standardと差異なしの秒単位のデータ出力
Glacier Deep Archive: 取り出し12時間、大容量24時間
S3 Intelligent-Tiering：データのアクセスパターンを解析し、自動ティアリング。予測がつかない時使える。
強い整合性モデルを持っているため、反映についてのラグは生じない（昔は結果整合性モデルだった）
オブジェクトロック：一定期間or無期限。ガバナンスモードはアクセス権限のないユーザーの操作を制限。ストリクトモードは一律で全員の操作を制限する
Glacierボールトロック：S3におけるオブジェクトロック的なモノ
バージョニング：バージョン管理。MFA Deleteも有効化できる
クロスリージョンレプリケーション：通常は同一リージョン３ヶ所のAZ
アクセス制御：IAMポリシー・バケットポリシー・ACL・ブロックアクセスブロック（外部からはアクセスできなくする）
暗号化：S3デフォルトキー（AWS管理）・KMSのキー（AWS管理）・ユーザー任意のキー（ユーザー管理）
マルチパートアップロード：大容量オブジェクトのパート分割
S3Transfer Acceleration：データ転送・エッジロケーション
webサイトホスティング：Route53のDNSフェイルオーバーと組み合わせてsorryページの作成によく使われる
署名付きURL：一定時間だけアクセス可能にして、AWSログインなしでもアクセス可能にする。時間は自由に決めれる
リクエスタ支払い機能：コストをリクエストした側に支払わせることができる。
ストレージクラス分析：最適なライフサイクルポリシーの設定を提案
S3 Access Analyzer: S3へのアクセスを解析。不審なアクセスを検知
S3 Global Accelerator: アクセスの高速化。アップロードは高速化されない
マルチパートアップロード：ファイルを分割してアップロード。失敗するとパートデータは残る
S3 select: シンプルなSQL文でフィルタリングできる
S3イベント通知：特定のイベントで通知ができる。SNS/SQS/Lamda/EventBridgeに通知
s3-website ダッシュ (-) リージョン or s3-website ドット (.) リージョン：http://bucket-name.s3-website(-|.)Region.amazonaws.com
EFS・FSx
EFS: 汎用モード・最大I/Oモード・バーストスループットモード・プロビジョンドスループットモードがある。
一番レイテンシーが低いのは汎用モード
バーストスループットモードはスケーリングする。
最大IOは大量読み書き用。
EFS IA（低頻度アクセス）はライフサイクルポリシーで移動可能
EFSはNFS（UNIX・Linux）・AmazonFSxはSMB系（windows）と認識しておけばOK
AmazonFSx for Windows File Server：SMBプロトコル。Active Directoryとの連携可能
FSx for Lustre：機械学習・HPCのlinux。スクラッチファイルシステム（短期間の処理でパフォーマンスがいい）と永続化ファイルシステム（永続的で可用性があるがパフォーマンスが悪い）
RDS
OLTP(Online Transactional Processing)
1日1回自動バックアップ
最大35日分保存
スナップショットからDBインスタンス復元
or ポイントインタイムリカバリ：パックアップとログが残っている範囲内の特定の日付時点でデータを復元
DBのトランザクションログはS3に5分ごとに保存
マルチAZ・マルチAZ DBクラスター
レプリカをプライマリインスタンスに昇格させてフェイルオーバー
昇格させる優先度をきめられる。同じ場合はインスタンスサイズが最大のレプリカが昇格する。
リードレプリカは異なるAZ・リージョンで構築可能→読み取り要求と書き込み要求の処理を分断し、パフォーマンスと耐久性が上がる。
クロスリージョンリードレプリカ：MariaDB・MySQL・Oracle DB・PostgreSQLの４つのみ。PostgreSQL以外はフェイルオーバーで自動昇格。バックアップをリージョン間転送するという手もある。
RDSの暗号化はDBインスタンス作成時のみ設定可能。DB作成後に暗号化する場合、スナップショット取得→スナップショットのコピーを暗号化設定→そのスナップショットからDBインスタンスを起動。
SSL接続可能
RDS proxy：DBのオーバーヘッドを減らす。DBへのアクセス開閉や保持をアプリケーションに代わって実行する。エンドポイントの代わりとしてLamdaとつなげるとよい。RDSエンドポイントとLamdaを繋げるのは非推奨：Lamdaが複数同時実行されてしまうため。
RDSイベント通知一応あるけど、S3みたいにDB操作をイベントとして操作できるわけではない。SNSとの連携のみ。Lamdaからスケジュール実行でRDSを読み取らせるとかが現実的
RDSのデータのシャーディング：複数のテーブルにデータを分割することによってアクセスを分散させること。
RDSのストレージはAuto Scalingできる
RDS for MySQL：デフォルトのストレージエンジンはInnoDBとなっており、そしてMyISAMの利用は非推奨（AuroraだとMyISAMつかえない）
Aurora
MySQLならAurora for MySQLをつかうべし。RDS for MySQLより全然性能がいい
SQL処理を行うDBインスタンスと、データを格納するストレージであるクラスターボリュームに分かれている
Auroraは3ヶ所のAZ。プライマリーDB1ヶ所（読み書き）、Auroraレプリカ２ヶ所（読み取り）
１つのAZにつき２ヶ所のディスクに書き込まれるので合計6箇所に保存される。これで障害発生時にダウンタイムが発生しない
Auroraマルチマスタークラスターは、2つのAuroraレプリカがなく、３ヶ所すべて読み書き可能にする。フェイルオーバーがないが、競合が起きる可能性がある。書き込みは特定のエンドポイントに対して行うのが推奨。カスタムエンドポイントを使用してDBをグループ化し、そこに対して読み取るようにすることもできる。
Amazon Aurora Global DB：複数リージョン。１リージョンにプライマリDBクラスター（データの書き込み）、他最大５つのセカンダリDBクラスター（プライマリのレプリケート、読み取りのみ）。
Aurora Serverless：必要な時だけ起動するDB。通常はボリュームインスタンスが起動していない。SQLのリクエストを受け取り起動する。利用頻度が高くないアプリケーション向け。
リーダーエンドポイント：クエリなどの読み取り処理専用のエンドポイント
DynamoDB
セッション管理やメタデータ保存に最適低レイテンシー読み取り・書き込み
３ヶ所のAZに保存
結果整合性モデル：書き込んだデータは時間が経てば正しく反映される。タイミングによっては反映されてない。
RDBMSはトランザクジション処理：複数アクションをまとめてオールオアナッシング。一貫性を保証する。
DynamoDBはデータは３ヶ所に分散・保存するが、時間差がある。その分処理が高速。
「強力な整合性」も提供しているが、応答速度が遅くなり、ネットワークが遅延するとDynamoDBにアクセスできなくなったりする。
データ書き込みの成功判断は、３つのうち２つに正常に書き込みが完了した時。なので、完了してないAZでは最新のデータが反映されていない。
キャパシティモード：課金をオンデマンドか、プロビジョニング済みで分けれる。事前に読み書きの回数とAuto Scalingの予想ができているかどうか次第。
オンデマンドバックアップ or ポイントインタイムリカバリ
別アカウントまたはリージョンにコピーしたい時はAWS Backupを使う
グローバルテーブルは可用性を高められるかつパフォーマンスも向上する。テーブル作成時に選択できる。すべてがプライマリテーブルなので、どのリージョンで変更してもすべてのデータとの同期を行う。
DynamoDB Accelerator（DAX）はdynamoDB用インメモリキャッシュ。キャッシュでより高速になる。ハイパフォーマンスだが高コスト。一時的な負荷対応ならAuto Scalingのほうがコストパフォーマンスは良い
DynamoDB Auto Scalingで急増する負荷にの増減に対応
DynamoDBストリームデータ：dynamoDBのデータが更新される際、保存、履歴、lamdaとの連携が可能になる処理
プロビジョニングモード：１秒中の読み込み回数と書き込み回数を指定することでコスト最適化
TTL属性(time to live)日数を指定して、それ以降はデータを削除するといった設定ができる。
Red Shift
OLAP(Online Analytical Processing)
RDBはどれも行指向のDB。データ量が増えるほどレスポンスは悪くなる。RedShiftは列指向。対象の列の全てを集計するような処理に優れており、ゆえにビッグデータを扱いやすかったり分析がしやすかったりする。
ノードの集まりで構成。コンピューターノードがそれぞれ処理をしてリーダーノードが処理を受け付ける。ノードの集まりは「クラスター」
スナップショットは８時間ごと or ノードあたり5GBのデータ変更があったときに自動で撮る。保存期間過ぎると消えるので、永続的なバックアップは手動で。
クロスリージョンスナップショット
RedShiftはPostgreに準拠している。Red Shiftは高速で便利にしたポスグレ的なポジション。
クロスアカウントデータ共有で、別のAWSアカウントにデータ共有できる。プロデューサーとコンシューマに分かれる。
Redshift Spectrumはデータの一部をS3に保存することができる。Glueを通してSQLデータ取得をするなど可能。高頻度にアクセスするものはRedshift,低頻度なものはS3に、などの融通が効く。
Redshift Concurrency Scalingを有効にすれば負荷が増しても事前に設定した範囲で自動でスケーリングする。
拡張VPCルーティングでVPCにトラフィックを強制しつつモニタリングが可能
Red Shift work load manager(WLM)：red shiftのキュー処理
最近マルチAZできるようになった。