Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
【AWSのログ周りを整理する】第4回 貯める ── コストの大半はここで 決まる
Search
赤神青空
PRO
September 18, 2026
Programming
14
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
【AWSのログ周りを整理する】第4回 貯める ── コストの大半はここで 決まる
赤神青空
PRO
September 18, 2026
More Decks by 赤神青空
See All by 赤神青空
【AWSのログ周りを整理する】第5回 調べる ── 貯めたログに問い合わせる
akagami
PRO
0
14
【AWSのログ周りを整理する】第3回 運ぶ ── 発生源と置き場のあいだ
akagami
PRO
0
11
【AWSのログ周りを整理する】第2回 出す ── ログはどこで生まれるか
akagami
PRO
0
19
【AWSのログ周りを整理する】全体像 ── 4段に分けて 位置づける
akagami
PRO
0
20
【ORM不要論の歴史】で、AIは新しい根拠なのか
akagami
PRO
0
32
【ORM不要論の歴史】反論と、噛み合わなさの正体
akagami
PRO
0
44
【ORM不要論の歴史】2026年の不要論は何を言っているのか
akagami
PRO
0
34
【ORM不要論の歴史】運用の問題は、いまの責務論に直結する
akagami
PRO
0
22
【ORM不要論の歴史】なぜ生まれ、20年前に何を言われたか
akagami
PRO
0
28
Other Decks in Programming
See All in Programming
thread_parallel_with_free-threaded_Python_and_NumPy.pdf
riku_sakamoto
0
340
AI Agent時代のリアーキテクチャ戦略と実践
hokaccha
9
4.6k
数年滞っていたダークモード対応をおよそ2週間で完了させる
chigichan24
0
710
Family mrubyの進捗
kishima
1
120
フロントエンドUIフレームワークのこれまでとこれから
ssssota
5
2.8k
Jetpack Compose メカニズム
skydoves
0
430
wkhtmltopdfの次どうするか問題2026
willnet
1
430
TiDB Cloudのカスタムコントローラーによるオートスケール対応
takaidohigasi
0
120
SREの越境 / SRE Collaboration
y0hgi
1
200
AIを上手に使っていこうとしたら越境せざるを得なくなった話 〜実践1年で見えた境界を越えなければならない理由と進め方〜 / Crossing borders with AI
tomoyakitaura
4
1.2k
そのリトライ、死んだコネクションを使い回していませんか ── GoのHTTPクライアントとHTTP/2を実プロダクト障害から学び直す
myus4a
0
140
アクセシビリティから考える情報設計
high_g_engineer
0
380
Featured
See All Featured
Code Review Best Practice
trishagee
74
20k
Exploring anti-patterns in Rails
aemeredith
4
510
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.7k
Darren the Foodie - Storyboard
khoart
PRO
4
3.9k
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
490
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
2
2.1k
Building Adaptive Systems
keathley
44
3.2k
Speed Design
sergeychernyshev
33
2.1k
SEO for Brand Visibility & Recognition
aleyda
0
4.7k
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
290
Six Lessons from altMBA
skipperchong
29
4.5k
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
460
Transcript
2026年9月 AWSのログ周りを整理する 第4回 貯める ── コストの大半はここで決まる 赤神青空
▪全6回のうち、今回は第4回 このシリーズの地図 第1回 全体像 第2回 出す 第3回 運ぶ 第4回 貯める
第5回 調べる 第6回 選び方 今ココ はじめに 4段に分けて位置づける ログはどこで生まれるか 発生源と置き場のあいだ コストの大半はここで決まる 貯めたログに問い合わせる 結局どう決めるのか 2/10
▪課金の軸がそれぞれ違う 保管の3択 CloudWatch Logs Amazon S そのまま検索できる 課⾦の軸 ‧取り込み $0.50/GB
‧保管 $0.03/GB‧⽉ ‧クエリはスキャン量 向いている⽤途 直近の障害調査 OpenSearch Service 安いが検索基盤が要る 課⾦の軸 ‧保管 $0.023/GB‧⽉ ‧Athena $ /TBスキャン ‧列指向+パーティション 向いている⽤途 数ヶ⽉前を掘る 速いが常時課⾦ 課⾦の軸 ‧インスタンス稼働時間 ‧ストレージ従量 ‧zero-ETLでS も参照 向いている⽤途 常時ダッシュボード 価格は⽶国東部の例。リージョンと時期で変わる 置き場の設計が、そのままコスト設計になる 今ココ 貯める 3/10
▪CloudWatch ログクラスの使い分け Logs ── 違うのは取り込み単価だけ Standard 取り込み $0.50/GB メトリクスフィルタが使える Live
Tail・ファセットが使える サブスクリプションフィルタ可 Infrequent Access 取り込み $0.25/GB Logs Insights は使える Live Tail・ファセットは不可 サブスクリプションフィルタ不可 保管料とクエリ料は両クラス同じ。作成後にクラスは変更できません。 今ココ 貯める 4/10
▪S3 ──S3に置くときの作法 ここを外すと安くなりません 「S3に逃がせば安い」は置き方を間違えると成り立たない。 日付でパーティションを切る Parquetなどの列指向形式に変換する 小さなファイルを大量に作らない ライフサイクルで古いものを寒いクラスへ落とす 今ココ 貯める
5/10
▪S3 ──S3 Tables 統合 ETLなしで分析基盤へ渡す Icebergテーブルとして出せるので、ETLを組まずにSQLへ渡せる。 CloudWatch側の設定だけでテーブルが作られる AthenaやIceberg互換のエンジンから引ける 連携先のストレージ料金はかからない 複雑なSQLが必要になった時点で足せばよい
今ココ 貯める 6/10
▪CloudWatch Intelligent Tiering Logs ── 2026年7月の自動階層化 Standard 取り込み直後‧ 最近触ったログ 30⽇
Infrequent Access 90⽇ 30⽇アクセスが なかったログ Archive Instant Access 90⽇アクセスが なかったログ 古いデータに触ると⾃動でStandardへ戻る(30⽇間) どの層にあってもクエリの体験は変わらない。有効化はアカウント単位‧リージョン単位 触らないログが自動で安い層へ落ちていく 今ココ 貯める 7/10
▪3択の外にある監査専用の置き場 セキュリティ用途の置き場 Security Lake 自アカウントのS3に貯まる OCSF形式に自動で正規化 他社製品のログも混ぜられる OpenSearchから直接引ける CloudTrail Lake
監査イベントに特化している 内蔵のSQLエンジンで引ける 保持は最長10年まで設定できる 2026年5月で新規受付を終了 CloudTrail Lake はこれから新規に使い始めることはできません。 今ココ 貯める 8/10
▪SecuritySecurity Lake の集まり方 Lake ── 形式を揃えてから貯める 複数アカウント / リージョン CloudTrail
VPC Flow Logs 引く側 OpenSearch AWS Cloud zero-ETLで直接クエリ Security Lake ⾃分のS に貯まる Athena SQLで掘る OCSF 形式に⾃動で正規化 AWS WAF Parquet で保存される サードパーティSIEM 購読して取り込む 他社製品‧オンプレ 形式が揃うので、AWSのログと他社製品のログを同じクエリで⾒られる 集める時点で形式を揃えるのがこのサービスの役割 今ココ 貯める 9/10
▪第4回で覚えて帰るのは3つ まとめ 01 置き場は3択、課金軸が違う 監査用途には Security Lake という別枠もある。 02 CloudWatch
Logs は自動で安くなる クラスは作成時に固定。階層化は有効化するだけ。 03 S3 は置き方しだい パーティションとParquet。S3 Tables で分析へ直結。 次回は「調べる」── 貯めたログへの問い合わせ方を見ていきます 今ココ おわりに 10/10