引き続きAWSの勉強を進めています。
今日はAWSサービスの中でも特に基本的なサービスの1つとして挙げられる、Amazon S3の基本について学んでいきます。
もくじ
・概要
３．アクセス管理方法
４．S3のその他機能
・フォルダ
１．Amazon S3とは
◎概要
Amazon S3（Amazon Simple Storage Service）とは、AWSが提供するストレージサービスである。
そもそも一般的な話として、ストレージには３種類（オブジェクトストレージ、ファイルストレージ、ブロックストレージ）ある。
Amazon S3はオブジェクトストレージに分類され、保存データを、
データ本体+メタデータで構成される「オブジェクト」という単位で管理する。
※３種類のストレージの違いや詳細は以下の記事にまとめています。
S3の主な特徴は以下の通り。
・上記の通りオブジェクト単位での管理のため、大きなデータや非構造データであっても保存できる。
・標準で、99.9999999%の耐久性と、99.9% の可用性を担保
・使った分だけの従量課金制
・デフォルトで非公開のストレージ（公開することも可能）
以降、本記事では、S3の特徴の詳細や、構成コンポーネント、アクセス方法や権限の考え方、その他の主な機能について説明する。
◎ストレージクラス
S3にはストレージクラスという概念がある。
ストレージクラスとは、S3リソースの管理・アクセス方法の選択肢のことである。
コストと利便性との兼ね合いを踏まえ、多様なユースケースに合わせてS3の使い方を選べるよう、
2023年5月現在で8種類のストレージクラスが存在する。
各クラスの詳細や比較は公式ドキュメントを参照頂きたいが、
ここでは最も標準となるストレージクラス（S3スタンダード）について紹介する。
S3スタンダードは、99.9999999%（イレブンナイン）の耐久性と、
99.9% の可用性がAWSによって保障されており、
S3スタンダードが適用されたオブジェクトは、最低3つ以上のAZ（アベイラビリティゾーン）に自動で複製される。
月に2回以上～高頻度でアクセスされるオブジェクトには、S3スタンダードの利用が推奨されている。
性能と、耐久性・可用性のバランスが、最も整った、文字通りスタンダードなストレージクラスとなっている。
月に1回以下のアクセスしか見込まれないデータや、
ほとんどアクセスが見込まれず書き込みもされないようなアーカイブデータ、
アクセスパターンが不明で自動最適化したいデータ等の場合は、
他のストレージクラスを適用することも視野に入れても良い。
適切に利用すれば、S3スタンダードよりも性能や可用性を落とす代わりに、使用料を安くできる。
ストレージクラスはオブジェクト作成時、または既存オブジェクトの変更により、
オブジェクト毎に指定できる。
ただし、特に指定しなかった場合は、標準のS3スタンダードのポリシーが適用される。
◎データ整合性モデル
前述の通り、Amazon S3は、非常に高い耐久性や可用性を提供するストレージサービスである。
S3の高耐久性や高可用性は、S3への保存データが、
自動で3つ以上のAZ（アベイラビリティゾーン）に複製されることで担保されている。
例えば、AZ①にあるS3にデータを書き込んだら、
AZ②とAZ③にも、同じデータが自動でコピーされる。
もしAZ①に何らかの障害が発生して、AZ①のS3内にあったデータが破損しても、
AZ②や③にはデータが残っており、継続して利用できる。
そこで問題となるのが、データの整合性の担保方式である。
AZ①へのデータ書き込み後、②と③にデータコピーが完了するまでには、
コピー時間というタイムラグが発生する。
2020年以前は、「結果整合性」という考え方のもと、
AZ①のS3にデータを保存完了した時点で、「保存完了」の応答がユーザに戻っていた。
すなわち、AZ②、③への複製処理が完了していない状態（AZ①内に保存されているデータと②、③のデータに差異がある状態）で、「保存完了」となっていた。
データのコピーには一定の時間がかかる。
コピー完了を待ってから「保存完了」とすると、性能が落ちてしまうことから、
厳密にはデータ不整合がある状態で「保存完了」となっていた。
2020年以降～2023年5月現在においては、
AZ②、③へのデータコピー処理も完全に終わってから「保存完了」の応答が戻されるようになった。
AWSが裏で努力し、コピー処理速度を上げてくれたことにより、
AZ①、②、③でデータの整合性担保＋性能影響の小ささ
という両方が実現されたのである。
ちなみにAWSは、現在の整合性担保の方式を、
「強力な整合性」もしくは「強力な書き込み後の読み取り整合性」と呼んでいる。
２．構成コンポーネント
S3は以下のコンポーネントによって構成される。
| コンポーネント | 説明 |
|---|---|
| バケット | S3に保存されるオブジェクト（データ）の入れ物で、 S3のストレージ管理単位。 バケットは1AWSアカウントにつき100個まで作成でき、 1つのバケットに対する容量やオブジェクト保存数の制限はない。 バケット作成時は、作成先リージョンと、 世界で一意のバケット名を指定する必要がある。 （リージョンとバケット名は変更不可） |
| オブジェクト | S3に保存されるデータ。 データ本体とメタデータで構成される。 |
| キー | バケット内のオブジェクト固有の識別子。 バケット・オブジェクトキー・バージョン IDの組合せにより、 各オブジェクトが一意に識別される。 |
| バケットポリシー | バケットへのアクセス権限を管理するために、 バケットに関連付けるポリシー。 詳細は３．アクセス管理方法で説明。 |
| アクセスポイント | バケットへのアクセス権を管理するために、 バケットに関連付けるネットワークエンドポイント。 詳細は３．アクセス管理方法で説明。 |
| バージョンID | オブジェクトのバージョン管理をする場合に、 バージョン毎にオブジェクトに付与されるID。 詳細は４．S3のその他機能で説明。 |
| フォルダ | オブジェクトを管理しやすくするために、 ファイルシステムのフォルダ（ディレクトリ）のように扱える、 論理フォルダ。 詳細は４．S3のその他機能で説明。 |
| プレフィックス | オブジェクトキー名のプレフィックス。 オブジェクトが論理的に存在するフォルダパスが、 プレフィックスとして扱われる。 （例：myphoto.jpgの論理格納先フォルダが"/pthotos/2023/"なら、 "/pthotos/2023/"がプレフィックス、 "/pthotos/2023/myphoto.jpg"がキーとなる。） 詳細は４．S3のその他機能で説明。 |
各コンポーネントの関係や、AWSクラウド全体のイメージをまとめると、
以下のようになる。
３．アクセス管理方法
デフォルトでは、Amazon S3 のバケット、オブジェクト、その他関連リソース等、
すべてのS3リソースは非公開となっており、
リソースの所有者のみが、リソースにアクセスできる状態である。
他のユーザ等がリソースにアクセスできるようにするためには、
リソースの所有者が、適切にアクセス管理を行う必要がある。
S3のアクセス管理方法は４つある。
どれか１つの方法だけでアクセス管理するのではなく、目的に応じて適切な管理方法を組み合わせて使うと良い。
| 管理方法 | 管理対象 | 説明 | 制御例 |
|---|---|---|---|
| バケットポリシー | S3リソースそのもの | バケット及び当該バケット内のオブジェクトへの読み書き可否を、 バケット単位で設定する方法。 |
①バケット"test-bucket"の閲覧は、IAMグループ"test-group"のみ許可する。 ②バケット"test-bucket"の読み書きは、IAMユーザ"test-user"のみ許可する。 ③バケット"test-bucket"では、AWS Key Management Serviceで暗号化されていないオブジェクトの書き込みを拒否する。 ④バケット"test-bucket"の読み書きは、VPC"test-vpc"の、VPCエンドポイントからのみ許可する。 |
| IAMポリシー | S3リソースの利用者 | バケットや個別のオブジェクトへの読み書き可否を、 IAMユーザ/グループ/ロール単位で設定する方法。 |
①バケット"test-bucket"の閲覧権限を、IAMグループ"test-group"に付与する。 ②バケット"test-bucket"の"common"フォルダ内の読み書き権限を、IAMユーザ"test-user"に付与する。 |
| S3アクセスポイント | S3リソースへのアクセスリクエスト | バケット及び当該バケット内のオブジェクトへの読み書き可否設定を持った、S3バケット専用のNWエンドポイント。 | ①バケット"test-bucket"の読み書きは、VPC"test-vpc"の、VPCエンドポイントからのみ許可する。 |
| ACL | S3リソースそのもの、利用者 | バケットや個別のオブジェクトへの読み書き可否を、 外部ユーザ含めて誰に許可するか細かく設定する方法。 ただしAWSでは、ACLを無効化し、 バケットポリシー+IAMポリシーで制御することが推奨されている。 |
※無効化推奨のため割愛 |
設定例を見て頂いても分かるように、それぞれのアクセス管理方法で設定できる内容には、
一部かぶるものもある。
特にアクセスポイントは、バケットポリシーによるアクセス制御の複雑さ、管理の大変さを背景に、
より簡潔にアクセス制御できるようにと新しく出てきた機能である。
それぞれで同じような制御ができるのは、ある意味当たり前なのだが、（私のように）S3を初めて触る人間にとっては使い分けが難しいところでもある。
表の「管理対象」の違いやシステム要件を勘案し、都度適切な設定を考えていく必要がありそうだ。
なお、上記の各手法を組み合わせてアクセス制御する際は、
各ポリシーの設定に矛盾の無いようにする必要がある。
例えば、
・バケットポリシーでは読み書き可
・IAMポリシーでは書き込み不可
と設定していれば、書き込みはできなくなってしまう。
（意図的に設定したなら問題ないが、書き込みも本当は許可したかったのに…とならないよう注意）
４．S3のその他機能
◎バージョニング
オブジェクトの複数のバージョンを 1 つのバケットに保持し、
必要に応じてオブジェクトの過去の状態を復元できるようにする機能。
デフォルトでは無効となっている。
バージョニングを有効化すると、オブジェクトには、当該オブジェクトで一意となるバージョンIDが、自動で付与される。
オブジェクトの更新（削除・上書き）をトリガーに、新しいオブジェクトバージョンが追加され、
過去のオブジェクトは過去の状態のまま保管される仕組みとなっている。
注意点として、過去バージョンのオブジェクトに対しても、S3の利用料金はかかる。
そのため、本当に必要な場合のみ、
過去バージョンの削除ルールを決めたうえで、有効化するようにしたい機能と言える。
◎データの暗号化
S3のバケットでは、デフォルトで暗号化が有効となっている（無料）。
デフォルトの場合、バケット内の全ての新規オブジェクトは
Amazon S3 マネージドキー (SSE-S3) によって自動的に暗号化される。
また、有料だが、AWS Key Management Service キー (SSE-KMS)による暗号化も可能である。
キーローテーションやアクセスポリシーの付与の管理など、
暗号化キーをより細かく制御したい、といった時に利用すると良い。
◎オブジェクトロック
オブジェクトロックとは、Write Once Read Many (WORM) モデルを使用してオブジェクトを保存する方式で、
S3のオプション機能の１つとなっている。
オブジェクトロックによって、オブジェクトの削除・上書きを、一定期間または無期限に防止できる。
コンプライアンス上の理由などで、必要なデータ文書を、書き換え不可の状態で一定期間保管したいといったケースで利用されることが多い。
なお、オブジェクトロックの設定は、バケット単位となる。（オブジェクト単位ではない）
◎フォルダ
１．Amazon S3とはとはにも記載の通り、S3は「オブジェクトストレージ」に分類されるストレージサービスである。
オブジェクトストレージでは、各オブジェクトはフラットな関係であり、ファイルシステムのような階層関係はない。
しかし、ユーザ（人間）としては、フォルダの階層構造のほうが、
中に入っているデータを探したり、管理したりしやすい。
そこでS3では、フォルダの概念を利用し、あたかも階層構造が存在しているかのように、
論理フォルダや論理サブフォルダを作って、バケット内の各オブジェクトを整理することができる。
S3のフォルダ概念を利用する際、オブジェクトの論理格納先（フォルダパス）情報を含む"フルパス"が、当該オブジェクトの「キー」名となる。
そして論理格納先（フォルダパス）情報が、当該オブジェクト名のプレフィックスとして扱われる。
オブジェクトにキー名でアクセスする際は、必ず論理格納先情報が必要となる。
今回は以上！
この記事を最後に、もしかしたらしばらくAmebaから遠ざかるかもしれません…(^-^;
生きてはいる（はず）ので、またどこかで更新した際はよろしくお願いしますー(@^^)/~~~