【コスト最適化の5原則】 ① 使わないものは削除 ・不要なリソースを定期的に棚卸し ・開発環境、テスト環境の放置を防ぐ ② 適切なサイズを選ぶ ・過剰なスペックを避ける ・負荷テストで適正サイズを見極める ③ コミット割引を活用 ・長期利用なら割引プランを使う ・RI（リザーブドインスタンス）、コミットメント ④ 効率的な設計 ・パーティション、クラスタリング ・必要なカラムだけSELECT ⑤ 継続的な監視 ・コストを可視化 ・アラート設定で異常を検知

【RIの3つの支払いオプション】 ┌─────────────────────────────────────────────────────────┐ │ ① 全額前払い（All Upfront） │ ├─────────────────────────────────────────────────────────┤ │ ・契約時に全額を一括払い │ │ ・割引率が最大（例：75%割引） │ │ ・キャッシュに余裕がある場合に最適 │ │ │ │ 例：3年契約の場合 │ │ 　 オンデマンド: $180/月 × 36ヶ月 = $6,480 │ │ 　 全額前払い: $1,620（一括）= 75%割引 │ └─────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────┐ │ ② 一部前払い（Partial Upfront） │ ├─────────────────────────────────────────────────────────┤ │ ・契約時に半額程度を前払い + 月額払い │ │ ・割引率は中程度（例：65%割引） │ │ ・バランスの取れた選択 │ │ │ │ 例：3年契約の場合 │ │ 　 前払い: $1,000 + 月額$17 × 36ヶ月 = $1,612 │ │ 　 合計約$2,612 = 約60%割引 │ └─────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────┐ │ ③ 前払いなし（No Upfront） │ ├─────────────────────────────────────────────────────────┤ │ ・前払いなし、毎月払い │ │ ・割引率は最小（例：40%割引） │ │ ・初期投資を抑えたい場合に │ │ │ │ 例：1年契約の場合 │ │ 　 月額$108 × 12ヶ月 = $1,296 │ │ 　 オンデマンド$180 × 12 = $2,160 → 約40%割引 │ └─────────────────────────────────────────────────────────┘ 【選び方の判断基準】 ・キャッシュに余裕あり → 全額前払い ・バランス重視 → 一部前払い ・初期投資を抑えたい → 前払いなし（または Savings Plans）

【どのストレージクラスを選ぶ？】 Q1: このデータに毎日アクセスする？ ├─ YES → Standard └─ NO ↓ Q2: 月に1回以上アクセスする？ ├─ YES → Standard-IA └─ NO ↓ Q3: 年に数回アクセスする？ ├─ YES → Glacier Instant Retrieval └─ NO ↓ Q4: ほぼアクセスしないが保存義務がある？ ├─ YES → Glacier Deep Archive └─ NO → 削除を検討！ 【迷ったら…】 ・アクセス頻度が予測できない → Intelligent-Tiering （自動で最適なクラスに移動してくれる） ・最初はStandardで、30日後に自動移行 （ライフサイクルポリシーで設定）

【Lambda関数の各部分を理解しよう】 def lambda_handler(event, context): │ │ │ │ │ └── context: Lambda実行環境の情報 │ │ ・残り実行時間 │ │ ・メモリ制限 │ │ ・リクエストID など │ │ │ └── event: トリガーからの入力データ │ ・EventBridgeの場合: スケジュール情報 │ ・API Gatewayの場合: HTTPリクエスト │ ・S3の場合: アップロードされたファイル情報 │ └── lambda_handler: AWSが呼び出す関数名（固定） ┌─────────────────────────────────────────────────────────┐ │ redshift = boto3.client(‘redshift’) │ ├─────────────────────────────────────────────────────────┤ │ Redshiftサービスのクライアントを作成 │ │ ・boto3 = AWSのPython SDK │ │ ・client(‘サービス名’) でそのサービスを操作できる │ │ ・Lambdaの実行ロールに権限が必要 │ │ （redshift:PauseCluster, redshift:ResumeCluster） │ └─────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────┐ │ redshift.pause_cluster(ClusterIdentifier=’…’) │ ├─────────────────────────────────────────────────────────┤ │ Redshiftクラスタを一時停止 │ │ ・ClusterIdentifier: 停止するクラスタの名前 │ │ ・AWSコンソールのRedshiftで確認できる │ │ ・停止中は課金されない（ストレージ料金のみ） │ │ ・再開には数分かかる │ │ │ │ 対になる関数: │ │ redshift.resume_cluster(ClusterIdentifier=’…’) │ │ → クラスタを再開 │ └─────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────┐ │ return {‘statusCode’: 200, ‘body’: ‘Cluster paused’} │ ├─────────────────────────────────────────────────────────┤ │ Lambda関数の戻り値 │ │ ・statusCode: HTTPステータスコード（200=成功） │ │ ・body: 処理結果のメッセージ │ │ ・API Gateway経由の場合はHTTPレスポンスになる │ │ ・EventBridgeの場合は記録用（CloudWatch Logsに出力） │ └─────────────────────────────────────────────────────────┘

【Cron式の読み方】 cron(0 9 ? * MON-FRI *) │ │ │ │ │ │ │ │ │ │ │ └── 年（* = 毎年） │ │ │ │ └── 曜日（MON-FRI = 月〜金） │ │ │ └── 月（* = 毎月） │ │ └── 日（? = 指定なし、曜日を使う場合） │ └── 時（9 = 9時 UTC） └── 分（0 = 0分） 【日本時間に変換】 ⚠️ EventBridgeはUTC（協定世界時）で動作！ 日本時間 = UTC + 9時間 したがって: ・cron(0 9 ? * MON-FRI *) = UTC 9:00 = 日本時間 18:00 ・cron(0 0 ? * MON-FRI *) = UTC 0:00 = 日本時間 9:00 【設定例】 ┌─────────────────────────────────────────────────────────┐ │ 毎日18:00（日本時間）に停止 │ │ cron(0 9 ? * MON-FRI *) │ ├─────────────────────────────────────────────────────────┤ │ 毎日9:00（日本時間）に再開 │ │ cron(0 0 ? * MON-FRI *) │ └─────────────────────────────────────────────────────────┘ 💡 日本の業務時間（9:00-18:00）に合わせた設定

【BigQueryコスト削減チェックリスト】 ① SELECT * を避ける ❌ SELECT * FROM sales ✅ SELECT order_id, amount FROM sales → 必要なカラムだけ指定で90%削減も ② パーティションプルーニング ❌ WHERE order_date > ‘2024-01-01’（曖昧） ✅ WHERE DATE(order_date) = ‘2024-01-15’（日付指定） → パーティションで絞り込み ③ クラスタリング活用 よく WHERE や GROUP BY で使うカラムでクラスタリング → 類似データがまとまり、スキャン量削減 ④ マテリアライズドビュー 頻繁な集計クエリを事前計算して保存 → 毎回計算せず、保存結果を参照 ⑤ BI Engine ダッシュボードをメモリキャッシュ → 同じクエリの繰り返しを削減

【実施内容】 ① RI 3年契約（全額前払い）を購入 ・$400 → $120（70%割引） ・常時稼働が必要な本番環境に適用 ② 夜間・週末の自動停止（開発環境） ・CloudWatch Events + Lambda で自動化 ・平日9時〜18時のみ稼働 ③ クラスタサイズの見直し ・CPU/メモリ使用率を確認 ・過剰なら小さいノードタイプに変更 【結果】 $400 → $120（70%削減）

【実施内容】 ① ライフサイクルポリシーの設定 ・30日後 → Standard-IA（50%削減） ・90日後 → Glacier Instant（80%削減） ・1年後 → Glacier Deep Archive（95%削減） ② 不要なデータの削除 ・開発テスト用の古いデータ ・重複しているバックアップ ③ データ保持ポリシーの見直し ・7年後に自動削除（法令要件に合わせて） 【結果】 $230 → $100（57%削減）

【実施内容】 ① DPU数を削減 ・10 DPU → 5 DPU ・処理時間が少し増えるが許容範囲 ② 実行頻度の見直し ・週1回で十分なものを日次から変更 ・リアルタイム性が不要なジョブを整理 ③ ジョブブックマークの活用 ・増分処理で実行時間を短縮 ・毎回全件処理 → 差分のみ処理 【結果】 $150 → $100（33%削減）

【実施内容】 ① 保持期間を短縮 ・90日 → 30日（本番環境） ・7日 → 3日（開発環境） ② 不要なログストリームを削除 ・古い開発環境のログ ・使っていないサービスのログ ③ ログレベルを調整 ・DEBUG → INFO以上のみ出力 ・詳細ログは必要な時だけ有効化 【結果】 $50 → $30（40%削減）

【実施内容】 ① リージョン統一 ・すべてのリソースを同一リージョン（東京）に ・リージョン間転送料金を削減 ② VPCエンドポイント ・S3へのアクセスを内部通信に変更 ・インターネット経由の転送料金を削減 ③ データ圧縮 ・転送前にgzip圧縮 ・Parquet形式でカラム圧縮 【結果】 $100 → $80（20%削減）

【毎月1日にチェックすること】 □ コスト推移の確認 ・前月比で増減をチェック ・予算との差異を確認 □ 大きな支出の特定 ・どのサービスが高いか ・急に増えたサービスはないか □ 未使用リソースの削除 ・放置されたEC2、S3 ・使っていないスナップショット □ RI/コミットメントの見直し ・利用率をチェック（80%以上が目安） ・更新時期の確認 □ 新しい最適化手法 ・AWSやGCPの新機能をキャッチアップ ・より安いオプションがないか