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 AWS Transform エージェントを使用してパッケージマニフェスト (pom.xml、package.json、requirements.txt) の高速スキャンを行い、古いバージョンと古い依存関係を特定します。ソースコードを分析しません。
tech-debt-comprehensive AWS Transform エージェントを使用した詳細なコードレベルの技術的負債分析。ソースコードを調べて、負債パターン、コード品質の問題、アーキテクチャの懸念、改善の機会を特定します。
security AWS セキュリティエージェントを使用した静的アプリケーションセキュリティテスト (SAST)。ソースコードをスキャンして、SQL インジェクション、ハードコードされたシークレット、安全でない逆シリアル化などの安全でないコーディングパターンを検出します。1 回限りのインフラストラクチャ設定が必要です。
agentic-readiness AI とエージェントの統合の準備状況の評価。Infrastructure & Platform、Application Architecture、Data Foundations、Identity/Security/Governance、Operations & Observability の 5 つのカテゴリにまたがる 56 の基準を採点します。
modernization-readiness クラウドモダナイゼーションの機会の評価。インフラストラクチャ、アプリケーション、データ、セキュリティ、運用の各側面にわたる準備状況を評価します。コンテナ化、サーバーレス移行、プラットフォームアップグレードの候補を特定します。
custom 独自の変換定義のいずれかを分析として実行します。ここでは、記述された各問題が検出結果として報告され、それを修正する 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、またはローカルブランチ) によって異なります。

変換定義

変換定義には、特定のコード変換を実行するために必要な手順と知識が含まれています。次の 2 種類があります。

  • AWS マネージド変換定義は、 によって事前に構築および検証されており AWS、セットアップなしで使用できます。名前は、 などAWS/、 で始まりますAWS/java-version-upgrade。検出結果は修正としてリンクされます。

  • カスタム変換定義は、作成して の変換レジストリに発行する変換定義です AWS アカウント。これらを使用して、カスタム分析に関する独自の問題を検索したり、修復で独自の変更を行ったりします。

変換定義のカテゴリによって、使用できる場所が決まります。カスタム分析ではanalysis、カテゴリを使用して変換定義を実行し、修復ではremediation、カテゴリまたは AWS マネージド変換を使用して変換定義を実行します。詳細については、「変換定義カテゴリ」を参照してください。

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

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

  1. Connect Sources — 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 「」を参照定期的な分析のスケジューリング)。

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

AWS Batch (Fargate) (推奨)

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

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

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

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

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

  • ジョブ送信用の Lambda 関数

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

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

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 分析タイプは、ソースコードの静的アプリケーションセキュリティテスト (SAST) に AWS Security Agent サービスを使用します。他の分析タイプとは異なり、 では 1 回限りのインフラストラクチャ設定が必要です AWS アカウント。

注記

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

setup コマンドは、以下を含む 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

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