S3について勉強する
AWS 認定ソリューションアーキテクト ? アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。
今回もこの本を一読したうえで機能単位で勉強していく。
- Amazon S3(Simple Storage Service)について
- S3の各用語とファイル構造
- ストレージ
- S3 intelligent-tiering
- S3の結果整合性モデル
- バージョニング機能
- アクセス制御
- 暗号化
- 監視
- クロスリージョンレプリケーション
- クロスリージョンリソースシェアリング(CORS)
- AWS Storage Gateway
- ログ保存
- ライフサイクルルールの適用
- AWS Transfer Acceleration
- Glacier
- Glacier Deep Archive
- 静的Webサイトホスティング時の注意点
- 複数のユーザがアクセスするS3をまとめて管理する場合
Amazon S3(Simple Storage Service)について
高耐久・大容量のオブジェクトストレージサービスで、マネージド型で提供されている。利用可能容量に制限がなく、利用した分だけ料金が発生するシステム。
リージョンサービスとなる。
S3の特徴は以下に記載する通り
高耐久性
デフォルトで同一リージョン内の3ヵ所のAZに自動的に格納するため高い耐久性を持つサービスとなる。またAZ間は低遅延のプライベートネットワークで接続されている。
SLA上、耐久性は99,999999999%。
ただ可能性の側面では耐久性には劣る。SLA上は99.99%。
安価
容量単価は月額１GBで約3円ほど。S3のサービスとしては、Readなどで課金するタイプ。
S3の各用語とファイル構造
S3は大きく分けてバケットとオブジェクトに分類される。バケット
オブジェクトが格納される場所。ディレクトリに近い。名前はグローバルでユニークてある必要性があるため、「test」とか安直なものは使用されていて使えない可能性が高いので注意。
オブジェクト
S3に格納されるファイルでURLが付与されている。バケット内オブジェクト数は無制限。
ひとつのオブジェクトサイズは0バイト～5TBまで。
ただし1回のPUTでアップロード可能なオブジェクトのサイズは最大5GBまでなので、それを超過する場合はマルチパートアップロードを使用する。
S3のファイル構造
S3のファイル構造はURLを見る限りは階層構造があるよう見えるが、階層構造ではなくすべてフラットに格納されている。（ファイルの上部階層もディレクトリではない）階層構造があるように見えるのは人間が見てわかりやすいため。
マルチパートアップロード
大容量ファイルを分割して送ることで1回のPUTできるサイズ5GB以上のファイルを格納できる。100MB以上のファイルをPUTする場合はこちらが推奨される。
5GBあるファイルをPUTするときのパフォーマンスあげるにはというような問題の場合はこれを選択するのがよさそうか。
ストレージ
利用意図にあわせて数種類存在する
STANDARD（スタンダード）
デフォルトのストレージクラス。上で書いた同一リージョン内の3ヵ所のアベイラビリティゾーンに自動的に格納する。
通常使用する場合はこれを使用する。
耐久性：99,999999999%、可用性：99.99%
STANDARD-IA（標準低頻度アクセス）(Standard-Infrequent Access)
スタンダードと同様に3ヵ所のアベイラビリティゾーンに保存するため、STANDARDと同等の耐久性を持っているストレージクラスで、STANDARDよりも安価。STANDARDと違う点は、読み出し容量に対して課金を実施する点。
そのため頻繁にアクセスするような場合は結果的にSTANDARDよりも高くなるというケースがあり得るので、頻繁にアクセスるデータはSTANDARDにしたほうがよい。
主にバックアップ用。
耐久性：99,999999999%、可用性：99.99%
ONE ZONE-IA(1ゾーン低頻度アクセス)(One Zone-Infrequent Access)
基本的にはSTANDARD-IAと同様のユースケースだが、耐久度をSTANDARD-IAより求めない場合に利用。耐久度を求められない理由は、このストレージクラスは3ヵ所ではなく、1ヶ所のアベイラビリティゾーンのみにデータを保存するため。
コストはSTANDARD-IAよりも少ないため、後述するGlacierよりもすぐに取り出したいけど、そんなに重要ではないデータに利用する。
バックアップデータや、一時的に格納するデータ、消えても大丈夫なログ用となる。
耐久性：99,999999999%、可用性：99.95%
S3 Glacier
ONE ZONE-IAよりも低コスト。ただしビジネスモデルとしてデータ取出で課金をするモデルのため、データ取出コストや、取出時間もかかる機能となる。
通常直接S3 Glacierに対してデータを投入することはない*1ので、S3のライフスタイルによって格納されることになる。
ボールドロック機能で、データの削除を防止したりもできる。
詳細は後述。
耐久性：99,999999999%、可用性：復元後99.99%
S3 Glacier Deep Archive
S3 Glacierよりももっと低コストでデータをアーカイブしたい場合に使用する機能。ただし、データの取出しも一番かかるので、データを取出しに時間がかかってもいいから安く補完したいというときに使用する。
耐久性：99,999999999%、可用性：-
S3 intelligent-tiering
バケットに保存されたオブジェクトが長時間アクセスがなかった場合に、より低価格なストレージ（低頻度ストレージ）に移動させることでコストを削減しようという設定。
Amazon S3 のライフサイクルを使用したオブジェクトの移行 - Amazon Simple Storage Service
30日間アクセスがないものを低頻度ストレージにもっていくのがよい。
また低頻度ストレージからアクセスされた場合は、高頻度アクセスに戻るためデータの活用が不明なものもコスト削減しながら運用することが可能となる。
S3の結果整合性モデル
S3の更新や削除は結果整合性モデルを採用している。
結果整合性とは、途中で整合性が崩れた状態になるが、十分な時間がたったら最終的には整合性が取れた状態になる。
即時反映はされない。
www.slideshare.net
問題的にはPUTがうまくいくと200が返却されるという点、
結果整合性上、すぐには確認するとデータが残りっぱなし。
最終的には整合性取れる。「最終的に」というワードが重要。
バージョニング機能
オブジェクトの世代管理ができる。バージョンはオブジェクト単位でバージョンIDが採番される。同名オブジェクトをuploadすると上書きされる
バケット上に古いージョンのデータが残りっぱなしになり、容量を食うためライフサイクル管理で古いバージョンを削除する必要がある。
アクセス制御
大きく分けて3種類あり、アクセス制御の強度としては、
となる。
S3はほかの機能とは違い、インターネットからのアクセスができる設定を実施することができる。（静的Webサイトホスティングのため）
IAMポリシー
IAMユーザやIAMロールからのS3やバケットへのアクセス権限制御をする。S3やそれ以外の機能も含めて一元的に管理したい場合に使用。
バケットポリシー
バケット自体に制御をかける。JSONコードを直接記載する。S3リソースにだれがアクセスできるのかを定義する。
ほかのアカウントからのアクセス制御も実施することができる。
CloudFrontなどでCDN経由の場合のみアクセスを許可するなどの場合に使用する（OAI）
ACL(アクセスコントロールリスト)
バケット・個々のオブジェクトに対してのAWSアカウントレベルの制御。ACLでパブリックアクセスの設定をすると、不特定多数のユーザに公開できる。
安易的にアクセス管理したい場合に使用する。
通常はバケットポリシーを使用する。
バケットがパブリックアクセスになっている問題
意図せずバケットが全公開になっている場合、S3コンソール上や、AWS Config上でチェックするマネージメントルールが提供されている。
BlockPublicAccess上でアカウントレベル、アカウントレベルで全公開になるのを抑制できる。
新規で作成されるバケットにはデフォルトで適用される。
ACLの単位で、パブリックなオブジェクトをアップロードさせない、無力化させる。
パブリックなアクセスを許可するバケットポリシーを使用させないようなことができる。
署名付きURL
AWS CLIやAWS SDKを利用して、署名付きURLを発行することができる。※署名付きURLはS3上のデータに対して一定時間だけアクセス許可するためのURLを発行するもの。アクセス可能な時間を自由に決められるので、ファイル授受をよりセキュアにできる。
これをやることで、ACL上でフルオープンになっているから直接リンクされて困るみたいなときに、防ぐことができる。
（ACL上でのフルオープンもやめたほうがいいよね……）
静的Webサイトホスティング
CloudFrontと組み褪せて、静的なサイトをS3で用意することができる。メンテナンス時のWebページ。暗号化
サーバサイド側暗号化
S3はサーバサイトの暗号化を以下3種類持っている。
キーの管理を極力実施したくない場合、SSE-S3（S3でのデフォルトのサーバサイド暗号化）を利用するのがよい。
AWS CLIやAWS SDKを利用することでサーバサイドの暗号化指定も可能。
SSE-KMSはKMS上で暗号化キーを作成し管理する。（自分のキーも使用できる）
SSE-KMSとSSE-S3の違い
以下がわかりやすかったので引用
ktrysmt.github.io
SSE-KMSの特徴
・キーポリシーでCMK(カスタマーマスターキー)への個別のアクセス制御ができる
・KMSに対するAPIコールに当たるため、監査証跡(CloudTrail)を残すことが可能
・暗号化キーの作成および管理ができる
・当該AWSアカウントのリージョンごとに一意に作成されるデフォルトサービスキーを使用することもできる
・KMS利用分の追加料金が発生
・S3に対するPut/Getが非常に多くなる場合には KMS の APIコールの制限 の考慮が必要
SSE-S3の特徴
・キーに対する個別アクセス制限は不可、実質的なアクセス制限は署名バージョン4による当該AWSアカウントID以外の拒否のみとなる
・監査証跡(CloudTrail)には残らない
・KMSに比べキーの選択肢は無く提供されるもののみ使用できる
・SSE-S3のための追加料金は発生しない
・APIコールの制限に関して考慮は不要
CloudTrailに残せるか残せないか、鍵のバリエーションがあるかないか、追加料金の有無、APIコールの制限が大きな違い。
KMSのほうが監査にのる点と、鍵のバリエーションでよいが、APIコールの制限と料金を考えるとS3のほうが良いという感じだろうか。
クライアント側暗号化
AWSへデータを送信・保存する前にユーザー環境でデータの暗号化を行う。
クライアント側で暗号化する場合、ユーザ側でファイルに対して暗号化、パスワード処理を施してからアップロードを行う。
AWS SDKを使用することでプログラムからS3アップロード時にファイル暗号化も可能。
監視
S3アクセスアナライザー
S3アクセスアナライザーを使用し、不正なアクセスが発生していないかアクセスポリシーを監視する機能。
バケットポリシー、ACLのモニタリング。
どのバケットがどのような権限がセットされているのかを見ることができる。
またバケットの実際のアクセス状況の確認も可能
クロスリージョンレプリケーション
異なるリージョン間のS3バケットオブジェクトのレプリケーションを実施する。バケットに対するオブジェクトの作成、更新、削除をトリガーに非同期レプリケーションする。
マネージドサービスとして、AZにまたがって堅牢な構成にもともとなっているが、それに加えてさらにリージョン間でもデータを保持したいという要望の場合に使用する。
対象元のバケットに対し、バージョニングの機能を有効にする必要がある。
また対象元<-->対象先で双方向でレプリケーションをしたい場合は、両方のバケットに設定が必要。
異なるアカウントが所有するバケットにも設定できる。
クロスリージョンリソースシェアリング(CORS)
CloudFrontで使用される、特定のドメインにロードされたアプリケーションが異なるドメイン内のリソースと通信する方法を定義。sample.a,comとsample.b.comのドメインは基本的にはどちらかしかアクセスができないが、この機能を使用すると複数のドメインも通信することが可能になる。
AWS Storage Gateway
オンプレミスとAWSを接続するためのサービス。
AWS Storage Gatewayでできること、使いどころのポイント (1/2)：CodeZine（コードジン） より引用
オンプレミスからバックアップをS3に置きたいというの基本的なユースケースとなる。
具体的には
AWS側の機能や性能をオンプレミス側が活用できるのが大きな利点。
- シームレスにオンプレミス側から機能を使用できる。
- キャッシュを活用した低レイテンシーなアクセスが可能
- 堅牢性・低コスト・拡張性も得ることができる
- 効率的なデータ転送
- AWSのモニタリング・管理・セキュリティも使用できる
AWS Storage Gatewayのタイプ
ファイルゲートウェイ
Storage Gatewayを経由してファイルデータを格納するものボリュームゲートウェイ
VTLを除くボリューム型のStorage Gatewayでは、Storage GatewayはiSCSIターゲットとして動作する。保管型ボリューム、キャッシュ型ボリューム
ログ保存
CloudTrailやELBのログ出力先として利用可能。S3へのアクセスログを取得することも可能。
ライフサイクルルールの適用
ライフサイクルルールを適用することで、オブジェクト生成から設定日付経過したオブジェクトを削除するように設定できる。30日よりも前のデータが要らなければ30を指定する。
スタンダード上に生成したファイルを30日後にGlacierにアーカイブしたい場合は、ライフサイクルルールを使用するとよい。
スタンダード -> 標準低頻度アクセス(Standard-Infrequent Access) -> Glacierの順番でアーカイブする場合、スタンダードで30日以上、Standard-IAで30日以上経過する必要がある。（計60日以上）
www.slideshare.net
AWS Transfer Acceleration
クライアントとS3バケット間で長距離にわたるファイル転送を高速、簡単、安全に実行できる。ユースケースとしては
- 世界中にファイルをアップロード、ダウンロードする場合
- 大陸間で定期的にギガバイトからテラバイト単位のデータ転送がある場合
- S3へのアップロード時にインターネット経由で利用可能な帯域を十分に活用できていない場合
Glacier
大容量データを安価で保存できるのが、データへのアクセスに時間がかかる。機能のモデル上、保存はS3よりも安くなるが、データの取出しで取出しのGB単位で課金＋リクエスト件数でも課金されるため、データ取出しにより課金するモデルとなっている。
Glacierはデータをアーカイブという形で保存される。
アーカイブした場合のマスターはS3ではなくGlacierになる。
ひとつのアーカイブの最大サイズは40TB。保存可能なアーカイブ数とデータ量に制限はない。
AES-256で自動的に暗号化している。
S3と違って直接アップロードする取得するという手段ができない。
主にデータアーカイブ用としてめったに触らないファイルを格納するのが良い。
ボールドロックを行うことでデータの削除を防ぐことができる。
Glacierでアーカイブしたデータを復元したい場合、以下のオプションを設定することで復元可能
迅速(Exprdited)
1～5分で復元可能。通常はオンデマンド。成功する保証がないタイプ。
プロビジョニングタイプだとリクエストはすぐに処理されるが、費用が高価
標準(Standard)
3～5時間で復元可能。大容量(Bulk)
5～12時間で復元可能。最も低価格で、大量データ（ペタバイトのデータを含む）を取得できるのが特徴。
上記にもあるけどレイテンシの観点でGlacierとそれ以外がかなり違う。他はミリ秒なのにGlacierは分時間単位なので。
データの削除
Glacierは最低90日間保持しなければデータを削除できない。もし少しの期間だけ格納して削除したいという場合は、S3に格納して削除したほうが値段が安くなる可能性がある。
また、S3上のデータを削除するとGlacier側のデータも削除される。
Glacier Deep Archive
Glacierよりも値段が安くデータ保存が可能だが、データ取得がさらに遅くなる中長期保存用ストレージタイプ。データは3つ以上のAZにまたがって保存される（S3と同様の耐久性）
標準取出しで12時間以内
大量取出しで48時間以内
静的Webサイトホスティング時の注意点
403エラーが出る場合
403エラーつまり接続先のサイトがなくて、アクセスできなかった場合になる。HTTP 403、またはエラーメッセージ Forbidden（「閲覧禁止」「禁止されています」の意）は、HTTPステータスコードの一つ。ページが存在するものの、特定のアクセス者にページを表示する権限が付与されず、アクセスが拒否されたことを示すもの。また、サイトの制作者側の設計ミスによる障害やサイトが非常に混雑している時、URLが間違っている場合にも表示されることがある。
HTTP 403 - Wikipedia
S3においてちゃんと置いたはずなのにつながらないパターンのやつだが、原因はアクセス制限がかかっていて見られないというものになる。
つまりバケットポリシーが設定されていない場合でのエラーになる。
503エラーが出る場合
503エラーつまり接続先がダウンしてしまっている場合になる。
HTTP 503、またはエラーメッセージ Service Unavailable（「サービス利用不可」「サービスが利用できません」の意）は、HTTPステータスコードの一つ。一時的にサーバーにアクセスできないことを示す。
HTTP 503 - Wikipedia
その場合は、パーティショニングに問題があるので確認する。
複数のユーザがアクセスするS3をまとめて管理する場合
S3アクセスポイントを利用することで、あるユーザはアクセスしないがあるユーザはアクセス可能にするなどの対応が可能。S3 Access Points によって、お使いのアプリケーションセットから S3 上の共有データセットへのデータアクセスの管理がシンプル化されます。たった 1 つの複雑なバケットポリシーを管理するのに、数百におよぶアクセス許可ルールの書き込み、読み取り、追跡、監査をする必要はなくなりました。S3 Access Points を使用すると、特定のアプリケーション向けに用意されたポリシーを使用して共有データセットへのアクセスを許可するアクセスポイントをアプリケーションに合わせて作成できます。
Amazon S3 Access Points - アマゾン ウェブ サービス
バケットポリシーが煩雑になるならこちらを使用するのがよさそう。
