View a markdown version of this page

AWS 継続的なモダナイゼーションを変革する - AWS 変換
AWS Transform Continuous Modernization とは主な機能分析タイプ重要な概念の理解AWS Transform の継続的なモダナイゼーションの仕組み

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

AWS 継続的なモダナイゼーションを変革する

AWS Transform Continuous Modernization とは

AWS 継続的なモダナイゼーションを変換することで、ソースコードリポジトリの分析と修復が可能になります。GitHub 組織、GitLab グループ、Bitbucket ワークスペース、ローカルリポジトリを接続し、自動分析を実行して、コードベース全体の技術的負債、セキュリティの脆弱性、モダナイゼーションの機会、エージェントの準備状況を特定できます。

すべての分析と修復は、 認証情報 AWS アカウント を使用して で実行されます。ソースコードはお客様の管理下に置かれます。

注記

Kiro Power またはエージェントプラグインから始めることをお勧めします。エージェントスキルは、インフラストラクチャのプロビジョニング、ソース設定、分析の実行、結果のトリアージ、修復など、継続的なモダナイゼーションのセットアップ、オンボーディング、継続的な使用を調整します。インストール手順については、「デベロッパーツール」を参照してください。

主な機能

AWS 継続的なモダナイゼーションを変換すると、次の機能が提供されます。

  • Tech Debt Analysis — 古い依存関係、セキュリティの脆弱性、コード品質の問題、モダナイゼーションの機会がないかリポジトリをスキャンします。パッケージマニフェストまたは包括的なコードレベル分析全体でクイックメタデータスキャンを実行します。環境に合わせた変換定義を使用して、カスタム分析基準を定義します。

  • 自律修復 — 検証済みのプルリクエストを大規模に生成します。各検出結果は、関連する変換定義を使用して自動修正できます。修復はブランチを作成し、GitHub、GitLab、Bitbucket 全体で PRs/MRs を自動的に開きます。

  • レポート — 重要度、リポジトリ、分析タイプ別に結果を示す HTML レポートを生成します。修復の進行状況と結果の解決を経時的に追跡します。

  • 継続的モニタリング — 定期的な分析をスケジュールして、新しい問題がないかポートフォリオを継続的にモニタリングします。セットアップなしで AWS Transform マネージドインフラストラクチャで実行するか、Amazon EventBridge スケジューラを使用してプロビジョニングされた Amazon EC2 またはバッチスタックで実行します。毎日、毎週、または毎月の頻度を設定します。

分析タイプ

AWS 継続的なモダナイゼーションの変換では、モダナイゼーションのニーズに対応するために、次の分析タイプがサポートされています。

型 説明
rapid-techdebt-analysis パッケージマニフェスト (pom.xml、、requirements.txt) のメタデータのみの高速スキャンによりpackage.json、古いバージョンと古い依存関係を識別します。ソースコードを分析しません。
tech-debt-comprehensive AWS Transform エージェントを使用した詳細なコードレベルの技術的負債分析。ソースコードを調べて、負債パターン、コード品質の問題、アーキテクチャの懸念、改善の機会を特定します。
security セキュリティエージェントを使用した AWS セキュリティ脆弱性と CVE 検出。ソースコードと依存関係をスキャンして、既知の脆弱性、安全でないコーディングパターン、悪用可能な弱点がないかどうかを確認します。1 回限りのインフラストラクチャのセットアップが必要です。
agentic-readiness AI とエージェントの統合の準備状況の評価。インフラストラクチャとプラットフォーム、アプリケーションアーキテクチャ、データ基盤、Identity/Security/Governance。
modernization-readiness クラウドモダナイゼーションの機会の評価。インフラストラクチャ、アプリケーション、データ、セキュリティ、運用の各ディメンションにわたる準備状況を評価します。コンテナ化、サーバーレス移行、プラットフォームアップグレードの候補を特定します。
custom 任意の変換定義 (TD) を分析として実行します。このタイプを使用して、独自の分析基準を定義したり、組み込みタイプでカバーされていない AWS マネージド変換を実行したりできます。

重要な概念の理解

[Sources] (出典)

ソースは、リポジトリの場所を継続的なモダナイゼーションに伝えます。サポートされているソースタイプ:

  • GitHub — 個人用アクセストークンを持つ組織 (クラシック)

  • GitLab — セルフホストインスタンスを含むグループまたはユーザー

  • Bitbucket — Workspaces (クラウド) またはプロジェクト (データセンター)

  • Local — git リポジトリを含む親ディレクトリ

リポジトリ

リポジトリは、スキャンソースによって検出されます。検出後、ソース、ラベル、またはその他の基準でフィルタリングしたり、組織 (チーム、優先度、移行ウェーブ) にラベルを適用したり、分析や修復のために特定のリポジトリをターゲットにしたりできます。

分析

分析は、特定の分析タイプを使用した 1 つ以上のリポジトリのスキャンです。各分析では、コード内の問題を識別する検出結果が生成されます。分析はオンデマンドで実行することも、自動的に実行するようにスケジュールすることもできます。分析タイプには、rapid-techdebt-analysis、tech-debt-comprehensive、security、agentic-Readiness、モダナイゼーション-Readiness、Custom などがあります。各分析は、ステータス (保留中、実行中、完了、キャンセル、失敗) とスキャンしたリポジトリを追跡します。

検出結果

結果は分析の結果です。各検出結果には、重要度 (高、中、低）、ステータス (オープン、却下、または廃止）、およびそれを修復できる修正変換 (自動修正可能な場合) が含まれます。新しい検出結果はオープンとして開始されます。ユーザーは、理由のある検出結果を却下できます。再分析では、解決された検出結果は自動的に古いものとしてマークされます。

修復

修正では、変換定義を適用して検出結果を修正します。3 つのモード: 検出結果ベース (各検出結果は独自の修正変換を使用）、TD オーバーライド (指定された検出結果の変換定義を上書き）、および直接 TD (検出結果なしでリポジトリに対して変換を実行）。出力はソースプロバイダー (GitHub PR、GitLab MR、Bitbucket PR、またはローカルブランチ) によって異なります。

変換定義

変換定義には、特定のコード変換を実行するために必要な手順と知識が含まれています。継続的なモダナイゼーションでは、カスタム分析 (--type custom --transformation-name name) と修復 () に変換定義を使用します--transformation-name name。で使用可能な変換定義を一覧表示しますatx custom def list。

AWS Transform の継続的なモダナイゼーションの仕組み

AWS トランスフォームの継続的なモダナイゼーションは、通常、複数のコードベースで継続的な分析と修復が必要な大規模なプロジェクトで使用されます。チームは通常、このワークフローに従います。

  1. ソースの接続 — GitHub 組織、GitLab グループ、Bitbucket ワークスペース、またはローカルディレクトリをソースとして追加します。認証トークンに適切なスコープを提供します。

  2. リポジトリの検出 — 検出スキャンを実行して、ソース内のすべてのリポジトリを列挙します。ラベルを使用して、チーム、優先度、または移行ウェーブ別にリポジトリを整理します。

  3. 分析の実行 — ポートフォリオ全体で分析を実行します。迅速な結果を得るにはクイックスキャンを選択し、詳細な結果を得るには包括的な分析を選択します。セキュリティ分析には、1 回限りのインフラストラクチャ設定が必要です。

  4. 結果のトリアージ — 重要度、リポジトリ、分析タイプ別に結果を確認します。文書化された理由で誤検出を却下します。分析を再実行して、解決された問題を古いものとしてマークします。

  5. 修復 — 検出結果を修正するための修復を作成します。継続的なモダナイゼーションにより、ブランチが自動的に作成され、修正されたプル/マージリクエストが開きます。修復ステータスを追跡し、失敗を再試行します。

  6. 継続的分析の設定 — Amazon EventBridge スケジューラを使用する atx ct schedule コマンドを使用して、定期的な分析をスケジュールします。分析頻度 (毎日、毎週、または毎月) を設定して、新しい問題がないかポートフォリオを継続的にモニタリングします。自動修復と組み合わせて、時間の経過とともにコードの状態を維持します。

コンピューティングオプション

継続的なモダナイゼーションは、分析と修復を実行するためのいくつかのコンピューティングオプションをサポートしています。分析は、ローカル、 AWS アカウント (Amazon Amazon EC2 または AWS Batch) でプロビジョニングおよび管理しているインフラストラクチャ、またはセットアップを必要としない AWS Transform マネージドインフラストラクチャで実行できます。Kiro Power and Agent プラグインのエージェントスキルは、各オプションの設定に役立ちます。

注記

コンピューティングオプションに関係なく、認証情報を使用して AWS アカウント ですべてのリソースを作成および所有し、ソースコードはユーザーの管理下に置かれます。分析と修復を実行するインフラストラクチャは、アカウントでプロビジョニングするスタックであるカスタマーマネージドか、 AWS Transform マネージドのいずれかです。 はコンピューティング AWS を運用し、プロビジョニングするものはありません。

Local (デフォルト)

デフォルトでは、分析はローカルマシンで実行されます。このオプションでは、追加のインフラストラクチャは必要ありません。サーバーはローカルで実行され、ローカルコンピューティングリソースを使用して分析を実行します。ツール、小さなリポジトリ、または個々の使用を試すのに適しています。

AWS 変換マネージド型 (プロビジョニングするインフラストラクチャなし)

スタックをプロビジョニングまたは管理することなく、 AWS Transform マネージドインフラストラクチャで分析を実行します。では--mode aws-managed、分析を AWS Transform に送信し、 AWSが運用するインフラストラクチャで実行します。Amazon EC2 インスタンス、 AWS バッチスタック、設定する VPC またはサブネットはありません。プロビジョニングや削除を行うものはありません。送信は実行です。これは、インフラストラクチャを管理したくないときにリモートで実行する最も速い方法です。

このオプションには、サポートされている SCM プロバイダー (GitHub、、または ) でホストされているソースが必要ですBitbucket。 AWS トランスフォームマネージドインフラストラクチャは、マシン上のリポジトリに到達できないためGitLab、ローカルソースをサポートしていません。--region オプションを使用して、ワークロードが実行される AWS リージョンを選択できます。

AWS 変換マネージドインフラストラクチャは分析のみを実行します。修復、またはカスタム変換定義 (--type custom) を実行するには、 AWS Batch または Amazon EC2 を使用します。

AWS Transform マネージドインフラストラクチャで を実行するには、 atx ct remote analysis --mode aws-managed コマンド (「」を参照リモート実行) を使用するか、Kiro Power またはエージェントプラグイン (「」を参照デベロッパーツール) をインストールし、エージェントに「インフラストラクチャ AWS なしで分析を実行する」と尋ねます。Transform マネージドインフラストラクチャの定期的な分析には、実行ロールが必要です ( AWS 「」を参照定期的な分析のスケジューリング)。

Transform マネージドインフラストラクチャの分析は、 AWS Transform Web アプリケーションの継続的なモダナイゼーションページから開始することもできます ( AWS 「」を参照AWS ウェブアプリケーションの変換)。

AWS Batch (Fargate) (推奨)

ほとんどのポートフォリオでは、推奨されるコンピューティングオプションである Fargate を使用して AWS Batch で分析を実行できます。各分析はサーバーレスコンピューティングを使用する独自のコンテナ内で分離されたジョブとして実行されるため、管理する永続的なインフラストラクチャはなく、ジョブは複数のソースまたは分析タイプの並列分析用にスケールアウトされます。

プロビジョニングは、以下を含む必要なインフラストラクチャをデプロイします。

  • AWS バッチジョブキューとコンピューティング環境

  • 継続的モダナイゼーションコンテナイメージを使用したジョブ定義

  • バッチジョブ実行の IAM ロール

  • ジョブ送信用の Lambda 関数

インフラストラクチャのプロビジョニングには、管理者権限が必要です。最小特権で既にプロビジョニングされたバッチスタックで分析と修復を実行するには、 マネージドポリシー をアタッチします AWS AWSTransformInfrastructureExecutorAccessBatch。

バッチ実行を設定するには、 atx ct remote コマンドを直接使用するか (「」を参照リモート実行)、Kiro Power またはエージェントプラグインをインストールするか (「」を参照デベロッパーツール)、エージェントに「Fargate で分析を実行する」または「継続的なモダナイゼーションのためにバッチ実行を設定する」と尋ねます。エージェントはスタックをデプロイし、ソース認証情報を Secrets Manager に保存して、分析ジョブを AWS Batch に送信します。

Amazon EC2

の永続的な Amazon EC2 インスタンスで分析を実行します AWS アカウント。このオプションは、ローカルマシンからコンピューティングをオフロードし、より大きな分析をサポートし、定期的なスケジュール分析を可能にします。インスタンスは送信間で実行され続けます。

プロビジョニングは、以下を含む AWS CloudFormation スタックをデプロイします。

  • Docker と継続的なモダナイゼーションコンテナを備えた Amazon EC2 インスタンス (Amazon Linux 2023)

  • AWS Transform、Amazon S3、KMS、Secrets Manager、およびセキュリティエージェントのアクセス許可を持つ IAM ロール AWS

  • AmazonSSMManagedInstanceCore SSM 経由のシェルアクセス用 (SSH キーペアまたはインバウンドポートは不要)

  • インバウンドルールのないセキュリティグループ

インフラストラクチャのプロビジョニングには、Amazon EC2 ライフサイクル管理、 AWS CloudFormation スタックオペレーション、IAM ロール作成、Amazon S3 バケットオペレーション、Secrets Manager シークレット管理、SSM コマンドの管理者権限が必要です。最小特権で既にプロビジョニングされた Amazon EC2 スタックで分析と修復を実行するには、 AWS マネージドポリシー をアタッチしますAWSTransformInfrastructureExecutorAccessEC2。

Amazon EC2 の実行を設定するには、 atx ct remote コマンドを直接使用するか (「」を参照リモート実行)、Kiro Power またはエージェントプラグインをインストールするか (「」を参照デベロッパーツール)、エージェントに「継続的なモダナイゼーション分析のために EC2 インスタンスを設定する」と尋ねます。エージェントはインフラストラクチャをプロビジョニングし、コンテナが正常であることを確認し、SSM を介して分析を送信します。SSH は必要ありません。

セキュリティエージェントの設定

security 分析タイプは、脆弱性と CVE 検出に AWS Security Agent サービスを使用します。他の分析タイプとは異なり、 では 1 回限りのインフラストラクチャ設定が必要です AWS アカウント。

注記

security 分析タイプは、カナダ (中部) ()、欧州 (ロンドン) (ca-central-1)、アジアパシフィック (ソウルeu-west-2) () の各リージョンでは使用できませんap-northeast-2。他の分析タイプは影響を受けません。

セットアップコマンドは、以下を含む AWS CloudFormation スタックをプロビジョニングします。

  • ソースコードのアップロード用の Amazon S3 バケット

  • が引き受ける IAM ロール securityagent.amazonaws.com

  • セキュリティエージェントロールの マネージドポリシー

セットアップ後に最小特権でセキュリティ分析を実行するには、IAM ユーザーまたはロールAWSTransformSecurityAgentExecutorAccessに AWS 管理ポリシーをアタッチします。

セットアップを実行するには、IAM ユーザーまたはロールに次の追加のアクセス許可が必要です。

  • cloudformation:CreateStack, cloudformation:UpdateStack, cloudformation:DescribeStacks

  • iam:CreateRole, iam:PutRolePolicy, iam:AttachRolePolicy, iam:CreatePolicy

  • s3:CreateBucket, s3:PutBucketEncryption, s3:PutBucketPublicAccessBlock

次のコマンドを使用して、セキュリティエージェントのインフラストラクチャを管理します。

# Provision the security agent infrastructure
atx ct setup security-agent

# Check the status
atx ct setup security-agent --status

# Delete the infrastructure
atx ct setup security-agent --delete

セットアップが完了したら、他の分析タイプと同じ方法でセキュリティ分析を実行できます。