サポート終了通知: 2027 AWS 年 6 月 30 日に、 は AMS Advanced のサポートを終了します。2027 年 6 月 30 日以降、AMS Advanced コンソールまたは AMS Advanced リソースにアクセスできなくなります。詳細については、「AMS Advanced サポート終了」を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AMS Advanced から AMS Accelerate への移行

AMS Advanced は 2027 年 6 月 30 日にサポートを終了します。この日以降、AMS Advanced の運用機能は機能しなくなり、すべてのお客様はサービスからオフボードされます。基盤となる AWS インフラストラクチャとワークロードは影響を受けません。AMS Advanced 管理レイヤーのみが削除されます。

このガイドは、移行中に何が変化し、どのようなアクションを実行する必要があるかを理解するのに役立ちます。AMS Accelerate は、インシデント管理、パッチ管理、バックアップ管理、セキュリティモニタリングを既存の AWS アカウントに直接提供し続けます。ワークロードは移行を必要とせずに維持されます。

AMS Advanced と Accelerate の違い

AMS Advanced は予防モデルを使用します。事前審査済みの自動変更 (変更タイプ) のライブラリを通じてのみ、または AMS エンジニアが実行する手動変更をリクエストして、環境を変更します。このアプローチにより、リスクのある変更がインフラストラクチャに到達するのを防ぐことができますが、独自のツール (Terraform、、 AWS CloudFormation AWS マネジメントコンソールなど) を使用して直接変更を行うことはできません。

AMS Accelerate はdetect-and-respondモデルを使用します。任意のツールとワークフローを使用して直接変更を行います。Accelerate は、変更を事前にブロックするのではなく、環境を監視し、リスクのある設定に対応します。各コントロールの設定方法に応じて、自動的に修正、通知、検出結果の報告を行います。これにより、AMS が引き続き環境を保護しながら、独自のペースで運用するための速度と自律性が得られます。

どちらのプランも、モニタリング、インシデント管理、パッチ管理、バックアップ管理、コスト最適化、レポート、専用 CSDM および CA サポートという同じコア運用サービスを共有しています。AMS Advanced に固有の一部の機能 (RFC システム、マネージドアクセス、エンドポイントセキュリティなど) は直接引き継がれません。次のセクションの表では、Accelerate で利用できるものと自分で管理する機能について説明します。

また、AMS オペレーションエンジニアがインスタンスにアクセスする方法を理解することも重要です。AMS Advanced では、AMS Ops は内部認証情報を使用して同じ踏み台インフラストラクチャを介して接続します。Accelerate では、AMS Ops AWS Systems Manager Session Manager は を使用して、インシデント対応、パッチ適用、または運用タスクに必要なときにインスタンスにアクセスします。これには、SSM エージェントをインスタンスで実行し、 AWS Systems Manager サービスとの通信を許可する IAM インスタンスプロファイルが必要です。AMS Accelerate は、EC2 インスタンスに SSM エージェント (および CloudWatch エージェント) をインストールして維持する自動インスタンス設定を提供します。CA は、オンボーディング中にこれを有効にするのに役立ちます。SSM エージェントをデプロイ済みで、互換性のあるインスタンスプロファイルがある場合は、追加のセットアップは必要ありません。

移行の仕組み

ワークロードは移行されません。アプリケーション、データ、インフラストラクチャは、正確な場所にとどまります。AMS Advanced からアカウントをオフボードし、Accelerate にオンボードします。これは運用上の移行であり、ワークロードの移行ではありません。

移行はアカウントごとに実行され、複数のアカウントで並行して続行できます。CSDM と CA は、オペレーションに適した日時を選択して、スケジューリングを調整します。移行中、AMS Accelerate コンソールと APIs が最初に有効になり、AMS Advanced コンソールと APIs は完全に削除される前に動作しなくなります。Accelerate コンソールと APIs が有効になったら、すぐに使用を開始する必要があります。AMS Advanced リソースの削除にはアカウントあたり約 2 時間かかり、その間、古い AMS Advanced インターフェイスは機能しなくなります。ワークロードは、全体を通して正常に実行され続けます。

移行を通じてお客様をサポートする方法

AMS が Accelerate で引き続き管理する機能 (モニタリング、パッチ適用、バックアップ、インシデント管理) については、AMS がユーザーに代わって移行を処理します。これには、新しい設定のデプロイ、タグの適用、アラーム設定の変換、メンテナンスウィンドウの移行が含まれます。また、発生する質問や問題については、プロセス全体を通して AMS エンジニアにもアクセスできます。

CSDM と CA は、全体の主要な連絡先です。これらは、特定のアカウントに関連する内容を理解し、移行日を調整し、必要に応じて適切なチームとつながるのに役立ちます。2027 年 6 月 30 日より前にバッファを許可するには、2027 年 3 月 31 日までに移行を完了することをお勧めします。

追加の実践的な変更が必要な場合、Operations on Demand では、毎月 20 時間のブロックでチームと一緒に作業できるスキルのある AMS エンジニアにアクセスできます。また、四半期ごと (2026 年 9 月、2026 年 12 月、2027 年 3 月) にチェックインして、進捗状況を確認し、ブロック要因に対処し、タイムラインや優先順位が変わった場合は計画を調整します。

変更内容の概要

AMS Accelerate には、13 以上のリソースタイプ (Amazon RDS、Elastic Load Balancing、Amazon EFS、Amazon EKS、OpenSearch Service、Amazon FSx、NAT Gateway、VPN)、自動リソースタグ付け (Resource Tagger)、コスト最適化のための自動リソーススケジューリング (Resource Scheduler)、エージェントのデプロイのための自動インスタンス設定のモニタリングなど、AMS Advanced では利用できないいくつかの機能が含まれています。これらはオンボーディング直後に利用できます。

次の表は、 Accelerate で利用できるものと AMS Advanced との違いをまとめたものです。

EC2 インスタンスアクセス

AMS Advanced では、インスタンスアクセスは規範モデルに従います。AMS が管理する踏み台ホスト経由で接続し、認証に AMS が管理する Active Directory を使用し、RFCs。AMS は、誰がどのインスタンスにどのくらいの期間アクセスできるかを制御します。

AMS Accelerate では、独自のアクセス方法を選択します。規定のパスはありません。使用したり AWS Systems Manager Session Manager、企業ネットワーク経由で RDP/SSH を誘導したり、セキュリティ要件に合ったその他のアプローチを使用したりできます。

移行の一環として、AMS 踏み台ホストを削除し、Active Directory インフラストラクチャをお客様に引き渡します。既存のインスタンスはドメイン結合されたままで、AD 認証情報を使用してアクセスできます。アクセスのダウンタイムなしで検証済みです。AD が組織で機能する場合は、長期的なアクセス方法として引き続き使用できます。または、別のアプローチを設定するときに一時的に使用できます。いずれにしても、AD の信頼、ネットワーク接続、ドメイン設定は保持する必要があります。

必要な作業

既存のインスタンスでは、企業ユーザーまたはグループを AMS AD アクセスグループに追加して、永続的なアクセス権を持つようにする必要があります。AMS Advanced では、RFC プロセスによって一時的な 8 時間のアクセスウィンドウが付与されました。移行後、自動化は利用できなくなります。代わりに、ユーザーをアクセスグループの永続メンバーとして追加します。ユーザーを追加するグループと追加するツールに関するガイダンスを提供します。

ユーザーがプロビジョニングされると、AD 認証情報を使用して既存のネットワークパス (Direct Connect、VPN、または Transit Gateway) に直接接続されます。

新しいインスタンスの場合、AMS ブートストラップスクリプトは起動時に実行されなくなるため、以前は自動だった 2 つの設定が必要になりました。

アクセス管理: インスタンスにアクセスできるユーザーの所有権を取得します。AD 管理者アカウント、管理者ワークステーション、ユーザープロビジョニング用の自動化ツールが用意されています。アクセスポリシーは、永続的なグループメンバーシップであるか、独自のガバナンスツールによる時間制限付きアクセスであるか、Session Manager IAM ポリシーであるかにかかわらず、決定します。

AMS Amazon マシンイメージ (AMIs)

AMS Advanced では、AMS はサポートされているオペレーティングシステム用に毎月更新された AMIs を作成し、管理ソフトウェア、セキュリティエージェント、ドメイン参加スクリプトで事前設定されています。これらの AMIs は アカウントと共有され、変更管理システムを介して新しい EC2 インスタンスを起動するときに使用されます。

AMS AMI の本稼働は AMS Accelerate の一部ではありません。移行後、AMS は毎月の AMIs を生成またはアカウントと共有しなくなります。新しいインスタンスの起動と Auto Scaling グループ (ASG) の起動設定には、オペレーティングシステム用の標準提供 AWSの AMIs を使用します (EC2 コンソールまたは AWS AMI カタログから入手できます）。これらは定期的なセキュリティ更新 AWS で によって維持され、すべての新しいインスタンスに推奨されるベースです。起動テンプレートで AMS AMIs を参照する ASGs を使用する場合は、それらの参照を AWS AMIsまたは独自のカスタム AMIs に更新して、スケーリングイベントによって起動される新しいインスタンスがサポートされているイメージを使用していることを確認します。

既に共有されている既存の AMS AMIs は、オフボーディング中にすぐに共有解除されることはありません。ただし、2026 年 6 月 30 日より前に作成された AMIs は、2027 年 6 月 30 日に廃止されます。2026 年 6 月 30 日から 2027 年 6 月 30 日の間に作成された AMIs は、2027 年 6 月 30 日から 1 年間共有され続けます。

StandardAMI が提供するもの (プリベイクアプリケーション、強化された設定、組織固有のツールなど) を超えるカスタム AWS AMIs 要件がある場合は、EC2 Image Builder を使用して独自のパイプラインを構築できます。AMS でこれを管理したい場合は、Operations on Demand カタログに AMI Building and Vending サービスが含まれています。このオプションについては、CSDM にお問い合わせください。

エンドポイントのセキュリティ

AMS Advanced では、AMS は EC2 インスタンスに Trend Micro エンドポイントセキュリティをデプロイおよび管理します。これには、エージェントのインストール (インスタンスの起動ごとにブートスクリプトによって自動化）、エージェントのアクティベーション、イベントモニタリング、インシデントの作成が含まれます。AMS は、アカウント設定に応じて Deep Security Manager (DSM)、Cloud One、または Vision One プラットフォームを通じてこのインフラストラクチャを管理します。

移行の一環として、エンドポイントのセキュリティパスを選択します。Vision One (Trend Micro がホストする完全に SaaS プラットフォームで、オンプレミスの DSM インフラストラクチャを排除) に移行するか、選択した別のセキュリティベンダーに移行して、Trend Micro を続行します。いずれの場合も、エージェントのデプロイ、ライセンスの管理、アクティベーションの設定など、選択したベンダーでエージェントのライフサイクルの所有権を取得します。AMS は移行中に EPS スタックをオフボードし、ブートスクリプトはインスタンスの起動時に Trend Micro エージェントをインストールまたはアクティブ化しなくなるため、これは Accelerate に移行する前に完了する必要があります。

オプション 1: Trend Micro Vision One (SaaS) の使用を継続する

Vision One は、 と統合されるクラウドネイティブの Trend Micro プラットフォームです AWS Security Hub。AMS は、オフボーディング前に現在のプラットフォーム (DSM または Cloud One) から Vision One への移行を支援します。Vision One では、Trend Micro と直接連携してエージェントのライフサイクル管理を行います。現在 DSM を使用している場合、移行パスはシーケンシャルです。DSM から Cloud One、Cloud One から Vision One です。Vision One では、セキュリティアラートが に送信されます AWS Security Hub。 AWS Security Incident Response (SIR) にもオンボードしているお客様は、 を通じて継続的なイベントモニタリングとインシデント対応を受けることができます AWS。

オプション 2: 別のエンドポイントセキュリティソリューションを使用する

選択したエンドポイントセキュリティソリューションを選択、デプロイ、管理します。AMS はインスタンスから Trend Micro エージェントを削除し、EPS スタックをオフボードします。選択したベンダーを立ち上げて実行するのはお客様の責任です。オプションで、選択したソリューションを と統合 AWS Security Hub して SIR カバレッジを実現できます。

どちらのオプションでも、エージェントライフサイクル全体を所有し、インスタンスへのエージェントのデプロイ (独自のオートメーション、SSM ステートマネージャー、カスタム AMIs、または設定管理ツールを使用）、ベンダーのライセンスとアクティベーションの認証情報の維持、ベンダーのダッシュボードまたは によるイベントモニタリングの設定を行います AWS Security Hub。

モニタリングとアラーム

AMS Advanced では、アラームマネージャーはすべてのマネージド EC2 インスタンスの CloudWatch アラームを自動的に作成し、しきい値を変更するサービスリクエストを送信します。AMS Accelerate では、AMS はユーザーに代わってアラームの作成と管理を継続しますが、モデルはタグ駆動型であり、AMS はモニタリングタグが適用されたインスタンスをモニタリングします。また、サービスリクエストを送信 AWS AppConfig せずに を通じてアカウント内で直接しきい値をカスタマイズします。また、カバレッジは EC2 と Redshift から、Amazon RDS、Elastic Load Balancing、Amazon EFS、Amazon EKS、OpenSearch Service、Amazon FSx、NAT Gateway、VPN など、13 以上のリソースタイプに拡張されます。

必要な作業

継続性をモニタリングするために手動アクションは必要ありません。AMS は、移行中に既存の EC2 インスタンスにモニタリングタグを適用し、現在のアラームのカスタマイズを Accelerate 設定形式に変換します。CA は、移行を開始する前に、翻訳された設定を確認します。

変更点

アラーム名とデフォルトのしきい値は、AMS Advanced と Accelerate で異なります (AMS Advanced のデフォルトは ~85%、 Accelerate は ~95% でアラートノイズを低減します）。特定のアラーム名を参照するダッシュボード、ランブック、またはアラートルーティングがある場合は、移行後に更新します。AMS Advanced 固有のインフラストラクチャをモニタリングする 3 つの AMS Advanced 固有のアラーム (ログエージェントのハード障害、ルートボリューム Inode 使用率、壊れたセキュアチャネル) は削除され、Accelerate に引き継がれません。移行後、モニタリングカバレッジを受信するには、新しい EC2 インスタンスにタグを付ける必要があります。AMS Resource Tagger を使用して、定義したルールに基づいてタグを自動的に適用するか、手動で適用します。

バックアップの管理

既存の復旧ポイントは変更されず、移行中もアクセスできます。バックアップカバレッジにギャップはなく、データは削除されません。必要に応じて、既存の復旧ポイントから復元を続行できます。

移行後、AMS Accelerate はマネージドプラン、スケジュール、ボールト AWS Backup を使用して を通じてリソースを保護します。バックアップスケジュールと保持期間は、現在の設定と一貫しています。アカウントの既存のバックアップ設定によっては、Accelerate は既存のボールトを再利用するのではなく、更新された名前で新しいボールトを作成する場合があります。その場合、新しいバックアップが新しいバックアップに書き込まれる間、履歴復旧ポイントは元のボールトで引き続き使用できます。

保持期間、スケジュール、ボールト設定、暗号化キーは、 AWS Backup コンソールまたは任意の infrastructure-as-code ツールから直接設定できます。いずれかのボールトでボールトロックが有効になっている場合、ロックされた復旧ポイントは設定された保持期間に従って保持されます。

必要な作業

バックアップの継続性を維持するためのアクションは必要ありません。

変更管理と設定のコンプライアンス

AMS Advanced では、変更管理システムが環境で発生する処理を制御します。事前に審査された変更タイプのライブラリから変更リクエスト (RFCs) を送信すると、AMS がユーザーに代わってそれらを実行します。自動化されていない変更の場合、AMS エンジニアは手動で変更を確認して実行します。この予防モデルでは、承認されたテスト済みの変更のみがインフラストラクチャに到達しますが、ネイティブ AWS ツール (コンソール、CLI、Terraform AWS CloudFormation) を使用して直接変更を行うことはできません。

AMS Accelerate では、任意のツールとワークフローを使用して直接変更を行います。RFC システムは Accelerate に存在しません。代わりに、AMS は設定コンプライアンスを通じて環境を保護します。これは、セキュリティと運用のベストプラクティスに照らしてリソース設定を継続的に評価する AWS Config ルールのライブラリです。これはdetect-and-respondモデルです。変更が発生する前にブロックするのではなく、AMS は適用後にリスクのある設定を検出し、制御するルールに従って応答します。

Accelerate での設定コンプライアンスの仕組み

オンボーディング中に CA でレスポンスレベルを設定し、いつでも調整できます。

対象

Accelerate には、IAM とアクセスコントロール、ネットワークと VPC セキュリティ、暗号化 (EBS、Amazon RDS、Amazon S3)、ログ記録と監査証跡の整合性、データベースとストレージの設定、サーバーレスリソースをカバーする約 87 の AWS Config ルールが含まれています。これは、AMS Advanced よりも広範囲にカバーされています。AMS Advanced では、約 24 ～ 27 のルール (SALZ または MALZ によって異なります) がデプロイされ、その多くは顧客のセキュリティ体制ではなく、AMS 内部サービス動作の適用に関連しています。新しい AWS サービスとコンプライアンス標準がサポートされるため、時間の経過とともに追加のコントロールが追加されます。

必要な作業

移行にアクションは必要ありません。AMS は Accelerate オンボーディング中に AWS Config ルールをデプロイします。CA は、使用可能なルールを順を追って説明し、各ルールのレスポンスレベルを設定するのに役立ちます。現在 AMS Advanced アカウントにカスタム AWS Config ルールがデプロイされている場合、それらは保持されます。オフボーディング中に削除されることはありません。

ガバナンスのために RFC システムに依存していたお客様にとっての変更点

組織が RFC システムをガバナンスコントロールとして使用した場合 (変更を行う前に承認ワークフローを要求するなど）、独自のツールを使用して同等のコントロールを実装する必要があります。一般的なアプローチには、アクセス許可の境界を適用するための AWS サービスコントロールポリシー (SCPs)、機密性の高い API コールの AWS CloudTrail アラート、CI/CD パイプラインまたは変更管理ツール (ServiceNow、Jira など) の承認ワークフローなどがあります。CA は、現在の RFC ベースのワークフローにマッピングされるガバナンスパターンを特定するのに役立ちます。

変更の実践的な支援が必要なお客様向けに、Operations on Demand は、熟練した AMS エンジニアを通じて 20 時間の月次ブロックで厳選された変更サポートを提供します。これは、移行期間中、直接アクセスに精通している間、またはエキスパートサポートが必要な複雑な変更に対して継続的に役立ちます。

パッチ管理

AMS Advanced では、パッチ管理は、RFC システムを介して設定されたメンテナンスウィンドウを持つ AMS パッチオーケストレーターを使用します。AMS は、パッチベースライン、スケジューリング、通知、およびデフォルトのメンテナンスウィンドウを管理します。カスタムメンテナンスウィンドウは、変更タイプによって作成および更新されます。

AMS Accelerate では、パッチ適用スケジュール、ベースライン、メンテナンスウィンドウは移行中も保持されます。同じタグベースのパッチ適用モデルが適用され、インスタンスには同じスケジュールで引き続きパッチが適用されます。一部の運用詳細 (通知配信、デフォルトのメンテナンスウィンドウの管理方法、変更プロセス) は変更されますが、パッチ適用動作は一貫しています。

必要な作業

移行を開始する前に、CSDM と CA はパッチイベントの通知 E メールアドレスを確認します。通知は AMS Advanced 配信モデルから Accelerate 通知フレームワークに移行されるため、適切なアドレスで受信し続ける必要があります。また、既存のパッチコンプライアンスレポート履歴を保持するかどうかも確認します。

移行中の動作

移行は、アクティブなメンテナンスウィンドウの実行外でスケジュールされます。移行ウィンドウ中にパッチは実行されません。既存のメンテナンスウィンドウ、パッチベースライン、スケジュール、OS ごとの設定は Accelerate インフラストラクチャに移行されます。メンテナンスウィンドウの名前と動作は保持されるため、運用プロセスの一貫性が保たれます。

変更点

移行後、以下の運用の詳細が変更されます。

継続性: 移行中にパッチ適用が停止することはありません。AMS Advanced インフラストラクチャが削除される前に、メンテナンスウィンドウとベースラインが Accelerate 側で機能するように移行が順序付けられます。問題が検出された場合は、移行を元に戻して AMS Advanced パッチ適用を復元できます。

タイムラインとサポート

2027 年 6 月 30 日のシャットダウン前にバッファを許可するには、2027 年 3 月 31 日までに移行を完了することをお勧めします。CSDM と CA は移行中の主要な連絡先であり、環境に合わせた計画を作成するのに役立ちます。

移行期間中に変更を行うサポートが必要なお客様向けに、Operations on Demand は毎月のブロックで厳選された変更サポートを提供します。

AMS は四半期ごとのチェックポイント (2026 年 9 月、2026 年 12 月、2027 年 3 月) を実施して移行の進行状況をモニタリングし、必要に応じて追加のサポートを提供します。

関連リソース