EC2フリートからメモリ、ディスク、プロセスに関するメトリクスを収集します。デフォルトのCloudWatchメトリクスにはこれらが含まれていません。
→SSM Distributorまたは`AmazonCloudWatch-ManageAgent` Run Command経由でCloudWatchエージェントをインストールします。Parameter Storeからエージェント構成をプッシュします。
理由: メモリとディスクはゲストOSのメトリクスであり、ハイパーバイザーからは見えません。デフォルトのCWメトリクスは、EBSレイヤーでのCPU/ネットワーク/ディスクIOのみです。
リファレンス↗
アプリケーションがビジネスKPI(例:1分あたりの注文数)をCloudWatchに公開する必要があります。
→カスタム名前空間とディメンションを持つ`PutMetricData` APIを使用します。大容量の使用にはEmbedded Metric Format (EMF) を使用します。構造化されたJSONをログに書き込むと、CWがメトリクスを自動的に抽出します。
リファレンス↗
高カーディナリティのカスタムメトリクスのコストを削減します。
→Embedded Metric Format (EMF) を使用します。構造化されたイベントを一度ログに記録すると、CWがそこからメトリクスを抽出します。1つのログと1つのメトリクスは、ディメンションの組み合わせごとに個別の`PutMetricData`呼び出しを行うよりも安価です。
リファレンス↗
トラフィックに日次/週次の季節性があるため、静的しきい値アラームが誤検知を生成します。
→CloudWatch異常検出アラームを使用します。バンドは学習された季節性に基づいて適応し、メトリクスがバンドから外れるとアラームが発報します。
理由: 季節性のワークロードは正常な変動幅が大きいため、固定しきい値は半分は間違っています。
リファレンス↗
エラー率が高いANDトラフィックが低い場合の両方でオンコールに通知し、どちらか一方だけが発報した場合は通知しないようにします。
→ルール式`ALARM(errors) AND ALARM(low_traffic)`を持つ複合アラームを使用します。基盤となるアラームは個別に発報しますが、複合アラームのみがSNSに通知します。
リファレンス↗
`ERROR uid=123`のようなログ行をCloudWatchメトリクスに変換してアラームを設定します。
→CloudWatch Logsメトリクスフィルター — パターン`ERROR`でメトリクスをインクリメントします。その後、そのメトリクスにアラームを作成します。
理由: フィルターはログ取り込み時に評価されるため、別途パースパイプラインは不要です。
リファレンス↗
過去1時間以内に多数のログストリームで5xxエラーを引き起こしている上位10個のIPを検索します。
→CloudWatch Logs Insightsクエリ: `fields @timestamp, @message | filter @message like /5\d\d/ | stats count() by clientIp | sort count desc | limit 10`。
リファレンス↗
ロググループの保持期間がデフォルトで「期限なし」になっており、費用が増加しています。
→ロググループごとに保持期間(1日~10年)を設定します。`aws logs put-retention-policy`または新しいグループを自動修復するAWS Configルールを介して適用します。
リファレンス↗
50のアカウントからのログを1つの中央セキュリティアカウントに集約します。
→各ソースロググループでサブスクリプションフィルターを設定し、中央アカウントのKinesis Data StreamsまたはFirehoseに送ります。メトリクスとトレースにはCloudWatchクロスアカウントオブザーバビリティを使用します。
リファレンス↗
低コストで長期的なログアーカイブを作成します。
→ロググループをKinesis Firehose → S3にサブスクライブし、Glacierへのライフサイクル移行を設定します。または、スケジュールされた`CreateExportTask`を直接S3に実行します。
理由: Firehoseは継続的であり、ExportTaskはオンデマンドの一括エクスポートです。S3 + GlacierはCW Logsストレージよりも100倍安価です。
リファレンス↗
IAMアクセス権のないAWS以外の契約者と運用ダッシュボードを共有します。
→CloudWatch Dashboard Sharing — パブリック共有リンク(Cognitoによる認証付き)または匿名(特定のダッシュボードにロック)を使用します。
リファレンス↗
EC2インスタンスが`stopped`状態になったときにLambdaをトリガーします。
→イベントパターン`{"source":["aws.ec2"],"detail-type":["EC2 Instance State-change Notification"],"detail":{"state":["stopped"]}}`を持つEventBridgeルール → Lambdaターゲット。
リファレンス↗
AWSがRDSインスタンスの予定メンテナンスを発表したときに、自動的にチケットを作成します。
→AWS Health → EventBridgeデフォルトバス → LambdaまたはSNS → チケットシステム。`source: aws.health`と影響を受けるリソースでフィルタリングします。
リファレンス↗
顧客が苦情を言う前に、公開ウェブサイトが404エラーを返すことを検出します。
→CloudWatch Synthetics canary — 1分ごとにスクリプト化されたブラウザアクセスを実行し、失敗時にスクリーンショットを撮り、失敗した実行でアラームを発報します。
リファレンス↗
実際のユーザーからのブラウザ側ページロード時間とJavaScriptエラーを測定します。
→CloudWatch RUM。ページ上のスニペットがパフォーマンスとエラーデータを送信します。バックエンド相関のためにX-Rayと組み合わせます。
リファレンス↗
すべてのインスタンスでCloudWatchを手動で確認することなく、EC2フリートを適切なサイズに調整します。
→AWS Compute Optimizer — CWメトリクスとメモリデータ(エージェントを使用)を分析し、インスタンスタイプ変更を推奨します。EC2、ASG、EBS、Lambda、ECS Fargateに対応しています。
リファレンス↗
200のアカウント全体で「すべてのEBSボリュームで保存時の暗号化が有効になっているか」を確認します。
→マルチアカウントマルチリージョン承認を持つAWS Configアグリゲーター。アグリゲーターダッシュボードと高度なクエリ (SQL)。
リファレンス↗
非準拠のリソースを自動修正します(例:暗号化されていないEBSボリューム → スナップショット+暗号化して再作成)。
→AWS Configルール + SSM Automation Runbookを介した自動修復アクション。再試行回数とパラメータを指定します。
リファレンス↗
カスタムスクリプトを書くことなく、コスト削減の機会とセキュリティリスクを表面化します。
→AWS Trusted Advisor。コスト / パフォーマンス / セキュリティ / 耐障害性 / サービス制限のチェック。完全なチェックセットにはビジネスまたはエンタープライズサポートが必要です。
リファレンス↗
今後のローンチのために、リージョンでEC2 vCPUクォータを引き上げる必要があります。
→Service Quotasコンソール — クォータ増加をリクエストします。またはService Quotas APIを使用してスクリプト化します。一部のクォータは自動承認され、その他はサポートを経由します。
リファレンス↗
月次請求書が届く前に予期せぬコストスパイクをキャッチします。
→AWS Cost Anomaly Detection — MLベース。サービス / リンクされたアカウント / コストカテゴリごとにモニターを設定します。SNSまたはEメールでアラートを送信します。
リファレンス↗
月次予算がしきい値を超えた場合、非本番EC2を自動停止します。
→AWS Budgetsアクション — しきい値に達した際に、タグ付けされたインスタンスを停止するか、IAM経由でdeny-all SCPを適用するSSM Automationを実行します。
リファレンス↗