Intelligent-TieringでS3コスト削減に挑戦した話

# はじめに

S3バケットのコスト削減策として昨年末頃よりIntelligent-Tieringを導入し、経過観察を行ってきました。
本記事ではその過程について書きたいと思います。

# Intelligent-Tieringとは

BlackBelt「[Amazon Simple Storage Service (Amazon S3) コスト最適化編](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-S3-CostOptimization_0602_v1.pdf)」より引用します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3333262/72a5fbc3-d990-e101-0592-09cdaff544e9.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3333262/49096209-2fbe-aba5-bdb7-70568af499f0.png)


詳細についてはドキュメントをご参照ください。

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/intelligent-tiering-overview.html

# 課題

とあるシステムにてAWS WAFのログをS3標準ストレージクラスに1年間保存する設定となっていました。
その他のS3バケットに比べログ量が多く、AWSコストも目立つものとなっており、コストを削減できないかと考えました。

なお、S3ストレージサイズの確認にはStorage Lens（[参考](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/storage_lens_basics_metrics_recommendations.html)）を利用しました。
利用の仕方によっては課金されますが、無料のデフォルトダッシュボード`default-account-dashboard`があり、こちらだけでもいろんなインサイトを得ることができて有用です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3333262/9ed254a6-e681-246c-0a95-c0f1c3881ef5.png)

# ストレージクラスの検討

WAFログについて調べたところ下記のことがわかりました。

**ログの利用状況**
- ログ保存開始後1年以上が経過
- ログ参照頻度は年間で数回程度
- 3か月以上前のログを参照したことはこれまでの実績上は無い
- 3か月以上前のログを参照する必要が生じた場合、取り出しに時間がかかる点（※）を許容できる

※Intelligent-Tieringのアーカイブデータ取得に要する時間については [こちら](https://docs.aws.amazon.com/AmazonS3/latest/userguide/restoring-objects-retrieval-options.html) をご参照ください。


**ログファイルあたりのサイズ**
- 128KBより大きい

いずれかのGlaicerのストレージクラスに移行させるのも一つの手ですが、今回は、取り出し（※）やアクセス階層間の移動にコストがかからないIntelligent-Tieringの採用について検討してみることにしました。

※例外として「アーカイブアクセス、迅速」の場合だけコストがかかります。

# Intelligent-Tieringの設計
最短で一つ下層のストレージクラスに移行する設計としました。

| 保管月数 | アクセス階層 |
|:--|:--|
| 0日～1か月前 | 高頻度アクセス階層 |
| 1～3か月前 | 低頻度アクセス階層 |
| 3～6か月前 | アーカイブアクセス階層 |
| 6～12か月前 | ディープアーカイブアクセス階層 |

:::note warn
- WAFのログ（[Vended Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html)）をS3に出力する際のストレージクラスは選択できず、標準ストレージクラスとなります。そのためS3へのオブジェクト格納直後にIntelligent-Tieringへの移行が必要となり、その分はコストがかかってしまいます。
- アーカイブアクセス階層、ディープアーカイブアクセス階層はデータの取り出しに時間がかかります。（[参考](https://docs.aws.amazon.com/AmazonS3/latest/userguide/restoring-objects-retrieval-options.html)）
:::



**Vended Logsのストレージクラスが選択できるようになると大変ありがたいのですが・・・この声が届きますように:pray_tone2:**


# コスト試算

下記のような方法でコストを試算しました。
No1-2が、基準とする実際のメトリクスの値ですが、実際の数値はお見せできないため、**一例として仮の値を設定**しています。
単価は東京リージョンのものです。
|No|項目|計算式|値|単位|
|:-:|:-|:-|-:|:-|
|1|合計オブジェクト数|CloudWatchメトリクス`NumberOfObjects`から確認|1,000,000|件|
|2|月当たりのログ量 GB|CloudWatchメトリクス`StandardStorage` / 12か月 で算出|100|GB|
|3|標準ストレージを利用した場合の月次コスト|0.0250 USD/月 × 12 か月 × 100 GB/月|**30.0000**|USD/月|
|4|高頻度アクセス階層の月次コスト|0.0250 USD/月 × 1 か月 × 100 GB/月|2.5000|USD/月|
|5|低頻度アクセス階層の月次コスト|0.0138 USD/月 × 2 か月 × 100 GB/月|2.7600|USD/月|
|6|アーカイブアクセス階層の月次コスト|0.0045 USD/月 × 3 か月 × 100 GB/月|1.3500|USD/月|
|7|ディープアーカイブアクセス階層の月次コスト|0.0020 USD/月 × 6 か月 × 100 GB/月|1.2000|USD/月|
|8|モニタリングおよびオートメーションの月次コスト|0.0025 USD(1,000件あたり) × 1,000,000 件 / 1,000件|2.5000|USD/月|
|9|ライフサイクル移行の月次コスト|0.0100 USD(1,000件あたり) × 1,000,000 件/ 12 か月 / 1,000件|0.8333|USD/月|
|10|Intelligent-Tieringを利用した場合の月次コスト|4～9の合計|**11.1433**|USD/月|

No3が標準ストレージ、No10がIntelligent-Tieringのコストです。
こちらの試算結果より、想定しているユースケースに対しては、**Intelligent-Tieringを利用することでコスト削減できる**と判断しました。

※S3料金の詳細については [こちら](https://aws.amazon.com/jp/s3/pricing/) をご参照ください。

# 導入

設定手順の詳細については割愛いたします。
詳細については下記ドキュメントをご参照ください。

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/using-intelligent-tiering.html#enable-auto-archiving-int-tiering

# 結果

## アクセス階層の遷移状況

まずはアクセス階層の遷移をCloudWatchメトリクスから見ていきます。
下記は`BucketSizeBytes`メトリクスの推移を`StorageType`ディメンションごとに線で表示したものです。
アクセス階層が変化していっていることが読み取れます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3333262/fcff6593-36a1-c42d-2fae-074863db9e0a.png)


## アクセス階層割合の遷移状況

下記は各`StorageType`ディメンションの合算値の遷移を表示したものです。
`StorageType`の割合が変化していっていることが読み取れます。（アクセス数の増加等が要因となりログの総量は増える傾向にあります）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3333262/16610149-9894-5011-e443-03531f8dca01.png)


グラフに表示されている各`StorageType`の意味は下記のとおりです。（[参考](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/metrics-dimensions.html#s3-cloudwatch-dimensions)）

| StorageType | 説明 |
|:-|:-|
| StandardStorage  | STANDARD ストレージクラスのオブジェクトに使用されているバイト数 |
| IntelligentTiering**FA**Storage | INTELLIGENT_TIERING ストレージクラスの`高頻度アクセス階層`のオブジェクトに使用されているバイト数 |
| IntelligentTiering**IA**Storage | INTELLIGENT_TIERING ストレージクラスの`低頻度アクセス層階`のオブジェクトに使用されているバイト数 |
| IntelligentTiering**AIA**Storage  | INTELLIGENT_TIERING ストレージクラスの`アーカイブインスタントアクセス階層`のオブジェクトに使用されているバイト数 |
| IntelligentTiering**AA**Storage  | INTELLIGENT_TIERING ストレージクラスの`アーカイブアクセス階層`にあるオブジェクトに使用されているバイト数 |
| IntelligentTiering**DAA**Storage | INTELLIGENT_TIERING ストレージクラスの`ディープアーカイブアクセス階層`にあるオブジェクトに使用されているバイト数 |
| Int**AA**S3ObjectOverhead  | ・INTELLIGENT_TIERING ストレージクラスの`アーカイブアクセス階層`の各オブジェクトごとに8KB追加されるメタデータ用ストレージのバイト数<br>・オブジェクトの名前とその他のメタデータを保管<br>・S3 標準料金が課金される |
| Int**AA**ObjectOverhead | ・INTELLIGENT_TIERING ストレージクラスの`アーカイブアクセス階層`の各オブジェクトごとに32KB追加されるメタデータ用ストレージのバイト数<br>・インデックスと関連メタデータを保管<br>・S3 Glacier Flexible Retrieval 料金が課金される |
| Int**DAA**S3ObjectOverhead  | ・INTELLIGENT_TIERING ストレージクラスの`ディープアーカイブアクセス階層`の各オブジェクトごとに8KB追加されるメタデータ用ストレージのバイト数<br>・オブジェクトの名前とその他のメタデータを保管<br>・S3 標準料金が課金される |
| Int**DAA**ObjectOverhead | ・INTELLIGENT_TIERING ストレージクラスの`ディープアーカイブアクセス階層`の各オブジェクトごとに32KB追加されるメタデータ用ストレージのバイト数<br>・インデックスと関連メタデータを保管<br>・Glacier Deep Archive ストレージ料金が課金される |

## AWSコストの遷移状況

AWSコストの遷移は下記のとおりです。
Intelligent-Tieringへのライフサイクル設定を入れた12月に既存オブジェクトすべてがIntelligent-Tieringに移行されたため、`Rquests-Tier4`のコストが跳ね上がってしまいましたが、翌月から下がり始め、**3～4か月後に標準ストレージのままだった場合よりコストを下げることができました**。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3333262/451d909e-2403-59b5-344d-e194c4814a39.png)


グラフに表示されている各使用タイプの意味は下記のとおりです。（[参考](https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/aws-usage-report-understand.html)）

| 使用タイプ | 説明 |
|:-|:-|
| TimedStorage-INT-**FA**-ByteHrs | INTELLIGENT_TIERING ストレージクラスの`高頻度アクセス階層`に保存されたデータの GB-月の数 |
| TimedStorage-INT-**IA**-ByteHrs | INTELLIGENT_TIERING ストレージクラスの`低頻度アクセス階層`に保存されたデータの GB-月の数 |
| Monitoring-Automation-INT | INTELLIGENT_TIERING ストレージクラスの監視および自動階層化された一意のオブジェクトの数 |
| Requests-Tier4 | S3 Glacier Flexible Retrieval、S3 Intelligent-Tiering、S3 Standard-IA、または S3 One Zone-IA ストレージへのライフサイクル移行数 |
| TimedStorage-INT-AA-ByteHrs | INTELLIGENT_TIERING ストレージクラスの`アーカイブアクセス階層`に保存されたデータの GB-月の数 |
| TimedStorage-INT-DAA-ByteHrs | INTELLIGENT_TIERING ストレージクラスの`ディープアーカイブアクセス階層`に保存されたデータの GB-月の数 |

# さいごに

結果としてはIntelligent-Tieringを利用することでコスト削減に成功することができました:moneybag:
ただし、コストを考慮したS3ストレージクラスの選択は考慮ポイントが多く、事前に厳密な試算をすることは困難なため、単純にコストを削減するためだけであれば、より最適な選択肢は他にあったかもしれません。
本記事がIntelligent-Tieringの一つの実用例として、どなたかの参考になれば幸いです。


# 弊社では一緒に働く仲間を募集中です！
現在、様々な職種を募集しております。
カジュアル面談も可能ですので、ご連絡お待ちしております！

募集内容等詳細は、是非採用サイトをご確認ください。

https://engineer.po-holdings.co.jp/