この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Systems Manager Automation 用 ドキュメントに AWS プレミアムサポートが作成した セルフ診断と修復を可能にするサポート自動化ワークフロー（ Support Automation Workflow ）の利用が可能となったようです！
「AWSSupport」「AWSPremiumSupport」 から始まるドキュメントが今回の SAW に該当するようです！自チームにフィットしそうなドキュメントがないかチェックしてみるのも良いかもしれません。（ Automation 用ドキュメントのリファレンスが独立して見やすくなっている
Systems Manager Automation runbook reference
本記事では、その中の一つである下記ドキュメントを実施してみたいと思います!
AWSPremiumSupport-TroubleshootEC2DiskUsage
Description
The AWSPremiumSupport-TroubleshootEC2DiskUsage runbook helps you investigate and potentially remediate issues with Amazon Elastic Compute Cloud (Amazon EC2) instance root and non-root disk usage. If possible, the runbook attempts to remediate issues by extending the volume and its file system. To perform these tasks, this runbook orchestrates the execution of several runbooks based on the operating system of the affected instance.
The first runbook, AWSPremiumSupport-DiagnoseDiskUsageOnWindows or AWSPremiumSupport-DiagnoseDiskUsageOnLinux, determines if disk issues can be mitigated by expanding the volume.
The second runbook, AWSPremiumSupport-ExtendVolumesOnWindows or AWSPremiumSupport-ExtendVolumesOnLinux, uses the output of the first runbook to run Python code that modifies the volume. After the volume has been modified, the runbook extends the partition and file system of the affected volumes.
Important Access to AWSPremiumSupport-* runbooks requires an Enterprise or Business Support Subscription. For more information, see Compare AWS Support Plans.
This document was built in collaboration with AWS Managed Services (AMS). AMS helps you manage your AWS infrastructure more efficiently and securely. AMS also provides operational flexibility, enhanced security and compliance, capacity optimization, and cost-savings identification. For more information, see AWS Managed Services.
↓↓↓ 自動翻訳 ↓↓↓
説明
AWSPremiumSupport-TroubleshootEC2DiskUsageランブックは、Amazon Elastic Compute Cloud (Amazon EC2)インスタンスのルートおよび非ルートのディスク使用に関する問題を調査し、修正するのに役立ちます。可能であれば、このランブックはボリュームとそのファイルシステムを拡張することで問題を修正しようとします。これらのタスクを実行するために、このランブックは、影響を受けるインスタンスのオペレーティング・システムに基づいて、複数のランブックの実行をオーケストレーションします。
最初のランブック、AWSPremiumSupport-DiagnoseDiskUsageOnWindowsまたはAWSPremiumSupport-DiagnoseDiskUsageOnLinuxは、ボリュームを拡張することでディスクの問題が緩和されるかどうかを判断します。
2 番目のランブック、AWSPremiumSupport-ExtendVolumesOnWindows または AWSPremiumSupport-ExtendVolumesOnLinux は、1 番目のランブックの出力を使用して、ボリュームを変更する Python コードを実行します。ボリュームが変更された後、ランブックは影響を受けるボリュームのパーティションとファイルシステムを拡張します。
重要 AWSPremiumSupport-*ランブックにアクセスするには、EnterpriseまたはBusiness Supportサブスクリプションが必要です。詳細については、Compare AWS Support Plansを参照してください。
このドキュメントは、AWSマネージドサービス（AMS）と共同で作成されました。AMSは、AWSインフラストラクチャをより効率的かつ安全に管理するのに役立ちます。またAMSは、運用の柔軟性、セキュリティとコンプライアンスの強化、キャパシティの最適化、コスト削減の識別を提供します。詳細については、「AWSマネージドサービス」をご覧ください。
（上記ドキュメントより引用）
事前に設定した条件で、ディスク使用状況を診断し、拡張を実行するドキュメントのようですね。定期的に実行したり、ディスクに関するアラートをトリガーに実行することで、対応者の手を介さずに迅速に対応が行えるのでは?!
ドキュメントによると冒頭の SSM ドキュメントからさらに複数の SSM ドキュメントが実行されているようです！具体的なフローもドキュメント内で紹介されています。ここでは割愛しますが、検討前にはご一読ください。また実行に際して、サポートプランが エンタープライズ または ビジネスであることが条件となっている点にも注意が必要です。
やってみる
準備
- 各 OS （Linux/Windows）の EC2 を起動
- Linux は ルートボリュームが 8GB
- Windows は ルートボリュームが 30GB
AWSPremiumSupport-TroubleshootEC2DiskUsage 実行
AWS Systems Manager >>> Automation >>> Execute automation >>> AWSPremiumSupport-TroubleshootEC2DiskUsage で検索
選択 >>> Next
まずは Linux で実施していきます
パラメータで条件を設定しています。 各パラメータについては ドキュメント に詳細が記載されています。 拡張の最大サイズが指定出来るため、思わぬサイズまで増えていたというトラブルを避けることが可能ですね。
- InstanceId
説明： (必須）AmazonEC2インスタンスのID。 - VolumeExpansionEnabled
説明： (オプション）ドキュメントが影響を受けるボリュームとパーティションを拡張するかどうかを制御するフラグ。 - VolumeExpansionUsageTrigger
説明： (オプション）拡張をトリガーするために必要なパーティションスペースの最小使用量（パーセンテージ）。 - VolumeExpansionCapSize
説明： (オプション）Amazon Elastic Block Store（Amazon EBS）ボリュームが増加する最大サイズ（GiB単位）。 - VolumeExpansionGibIncrease
説明： (オプション）ボリュームのGiBの増加。VolumeExpansionGibIncreaseとVolumeExpansionPercentageIncreaseの間の最大の純増加が使用されます。 - VolumeExpansionPercentageIncrease
説明： (オプション）ボリュームのパーセンテージの増加。VolumeExpansionGibIncreaseとVolumeExpansionPercentageIncreaseの間の最大の純増加が使用されます。 - AutomationAssumeRole
必要な権限を参照の上、事前に準備する必要があります。
どのボリュームに対してというものではなく、インスタンスにアタッチされているボリューム全てが対象となり、条件を満たすものが拡張されるようです。
同様の手順で Windows インスタンスでも実行します。
実行結果
しばらくすると Automation が終了します（実行時間は拡張するサイズ等に左右されると想定されます）。
それぞれボリュームが拡張されたかを確認します。
- Linux（ 8GB → 50GB ）
$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 469M 0 469M 0% /dev
tmpfs 479M 0 479M 0% /dev/shm
tmpfs 479M 328K 479M 1% /run
tmpfs 479M 0 479M 0% /sys/fs/cgroup
/dev/nvme0n1p1 50G 1.6G 49G 4% /- Windows（ 30GB → 50GB ）
無事、拡張されています！
さいごに
シンプルな設定で実行が可能でした！本記事ではまずはどんなものかやってみましたので、実運用で活用するにはいくつかの検証が必要になるのではかと思います。
- 変更によるパフォーマンス・サービス影響
- 複数ボリュームがアタッチされている際の動作
- 失敗した場合の動作、検知方法
- 手持ちリソースが実施可能か（対象リソース OSやバージョンなど、変更後アクションの要否）
- アラートを起点とした際の対象リソースを受け渡す部分など一連の動作
などなど、気になる点はありますが、自前で手順を作成・管理するよりも、本 SSM ドキュメントを手順としておくだけでも、作業ミスや管理の負担が減るなどの効果が見込めるのではないでしょうか！ 他のドキュメントも気になりますし、今後も拡充されていくのではないでしょうか。こういったサービス・リソースはどんどん活用（少なくとも検討）して自チームの負担を減らしていきたいですね。
2
