0
1

More than 1 year has passed since last update.

S3のライフサイクルルールの設定

Posted at

:raised_hand: 前置き

本編ではないので読み飛ばしちゃって大丈夫です。

:smile: 使用しているWAFサービス

現在の案件ではWAFとしてWafCharmという製品を使っていて、
毎月のレポートでサービスへの攻撃状況を把握しています。
WafCharmはメールでサポートに連絡すると割とすぐに返信があるのでサポートもしっかりとしている印象。

:fearful: 問題点

ただ、月次のレポートでは、
「攻撃が多いIPアドレス」「攻撃が多い国」「ヒットしたBlockルール」のTOP10はわかるが、
そこから「攻撃が多かったIPアドレスがどんなBlockルールにヒットしたのか」
などはWafCharm上では解析出来ないのが私としては少し残念なところ。

どうしたらレポートの詳細がわかるのかとサポート様に確認したところ、
詳細はAWS WAFのWAFログを見れば良いということだった。

そこでS3に貯めていたWAFログをAthenaで確認しようと思ったら、
Glacierに移行する期間を30日間に設定していたため、
先月分のログを確認しようと思ったら月初のログの確認ができなかった。
:point_up:というわけで、WAFログをGlacierに移行するまでの期間を60日に伸ばすことにしました。

:spy: 本編(S3の設定)

:writing_hand: バケットのライフサイクルルールの変更

設定の変更は私のように調べながら対応したエンジニアでも簡単だったが、
注意点もあったので設定方法を記載しながら触れていきます。
1.png
まずは、S3の画面で対象のバケットを選んで管理タブをクリックし、
対象のライフサイクルルールを選択して編集ボタンをクリック。
(新たに作る場合は「ライフサイクルルールを作成する」ですね)

:writing_hand: ルールのスコープ

注意点の一つとしてスコープがあります。
ライフサイクルルールは複数設定できるので、
バケット内のログの種類ごとにルールを設定出来ますが、
「すべてのオブジェクトに適用]というルールを作成しているとルール同士が競合することもあります。

その場合、一応決まりはあるので挙動の予想は出来ますが、
実際どれが有効になっているかは動かしてみないとわからないです。

:ear_tone2:参考)
例 5: 重複するフィルター、競合するライフサイクルアクション、Amazon S3 がバージョン管理されていないバケットに対して行うこと

一般的に、S3 ライフサイクルはコストに合わせて最適化されます。たとえば、2 つの有効期限ポリシーが重複している場合は、短い有効期限ポリシーが適用されるため、データが予想よりも長く保存されることはありません。

:writing_hand: すべてのオブジェクトに適用

2_全てに適用される.png
↑ちゃんと注意書きも出るので親切ですね。

:writing_hand: フィルターを使用してスコープを制限

私は特定のフォルダ配下のログのみに適用したいので、
3_2_オブジェクト.png
下記のようにプレフィックスを指定しました。
3_プレフィックス指定.png
ここでの注意点としては、
プレフィックスの最後に「/」を付けないとうまく動かないようですので忘れずに付けてください。
:v_tone2:例を見ればわかったのですが私は付け忘れました。。

:writing_hand: オブジェクトサイズ

こちらは指定しなくても問題ないと思いますが、
小さいオブジェクトをGlaicerに移行すると不要なコストが発生するようなので設定しました。
4_オブジェクトサイズ指定.png
なぜ40KBに設定したかというと、
下記のリンク先にGlacierに移行する際にS3に8KB+32KBのメタデータを作成すると記載があったので、
40KB以下のファイルだと
「40KBのメタデータ + Glacierのファイル」でむしろGlacierにした方がコスト高いじゃん」
と思い設定しました。(理解が間違えていたら教えて欲しいです)

:ear_tone2:参考)
Amazon S3 ライフサイクルオブジェクトを Amazon S3 Glacier に移行する方法と Amazon S3 Glacier アーカイブを管理する方法の比較

S3 Glacier または S3 Glacier Deep Archive にアーカイブするオブジェクトごとに、Amazon S3 ではオブジェクト名やその他のメタデータに 8 KB のストレージを使用します。

また、Amazon S3 Glacier または S3 Glacier Deep Archive ストレージクラスにアーカイブされたオブジェクトごとに、インデックスおよび関連するメタデータ用に 32 KB のストレージが追加されています。

ちなみにここら辺の内容は、
Glacierに移行する期間を設定するエリアでも注意書きがありました。(後述)

:writing_hand: Glacierに移行するまでの期間を設定

私の場合はここの日数が30日だったので、今回は60日に変更しました。
5_Glacierに移行.png
小さいオブジェクトをGlacierにするとコストが増えるかもよ、と注意書きがありますね。

:writing_hand: 削除期限の設定

最後にオブジェクト作成後の日数というところで、Glacierからも削除する期限を設定します。
6_最後の確認.png
ちなみに有効期限ですが90日間より短い場合は料金が発生するようです。
私はとりあえず変更なしのままとしました。(例でキャプチャした値が365ではない謎:rolling_eyes:)

:ear_tone2:参考)
最小ストレージ期間料金

S3 Glacier ストレージにあった期間が 90 日未満のオブジェクトを失効させるライフサイクル有効期限ルールを作成すると、90 日間の料金が発生します。

コストに関する考慮事項

Amazon S3 Glacier にアーカイブされているデータの削除は、削除するオブジェクトが最小ストレージ期間より長い期間アーカイブされている場合は無料です。

:writing_hand: 動作確認

後は翌日になってルール通り動いているかを確認するだけです。
40KBのルールでGlacierになってない?など確認誤りに気をつけてください。
(ルール通りなのにここで悩んだりしていました、、愚か)

:raised_hand_tone3: 終わり

後は来月、再来月のWafCharmレポートを見て、
ログの分析をするだけです。

まだ気づいていない設定ミスなどもあると思いますので、
何かあれば追記します。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1