ある程度整理はしたと思うけれど、これでもまだ理解レベルとしてはかなり好意的に見ても50％あるかないかという感じなので、先に進んでベストプラクティスとか Well Architected
Frameworkあたりに触れたらもう一度サービス同士のつながりとかユースケースを想定した構成とかの観点で振り返らないとダメそう。

概要

Simple Storage Serviceの略。
AWSにおけるストレージサービスの1種であり、EC2の枠組みであったEBS(といっても管理自体は独立している)とインスタンスストアと違い独立したサービスになる。
ストレージ形式としてはオブジェクトストレージにあたる。
S3 Intelligent-Treringで保存されているオブジェクトに対して期間を指定し、それ以下のアクセスであるオブジェクトを低頻度のアクセスと見なして自動的に低頻度アクセス層へと移動することでコストを削減することができる。

主な用途

コンテンツ配信・保管

CMS(コンテンツマネージメントシステム)と呼ばれる体型のサービスのコンテンツデータの保存場所として用いる。
CMSはざっくりいうとWebコンテンツを構成するテキストや画像などのデジタルコンテンツを統合的あるいは体系的に管理して、必要に応じて配信等行うサービスやシステムのこと。
例えばAmazon CloudFrontというユーザーへの静的および動的なウェブコンテンツ (.html、.css、.js、イメージファイルなど) の配信を高速化するウェブサービス……
これもザックリいうと超高速なWebサーバーを使ってWebサービスを提供する場合、CMSから提供された素材をS3に保存してそれをCloudFrontが取り出してWebページを配信する……といった使い方があったりする。
まあつまりはコンテンツに使うものの保管場所ということ。

ログ・バッチの保管場所

こちらは前者に比べて保守に関わる使い方。
バッチ処理でDBを更新するためのバッチを置いておいたり、各種ログ(Cloud Trailなど)の保管場所となり必要に応じて取り出せるようにするということ。

バックアップ・ディザスタリカバリ

バックアップの中長期的な保存場所として用いる。
例えばEC2からAWS環境のバックアップを受け取り保存しておいてそれをさらにクロスリージョンでレプリケートしたり、オンプレ環境の構成をバックアップしたものを保存……といったユースケースがこれに当たる。

静的Webホスティング

動的なページでなければS3のみでホスティングできる。
基本的な設定は以下の通り。

マネージメントコンソールでバケットを作成
オブジェクトのプロパティから静的Webホスティングの設定を行う
htmlファイルをindexとerrorとでアップロードして、公開アクションを行う
バケットポリシーを設定する


バケットポリシーの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadForGetBucketObjects", # バケットポリシーのID
            "Effect": "Allow", # 許可に関するポリシーか拒否に関するポリシーか
            "Principal": "*", # 許可する対象(この場合は全許可)
            "Action": "s3:GetObject", # 許可するアクション
            "Resource": "arn:aws:s3:::bucket-name/*" # どのバケットに適用するか
        }
    ]
}

任意の部分の設定は以下の通り。

CORSの設定
独自ドメインをバケット名として指定
任意のドメインへのリダイレクト機能設定
CloudFrontとの連携(これを経由して実際にWebページを配信する)

データレイク

データレイクは様々なデータソースから集められたデータを管理し、活用のための前処理を行える環境のことを指す。
例えば複数のS3及びそれらのアーカイブ管理としてのGlacierにおいて大規模なデータセットが管理されているといった状況で、S3に保存されたデータ、及びアーカイブから戻してきたS3に戻してきたデータを
データウェアハウス用途(データ分析のために様々なデータ源からデータを収集・統合・蓄積しておくシステム。書き込むときには一括、読み出すときには大容量のデータを読み出すという特徴がある
)であるRedshiftに必要に応じて送る……といったデータのハブ的な役割であったりする。
つまり、近年IoTが当たり前になってデータ分析し、それを可視化するというサービスやそこから更に発展してAI・機械学習分析、チャットボット・スマートスピーカーといったものを利用するための
構造の一つとして非常に重要な考え方になる。

AWSのストレージサービスの形式

ブロックストレージ

ブロック形式でデータが保存され、EC2に直接アタッチするストレージでインスタンスストアとEBSが該当。
インスタンスストアは物理ディスクストレージで、EBSは管理はEC2から独立している。
高速・広帯域幅で利用できるのが特徴であり、サーバーのストレージとしての役割を担う。
要は一般PCに置き換えると仮想デスクトップ環境、開発/テスト環境としてSSDを用意し、
例えば用意されているプランの1つであるプロビジョンドIOPSを使うとなるとリレーナルデータベースやNoSQLデータベースを稼働させるサーバーのボリュームとなる……といったイメージ。

オブジェクトストレージ

今回やるS3やそれに付随したサービスであるGlacierがこれにが該当する。
オブジェクト形式でデータが保存され、HTTPSエンドポイントにリクエストしてデータのやり取りをする。
SQL的なデーターベースに近いイメージであり、ブロックストレージがEC2の役割上コンピューティングの観点で用いるストレージであるのに対して、
こちらはストレージという名の通りデータ保存の役割が強い。

ファイルストレージ

複数のEC2インスタンスから同時にアタッチ可能な共有ストレージ。
ファイル形式でデータが保存され、EFSがそれに該当する。
イメージ的には外付けHDDやSSDみたいなもの。

サービス・機能としての構成

サービス → S3
ストレージ → STANDARD、STANDARD-IA、One Zone-IA、RRS、Amazon Glacier
アクセス管理 → IAM(サービス自体へのアクセス権)、バケットポリシー(バケットへのアクセス権)、ACL(バケットに加えてオブジェクト単位までのアクセス権限)、署名付きURL(一定期間他者にアクセス権を与える)
暗号化方式 → SSE-S3、SSE-KMS、SSE-C、クライアントサイド暗号化(CSE)
パブリックアクセス(外部アクセスのやり取り) → アクセスポイント、CORS
アクセス分析・監視 → S3アクセスアナライザー
バケット管理 → ライフサイクル管理
耐障害性強化 → レプリケーション
バックアップ → レプリケート先からの復旧(双方向レプリケーションでは不可)、Glacierに保存したアーカイブから復旧、バージョン管理からのリストア
データ解析 → S3 Select(Glacier Select)、Amazon Athena、Amazon Macie、Amazon Redshift Spectrum
大容量オブジェクトの保存方法 → マルチパートアップロード
バッチ処理 → ジョブ、マニフェスト

S3の特徴とプラン

整合性に関しては2021年現在は強い整合性モデルへと変更された模様。
Udemyの講座を含めAWSの参考書はこういう細かいアップデートに対応しきれないのが難点。
参考

特徴

マネージド型サービス
高い耐久性
安価に利用できる(月額1GB/3円程度)
スケーラブル(拡張性、変化に応じての柔軟性)で安定した性能(データは冗長化されて保存され、データ容量に依存しない性能がAWSに保証される)
暗号化できる
保存できるデータサイズは0KBから5TBまで
インターネットから直接アクセスできる(HTTPSエンドポイント設定で)
結果整合性モデルである

以上に加えてバケットと呼ばれる領域をリージョンに紐付けて作成し、そこにオブジェクトにされたデータが格納される。
このオブジェクトにはURLが付与される。
オブジェクトの形式は

Key
Value
バージョンID
メタデータ(属性情報)
サブリソース(バケット構成情報を保存および管理するためのサポートサービスを使うための情報)

となる。
結果整合性モデルはデータ更新・削除等更新処理に対してその処理の反映を意図的に遅延するような処理になる。
S3は分散ストレージなので、1つのファイルの更新処理にしても分散しているストレージにコピーが順次行われるので、いわゆる競合の問題が発生する。
なのでその更新の反映を意図的に遅延することで仮に競合が起きた場合、一番最後に行われた更新処理が反映されるようになるという理屈。
これにより、強い可用性と耐久性を担保するということなのだろう。
しかし、このモデルはリアルタイムに情報する必要がある要件のDBモデルには向かないというデメリットがある。
具体的には

新規登録 → Consistency Read(読み取り一貫性)、登録後即データ反映
更新 → Eventual Consistency Read(結果整合性読み取り)、データ反映にラグ
削除 → 同上

といった感じで同時書き込み(競合)が起きた場合はタイムスタンプで判断して処理を前後させる。

プラン

例に漏れずストレージによって用途と性能(および金額も)が違う。
課金対象はまず保存データ容量(つまりどれくらい使ってるか)で1GBあたりに課金される。
500TB使っても1GB/3円程度。
次にHTTPSリクエストに対して利用料金がかかる。
リクエストによって少し違うが、1000リクエスト/0.5円程度。
最後にデータ転送に料金がかかる。
S3はインターネットからのアクセスができるAWSストレージサービスなのでということなのだろう。
インターネットからのアクセスによるアップロードは無料だが、引っ張ってくるときにはリクエスト料金と同時に転送料がかかる。

STANDARD

一番ノーマルなやつ。
複数AZにデータを複製(レプリケーション)するため耐久性が高い。
可用性は99.99%。

STANDARD-IA

IAはInfrequency Accessの略で稀なアクセスつまり低頻度にアクセスされるデータの置き場として使えるという意味になる。
STANDARDに比べて安価であるが、データを読みだした容量に応じて課金される。
可用性は99.9%とSTANDARDと比べて落ちる。

One Zone-IA

使用する目的としてはSTANDARD-IAと同じ。
ただし、こちらは上記2つよりさらにコストを抑えて運用できる代わりに、One Zoneの名の通りレプリケーションされないので可用性は更に落ちて99.5%となる。
なので、低頻度アクセスではあるが必要に応じてすぐに取り出す必要があるがデータの重要度としては低い(障害等をある程度考慮しなくても運用に支障がない)ものに使う。

RRS

Reduced Redundancy Storageの略で冗長化を削減したストレージ、つまり低冗長化ストレージという意味。
以下のGlacierから取り出したデータをおいておくところとして使う。
耐久性は唯一99.99%と低い。
可用性は99.99%。

Amazon Glacier

アーカイブ用として利用されるストレージであり、最安ではあるがデータ抽出に時間がかかる(3~5時間)。
最速のオプションを選択しても数分取り出しに時間がかかるので中長期的なデータの保存場所として考える。
ライフサイクルマネジメントで管理でき、ボールロック機能でデータを保持する。
可用性は保証されない。

S3アクセス管理

4パターンある。
これとは別にその特性上、インターネットからのアクセス(パブリックアクセス)の許可・拒否設定ができる。
パブリックアクセスの許可設定はバケットだけではなく、オブジェクト単位でも存在するのでのでバケットに対してパブリックアクセスの許可設定をしてもオブジェクトに対してのアクセスは許可されない。
なので、オブジェクトへのアクセスを許可するならACLの設定が必要である

IAMユーザーポリシー

そもそもS3に対してアクセスできるのか否かを決めるときにはIAMでポリシーを設定する。

バケットポリシー

S3で設定するポリシー。
バケットへのアクセス権をJSON形式で設定でき、他のアカウントへの許可も可能。
バケット単位でアクセスを管理するときに使う。

ACL

アクセスコントロールリストの略。
バケットポリシーとの違いはオブジェクト単位にまでアクセス権限を設定できること。
形式はXMLでこちらも他のアカウントへの許可もできる。
オブジェクト単位への管理になるので、簡易的なアクセス設定をするときに使える。

署名付きURL

AWS SDKで生成した署名付きURLでS3のオブジェクトへのアクセスを一定時間許可できるようにする。
語弊はあるが用途的にはロールのようなものか。

暗号化

4パターンある。

SSE-S3

標準の暗号化方式であり、簡易的に利用が可能
S3側で自動的に作成と管理を行ってくれる
Advanced Encryptoin Standard(AES-256)形式での暗号化

SSE-KMS

AWS KMSに設定した暗号キーを利用して暗号化する
ユーザーが作成・管理する
クライアント独自の暗号キーを設定することができる

SSE-C

ユーザーが指定したキーによるサーバー側の暗号化を使用することが可能
利用設定や管理が煩雑化する

クライアントサイド暗号化(CSE)

S3に送信する前にデータを暗号化する
AWS KMSなどを利用して暗号化キーを作成・管理する
アプリケーション内にマスターキーを保存する

アクセスポイント

S3をDBとして使うようなアプリケーションに対してはアクセスポイントを設定することでこれを経由してバケット内のデータのやり取りを行う。
ある程度バケットポリシーの代わりに特定のIAMユーザー、IAMロールを指定してS3へのアクション制御を行うことができる。
広範的な制御のバケットポリシー、オブジェクト単位でのACLに対して、特定のユーザー・ロールに合わせてチューニングできるのが差別点。
ただし、あくまでオブジェクトに対するアクション(オペレーション)の実行に対しての制御を行えるだけで、バケットの削除・変更、クロスレプリケーション等、アクセスポイントでは行えないことも多々ある。
参考: 互換性のある Amazon S3 オペレーションによるアクセスポイントの使用

フローとしては以下の通り

アクセスポイント作成
IPアドレス、Webサービスへのアクセス制限設定
VPCへのアクセス制限設定
アクセス管理の実行

また、エンドポイントとしての役割としてはTransfer accelerationというのものも存在する。
ユースケースとしては以下の通り。

さまざまな理由で、バケットに対して Transfer Acceleration を使用することが推奨されます。
一元化されたバケットに世界中のお客様がアップロードします。
大陸間で定期的にギガバイトからテラバイト単位のデータを転送する。
Amazon S3 にアップロードする際に、インターネット経由で利用可能な帯域幅を効果的に活用できていないと感じる場合。

Amazon S3 Transfer Acceleration を使用した高速かつ安全なファイル転送の設定

S3アクセスアナライザー

IAMにおけるアクセスアナライザーのS3版。
IAMアクセスアナライザーに連動して、バケットポリシー/ACLのモニタリングを行う他、パブリックアクセスを許可したバケット或いは他のAWSアカウントにバケットルール・ACL等で権限を付与しているバケットに対してのアクセスを分析してくれる。
簡潔に言うと、どのバケット・オブジェクトに対してどういったアクセスが許可されていて、実際にどのようなアクセスがされているのかを可視化する機能。
すべてのパブリックバケットと共有バケットのアクセス結果がわかるので、実際のアクセス状況を確認して想定した通りポリシーが設定されているか、機能しているか、不正なアクセスはないかというのを確認して
問題があれば対処をするといった使い方をする。
結果はIAMAccessAnalyzerへとパスされて、アーカイブにすることもできる。
性質的にはCloudTrail等がログ分析なのに対して、こちらはIAMAccessAnalyzerと同様にポリシーの適用状態を分析してセキュリティリスクを把握して、適切にポリシーを設定するのに使用する。

ライフサイクル管理

バケット内のオブジェクトは放っておくと無駄な課金対象となってしまう。
なので、S3 Intelligent-Treringと合わせてライフサイクル管理によってオブジェクト単位で保存するストレージクラスの変更、不要なデータの削除時期等を設定することで自動的に管理をするように
設定できる。
特徴としては

バケット全体やPrefixに設定する
オブジェクト更新日を基準として日単位で毎日0:00UTCに設定したキューが実行される
最大1000ルールまでライフサイクルを設定できる
IAなストレージに移せるオブジェクトのサイズは128KB以上から
MFA Deleteが有効だと設定できない

というものがある。

レプリケーション

リージョン間を跨いでバケットを作り、そこにトリガーに応じてオブジェクトを複製することで実行リージョンのS3に障害が起きた場合へのより強固な備えとする機能。
指定したバケットでオブジェクトの作成・更新・削除が行われた場合、レプリケーション先のバケットにも同期させるイメージ。
特徴としては

バージョニング機能を有効にしないと使えない
バケットはそれぞれ別のリージョンのものを指定する
一方向だけではなく、双方向なレプリケーションも可能
ただし、データ転送費用が別途発生する

ということが挙げられる。

バージョン管理

S3のEC2ImageBuilderのようにS3でもバージョン管理をすることでアーカイブのような形でバケットを管理することができる。
MacでいうとTimeMachineでのバックアップのようなもの。
ユースケースとしては誤って消してしまったデータをバージョンを戻すことで復元するといったものがある。
特徴としては

バージョン管理されるのはバケット
ただし、バージョン管理されたバケットのオブジェクトは参照可能
ライフサイクル管理で管理が可能(特性上、放置しておくと無限にバージョンが増えて保存容量を圧迫するので必須)
バージョン管理されているバケットを削除する場合は、古いバージョンの削除が別途必要になる

ということが挙げられる。

S3の利用状況を確認する意味

S3の分析をする意味

アクセス頻度の低いデータやデータの保存期間を確認して、ライフサイクルポリシーを適切に設定するため。

S3のイベント通知

バケット内のイベントの発生をトリガーにして、SNS/SQS/Lambdaに通知が設定できる・
例えば特定のイベントが確認できたらSNSを使ってメールで通知するようにしたり、Lambdaで特定の処理を実行するなどシステム連携をシームレスにできる。

S3のデータ解析

S3内のデータは必要に応じて検索や解析が行える。
用途によって以下の4つのサービスから選択する。

S3 Select(Glacier Select)

S3の内部機能として有している検索機能で、S3内で直接クエリを実行してデータを取得する。
GZIP圧縮データ、CSV、JSON形式のデータに対して実行可能

Amazon Athena

S3内のデータを簡単かつ直接分析できるようにする。
対話的にクエリを実行できるサービス。
例えばAthena SQLクエリでSageMaker機械学習モデルというものを呼び出して、機械学習による推論をさせることもできる。

Amazon Macie

機械学習によりS3の機密データを検出、分類、保護するフルマネージド型のサービス。
機密データの検出・調査のために利用する。

Amazon Redshift Spectrum

S3の格納データに対して、Redshiftから直接クエリを実行できる機能。
当然Amazon Redshiftを利用していることが前提。

メトリクスとStorage Lens

S3はバケットに対してメトリクスを作成するのでそのバケットの合計サイズやオブジェクトの合計数なのである程度のデータは自動で収集され可視化される他、自分でフィルターを作成してCloudWatch経由でバケットに対するリクエストをモニタリングすることもできる。
さらに、Storage Lensはリージョン、ストレージクラス、バケット、プレフィックス別のドリルダウン(データの集計レベルを１つずつ掘り下げて集計項目をさらに詳細にする操作のこと。またはその機能のこと。例えば、国別に見ていたデータを都道府県別に集計し直すみたいなこと。)を使用して、組織またはアカウントレベルでストレージの使用状況とアクティビティの傾向を可視化できる。
メトリクスと機能・目的としては似通っているが、バケット以外にもアカウント・AWSリージョン・ストレージクラスといったより大きな単位でのメトリクスを把握するというところで差別化される。

CORS(クロスオリジンリソースシェアリング)

特定のドメインにロードされたアプリケーションが異なるドメイン内のリソースと通信する方法を定義するのがこれ。
これだけだとよくわからないので例を挙げるとDjangoとReactをハイブリッドアーキテクトの構成で使わない場合、フロントとエンドではドメインが異なるので、
これを設定しないとフロントからのRequestがエンドで拒否されるアレのこと。

マルチパートアップロード

データ容量が大きいオブジェクトに対して分割してアップロードを行う機能。
特徴として

1~10000パートまで分割できる
1パートあたり5MB~5GBまで分割可能
最後はキリよくいかない可能性もあるので5MB以下になってもOK
アップロードが中止されるとパートデータが残ってしまう
ライフサイクル管理でパートデータは削除可能

バッチオペレーション

S3オブジェクトに対して一括処理を実行する機能。
以下2つに大別される。

ジョブ

バッチオペレージョンの基本単位となるもの。
これを作成しないとバッチオペレーションは実行できない。
オブジェクトのリストに対して指定された操作を実行するために必要な情報がすべて登録されている。
バッチオペレーションにオブジェクトのリストを渡した際に実行するアクションを指定することでオペレーションが実行できる。

マニフェスト

S3が作用するオブジェクトのキーをリストしているS3オブジェクト。
ジョブを実際に実行するためのオブジェクトという役割を持つ。

マニフェストオブジェクトキー
ETag
バージョンID

以上3点を指定して作成する。
インベントリレポートかCSVファイルのどちらかで設定することができる。

S3ユースケース色々

S3は用途からもアクセス制御の観点からも様々なユースケースが考えられる。
用途は先述の通り。
いくつかサービスの理解に必要だなと思うところを考えて列挙していく。

バージョニングに関して

参考: 絵で見て 3分でおさらいする Amazon S3 のバージョニングとライフサイクル
 参考: バージョニングが停止されたバケットへのオブジェクトの追加
S3はバケットに対してバージョニングの設定をすることができる。
EC2におけるEC2ImageBuilderでも同じような機能があったが、あちらは作成したAMIにおけるアレコレを自動で更新してバージョンを作る……といういわゆるOSにおけるバージョンのようなものだったのに対して、こちらはMacにおけるTimeCapsuleのようなバックアップ方式の使い方をする。
データをレストアする時、またはレプリケーションをする際には必須なので実務で使う場合は必ず設定することになるはずである。
ただし、以下を見ていくとわかるように更新や削除(バージョンごと削除する完全な削除以外)をやる度にオブジェクトが増えていくので、ストレージが圧迫されていくことに注意しないといけないのでこれを使う場合はライフサイクルの導入も必須になる。

仕組みとしてはバージョニングの設定をした以後にアップロードされたオブジェクトがあると自動的にバージョンを作り、以後更新があるたびにバージョンが作られる。
バージョンにはステータスとして

・null(デフォルト、バージョニングが有効ではない状態)
・有効

の2種類があり、それとは別にバージョニングの状態に

・停止

のというものがある。
バージョニングは一度有効化すると無効にはできないので、停止という処置を取ることになる。
バージョニングの停止をすると、削除マーカーに関わらず新規で追加されるオブジェクトのバージョンIDがnullとなる。
既存の現行バージョンのオブジェクトのIDがnullだった場合、再度上書きされnullとなるが、nullでない場合は新しく追加されたものが現行のものになりIDはnullが割当られるが、既存のバージョンに関してはIDの繰り下げが行われる。
例を挙げるとバージョン2とバージョン1が存在している場合は、新規追加するとnullのものが現行バージョンとなり、バージョン2と1はそれぞれ1世代、2世代前になる。
つまり、このことからバージョニングを停止してもバージョンの構成は維持されたままとなることがわかり、それ故にバージョンの無効ではなく停止と呼ばれる。

レストアのケースとしては以下2パターンが考えられる。
また以下で言及している通り、削除マーカーを削除することでレストアはできるがバージョン自体(バージョンIDが振られてる奴)を削除してしまうとそのバージョンのレストアは不可能になる。
なので、IAMでユーザーに対してMFAを設定して二重認証にしたように必要であれば、バージョンの削除に対してもMFAを設定することで事故を予防することもできる。

現行バージョンのレストア

バージョニングを有効にしたあとに追加されたオブジェクトは削除されると削除マーカーが作成される。
なので現行バージョンを削除してしまった場合は、バージョンのリストから削除マーカーを削除すればレストアできる。

過去バージョンのレストア

これはバージョンの項目から任意の数新しいIDのものを削除していけばレストアできる。
また、単純な方法としては該当するバージョンと同じ内容のファイルをアップロードすれば同じことができる。

ライフサイクルに関して

ライフサイクルを利用する目的としては大まかに以下の2つになると思うのでこれを掘り下げてみる。

・オブジェクトの定期的な削除のスケジューリング(Cloud Trailで証跡を作った場合やバージョニングを行っていた場合は不要なバージョンの削除など)
・オブジェクトを保存しているストレージクラスの変更

Intelligent Tiering Archiveと合わせてオブジェクトのストレージクラスを適切に管理したい

Intelligent Tiering Archiveと合わせてオブジェクトを任意のストレージクラスに移行させることができる。
ただし、移行にはコストがかかり、アーカイブへと移行すると当然取り出すときには時間もかかる上に取り出し料金もかかることに注意しないといけない。
ケースとしては以下の通り。

オブジェクトの現行バージョンのストレージクラスを変更する

クラスごとに日数を設定して、その日数を超えるたびに下位のクラスへと移行させることができる。
当然、現状のクラスより下位のクラスからしか選択できず、日数の設定も下位のクラスに行くに従って日数は長くなる。
例を挙げると現行ストレージがSTANDARDだった場合は

オブジェクトが作成されてから60日後にSTANDARD-IAへと移行する
オブジェクトが作成されてから180日後にGlacierへと移行する
オブジェクトが作成されてから360日後にGlacier Deep Archiveへと移行する

といった具合に遷移させることもできる。

現行バージョンではないオブジェクトのストレージクラスを変更する

基本的には同上となるが移行するストレージの選択にインテリジェントな階層という項目が追加される。
これを選ぶとIntelligent Tiering へと移行される。
Intelligent Tieringは高頻度アクセス層と低頻度アクセス層とに分かれていて、どちらもSTANDARDと同等の低レイテンシーが提供される。
Intelligent Tiering自体は高頻度アクセス層のデータに30日アクセスがないとそのデータは低頻度に自動的に移行され、再度アクセスがあった場合は高頻度へ戻されるという仕組みで性能の影響なく、運用のオーバーヘッドもなく、データ取り出しのための料金もなく、利用料金を節約する仕組みである。
ただし、STANDARD-IAよりは高くなるのでデータのアクセスが予測できるかできないかで使い分けをする。
参考: 新機能- Intelligent TieringによるAmazon S3の自動的なコスト最適化

Intelligent Tiering Archiveを利用する場合

バケット内のオブジェクト全て、あるいはオブジェクト単位(スコープを設定することができる)から設定できる。
Intelligent Tieringとは別物……というより、それのArchive版というような機能になる。
前者がSTANDARDと同等の性能の高頻度アクセス層と低頻度アクセス層に分かれているのに対して、後者はGlacier及びGlacier Deep Archiveと同じストレージにアーカイブを作ることになる。
Archive Access階層(=Glacier)は最低でもオブジェクト作成から90日、Deep Archive Access(=Glacier Deep Archive )だと180日以降でないと設定できない。

オブジェクトの削除について

削除のライフサイクルに関しては以下の3パターンが設定できる。

オブジェクトの現行バージョンの有効期限を設定して、期限が過ぎると過去のバージョンにする
オブジェクトの過去のバージョンに有効期限を設定して、期限が過ぎたら完全に削除する(MFA設定している場合は設定できない)
バーションニングされていないオブジェクトの場合は有効期限を設定した場合、過ぎたら削除する
期限切れの削除マーカーまたは不完全なマルチパートアップロードを削除する

S3のアクセス制御について

個々については前述の通りなのでユースケースだけ列挙してみる。

前提

IAMにおけるユーザーポリシーでS3へのアクセス権限をIAMユーザー、及びロールに付与するかしないかで制御

バケットポリシー

バケットへの一元的な制御を行いたい場合はこれで制御する。

ACL

オブジェクト単位での制御を行いたい場合はこちらも設定しないといけない。
特にパブリックアクセスの有効に関してはバケットに対して有効にしても、該当のオブジェクトが有効になってないとアウトになるケースがある(静的ホスティング機能など)

クロスアカウントアクセスを許可したい

以下の3パターンがある。

S3へのアクセスポリシーを持った外部アカウントのユーザーまたはロールをIDやメールアドレスでバケットポリシー設定で指定して許可する
ACLの場合でも同上
IAMロールで権限移譲をしてそもそもコンソール自体へのアクセス、及びプログラムによるアクセスを可能にする

なおクロスアカウントアクセスを許可しているバケットでオブジェクトを追加した場合、特に設定していない場合はアップロードしたアカウントに所有権があることになる。
こうなるとバケットの所有権を持っているユーザーなのに、当該オブジェクトに対しては権限を持たないというねじれが発生してしまうのでそれを解消しないといけない場合がある。
任意の所有者に変更したい場合はアクセス管理から変更を行う。

外部アクセスに関して

以下の3パターンがある。

署名付きURLを発行する
アクセスポイントを設定する(実行できるアクションは限られるが特定のIAMユーザー、IAMロールに合わせてチューニングするということもできる)
バケット・オブジェクトへのパブリックアクセスを許可した上で適切にポリシー・ACLを設定する
オンプレミス環境と接続したい場合はAWS Storage GateWayを使う(後述)
Snowballというコンテナ型の物理ストレージデバイスを利用する(大規模データ移行を迅速に行いたい場合、Snowballにインポートしてからデータセンターへ配送することで時短できる)

AWS Storage Gateway

オンプレミス環境とAWSストレージを接続するサービス。
堅牢性・低コスト・拡張性を備えたクラウドストレージというS3の利点をオンプレ環境から利用でき、ファイル共有とデータへの低レイテンシーアクセスを実現できるところに利点がある。
モニタリング・管理・アクセス制御等々も普通にS3を利用するのと同じように扱えることも利点。

ユースケースとしては

ビックデータ処理・クラウドバースティング(コンピューティングリソースの需要が極端に高まったピーク時（バースト）に、処理をクラウド上のリソースに迅速に切り替えることを可能にするもの。内部リソースで需要を満たすのが難しいときや、企業ネットワーク内の容量が上限に達したときなどに行われる。)・システム移行のためのデータをAWSストレージへ移行する
オンプレ環境のデータのバックアップ・アーカイブ化・災害対策を目的としてAWSにデータを保持したい
オンプレミス環境でAWSストレージを活用したい

ということが挙げられる。
利用する目的やデータタイプによって以下の4つからゲートウェイを選択する。

ファイルゲートウェイ

オンプレミスのファイルデータをS3上にオブジェクトとして格納する。
特徴としては以下の通り。

仮想アプライアンス(仮想化技術を用いて、特定用途のアプリケーションソフトが稼働する環境を即座に構成できるようにしたもの。仮想マシン（VM）のイメージファイルなどとして提供される)でNFSv3/V4.1のインターフェースが提供される
更新データは非同期でAWSに転送される
ファイルとオブジェクトのマッピングは1:1
S3のライフサイクルポリシー、バージョニング、クロスレプリケーション等の機能がそのまま使える

ボリュームゲートウェイ

オンプレミス環境のディスクデータをSnapshotとしてS3に取得し、Disaster Recovery(地震や津波などの天災や、テロ、不正侵入などによりシステムが壊滅的な状況になった際に復旧・修復すること、また、その災害に備えたシステムや体制を指します)を実現するゲートウェイ。
特徴としては以下の通り。

iSCSI(IPネットワークを利用してSAN（Storage Area Network）を構築するプロトコル規格)でブロックストレージとしてインターフェースを提供する
オンプレミスのローカルディスクのバックアップを自動的にAWS側で実施している
更新データは非同期でAWSに転送される
オンプレミス側のStorage Gatewayへとリストアすることができる。
AWSのEBSへとリストアすることもできる

テープゲートウェイ

Storage Gatewayを仮想テープライブラリとして利用することで堅牢性の高い外部保管バックアップストレージを実現する。
前2つのゲートウェイよりもより長期かつ低頻度のデータに対して利用する。
特徴としては以下の通り。

VTL(Virtual Tape Library)対応バックアップソフトウェアを利用して、Storage Gatewayを経由して、バックアップデータをS3及びGlacierに格納する
オンプレミス及びAWSのEC2環境でも利用できる
バックアップソフトウェアによりテープ取り出しオペレーションを行うことで、Glacierを利用することができる
主要なバックアップソフトウェアをサポートしている

FSx File Gateway

オンプレミスからAmazon FSx for WindowsへのSMBプロトコルによる接続を可能にするゲートウェイ。
2021年4月に一般提供が始まった新入り。
特徴としては以下の通り。

オンプレから低レイテンシーでアクセス可能かつ、オンプレ側にキャッシュを残すことができる
ファイルゲートウェイと比べてファイルへのアクセスをより細かく制御できる。
SMBを使用しているNASストレージをオンプレミスから移行するときに検討される

EC2でS3に保存されているファイルへアクセスしたい

サービス間同士のアクセス制御になるのでIAMロールの出番となる。
EC2インスタンスを作成したらIAMロールを作って、そこにS3へのアクセスポリシーを付与し、それをEC2インスタンスに適用する。
あとはバケットポリシーやACL等をそのロールに対して設定する。

静的Webホスティング

バックエンドの処理を必要としない程度のページであればこの機能でデプロイすることができる。(LP等)
単純にバケットをエンドポイントとし、それをWebアドレスとしてホスティングすることもできし、リクエストに対して別のバケットやドメイン、プロトコルを指定してそちらにリダイレクトすることもできる。
静的Webサイトホスティング目的で使う場合はバケットを混在しないように必ず専用のバケットを作成する。
また、当然利用にはパブリックアクセスの解放が必要なのでその設定とそれに合わせてポリシー等のアクセス制御の設定を行わないといけない。

レプリケーション

可用性とバージョニングと合わせてデータロスト対策として使用する。
レプリケーションルールを設定して運用することになり、レプリケーション先に複数のルールが存在する場合はルールに優先順位をつける。
他のルールと同様、プレフィックスを用いてレプリケーションするオブジェクトをフィルタリングすることもできる。
レプリケーション先のバケットは別アカウントのものも指定できる。
また、バケット間アクセスを許可するのにIAMロールが必要になる(自作のものがなければAWS側がルール作成の際に自動で作成)
ルールを作った時点ではレプリケーションは行われていないので別途レプリケーション元とレプリケーション先とでバケットの構成を等しくしないといけないことに注意する（CLI経由でバケットの中身をコピーするのが1番確実）
双方向でレプリケーションする場合はレプリケーション先のレプリケーションルールでレプリケーション元のバケットを指定してやればいい(ただし、これをやるとレプリケーション先のバケットに変更があった場合、レプリケーション元のバケットにもそれが反映されることになるので、レプリケーション元のデータの完全性・可用性を担保するという目的からは外れたものになってしまうことに注意)

Glacier

最後にGlacierを見てみる。
中長期的なデータの保存として使われるS3の各ストレージクラスよりもさらに長期……つまりアーカイブとして扱うデータを保存する場合はGlacierの利用を検討する。
特徴としては以下の通り。

オブジェクトではなく、アーカイブとして保存される
1アーカイブの最大容量は40TB
保存可能なアーカイブ数とデータ量に制限はない
アーカイブ作成時に一意のIDを割り当てられ、アーカイブは以後更新できない(更新したい場合はもう一度アーカイブとして保存し直す必要がある)
バケットではなく、ボールドと呼ばれるコンテナに保存される(1アカウント1000ボールドまで)
ボールド(S3ではバケット)、アーカイブ(S3ではオブジェクト)、ジョブ(アーカイブに対してのSELECTクエリやGETクエリ等々……アーカイブの取得やインベントリの取得のなどクエリの実行単位を指す)、通知設定(ジョブの完了には時間がかかるので終了したら通知するように設定しないと不便)で成り立っている
前述の通り、ライフサイクルルールを用いてS3ストレージのデータをスケジューリングしてアーカイブ化することができる
Advanced Encryption Standard(AES)256ビット対象鍵を使用してデフォルトで自動的に暗号化される
直接アップロード・取得という処理ができないのでライフサイクル経由かプログラム処理が必要になる
データ取り出しに時間とコストがよりかかる
90日の最低保持期間を過ぎないとアーカイブが削除できない
認証保護のために、必ず全リクエストに署名が必要になる
課金対象は容量あたりの料金は最安クラスだが、取り出し及び取り出しのリクエストに対しても1件ずつ課金対象となる(プロビジョニングタイプのボールドを利用している場合はさらにオプション料みたいなのが上乗せされる)。S3と同じくデータ転送のうちインは無料だが、アウトは月1GB以降は有料。

アーカイブ化から保存・取得までは以下のフロー。

データが高速でアーカイブ化される
アーカイブは低速でボールドに保存される
ジョブを実行することでアーカイブが取得される

アクセス管理もS3と似たような感じで以下の通り。

前提としてS3アクセス権限を持つIAMポリシーをIAMユーザーやロールに付与
バケットポリシーにあたる、ボールドポリシーでボールド全体に一元的にアクセス管理を行う。
データ取り出しポリシーでデータを取り出す量を管理する。取り出し時にコストが一番かかるので、無料枠内で収めるか超えることが想定される場合は最大取得率を設定することで、取り出し速度をより制限して、コストの上限を設けることができる
ボールドロックポリシーはバケットでもあった変更を完全に禁止することができるポリシー

ボールドにおけるデータの取り出し方のタイプは以下の通り。

迅速

取り出しが一番早いタイプになる。
アーカイブの中でも必要時にいち早く使用可能にしたいものはこれを選択するがそれでも1~5分かかる。

プロビジョニングキャパシティ

厳密には迅速のオプションみたいなもので、迅速でのデータ取り出しを行うときに事前に取得容量を設定した上で予約しておくことで必要時に取り出しを保証する機能

標準

デフォルトはこちら。
アーカイブのアクセスに数時間かかる。

大容量

アーカイブの取得に1日以内(実際は5~12時間程度)もかかるが代わりに取り出し料金が一番安い。
取得する際にアーカイブの量が膨大であることが考えられる場合はこちらを選択しておく。

Glacier Deep Archive

データ取り出しタイプとはちょっと違うがこちらに記載。
通常のGlacierよりさらにデータの取得に時間がかかる代わりにさらに安価に利用できるストレージ。
耐久性はS3と同等だが、デフォルトで12時間も取得にかかる上に大容量取り出しの場合は2日以内となる。

S3ハンズオン

バケットの作成

作成したバケットの概要

プロパティ

アクセス管理

メトリクス

バケット管理

アクセスポイント

バケットにファイル等をアップロードする

オブジェクトの概要

オブジェクトのパブリックアクセスの許可

バージョニングの設定

オブジェクトは公開アクションでACL設定におけるパブリックアクセスの許可を手軽に行う事ができる。

アップロード時のオブジェクトにパブリックアクセスしてみた結果。

バージョンを有効にした上で内容を変更してアップロードすると以下の通り変化する。

もちろん、先程のも以前のバージョンとして保持されていることが以下の通りわかる。

バージョンのリストは以下のように表示され、削除マーカーを削除するとレストアできることが確認できる。

Intelligent Tiering Archive

プレフィックスはここだけじゃなく、各種ルール等でも設定してフィルタリングに使える。

サーバーアクセスログ周り

イベント通知

Transfer Acceleration

リクエスタ支払い

静的Webホスティング

ライフサイクルルール

CLI周り

VScodeを使っているのでAWS Toolkit for Visual Studio Codeも合わせて導入。

Windows での AWS CLI バージョン 2 のインストール、更新、およびアンインストール
 AWS Toolkit for Visual Studio Code

以下を選択して、アカウントのアクセスキーとシークレットキーを指示に従って設定する。

あとはリージョンを選べば各サービスへとアクセスができる。
S3にも既存のバケットが確認でき、バケットの追加やオブジェクトのアップロード削除が行える。
ただし、クロスレプリケーション等の設定等は行えないのでそういうのは正規のCLIで行う。

クロスレプリケーション

まずは異なるリージョン同士でバケットを作る。

以上のように各種ルールを設定すると以下のようにレプリケーションされる。
(すでにファイルやフォルダ等がアップロードされているバケットの場合は、前述の通り必ずCLIでcpコマンド等実行するなどして、バケットの構成を同じにしておく)

新しくレプリケーション元でフォルダを作ると

レプリケーション先でも反映される。

CLIでバケットの作成や削除を行う

バケットの削除は空にしてからじゃないとできないこともあるので以上のようにエラーが出る場合もある。
その場合はrmコマンドを実行してからrbコマンドを実行する。

クロスアカウント周り

オブジェクトの所有者の変更

ACL設定

クロスアカウントのCLI操作

インベントリ

アクセスポイントの設定

メトリクス