おうちでAWS　～AWS Systems Manager 編～

#AWS
#AWS Systems Manager（SSM）
あかいけ
2025.05.28
 はじめに皆様こんにちは、あかいけです。
突然ですが、おうちで AWS を使っていますか？

このブログを見ているということはおそらくあなたは仕事で AWS を利用されている方だと思いますが、

おうちでも AWS を感じたくないですか？（私は感じたいです）
というわけで本シリーズでは、 「AWS をもっと身近に」 をテーマに、おうち（オンプレ）で活用できる AWS サービスを再発見していきます。

記念すべき第一回目は、AWS Systems Manager です。
なお本記事のコードは以下リポジトリに格納しているので、

よければこちらを Clone してご利用ください。
https://github.com/Lamaglama39/aws-at-home/tree/main
 AWS Systems Manager とは？AWS Systems Manager とは、AWS 上のサーバー（EC2 インスタンス）や、皆さんがお持ちの自宅サーバー（オンプレミス）、さらには他のクラウドサービス上にあるサーバーまで、一元的に管理し、運用タスクを自動化するための統合サービスです。

いわばサーバーを管理するための十徳ナイフのような存在です。
とにかく提供サービスが多いので詳しい解説は省略しますが、

大まかな全体像は以下ブログが参考になるので、よければご参照ください。
https://dev.classmethod.jp/articles/relay-re-introduction-2019-ssm/
 使う方法AWS Systems Manager を利用する場合、SSM Agent をインスタンスにインストールし、マネージドインスタンスにする必要があります。

これはEC2やオンプレ上のインスタンスでも同様です。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/ssm-agent.html
SSM Agent は各インスタンス（EC2 やオンプレミスサーバー）にインストールされるソフトウェアで、AWS Systems Manager サービスとインスタンス間の橋渡しを行います。
 料金についてAWS Systems Manager は数多くのサービスを内包しており、その料金形態も様々です。

ただし無料で使えるものや、ほぼ無料のような低価格で提供されているサービスが多い印象です。
本記事で触れるサービスの料金は後述しますが、

各サービスの詳細な料金は以下をご参照ください。
https://aws.amazon.com/jp/systems-manager/pricing/
 実行環境筆者の環境は以下の通りです。

またAnsibleを利用するため、作業用PCから管理対象サーバーへSSHで接続できることを前提としています。
なお今回は物理サーバーを使っていますが、仮想サーバーでももちろん同じことができるので、お好みのサーバーで実行してください。
 作業用PCTerraform - v1.10.0
Ansible - core 2.18.6
AWS CLI - 2.16.4
 管理対象サーバーOS - Ubuntu 24.04 LTS × 6
 セットアップオンプレインスタンスでのセットアップ手順は以下ドキュメントの通りです。

今回は再現性向上のため、Terraform と Ansible で設定してみます。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-hybrid-multicloud.html
 1.AWS 側以下の Terraform を実行して、AWS 上でリソースを作成します。

作成しているリソースは以下の通りです。
ハイブリッドアクティベーション用の IAM ロール
マネージドノードを登録するためのアクティベーション
セッションマネージャー暗号化用の KMS キー
なおregistration_limitは登録するサーバー数に応じて変更してください。
main.tf
data "aws_caller_identity" "current" {}

resource "aws_iam_role" "main" {
  name = "ssm-agent-homeserver-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "ssm.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_policy" "use_kms_key" {
  name        = "ssm-agent-homeserver-use-kms-key-policy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "kms:Decrypt"
        Effect   = "Allow"
        Resource = aws_kms_key.main.arn
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "use_kms_key" {
  role       = aws_iam_role.main.name
  policy_arn = aws_iam_policy.use_kms_key.arn
}

resource "aws_iam_role_policy_attachment" "ssm_instance_core" {
  role       = aws_iam_role.main.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

resource "aws_ssm_activation" "main" {
  name               = "ssm-agent-homeserver-activation"
  iam_role           = aws_iam_role.main.id
  registration_limit = "6"
  depends_on         = [aws_iam_role_policy_attachment.ssm_instance_core]
}

resource "aws_kms_key" "main" {
  deletion_window_in_days = 7
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "Enable IAM User Permissions"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${data.aws_caller_identity.current.account_id}:root"
        },
        Action   = "kms:*"
        Resource = "*"
      }
    ]
  })
}

output "kms_key_arn" {
  value = aws_kms_key.main.arn
}

output "activation_id" {
  value = aws_ssm_activation.main.id
  sensitive = true
}

output "activation_code" {
  value = aws_ssm_activation.main.activation_code
  sensitive = true
}
terraform apply;
次の手順で利用するアクティベーションコードと ID は、

リソース作成後に以下のコマンドで確認できます。
terraform output -json;
 2.おうち側おうち側では 管理対象となるサーバーへ SSM Agent をインストールしてから、

AWS側で作成したアクティベーションのコードとIDを利用してマネージドインスタンス化します。
今回この作業は Ansible で実行します、ディレクトリ構成は以下の通りです。
.
├── amazon-ssm-agent.json.template # SSM Agent カスタム設定ファイル
├── group_vars
│   └── all.yml                    # クレデンシャル用ファイル
├── inventory.ini                  # 実行対象のサーバー情報
├── ssm_register.yml               # SSM Agent 初期設定用 プレイブック
├── ssm_config_deploy.yml          # SSM Agent カスタム設定用 プレイブック
└── ssm_uninstall.yml              # SSM Agent削除用 プレイブック
まずは管理対象となるサーバーを記載したインベントリを作成します。

サーバー名、IP アドレスは各自の環境に合わせてください。
cat << EOF > inventory.ini;
---
[home_servers]
server-name-01 ansible_host=XXX.XXX.XXX.XXX
server-name-02 ansible_host=XXX.XXX.XXX.XXX
server-name-03 ansible_host=XXX.XXX.XXX.XXX
EOF
次にアクティベーションコードと ID 、サーバー接続用のクレデンシャルをファイルに記載します。

実際の値は各自の環境に合わせてください。
mkdir group_vars;
cat << EOF > group_vars/all.yml;
---
# AWS Config
aws_region: "ap-northeast-1"
ssm_activation_code: "XXXXXXXXXXXXXXXXXX"
ssm_activation_id: "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

# Home Server Credentials
ansible_user: user
ansible_ssh_private_key_file: ~/.ssh/key_name
ansible_become_pass: password
EOF
次に以下のプレイブックを指定して実行します。

実行する内容は、以下公式ドキュメントの Ubuntu Server の手順そのままです。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/hybrid-multicloud-ssm-agent-install-linux.html
ssm_register.yml
---
- name: Install and Register SSM Agent on Debian/Ubuntu
  hosts: home_servers
  become: true

  tasks:
    - name: Create a temporary directory for the installer
      ansible.builtin.file:
        path: /tmp/ssm
        state: directory
        mode: '0755'

    - name: Download the SSM installer script
      ansible.builtin.get_url:
        url: "https://amazon-ssm-{{ aws_region }}.s3.{{ aws_region }}.amazonaws.com/latest/debian_amd64/ssm-setup-cli"
        dest: /tmp/ssm/ssm-setup-cli
        mode: '0755'

    - name: Register the node with SSM (if not already registered)
      ansible.builtin.command:
        cmd: /tmp/ssm/ssm-setup-cli -register -activation-code "{{ ssm_activation_code }}" -activation-id "{{ ssm_activation_id }}" -region "{{ aws_region }}"
        creates: /etc/amazon/ssm/amazon-ssm-agent.json
ansible-playbook -i inventory.ini ssm_register.yml -v;
Ansible 実行後に作成したアクティベーションを見てみると、

マネージドインスタンスとして登録 (RegistrationsCount) されていることがわかります。
aws ssm describe-activations \
  --filters FilterKey=DefaultInstanceName,FilterValues=ssm-agent-homeserver-activation;
{
    "ActivationList": [
        {
            "ActivationId": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
            "DefaultInstanceName": "ssm-agent-homeserver-activation",
            "IamRole": "ssm-agent-homeserver-role",
            "RegistrationLimit": 6,
            "RegistrationsCount": 6,
            "ExpirationDate": "2025-05-26T14:03:22.722000+09:00",
            "Expired": false,
            "CreatedDate": "2025-05-25T14:03:22.722000+09:00"
        }
    ]
}
マネージドインスタンスの詳細情報は以下で確認できます。

先頭に「mi-」が付いたIDが、アクティベーションされたインスタンスです。
aws ssm describe-instance-information;
 (オプション) プライベートキーの自動ローテーションを設定するこの設定はオプションですが、

セキュリティー強化のため、SSM Agent が利用するプライベートキーの自動ローテーションの設定が有効とのことです。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/hybrid-multicloud-ssm-agent-install-linux.html
このローテーション設定に限らず、

SSM Agent の設定は以下設定ファイルを配置することで設定できます。
https://github.com/aws/amazon-ssm-agent/blob/mainline/amazon-ssm-agent.json.template
以下はローテーション設定 (KeyAutoRotateDays：デフォルト値 0) だけ書き換えたもので、今回はこちらを利用します。
amazon-ssm-agent.json.template
{
    "Profile":{
        "ShareCreds" : true,
        "ShareProfile" : "",
        "ForceUpdateCreds" : false,
        "KeyAutoRotateDays": 1
    },
    "Mds": {
        "CommandWorkersLimit" : 5,
        "StopTimeoutMillis" : 20000,
        "Endpoint": "",
        "CommandRetryLimit": 15
    },
    "Ssm": {
        "Endpoint": "",
        "HealthFrequencyMinutes": 5,
        "CustomInventoryDefaultLocation" : "",
        "HibernationMaxBackoffIntervalMinutes" : 60,
        "AssociationLogsRetentionDurationHours" : 24,
        "RunCommandLogsRetentionDurationHours" : 336,
        "SessionLogsRetentionDurationHours" : 336,
        "SessionLogsDestination": "none",
        "PluginLocalOutputCleanup": "",
        "OrchestrationDirectoryCleanup": ""
    },
    "Mgs": {
        "Region": "",
        "Endpoint": "",
        "StopTimeoutMillis" : 20000,
        "SessionWorkersLimit" : 1000,
        "DeniedPortForwardingRemoteIPs" : [
            "169.254.169.254",
            "fd00:ec2::254",
            "169.254.169.253",
            "fd00:ec2::253",
            "169.254.169.123",
            "fd00:ec2::123",
            "169.254.169.250",
            "169.254.169.251",
            "fd00:ec2::250"
        ]
    },
    "Agent": {
        "Region": "",
        "OrchestrationRootDir": "",
        "SelfUpdate": false,
        "TelemetryMetricsToCloudWatch": false,
        "TelemetryMetricsToSSM": true,
        "AuditExpirationDay" : 7,
        "LongRunningWorkerMonitorIntervalSeconds": 60
    },
    "Os": {
        "Lang": "en-US",
        "Name": "",
        "Version": "1"
    },
    "S3": {
        "Endpoint": "",
        "Region": "",
        "LogBucket":"",
        "LogKey":""
    },
    "Kms": {
        "Endpoint": "",
        "RequireKMSChallengeResponse": false
    }
}
カスタム設定用のプレイブックで用意したので、こちらを実行します。

実行内容は設定ファイルを配置して、SSM Agent を再起動しているだけです。
ssm_config_deploy.yml
---
- name: Deploy SSM Agent configuration file
  hosts: home_servers
  become: true

  vars:
    ssm_config_source: "amazon-ssm-agent.json.template"
    ssm_config_dest: "/etc/amazon/ssm/amazon-ssm-agent.json"

  tasks:
    - name: Copy new SSM configuration file (with automatic backup)
      ansible.builtin.copy:
        remote_src: false
        src: "{{ ssm_config_source }}"
        dest: "{{ ssm_config_dest }}"
        mode: '0644'
        owner: root
        group: root
        backup: true

    - name: Restart SSM agent service (if running)
      ansible.builtin.command:
        cmd: snap restart amazon-ssm-agent
      ignore_errors: true
ansible-playbook -i inventory.ini ssm_config_deploy.yml -v;
 使ってみたさて前置きが長くなってしまいましたが、実際に使っていきましょう。
冒頭でも触れた通り AWS Systems Manager は数多くのサービスを提供しているので、

おうちでも使いやすそうなもの or 使用頻度が高そうなもの をいくつかピックアップして使ってみます。
 Session Managerさて、まず使いたいのはセッションマネージャー経由のリモート接続でしょう。

という訳で以下コマンドで接続してみますが、
aws ssm start-session --target mi-XXXXXXXXXXXXXXXXX;
残念ながら以下のエラーで接続が失敗します。
An error occurred (BadRequest) when calling the StartSession operation: Enable advanced-instances tier to use Session Manager with your on-premises instances
これを解消するには以下ドキュメントの通り、

プランをアドバンスドにする必要があります。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-manager.html#session-manager-features

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/fleet-manager-enable-advanced-instances-tier.html
なおアドバンスドを利用する場合は、

アクティベーションを使用して登録されたインスタンス数に応じて料金が発生します。


プラン
料金について


スタンダード
追加料金なし (デフォルト)  
アカウントごとにリージョンあたり最大 1,000 までの制限

アドバンスド
アドバンスドオンプレミスインスタンスごとに時間あたり 0.00695 USD  
無料利用枠なし

今回は AWS CLI で設定してみます。

まずアカウント ID とリージョンを環境変数に設定しておきます。
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text);
REGION=ap-northeast-1;
プランのデフォルト値は以下のように standard となっています。
aws ssm get-service-setting \
    --setting-id "arn:aws:ssm:$REGION:$ACCOUNT_ID:servicesetting/ssm/managed-instance/activation-tier";

{
    "ServiceSetting": {
        "SettingId": "/ssm/managed-instance/activation-tier",
        "SettingValue": "standard",
        "LastModifiedDate": "2020-01-16T09:55:08.867000+09:00",
        "LastModifiedUser": "System",
        "ARN": "arn:aws:ssm:ap-northeast-1:XXXXXXXXXXX:servicesetting/ssm/managed-instance/activation-tier",
        "Status": "Default"
    }
}
以下のコマンドでプランをアドバンスドに切り替えられます。
aws ssm update-service-setting \
    --setting-id "arn:aws:ssm:$REGION:$ACCOUNT_ID:servicesetting/ssm/managed-instance/activation-tier" \
    --setting-value advanced;
再度確認してみると、advanced に切り替わっています。
aws ssm get-service-setting \
    --setting-id "arn:aws:ssm:$REGION:$ACCOUNT_ID:servicesetting/ssm/managed-instance/activation-tier";

{
    "ServiceSetting": {
        "SettingId": "/ssm/managed-instance/activation-tier",
        "SettingValue": "advanced",
        "LastModifiedDate": "2025-05-25T16:34:14.562000+09:00",
        "LastModifiedUser": "arn:aws:iam::XXXXXXXXXXX:user/XXXXXXXXXXX",
        "ARN": "arn:aws:ssm:ap-northeast-1:XXXXXXXXXXX:servicesetting/ssm/managed-instance/activation-tier",
        "Status": "Customized"
    }
}
この状態で以下のコマンドを実行すると、正常に接続できるようになっています。
$ aws ssm start-session --target mi-XXXXXXXXXXXXXXXXX;

Starting session with SessionId: XXXXXXXXXX-XXXXXXXXXXXXXXXXXXXXXXX
$ whoami
ssm-user
$ hostname
server-name-01
AWS 上のインスタンスやオンプレミスインスタンス問わず、

おそらくこの機能を一番使うのではないでしょうか。
個人的には旅行中などに発作的に自宅のサーバーが気になるときがあるので、

この機能はぜひ使いたいですね。
なおプランは以下コマンドで戻すことができます。

うっかりアドバンスドのままオンプレインスタンスを登録していると料金がかかるため、

おうちで利用する場合、普段使わないときはスタンダードにしておくのが良さそうです。
aws ssm update-service-setting \
    --setting-id "arn:aws:ssm:$REGION:$ACCOUNT_ID:servicesetting/ssm/managed-instance/activation-tier" \
    --setting-value standard;
 Run Command次によく使うのはおそらく Run Command でしょう。

そしてこれは追加料金がかかりません、素晴らしい！
AWS CLI であれば以下のように実行して、
aws ssm send-command \
    --document-name "AWS-RunShellScript" \
    --document-version "1" \
    --targets "Key=instanceids,Values=mi-0bf6b6fe13e386017" \
    --parameters "commands='hostname'" \
    --query Command.CommandId;
以下コマンドで実行結果を確認できます。
aws ssm get-command-invocation \
  --command-id XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX \
  --instance-id mi-XXXXXXXXXXXXXXXXX;
お手軽にコマンドを実行できるので、普段使いしやすいのがいいですね。

Ansible など本格的に IaC を組むほどではないコマンドや、一括で実行したい一度きりのコマンドなど、わりかしこれ一つで何とかなりそうな気がします。
 Fleet Manager次は Fleet Manager です。

そしてこれも追加料金がかかりません、素晴らしい！

が、一部機能を利用するためにSSM Session ManagerにてKMSキーを設定する必要があるため、全機能を使う場合は間接的に料金がかかります。
Fleet Manager はマネージドインスタンスを状態を統合的に確認できるツールです。

例えば以下のように本来であれば実機にログインして確認したり作業する必要がある内容を、

マネジメントコンソールから実行できます。
ディレクトリ、ファイルの確認や作成
10 秒単位のリアルタイムのメトリクス
プロセスの確認や作成
OS ユーザー、グループの確認や作成
実運用でマネジメントコンソールから OS レベルの作業をするケースは少ないと思いますが、

SSM Agent が機能している限り使える機能なので、緊急時の対応などで活用できそうです。
 全般情報
 ファイルシステム
 パフォーマンスカウンター
 プロセス
 ユーザーとグループ
なおデフォルトではファイルシステム/パフォーマンスカウンター/プロセスを表示しようとするとエラーが出ます。
表示させるためには、SSM Session Manager にて KMS 暗号化を設定する必要があります。
今回は事前に Terraform で作成した KMS を利用して設定します、

私の環境では設定から数分後には正常に表示できるようになっていました。
 Patch Manager最後は Patch Manager です。

そしてこれも追加料金がかかりません、素晴らしい！
ただしパッチマネージャーを使用してオンプレミス上でホストされる Microsoft アプリケーションをパッチしたい場合は、インスタンス枠をアドバンスドにする必要があります。
https://aws.amazon.com/jp/systems-manager/pricing/
パッチマネージャーでカスタマイズしたパッチを適用する場合、以下の作業が必要となります。
パッチベースラインの作成 (定義済/カスタム)
パッチグループの作成 (管理対象を規定)
パッチベースラインにパッチグループを追加
パッチ適用の MaintenanceWindow を作成
ただし私がパッチマネージャー初心者なのと今回はお試しで使いたいため、

設定なしで利用できるオンデマンドのパッチ適用を使ってみます。
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/patch-manager-patch-now-on-demand.html
オンデマンドのパッチ適用では、OS ごとのデフォルトのパッチベースラインが利用されます。

今回は特にパッチベースラインを設定していないので、AWS が用意しているUbuntu Serverのパッチベースラインが利用されます。
実行方法は簡単で、パッチマネージャーの画面から「今すぐパッチ適用」をクリックして、
今回はお試しなのでスキャンだけ実行してみます。
だいたい 30 分ぐらいで実行が完了しました。
スキャンの結果の概要はパッチマネージャーのダッシュボードから確認でき、
詳細はコンプライアンスレポートから確認できます。
今回は以下の一部のライブラリで適用すべきパッチが検知されているようです。
個人的にはおうちのサーバーはセキュリティーがなおざりになりがちなので、

まとめてパッチ適用ができるのは大変便利ですね。

これからは気が向いたタイミングでちょこちょこ実行してみようと思います。
 お掃除いろんなサービスを触り散らかしたのでお片付けをしましょう。
 マネージドインスタンス 登録解除以下のコマンドでまとめてマネージドインスタンスの登録を解除します。

先頭が「mi-」から始まるインスタンスをすべて解除しています。
aws ssm describe-instance-information \
  --query "InstanceInformationList[].InstanceId" \
  --output text | \
  tr '\t' '\n' | grep '^mi-' | \
  xargs -n1 -I{} aws ssm deregister-managed-instance --instance-id {}
その後以下コマンドでマネージドインスタンスが無くなっていることが確認できます。
aws ssm describe-instance-information
 オンプレインスタンス SSM Agent 削除公式だと削除の仕組みが用意されていなかったので、削除用の プレイブック を用意しました。
ssm_uninstall.yml
---
- name: Uninstall SSM Agent from Debian/Ubuntu
  hosts: home_servers
  become: true

  tasks:
    - name: clear SSM agent registration
      ansible.builtin.command:
        cmd: sudo /snap/amazon-ssm-agent/current/amazon-ssm-agent -register -clear

    - name: Stop SSM agent service
      ansible.builtin.command:
        cmd: snap stop amazon-ssm-agent
      ignore_errors: true

    - name: Remove SSM agent snap package
      ansible.builtin.command:
        cmd: snap remove amazon-ssm-agent
      ignore_errors: true

    - name: Remove root aws credentials
      ansible.builtin.file:
        path: /root/.aws
        state: absent

    - name: Remove SSM configuration directory
      ansible.builtin.file:
        path: /etc/amazon/ssm
        state: absent

    - name: Remove SSM data directory
      ansible.builtin.file:
        path: /var/lib/amazon/ssm
        state: absent

    - name: Remove SSM log directory
      ansible.builtin.file:
        path: /var/log/amazon/ssm
        state: absent

    - name: Remove temporary SSM installer directory
      ansible.builtin.file:
        path: /tmp/ssm
        state: absent

    - name: Check if SSM agent is completely removed
      ansible.builtin.command:
        cmd: snap list amazon-ssm-agent
      register: ssm_check
      failed_when: false
      changed_when: false

    - name: Display removal status
      ansible.builtin.debug:
        msg: "SSM Agent removal completed. Status: {{ 'Successfully removed' if ssm_check.rc != 0 else 'Still installed' }}" 

Ubuntu Server の場合 Snap で SSM Agent がインストールされているためそれの削除、

また SSM Agent に関連した設定ファイルの削除を実施しています。
なお アクティベーションの過程で /root/.aws/credentials にてシークレット情報が定義されているので、

それも合わせて削除しています。
ansible-playbook -i inventory.ini ssm_uninstall.yml -v
 SSM Sessoin Manager KMS キー登録解除暗号化に利用した KMS キーの登録を解除しておきます。

対象の KMS キーを削除しても設定は解除されないので、忘れずに実施しましょう。
 インスタンス プラン 修正プランをアドバンスドからスタンダードに戻しておきます。
aws ssm update-service-setting \
    --setting-id "arn:aws:ssm:$REGION:$ACCOUNT_ID:servicesetting/ssm/managed-instance/activation-tier" \
    --setting-value standard
aws ssm get-service-setting \
    --setting-id "arn:aws:ssm:$REGION:$ACCOUNT_ID:servicesetting/ssm/managed-instance/activation-tier"
 Terraform リソース削除作成した Terraform リソースを削除します。

これで本記事で作成したすべてのリソースの設定値戻し、および削除が完了しました。
terraform destroy;
 さいごに以上、おうち de AWS　～AWS Systems Manager 編～でした。
AWS Systems Manager が多種多様なサービスを提供してるためちょっとボリューミィーになってしましたが、改めて便利さが知れるいい機会になりました。

また無料で利用できるサービスが多いので、そういった意味でもおうちでも使いやすくていいなぁと思いました。
これを機に、皆さんもおうちに転がっているサーバーに SSM Agent を入れて AWS 上で管理してみてはいかがでしょうか。
また今後も定期的におうちで活用できる AWS サービスを模索してブログにしてきますので、

その際はまた見ていただければ幸いです。
おうちでAWS　～AWS Systems Manager 編～

はじめに

AWS Systems Manager とは？

使う方法

料金について

実行環境

作業用PC

管理対象サーバー

セットアップ

1.AWS 側

2.おうち側

(オプション) プライベートキーの自動ローテーションを設定する

使ってみた

Session Manager

Run Command

Fleet Manager

全般情報

ファイルシステム

パフォーマンスカウンター

プロセス

ユーザーとグループ

Patch Manager

お掃除

マネージドインスタンス登録解除

オンプレインスタンス SSM Agent 削除

SSM Sessoin Manager KMS キー登録解除

インスタンスプラン修正

Terraform リソース削除

さいごに

関連記事

主なカテゴリ

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

お問い合わせ

運営会社

プラン	料金について
スタンダード	追加料金なし (デフォルト) アカウントごとにリージョンあたり最大 1,000 までの制限
アドバンスド	アドバンスドオンプレミスインスタンスごとに時間あたり 0.00695 USD 無料利用枠なし
はじめに

AWS Systems Manager とは？

使う方法

料金について

実行環境

作業用PC

管理対象サーバー

セットアップ

1.AWS 側

2.おうち側

(オプション) プライベートキーの自動ローテーションを設定する

使ってみた

Session Manager

Run Command

Fleet Manager

全般情報

ファイルシステム

パフォーマンスカウンター

プロセス

ユーザーとグループ

Patch Manager

お掃除

マネージドインスタンス 登録解除

オンプレインスタンス SSM Agent 削除

SSM Sessoin Manager KMS キー登録解除

インスタンス プラン 修正

Terraform リソース削除

さいごに

関連記事

主なカテゴリ

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

お問い合わせ

運営会社

マネージドインスタンス登録解除

インスタンスプラン修正
