はじめに
問題解いてて問われた内容の備忘録だったもの。
EBS(Elastic Block Store)
ボリュームタイプ
- SSD(Solid State Drive)系
- 汎用SSD(gp2/gp3):一般的な用途向け
- プロビジョンドIOPS SSD(io1/io2):高いI/O性能が必要なワークロード向け
- HDD(Hard Disk Drive)系
- スループット最適化HDD(st1):高スループットなシーケンシャルアクセスが必要なアプリケーション向け
- Cold HDD(sc1):アクセス頻度は低いがコスト効率の高いストレージが必要なデータ向け
- マグネティック:旧世代のストレージタイプ
EBSのtipsなど
- EBSはEC2とは物理的に隔離された(ネットワークで接続された)独立したブロックストレージ
- ボリュームは同じAZ内のEC2インスタンスにしかアタッチできない
- EBSボリュームはインスタンス経由でアクセスされる
- ボリュームは同じAZ内の1つのインスタンスにのみアタッチできる
- ※ プロビジョンドIOPSボリュームの一部は複数EC2インスタンスにアタッチ可能
- 高速スナップショット復元(FSR:Fast Snapshot Restore)
- スナップショットを取得したEBSの高速スナップショット復元を使うと、データが使用可能になった直後から最大I/Oパフォーマンスを発揮できる
- アタッチされているEC2が停止状態でも利用しているEBSボリュームは課金対象
ボリュームの作成
作成方法は2パターン。
- Amazon EBS スナップショットからボリュームを作成
- スナップショットはEBSの利用状況に関係なく、非同期に作成できる
- データに齟齬が発生しないためにも関連アプリケーションを停止した上でスナップショットを取得する方がよいとされる
- スナップショットはEBSの利用状況に関係なく、非同期に作成できる
- 空のボリュームを作成
- 新規で作成後はまずボリューム内にファイルシステムを作成することが必要
- そのボリュームをEC2インスタンスにマウントすることでディスクとして利用可能になる
ボリューム削除
- EC2の削除とともにEBSは削除されるため、データを保持したい場合には設定変更が必要
- ルートボリュームのDeleteOnTermination属性
- デフォルトで有効化(つまり削除される)
- ルートボリューム以外のDeleteOnTermination属性
- デフォルトで非有効化(つまり保持される)
- ルートボリュームのDeleteOnTermination属性
ボリュームの暗号化
-
ボリュームの作成時にのみ暗号化を適用できる
- 暗号化されていないEBSボリュームに対して、後から暗号化を適用することはできない
- 暗号化されていないEBSボリュームを暗号化したい場合は、スナップショットからEBSボリュームを復元する際に暗号化を有効化する
EFS(Elastic File System)
EFSの基本
- 特定のAZに限定せずにVPCに配置して利用するファイルシステム
- 構成要素
- ファイルシステム
- マウントターゲット
- セキュリティグループ
ストレージクラス
- EFSスタンダード:3つのAZに分散
- EFS 1ゾーン:1つのAZのみ配置
- EFS IA(低頻度アクセス):コストおさえるやつ
- EFS 1ゾーン-IA :1ゾーンと低頻度アクセスの組み合わせ
EFS ライフサイクル管理
- 指定したライフサイクルポリシーに従って、ファイルは自動的にストレージクラス間で移動する
- ライフサイクルポリシー
- IA への移行:低頻度アクセスへ
- アーカイブへの移行:アーカイブストレージへ
- 標準への移行:標準ストレージに戻す
パフォーマンスモード
- 汎用モード:
- デフォルト、低いレイテンシ用途(推奨)
- ほとんどの場合こっちでOK
- 最大I/Oモード:
- 高いスループットと高いレイテンシを許容する用途
- 並行してアクセスする数が多い場合でもパフォーマンスを維持してくれる
- 数百 ~ 数千のクライアント同時アクセスがある場合などはこっち
スループットモード
- バースト:
- 設定されたスループットを越えるような一時的な負荷にも耐えられる
- プロビジョニング:
- バーストでも耐えられそうにない負荷が予測できる場合はこれ
- エラスティック:
- パフォーマンスを動的にスケールアップ/ダウンしてくれる
FSx
Amazon FSx for Windows File Server
- SMBプロトコルをサポートし、フルマネージドなWIndowsのファイルサーバーとして機能する
- EFSはLinux向けに設計されているよ(NFSプロトコル)
- Microsoft Active Directory統合、Windows ACL(アクセス制御リスト)などのWindows固有の機能を提供
Amazon FSx for Lustre
- Linuxベースで動作し、Lustre(OSSの分散ファイルストレージ)ファイルシステムを使用
- 高帯域幅、低レイテンシのパフォーマンス(速度が重要)が求められるワークロードに最適
- 2つのファイルシステムデプロイオプションがある
- スクラッチ
- 高速なデータアクセスが必要な一時的および短期間の処理向け
- 再起動や障害時にデータが失われる可能性があるので重要なデータのバックアップとしては使わない
- 永続的
- データの長期ストレージが必要なワークロード向け
- システムの再起動や障害が発生してもデータが保持されるため、重要なデータの保存に適している
- スクラッチファイルシステムと比較して、ネットワークパフォーマンスやや低くなることがある
- 耐久性とデータの永続性を提供しているので
- スクラッチ
S3(Simple Storage Service)
構成要素
- バケット:保存されるオブジェクトのコンテナ
- オブジェクト:データとメタデータで構成される
- メタデータ:オブジェクトを表現する名前と値のペアのセット
強い整合性モデル
あるデータの追加や更新の反映後は必ず変更後の状態が取得できるようになる。
パフォーマンス改善系
- オブジェクトキーにプレフィックスを利用する
- 日付ベースでアップロードを分散することで少なくとも 3,500 リクエスト/秒、データの取得で 5,500 リクエスト /秒をサポートできるようにパフォーマンスを自動的に向上できる
-
マルチパートアップロード
- 大容量オブジェクトをいくつかに分けてアップロードできる
- 大きなファイルのアップロード処理の負荷を軽減できる
-
S3 Transfer Acceleration
- 遠い地域のS3へのデータ転送をサポートする
- CloudFrontのエッジロケーションにアップロードすることで、AWSの安定した回線を使える
- 似てるけど AWS Global Accelerator はアプリケーションへのアクセス全般を高速化するための機能
-
S3 Select(S3 Glacier Select)
- シンプルなSQLを使用してAS3オブジェクトのコンテンツをフィルタリングし、必要なデータのみ取得できる
- 必要なデータ転送量の削減によりパフォーマンスが向上
- AS3 Selectは単一のオブジェクトを取得、Athenaは複数のオブジェクトを取得できる
- ちなみに、新規のお客様へのAmazon S3 Selectの提供は終了したみたい...
データの暗号化
S3の暗号化方式として、サーバ側の暗号化とクライアント側の暗号化を選択可能。
※ 現在、Amazon S3のバケット作成時に SSE-S3 がデフォルトの暗号化として設定されている。
- サーバー側の暗号化
-
Amazon S3管理キーによる暗号化(SSE-S3)
- データをAmazon S3にアップロードすると、オブジェクトは保存される前にAmazon S3が自動的に暗号化
- オブジェクトをダウンロードする際は、S3側で自動的に復号
- ちなみに、S3バケットに保存されるアクティビティログなどのログも自動で暗号化、復号される(S3バケットに保存されるからね)
-
AWS KMSのカスタマーマスターキーによる暗号化(SSE-KMS)
- データの暗号化と復号にはAWS KMSのカスタマーマスターキーが使用される
- 復号にはAWS KMSカスタマーマスターキーに対して権限が必要
-
お客様指定キーによる暗号化(SSE-C)
- ユーザー自身が管理するカスタマー管理のキーを使用して暗号化
- データの復号にはユーザーが提供するキーが必要
-
Amazon S3管理キーによる暗号化(SSE-S3)
- クライアント側の暗号化
- SDKを使ってデータを暗号化してからS3に送信するなど
- ユーザー自身が暗号化キーを管理し、このキーを用いてデータを暗号化
データ保護の観点
バージョニング
- バケット単位で指定可能
- バージョンを合計した保存容量が必要
S3オブジェクトロック(バケット作成時にしか有効化できない)
- リテンションモード
- ガバナンスモード:特別なアクセス許可を持つユーザー以外が、オブジェクトバージョンの上書きや削除ができない
- コンプライアンスモード:ルートユーザー含め全員が、オブジェクトバージョンの上書きや削除ができない
- リーガルホールド
- リテンションモードとの違いは保持期間の設定がないこと
- 解除は s3:PutObjectLegalHold 権限を持つユーザーのみ可能
MFA Delete
有効化すると、バケットやオブジェクトの変更・削除時にMFA(多要素認証)のワンタイムパスワードが必要
署名付きURL
- 特定のオブジェクトに対して一時的にアクセス権を付与できる
- URLを知っている人は誰でもアクセス可能になるので注意
データ共有
クロスリージョンレプリケーション
- S3バケットにオブジェクトが作成・更新・削除された際のイベントをトリガーとして、別のS3バケットに対してオブジェクトデータのレプリケーションが実行される(一方通行)
- CLIを使った手動実行も可能(通常は自動)
クロスアカウントアクセスの有効化
- 別アカウントのユーザーに対して IAMロール と バケットポリシー 両方の許可を行ってクロスアカウントアクセスの設定
- リクエスタ支払い機能の有効化
- データをリクエストしたユーザーに支払いが発生するS3バケットの課金の仕組み
- 他者がデータにアクセスする際に、発生する費用を負担したくない場合に使う
静的Webサイトホスティング
S3を利用した静的コンテンツの配信に関して、設定が必要なポイントは以下。
- ブロックパブリックアクセスの無効化
- バケットポリシーでバケットの読み取り許可を設定
※ 使用しているリージョンに応じて、Amazon S3 ウェブサイトエンドポイントは以下の2つの形式のいずれかになる
http://${bucket-name}.s3-website-${Region}.amazonaws.com
http://${bucket-name}.s3-website.{Region}.amazonaws.com
S3 Glacierの取り出しオプション
よく問われる印象。
-
Instant Retrieval:
- ミリ秒単位
-
Flexible Retrieval(Glacier標準):
- 迅速(Expedited):1~5 分
- 標準(Standard):3~5 時間
- 大容量(Bulk):5~12時間
-
Deep Archive:
- 標準(Standard):12時間以内
- 大容量(Bulk):48時間以内
その他S3に関わる機能など
S3データレイク
- S3バケットを利用して、大量のデータを一元的に格納するデータストレージソリューション
- 各種分析ツールやAWSサービス(Athena や Redshiftなど)と連携して利用できる
ストレージクラス分析
- ストレージアクセスパターンを分析し、適切なデータを適切なストレージクラスに移行すべきタイミングを判断できる
- 定期的な分析を通じて不要なコストを削減し、データ管理の効率を向上させる
S3 Access Analyzer
- AWSアカウントの外部からアクセスできるリソースを特定するためのツール
- S3バケットに対する外部アカウントからのアクセス情報を分析し、不正なアクセス設定がないかを確認できる
Storage Gateway
- オンプレのデータをクラウドへ連携させるためのインターフェースみたいなもの
- S3バケットとオンプレミスストレージを接続してハイブリッドストレージを構成する機能を提供している(ISCSIデバイスとの接続とかね!)
※ iSCSI(アイスカジー):物理的に接続されているデバイスと、ネットワーク越しにSCSI接続をするためのインターネットプロトコル
Storage Gatewayのタイプは3種類
ファイルゲートウェイ
- Amazon S3 ファイルゲートウェイ:
- オンプレのアプリケーションがS3にファイルを保存したり、S3からファイルを取得したりするためのインターフェースを提供
- ※ AWS上のWindowsファイルサーバーに直接アクセスできない
- Amazon FSx ファイルゲートウェイ:
- Amazon FSxのファイルシステムへの簡易アクセスを提供
- 特にWindows環境向けに設計されており、Amazon FSx for Windows File Serverとの互換性◎
ボリュームゲートウェイ
S3全体を1つのボリュームとして管理するのでS3のAPI使用不可!
- キャッシュ型ボリューム:
- 主にS3にデータを保存 して、頻繁に利用するデータだけをローカルにキャッシュする
- キャッシュがないデータは取得が遅延するのでデータの読み込み速度がシステム上問題になる場合は適さない
- 保管型ボリューム:
- ローカルにデータを保存 して、定期的にS3にバックアップをとる
- オンプレデータを定期的にバックアップとるみたいな用途に向いてる
テープゲートウェイ
- 物理的なテープデバイスの代わりに仮想テープを使用し、データをクラウドにバックアップするタイプ
- 試験で問われたことはたぶんない