開発者ガイドを全部読んで大事かなーって所だけピックアップして書き出した。ちゃんとドキュメントはここを読んだほうがいいよ
- 1オブジェクト~5TB変わらず
- 1回のオペレーションでアップロードできるサイズ5GB（超える場合はマルチパートアップロード。100MBからマルチパート使ったほうがよい）
- 分割したパーツは最大10,000個
- SOAP for HTTPは廃止済み、HTTPSは使えるけど非推奨。SOAP用にS3機能は開発しないのでREST APIかAWS SDK使ってね
- オブジェクト
- キー（名前）とバージョンIDによってバケット内で一意に識別される
- オブジェクトデータ
- データ部分をS3から見ることは出来ない
- メタデータ
- オブジェクトを表現する名前と値のペアのセット and more...
- PUTリクエストヘッダーのサイズは8KBに制限されている
- システムメタデータ
- システム的に必要なデータ。多くはAWSが自動で設定しユーザーは操作不可（日付など）
- ユーザー定義メタデータ
- カスタムメタデータ、PUTリクエストヘッダー内では2KBに制限
- キーと値の各ペアをUTF-8にエンコードしたバイト数に合計=2KB以下
- x-amz-meta-で開始する必要あり
- リージョン
- 明示的に別リージョンを選ばない限りリージョンを勝手にデータが動くことはないよ
- PUTなどの動作に関して
- 変更に関しては、S3内でレプリケーションされているからちょっと時間かかる
- 古いデータが表示されることあり
- 削除に関しても上記と同じ
- 削除したのに一覧で見た時表示されるなど
- オブジェクトのロックをサポートしていない
- 同じキーに対して2つのPUTリクエストが行われた場合、最新のタイムスタンプを持つリクエストが優先される
- 読み込みと書き込みに整合性が必要であればアプリ側で実装しなければいけない
- RRS(低冗長性ストレージ）
- 通常のディスクドライブの400倍の堅牢性を提供
- 年間99.99%のオブジェクト耐久性
- 年間平均予測オブジェクト喪失率 0.01%
- バケットポリシー
- ポリシーはバケット内のすべて（または一部）のオブジェクトに対して影響出来る
- ARNやワイルドカードも利用可能
- バケット所有者のみが設定可能
- バケット、オブジェクトに対しての動作
- 誰から
- 条件
- IPアドレス、CIDRでのIPアドレス範囲、日付、ユーザーエージェント、HTTP Referrer,トランスポート(HTTP/HTTPS)など
- でもIAM使うといいかも
- 一時的なセキュリティ認証情報を扱うSecurity Token Service(STS)もあるよ
- 一時的なアクセスキー(access key/secrect key)とセキュリティートークンを返す
- APIについて
- SOAPじゃなくてREST使ってね
- SOAPではバージョニングをサポートしてない
- REST API
- HTTPに追加機能がある（ACLをサポートするヘッダーなどを追加）
- 標準HTTP書式の使用法に合致するように頑張ったよ
- 料金
- 使った分だよ as always!
- EC2, EMR, Import/ExportにもS3がよく出てくるから一緒にドキュメント読むといいじゃない？
- エンドポイント
- サンプルスクリプトは Java, .NET, PHP, Rubyのようだ
- バケットの仮想ホスティング？
- ウェブサイト機能のようだ
- Hostヘッダーにどこまで含むかはリクエストするURIにも影響するからリージョンを意識しよう
- HTTPでREST API利用時のみ
- 以前のバージョンのS3はHTTPのHostヘッダーを不正に無視していた
- リダイレクトについて
- 全HTTPリクエストヘッダーがリダイレクトリクエストに適切に含まれている事
- 非GETリダイレクトが正常動作しているか確認
- 大きなPUTリクエストがリダイレクトに従っているか確認
- 100-continueレスポンス が届くまで時間がかかる場合はPUTリクエストがリダイレクトに従っているか確認
- PUTに対して100-continueを利用するようにアプリ側で設定
- バケットについて
- リージョンを指定しないでバケットを作ると米国東部（バージニア北部）リージョンになるよ
- バケットのドメインは以下のパターン
- http://bucket.s3.amazonaws.com
- http://s3.amazonaws.com/bucket
- http://bucket.s3-aws-region.amazonaws.com
- http://s3-aws-region.amazonaws.com/bucket
- http://bucket.s3-website-aws-region.amazonawscom (静的ウェブ)
- http://bucket.s3-website.aws-region.amazonaws.com (静的ウェブ)
- 設定オプション（サブリソースと呼ばれるらしい）
- ライフサイクル
- Standard_IAからStandardもしくはRRSへの移行はサポートされてない
- Glacierから他のストレージクラスには移行出来ない
- RRSに移行出来ない
- MFAが有効なバケットではライフサイクル設定はサポートされてない
- ログ設定が有効な場合オブジェクトの移動、削除などはレコードに記載される
- 日付は翌日の午前00:00(UTC)にくるめられて、実行される
- オブジェクトの作成日は翌日の00:00として見なされ実行日がその日付からプラスされて実行される
- website
- バージョニング
- バケット単位の有効設定
- MFAをバケットに対して設定することで削除を制御する
- 有効に出来るのはバケット所有者のみ
- バージョニング無効には出来ない、停止のみ
- PolicyとACL
- Cross-Origin Resource Sharing(CORS)
- ロギング
- タグ付け
- ロケーション
- 通知
- バージョン
- リクエスタ支払い
- データ転送量をリクエスタが支払う仕組み
- 有効にすると匿名アクセス、BitTorrent, SOAPが利用不可
- Amazon DevPayを使ってバケットに格納されたコンテンツを販売出来る
- 制約
- 1AWSアカウントについき最大100個のバケット作成可能。制限緩和で上限を増やすことが可能
- バケットの所有権は譲渡不可、バケットが空の場合は削除可能。
- バケット内に別のバケットを作ることは出来ない
- バケット作成時命名の衝突が起こらないようにアプリで実装する
- 命名規則
- DNS命名規則に準拠する
- 米国東部（バージニア北部）除く
- AWSコンソールを使うと、自動でDNS準拠になる
- 3~63文字
- ピリオド利用可能、小文字の英文字、数字、ハイフン
- 先頭および末尾は小文字の英数字
- IPアドレスは不可
- バケットにピリオドを入れるとSSLワイルドカード証明書対応ができなくなるので、使うの止めよう
- 米国東部ルール
- 最長255文字、大文字、小文字、数字、ピリオド、ハイフン、アンダースコア利用可能だがよろしくないのでDNS命名規則使おう
- AWS S3コンソールは100,000までのオブジェクトがあるバケットを削除出来るらしい。それ以上ある場合はSDK使って削除してね
- ライフサイクル設定をしてバケットもしくはオブジェクトを削除する
- S3には階層がない
- オブジェクトに関して
- 命名ガイドライン
- キー名にUTF-8文字利用可能
- 英数字、特殊文字にしておくと何かとよい
- 特殊文字をキー名に使う場合は16進数としてURL encodeが必要かもしれないので気をつけて
- "&", "$", "@", "=", ";", ":", "+", ",","?"
- 0x0000(NULL)~0x001F(US)までの範囲と、0x007F(DEL)
- 使わないで
- "\","{","^","}","`","[","]",">","<","#","|","~",表示不可なASCII文字
- オブジェクトのサブリソース（設定）
- ACL
- Torrent
- BitTorrentプロトコルをサポートしている
- 削除について
- ライフサイクルでの有効期限超えをすると削除キーに追加して非同期的に削除する
- 日付
- 作成日は最終更新日（バージョン管理していても最新の更新日）
- S3内でコピーを取る場合
- 1回のアトミックコピーは最大5GB。超える場合はマルチパートアップロードを使ってコピーする
- GETに関して
- 1回のリクエストによるデータの複数範囲取得はサポートされてない
- ストレージの種類
- スタンダード(通常のS3)用
- 少頻度アクセス(Standard IA)用
- 128KB以上の大規模オブジェクト、30日間以上入れておく（イメージは月額課金みたいな感じ）、料金もS3とは違うので要確認
- アーカイブ(a.k.a. Glacier)用
- 取り出しに時間かかる、いつでもアクセス出来るわけではない
- 低冗長化ストレージ(RRS)
- 堅牢性と可用性
- スタンダード= 99.999999999%, 99.99%
- 少頻度アクセス=上に同じ, 99,9%
- Glacier=上に同じ, 99.99%
- RRS=99.99%, 99.99%
- Glacierについて
- オブジェクト1個にあたり、S3での名前とメタデータ用に8KBのストレージを利用する
- 保存して3ヶ月位以上アーカイブしている場合は削除は無料
- 3ヶ月未満で削除または上書きする場合はS3による早期削除料金が課金される👀
- 復元するまで大体4時間（3〜5時間）
- CORSについて
- AllowedOriginとAllowedMethod、オプションとしてAllowedHeader, ExposedHeader, MaxAgeSecondsをXMLにて設定
- 署名付きオブジェクトURLにつちて
- オブジェクトの所有者はオプションで独自のセキュリティ証明書を利用し、ダウンロードさせる為の期限付き許可を与える事が可能
- セキュリティ証明書と、バケット名、オブジェクト名を指定する必要があり
- HTTPメソッド(GET)と有効期限も指定する必要
- 署名付きURLを受け取った相手は誰でもそのオブジェクトにアクセス出来る
- オブジェクトをアップロードする場合は、元々のURIに対して実行出来る権限を持っている必要がある
- アクセス権限について 再度確認
- アクセスポリシー、ユーザーポリシー、リソースベースポリシー（バケットポリシー、バケットACL、オブジェクトACL)全てを評価してリクエストを許可するか決定する
- IAMユーザーの場合、自分の所属するAWSアカウントからの許可、リソース所有者からの許可が必要
- 評価の順番 図がある
- ユーザーコンテキスト
- 親アカウントのポリシー評価
- リソース所有者が親の場合リソースポリシー（バケットポリシー、バケットACL、オブジェクトACL)も同時に評価
- バケットコンテキスト
- 所有者アカウントのポリシーを評価
- 明示的に拒否セットがあるか確認
- オブジェクトコンテキスト
- 所有者のポリシーのサブセットの評価する
- データの保護
- チェックサム
- チェックサムを利用してデータの保全性を定期的に検証している
- ネットワークの全トラフィックに対してチェックサムを計算してデータパケットの損傷を検出している
- 暗号化
- バケットポリシーで暗号化していないオブジェクトをアップロードさせないなど可能
- サーバー側
- SSE-S3(AES-256)
- 署名付きURLを使って更新されたオブジェクトはSSE-S3で暗号化するかを強要する事は出来ない
- AWS KMS
- ヘッダーがBase64 encoded JSONなら好きな値をセット可能。CloudTrailログに残るので機密情報は入れない
- SSE-C(顧客が用意したキー）
- 暗号化キーはAWS側では保存しないが、ランダムなSALT値が付加された暗号化キーのHMAC値を保存している。
- HTTPSのみ受け付ける
- 署名済みURLを作成時に署名計算の為にアルゴリズムを指定する必要がある
- クライアント側
- AWS KMSで管理されているカスタマーマスターキーを利用
- クライアント側のマスターキーを利用
- バージョン管理
- バージョンIDはURLセーフ、バージョンIDは一意の値をAWSが付与する
- バージョン数取得はディフォルト1,000個
- 削除に関して
- MFA Deleteが有効の場合は、バケット所有者はリクエストにx-amz-mfaリクエストヘッダを入れる。HTTPS
- ヘッダーの値は、認証デバイスのシリアル番号、スペース、認証デバイスに表示される認証コードの連結文字
- 削除マーカー
- 削除マーカーの削除
- 以前のバージョンの復元
- オブジェクトを戻したいオブジェクトで上書きする
- オブジェクトの最新バージョンを削除する
- アクセス許可
- アクセス許可はバージョンレベルで設定出来る
- オブジェク所有者はWSアカウント
- 静的ウェブサイト
- インデックスは、ルートドメインとサブフォルダーへのリクエストのみ
- 4XXのエラーのときは独自のエラードキュメントを返す事が可能
- 全てのリクエストをリダイレクト
- 条件付きリダイレクト
- 特定のオブジェクトキー名、プレフィックス、レスポンスコード
- x-amz-website-redirect-location
- イベントの通知
- イベント
- 新しいオブジェクト作成
- オブジェクト削除
- RRSオブジェクト消失
- 宛先
- SNSトピック
- SQSキュー
- Lambda
- クロスリージョンレプリケーション
- 異なるAWSリージョンにあるバケット間でオブジェクトを自動で非同期でコピー
- 全てのオブジェクト、もしくは特定のキー名のプレフィックスが付いた一部のオブジェクトなど
- コピー先のバケットは完全コピーになる
- 同じキー名、メタデータ
- SSLで転送される
- オリジナルバケットとレプリケーション先のバケット両方でバージョニングを有効にする必要がある
- 違うリージョンであるhチウ用がる
- N対Nの関係。N対複数のレプリケーションは出来ない
- レプリケーション出来るように権限付与が必要。IAM Role使うとよい
- オリジナル/レプリケーション先のバケット所有者、オブジェクト所有者での権限が正しく設定されていること
- レプリケーションされないもの
- レプリケーション設定が追加される前に存在するオブジェクトは遡ってレプリケーションしない（バージョン管理の関係と思われる）
- SSE-CのキーとSSE-KMSのキーを使って暗号化されたオブジェクトはレプリケーションしない
- バケットレベルのサブリソースの更新はレプリケーションされない
- ライフサイクル設定で実行されたアクションはレプリケーションされない
- 同じにしたければ両方のバケットでライフサイクル設定が必要
- 元のバケットが実は別のバケットからのレプリケーションされたバケットだった場合、オリジナルになれない
- 確認する時はx-amz-replication-statusヘッダー
- pending, completed, failed
- レプリケーション設定を削除してからバージョニング無効化
- レプリケーション先のバケットでバージョニングを無効にするとレプリケーションが停止する
- バケットのロギングが有効の場合、ログオブジェクトもレプリケートする
- パフォーマンスの最適化（想定は毎秒100回のリクエスト）
- 毎秒100回PUT/LIST/DELETEまたは毎秒300回GETリクエストをする場合はちゃんとこのガイドラインに従う
- 毎秒300回PUT/LIST/DELETEまたは毎秒800回GETリクエストが予測される場合はサポートに問い合わせをする
- 前訳したこれ http://blog.serverworks.co.jp/tech/2012/08/10/best-practices-for-using-amazon-s3/
- GET多かったらCloudFront使って
- CloudWatchで確認
- バケットのサイズとオブジェクトの数はメトリックスとして取得出来る
- CloudTrailでもS3操作のログが残るよ
- DevPay http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/UsingDevPay.html