AWS SSMの組織全体のノード一元管理機能検証から導き出された課題点

## はじめに
従来のAWS SSM(Systems Manager)によるノード管理は、AWS Organizationsを使用している場合であっても、稼働しているEC2インスタンス、ハイブリッド・サーバー、マルチクラウド環境で稼働しているサーバーは、各々のAWSアカウントのSSMのフリートマネージャー上でしか確認することができませんでした。
今回、2024年11月21日のAWS社からの発表により、AWS Organizationsを使用している場合、組織のAWSアカウントとリージョン内にある全てのマネージドインスタンス、アンマネージドインスタンスを一カ所で確認することが可能になったとの発表がありました。

https://aws.amazon.com/jp/about-aws/whats-new/2024/11/aws-systems-manager-experience-simplifying-node-management/

まだクラウド環境を使用していないオンプレミス環境において、稼働しているLinuxサーバーの状態を一元管理する為には、Zabbixと呼ばれる監視ソフトウェアを使用されることが一般的かなと思います。

https://www.zabbix.com/jp

今回の発表によりCloud上にLinuxを移行した場合(一部オンプレミス環境にサーバーを残す場合含む)には、このAWS SSMのノード一元管理機能の使用が期待できるため、個人のAWS環境を使用して当該機能の検証を実施しました。本記事では、当該機能を使用する為の設定手順、及び、機能検証結果から判明した現時点での課題と思われるポイントをご紹介します。

## 機能検証
### 検証環境構成
今回の検証環境構成図は下記になります。
![SSM構成図.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/342c90d9-b026-f9e9-7763-9009b34303b0.png)

使用するAWSアカウントは下記の3つになります。
* AWS Organizations Management Account　
    * 組織の管理者アカウントです。アカウントIDは「1xxxxxxx」としておきます。
* AWS Organizations Member Account (SSM Manager)
    * 組織のメンバーアカウント、かつ、SSMの管理権限を委任されたアカウントです。
    * アカウントIDは「2xxxxxxx」としておきます。

:::note warn
下記のドキュメントにも記載がありますが、今回検証する組織全体でのSSMのノード一元管理機能を有効にするためには、組織の管理者アカウントとは別のメンバーアカウントの中からSSMの管理者アカウントをアサインする必要がありますので、ご注意ください。

https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-organizations.html

:::

* AWS Organizations Member Account
  *  組織のメンバーアカウントです。アカウントIDは「8xxxxxxx」としておきます。

各々のアカウントにつき、1つのプライベートEC2インスタンスを稼働させます。また、各々のVPCにはインターフェース・エンドポイントを設置し、PrivateLinkを使用してSSMとプライベート通信を行います。
また、AWS外のハイブリッド環境(自宅PC)で稼働しているVMWare上のLinuxも、組織の管理者アカウントの下でSSMのマネージドインスタンスとして管理しています。このAWSのEC2インスタンス以外のサーバーをSSMでマネージドインスタンスとして管理させるための設定手順については、下記の記事で纏めていますので、そちらを参照ください。

https://qiita.com/duelist2020jp/items/e4c8f09a063c28685a0d

### 事前準備
各々のAWSアカウントにおいて、下記3つのCloudFormationのyamlファイルを使用して、スタックを作成しておきます。
* ネットワーク環境の作成
<details><summary>CreateNetwork-Stack.yaml</summary>

```yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: Sample Script for Creating NetWork Stack (VPC,Public Subnet,Private Subnet,Internet Gateway,Nat Gateway,Route Table)
Parameters:
  Azname:
    Description: Set 1st az-name
    Type: String
    Default: ap-northeast-1a
    AllowedValues:
      - ap-northeast-1a
      - ap-northeast-1c
      - ap-northeast-1d
  VPCCidrBlock:
    Description: VPC Cidr Block
    Type: String
    Default: 10.0.0.0/16
  PublicSubnetCidrBlock:
    Description: Public Subnet Cidr Block for 1st az-name
    Type: String
    Default: 10.0.1.0/24
  PrivateSubnetCidrBlock:
    Description: Private Subnet Cidr Block for 1st az-name
    Type: String
    Default: 10.0.2.0/24
      
Resources:
  MyVPC:
    Type: AWS::EC2::VPC
    Properties: 
      CidrBlock: !Ref VPCCidrBlock
      EnableDnsHostnames: 'true'
      EnableDnsSupport: 'true'
      Tags: 
        - Key: Name
          Value: My-vpc
  MyPublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: !Ref PublicSubnetCidrBlock
      AvailabilityZone: !Ref Azname
      Tags:
        - Key: Name
          Value: My-Public-Subnet
    DependsOn: MyVPC
  MyPrivateSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: !Ref PrivateSubnetCidrBlock
      AvailabilityZone: !Ref Azname
      Tags:
        - Key: Name
          Value: My-Private-Subnet
    DependsOn: MyVPC
  MyIGW:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: My-internet-gateway
    DependsOn: MyVPC
  MyIGWAttachToVPC:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref MyVPC
      InternetGatewayId: !Ref MyIGW 
  MyEIP:
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc
      Tags:
        - Key: Name
          Value: My-Elastic-IP
    DependsOn: MyIGWAttachToVPC
  MyNGW:
    Type: AWS::EC2::NatGateway
    Properties:
      AllocationId: !GetAtt MyEIP.AllocationId
      ConnectivityType: public
      SubnetId: !Ref MyPublicSubnet
      Tags:
        - Key: Name
          Value: My-NAT-Gateway
    DependsOn: MyIGWAttachToVPC
  MyPublicRtbl:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref MyVPC
      Tags:
        - Key: Name
          Value: My-Public-Rtbl
    DependsOn: MyIGW
  MyPublicRoute:
    Type: AWS::EC2::Route
    Properties:
      RouteTableId:
        Ref: MyPublicRtbl
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref MyIGW
  MyPublicSubnetRouteTblAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref MyPublicRtbl
      SubnetId: !Ref MyPublicSubnet
  MyPrivateRtbl:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref MyVPC
      Tags:
        - Key: Name
          Value: My-Private-Rtbl
  MyPrivateRoute:
    Type: AWS::EC2::Route
    Properties:
      RouteTableId:
        Ref: MyPrivateRtbl
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId: !Ref MyNGW
    DependsOn: MyNGW
  MyPrivateSubnetRouteTblAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref MyPrivateRtbl
      SubnetId: !Ref MyPrivateSubnet
  MyPrivateSubnetSecGrp:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: My-Private-SecGrp
      VpcId: !Ref MyVPC
      Tags:
        - Key: Name
          Value: My-Private-SecGrp

Outputs:
  MyStackVPCID:
    Description: The ID of My VPC
    Value: !Ref MyVPC
    Export:
      Name: !Sub "${AWS::StackName}--VPCId"
  MyVPCCidrBlock:
    Description: The CIDR block of My VPC
    Value: !GetAtt MyVPC.CidrBlock
    Export:
      Name: !Sub "${AWS::StackName}--VPCCidrBlock"
  MyStackPublicSubnetID:
    Description: The ID of My Public Subnet for Azname
    Value: !Ref MyPublicSubnet
    Export:
      Name: !Sub "${AWS::StackName}--PublicSubnetID"
  MyStackPrivateSubnetID:
    Description: The ID of My Private Subnet for Azname
    Value: !Ref MyPrivateSubnet
    Export:
      Name: !Sub "${AWS::StackName}--PrivateSubnetID"
  MyStackPrivateSubnetSecGrpID:
    Description: The ID of My Private Security Group
    Value: !Ref MyPrivateSubnetSecGrp
    Export:
      Name: !Sub "${AWS::StackName}--PrivateSubnetSecGrpID"
```
</details>

* プライベートEC2インスタンスの作成
<details><summary>CreatePrivateEC2-Stack.yaml</summary>

```yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: Sample Script for Creating Private EC2 Instance

Parameters:
  MyNetworkStackName:
    Description: This stack name is already created Network Stack for provisioning Private EC2 Instance
    Type: String
    Default: Network-Stack

Resources:
  MyKey:
    Type: AWS::EC2::KeyPair
    Properties:
      KeyName: MyEC2Key
      PublicKeyMaterial: '{{resolve:ssm:publickeymaterial}}'
      Tags:
        - Key: Name
          Value: My-Key
  MyPrivateInstance:
    Type: AWS::EC2::Instance
    Properties:
      CreditSpecification: 
        CPUCredits: standard
      InstanceType: t2.micro
      KeyName: !Ref MyKey
      ImageId: ami-094dc5cf74289dfbc
      IamInstanceProfile: EC2Instance_Role
      NetworkInterfaces:
        - AssociatePublicIpAddress: "false"
          DeviceIndex: "0"
          SubnetId: 
            Fn::ImportValue: 
              !Sub "${MyNetworkStackName}--PrivateSubnetID"
          GroupSet: 
            -
              Fn::ImportValue: 
                !Sub "${MyNetworkStackName}--PrivateSubnetSecGrpID"
      Tags:
        - Key: Name
          Value: Private-instance-03
  
Outputs:
  MyPrivateInstanceIPaddr:
    Description: My Private Instance's Private IP address for AzName
    Value: !GetAtt MyPrivateInstance.PrivateIp

```
</details>

* SSMに対するインターフェースエンドポイントの作成
<details><summary>CreateSSMEndpoint-Stack.yaml</summary>

```yaml
AWSTemplateFormatVersion: '2010-09-09'
Description: Sample Script for Creating VPC Endpoint with SSM and SSM-Messages and EC2-Messages

Parameters:
  MyNetworkStackName:
    Description: This stack name is already created MyNetwork Stack for provisioning EC2 Instance
    Type: String
    Default: Network-Stack

Resources:
  VPCEndpointSecGrp:  
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Security Group for VPC Endpoint
      VpcId:
        Fn::ImportValue:
          !Sub "${MyNetworkStackName}--VPCId"
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp:
            Fn::ImportValue:
              !Sub "${MyNetworkStackName}--VPCCidrBlock"
      Tags:
      - Key: Name
        Value: VPCEndpoint-Security-Group
  MySSMEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      VpcEndpointType: Interface
      ServiceName: 
        !Sub "com.amazonaws.${AWS::Region}.ssm"
      PrivateDnsEnabled: true
      VpcId:
        Fn::ImportValue:
          !Sub "${MyNetworkStackName}--VPCId"
      SubnetIds:
        - Fn::ImportValue:
              !Sub "${MyNetworkStackName}--PrivateSubnetID"  
      SecurityGroupIds: # Must be a list of one or more
        - !Ref VPCEndpointSecGrp
      PolicyDocument: 
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal: "*"
            Action:
              - "*"
            Resource:
              - "*"
    DependsOn: VPCEndpointSecGrp
  MySSMMSGEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      VpcEndpointType: Interface
      ServiceName: 
        !Sub "com.amazonaws.${AWS::Region}.ssmmessages"
      PrivateDnsEnabled: true
      VpcId:
        Fn::ImportValue:
          !Sub "${MyNetworkStackName}--VPCId"
      SubnetIds:
        - Fn::ImportValue:
              !Sub "${MyNetworkStackName}--PrivateSubnetID"  
      SecurityGroupIds: # Must be a list of one or more
        - !Ref VPCEndpointSecGrp
      PolicyDocument: 
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal: "*"
            Action:
              - "*"
            Resource:
              - "*"
    DependsOn: VPCEndpointSecGrp
  MySSMEC2MSGEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      VpcEndpointType: Interface
      ServiceName: 
        !Sub "com.amazonaws.${AWS::Region}.ec2messages"
      PrivateDnsEnabled: true
      VpcId:
        Fn::ImportValue:
          !Sub "${MyNetworkStackName}--VPCId"
      SubnetIds:
        - Fn::ImportValue:
              !Sub "${MyNetworkStackName}--PrivateSubnetID"  
      SecurityGroupIds: # Must be a list of one or more
        - !Ref VPCEndpointSecGrp
      PolicyDocument: 
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal: "*"
            Action:
              - "*"
            Resource:
              - "*"
    DependsOn: VPCEndpointSecGrp
```
</details>

### 設定手順
下記ドキュメントの記載に従い設定していきます。

https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-organizations.html

#### 組織の管理アカウントでの設定作業
AWSのマネージドコンソールから「Systems Manager」のトップページに遷移し、下記図の赤枠部分の「使用開始」ボタンを押下します。
![p1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/c83bfdb1-8978-c6ee-ff22-15c95eeb0768.jpeg)

:::note info
組織のメンバーアカウントの場合は、下記図に見られるように「Systems Manager」のトップページの記載内容が少し異なっているようです。
![p20.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/8f6c1866-93b4-0c79-3512-4ef82f608ec8.jpeg)
:::

「使用開始」ボタンを押下後、下記画面に遷移します。ここで、SSMの管理を任せるアカウントID(2xxxxxx)を入力し、「確認」ボタンを押下します。
![p1_2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/f335bc51-c066-9fe2-1b39-58f84e5b3a61.jpeg)
ちなみに、この画面で組織の管理アカウントIDを入力した場合は、先に述べた仕様の通り登録エラーになります。
![p1_1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/87a9754e-8d4f-3637-f837-4b5c68eef098.jpeg)

SSM管理者登録が終わると、下記のように表示されます。
![p2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/46be2b83-1ab5-ceec-ef3f-133acb438620.jpeg)
「管理者として登録されました」と言っている割には「委任された管理者なし」と表示されるというのはおかしいとは思いますが、一旦ここで組織の管理アカウントでの設定作業は終了です。

#### SSM管理者アカウントによる設定作業
SSM管理者アカウントでAWSマネージドコンソールにログオンし、「Systems Manager」の画面に遷移後、左側のメニューにある「設定」をクリックすると下記図のようになります。
![p3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/55565eee-fc2b-33e0-c35c-17436ba157d8.jpeg)
AWSのドキュメントには「Systems Managerを有効にする」を選択するようにと書かれていますが、画面上既に有効になっており、「編集」というボタンが表示されています。ここもドキュメントには記載が見られない怪しいと思われる要素の1つです。先進めするため、「編集」ボタンを押下すると、下記図に遷移します。
![p4.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/0aca00c2-e481-10c7-7a3b-b6abe2ec144f.jpeg)
ホームリージョンには、デフォルトで通常使用しているリージョン名が表示されます。リージョンは変更したり、他にも追加することが可能ですが、IAM Identity Centerを使用しており、そこでホームリージョンを指定している場合には、そのリージョン名と合せる必要があります。筆者の環境では、IAM Identity Centerでホームリージョンに東京リージョンを指定しているため、リージョンは「Custom」を選択し、ap-northeast-1以外のリージョンからチェックを外します。
![p5.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/1488e25b-86b2-3961-8696-60d50e506697.jpeg)
上記図の概要に記載されている「管理アカウントを除く組織内のすべてのアカウントでSystems Managerを有効にします」という記述に関して、ここでの管理アカウントとは組織の管理アカウント、SSM管理アカウントのいずれの事を言っているのかな？と気にはなりましたが、とりあえず「送信」ボタンを押下します。すると下記画面に見られるように設定が開始されます。
![p6.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/a7c58662-95f6-6dd5-501b-6d86968aa8e8.jpeg)
組織の大きさによって設定時間は変わるようですが、設定が終わると下記画面のようになります。
![p7.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/e75bd325-0fa4-afad-572d-b1455486dc43.jpeg)
内部的にはCloudFormationのスタックセットの実行を通して設定が行われていたようです。
* 組織の管理アカウントの場合
![p7_1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/05716029-c15a-13ab-d323-ff230331e8d9.jpeg)
* SSM管理アカウントの場合
![p7_2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/32990ae7-d04c-e94a-e7e0-b2ec64b6041b.jpeg)
* 組織のメンバーアカウントの場合
![p7_5.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/83f7d682-e2f8-a6b1-0472-4ead2a7448d2.jpeg)

### 設定結果確認 
設定が終わったので、SSM管理アカウントのAWSマネージドコンソールにおいて「Systems Manager」の「ノードのインサイトを確認」に遷移すると、下記図のようになりました。
![p8_1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/f5eecbf3-8f57-3502-f342-af238a5a6a8e.jpeg)
![p8_2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/c38778bf-5e69-a3f0-68b8-5071573a8004.jpeg)
Amazon QuickSightのダッシュボードみたいで、見やすくて良いなと感じたのは束の間、マネージドノードが2ノードしかないのは何故という素朴な疑問が生じました。そこで、この2ノードの内訳を見るために、画面左側のメニューにある「ノードを詳しく見る」をクリックし、ノードの詳細を確認します。
![p8_3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/50bb644c-5b97-773e-be2b-d36188e9784f.jpeg)
表示されているノードのアカウントIDを見ると「2xxxxxx」と「8xxxxxx」の2種類のインスタンスしかなく、組織の管理アカウント「1xxxxx」配下で稼働しているEC2インスタンスとハイブリッド・サーバーが表示されていませんでした。

## 検証を通して判明した課題点
### 課題点1 組織のメンバーアカウント配下のインスタンスしか一元表示されない。
当該新機能は組織のアカウント全てにおけるEC2インスタンス、外部のハイブリッド・サーバー、マルチクラウド環境で稼働しているサーバーを一カ所で表示できるというものであるにも関わらず、組織の管理アカウント配下のEC2インスタンスやサーバーについては表示されません。AWSドキュメントにも「組織の管理アカウントについては一元管理対象外とする」なんて記載はどこにも書いてありません。お客様の環境に当該新機能を提案して、いざ適用してみたら「一部表示されていないノードがある」となって騒ぎになりそうな気がします。
なお、組織の管理アカウントのAWSマネージドコンソールから「Systems Manager」→「ノードのインサイトを確認する」に遷移すると、下記のような表示がされました。
![p9.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/21f13ef9-3454-e8dc-1102-3725546ef041.jpeg)
「Systems Manager統合エクスペリエンスは、組織の管理アカウントでは使用できません。組織全体のノードを管理する委任された管理者アカウントxxxxxxに切り替えてください。」と書かれてはいますが、あくまでもノードの一元管理画面を見ることは組織の管理アカウントではできないというだけだと考えましたが、正直謎です。。
仮にこの課題点1が仕様だった場合には、AWSドキュメントに明記してほしいですし、そういう仕様ではないというのであれば不具合だと思われるので、修正いただけると嬉しいです。

### 課題点2 当該機能の無効化は、現状AWSマネージドコンソールからは実施できない。
下記のAWSドキュメントでは、SSM管理者アカウントでAWSマネージドコンソールにログオン→「Systems Manager」に遷移→「設定」画面から「無効にする」ボタンを押下するとあります。

https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-disable-integrated-console.html

![p11_1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/1f05ee11-ab71-67a8-2c63-1bfaceb7b5d1.jpeg)

上図の「無効にする」ボタンを押下すると、下記の確認画面が表示されます。
![p11_2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/cebaffe2-f94a-5fac-4a57-210648a21d7b.jpeg)
なんと、「無効」と入力しても赤枠箇所の「Disable」ボタンが押下できないのです。。。。
お客様の環境に当該新機能を適用して、想定外の事象が発生した場合、機能使用前の状態に戻すことになると思いますが、今のままだと戻しもできないのかと考えてしまいます。
これは明らかに不具合だと考えますが、以下の対応を行うことで、機能を無効にすることができました。

#### AWS CLIを使用した機能無効化手順
AWSのドキュメントには、組織の管理アカウントから、AWS CLIもしくはSDKを使用して、DeleteConfigurationManager APIをコールするようにと記載があります。ここでは、AWS CLIを使用して無効化を行いましたので、その手順を纏めました。無効化するためのコマンドは「aws ssm-quicksetup delete-configuration-manager」コマンドになります。

https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ssm-quicksetup/delete-configuration-manager.html

* AWS CLI V2の再インストール
  *  最初インストールされていたCLIのレベルが低かったからか、コマンド実行時「aws quick-setupなんてコマンドは存在しない。」と言われてエラーになりました。ですので、こういった新機能関連のコマンドを実行される際には、先にCLIのレベルを上げられることをお奨めします。少なくともCLIのレベルが2.22.4であれば大丈夫です。
```
C:\Users\testuser>aws --version
aws-cli/2.22.4 Python/3.12.6 Windows/11 exe/AMD64
```
* ManagerArnの確認
  * 「 aws ssm-quicksetup list-configuration-managers」コマンドを実行すれば、ManagerArnの確認が可能です。

https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ssm-quicksetup/list-configuration-managers.html

ただ、初めてコマンドを実行する際にはコマンド権限がなく、下記のようなエラーになりました。
```
C:\Users\testuser>aws ssm-quicksetup list-configuration-managers

An error occurred (AccessDeniedException) when calling the ListConfigurationManagers operation: User: arn:aws:iam::1xxxxxxxxxx:user/ProdUser is not authorized to perform: ssm-quicksetup:ListConfigurationManagers on resource: arn:aws:ssm-quicksetup:ap-northeast-1:1xxxxxxxxxx:/listConfigurationManagers
```
そこで、以下のようなカスタマーポリシーを作成し、AWS CLI実行ユーザーのグループに当該ポリシーをアタッチします。
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "ssm-quicksetup:*",
            "Resource": "*"
        }
    ]
}
```
再度コマンドを実行すると下記のような出力が得られ、ManagerArnを確認することができます。
```
C:\Users\kiyomasa>aws ssm-quicksetup list-configuration-managers
{
    "ConfigurationManagersList": [
        {
            "ConfigurationDefinitionSummaries": [
                {
                    "FirstClassParameters": {
                        "TargetOrganizationalUnits": "r-i2sa",
                        "TargetRegions": "ap-northeast-1"
                    },
                    "Id": "ixu9t",
                    "Type": "AWSQuickSetupType-SSM",
                    "TypeVersion": "1.0"
                }
            ],
            "Description": "",
            "ManagerArn": "arn:aws:ssm-quicksetup:ap-northeast-1:1xxxxxxxx:configuration-manager/19fc7f33-8cd9-477e-8e52-7bfe2621ae99",
:
(略)
```
:::note warn
AWSドキュメントには、ManagerArnのフォーマットは「arn:aws:ssm-quicksetup:account-id:configuration-manager/AWSQuickSetupType-SSM」だと書かれています。もしかしたらAWS SDKを使用してAPI経由で確認する場合にはこのフォーマットが正しいのかもしれませんが、実際に「aws ssm-quicksetup delete-configuration-manager」コマンドで、--manager-arnオプションにこのフォーマットを指定するとエラーになるのでご注意ください。(account-idには組織の管理アカウントIDを指定したとしても。)
:::

* 「aws ssm-quicksetup delete-configuration-manager」コマンドの実行
  * 先の「aws ssm-quicksetup list-configuration-managers」の実行結果から確認できたManagerArnを指定し、コマンドを実行します。(1xxxxxxxxxは、組織の管理アカウントID)
```
C:\Users\testuser>aws ssm-quicksetup delete-configuration-manager --manager-arn arn:aws:ssm-quicksetup:ap-northeast-1:1xxxxxxxxx:configuration-manager/19fc7f33-8cd9-477e-8e52-7bfe2621ae99

C:\Users\testuser>
```
上記の様に空のプロンプトが返ってきたらコマンド実行は正常終了しています。この後、SSM管理アカウントでAWSマネージドコンソールにログオンし、「Systems Manager」→「ノードのインサイトを確認」に遷移すると、しばらく時間はかかりますが、下記図に見られるように当該機能が無事無効化されたことを確認できました。
![p12.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/a0519ef1-0755-e708-aaad-1082e054ae64.jpeg)
とはいえ、かなり機能の戻し手順が煩雑となっていますので、この点は改善されることを期待します。

## 機能無効化後の後始末
機能は無効化されましたが、SSMアカウントの登録等については引き続き残っています。これらを綺麗にする場合は、以下の手順を実施します。
### 組織の管理アカウントでの作業
#### Systems Manager Quick-Setup機能の管理委任者アカウント登録解除
AWSマネージドコンソールにおいて、「Systems Manager」→「高速セットアップ」に遷移し、委任された管理者アカウントの登録情報を削除します。
![p14.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/5408a977-7bf3-eac7-43a6-b32df0c61d55.jpeg)
確認画面が表示されるので、「Confirm」ボタンを押下します。
![p15.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/79bdb645-f786-c5a2-88e4-b721d21267d8.jpeg)
下記のような画面に遷移できれば削除完了です。
![p16.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/b1421750-d031-8711-cdf6-6f1a372dd922.jpeg)

#### Systems Manager Explorer機能の管理委任者アカウント登録解除
AWSマネージドコンソールにおいて、「Systems Manager」→「エクスプローラー」→「設定」に遷移し、委任された管理者アカウントの登録情報を削除します。
![p19_3.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/ce741589-f9c7-ea71-5062-dbd9a10e397c.jpeg)
確認画面が表示されるので、「登録解除」ボタンを押下すれば解除完了です。
![p19_4.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/1c0a9a22-0366-7f8a-948e-0a3010240e5f.jpeg)

#### CloudFormationの管理委任者アカウント登録解除
AWSマネージドコンソールにおいて、「CloudFormation」→「StackSets」に遷移し、委任された管理者アカウントの登録を解除します。
![p19_1.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/65b2e711-aa59-96b6-994d-dc403bf52679.jpeg)
確認画面が出るので、「登録解除」ボタンを押下すれば解除完了です。
![p19_2.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/7bd7605c-f26f-fcde-d86d-d97ff33b1023.jpeg)

#### AWS Resource Explorerの管理委任者アカウント登録解除
AWSマネージドコンソールにおいて、「AWS Resource Exploler」に遷移し、「信頼されたアクセスを無効にする」ボタンを押下し、委任された管理者アカウントの登録を解除します。
![p19_5.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/6d92c7aa-a27e-8938-ecd2-a3b7672bdd0b.jpeg)
確認画面が出るので、「信頼されたアクセスを無効にする」ボタンを押下すれば、解除完了です。
![p19_6.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1567099/4a907a9f-2b29-cca6-6c5d-7aed8d21437a.jpeg)

## おわりに
今回は、2024年11月21日にAWS社より発表されたAWS Systems Manager(SSM)の組織全体のノードを一元管理する新機能に関する検証を実施しました。残念ながら想定していた結果を得ることはできませんでしたが、検証結果から導き出された課題点がクリアになれば、今までにないSSMのノード管理を実現することが可能になる良き機能になると思いますので、何かのタイミングで修正いただけると嬉しいです。