SAA対策の自分用のメモ。
7/13にSAA合格
SOA対策の自分用のメモ。
どんどん更新して加筆修正していく予定。
インスタンスストア（エフェメラルディスク）
☆ホストコンピュータに物理的にくっついている。インスタンスを再起動すると、別のホストコンピュータでインスタンスが起動されてしまい、データは消えてしまう。
EBS
ブロックストレージ
確保した容量分課金（使っていなくても）
スナップショット機能（S3に保存）
☆EC2インスタンスとは独立しているため、再起動してもデータは残る
複数のEC2インスタンスにアタッチすることはできない
プロビジョンドIOPSはMulti-Attach を有効にすると、複数のEC2インスタンスにアタッチ可能
☆同AZ内のEC2インスタンスのみにアタッチ可能。ただし、スナップショットを取得し、任意のAZでボリュームを復元し、EC2インスタンスにアタッチすれば、別のAZでもアタッチ可能。
-
汎用SSD
中小規模のDBなどで使用 -
プロビジョンドIOPS SSD
ハイパフォーマンス、汎用SSDではできないミッションクリティカルな低レイテンシー高スループット向け
高スループットなアプリや大規模DB（RDSやNoSQL）で使用 -
スループット最適化HDD
高スループット低コスト、ビッグデータやデータウェアハウス、ログ処理向け
最大500MB/秒 -
コールドHDD
アクセス頻度の低い大量のデータ用
EBS最適化オプション（デフォルトは無効）
より大きなIOPSが必要なときに設定。EC2インスタンスとEBS間の専用帯域を設ける。
有効になっているインスタンスをEBS最適化インスタンスという。
ポイントインタイムスナップショット
スナップショットによるバックアップは増分のみ
EBSボリュームを別リージョンでも使いたい時は、スナップショットを作成し、別リージョンで復元、そのEBSボリュームを新しいEC2にアタッチする
☆暗号化
新規に作成するときに暗号化のオプションを選択できる
また、既存のEBSボリュームを暗号化したい場合には、一度スナップショットを取得し、それを復元する際に暗号化する事ができる。暗号化されたボリュームからのスナップショットは暗号化されている。
Data Lifecycle Manager(DLM)
EBSボリュームのスナップショットの作成・保持・削除を自動化できる
S3
インターネット経由のオブジェクトストレージサービス
容量無制限で高耐障害性、高可用性のリージョンサービス
固有のID（オブジェクトキー）を付与し、これでアクセスする。オブジェクトキーは全体で一意である必要あり
バケットでオブジェクトを保存
※大量のリクエストがあるサービスには不向き
☆VPCエンドポイント
インターネットを経由せずにVPC内部からアクセス可能。インターネットアクセスを排除。
☆署名付きURL
有効期限つき署名付きURLを発行できる。これにより、サーバーを経由することで生じるような通信トラフィックを気にしなくて済む。
3ヶ所のAZに自動複製して高可用性
☆結果整合性モデル
データを更新後、タイミングによっては古いデータが読み込まれる事がある。しかし、一貫性は担保されているので、ちゃんと時間が経つと、全てのデータは更新される
☆種類
-
スタンダード（デフォルト）
-
標準ー低頻度アクセス（Infrequent-Access）
アクセス頻度は低いが、必要になったらすぐに取り出せる必要があるデータに使う -
１ゾーン低頻度アクセス
１つのAZにのみ保存のため、可用性は下がるが、コストを約２０%カットできる。
オンプレや複製が容易なデータのセカンダリバックアップとして使われる。 -
Intelligent-Tiering
自動的にコスト効率のより良いストレージクラスに移動させる。
未知のアクセスパターンのデータやアクセスパターンが変化するデータに使われる。 -
Reduced redundancy storage？
２つのAZにのみ保存のため、可用性は下がる。 -
Glacier
アーカイブ用。データの取り出しには手続きが必要。テープアーカイブとか。
Vault Lockを設定することで、データを保存後に編集できなくできる。
取り出しについて
-
Expedited 1~5分でデータを取り出し可能。高価
-
Standard 3~5時間でデータを取り出し可能
-
Bulk 5~12時間でデータを取り出し可能
-
Glacier Deep Archive
年１回取り出すとか- Standard 12時間以内にデータを取り出し可能
- Bulk 48時間以内にデータを取り出し可能
バージョニング
オブジェクトの世代管理。バージョンIDを付与。MFA Deleteを有効にすると、誤った削除などを防げる
ライフサイクルポリシー
自動で削除や別ストレージへのアーカイブ処理を設定できる
☆静的ウェブホスティング
静的コンテンツであれば、 S3をwebサーバーのように使用できる。ただし、パブリック読み取権限が必要で、HTTPSには対応していない。
クロスリージョンレプリケーション
↓↓S3リクエストレートのパフォーマンス向上によりもう不必要。
S3のパフォーマンス改善に、ファイル名のプレフィックスにランダムの16進数の文字列をつける。インデックス格納先が分散されてハイパフォーマンスになる
Cross-Origin Resource Sharing(CORS)
別ドメインにあるS3リソースとの通信が可能(Ajax)。本来なら、CSS攻撃など対策のためにできない仕様になっている。
パブリックアクセスの項目でアクセス制御が可能
☆結果整合性モデル
同じキーを持つ既存オブジェクトを上書きすることによって、レコードを更新しているため、更新前に読み込むと古いデータが表示されることがある。
☆暗号化（3つのサーバーサイド暗号化）
- S3管理のキーによるもの
- KMS管理のキーによるもの
- ユーザーのキーによるもの
S3で誤って削除しない対策
- MFA削除の有効化
- バージョニングの有効化
- バケットのアクセスを特定のIAMロールに制限
☆S3 Transfer Acceleration
S3に直接アップロードする代わりに、CloudFrontのエッジロケーションを経由してからS3にアップロードする。これにより、別リージョンへのファイルの転送が高速にできる。
S3 Select
シンプルなSQLステートメントを使用してS3オブジェクトのコンテンツをフィルタリング、必要なデータのサブセットのみを取得できる。 転送するデータ量を削減し、このデータを取得するためのコストと待ち時間を削減できます。
Storage Gateway
オンプレとAWSストレージをつなぐ。オンプレの拡張としてクラウドストレージを用いることが多い。
-
ファイルゲートウェイ
NFSインターフェイスを利用し、データを直接S3にオブジェクトとして保存。
SMBプロトコル -
テープゲートウェイ
物理のテープストレージの代替。Glacier -
保管型ボリュームゲートウェイ
オンプレのデータのスナップショットをS3へ。データはオンプレにある（オンプレがプライマリーストレージ）。 -
キャッシュ型ボリュームゲートウェイ
S3にスナップショットを保管し、よく使われるデータのみをキャッシュとしてオンプレに保存。（S3がプライマリーストレージ）
EFS
共有ファイルシステム
複数AZの複数EC2インスタンスからアクセス可能
ビッグデータやコンテンツの共有リポジトリに使う
オートスケール可
暗号化
オンプレのプロプライエタリ（クローズド）なファイルシステムを利用しているレガシーアプリをAWSに移行するなら向いている。
SMBプロトコル、Windows NFTS、Microsoft Active Directoryへの統合をサポート。
☆FSx
☆FSx For Windows
フルマネージドのWindowsファイルシステム。
WindowsシステムのAWSへの移行を容易にする
ファイルシステム当たり最大 2 GB/秒のスループット、数百万の IOPS、一貫したミリ秒未満のレイテンシーで高速。
FSx For Lustre
高パフォーマンス
RDS
ACID特性（Atomicity, Consistency, Isolation, Durability）
トランザクション処理において、即時の一貫したデータの整合性を担保し、処理中の失敗はロールバックが可能。
リードレプリカ（スケーラビリティ）
書き込み用ワークロードはプライマリDBインスタンスにアクセス、読み取り用ワークロードはリードレプリカにアクセスさせることで、大量のトラフィックの読み込みに対するスループットを向上できる。最大５台まで（Auroraは15台）
RDS作成時に暗号化のオプションを有効化することで、RDSインスタンスやスナップショットを暗号化できる。
RDSはトランザクション処理が必要なアプリケーション用
Multi-AZ配置（高可用性）
プライマリDBインスタンスと複製されたスタンバイDBインスタンスで構成。プライマリDBインスタンスで障害が起きたら、フェイルオーバーし、スタンバイDBインスタンスの方がプライマリDBインスタンスになる。アップグレードなどはスタンバイDBインスタンス→プライマリDBインスタンスの順で行われる。
RDSの障害発生時
- シングルAZの場合、RDSが自動で再起動。ポイントタイムリカバリが復元可能
- マルチAZの場合、マスターに障害発生したら自動的にスレーブへフェイルオーバー。スレーブが代わりにマスターに昇格。特に対応は不要。（マスター・スレーブ）
RDSのメンテナンスウィンドウ
メンテナンスの際には、DBインスタンスは停止する。
Aurora
オートスケーリングあり
頻繁にデータ更新があるDB用
1リージョン3AZにそれぞれ2つずつ自動複製（計６つ）で耐障害性・可用性高い。
自動フェイルオーバーあり
プライマリDBインスタンスに障害発生時は、リードレプリカをプライマリDBインスタンスに昇格させる。
エンドポイント
-
クラスターエンドポイント
各インスタンスはこのエンドポイントとアクセスするため、アプリのDBアクセスは変更しなくてOK。
唯一書き込み可能。 -
リーダーエンドポイント
リードレプリカに接続する、読み取り専用 -
カスタムエンドポイント
任意の用途で設定 -
インスタンスエンドポイント
クラスター内の特定DBインスタンスに接続し、直接制御できる
Aurora サーバーレス
スケーラブルでコスパがいい
DynamoDB
キーバリュー型のNoSQL
非／半構造化データを扱う
BASE特性（Basically Available, Soft-state, Eventual Consistency）
1リージョン3AZに自動保存
オンデマンドバックアップにより、稼働中でもパフォーマンスが下がらずにバックアップ可能
結果整合性モデル
2カ所のAZへの書き込みが完了したら、正常に書き込みが完了したと見なされるが、そのときに3カ所目のAZで読み取り処理があると、最新のデータが取得できない可能性がある。
強力な整合性のある読み込みオプションを設定すると、最新のデータを常に表示可能。
※NoSQLなのでミッションクリティカルなシステムのトランザクション処理には向いていない
DynamoDBの使い方
- 利用負荷があらかじめ予測できる場合はプロビジョンドスループット
- 利用負荷があらかじめ予測できない場合はオンデマンドキャパシティーモードを選択
ユースケースは大量のデータ処理が必要なモバイルゲームやアドテク、IoTのデータ処理、セッション情報、JSONドキュメントなど
TTL（Time To Live）
テーブル項目に有効期限を設定し、それを過ぎると自動削除される。
DynamoDB Streams
追加などの変更履歴を保持し、ストリームとして24時間保持する。
DAX （DynamoDB Accelerator）
DynamoDB用のインメモリキャッシュ
低レイテンシーで読み取りスループット向上
ユースケース
JSONドキュメント保存、IoTデータ格納、セッション保存、S3オブジェクトのメタデータ保存など
DynamoDB グローバルセカンダリインデックス(GSI)
クエリ処理の柔軟性を高めるための機能
DynamoDB Local
DynamoDBのエンジンのみのライブラリ。デプロイせずにDynamoDBとアプリケーションの連携テスト可能。
Redshift
ペタバイトのデータも扱えるマネージド型データウェアハウス
大量のデータの集計と分析が可能
☆列指向型DB↔︎行指向型DBはこれまでのRDBで、データ量が増えるほど遅くなる
ノード、リーダーノード（指示用）、コンピュータノード（処理用）、クラスター（まとまり）
自動スナップショットは８時間ごと or ノードあたり5GBの変更時。自動スナップショットの場合は保存期間が過ぎると、自動削除される。
自動削除が嫌なら手動でスナップショットを取る
ただし、コストを抑えるなら手動スナップショットは定期的に削除しよう
クロスリージョンスナップショット可能
冗長性を高めるのは、ノード数を増やそう
コンピューティングノードの障害は自動検知、他のノードからデータが複製され、自動プロビジョニング。代替ノードが復旧されるまで更新はできない。
「拡張されたVPCルーティング」を有効にし、VPCエンドポイントを置くことで、インターネットを経由せずにRedshift-S3間を接続できる。
Redshift Spectrum
S3上に配置されたファイルを外部テーブルとして定義してアクセスできる。それにより、データロードの時間などが不要になる。
Redshiftだと、DBが大規模になるとS3からのデータのロード二時間がかかってしまっていた。
ElastiCache
マネージド型インメモリデータベース
高スループットで低レイテンシー
毎回DBにクエリを投げるのは非効率だから使用。RDBのパフォーマンス向上。
ElastiCacheをDBの前におくことで、DBの負荷を軽減＆パフォーマンス向上
高速にリアルタイム処理が必要な場合はインメモリキャッシュを利用してデータ処理を高速化する
-
Memcached
キャッシュ用、シンプルな構造。
暗号化や高可用性、コンプライアンスを気にしないならこれ。 -
Redis
マスター・スレーブ型、複雑な構造、フェイルオーバーあり。
ミッションクリティカルな業務用ならこれ。
キャッシュ戦略
遅延読み込み（Lazy Loading）
データ読み込み時にまずキャッシュを参照し、ヒットしない場合にサーバーへ取りに行く
書き込みスルー（Write Through）
データ書き込み時にキャッシュにも書き込みをする。常にキャッシュから読み込める。