手動監査の罠：なぜクラウドスプロールが生産性を低下させるのか
クラウドインフラストラクチャの拡張スピードは、チームの追跡能力を上回ります。ある週は10個のEC2インスタンスを管理していたと思えば、次の週にはAWS、Azure、GCPにまたがる数百ものアカウントに組織が急拡大している、といった具合です。
私は、シニアDevOpsエンジニアが金曜日の全時間を費やして、暗号化されていないS3バケットを探したり、数ヶ月前に忘れ去られた「ゾンビ」ディスクを削除したりする姿を見てきました. AWSの1TBのgp3ボリュームが放置されているだけで、何もしていないのに月額約80ドルかかります。これが10リージョンで50ボリュームあれば、毎月4,000ドルをデジタルのゴミに費やしていることになります。
この摩擦の主な原因は、集約され自動化された強制力の欠如にあります。エンジニアに50ページの「ベストプラクティス」PDFを暗記させるのは、失敗への近道です. ヒューマンエラーは避けられません。コントロールを維持するには、これらのガイドラインを実行可能なコードに変換する必要があります。ここで、Cloud Custodian (c7n) が最も価値のあるDevOpsツールとなります。
クイックスタート：5分で最初のポリシーをデプロイする
Cloud Custodianは、YAMLを使用してインフラストラクチャポリシーを定義するオープンソースのルールエンジンです。非常に軽量で、実行のために大規模なサーバークラスターを管理する必要はありません。ローカルのノートPCや基本的なCI/CDランナーがあれば十分です。
1. インストール
Cloud CustodianはPythonベースであるため、仮想環境（venv）を使用してワークスペースをクリーンに保つのが最善です。
python3 -m venv custodian-venv
source custodian-venv/bin/activate
pip install c7n2. セキュリティポリシーの作成
encrypt-buckets.ymlという名前のファイルを作成します。このポリシーは、AES-256またはKMS暗号化が設定されていないS3バケットをスキャンし、警告タグを付与します。これは、セキュリティ体制を破壊せずに監査する手法です。
policies:
- name: s3-unencrypted-report
resource: s3
filters:
- type: no-encryption
actions:
- type: tag
key: SecurityStatus
value: NonCompliant3. 監査の実行
AWSアカウントに対してポリシーを実行します。開始前に、ターミナルセッションで認証情報がエクスポートされていることを確認してください。
custodian run --output-dir=. encrypt-buckets.ymlCustodianはresources.jsonファイルを生成します。このファイルには、チェックに合格しなかったすべてのバケットがリストされます。AWSコンソールを何時間もクリックし続ける必要はもうありません。
3つの柱：ポリシーの構成要素
すべてのCloud Custodianポリシーは、論理的な3部構成になっています。クラウドインフラに対する「If-This-Then-That（もしこれなら、あれをする）」と考えてください。
- Resource（リソース）: 対象となるアセット（例:
aws.ec2、azure.vm、またはgcp.instance）。 - Filter（フィルター）: 選択のための特定の基準。「60日以上経過したインスタンス」や「所有者が設定されていないディスク」などを指定できます。
- Action（アクション）: 実行する処理。停止、削除、タグ付け、あるいはリソース作成者へのSlack通知などが可能です。
本番環境では、私はこのロジックを使用して、毎週日曜日の夜に放置されたEBSボリュームを処理しています。これは、「クラウドの墓場」が四半期予算を食いつぶすのを防ぐ簡単な方法です。
実践：マルチクラウドガバナンス
Cloud Custodianは、プロバイダー固有のAPIを統一された構文に抽象化します。つまり、マルチクラウド環境を管理するために3つの異なるCLIツールを学ぶ必要はありません。
AWS：コスト削減の自動化
開発環境は週末も稼働し続け、60時間以上のコンピューティング時間を浪費しがちです。このポリシーは、Env: Devタグが付いたインスタンスをターゲットにし、午後6時にシャットダウンします。
policies:
- name: ec2-nightly-stop
resource: ec2
filters:
- type: value
key: "tag:Env"
value: Dev
- type: schedule
# 午後6時に停止するスケジュール設定
schedule: "stop"
default_tz: "utc"
actions:
- stopAzure：管理ディスクのクリーンアップ
Azureでは、親機となるVMを削除した後も管理ディスクの課金が継続されます。このポリシーは、接続されていない（Unattached）ディスクを自動的に見つけて削除します。
policies:
- name: azure-cleanup-unattached-disks
resource: azure.disk
filters:
- type: value
key: properties.diskState
op: eq
value: Unattached
actions:
- type: delete安心して運用するための本番戦略
インフラを削除できるツールを実行するのは、当然ながら不安が伴います。予期せぬ停止を避けるため、私は厳格なデプロイワークフローに従っています。
「Dry Run」というセーフティネット
新しいポリシーをいきなり「ライブ」モードで実行しないでください。--dryrunフラグを使用しましょう。これにより、実際に変更を加えることなく、どのリソースが影響を受けるかを正確にシミュレートできます。
# 実際に変更を加えず実行結果をシミュレートする
custodian run --dryrun --output-dir=out policy.yml「通知と待機」の猶予期間
突然の削除は開発者を混乱させます。即座にアクションを起こすのではなく、2段階のポリシーを作成しましょう。最初のポリシーで非準拠のリソースにタグを付け、Slackアラートを送信します。72時間の猶予期間を経ても非準拠のままであれば、2番目のポリシーで削除を実行します。
CI/CDへの統合
長期的なガバナンスを個人のノートPCで行うべきではありません。YAMLポリシーをGitリポジトリに移行しましょう。GitHub ActionsやGitLab CIを使用して、これらのポリシーをスケジュール実行します。例えば、セキュリティチェックは1時間ごと、コストクリーンアップは週に1回といった運用が考えられます。
最後に
クラウドガバナンスは「インフラ警察」を演じることではありません。開発者が玄関を開けっぱなしにすることなく、迅速に行動できるようにするための「ガードレール」を構築することです。ポリシーをコードとして扱うことで、請求額に驚いてから対処するのではなく、意図を持ってクラウドを管理できるようになります。Cloud Custodianは、混沌とした環境を、予測可能で自動化されたエコシステムへと変えてくれます。
