マネージドサービス部 佐竹です。
組織全体で AWS Systems Manager のデフォルトホスト管理設定（Default Host Management Configuration setting）をセットアップし、利用した時に運用でハマった点を記載してみます。
- はじめに
- DHMC のセットアップが AWS Organizations へ対応
- SSM クイックセットアップを組織で有効化する
- SSM DHMC を利用した Session Manager の動作確認
- SSM DHMC の IAM Role が利用される条件を整理する
- 625 アカウントという制限について
- まとめ
はじめに
AWS Systems Manager (SSM) の Default Host Management Configuration (DHMC) は2023年2月17日にリリースされた新機能です。
SSM DHMC の何が嬉しいのか？
SSM DHMC の利点は以下の通りです。
- SSM 利用時に、各 EC2 インスタンスへ IAM Role (インスタンスプロファイル)をアタッチする作業が不要となります
- 代わりに、SSM DHMC 側でデフォルトとして設定される IAM Role が利用されるようになります
- IAM Role から SSM の権限を分離することができ、インスタンス利用者による権限修正とのコンフリクトを回避することが可能となります
- オプションで、SSM Agent の更新が2週間毎に実施されるよう自動化することも可能です
ようは SSM の利用前提で最も手間となる「各 EC2 インスタンスへ IAM Role を漏れなくアタッチする作業」をしなくても SSM が利用できるようになるというもので、運用者からするとかなりの手間を削減してくれる機能です。
以下でまとめてアップデート発表時のニュース、ブログ、そして AWS 公式ドキュメントを紹介します。
1. AWS Systems Manager をアカウント内すべての EC2 インスタンスにおいてデフォルトで有効にする新機能が登場
2. デフォルトのホスト管理設定の使用
ドキュメントに重要な記載があるため掘り下げます。
本ドキュメントに記載がある前提条件は要確認となります。以下、その前提条件の抜粋となります。
- 管理対象となるインスタンスには、インスタンスメタデータサービスのバージョン 2 (IMDSv2) を使用する必要があります。
- SSM Agent バージョン 3.2.582.0 以降がインスタンスにインストールされている必要があります。
- Systems Manager を使用して管理される Amazon EC2 インスタンスに IAM インスタンスプロファイルがすでにアタッチされている場合は、
ssm:UpdateInstanceInformation操作を実行するためのアクセス許可をすべて削除します。SSM Agent は、デフォルトのホスト管理設定のアクセス許可を使用する前に、インスタンスプロファイルのアクセス許可の使用を試みます。
IMDSv2 が前提となっていることと、SSM Agent バージョン 3.2.582.0 がインストールされていること。さらに特定の権限を持った IAM インスタンスプロファイルがアタッチされていないことが重要です。
特に3つ目の仕様については運用上重要なポイントのため、後程具体的な例と構成図で解説していきます。
3. Enable management of your Amazon EC2 instances in AWS Systems Manager using Default Host Management Configuration
DHMC のセットアップが AWS Organizations へ対応
さらに、2023年10月13日にアップデートが行われ Systems Manager Quick Setup を利用するだけで AWS Organizations 配下の全アカウント、全リージョンに SSM DHMC の自動構築が可能となりました。これについては、先にご紹介しましたブログ内にも追記がされています。
2024 年 1 月更新: 2023 年 10 月、AWS Systems Manager は、Systems Manager Quick Setup を使用して組織内のすべての EC2 インスタンスに対して AWS Systems Manager をデフォルトで有効にする機能を発表しました。Quick Setup コンソールから数回クリックするだけで、DHMC の利点を活用できます。詳細については、「組織のデフォルトのホスト管理」を参照してください。
さらに、この投稿で参照されている CloudFormation テンプレートは、各ターゲットリージョンに IAM Role を作成するように更新され、この変更を反映するように手順が変更されました。以前のバージョンのテンプレートでは、
MainRegionに 1 つの IAM Role が作成されていました。以下、原文です。
Update 01/2024: In October 2023, AWS Systems Manager announced the ability to enable AWS Systems Manager by default for all EC2 instances in an organization using Systems Manager Quick Setup. You can begin utilizing the benefits of DHMC in just a few clicks from the Quick Setup console. For more information, see Default Host Management for an organization.
Additionally, the CloudFormation template referenced in this post has been updated to create IAM roles in each target Region and the instructions have been modified to reflect this change. The previous version of the template created a single IAM role in the MainRegion.
これを組織においてセットアップしておくことで、特に何をせずとも SSM Agent がデフォルトでインストールされている EC2 インスタンスであれば構築直後に SSM が動作するようになります。
参考までに、このアップデートについてもアップデート発表時のニュース、AWS 公式ドキュメントのリンクをそれぞれご紹介しておきます。
4. AWS Systems Manager を組織内すべての EC2 インスタンスに対してデフォルトで有効にする新機能が登場
5. (サポートされている Quick Setup) 組織のデフォルトのホスト管理
SSM クイックセットアップを組織で有効化する
Systems Manager Quick Setup （以下クイックセットアップ）を利用するだけで AWS Organizations 配下の全アカウント、全リージョンに DHMC の自動構築が可能となっていますので、今回このセットアップを行ったアカウント用いて説明致します。
まずはクイックセットアップを用いて組織全体に SSM DHMC の設定を行った時の作業履歴をご紹介します。
ただ、先に説明をしたい重要な補足事項が2つあります。
補足事項1. ホームリージョン
以下、AWS 公式ドキュメントから引用します。
ホーム AWS リージョン を設定するには
AWS Systems Manager の一機能である Quick Setup の使用を開始するには、ホーム AWS リージョン を選択してから、Quick Setup でオンボードする必要があります。ホームリージョンは、Quick Setup が設定のデプロイに使用される AWS リソースを作成する場所です。選択したホームリージョンは変更できません。https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/quick-setup-getting-started.html
まず、利用開始にあたり「Quick Setup の使用を開始するには、ホーム AWS リージョン を選択」する必要があります。
これは上画像の通り、AWS Systems Manager の「Quick Setup」の画面、右端に表示されるものです。
SSM のクイックセットアップ画面を表示した際に「ホームリージョンを選択する」旨が表示される場合は、ホームリージョンが未設定ということになります。まずはホームリージョンを設定してください。
そしてドキュメントより引用した文章の最後に「選択したホームリージョンは変更できません」と記載があるように、変更できない仕様です。
また、一度設定したホームリージョンは「その設定がどこのリージョンとなっているか」をマネジメントコンソールからも AWS CLI からでも確認することができません*1。ただ、ホームリージョンを間接的に確認する方法は存在します。
この後の作業を継続すると、その裏ではクイックセットアップ用の CloudFormation StackSets が実行されます。この CloudFormation StackSets の実行起点となるリージョンがホームリージョンです。
補足事項2. 委任管理者
加えて、SSM のクイックセットアップの機能は AWS Organizations の Delegated Administrator （管理者を委任する機能）に対応しておらず、マネジメントアカウント（管理アカウント）で実行する必要があります*2。
よって今回ご紹介するクイックセットアップの作業履歴は AWS Organizations のマネジメントアカウントにおける作業履歴となっております。
クイックセットアップの実行
ではセットアップ手順の紹介を続けます。
先に記載しました「ホームリージョン」の設定を完了した後に、SSM のクイックセットアップの「Library」において「Default Host Management Configuration」が表示されるようになります。
この「Default Host Management Configuration」が表示されるのはマネジメントアカウントのみで、メンバーアカウントで確認しても表示されません。
「Default Host Management Configuration」の「Create」を押下して作業を進めます。
特に設定を変更することなく「Create」を押下して作業を完了します。なお Enable automatic updates of the SSM Agent every two weeks については後程変更できます。SSM Agent の自動アップデートを望まない場合はセットアップ後にも解除可能です。
正しく実行されると、DHMC の設定が全アカウントに施されて行きます。裏側では CloudFormation のスタックが動作するため少々時間がかかります。
念ため確認してみたところ、CloudFormation StackSets では「AWS-QuickSetup-DHMC-TA-[QuickSetupID]」という StackSets ができています。これは各メンバーアカウント、各リージョンに実行されるスタックの元です。
実行される CloudFormation StackSets に関して3点補足です。
1つ目は、この CloudFormation StackSets の実行先は AWS Organizations の root となっており組織全体です。
2つ目に、対象となるリージョンは現在「全てのリージョン」となっており、リージョン単位のオンオフには対応していません。
3つ目に、そもそもとして CloudFormation StackSets は AWS Organizations の管理アカウントは実行対象とならないため、もし管理アカウントにも配備されたい場合は個別に対応が必要です*3。
クイックセットアップが可能なリージョンについて
クイックセットアップが可能なリージョンについては以下のドキュメントに記載があります。
Availability of Quick Setup in AWS Regions
現時点では以下の16リージョンがデフォルトでは対象となっており、本ブログでも以下の16リージョンを対象としています。
- US East (Ohio)
- US East (N. Virginia)
- US West (N. California)
- US West (Oregon)
- Asia Pacific (Mumbai)
- Asia Pacific (Seoul)
- Asia Pacific (Singapore)
- Asia Pacific (Sydney)
- Asia Pacific (Tokyo)
- Canada (Central)
- Europe (Frankfurt)
- Europe (Stockholm)
- Europe (Ireland)
- Europe (London)
- Europe (Paris)
- South America (São Paulo)
補足ですが、大阪リージョンは SSM のクイックセットアップに対応していないため、通常の Host Management もセットアップできませんでした。
クイックセットアップの完了確認
セットアップが完了すると、クイックセットアップの「Configurations」から詳細が確認できます。ラジオボタンで対象を選択し、「View details」を押下します。
上画像のようにステータスを確認し、デプロイ状況に問題がないかどうか確認が可能です。
また上記はメンバーアカウントの画面キャプチャですが、本セットアップが完了すると IAM に「AWS-QuickSetup-DHMCRole-[QuickSetupID]-[Region]」という名前の IAM Role が各リージョンごとに作成されるようになります。
本 IAM Role には「AWS-QuickSetup-EnableDHMC-AutomationPolicy」と「SSMQuickSetupEnableExplorerInlinePolicy」という名称の IAM ポリシーが付与されます。
加えて、「AWS-QuickSetup-SSM-DefaultEC2MgmtRole-[Region]」という IAM Role も作成され、これが実際に SSM DHMC を有効化している場合に Systems Mnagaer Agent が利用する IAM Role となります。
この IAM Role には arn:aws:iam::aws:policy/AmazonSSMManagedEC2InstanceDefaultPolicy という AWS マネージドポリシーがアタッチされているのみです。
なお「View details」の画面の右上にある「Edit」を押下することで、編集画面が表示されます。
編集できる設定はほぼありませんが、上画像の通り「Configuration options」において「Enable automatic updates of the SSM Agent every two weeks」のオンオフが後からでも可能です。
一旦、ここまでで SSM のクイックセットアップは完了となります。
ここで覚えて置いて頂きたいことは「AWS-QuickSetup-SSM-DefaultEC2MgmtRole-[Region]」が実際に Systems Mnagaer Agent によって利用される IAM Role という点です。
SSM DHMC を利用した Session Manager の動作確認
では動作確認です。
メンバーアカウントに EC2 インスタンスを構築して動作確認を実施します。検証用のEC2 インスタンスは以下の設定で構築します。
- IMDSv2 は Required とする
- AMI は Amazon Linux 2023 の「al2023-ami-2023.5.20240708.0-kernel-6.1-arm64 (ami-0b44ce1dad7c202b7)」を利用
- IAM インスタンスプロファイルはアタッチしない
- Security Groups は TCP 443/80 に対して Outbound のみ 0.0.0.0/0 で解放
本設定で構築後に「Fleet Manager」から該当の EC2 インスタンスステータスを確認してみると、「Online」のため問題なく Systems Mnagaer が動作していることがわかります。
よって、このままの状態（IAM インスタンスプロファイルなしの状態）でも Session Manager が利用できそうです。
実際に動作確認を行ったところ、基本的には問題なく Session Manager の利用が可能なことが確認できました。
Error が発生してしまう条件
ですが、上記インスタンスに対して Session Manager を実行すると、以下のような Error が発生してしまう場合があります。
Your session has been terminated for the following reasons: Couldn't start the session because we are unable to validate encryption on Amazon S3 bucket. Error: AccessDenied: Access Denied status code: 403, request id: SD9611B6FHM4V46B, host id: a4MDWaUTRNFnPt3OZ6cTYpl0KEDNQ6lxVoQJom2L7TpQUXzPErFqQJYU5aIjDObjj+JFUZruTcM=
エラーで失敗しました。
これは上画像のように Session Manager のログを S3 バケットに出力する設定を行っている条件下において、SSM Agent が参照している IAM Role に S3 バケットへのログ出力権限がない場合に発生します。
さて、このエラーをどうトラブルシューティングしていく必要があるでしょうか？
SSM DHMC の IAM Role が利用される条件を整理する
本ブログの本題がこちらになります。
本事象の解決に関しては、SSM Agent によって「SSM DHMC の IAM Role がどのような場合に利用されるのか」という前提及び仕様の理解が必要です。
さて、本ブログで先に紹介した以下の条件を再度確認してみます。
- Systems Manager を使用して管理される Amazon EC2 インスタンスに IAM インスタンスプロファイルがすでにアタッチされている場合は、
ssm:UpdateInstanceInformation操作を実行するためのアクセス許可をすべて削除します。SSM Agent は、デフォルトのホスト管理設定のアクセス許可を使用する前に、インスタンスプロファイルのアクセス許可の使用を試みます。
「ssm:UpdateInstanceInformation 操作を実行するためのアクセス許可をすべて削除します」とあるように、この権限がスイッチであり「On/Off を切り替えるもの」と判断できます。
EC2 の IAM Role が優先される条件
例えば、上図のような状況とします。
この図では、EC2 インスタンスには IAM インスタンスプロファイル（IAM Role）が既に付与されており、それが ssm:UpdateInstanceInformation の権限を保持している状況です。既存では AmazonSSMManagedInstanceCore という AWS マネージドポリシーが利用されることが多いでしょう。
加えて図では AWS-QuickSetup-SSM-DefaultEC2MgmtRole も作成されており*4、これには AmazonSSMManagedEC2InstanceDefaultPolicy が付与されています。これも ssm:UpdateInstanceInformation の権限を保持しています。
この状況では「SSM Agent は、デフォルトのホスト管理設定のアクセス許可を使用する前に、インスタンスプロファイルのアクセス許可の使用を試みます」と記載がある通り、EC2に直接アタッチされた IAM Role が優先されることになります。
よって、この場合 SSM Agent は SSM DHMC の IAM Role (AWS-QuickSetup-SSM-DefaultEC2MgmtRole)を利用していません。これを先の構成図では EC2 インスタンスから右へ向かう矢印で示しています。
SSM DHMC の IAM Role が利用される条件
では SSM DHMC の IAM Role を利用するにはどうすればいいでしょうか。
ドキュメントに記載があるように EC2 インスタンスにアタッチされた ssm:UpdateInstanceInformation 操作を実行する権限を持つ IAM インスタンスプロファイルをデタッチすれば良いとなります。
このようにすれば AWS-QuickSetup-SSM-DefaultEC2MgmtRole が利用されることになります。
Session Manager のログを S3 に出力する権限はどうするか
ここから「Session Manager のログを S3 バケットへ出力する権限をどのように付与していくか」を考えていきます。
EC2 インスタンス側で制御する場合
まずは、これまで通り EC2 インスタンスに直接アタッチされた SSM 用の IAM インスタンスプロファイル（IAM Role）で制御する場合を考えます。下図の左側をご覧ください。
EC2 インスタンスにアタッチが可能な IAM Role は1つのみですので、この IAM Role に例えば以下のような IAM ポリシーを追加することになります。このポリシーの名称は仮に「SSMSessionManagerLogPolicy」としています。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "SendtoS3", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:PutObjectAcl", "s3:GetEncryptionConfiguration" ], "Resource": [ "arn:aws:s3:::[BlogSample]-session-manager-log", "arn:aws:s3:::[BlogSample]-session-manager-log/*" ] } ] }
図では s3:PutObject と記載している箇所がそれであり、この権限付与により SSM Agent は S3 バケットへのログ出力が可能になります。
SSM DHMC 側で制御する場合
反対に、SSM DHMC で制御したい場合はどのようにする必要があるでしょうか。下図の右側をご覧ください。
EC2 インスタンスの IAM インスタンスプロファイルはデタッチした状態で考えます。
「AWS-QuickSetup-SSM-DefaultEC2MgmtRole-[Region]」が実際に SSM Agent によって利用される IAM Role のため、AWS-QuickSetup-SSM-DefaultEC2MgmtRole と図に記載している IAM Role に対して先に記載した権限を持つ IAM ポリシーをアタッチすることになります。
実際にマネジメントコンソールで IAM ポリシーのアタッチを行うと上画像の通りとなり AmazonSSMManagedEC2InstanceDefaultPolicy の下に先ほど作成した SSMSessionManagerLogPolicy が並んでいます。
この権限追加を行うことで、SSM DHMC の IAM Role を利用する場合でも S3 の権限に関するエラーが回避できます。
AWS re:Post を確認する
AWS Systems Manager Session Managerの問題をトラブルシューティングするにはどうすればよいですか?
https://repost.aws/ja/knowledge-center/ssm-session-manager-failures
本修正については、上記ドキュメントにも以下の通り記載がされています。
デフォルトのホスト管理設定を使用して管理するインスタンスの場合は、暗号化されたログを Amazon S3 にアップロードできるアクセス許可を付与するポリシーを、IAM ロールに追加します。手順については、「セッションマネージャー、Amazon S3、CloudWatch Logs（コンソール）用の権限を持つIAMロールの作成」を参照してください。
注意点としては「AWS-QuickSetup-SSM-DefaultEC2MgmtRole-[Region]」は各リージョンごとにバラバラに作成されるという点です。
このため、漏れなく対応を行うためには Session Manager を利用する全リージョンの IAM Role を修正する必要があります。利用リージョンが16あれば、16の IAM Role のメンテナンスが必要です。これはさらに AWS Organizations においては、各メンバーアカウントで必要となってしまいます。
この対応は手動ではかなり厳しいものがあるため、CloudFormation StackSets を利用して改善を検討したいと考えています。
SSM Agent が参照できる IAM Role は1つだけ
さて、最後に先の設定を組み合わせたパターンを紹介します。
上図に向かって右側の AWS-QuickSetup-SSM-DefaultEC2MgmtRole をそのままメンテナンスをせず利用をし、S3 バケットへのログ出力権限は EC2 インスタンスの IAM インスタンスプロファイルで対応する、という権限の分離です。
一見この構成はうまく動作しそうです。
ですがこの構成で動作確認を行ってみると、想定とは異なり正しく動作しません。
私がここでハマってしまったのは「SSM Agent が参照できる IAM Role は1つだけである」という仕様を理解できていなかったためでした。
SSM Agent は IAM Role の権限を参照して利用しますが、この時参照するのはどちらか1つだけです。
EC2 インスタンスの IAM インスタンスプロファイルを参照している場合は、そちらにログの出力権限が必要です。SSM DHMC の IAM Role を参照している場合には、SSM DHMC の IAM Role にログの出力権限が必要です。これらを組み合わせて利用はできない点に注意してください。
SSM Agent が利用する IAM Role を切り替えたい場合の注意点
EC2 インスタンスにアタッチされた IAM インスタンスプロファイルに ssm:UpdateInstanceInformation の権限があるかないかで利用先の切替が可能なことを先に記載しました。
ではこの切り替えはどれほど柔軟に可能でしょうか？
ここで知っておくべき仕様について記載します。
デフォルトのホスト管理設定の有効化
デフォルトのホスト管理設定をオンにした後、以下の手順のステップ 5 で選択したロールの認証情報をインスタンスが使用できるようになるまでに 30 分かかる場合があります。
ヒントは上記 AWS 公式ドキュメントに記載がある「30 分かかる場合があります」という表記です。これは SSM Agent が保持する認証情報の最大キャッシュ期間（ローテーション期間）を示しています。
例えば、ある EC2 インスタンスを IAM Role をアタッチした状態で Launch（作成）したとします。EC2 インスタンスでは OS の起動と同時に SSM Agent が立ち上がり SSM Agent は EC2 インスタンスにアタッチされた IAM Role の権限を参照しに行きます。
構築直後に「SSM DHMC の IAM Role を利用しないといけなかったんだ」と思い出し、EC2 インスタンスにアタッチされた IAM Role をデタッチしました。
さて、このようにすれば SSM DHMC の IAM Role にすぐに切り替わってくれるのではと想定しますが、実際はすぐには切り替わらず、最大30分の待ち時間がかかる場合があります。
SSM Agent は取得した認証情報（EC2 インスタンス側の IAM Role を使っているのか、DHMC 側なのか）を最大30分保持しており、30分ごとのローテーション期間を経てリフレッシュがされます。このため、ローテーションが行われるまで待たなければいけません。
よって、すぐに切り替えるといことができず、待ち時間が発生します。ただし、先の例であれば一度 EC2 インスタンスの Terminate を行い、再度 Launch を行うことですぐに回復は可能です。
補足となりますが、本件について AWS サポートにケースを起票し「待ち時間を短縮可能かどうか」を確認したところ /var/lib/amazon/ssm/runtimeconfig/identity_config.json ファイルを削除した後に再起動を行うことで、SSM Agent が認証情報をすぐに再取得するようにできるとのことでした。ただしこれは公式に推奨されている手順ではなく、緊急時のワークアラウンドとして利用するものとご認識ください。
625 アカウントという制限について
関連して、クォータに関わる注意点についても記載しておきます。
AWS 公式ドキュメントには以下の通りの注記が掲載されています。
Quick Setup は AWS CloudFormation StackSet を使用して、AWS アカウント およびリージョン全体で設定をデプロイします。ターゲットアカウントの数にリージョンの数を乗じて算出した数値が 10,000 を超える場合、設定のデプロイは失敗します。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/quick-setup-getting-started.html
「ターゲットアカウントの数にリージョンの数を乗じて算出した数値が 10,000 を超える場合」にデプロイが失敗すると記載されています。
この仕様には、CloudFormation StackSets のクォータが関連しています。
本ドキュメントに掲載されている「StackSets instance operations」というクォータは「10,000 operations」が制限となっています。
これは CloudFormation StackSets によって実行される「Stack instances」の数が1万で上限となるということなのですが、AWS SSM DHMC クイックセットアップも同様に StackSets で行われるために、本制限の影響を受けます。
クイックセットアップのデプロイ対象リージョンが 16 となっているため「10000÷16=625」の計算式から、625 メンバーアカウントが上限であることがわかります。
つまり、626 メンバーアカウント目からはスタックによるデプロイが失敗することが想定されます。
組織のメンバーアカウントの数が 625 を越えることは稀であると思われますが、この制限については認識した上で実装されたほうが良いでしょう。
まとめ
本ブログでは AWS Systems Manager のデフォルトホスト管理設定（Default Host Management Configuration setting）のクイックセットアップを利用し組織全体に配備した状況下でハマった運用知見について記載しました。
記載した内容から、重要と思われる点をまとめてみます。
- SSM Session Manager のログを S3 バケットへ出力している場合 SSM DHMC クイックセットアップのデフォルト権限だけではエラーになる
- SSM Agent が EC2 インスタンスの IAM Role を利用するか、それとも SSM DHMC の IAM Role を利用するかは
ssm:UpdateInstanceInformationの有無によって切り替わる - SSM Agent が参照可能な IAM Role は1つだけである
- Session Manager のログ出力に DHMC の IAM Role を利用する場合、各リージョンごとに作成される IAM Role それぞれに S3 バケットへの権限追加が必要になる
- SSM Agent は取得した認証情報を保持しており、30分ごとのローテーション期間を経てリフレッシュがされる
- CloudFormation StackSets のクォータにより、クイックセットアップは 625 メンバーアカウント×16 リージョンが上限となっている
AWS Systems Manager のデフォルトホスト管理設定（Default Host Management Configuration setting）は比較的新しい機能であり、また AWS Organizations (組織)単位でも利用され始めたばかりですため、現在は未だ運用知見が乏しい状況と思われます。
これらの知見がガバナンスやセキュリティ統制の一助になれば幸いです。
では、またお会いしましょう。
*1:これについては AWS サポートに確認を取りましたが現状機能が提供されていないためにできないとのことでした
*2:これについても AWS サポートに確認を取りましたが委任はできないとのことでした
*3:クイックセットアップの「Default Host Management Configuration」ではなく「Host Management」を利用する等
*4:Region は都合表記から省略しました
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
