本ブログは 2025 年 12 月 23 日に公開された AWS Blog “ Exploring the zero operator access design of Mantle ” を翻訳したものです。 Amazon では、改善点について率直かつオープンに議論する文化があります。この文化があるからこそ、お客様への価値提供の基準を継続的に引き上げるための投資とイノベーションに注力し続けることができています。2025 年 12 月初め、 Amazon Bedrock の次世代推論エンジンである Mantle において、このプロセスが実際に機能している例を共有する機会がありました。生成 AI の推論処理やファインチューニングのワークロードが進化し続ける中、お客様に最適化された方法で推論を提供する方法も進化させる必要があり、それが Mantle の開発につながりました。 次世代推論エンジンのアーキテクチャを再構築するにあたり、AWS はセキュリティの基準を引き上げることを最優先事項としました。AWS はお客様と同様に、セキュリティとデータプライバシーに一切妥協しない姿勢で取り組んでいます。これは当初からビジネスの中心であり、Amazon Bedrock においても初期段階から徹底してきました。生成 AI の推論ワークロードは、お客様がデータの潜在的な価値を引き出すための、かつてない可能性をもたらします。しかし、その可能性を活かすには、最も機密性の高いデータを処理し、最も重要なシステムと連携する生成 AI システムを構築する際に、セキュリティ、プライバシー、コンプライアンスの最高基準を確保する必要があることを、AWS は当初から理解していました。 前提として、Amazon Bedrock は AWS 全体に適用されているものと同じ運用セキュリティ基準で設計されています。AWS は常に最小権限モデルを運用に採用しており、各 AWS オペレーターは割り当てられたタスクを実行するために必要な最小限のシステムにのみアクセスでき、その権限はタスクの実行に必要な期間のみに限定されています。顧客データやメタデータを格納または処理するシステムへのアクセスはすべてログに記録され、異常がないか監視され、監査されます。AWS はこれらのコントロールを無効化またはバイパスするあらゆる行為を防止しています。さらに、Amazon Bedrock ではお客様のデータがモデルのトレーニングに使用されることはありません。モデルプロバイダーは顧客データにアクセスする手段を持っていません。推論処理は、AWS が管理する Amazon Bedrock のサービスアカウント内でのみ行われ、モデルプロバイダーはこのアカウントにアクセスできないためです。この強力なセキュリティポスチャにより、お客様は安心して機密データを生成 AI アプリケーションで活用できるようになっています。 Mantle では、AWS はさらに高い基準を設けました。 AWS Nitro System のアプローチに従い、Mantle をゼロから設計してゼロオペレーターアクセス (ZOA) を実現しました。これは、AWS オペレーターが顧客データにアクセスするための技術的手段を設計の段階から徹底して排除したものです。代わりに、システムとサービスは顧客データを保護する自動化とセキュアな API を使用して管理されます。Mantle では、AWS オペレーターが基盤となるコンピューティングシステムにサインインしたり、推論プロンプトや生成結果などの顧客データにアクセスしたりする手段はありません。Secure Shell (SSH)、 AWS Systems Manager Session Manager 、シリアルコンソールなどの対話型通信ツールは、Mantle のどこにもインストールされていません。さらに、すべての推論ソフトウェアの更新は、サービスにデプロイされる前に署名と検証が必要であり、承認されたコードのみが Mantle で実行されることを保証しています。 Mantle は、最近リリースされた EC2 インスタンスアテステーション機能 を使用して、顧客データ処理のための堅牢化され、制限された、イミュータブルなコンピューティング環境を構成しています。Mantle でモデルの重みを取り扱い、顧客プロンプトに対する推論処理を担当するサービスは、 Nitro Trusted Platform Module (NitroTPM) から暗号署名されたアテステーション・メジャーメントによる高い保証によってさらに裏付けられています。 お客様が Mantle エンドポイント (例: bedrock-mantle.[regions].api.aws ) を呼び出すと、Amazon Bedrock の Responses API を提供するエンドポイントなど、顧客データ (プロンプト) は TLS を通じてお客様の環境を離れ、ZOA で運用される Mantle サービスまで暗号化されたまま送信されます。フロー全体および Mantle 内で、AWS、お客様、モデルプロバイダーのいずれのオペレーターも顧客データにアクセスできません。 今後の展望 Mantle の ZOA 設計は、お客様のデータのセキュリティとプライバシーに対する AWS の長期的なコミットメントの表れです。だからこそ、AWS のすべてのチームがセキュリティの基準をさらに引き上げるための投資を行うことができています。同時に、NitroTPM アテステーションなど、Amazon 社内で使用している基盤となるコンフィデンシャルコンピューティング機能を、すべてのお客様が Amazon Elastic Compute Cloud (Amazon EC2) で使用できるようにしました。 AWS はここで止まることはありません。お客様のデータのセキュリティを強化するための投資を継続し、これをどのように実現しているかについて、より高い透明性と保証を提供することにコミットしています。 著者について Anthony Liguori は Amazon Bedrock 担当の AWS バイスプレジデント兼ディスティングイッシュドエンジニアであり、Mantle のリードエンジニアです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2026 年 1 月 22 日 に公開された「 Managing Amazon OpenSearch UI infrastructure as code with AWS CDK 」を翻訳したものです。 複数の AWS リージョンや環境にまたがって可観測性と分析機能を拡張していくと、ダッシュボードの一貫性を維持することが難しくなります。チームはダッシュボードの再作成、ワークスペースの作成、データソースの接続、設定の検証に何時間も費やすことがあります。繰り返しが多くエラーが発生しやすいプロセスであり、運用の可視化を遅らせる原因となります。 Amazon OpenSearch Service の次世代 OpenSearch UI は、個々の OpenSearch ドメインやコレクションから切り離された、統合されたマネージド分析エクスペリエンスを提供します。ワークスペースは、コラボレーター管理機能を備えた専用のチームスペースであり、可観測性、検索、セキュリティ分析のユースケースに合わせた環境を提供します。各ワークスペースは、OpenSearch Service ドメイン、 Amazon OpenSearch Serverless コレクション、 Amazon Simple Storage Service (Amazon S3) などの外部ソースを含む複数のデータソースに接続できます。OpenSearch UI は、 AWS IAM Identity Center 、 AWS Identity and Access Management (IAM)、IdP 起点のシングルサインオン (IAM フェデレーションを使用した SAML)、AI を活用したインサイトによるアクセスもサポートしています。 本記事では、 AWS Cloud Development Kit (AWS CDK) を使用して OpenSearch UI アプリケーションをデプロイし、OpenSearch Dashboards Saved Objects API でワークスペースとダッシュボードを自動作成する AWS Lambda 関数と統合する方法を紹介します。この自動化により、環境は標準化され、バージョン管理され、デプロイ間で一貫性のある、すぐに使用できる分析機能を備えた状態で起動します。 本記事で学ぶ内容: AWS CloudFormation を使用する AWS CDK で OpenSearch UI アプリケーションをデプロイする Lambda ベースのカスタムリソースを使用してワークスペースとダッシュボードを自動的に作成する 即座に可視化できるサンプルデータを生成して取り込む OpenSearch Dashboards Saved Objects API を使用してプログラムで可視化を構築する AWS Signature Version 4 を使用して API リクエストを認証する この記事のすべてのコードサンプルは、 AWS Samples リポジトリ で入手できます。 ソリューションの概要 以下のアーキテクチャは、AWS CDK、AWS Lambda、OpenSearch UI API を使用して OpenSearch UI ワークスペースとダッシュボードの作成を自動化する方法を示しています。 ワークフローは左から右に流れます。 スタックのデプロイ – 開発者が cdk deploy を実行してインフラストラクチャを起動し、CloudFormation スタックを作成します。 ドメインの作成 – CloudFormation が OpenSearch ドメイン (データソースとして機能) を作成します。 OpenSearch UI アプリの作成 – CloudFormation が OpenSearch UI アプリケーションを作成します。 Lambda のトリガー – CloudFormation がカスタムリソースとして Lambda 関数を呼び出します。 データの生成と取り込み – Lambda がサンプルメトリクスを生成し、ドメインに取り込みます。 Saved Object API を使用したワークスペースとアセットの作成 – Lambda が OpenSearch UI API 呼び出しを使用して、ワークスペース、インデックスパターン、可視化 (円グラフ)、ダッシュボードを作成します。 サンプルデータとすぐに使用できるダッシュボードを備えた、完全に設定された OpenSearch UI が Infrastructure as Code (IaC) によって自動化されます。同じワークフローを既存の OpenSearch UI アプリケーションのインフラストラクチャに統合して、将来のデプロイ時にダッシュボードを自動的に作成または更新し、環境間の一貫性を維持することもできます。 前提条件 本ソリューションには以下が必要です。 十分な権限を持つ AWS ユーザーまたはロール – OpenSearch Service ドメイン、OpenSearch UI アプリケーション、Lambda 関数、IAM ロールとポリシー、仮想プライベートクラウド (VPC) ネットワークコンポーネント (サブネットとセキュリティグループ)、CloudFormation スタックなどの AWS リソースを作成および管理する権限が必要です。テストや概念実証のデプロイには、管理者ロールの使用をお勧めします。本番環境では、最小権限の原則に従ってください。 開発ツールのインストール: AWS CLI v2.x 以降。詳細については、 AWS CLI の開始方法 を参照してください。 Node.js 18.x 以降。 AWS CDK v2.110.0 以降: npm install -g aws-cdk 。 Python 3.11 以降。 CDK のブートストラップ – アカウントまたはリージョンごとに 1 回のセットアップです。 cdk bootstrap <aws://123456789012/us-east-1> このコマンドにより、アカウントで AWS CDK デプロイに必要な S3 バケットと IAM ロールが作成されます。 サンプルコードの取得 GitHub からサンプル実装をクローンします。 git clone https://github.com/aws-samples/sample-automate-opensearch-ui-dashboards-deployment.git cd opensearch-dashboard-automation-sample リポジトリには以下が含まれています。 opensearch-dashboard-automation-sample/ ├── cdk/ │ ├── bin/ │ │ └── app.ts # CDK アプリのエントリポイント │ └── lib/ │ └── dashboard-stack.ts # OpenSearch ドメイン、Lambda、カスタムリソース └── lambda/ ├── dashboard_automation.py # ワークスペースとダッシュボード自動化のメイン Lambda ├── sigv4_signer.py # AWS SigV4 署名ユーティリティ └── requirements.txt # Python 依存関係 このサンプルは、OpenSearch UI アプリケーションのデプロイ、ワークスペースの作成、サンプルデータの取り込み、IaC を使用した可視化とダッシュボードの自動生成方法を示しています。 リポジトリをクローンした後、スタックをデプロイして、最初の OpenSearch ワークスペースとダッシュボードを自動的に作成できます。 ソリューションの理解 デプロイする前に、ソリューションの仕組みを確認しましょう。以下の手順では、AWS CDK スタックをデプロイしたときに自動的に実行されるアーキテクチャと自動化ロジックについて説明します。次のセクションには、実行する実際のデプロイコマンドが含まれています。 OpenSearch UI リソースのプロビジョニング AWS CDK は AWS CloudFormation とシームレスに統合されています。つまり、OpenSearch リソースと自動化ワークフローを IaC として定義できます。本ソリューションでは、AWS CDK が OpenSearch ドメイン、OpenSearch UI アプリケーション、自動化ロジックを実行する Lambda ベースのカスタムリソースをプロビジョニングします。 OpenSearch UI の自動化をデプロイする際、依存関係を正しく解決するためにリソース作成の順序が重要です。推奨される順序は以下のとおりです。 Lambda 実行ロールの作成 – AppConfigs と API へのアクセスに必要 OpenSearch ドメインの作成 – プライマリデータソースとして機能 OpenSearch UI アプリケーションの作成 – AppConfigs で Lambda ロールを参照 Lambda 関数の作成 – 自動化ロジックを定義 カスタムリソースの作成 – スタックデプロイ中に Lambda 自動化をトリガー 以下のコードスニペット ( cdk/lib/dashboard-stack.ts より) は、主要なインフラストラクチャ定義を示しています。 export class OpenSearchDashboardStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: OpenSearchDashboardStackProps) { super(scope, id, props); const masterUserArn = props?.masterUserArn || `arn:aws:iam::${this.account}:role/Admin`; // Step 1: Create IAM Role for Lambda FIRST const dashboardRole = new iam.Role(this, 'DashboardLambdaRole', { assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'), inlinePolicies: { OpenSearchAccess: new iam.PolicyDocument({ statements: [ new iam.PolicyStatement({ actions: ['opensearch:ApplicationAccessAll'], resources: ['*'] }), new iam.PolicyStatement({ actions: ['es:ESHttpPost', 'es:ESHttpPut', 'es:ESHttpGet'], resources: [`arn:aws:es:${this.region}:${this.account}:domain/*`] }) ] }) } }); // Step 2: Create OpenSearch Domain const opensearchDomain = new opensearch.Domain(this, 'OpenSearchDomain', { version: opensearch.EngineVersion.OPENSEARCH_2_11, capacity: { dataNodes: 1, dataNodeInstanceType: 'r6g.large.search' }, // ... additional configuration }); // Step 3: Create OpenSearch UI Application const openSearchUI = new opensearch.CfnApplication(this, 'OpenSearchUI', { appConfigs: [ { key: 'opensearchDashboards.dashboardAdmin.users', value: `[${masterUserArn}]` // Human users }, { key: 'opensearchDashboards.dashboardAdmin.groups', value: `[${dashboardRole.roleArn}]` // Lambda role } ], dataSources: [{ dataSourceArn: opensearchDomain.domainArn }], // ... additional configuration }); // Step 4: Create Lambda Function const dashboardFn = new lambda.Function(this, 'DashboardSetup', { runtime: lambda.Runtime.PYTHON_3_11, handler: 'dashboard_automation.handler', code: lambda.Code.fromAsset('../lambda'), timeout: cdk.Duration.minutes(5), role: dashboardRole }); // Step 5: Create Custom Resource const provider = new cr.Provider(this, 'DashboardProvider', { onEventHandler: dashboardFn }); new cdk.CustomResource(this, 'DashboardSetupResource', { serviceToken: provider.serviceToken, properties: { opensearchUIEndpoint: openSearchUI.attrDashboardEndpoint, domainEndpoint: opensearchDomain.domainEndpoint, domainName: opensearchDomain.domainName, workspaceName: 'workspace-demo', region: this.region } }); } } 実装に関する重要な注意点: Lambda ロールは、その Amazon リソースネーム (ARN) を dashboardAdmin.groups で参照できるように、OpenSearch UI アプリケーションより先に作成する必要があります。 Lambda ロールには、 opensearch:ApplicationAccessAll (OpenSearch UI API アクセス用) と es:ESHttp* 権限 (OpenSearch ドメインへのデータ取り込み用) の両方が含まれています。 カスタムリソースにより、自動化関数がデプロイ中に実行され、OpenSearch UI と OpenSearch ドメインの両方のエンドポイントがパラメータとして渡されます。 OpenSearch UI API での認証 OpenSearch UI (Dashboards) API とプログラムでやり取りする場合、Lambda 関数や自動化スクリプトが API に安全にアクセスできるように適切な認証が必要です。OpenSearch UI は、OpenSearch ドメイン API と同様に AWS Signature Version 4 (SigV4) 認証を使用しますが、いくつかの重要な違いがあります。 OpenSearch UI API リクエストに署名する際、サービス名は es ではなく opensearch である必要があります。これはよくある混乱の原因です。OpenSearch ドメインエンドポイントは引き続きレガシーサービス名 es を使用しますが、OpenSearch UI エンドポイントには opensearch が必要です。間違ったサービス名を使用すると、認証情報が有効であってもリクエストは認証に失敗します。 POST、PUT、DELETE リクエストの場合、OpenSearch UI API のセキュリティ要件を満たすために以下のヘッダーを含めます。 ヘッダー 説明 1 Content-Type JSON ペイロードの場合は application/json に設定 2 osd-xsrf 状態を変更する操作に必要 ( true に設定) 3 x-amz-content-sha256 データの整合性を確保するためのリクエストボディの SHA-256 ハッシュ SigV4 署名プロセスは、botocore の AWSRequest オブジェクトを使用する際にこのボディハッシュを自動的に計算し、リクエストの整合性を維持して送信中の改ざんを防止します。 以下のコードスニペット ( lambda/sigv4_signer.py より) は、OpenSearch UI API へのリクエストに署名して送信する方法を示しています。 def get_common_headers(body: bytes = b"{}") -> Dict[str, str]: """ Get common headers for OpenSearch UI API requests. Args: body: Request body bytes to hash Returns: Dictionary of required headers """ body_hash = hashlib.sha256(body).hexdigest() return { "Content-Type": "application/json", "x-amz-content-sha256": body_hash, "osd-xsrf": "osd-fetch", "osd-version": "3.1.0", } def make_signed_request( method: str, url: str, headers: Dict[str, str], body: bytes = b"", region: str = None, ) -> Any: session = boto3.Session() if not region: region = session.region_name # Create AWS request request = AWSRequest(method=method, url=url, data=body, headers=headers) # Sign with SigV4 using 'opensearch' service name (not 'es') credentials = session.get_credentials() SigV4Auth(credentials, "opensearch", region).add_auth(request) # Send request using URLLib3Session http_session = URLLib3Session() return http_session.send(request.prepare()) SigV4 署名関数は、正しいサービス名 ( opensearch ) を使用してリクエストに署名し、必要なヘッダーを添付して、OpenSearch UI エンドポイントに安全に送信します。 サンプルデータを使用したワークスペースとダッシュボードの作成 Lambda 関数 ( lambda/dashboard_automation.py ) は、OpenSearch UI API を通じてワークスペースのプロビジョニング、サンプルデータの生成、可視化とダッシュボードの作成のプロセス全体を自動化します。以下の API リストを参照してください。 Workspace API リスト Saved Objects API リスト 以下の手順に従います。 ワークスペースの検索または作成。OpenSearch UI の各ダッシュボードはワークスペース内に存在する必要があります。関数はまずワークスペースが既に存在するかどうかを確認し、必要に応じて作成します。ワークスペースは 1 つ以上のデータソース (OpenSearch ドメインや OpenSearch Serverless コレクションなど) を関連付けます。 def get_or_create_workspace(endpoint: str, region: str, data_source_id: str, workspace_name: str) -> Optional[str]: """Get existing workspace or create new one (idempotent).""" # Check for existing workspace workspace_id = find_workspace_by_name(endpoint, region, workspace_name) if workspace_id: return workspace_id # Create new workspace url = f"https://{endpoint}/api/workspaces" payload = { "attributes": {"name": workspace_name, "features": ["use-case-observability"]}, "settings": {"dataSources": [data_source_id]} } response = make_signed_request("POST", url, get_common_headers(), json.dumps(payload).encode(), region) return response.json()["result"]["id"] ワークスペース検索ロジックにより、繰り返しのデプロイが 冪等 になります。Lambda 関数は重複を作成するのではなく、既存のワークスペースを再利用します。 サンプルデータの生成と取り込み。最初の起動時にダッシュボードを意味のあるものにするために、Lambda 関数は HTTP リクエストメトリクスをシミュレートする小さなデータセットを生成し、Bulk API を使用して OpenSearch ドメインに取り込みます。 def generate_sample_metrics(num_docs: int = 50) -> list: """Generate realistic HTTP API request metrics.""" endpoints = ["/api/users", "/api/products", "/api/orders"] status_codes = [200, 201, 400, 404, 500] status_weights = [0.70, 0.15, 0.08, 0.05, 0.02]# Realistic distribution documents = [] for i in range(num_docs): documents.append({ "@timestamp": generate_timestamp(), "endpoint": random.choice(endpoints), "status_code": random.choices(status_codes, weights=status_weights)[0], "response_time_ms": random.randint(20, 500) }) return documents 関数はこのデータをドメインに取り込みます。 def ingest_sample_data(domain_endpoint: str, region: str, documents: list) -> bool: """Ingest documents using OpenSearch bulk API.""" index_name = f"application-metrics-{datetime.utcnow().strftime('%Y.%m.%d')}" bulk_body = " ".join([ f'{{"index":{{"_index":"{index_name}"}}}} {json.dumps(doc)}' for doc in documents ]) + " " url = f"https://{domain_endpoint}/_bulk" response = make_domain_request("POST", url, headers, bulk_body.encode(), region) return 200 <= response.status_code < 300 サンプルデータの取り込みにより、各デプロイに分析データが含まれ、最初のログイン時にダッシュボードにすぐにデータが表示されます。 可視化の作成。インデックスパターンが利用可能になった後、Lambda 関数は HTTP ステータスコードの分布を示す円グラフの可視化を作成します。 def create_visualization(endpoint: str, region: str, workspace_id: str, index_pattern_id: str) -> Optional[str]: """Create pie chart showing HTTP status code distribution.""" url = f"https://{endpoint}/w/{workspace_id}/api/saved_objects/visualization" vis_state = { "title": "HTTP Status Code Distribution", "type": "pie", "aggs": [ {"id": "1", "type": "count", "schema": "metric"}, { "id": "2", "type": "terms", "schema": "segment", "params": {"field": "status_code", "size": 10} } ] } payload = { "attributes": { "title": "HTTP Status Code Distribution", "visState": json.dumps(vis_state), "kibanaSavedObjectMeta": { "searchSourceJSON": json.dumps({ "index": index_pattern_id, "query": {"query": "", "language": "kuery"} }) } } } response = make_signed_request("POST", url, get_common_headers(), json.dumps(payload).encode(), region) return response.json().get("id") この可視化は、後でダッシュボードパネル内に埋め込まれます。 ダッシュボードの作成。最後に、Lambda 関数は前のステップで作成した可視化を参照するダッシュボードを作成します。 def create_dashboard(endpoint: str, region: str, workspace_id: str, viz_id: str) -> Optional[str]: """Create dashboard containing the visualization.""" url = f"https://{endpoint}/w/{workspace_id}/api/saved_objects/dashboard" # Define panel layout for the visualization panels_json = [{ "version": "2.11.0", "gridData": {"x": 0, "y": 0, "w": 24, "h": 15, "i": "1"}, "panelIndex": "1", "embeddableConfig": {}, "panelRefName": "panel_1" }] payload = { "attributes": { "title": "Application Metrics", "description": "HTTP request metrics dashboard", "panelsJSON": json.dumps(panels_json), "optionsJSON": json.dumps({"darkTheme": False}), "version": 1, "timeRestore": False, "kibanaSavedObjectMeta": { "searchSourceJSON": json.dumps({"query": {"query": "", "language": "kuery"}}) } }, "references": [{ "name": "panel_1", "type": "visualization", "id": viz_id }] } response = make_signed_request("POST", url, get_common_headers(), json.dumps(payload).encode(), region) return response.json().get("id") ダッシュボード作成プロセスが完了し、ユーザーがワークスペースにアクセスするとすぐにアプリケーションメトリクスのインタラクティブな可視化が提供されます。 ロギング、エラー処理、ヘルパーユーティリティを含む完全な実装は、 AWS Samples GitHub リポジトリ で入手できます。 AWS CDK によるインフラストラクチャのデプロイ AWS CDK スタックと Lambda 自動化が整ったら、完全なソリューションをデプロイして、OpenSearch UI ダッシュボードが自動的に作成されることを確認する準備ができました。 スタックのデプロイ クローンしたリポジトリのルートディレクトリから、AWS CDK フォルダに移動し、 前提条件 セクションの IAM ユーザー ARN を使用してスタックをデプロイします。 cd cdk npm install npx cdk bootstrap# First time only npx cdk deploy -c masterUserArn=arn:aws:iam::123456789012:user/your-username AWS CDK が OpenSearch ドメイン、OpenSearch UI アプリケーション、Lambda 関数、自動化を実行するカスタムリソースをプロビジョニングするため、デプロイプロセスには通常 20〜25 分かかります。 デプロイの確認 デプロイが完了したら: AWS CDK 出力に表示される OpenSearch UI エンドポイントを開きます。 IAM 認証情報を使用してサインインします。 新しく作成された workspace-demo ワークスペースに切り替えます。 Application Metrics ダッシュボードを開きます。 サンプルデータからの HTTP ステータスコードの分布を表示する円グラフの可視化を確認します。 ダッシュボードには、合成アプリケーションメトリクスが入力された円グラフの可視化が自動的に表示され、Saved Objects API を使用してデプロイ直後に意味のある分析ダッシュボードをブートストラップする方法を示しています。 拡張 1: Saved Object Import API によるダッシュボード作成の簡素化 OpenSearch Dashboards が進化するにつれて、インデックスパターン、可視化、ダッシュボード間の複雑な依存関係の管理がますます困難になる可能性があります。各ダッシュボードは複数の保存オブジェクトを参照することが多く、環境間で手動で再作成または同期することは時間がかかり、エラーが発生しやすくなります。 ダッシュボード管理を簡素化するために、Saved Objects Import/Export API の使用をお勧めします。この API を使用すると、依存オブジェクトを含むダッシュボード全体を単一の転送可能なアーティファクトにバンドルできます。このアプローチにより、ダッシュボードを CI/CD ワークフローの一部としてバージョン管理、移行、環境間でデプロイでき、一貫性を維持しながら運用オーバーヘッドを削減できます。 ダッシュボードのエクスポート ダッシュボードは OpenSearch UI から直接エクスポートするか、 saved object export API を使用できます。 Stack Management を開き、次に Saved Objects を開きます。 ダッシュボードと関連オブジェクト (可視化やインデックスパターンなど) を選択します。 Export を選択します。 エクスポートしたファイルを dashboard.ndjson として保存します。 このファイルには、改行区切り JSON (NDJSON) 形式でシリアル化された保存オブジェクトが含まれており、バージョン管理やデプロイ自動化に使用できます。 プログラムによるダッシュボードのインポート Saved Objects import API を使用して、NDJSON ファイルをターゲットワークスペースにプログラムでインポートできます。 # Pseudo code for import function def import_dashboard(workspace_id, ndjson_file): # Read the exported dashboard file dashboard_config = read_file(ndjson_file) # POST to import to opensearch ui endpoint url = f"{opensearch_ui_endpoint}/w/{workspace_id}/api/saved_objects/_import" response = make_signed_request("POST", url, dashboard_config) return response.success Import/Export API により、ダッシュボードをアプリケーションコードと同様にデプロイ可能なアセットとして扱うことができます。エクスポートしたダッシュボードをソース管理に保存し、AWS CDK または CloudFormation パイプラインに統合して、複数の環境に自信を持って自動的にデプロイできます。 拡張 2: セキュリティ設定の強化 場合によっては、OpenSearch UI アプリケーションのセキュリティ設定を強化したい場合や、追加のセキュリティ設定でデプロイされた OpenSearch ドメインを扱っている場合があります。以下では、OpenSearch UI アプリケーションのセキュリティ設定を強化しながら、AWS CDK で IaC を実現する方法について説明します。具体的には、OpenSearch ドメインが VPC 内にある場合や、きめ細かなアクセス制御が有効になっている場合の OpenSearch UI アプリケーションのセットアップ方法を説明します。 OpenSearch ドメインが VPC 内にある場合、ダッシュボードと適切に接続するために追加の設定が必要になります。 データを取り込む Lambda 関数と VPC 内の OpenSearch ドメイン間の通信を有効にする OpenSearch Service ドメインが VPC 内にある場合、ドメインにデータを取り込む Lambda 関数はドメインと通信できる必要があります。最も簡単な方法は、Lambda 関数を OpenSearch Service ドメインと同じ VPC 内で実行し、同じセキュリティグループを付与することです。例は GitHub リポジトリ で提供されています。 OpenSearch Service ドメインと通信しようとするクライアントからの HTTPS 通信を許可します。この例では、クライアントは OpenSearch Service ドメインで使用されているのと同じセキュリティグループを使用します。 openSearchSecurityGroup.addIngressRule( openSearchSecurityGroup, ec2.Port.tcp(443), 'Allow inbound HTTPS traffic from itself', ); Lambda 関数が引き受けるロールにこのマネージドポリシーを追加して、VPC へのアクセスを許可します。 iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSLambdaVPCAccessExecutionRole') Lambda 関数が使用する VPC とセキュリティグループを指定します。この場合、VPC は OpenSearch Service ドメインで使用されているものと同じです。 const dashboardFn = new lambda.Function(this, 'DashboardSetup', { // ... additional configuration vpc: vpc, securityGroups: [openSearchSecurityGroup] }); VPC エンドポイントアクセスのための OpenSearch UI サービスの認可 OpenSearch Service ドメインがダッシュボードからアクセスできるようにするには、VPC エンドポイントアクセスを有効にする必要があります。これは、以下の設定に示すようにカスタムリソースを使用して実現できます。 const authorizeOpenSearchUIVpcAccess = new cr.AwsCustomResource(this, 'AuthorizeOpenSearchUIVpcAccess', { onUpdate: { service: 'OpenSearch', action: 'authorizeVpcEndpointAccess', parameters: { DomainName: opensearchDomain.domainName, Service: 'application.opensearchservice.amazonaws.com', }, physicalResourceId: cr.PhysicalResourceId.of(`${opensearchDomain.domainName}-VpcEndpointAccess`), }, policy: cr.AwsCustomResourcePolicy.fromStatements([ new iam.PolicyStatement({ actions: ['es:AuthorizeVpcEndpointAccess'], resources: [opensearchDomain.domainArn], }), ]), }); きめ細かなアクセス制御の有効化 きめ細かなアクセス制御を OpenSearch UI と組み合わせて使用すると、各ユーザーに許可される操作をより細かく制御できます。これは、OpenSearch UI に付属する管理者、読み取り、書き込み権限を超えてユーザーのアクションを制限したい場合に特に便利です。固有のロールを作成し、1 人以上のユーザーにマッピングして、誰がどの機能にアクセスできるかを正確に制御できます。 前のセクションでは、同じ Lambda が OpenSearch Service ドメインと OpenSearch UI の両方にリクエストを行うために使用されました。ただし、OpenSearch Service ドメインと OpenSearch UI の間でメインロールが同じでない状況では、各ロールに対して Lambda 関数を作成することをお勧めします。前述のように、OpenSearch UI の自動化をデプロイする際、依存関係を正しく解決するためにリソース作成の順序が重要です。推奨される順序は以下のとおりです。 ダッシュボード Lambda 実行ロールの作成 – AppConfigs と API へのアクセスに必要 OpenSearch ドメインメインロールの作成 – ドメインの作成と API に必要 OpenSearch ドメインの作成 – プライマリデータソースとして機能 OpenSearch ドメイン Lambda 関数の作成 – OpenSearch ドメインの自動化ロジックを定義 OpenSearch ドメインカスタムリソースの作成 – スタックデプロイ中に Lambda 自動化をトリガー OpenSearch UI アプリケーションの作成 – AppConfigs で Lambda ロールを参照 OpenSearch UI Lambda 関数の作成 – OpenSearch UI の自動化ロジックを定義 OpenSearch UI カスタムリソースの作成 – スタックデプロイ中に Lambda 自動化をトリガー OpenSearch Service ドメインを作成する際、以下のようにきめ細かなアクセス制御パラメータを指定します。 // Step 3: Create OpenSearch Domain const opensearchDomain = new opensearch.Domain(this, 'OpenSearchDomain', { // ... additional configuration // Enable Fine-Grained Access Control in your OpenSearch Domain fineGrainedAccessControl: { masterUserArn: openSearchMasterRole.roleArn, } }); OpenSearch Service ドメインと通信する Lambda 関数には、ドメインに書き込むために必要な権限が必要です。以下は、Lambda 関数がドメインのメインロールを引き受ける設定例です。 // Step 4: Create Lambda Function for OpenSearch Domain const domainFn = new lambda.Function(this, 'DomainSetup', { // ... additional configuration role: openSearchMasterRole }); 次に、必要に応じてロールとロールマッピングを作成するカスタムリソースを追加します。 // Step 5: Create Custom Resources for OpenSearch Domain const domainProvider = new cr.Provider(this, 'DomainProvider', { onEventHandler: domainFn }); // A custom resource to create roles (Optional) new cdk.CustomResource(this, 'DomainRoleSetupResource', { serviceToken: domainProvider.serviceToken, // ... additional configuration }); // A custom resource to create role mappings (Optional) new cdk.CustomResource(this, 'DomainRolesMappingSetupResource', { serviceToken: domainProvider.serviceToken, // ... additional configuration }); OpenSearch Service ドメインでの追加ロールの作成 (オプション) 一部のユーザーに特定の権限を付与したい場合は、ロールを作成することをお勧めします。これは、OpenSearch Service ドメインエンドポイントへのリクエストで実現できます。 roles エンドポイントの詳細については、OpenSearch ドキュメントの Create role を参照してください。 # Pseudo code to create a role def create_role(domain_endpoint: str, region: str, new_role_name: str) -> bool: """Create a new role""" url = f"https://{domain_endpoint}/_plugins/_security/api/roles/{new_role_name}" payload = { "description": "", "cluster_permissions": [ // ... Permisions ], "index_permissions": [ { "index_patterns": [ // ... Index patterns ], "fls": [], "masked_fields": [], "allowed_actions": [ // ... Allowed actions ], }, ], } response = make_domain_request("PUT", url, headers, json.dumps(payload).encode(), region) return response.success ダッシュボードユーザー用の OpenSearch ドメインでのロールマッピングの作成 (オプション) ユーザーを 1 つ以上のロールにマッピングして、OpenSearch Service ドメインへのアクセスを制御できます。これは、ドメインに接続された OpenSearch UI ダッシュボードに反映されます。 rolesmapping エンドポイントの詳細については、OpenSearch ドキュメントの Create role mapping を参照してください。 # Pseudo code to create a role mapping def create_role_mapping(domain_endpoint: str, region: str, new_role_name: str) -> bool: """Create a new role mapping""" url = f"https://{domain_endpoint}/_plugins/_security/api/rolesmapping/{new_role_name}" payload = { "backend_roles": [ "", "", ], } response = make_domain_request("PUT", url, headers, json.dumps(payload).encode(), region) return response.success 実装に関する重要な注意点: デフォルトでは、OpenSearch ドメインはメインユーザー用のロールマッピングを all_access と security_manager の下に作成します。これらのマッピングを変更する場合は、誤ってアクセスを失わないようにメインユーザーをリストに残しておくことをお勧めします。 きめ細かなアクセス制御を使用する場合、ユーザーが OpenSearch ドメインのロールにマッピングされずに OpenSearch UI を開くと、OpenSearch UI の管理者グループに属していても、OpenSearch ドメインにあるデータを可視化または変更できません。このため、適切なロールマッピングを追加するカスタムリソースを作成することをお勧めします。OpenSearch UI 管理者は引き続き OpenSearch UI ダッシュボードに変更を加えることができます。 OpenSearch ドメイン API とプログラムでやり取りする場合、Lambda 関数や自動化スクリプトが API に安全にアクセスできるように適切な認証が必要です。OpenSearch ドメインは SigV4 認証を使用します。OpenSearch ドメイン API リクエストに署名する際、サービス名は es である必要があります。 コストに関する考慮事項 本ソリューションは複数の AWS サービスを使用しており、それぞれに独自のコストコンポーネントがあります。 Amazon OpenSearch Service – 主なコスト要因です。料金はインスタンスタイプ、ノード数、 Amazon Elastic Block Store (Amazon EBS) ストレージに基づきます。テストには、より小さいインスタンス (例: t3.small.search ) を使用するか、使用後にドメインを削除してコストを最小限に抑えることができます。 AWS Lambda – 自動化関数はデプロイ中にのみ実行され、数回の短い呼び出しに対して最小限の料金が発生します。 AWS CDK と CloudFormation – 一時的な IAM ロールと Amazon S3 デプロイアセットを作成しますが、コストはごくわずかです。 料金の詳細については、 Amazon OpenSearch Service の料金 を参照してください。 クリーンアップ テストが完了したら、継続的なコストを避けるためリソースをクリーンアップしてください。プロジェクトディレクトリを開き、AWS CDK スタックを削除します。 cd cdk npx cdk destroy cdk destroy コマンドは、AWS CDK スタックによってプロビジョニングされたリソースを削除します。これには以下が含まれます。 Amazon OpenSearch Service ドメイン OpenSearch UI アプリケーション AWS Lambda 関数とカスタムリソース デプロイに関連付けられた IAM ロールとポリシー クリーンアップにより、関連する料金を停止し、コスト効率の良い AWS 環境を維持できます。 その他のリソース Amazon OpenSearch Service ドキュメント AWS CDK カスタムリソースドキュメント OpenSearch Dashboards API リファレンス API リクエストの AWS Signature Version 4 まとめ Saved Objects API を次世代 Amazon OpenSearch UI と統合することで、ワークスペース、サンプルデータ、可視化、ダッシュボードを含む分析エクスペリエンス全体を IaC から直接プログラムで作成できます。 このアプローチにより、IaC の力を分析レイヤーにもたらします。AWS CDK と AWS Lambda を使用することで、ダッシュボードを環境間で一貫してバージョン管理、デプロイ、更新でき、手動セットアップを削減しながら信頼性とガバナンスを向上させます。ダッシュボード自動化により、チームはセットアップではなくインサイトに集中でき、組織とともにスケールする observability-as-code を実現できます。 著者について Zhongnan Su Zhongnan は、Amazon Web Services (AWS) の Amazon OpenSearch Service チームのソフトウェア開発エンジニアであり、OpenSearch Dashboards のアクティブなメンテナーです。オープンソースプロジェクトと AWS マネージドサービスの両方で、クラウドベースのインフラストラクチャの構築と、開発者エクスペリエンスを向上させる基盤となる UI およびプラットフォームの強化に取り組んでいます。 Paul-Andre Bisson Paul-Andre は、Amazon Pharmacy のソフトウェアエンジニアです。Amazon Pharmacy の配送を調整し、お客様へのタイムリーな配達を可能にするインフラストラクチャの開発と保守を担当しています。プロセス最適化に情熱を持ち、既存のワークフローの分析、ソリューションの実装、より広いコミュニティとのインサイトの共有を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の榎本 貴之がレビューしました。

この記事は 2025 年 12 月 22 日に公開された When data is all you need: An overview of IoT communication with the cloud を翻訳したものです。翻訳はプロフェッショナルサービスの権藤 陸が担当しました。 IoT（Internet of Things）プログラムに取り組む技術チームやマーケティングチームは、遅かれ早かれ、デバイス群（フリート）とクラウド間でデータをやり取りする必要があるプロジェクトに直面します。このデータは極めて重要です。マーケティングはユーザーにより多くの機能を提供したいと考え、ビジネスチームはデータに基づく意思決定を求め、技術チームは既存デバイスフリートとの接続性を最適化しようとします。これらすべての理由は、最終的にはカスタマーエクスペリエンスの向上という一点に収束します。本記事では、IoT プロジェクトの初期段階と、デバイスとクラウド間で通信するために利用可能な選択肢のいくつかを紹介します。また、要件やプロジェクト制約に基づいて通信方式を選択するための具体的な指針も提供します。一般的なソリューションから、あまり標準的ではないアプローチまでを取り上げ、コスト・スコープ・期間を損なう典型的な落とし穴を回避するための助けとなることを目的としています。 IoT デバイスとデバイスデータ IoT プロジェクトに携わる前、私は IoT をデバイス中心の視点で捉えていました。接続されたデバイスは、センサーやアクチュエータを通じて現実世界と相互作用する、IoT の中核コンポーネントです。しかし、それはソリューションの一部にすぎません。もう一つの重要な要素が「データ」です。プロジェクトによっては、必要なのはデバイスデータだけというケースもあります。多くの IoT プロジェクトでは、最初の技術的な議論は、デバイスとクラウド間でデータをどのように流すか、そしてどの通信プロトコルが必要かという点に集中します。では、どの通信プロトコルが必要なのでしょうか。結論から言えば、ケースバイケースです。さまざまなプロジェクト、プロトタイプ、業界での経験を通じて、単一のプロトコルだけを使う必要はないということを学びました。プロジェクトごとに適切な通信プロトコルを選択することは、探索的なプロセスになることもあります。その鍵となるのが、次の 4 つのシステム制約に分解して考えることです。 デバイス： メモリ容量、利用可能な通信インターフェース、計算能力、消費電力といった物理的な制約は何か。 データ： デバイスで収集されるデータの種類は何か。各データタイプの量（ボリューム）はどれくらいか。データの流れは双方向か片方向か。 コスト： 各データタイプにおける通信コストはいくらか。できるだけ早くクラウドに送るだけの価値があるか。 セキュリティ： 単にデータを送受信するだけでは不十分です。通信は、認証・認可・検証・プライバシーポリシーをサポートする安全な方法で管理される必要があります。セキュリティ機能は、分析段階および通信プロトコル選定時の基盤要件として考慮しなければなりません。 注： 本記事で紹介する各通信プロトコルは、X.509 証明書、カスタムオーソライザー、フェデレーションなど、さまざまな認証方式を実装できます。 MQTT プロトコル MQTT は、IoT プロジェクト向けの標準的なメッセージングプロトコルです。双方向で、軽量かつスケーラブルであり、HTTP と同様にアプリケーションレイヤの高レベルプロトコルですが、特性は異なります。また、多くのライブラリやプログラミング言語で広くサポートされています。 OSI モデルにおける HTTP と MQTT プロトコル MQTT は パブリッシュ-サブスクライブモデルに基づいており、ブローカーがクライアント間の通信を仲介します。基本的な MQTT メッセージは、メッセージ内容を階層的に識別する「トピック」と、JSON、バイナリ、テキストなどの形式で表現される「ペイロード」という 2 つの要素で構成されます。 もしプロジェクトにおいて、デバイスとクラウド間でメッセージを送受信するための通信チャネルが必要な場合、MQTT は非常に適した選択肢です。MQTT を利用することで、デバイスのデータやステータスをクラウドに送信し、クラウドからのリクエストやメッセージを受信できます。シンプルで柔軟な設計を維持しながら、MQTT はアプリケーションを簡素化するための機能をネイティブに提供します。たとえば、適切なトピック階層構造を設計することで、デバイスが送信または受信できるメッセージを効率的に制御できます。詳細については AWS IoT Core 向け MQTT トピック設計 を参照してください。 AWS IoT Core は、MQTT、MQTT5、MQTT over WebSocket、HTTPS プロトコルをサポートしています。また、MQTT ブローカーとして動作し、デバイスをクライアントとして扱います。AWS IoT Core は、さまざまな追加機能やサービスを提供しています。たとえば、デバイスの自動プロビジョニングを可能にする仕組みや、デバイスタイプ・属性・タグに基づいて静的または動的なデバイスグループ（ジョブ）を制御する機能などがあります。さらに、単一デバイスの運用から、デバイスフリート全体の管理へと移行することもサポートしています。 AWS IoT Core を用いた MQTT 通信 データストリームと MQTT デバイスから送信される MQTT メッセージには、通常、測定値、ステータス、イベント、制御データ、設定データなどが含まれます。このプロトコルは柔軟性が高く、1 つのメッセージに 1 つまたは複数のデータペイロードを含めることができます。たとえば、単一のイベントを含むメッセージもあれば、特定の時点における複数の測定値やデバイスステータスを含む JSON オブジェクトをペイロードとして送信することも可能です。一方で、複数のメッセージを管理するよりも、ストリームベースの通信が適しているケースもあります。代表的なユースケースの一つが、デバイスの不揮発性メモリにローカル保存またはキャッシュされているデータを扱う場合です。デバイスは、定期的に、あるいはリクエストに応じてオンデマンドでこれらのデータを送信できます。また、ストリームは、高ボリュームで準リアルタイムなデータを送信する際にも一般的に利用されます。たとえば、複数のデバイスから生の測定データを送信し、クラウド上で処理・分析を行うケースです。 データまたは映像ストリームの取り込み Amazon Kinesis は、データやビデオストリームの取り込み、処理、分析をサポートするサービス群です。代表的なユースケースとして、デバイスから Amazon Kinesis Data Streams へデータをストリーミングするケースがあります。詳細については、 AWS IoT Core および Amazon Kinesis を用いたデバイスデータ取り込みのベストプラクティス を参照してください。これら 2 つの通信チャネルは、クラウドとの通信要件を満たすために、同一デバイス上で併用されることも少なくありません。 送信専用（メッセージ送信のみ）パターン 一部のプロジェクトでは、デバイスからクラウドへの軽量な片方向通信レイヤのみが求められます。アプリケーション、デバイス、またはプロジェクト上の制約により、デバイスとクラウド間で双方向通信を確立することが常に可能とは限りません。また、システムがサードパーティによって開発されており、新たな機能追加が難しい場合にも、このような片方向通信の構成が採用されることがあります。 双方向通信は、デバイスがステータス更新や測定値を送信し、それに対してクラウドが確認応答を返す場合に一般的に用いられます。一方で、この片方向通信パターンをサポートするために、AWS IoT Core、 Amazon API Gateway または AWS AppSync などのサービスを利用できます。ただし、これは publish-only プロトコルであるため、デバイス側はクラウドの更新情報を取得するためにポーリングを行う必要があります。その結果、デバイス切断検知などの機能は、他のプロトコルのように標準で提供されず、追加実装が必要になります。 HTTP によるリクエストのみの通信 MQTT が利用できない場合でも、HTTPS プロトコルを使用し、レスポンスメッセージを通じてクラウドからデータを受信することが可能です。データが AWS に取り込まれた後は、200 を超える AWS のマネージドサービスを利用して、データの処理、分析、知能化を行えます。 デバイスで静的データを受信する デバイスまたはデバイスフリートが、クラウドから静的または準静的なデータを読み取る必要がある場合もあります。たとえば、設定情報やソフトウェアアップデートなどです。アプリケーションですでに MQTT プロトコルを実装している場合、 MQTT シャドウ は、設定情報のような比較的小さな静的データを取得するための効率的な手段です。詳細については、 AWS IoT Core のメッセージブローカーおよびプロトコルの制限とクォータ を参照してください。 Amazon S3 バケットからの読み取り ファームウェア更新のように、バージョン番号やステータスを含む比較的大きなファイルについては、 Amazon Simple Storage Service (Amazon S3) から直接ダウンロードできます。 S3 からの能動的なデータ受信：双方向プロトコルと片方向プロトコルの比較 デバイスを 伴わない IoT プロジェクト（稀なケース） IoT デバイスを直接扱って開発を行うことが、常に可能とは限りません。たとえ複数のデバイスを管理する IoT クラウドアプリケーションを構築することが目的であっても、さまざまな制約によって状況が複雑になる場合があります。たとえば、次のようなケースです。 現場に展開済みの既存デバイスを更新できない、または更新に非常に大きな開発工数が必要な場合。 既存システムが依存しているため、現在のデバイス通信機能を変更できない場合。 サードパーティ製デバイスが含まれる場合。これには、独自の制御システムや独自の通信プロトコルを持つデバイス、あるいはチーム側で変更できないクローズドなシステムが含まれる可能性があります。 実現可能性の検証やシステム全体像の把握が目的であれば、IoT クラウド基盤およびアプリケーションのプロトタイプを開発することが有効です。この際、既存デバイスのテレメトリデータや制御機能を活用できます。このアプローチには、主に次の 2 つの戦略が考えられます。 クラウド間（Cloud-to-Cloud）通信ソリューションを実装する。 既存デバイス API に対するラッパーを開発する。 デバイス開発を伴わない、クラウド間通信 クラウド間通信を利用することで、既存ソリューションを新しい開発から分離できるという利点があります。また、異なるアプリケーションプロトコルを使用してデバイステレメトリデータを転送し、データの制御性を高めることも可能です。既存アプリケーションと新規アプリケーション間に仮想ネットワークを構築するために、 Amazon Virtual Private Cloud (Amazon VPC) を活用することも考えられます。この通信方式は、たとえばデバイスグループ単位で測定値や状態を受信するようなケースでは、非常に効率的です。一方で、Amazon VPC の運用には追加の管理工数が必要となります。また、対象デバイスがサードパーティ製である場合には、共同開発が必要になることがあり、これが導入の障壁となることもあります。 デバイス開発を伴わない、既存の通信機能を活用する方式 もう一つの選択肢は、 Amazon API Gateway を利用して、外部システムがすでに提供している API を活用するラッパーを開発する方法です。典型的なユースケースとしては、REST API や WebSocket API と通信するケースが挙げられます。サードパーティ API を利用する場合、1 秒あたり、1 分あたり、あるいは 1 日あたりのリクエスト数を制限するセキュリティ対策が施されていることがあります。これらの制約はスケーラビリティを制限する要因となる可能性があるため、事前に考慮しておく必要があります。 結論 IoT の強みの一つは、通信、データ保存、そしてエッジで意思決定を行える点にあります。IoT プロジェクトの進め方としては、デバイス（モノ）を起点に、その能力に基づいて設計を行うアプローチがあります。一方で、本記事では、データ中心のモデルに基づく異なるアプローチを紹介しました。最初にデータに着目することで、よりコスト効率の高いソリューションを設計できます。また、複数の通信プロトコルを使ってデータを取得することで、プロジェクトの目的や制約に合致した構成を実現できます。 参考文献 [ 1 ] https://aws.amazon.com/what-is/mqtt/ [ 2 ] https://docs.aws.amazon.com/pdfs/whitepapers/latest/designing-mqtt-topics-aws-iot-core/designing-mqtt-topics-aws-iot-core.pdf [ 3 ] https://aws.amazon.com/blogs/iot/best-practices-for-ingesting-data-from-devices-using-aws-iot-core-and-or-amazon-kinesis/ [ 4 ] https://docs.aws.amazon.com/iot/latest/developerguide/iot-device-shadows.html [ 5 ] https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits 著者について Alfonso Torres Soto は、インダストリアルエンジニア（修士）およびプロジェクトマネージャー（PMP）です。AWS のソリューションアーキテクトとして、お客様のアイデアを現実のものにする支援を行っています。テクノロジーと哲学の双方に情熱を持っています。 <!-- '"` -->

はじめに 現代のデジタル社会において、組織はサイバーセキュリティの脅威に対する懸念を強めており、インフラストラクチャをより適切に保護する方法を積極的に模索しています。高度化するサイバー攻撃の増加と、より厳格になるデータ保護規制により、コンテンツ配信インフラのセキュリティ確保は企業にとって重要事項となっています。安全なコンテンツ配信ソリューションの必要性は、かつてないほど高まっています。 最近、 Amazon CloudFront は CloudFront VPC オリジン のサポートを発表しました。これにより、顧客は CloudFront ディストリビューションからのみプライベートサブネット内のオリジンにルーティングできるようになりました。このアーキテクチャでは、パブリック IP アドレスやインターネットゲートウェイが不要となり、防御と監視が必要な攻撃対象領域を効果的に最小化できます。 現代のインターネットベースのアプリケーションにおいて、セキュリティは重要ですが、顧客は包括的なアプリケーションアーキテクチャとして、高可用性も必要としています。AWS は、CloudFront VPC オリジンと CloudFront Functions を使用したマルチリージョンのアクティブ/アクティブ構成によって、これらの要件に対応できます。 ユースケース概要 図1. CloudFront VPC オリジンを使用したマルチリージョンのアクティブ/アクティブ構成 マルチリージョンのアクティブ/アクティブ構成を実装することで、複数の AWS リージョン（例：us-east-1 と us-west-1）でワークロードを同時に実行し、各リージョンがアクティブにトラフィックを処理します。CloudFront VPC オリジンは、CloudFront Functions を通じて加重ルーティングを実装することが可能であり、各リージョンの重みは CloudFront KeyValueStore に保存できます。これにより、再デプロイなしでリージョン間のトラフィック分散を調整できます。例えば、リージョン間でトラフィックを 50/50 に分割し、運用ニーズに基づいてリアルタイムで調整することが可能です。この構成により、単一リージョンに障害が発生した場合でも他のリージョンでサービスを継続できるため、アプリケーションの可用性が向上します。また、トラフィックの重み付け調整により、計画的なメンテナンスやパフォーマンス最適化時にも柔軟に対応できます。 マルチリージョン構成では、データベースのレプリケーション戦略も重要な検討事項となります。リージョン間でデータベースをレプリケーションする場合、レプリケーション遅延が発生するため、ユーザーが異なるリージョンにアクセスすると、データの不整合が発生する可能性があります。このような場合、Session Affinity の実装を推奨します。CloudFront Functions で Cookie ベースのルーティングを利用することで、同一ユーザーのリクエストを一貫して同じリージョンにルーティングし、データ整合性を保証できます。 さらにプライマリとセカンダリの 2 つの CloudFront VPC オリジンを持つ オリジングループ に対してトラフィック分散することにより、あるリージョンで障害が発生した場合に正常なリージョンにフェールオーバーするため、回復性を高めることも可能です。 この構成は、インフラストラクチャを保護するだけでなく、リージョン障害やその他のサービス中断を伴うシナリオにおいて、アプリケーションの可用性を確保します。CloudFront VPC オリジンとマルチリージョン展開の組み合わせにより、セキュリティと可用性が両立する包括的なソリューションを実現し、現代の重要システムの要件を満たすことが可能です。 セットアップ手順 ステップ 0：前提条件 セットアップを開始する前に、以下の前提条件が満たされていることを確認してください： CloudFront ディストリビューション VPC オリジンとして、異なるリージョンに配置された 2 つの内部 Application Load Balancer（ALB） 以降のステップに進む前に、ALB と ALB ターゲットグループ の設定をテストしてください。ALB と ALB ターゲットグループの設定については、 Application Load Balancer の作成 を参照してください。 CloudFront ディストリビューション用の VPC オリジンは、 AWS Management Console または AWS Command Line Interface（CLI） を使用して作成できます。このブログ記事では、AWS コンソールを使用して作成する方法を説明します。 ステップ 1：VPC オリジンのセットアップ 1. Amazon CloudFront コンソールを開き、 [VPC origins] を選択し、 [Create VPC origin] をクリックして、新しい VPC オリジンを作成します。以下に示すように、VPC オリジン名を入力し、オリジン ARN を選択します。 図2. VPC オリジンの作成 2. 両リージョンの VPC オリジンが作成されたことを確認してください。新しい VPC オリジンのステータスは最初 “Deploying” となり、以下に示すように、使用可能な状態になると “Deployed” に変わります。 図3. VPC オリジンのデプロイ確認 3. Amazon CloudFront コンソールを開き、 [Distributions] を選択してから、該当するディストリビューションを選択します。次に [Origins] タブを選択し、 [Create origin] をクリックします。 Origin domain として VPC オリジンを選択し、 [Create origin] をクリックして、以下に示すようにディストリビューションに VPC オリジンを追加します。 図4. ディストリビューションへの VPC オリジンの追加 4. 以下に示すように、両方の VPC オリジンがディストリビューションに追加されたことを確認します。 図5. ディストリビューションへの VPC オリジン追加の確認 5. Amazon CloudFront コンソールを開き、 [Distributions] を選択してから、該当するディストリビューションを選択します。次に [Origins] タブを選択し、 [Create origin group] をクリックします。以下に示すように、 Origins のプライマリとセカンダリの VPC オリジンに加え、 Failover criteria を指定し、デフォルト用のオリジングループを作成します。 図6. ディストリビューションへのオリジングループ追加 6. 以下に示すように、オリジングループがディストリビューションに追加されたことを確認します。 図7. ディストリビューションへのオリジングループ追加の確認 ステップ 2：CloudFront KeyValueStore の設定 1. 以下に示すように、キーと値が含まれる JSON ファイルを S3 バケットにアップロードします。キーと値のペアは、CloudFront KeyValueStore コンソールから直接追加することもできます。このブログ記事では、JSON ファイルをアップロードし、KeyValueStore 作成時に S3 URI を指定する方法で実施します。 { "data": [ { "key": "origin-group-us-east-1-primary", "value": "50" }, { "key": "origin-group-us-west-1-primary", "value": "50" } ] } 図8. VPC オリジンの重み付け設定用 JSON ファイル（キー：オリジン名、値：重み） 図9. JSON ファイルの S3 バケットへのアップロード 2. Amazon CloudFront コンソールを開き、 [Functions] と [KeyValueStores] タブを選択します。 [Create KeyValueStores] をクリックして KeyValueStore を作成し、以下に示すように、KeyValueStore 名を入力し、JSON ファイルの S3 URI を指定した後、 [Create] をクリックします。 図10. KeyValueStoreの作成 3. KeyValueStore が作成されたことを確認します。新しい KeyValueStore の Last modified は、最初 “Provisioning” と表示され、以下に示すように、使用可能になるとタイムスタンプに変更されます。 図11. KeyValueStore のデプロイ確認 ステップ 3：CloudFront Functions の設定 1. Amazon CloudFront コンソールを開き、 [Functions] を選択します。 [Create function] から以下に示すように、関数名を入力して JavaScript バージョンを指定した後、 [Create function] をクリックして関数を作成します。 図12. 重み付けルーティング用の関数作成 2. [Associate existing KeyValueStore] をクリックし、作成した KeyValueStore を選択して、関数に KeyValueStore を関連付けます。以下に示すように、選択後、 [Associate KeyValueStore] をクリックします。 図13. 関数への KeyValueStore の関連付け 3. [Development] ウィンドウ内の [Build] タブで重み付けルーティングのロジックを実装し、以下に示すように [Save changes] をクリックします。 import cf from "cloudfront"; // Initialize CloudFront KeyValueStore const kvs = cf.kvs(); /** * Origin Group configurations * OriginGroup1: us-east-1 (primary), us-west-1 (secondary) * OriginGroup2: us-west-1 (primary), us-east-1 (secondary) */ const originGroups = [ { name: "origin-group-us-east-1-primary", originIds: [ "vpc-origin-us-east-1-internal-webapp-alb", "vpc-origin-us-west-1-internal-webapp-alb" ] }, { name: "origin-group-us-west-1-primary", originIds: [ "vpc-origin-us-west-1-internal-webapp-alb", "vpc-origin-us-east-1-internal-webapp-alb" ] } ]; /** * Failover criteria configuration * Defines which HTTP status codes should trigger failover to secondary origin */ const failoverCriteria = { statusCodes: [500, 502, 503, 504] }; /** * Selects an Origin Group index based on weighted probability * * @param {Array&lt;number&gt;} weights - Array of weights corresponding to each Origin Group * @returns {number} - Index of the selected Origin Group */ function getOriginGroupIndex(weights) { // Calculate the sum of all weights const sum = weights.reduce((total, weight) =&gt; total + weight, 0); // Generate a random number between 1 and the sum of weights let choice = Math.floor(Math.random() * sum) + 1; // Start from the last Origin Group and work backwards let index = weights.length - 1; // Subtract each weight from our random number until we find the selected Origin Group while ((choice -= weights[index]) &gt; 0) { index -= 1; } return index; } /** * Retrieves the current weight configuration for each Origin Group from KVS * * @returns {Promise&lt;Array&lt;number&gt;&gt;} - Array of weights for each Origin Group */ async function getWeightsFromKvs() { const weights = []; // Fetch weight for each Origin Group from the KeyValueStore for (let i = 0; i &lt; originGroups.length; i++) { const weight = await kvs.get(originGroups[i].name); weights.push(parseInt(weight, 10)); // Convert string to integer with base 10 } return weights; } /** * CloudFront function handler that routes requests to Origin Groups based on weighted distribution * * @param {Object} event - CloudFront event object * @returns {Object} - Modified request object */ async function handler(event) { // Get current weights for each Origin Group const weights = await getWeightsFromKvs(); // Select an Origin Group based on the weighted distribution const selectedOriginGroupIndex = getOriginGroupIndex(weights); const selectedOriginGroup = originGroups[selectedOriginGroupIndex]; // Create and route to the selected Origin Group with originIds array and failover criteria cf.createRequestOriginGroup({ originIds: selectedOriginGroup.originIds, failoverCriteria: failoverCriteria }); return event.request; } 図14. 重み付けルーティング用の関数サンプルコード 注意: このコードはあくまでサンプルコードです。本番環境での利用を想定したものではありません。 図15. 開発ウィンドウでの重み付けルーティングロジックの実装 4. [Publish] タブを選択し、以下に示すように [Publish function] をクリックして関数を公開します。 図16. 関数の公開 5. 関数が公開されたことを確認します。以下に示すように、ステータスは “Development” から “Published” に変更されます。 図17. 関数の公開確認 6. Amazon CloudFront コンソールを開き、 [Distributions] を選択してから、該当するディストリビューションを選択します。次に [Behaviors] タブを選択し、 [Create Behavior] をクリックします。以下に示すように、 Path pattern の入力と Origin and origin groups にデフォルト用のオリジングループを指定します。 図18. Path pattern と Origin and origin groups の入力 7. [Function associations] セクションで、 Function type として CloudFront Functions を選択し、 Viewer request として先ほどの関数を選択します。以下に示すように、最後に [Create behavior] をクリックします。 図19. Viewer request としての関数の関連付け ステップ 4：関数のテスト 1. 以下に示すように、動作を編集し、キャッシュポリシーとして [CachingDisabled] を選択します。これは、重み付けに従って両方の VPC オリジンにトラフィックが分散されていることを確認するため、意図的にキャッシュを無効にするための設定です。 図20. キャッシュポリシーで [CachingDisabled] を選択 2. 以下に示すように、CloudFront ドメインに対して複数回リクエストを実行し、両方の VPC オリジンにトラフィックが分散されていることを確認します。 $ echo ""; for i in `seq 1 5`; do echo "Request [$i]"; curl &lt;your-distribution-id&gt;.cloudfront.net; echo ""; echo ""; done Request [1] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [2] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [3] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [4] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [5] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; 図21. CloudFrontドメインへの curl コマンド 3. Amazon CloudFront コンソールを開き、 [Functions] と [KeyValueStores] タブを選択します。KeyValueStore を選択し、 [Key value pairs] セクションで [Edit] をクリックします。以下に示すように、VPC オリジンの重み値を変更し、 [Save changes] をクリックします。 図22. KeyValueStore コンソールでの重み値の変更 4. 以下に示すように、CloudFront ドメインに対して再度複数回リクエストを実行し、変更が反映されていることを確認します。 $ echo ""; for i in `seq 1 5`; do echo "Request [$i]"; curl &lt;your-distribution-id&gt;.cloudfront.net; echo ""; echo ""; done Request [1] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [2] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [3] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [4] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [5] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; 図23 . us-east-1 の重みを 0、us-west-1 の重みを 100 に設定した場合の CloudFront ドメインへの curl コマンド 5. Amazon EC2 コンソールを開き、VPC オリジンとして設定されている us-west-1 の ALB リスナー Default action として [Returned fixed response] を選択し、 Response code を 500 エラーに設定 図24. Amazon EC2 コンソールで ALB リスナーの Default action を変更 6. 以下に示すように、CloudFront ドメインに対して再度複数回リクエストを実行し、セカンダリーの us-east-1 にフェイルオーバしていることを確認します。 $ echo ""; for i in `seq 1 5`; do echo "Request [$i]"; curl &lt;your-distribution-id&gt;.cloudfront.net; echo ""; echo ""; done Request [1] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [2] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [3] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [4] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [5] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; 図25. us-west-1 の ALB リスナーが 500 エラーを返す設定をした状態の CloudFront ドメインへの curl コマンド まとめ セキュリティと可用性という重要な要件に基づき、このソリューションでは CloudFront VPC オリジンと CloudFront Functions を効果的に活用してこれらの要件を達成する方法を示しました。 このソリューションは非常に柔軟性が高く、ユーザーセッションの維持、ユーザーの位置に基づくパフォーマンスの最適化、特定のアプリケーション要件への対応など、さまざまなニーズに応じてトラフィックルーティングをカスタマイズできます。この柔軟性により、セキュリティと可用性を維持しながら、幅広いビジネスニーズに対応することが可能です。 このブログが、重要なアプリケーションのための強固なソリューションの構築に役立ち、堅牢なセキュリティ制御とサービスの継続的な可用性を確保しながら、ビジネスを成長させる一助となれば幸いです。 このブログの著者 針谷 浩紀 (Hiroki Harigai) Technical Account Manager

株式会社リクルートは、日本国内で HR・販促事業を行う事業会社です。リクルートでは、満足度No1(*1)を誇る飲食店予約・グルメ情報サイト『ホットペッパーグルメ』を運営しています。 『ホットペッパーグルメ』では、ユーザーが飲食店を検索する際の「0件ヒット」問題を解決するため、 Amazon OpenSearch Service （以下、OpenSearch Service）を採用し、Hybrid Search 機能を実現しました。約6ヶ月の取り組みにより、検索における0件ヒットを90%削減し、検索経由の予約数を10%向上させることに成功しています。 本ブログでは、『ホットペッパーグルメ』における検索改善の取り組みについて、チャレンジから導入効果までをご紹介します。 課題 『ホットペッパーグルメ』では、ユーザーが飲食店を探そうと検索しても、検索結果が0件になるケースがありました。行きたいお店があるのに見つけられず、ユーザーと飲食店のマッチングの機会を逃してしまう状況です。これはユーザー体験の低下だけでなく、検索から予約への転換機会の損失にもつながる重要なビジネス課題でした。 0件ヒットが発生する背景として従来の検索技術である Lexical Search には限界があり、ユーザーの意図を正しく理解できないケースがありました。 Lexical Search について : Lexical Search（字句検索）は、入力されたキーワードと完全に一致する文字列を検索する手法です。しかし入力ミスに弱いという課題がありました。ユーザーが「寿司」と入力しようとして「寿し」や「すそ」と入力してしまうと、検索結果を取得できません。また、日本語はスペースで単語を区切らない言語のため、セグメンテーションエラーが発生しやすいという日本語特有の課題もありました。 Vector Search の限界 : Vector Search（ベクトル検索）は、テキストを数値ベクトルに変換し、意味的な類似度で検索する手法です。タイポや言い換えに強いという特徴がありますが、固有名詞の検索で精度が低下するという課題がありました。店舗名のような固有名詞を検索する際、意味的に近い別の店舗が上位に表示されてしまいます。また、位置情報などのノイズにより、検索意図とは異なる結果が返される意味的なずれも発生していました。 検索手法 Lexical Search Vector Search 完全一致キーワード ○ × タイポ耐性 × ○ 言い換え対応 × ○ 固有名詞の精度 ○ × 日本語セグメンテーション × ○ 一般的に、ユーザーは検索結果の上位に高い関心があるため(*2)、 特にTop-1の検索結果を改善する方針 としました。 OpenSearch Service を活用した Hybrid Search の実現 これらの課題を解決するため、『ホットペッパーグルメ』では Lexical Search と Vector Search を組み合わせた Hybrid Search を採用しました。またそれを支える基盤として、OpenSearch Service を採用しました。 OpenSearch Service を選定した最大の理由は、Full-text Search と Vector Search を単一のサービスで実現できる Hybrid Search 機能の統合です。また、フルマネージド型サービスとしてインフラ管理の負荷を軽減できる開発・運用の容易さも重要な選定ポイントでした。さらに、OpenSearch Ingestion による Managed ETL や言語別テキスト解析プラグインなど AWS がサポートするプラグインが充実しており、豊富な周辺機能を活用できます。Blue/Green デプロイによる無停止でのスケーリングも、運用の安心感を確保する上で大きなメリットでした。 アーキテクチャと実装 Two-tower Model Architecture 『ホットペッパーグルメ』では、検索クエリと店舗情報をそれぞれ別のエンコーダーで処理する Two-tower Model Architecture を採用しました。 Two-tower Model は、Query Encoder と Document Encoder という2つの独立したエンコーダーで構成されています。Query Encoder はユーザーが入力した検索クエリ（例：「東京 寿司」）をベクトルに変換します。一方、Document Encoder は店舗情報をベクトルに変換します。店舗情報には、店舗名、住所、メニュー、説明文、キャッチコピー、レビューなど、検索に関連する情報が含まれます。埋め込みのスコープについても検証を行いました。店舗名や住所といった基本情報のみを使用するパターンと、メニューや説明文、キャッチコピーといったコンテンツフィールドを含めるパターンを比較し、検索精度への影響を評価しています。 モデルの学習には対照学習を採用しました。学習データとして、ユーザーの検索ログと LLM で生成した合成ペアを組み合わせて使用しています。ユーザーログからは実際の検索行動に基づくクエリと店舗のペアを抽出し、LLM 生成の合成ペアにより学習データのカバレッジを拡大しました。ベースモデルには日本語 BERT を採用し、『ホットペッパーグルメ』のドメインに特化したファインチューニングを実施しています。汎用的な埋め込みモデルと比較して、店舗名のようなドメイン固有の用語に対する検索精度が向上しました。埋め込みの次元数は512次元を採用しています。 日本語テキストの形態素解析には Sudachi を使用し、split_mode: A（最小単位での分割）を設定しています。これにより、日本語特有の複合語や固有名詞を適切にトークン化し、検索精度の向上に寄与しています。 導入プロセス Built-in Hybrid Search（第1フェーズ） 最初のステップとして、AOS の標準機能である Built-in Hybrid Search を導入しました。Built-in Hybrid Search は実装が容易であり、検索基盤の構築よりもモデル改善に集中できるというメリットがありました。 Built-in Hybrid Search では、OpenSearch が Lexical と Vector の検索結果を取得し、それぞれのスコアを正規化した後、単一のスコアにマージしてから Reranking を行います。この仕組みにより、短期間で Hybrid Search を導入し、効果を検証することができました。 一方で、運用を通じて課題も見えてきました。一度スコアがマージされると、スコアの差異が何に起因するのかを把握できなくなります。Lexical Score が高く Vector Score が低い場合、それがタイポによるものなのか、言い換えによるものなのか、あるいはレアな固有名詞によるものなのか、判断できません。どちらのシグナルを重視すべきかは検索意図に依存するため、固定のマージ重みでは対応しきれないケースがありました。この学びから、Reranker には統合されたスコアではなく、Lexical Score と Vector Score を個別に渡す必要があるという結論に至りました。 Custom Hybrid Search（第2フェーズ） Built-in Hybrid Search の課題を解決するため、Custom Hybrid Search を開発しました。 Custom Hybrid Search では、Lexical Score と Vector Score を別々に保持し、マージ前の個別スコアを Reranker に渡すことで、より精緻なランキングが可能になりました。また、ユーザーログや検索意図などの追加シグナルを Reranking に活用しています。スコアの統合には LightGBM による適応的なスコア統合とランキングを採用し、機械学習モデルによる動的なスコア統合を実現しています。アーキテクチャは Planner → Executor → Merger &amp; Reranker の構成となっており、検索意図に応じた柔軟なランキングを実現しています。Custom Hybrid Search の導入により、Top-1 検索精度が最大2倍改善しました。 段階的なリリース戦略 新しい検索システムの導入にあたり、A/B Test Router を用いたトラフィック制御を実施しました。当初は新規システムに10%、既存システムに90%のトラフィックを振り分け、この比率を段階的に調整しながら A/B テストにより効果を検証しました。A slot / B slot による並行検証を行い、新システムの安定性と効果を確認した上で、トラフィック比率を徐々に増加させていきました。 成果 ビジネス成果 : Custom Hybrid Search を本番環境に導入した結果、検索経由の予約数が10%改善し、0件ヒット検索が90%削減されました。これらの改善により、ユーザーと飲食店のマッチング機会が大幅に増加し、サービス全体の価値向上につながっています。 技術的成果 : 運用面でも多くのメリットが得られました。Blue/Green デプロイによる無停止でのスケーリングで運用負荷が軽減され、Plugins や OpenSearch Ingestion を活用することでランキングモデルの改善サイクルを加速できています。フルマネージド型サービスとしてインフラ管理の負荷が軽減されたことで、運用の安心感も確保できました。 まとめ 本ブログでは、『ホットペッパーグルメ』における OpenSearch Service で実現された Hybrid Search を活用した検索改善の取り組みをご紹介しました。 Lexical Search と Vector Search を組み合わせた Hybrid Search により、それぞれの検索手法の強みを活かしながら弱点を補完し、0件ヒット問題を大幅に改善することができました。また、Built-in Hybrid Search から Custom Hybrid Search への段階的な進化により、Top-1 検索精度を最大2倍改善し、検索経由の予約数10%向上という成果を達成しています。 OpenSearch Service の採用により、Lexical Search と Vector Search を組み合わせた Custom Hybrid Search の構築、開発・運用の容易さ、Blue/Green Deployment による安定した運用を実現できました。 こうした検索基盤の進化は、新たなユーザー体験の創出にもつながっています。2026年1月22日にリリースした 「席押さえ」機能 は、現在地周辺のお店をマップから探し、「今すぐ席を押さえる」ボタンをタップするだけで、予約なしで席を確保できるアプリ限定機能です。リアルタイムな「空席情報」と「位置情報」を地図 UI 上でマッチングするこの検索体験も、OpenSearch Service で実現しています。 Reference (*1)2025年6月時点　株式会社東京商工リサーチ調べ (*2) Google検索のClick Trough Rateは、Top1が27.6% backlinko 社調べ AWS re:Invent 2025 – Build Advanced Search with Vector, Hybrid, and AI Techniques (ANT314) Amazon OpenSearch Service BlackBelt 『ホットペッパーグルメ』「席押さえ」機能を全国で提供開始

新年あけましておめでとうございます。ソリューションアーキテクトの konippi です。 Kiro CLI は、2025 年 11 月から 12 月にかけて、v1.21.0・v1.22.0・v1.23.0 と立て続けにアップデートがリリースされました。Web 検索機能、コードインテリジェンス、サブエージェント、Plan エージェントなど、開発体験を大きく向上させる機能が追加されています。Kiro についてまだご存知でない方は「 Kiroweeeeeeek in Japan 開催のお知らせ 」を読んでいただけますと幸いです。また、Kiro のアップデートは Changelog よりご確認ください。 本記事では、これら 3 つのバージョンで追加された主要機能をまとめて紹介します。 v1.21.0 Web 検索・取得機能 Kiro CLI がインターネットからリアルタイムで情報を取得できるようになりました。最新のライブラリバージョン、ドキュメント、技術的な問題の解決策などを、ブラウザに切り替えることなく開発ワークフロー内で直接検索できます。 主な用途 最新のライブラリドキュメントの参照 技術的な問題の解決策の検索 API の最新仕様の確認 使い方 # エージェントが自動的に Web 検索を実行 &gt; React 19 の新機能について調べて教えてください Web 検索機能により、開発中に必要な情報をその場で取得でき、開発フローが中断されることがなくなります。 v1.22.0 コードインテリジェンス機能 v1.22.0 で追加された機能の 1 つは、Language Server Protocol (LSP) 統合による強力なコードインテリジェンス機能です。Kiro IDE と同等のコード理解能力がターミナルで利用できるようになりました。 組み込み機能（セットアップ不要） インストール直後から以下の機能が利用可能です: 対応言語: Bash, C, C++, C#, Elixir, Go, Java, JavaScript, Kotlin, Lua, PHP, Python, Ruby, Rust, Scala, Swift, TSX, TypeScript 主な機能: シンボル検索 : コードベース全体から関数、クラス、変数を検索 定義へのジャンプ : シンボルの定義箇所へ即座に移動 パターン検索 : AST ベースの構造的コード検索 パターン書き換え : AST パターンを使った自動コード変換 コードベース概要 : プロジェクト構造の即座の把握 # コードベース全体の概要を取得 &gt; /code overview # より簡潔な出力 &gt; /code overview --silent LSP 統合（オプション） さらに高度な機能が必要な場合は、LSP サーバーを統合できます: # プロジェクトルートで初期化 &gt; /code init これにより、参照検索、リネームリファクタリング、診断情報、コード補完などの機能が追加されます。 自然言語でのクエリ例: &gt; UserRepository クラスを見つけて &gt; s3Client で使えるメソッドは? LSP サーバーは自動的に検出・起動され、ワークスペースごとに .kiro/settings/lsp.json で設定が管理されます。 対応言語と Language Server 言語 拡張子 Language Server インストールコマンド TypeScript/JavaScript .ts, .js, .tsx, .jsx typescript-language-server npm install -g typescript-language-server typescript Rust .rs rust-analyzer rustup component add rust-analyzer Python .py pyright npm install -g pyright または pip install pyright Go .go gopls go install golang.org/x/tools/gopls@latest Java .java jdtls brew install jdtls (macOS) Ruby .rb solargraph gem install solargraph C/C++ .c, .cpp, .h, .hpp clangd brew install llvm (macOS) または apt install clangd (Linux) カスタム Language Server の追加 上記以外の言語を使用する場合、 .kiro/settings/lsp.json を編集してカスタム Language Server を追加できます: { "languages": { "mylang": { "name": "my-language-server", "command": "my-lsp-binary", "args": ["--stdio"], "file_extensions": ["mylang", "ml"], "project_patterns": ["mylang.config"], "exclude_patterns": ["/build/"], "multi_workspace": false, "initialization_options": { "custom": "options" }, "request_timeout_secs": 60 } } } 編集後、Kiro CLI を再起動して設定を反映してください。 ※ コードインテリジェンス機能はワークスペース単位で設定されます。各プロジェクトで独立して管理されるため、プロジェクトごとに /code init を実行する必要があります。 Knowledge Management 機能 Knowledge Management 機能により、プロジェクト固有のドキュメントやコードベースを永続的な知識ベースとして管理できるようになりました。この機能は Experimental 機能であり、使用前に有効化が必要です。 2つのインデックスタイプ: Fast (Lexical – BM25) : 高速なキーワードベース検索。ログファイルや設定ファイルに最適 Best (Semantic – all-minilm-l6-v2) : 意味を理解するセマンティック検索。ドキュメントや研究論文に最適 基本的な使い方 # 機能を有効化 $ kiro-cli settings chat.enableKnowledge true # ディレクトリをインデックスに追加 $ /knowledge add --name "project-docs" --path /path/to/documentation # セマンティック検索を使用 $ /knowledge add --name "api-docs" --path /path/to/docs --index-type Best # パターンフィルタリング &gt; /knowledge add --name "rust-code" --path /path/to/project \ --include "*.rs" --exclude "target/*" # ナレッジベースを確認 &gt; /knowledge show エージェント別の独立した知識ベース 各エージェントは独自の知識ベースを持ち、コンテキストの混在を防ぎます: # デフォルトエージェントで知識を追加 &gt; /knowledge add /path/to/docs # カスタムエージェントに切り替え &gt; kiro-cli chat --agent my-custom-agent # カスタムエージェント専用の知識ベースを作成 &gt; /knowledge add /path/to/agent/docs 知識ベースはセッション間で永続化され、自然言語クエリで検索できます。 v1.23.0 サブエージェント機能 複雑なタスクを専門的なサブエージェントに委譲できる機能が追加されました。サブエージェントは独自のコンテキストを持ち、並列実行が可能です。 主な特徴 自律実行 : 独自のコンテキストで独立して実行 リアルタイム進捗追跡 : タスク実行中の状態をリアルタイムで確認 並列タスク実行 : 複数のサブエージェントを同時実行 カスタムエージェント設定のサポート : 専門化されたエージェントを利用可能 コアツールへのアクセス : ファイル読み書き、シェルコマンド、MCP ツールの使用 結果の自動集約 : 完了時に結果をメインエージェントに自動返却 使用例 # デフォルトのサブエージェントを使用 &gt; 複数のデータソースを並列で調査して # カスタムエージェントをサブエージェントとして使用 &gt; 商品アイテムの一覧を返す API エンドポイントを backend エージェントで、 商品アイテム一覧ページの UI コンポーネントを frontend エージェントで実装して カスタムエージェントを使用することで、フロントエンドとバックエンドの同時開発など、より高度なワークフローを実現できます。 ※ 既存のエージェント設定でツールを制限している場合は、 subagent ツールを許可リストに追加する必要があります。 Plan エージェント機能 アイデアを構造化された実装計画に変換する専用のビルトインエージェントが追加されました。要件収集、リサーチを通じて、実装前に詳細なタスク分解を作成します。 アクセス方法 キーボードショートカット: Shift + Tab キー（Plan モードと実行モードを切り替え） スラッシュコマンド: /plan プロンプトと同時に起動: /plan 商品一覧を取得する API エンドポイントを実装したい ワークフロー 要件収集 : 構造化された質問でアイデアを洗練 リサーチと分析 : コードインテリジェンス、grep、glob ツールを使用してコードベースを探索 実装計画の作成 : 明確な目標とデモ説明を含む詳細なタスク分解を作成 計画の承認と引き継ぎ : 承認された計画を実行エージェントに転送 各タスクに含まれる情報: Problem Statement (問題定義) : 何を作るのか、解決すべき課題 Requirements (要件) : 実装すべき機能と制約 Background (背景) : 技術的な意思決定の理由と前提知識 Proposed Solution (提案する解決策) : 実装アプローチの全体的な戦略 Task Breakdown (タスク分解) : 目標、実装ガイダンス、Demo Plan エージェントは読み取り専用モードで動作し、ファイルを変更せずに計画に集中します。コードベース探索、Language Server、Grep / Glob ツール、Web 検索は利用可能ですが、ファイル書き込みやコマンド実行、MCP ツールは使用できません。 Grep / Glob ツール 高速なファイル検索のための2つの新しいビルトインツールが追加されました。 Grep ツール : 正規表現を使用した高速コンテンツ検索。bash の grep 、 rg 、 ag コマンドの代替として使用 Glob ツール : Glob パターンを使用した高速ファイル発見。bash の find コマンドの代替として使用 両ツールは .gitignore を自動的に尊重し、カレントディレクトリでデフォルトで信頼されます。 使用例 # エージェントが自動的に使用 &gt; すべての Rust ファイルで 'async fn' を検索して &gt; src ディレクトリ内の全ての .ts ファイルを見つけて shell ツールとの違い: 項目 Grep / Glob ツール shell ツール .gitignore 自動的に尊重 考慮しない 速度 高速 標準 カレントディレクトリ デフォルトで信頼 デフォルトで確認が必要 エージェント設定で allowedPaths と deniedPaths を設定してアクセス範囲を制御できます。 マルチセッションサポート 複数のチャットセッションを管理できるインタラクティブなセッションピッカーが追加されました。セッションは起動したディレクトリごとに保存され、会話のターンごとに自動保存されます。 コマンドラインからの操作 # セッションピッカーを開く $ kiro-cli chat --resume-picker # 最新のセッションを再開 $ kiro-cli chat --resume # または -r # セッション一覧を表示 $ kiro-cli chat --list-sessions # または -l # セッションを削除 $ kiro-cli chat --delete-session &lt;SESSION_ID&gt; # または -d チャットセッション内からの操作 # セッションピッカーを開く &gt; /chat resume # セッションをファイルに保存 &gt; /chat save &lt;FILE_PATH&gt; # ファイルからセッションを読み込む（.json 拡張子は省略可能） &gt; /chat load &lt;FILE_PATH&gt; セッションピッカーには、セッション名、最終アクティビティ、メッセージプレビューが表示されます。 MCP Registry サポート MCP レジストリサポートにより、組織レベルでの MCP ツールのガバナンス機能が追加されました。管理者は利用可能な MCP ツールを管理・制御でき、チーム全体での一貫性とセキュリティを確保できます。 まとめ Kiro CLI v1.21.0 から v1.23.0 にかけて、以下の主要機能が追加されました: v1.21.0 : Web 検索・取得機能によるリアルタイム情報アクセス v1.22.0 : コードインテリジェンス機能 (LSP 統合によるさらに高度なコード操作) Knowledge Management 機能による永続的な知識ベース管理 (Experimental 機能) v1.23.0 : サブエージェントによる並列タスク実行 Plan エージェントによる構造化された実装計画 Grep / Glob ツールによる高速ファイル検索 マルチセッションサポート MCP Registry によるガバナンス機能 これらのアップデートにより、Kiro CLI はターミナル上での AI 駆動開発体験をさらに強化し、より複雑なタスクを効率的に処理できるようになりました。 まだ Kiro CLI を試していない方は、 公式サイト からダウンロードできるのでぜひ試してみてください。また、 Kiro のドキュメント を参照し、ぜひたくさんの機能を触ってみてください！ 著者 小西 杏典 (Kyosuke Konishi) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 2025 年に新卒入社した 1 年目のソリューションアーキテクト konippi です。Amazon Q Developer CLI をはじめ、いろいろな OSS に Contribution することが好きです。 X : https://x.com/_konippi LinkedIn : https://www.linkedin.com/in/kyosuke-konishi GitHub : https://github.com/konippi

はじめに 「AWS を使ってみたいけれど、学習方法がわからない」「実践的に AWS を学んでみたい」「AWS をより活用していきたい」といったお悩みがある方にぜひご参加いただきたいのが、AWS 初学者向けのイベント AWS JumpStart です。 AWS JumpStart は 2022 年の創設以来、参加者は年々増加しており、2025 年には 2500 人もの方が参加し、高い満足度をいただいています。 多くの方から「来年もぜひ開催してほしい」との声をいただき、2026 年も開催が決定しました！本記事では、イベントの内容や 2026 年の開催情報についてご紹介します。 AWS JumpStart とは AWS JumpStart は、新卒を含む AWS 初学者のエンジニアを対象とした、クラウドネイティブなテックリード人材を育成するための第一歩となる実践的な研修プログラムです。事前学習用動画と 2 日間の集中的なオンラインワークショップを通して、皆様の AWS に対する理解度を一気に引き上げることを目的としています。2 日間のプログラムを経て実践的なアーキテクチャ図を自分で設計できるようになることを目指します。 AWS について話を聞いたことはあるが使ったことはない EC2 等の単体サービスは触ったことあるが、システム全体の設計経験はない クラウドネイティブなアプリケーションを設計する上で重要な観点を知りたい といった方々には、短期間で一気にレベルアップできる内容となっているので、AWS を学びはじめるのにもってこいのプログラムとなっています。 AWS JumpStart 2026 のご案内 2026 年も全 4 回、各回 2 日間での開催を決定しました！ AWS JumpStart 2026（全てオンラインでの開催です） 開催日時（各回 2 日間：9 – 18 時） 2026年 5 月 11 日 (月) ~ 5 月 12 日 (火) 2026年 6 月 4 日 (木) ~ 6 月 5 日 (金) 2026年 9 月 17 日 (木) ~ 9 月 18 日 (金) 2026年 11月 12 日 (木) ~ 11 月 13 日 (金) 参加費 無料 参加登録ページ Coming Soon 2026 年の AWS JumpStart では、各回同じコンテンツで開催しますので、ご都合に合わせてご参加ください。 参加登録方法については、2026 年 2 月ごろを目処にお知らせいたします。 こちらのブログ内でもアップデートさせていただきますので今しばらくお待ちください。 AWS JumpStart 2026 も多くの方々のご参加を心よりお待ちしております！ 事前学習コンテンツ 「AWS を学習するのは初めてでイベントでついていけるか不安」という方もご安心ください。AWS JumpStartでは、初心者の方でも安心して参加できるよう、無料の事前学習コンテンツをご用意しています。 本イベントに申し込まれた方に別途ご連絡いたしますが、「早めに内容を確認したい」といった熱心なご意見をしばしばいただくため、以下に事前コンテンツの一例を掲載いたします。 (※ AWS Builder ID アカウントを作成する必要があります。) Cloud for Beginners モジュール 0 ~ 5 Web サービスの基礎について説明しています。 AWS Cloud Practitioner Essentials モジュール 1 ~ 6 AWS の基本的な概念を包括的に学習いただけます。 事前学習コンテンツをイベント参加前にご覧いただくことで当日の理解がより深まります。ぜひご活用ください。 2025 年開催の様子 AWS JumpStart 2025 は全 2 日、オンラインにて開催しました。イベントの内容や雰囲気をご紹介します。 受動的な講義だけではなく、能動的に手を動かしていただけるコンテンツを目指しています。 1 日目 1 日目は、講義形式の座学と実際に手を動かすハンズオンを交互に実施し、知識定着を図りました。 座学では、事前学習コンテンツの振り返りに加え、実際にAWSでシステムを構築する際のアーキテクチャのポイントを解説しました。 ハンズオンでは、仮想サーバーの起動から始まり、最終的に簡単なWebアプリを動かすまでを体験していただきました。2025 年からの新しい取り組みとして、ペアプログラミング形式で実施しています。「次に何をするべきか」「どうしてこの手順を実施するのか」などを話し合いながら進めることで、わからない部分を共有したり調べたりしながら理解を深めることができます。参加者の方からも「協力しながら学べたことで、より深く理解できた」と好評をいただいています。 2 日目 2 日目は、より実践的に AWS を学んでいただけるコンテンツをご用意しました。 コンテンツはクイズとアーキテクティング課題の二つです。 クイズでは、1 日目の内容から出題し、知識の定着を図るとともに、この後のアーキテクティング課題に取り組むにあたって必要な知識の確認を行います。 アーキテクティング課題では、参加者の皆さんには、とある企業の新入社員としてアーキテクチャを設計するというシナリオで、アーキテクチャを考えていただきました。要件に沿ってどのようなサービスを選定しアーキテクチャを設計するかを検討します。まず個人で検討を行い、その後グループワークで議論を深めていきます。グループワークでは AWS 社員がサポートしますので、AWS 初学者の方でも安心してアーキテクティングの考え方を実践的に学ぶことができます。最終的にはアーキテクチャ図を成果物として作成します。AWS JumpStart を通じて、実践的なアーキテクチャ図を理解し、自ら設計・作成できるようになることを目指しています。 AWS JumpStart 2025 では、以下のようなアーキテクチャ図が最終成果物として作成されました。 参加者からの感想 参加者の皆様から、さまざまなポジティブな感想をいただくことができました。 2日間を通して、AWSのサービスについて理解を深めることができました。それぞれのサービスの特徴や他のサービスとの関連についても、さらに学習を進めていきたいと思います。 アーキテクチャ図の作成を初めてやったが、講義内容や個人調査、グループディスカッションを通して徐々に形作ることができたのが面白かった。これからはAWSの構成図を見るのが楽しくなりそう。 実際にAWS環境に触れることが初めてで手探り状態ではありましたが、今まで漠然としていたサービスだったりのイメージが少し掴めたような気がします。 自分たちが疑問に思うであろう点をあらかじめ説明していただき、内容がスムーズに理解できました。このプログラムを通じて資格の取得にも励んでいきたい。 まとめ AWS JumpStart は、AWS 初学者のエンジニアを対象とした実践的な研修プログラムです。2026 年も全 4 回の開催が決定しており、事前学習コンテンツと 2 日間のオンラインワークショップを通じて、AWS の基礎から実践的なアーキテクチャ設計まで、短期間で集中的に学ぶことができます。 AWS を学び始めたい方、実践的なスキルを身につけたい方は、ぜひ AWS JumpStart 2026 にご参加ください。皆様のご参加を心よりお待ちしております！

本ブログは 2025 年 6 月 30 日に公開された AWS Blog “ AWS Certificate Manager now supports exporting public certificates ” を翻訳したものです。 AWS Certificate Manager (ACM) は、AWS サービスやオンプレミス、ハイブリッドアプリケーション向けのパブリックおよびプライベート TLS 証明書のプロビジョニング、管理、デプロイを簡素化するサービスです。多様なワークロードに対する ACM の柔軟性をさらに高めるため、AWS は強力な新機能である ACM エクスポート可能なパブリック証明書 を導入しました。この機能により、ACM からパブリック TLS 証明書と関連するプライベートキーをエクスポートできるようになります。エクスポートした証明書は、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Elastic Kubernetes Service (Amazon EKS) Pod、オンプレミスサーバー、または他のクラウドプロバイダーでホストされているサーバー上のワークロードを保護するために使用できます。この機能は、AWS アカウントで新しく作成されたパブリック証明書をサポートしています。 このブログでは、多様なインフラストラクチャ全体でエクスポート可能なパブリック証明書のエクスポートとデプロイを自動化する方法を紹介します。EC2 インスタンスやハイブリッド環境の仮想マシンなど、複数の宛先に証明書を自動的にデプロイするワークフローの作成手順を説明します。この自動化の仕組み、メリット、および開始するためのステップバイステップガイドを提供します。さらに、 Amazon EventBridge との統合により、証明書が発行または更新されたときに自動的に証明書のエクスポートをトリガーする方法についても説明します。これにより、異種環境全体での証明書のデプロイが効率化され、管理オーバーヘッドが大幅に削減されます。 背景: ACM と証明書管理 ACM は、TLS 証明書の購入、アップロード、更新の複雑さを取り除くマネージドサービスです。 Elastic Load Balancing (ELB) 、 Amazon CloudFront 、 Amazon API Gateway など、ACM と統合された AWS サービス向けに追加料金なしでパブリック証明書を提供します。ACM は、サードパーティのパブリック証明書のインポートや、 AWS Private Certificate Authority を通じたプライベート証明書の発行もサポートしています。本日 (2025 年 6 月 30 日) のリリース以前、ACM パブリック証明書は CloudFront などの ACM と統合された AWS サービス 向けに設計されており、それらのサービスにシームレスな TLS 暗号化を提供していました。サードパーティのコンテンツ配信ネットワーク (CDN) や EC2 インスタンスで TLS を終端するワークロードでは、お客様は通常、他のプロバイダーから証明書を取得するか、一元管理のために ACM にインポートしていました。お客様からは、これらのユースケースにも ACM を使用し、そのシンプルさとスケーラビリティをより幅広い環境に拡張したいというご要望をいただいていました。新しい ACM エクスポート可能なパブリック証明書機能は、このニーズに応えるものであり、一元管理と自動更新を維持しながら、ACM で管理されたパブリック証明書をカスタムワークロードで使用するためにエクスポートできるようになりました。 ACM を使用すると、パブリック証明書をリクエストし、ドメインの所有権が検証された後、Apache、NGINX、Microsoft IIS などの TLS を終端するソフトウェアで使用するために証明書をエクスポートできるようになりました。ACM は証明書の更新を処理するため、アプリケーションを中断させる可能性のある証明書の有効期限切れのリスクが軽減されます。 仕組み: ACM パブリック証明書の発行と更新 ACM エクスポート可能なパブリック証明書を使用するには、発行と更新のプロセスを理解し、証明書管理を自動化する方法を把握する必要があります。このセクションでは、これらのプロセスと自動化機能について説明します。これらは証明書のデプロイと維持に不可欠です。 ACM パブリック証明書の発行 ACM パブリック証明書の発行には、以下の手順が含まれます。 証明書のリクエスト: ACM の AWS マネジメントコンソール、または AWS コマンドラインインターフェイス (AWS CLI) や API で、保護したいドメイン名 (例: example.com や *.example.com) を指定して証明書をリクエストします ドメイン所有権の検証 : ACM では、ドメインの管理権限を証明する必要があります。ドメインが Amazon Route 53 でホストされている場合、ACM にドメインの所有権を検証するようリクエストできます。AWS 外でホストされているドメインの場合、DNS 検証 (CNAME レコードの追加) または E メール検証 (ドメイン連絡先に送信されたメールへの応答) を使用できます 証明書の発行: ドメインの所有権が検証されると、ACM は公開鍵、プライベートキー、証明書チェーンを含む証明書を発行します 統合された AWS サービスへの証明書の関連付け: 統合された AWS サービスに証明書を関連付ける方法については、 ACM と統合されたサービス を参照してください 証明書のエクスポート: 新機能により、ACM コンソール、AWS CLI、または API を使用して、ACM と統合されていないサーバーで使用するために パブリック証明書 、プライベートキー、証明書チェーンをエクスポートできるようになりました アプリケーションへのバインド: エクスポートした証明書をサーバー (例: Apache や NGINX) にインストールして、TLS 終端を有効にします この新機能のリリースにより、ACM で作成したパブリック証明書をエクスポートできるようになりました。エクスポートの可否は証明書の作成時に指定します。 エクスポート可能なパブリック証明書を作成するには、ACM コンソールを使用して新しいパブリック証明書を作成します。開始するには、 ACM コンソール で [証明書をリクエスト] を選択し、[パブリック証明書をリクエスト] ページの [エクスポートを許可] で [エクスポートを有効にする] を選択します。[エクスポートを無効にする] を選択すると、この証明書のプライベートキーは ACM からのエクスポートが許可されなくなり、証明書の発行後に変更することはできません。 図 1: パブリック証明書をリクエストしてエクスポートを有効化 [エクスポートを有効にする] オプションを選択して証明書を作成し、ドメインの所有権の検証を完了したら、図 2 のようにエクスポートプロセスに進むことができます。証明書をエクスポートするには、証明書のリストから証明書を選択し、[その他のアクション] を選択して、[エクスポート] を選択します。 図 2: 証明書のエクスポート ACM パブリック証明書の更新 ACM は証明書の更新プロセスを自動化します。このプロセスには以下が含まれます。 更新の開始: ACM は証明書の有効期限の 60 日前に自動的に更新プロセスを開始します ドメインの再検証: ACM は初回発行時と同じ方法 (DNS または E メール) を使用してドメインの所有権を再検証します 証明書の更新: 再検証が成功すると、ACM は同じ Amazon リソースネーム (ARN) で有効期限が更新された新しい証明書を発行します ACM で証明書が更新されると、サービスは自動的に EventBridge イベントを送信し、新しい証明書が利用可能になったことを通知します。更新が失敗した場合、ACM は AWS Health Dashboard と EventBridge の両方に通知を送信します。これらの証明書イベントに関する情報を受け取るには、特定の証明書関連イベントを監視する EventBridge ルールを作成します。これらのルールを設定して Amazon Simple Notification Service (Amazon SNS) トピックに通知を送信することで、関係者が証明書のステータスに関するタイムリーな更新を受け取ることができます 新しい EventBridge スキーマフィールド: ACM 証明書の更新が成功すると、 ACM Certificate Available イベントに exportable フィールドが含まれるようになりました。このフィールドは、パブリック証明書がエクスポート可能かどうかを TRUE|FALSE で示します。 { "version": "0", "id": "id", "detail-type": "ACM Certificate Available", "source": "aws.acm", "account": "account", "time": "2019-12-22T18:43:48Z", "region": "region", "resources": [ "arn:aws:acm:region:account:certificate/certificate_ID" ], "detail": { "Action" : "ISSUANCE" | "RENEWAL" | "IMPORT" | "REIMPORT", "CertificateType" : "AMAZON_ISSUED" | "PRIVATE" | "IMPORTED", "CommonName": "example.com", "DomainValidationMethod" : "EMAIL" | "DNS", "CertificateCreatedDate" : "2019-12-22T18:43:48Z", "CertificateExpirationDate" : "2019-12-22T18:43:48Z", "DaysToExpiry" : 395, "InUse" : TRUE | FALSE, "Exported" : TRUE | FALSE, "Exportable" : TRUE | FALSE &lt;== New } } エクスポートと更新: 更新された証明書をエクスポートし、手動でサーバーに更新するか、EventBridge ルールによってトリガーされる AWS Systems Manager Automation ドキュメントなどの EventBridge ターゲットを使用して更新できます。詳細については、 Amazon EventBridge のイベントバスターゲット を参照してください EventBridge ルールを使用して特定のイベントを監視し、処理のために 1 つ以上の ターゲット (Amazon SNS トピック、 AWS Lambda 関数、その他の AWS サービスなど) に配信できます。たとえば、DNS 設定の問題によりドメイン検証が失敗した場合、ACM は ACM Certificate Renewal Action Required EventBridge イベント を生成します。SNS トピックをターゲットとする EventBridge ルールを作成することで、E メールアラートを受信するようサブスクライブし、必要な是正措置を講じることができます。 EventBridge を使用した更新済み証明書のデプロイの自動化 証明書の更新プロセスにより、手動介入なしで TLS 証明書の有効性を維持できますが、多様な環境全体で証明書を更新するには依然として手間がかかる場合があります。ACM が証明書を更新すると、EventBridge イベントが生成されます。このイベントに基づいてターゲットをトリガーする EventBridge ルールを設定できます。 通知の送信: イベントを Amazon SNS に配信して、管理者に E メールまたは SMS 通知を送信します 証明書デプロイの自動化: Lambda 関数または Systems Manager Automation ドキュメントをトリガーして、ACM API を使用して更新された証明書を取得し、サーバーに更新します 更新失敗の監視: ACM 証明書の更新失敗イベントに基づいてアラートを設定します。これらのイベントは通知チャネルに直接配信して、ドメイン検証エラーなどの問題を通知できます これを設定するには、ACM 更新イベントに一致する EventBridge ルールを作成し、ターゲット (SNS トピックや Lambda 関数など) を指定します。この自動化により手動介入が最小限に抑えられ、インフラストラクチャ全体でシームレスな証明書更新が実現します。 ソリューションの概要 このセクションでは、2 つのワークフローについて説明します。1 つ目は、既存の ACM パブリック証明書をエクスポートし、ターゲットの EC2 インスタンスまたは仮想マシンにインストールする自動化プロセスです。2 つ目は、ACM でパブリック証明書が自動更新されて利用可能になったときにトリガーされ、対象の EC2 インスタンスと仮想マシンの証明書を更新するワークフローです。このソリューションではターゲットシステムとして EC2 インスタンスと仮想マシンを使用していますが、同じ方法を適用して、さまざまな種類のシステム全体でパブリック証明書を大規模に更新できます。 前提条件 この自動化されたパブリック証明書のエクスポートと更新プロセスを拡張するには、以下を行います。 EC2 インスタンスの管理: Systems Manager による EC2 インスタンスの管理 の手順に従ってください オンプレミスや他のクラウド環境の仮想マシンの管理: Systems Manager によるハイブリッドおよびマルチクラウド環境のノード管理 の手順に従ってください 更新された証明書をデプロイする EC2 インスタンスと仮想マシンに TargetTagKey タグを追加します。自動化はこれらのタグを使用してターゲットインスタンスを識別します ExportCertificate API の操作には証明書のパスフレーズが必要です。セキュリティのベストプラクティスを維持するため、パスワードはプレーンテキストではなく、暗号化して安全に保存することをお勧めします。この実装では、 AWS Secrets Manager を使用してこれらの機密認証情報を安全に保存します。このソリューションでは、 Amazon DynamoDB を使用して証明書メタデータを維持します。これには、Secrets Manager に保存されている対応するシークレット名への参照が含まれます。セキュリティを強化するため、DynamoDB テーブルのデータは AWS Key Management Service (AWS KMS) を使用して保存時に自動的に暗号化されます ACM 証明書のエクスポート 図 3: ACM 証明書の発行とエクスポートのワークフロー 図 3 のワークフローは、既存の ACM パブリック証明書を API 駆動のプロセスでエクスポートし、対象のシステムにデプロイする自動化プロセスです。 プロセスは、ユーザーが API Gateway エンドポイントにリクエストを送信することから始まります。リクエストには、エクスポートする証明書を識別する CertificateArn 、証明書の識別用の CertName 、証明書をインストールするターゲット EC2 インスタンスを識別するための TargetTagKey と TargetTagValue などの必須パラメータが含まれます。以下は API Gateway に送信されるペイロードの例です。 { "CertificateArn": "arn:aws:acm:us-east-1:1234567890123:certificate/8106d6b2-f204-4354-8893-d49e311b3900", "CertName": "academe", "TargetTagKey": "env", "TargetTagValue": "dev" } リクエストを受信すると、API Gateway は複数のオーケストレーションされた状態を含む AWS Step Functions ワークフローをトリガーします 最初の状態では、 acm-Export という Lambda 関数が実行され、プライベートキー用のパスフレーズを生成します acm-Export Lambda 関数は、生成されたパスフレーズを Secrets Manager に安全に保存し、そのパスフレーズを使用して ACM 証明書をエクスポートします acm-Export 関数の完了後、Step Functions ワークフローは ssm-run Lambda 関数を呼び出します この関数は 2 つの操作を実行します。DynamoDB (インベントリ追跡システムとして機能) で証明書の存在を確認し、レコード管理を行います。既存の certificateARN が見つかった場合、関数は現在の CertExpiryDate と LastExportedDate のタイムスタンプ値でレコードを更新します。初めてエクスポートされる証明書の場合、一致するエントリが存在しなければ、Lambda 関数は DynamoDB に新しいレコードを作成します。この新しいレコードには、証明書の詳細と追跡情報を含むメタデータが記録されます。図 4 は、このメタデータがコンソールの DynamoDB テーブルエントリでどのように構造化されているかの例です 図 4: DynamoDB テーブル内の証明書メタデータ DynamoDB でのメタデータ検証ステップの後、Lambda 関数は Install-ACMCertificate というカスタム Systems Manager ドキュメントの実行も開始します。このドキュメントは、新しくエクスポートされたパブリック証明書を指定された EC2 インスタンスにインストールする処理を行います。同じ Systems Manager ドキュメントを使用して、オンプレミスサーバーへの証明書のインストールや更新も行うことができ、証明書デプロイの柔軟性を提供します Systems Manager ドキュメントの実行が成功すると、 TargetTagKey に一致する EC2 インスタンスに新しくエクスポートされたパブリック証明書がデプロイされます。デフォルトでは、Linux サーバーでは証明書は /etc/ssl/certs と /etc/ssl/private に保存されますが、これらのパスは Systems Manager ドキュメントでカスタマイズできます Systems Manager ドキュメントの実行が成功した後、Step Functions ワークフローは次の状態に進み、 Statuscheck という別の Lambda 関数をトリガーします。この関数は、先に開始された Systems Manager ドキュメントの実行ステータスを監視します。Step Functions ワークフローは、ターゲットの EC2 インスタンスへの証明書のインストールが成功したことを確認した後、実行を完了します ACM 証明書の更新とエクスポート 図 5: ACM 証明書と更新プロセス 証明書の有効期限が 60 日以内になると、ACM は自動的に更新プロセスを開始します。ACM が証明書の更新を正常に完了すると、以下の例のように EventBridge でイベント を生成します。 { "version": "0", "id": "id", "detail-type": "ACM Certificate Available", "source": "aws.acm", "account": "account", "time": "2019-12-22T18:43:48Z", "region": "region", "resources": [ "arn:aws:acm:region:account:certificate/certificate_ID" ], "detail": { "Action" : "RENEWAL", "CertificateType" : "AMAZON_ISSUED", "CommonName": "", "DomainValidationMethod" : "DNS", "CertificateCreatedDate" : "2025-05-22T18:43:48Z", "CertificateExpirationDate" : "2026-06-23T18:43:48Z", "DaysToExpiry" : 395, "InUse" : "TRUE", "Exported" : "TRUE", } } 図 5 のワークフローは、既存の ACM パブリック証明書を API 駆動のプロセスでエクスポートし、対象のシステムにデプロイする自動化システムです。 このソリューションでは、証明書の更新通知を監視し、それに応じて acm-renew Lambda 関数をトリガーする EventBridge ルールを使用します。関数は ACM イベントから証明書 ARN を受け取って実行を開始します。この ARN をルックアップキーとして使用し、DynamoDB テーブルをクエリして関連する証明書メタデータを取得します。このクエリから、 Certificate Name や、更新された証明書が必要なリソースを識別する TargetTag Key-Value ペアなど、重要な証明書の詳細を抽出します。これらの詳細は、その後の証明書デプロイプロセスに必要であり、更新が正しいシステムに適用されることを確認するのに役立ちます この情報はペイロードにフォーマットされ、Step Functions ワークフローをトリガーするために使用されます。この Step Functions ワークフローは、 ACM 証明書のエクスポートセクション で説明したのと同じプロセスに従います ステップ 3 から 9 は、 ACM 証明書のエクスポートセクション で説明したプロセスに従います。ステップ 9 が正常に完了すると、Step Functions ワークフローは実行を完了します。この時点で、更新されたパブリック証明書はターゲットの EC2 インスタンスに正常にインストールされ、自動化された証明書のエクスポートとインストールプロセスが完了します ソリューションのダウンロード、実行、証明書エクスポートの検証、AWS アカウントへのデプロイの詳細な手順は、 GitHub で入手できます。 料金と利用可能なリージョン ACM エクスポート可能なパブリック証明書は、AWS 商用リージョン、AWS GovCloud (US) リージョン、および中国リージョンで利用可能であり、前払いなしの従量課金制の料金モデルに従います。ELB、CloudFront、API Gateway などの ACM と統合された AWS サービス 向けのパブリック証明書は、引き続き追加料金なしで利用できます。詳細な料金については、 AWS Certificate Manager の料金 を参照してください。 まとめ ACM エクスポート可能なパブリック証明書機能により、統合されたマネージド証明書ソリューションで多様なワークロードを保護できるようになりました。EC2、コンテナ、オンプレミスサーバー、他のクラウドプロバイダー向けの証明書エクスポートが可能になったことで、ACM は一元管理、自動更新、コスト効率の高い料金を提供しながら、TLS 管理を簡素化します。ぜひ ACM コンソールでこの機能をお試しいただき、証明書管理ワークフローを効率化してください。 FAQ ACM はパブリック証明書の有効期間の短縮をサポートしますか? ACM は、今後数か月以内に CA/Browser Forum の TLS 証明書に関する要件に合わせて、パブリック証明書の有効期間を短縮する予定です。ACM は既に証明書の更新を自動的に処理し、新しい証明書がデプロイ可能になったときに通知する機能を提供しています。Amazon Trust Services (ATS) は、公的に信頼される TLS 証明書の標準が設定される CA/Browser Forum に積極的に参加しています。CA/Browser Forum の要件を満たすため、AWS は以下のスケジュールで TLS 証明書の最大有効期間を適用します。 2026 年 3 月 11 日まで、発行される TLS 証明書の最大有効期間は 398 日 2026 年 3 月 1 日以降、発行される TLS 証明書の最大有効期間は 200 日 2027 年 3 月 1 日以降、発行される TLS 証明書の最大有効期間は 100 日 2029 年 3 月 1 日以降、発行される TLS 証明書の最大有効期間は 47 日 有効期間が短い証明書の料金はどうなりますか? ACM のエクスポート可能なパブリック証明書をご利用の場合、証明書の最大有効期間の変更に伴うコスト増加についてご懸念があることを理解しています。AWS は ACM を通じて発行される証明書の公正な料金を維持することをお約束します。業界標準の変更に伴い、年間の証明書コストを現在の料金と同等に維持することを目指して、料金体系を適宜調整する予定です。料金変更が適用される前に、詳細をお知らせします。 このブログについてご質問がある場合は、 AWS サポート にお問い合わせください。 Pravin Nair Pravin は Data Protection and Privacy のシニアセキュリティソリューションアーキテクトです。お客様のビジネスニーズをサポートする安全でスケーラブルなソリューションの構築を支援しています。保存時および転送時の暗号化、インフラストラクチャセキュリティ、プライバシーに関するバックグラウンドを持っています。 Santosh Vallurupalli Santosh は AWS のシニアソリューションアーキテクトです。ネットワーキング、コンテナ、移行を専門としており、お客様のクラウド導入の過程を支援し、困難な課題に対するクラウドに特化したソリューションの構築を楽しんでいます。仕事以外では、旅行、F1 観戦、「The Office」を繰り返し視聴することが好きです。 Chandan Kundapur Chandan は AWS Certificate Manager (ACM) チームのプリンシパルテクニカルプロダクトマネージャーです。約 20 年のサイバーセキュリティ経験を持ち、AWS のお客様がパブリックおよびプライベート証明書でリソースとエンドポイントを識別し保護できるよう、ACM チームの製品戦略を推進することに情熱を注いでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは株式会社 Works Human Intelligence 様と Amazon Web Services Japan 合同会社が共同で執筆しました。 Works Human Intelligence (以下、WHI) は「人に真価を。」をコーポレートブランドに掲げ、日本の大手企業および公共・公益法人向け統合型人事システム COMPANY の開発・販売・サポートの他、HR 関連サービスの提供を行っています。WHI は人事部門が定型業務ではなく戦略的な業務に取り組めるよう尽力しており、今回は AWS の Generative AI Innovation Center (以下、GenAIIC) とともに取り組んだ AI Agent を活用したプロダクト構築から得た知見についてご紹介します。 背景 Overview 人事システムをご利用されるお客様は、組織変更や人事制度変更、社員情報の更新といった多くの場面で対応が必要となります。WHI では AI Agent を活用することで、担当部署の方々の業務負荷軽減、生産性向上に寄与できることを期待しています。実際に AI Agent を活用したプロダクトの構築に取り組んだところ、いくつかの悩みが生じました。WHI が課題解決に向けて取り組む中で、GenAIIC には新しい観点を追加し、良いものを作るためのサポートを期待していました。 今回のプロジェクトの対象は、担当部署の方の業務を支援する 2 つの AI Agent です。 1 つ目の AI Agent (以下、通勤手当エージェント) は引越しの際などに生じる通勤手当申請の承認に関するエージェントです。2 つ目の AI Agent (以下、ブラウザ操作エージェント) は、お客様に代わって COMPANY を操作するエージェントとなっています。 ここからは通勤手当エージェント、ブラウザ操作エージェントの順に、2 つのエージェントの課題と解決方法をお伝えします。 通勤手当エージェント 課題 Challenge 通勤手当エージェントは、通勤手当申請の承認という定型業務を支援するエージェントです。WHI では既に LangGraph と Amazon ECS、AWS Fargate を用いた PoC を進めていましたが、開発途中で Amazon Bedrock AgentCore がリリースされたため、移行を検討し始めました。 COMPANY とシームレスに統合する AI Agent の実現に向けての Amazon Bedrock AgentCore でのソリューション構築、および現行開発している AWS Fargate や Amazon Cognito を用いた認証認可の実装を含んだ統合的なマルチエージェント環境への移行を GenAIIC と共に実施したいと考えました。 解決策 Solution overview 通勤手当エージェントは LangGraph と Amazon ECS を利用して開発していましたが、全て同じ ECS タスクとして起動するモノリシックな構成になっていることに対して WHI も懸念がありました。そこで、サブエージェントは個別に Amazon Bedrock AgentCore Runtime で起動するように変更しました。マルチテナント対応が求められていたため、自分たちで構築できる自由度を求めて Amazon DynamoDB と Amazon Cognito を用いてテナント管理をすることとしました。 アーキテクチャ 通勤手当エージェントは Slack が呼び出しの起点となるため、呼び出されたタイミングで認証を行い、リクエストに対して適切な各サブエージェントが処理を行う仕組みとなっています。 結果 Results and Impact プロジェクトの途中で Amazon Bedrock AgentCore が GA したことで、本格的に活用できるようになりました。通勤手当エージェントは LangGraph を継続して利用していますが、サブエージェントは別の Runtime で起動するように変更を行いました。この対応により将来のサブエージェント拡充を容易にしています。今後はサブエージェントを束ねるスーパーバイザーエージェントを Strands Agents に変更することも検討しています。 また、今まではエージェントの状態を確認するために Langfuse をホストしていたため運用コストが発生していましたが、Amazon Bedrock AgentCore Observability に変更することで負荷が軽減されました。 ブラウザ操作エージェント 課題 Challenge ブラウザ操作エージェントは、ブラウザを使い、COMPANY にアクセスし、内容を確認した後、操作を行なってエビデンスを取得する処理を行います。構築は LangGraph と Playwright MCP で進めていました。ブラウザ操作のトークン数は、以下のアプローチによって、88% の削減効果が確認できていました。 エージェントループ (AI と Playwright MCP との会話履歴) から過去の不要になった部分を削除 Playwright MCP の戻り値からブラウザ操作に不要な部分を削除 TOOL 部分のプロンプトキャッシュの有効化 しかしながら、独自実装に依存していたため、Strands Agents への移行が困難といった課題を抱えていました。また、より一層トークンを削減する方法について検討していました。こうした中で GenAIIC と協働することとなりました。 解決策 Solution overview ブラウザ操作エージェントは Strands Agents を使い、いくつかのブラウザ操作ツールを試しながら、処理がうまくいくことを確認し、その後は利用するトークン数の削減に取り組みました。エージェントのワークフローは以下の 5 つのステップで構成されています。 操作テンプレート選択 : ユーザーの指示に基づき、ナレッジベースから最適な操作テンプレートを検索します。 操作マニュアル作成 : 取得したテンプレートのプレースホルダーを、別のナレッジベースから取得した情報で置換します。 ブラウザ操作 ( 現状確認 ): 作成したマニュアルに基づき、ブラウザを操作して現状の確認を行います。 変更案作成: 現状確認で得られた情報 (CSV など ) を基に、変更案を作成し、ユーザーに提示します。 変更実行 ( ブラウザ操作 ): ユーザーの承認後、変更案に基づき再度ブラウザを操作して変更を実行します。 基本的なワークフローを定めていますが、ユーザーのインプットに情報が足りない場合や、一部の作業のみ行うことなどもエージェントの自立的な判断で柔軟に対応できます。 アーキテクチャ ブラウザ操作エージェントから COMPANY へのアクセスには IP アドレス制限を行なっているため、VPC 内に Amazon Bedrock AgentCore Runtime を配置し、NAT ゲートウェイ経由で固定 IP アドレスでアクセスする構成としました。また、操作テンプレートや操作手順作成時の補助情報を格納するナレッジベース、短期的な情報を保存する S3 バケットも構築しました。 結果 Results and Impact ブラウザ操作エージェントは Strands Agents を利用して構築しました。ブラウザ操作ツールは browser-use、Playwright、fast playwright を試し、fast playwright が消費するトークン数が最も少ないことを確認しました。加えて、Bedrock のプロンプトキャッシュの有効化やシステムプロンプトの変更といった改善を WHI と GenAIIC で協力して行ったことで、一回の処理でかかる費用を最大 97% 削減することに成功しました。 主な改善施策は以下の通りです。 ユーザーメッセージも対象としたプロンプトキャッシュの活用 : Bedrock のプロンプトキャッシュ機能を有効化 (2,171 円 → 307 円 ) エージェントの行動最適化 : サブエージェントのプロンプトを改善し、不要な操作を削減 (307 円 → 154 円 ) モデルの変更 : モデルを Claude Sonnet 4.5 から Haiku 4.5 に変更 (154 円 → 56 円 ) これらの改善によりコストを最適化しつつ、複数の変更を連続して実行するシナリオや、指示が曖昧な場合にエージェントから人間に質問するシナリオなど、より複雑なタスクも成功させることができました。 まとめと今後 Conclusion and Next step WHI と GenAIIC が協力して開発を進めたことで、AI Agent の実行基盤を Amazon Bedrock AgentCore Runtime に移すことに成功し、Amazon Bedrock AgentCore Observability を活用して稼働状況を確認できるようになりました。 Amazon Bedrock AgentCore を利用することによって、マネージドサービスでログの確認も容易にできるようになり非常に開発が楽になった、また、ブラウザエージェントは Strands Agents にしたことで、柔軟に動作するエージェントが少ない実装で実現できたと WHI メンバーは語っています。現実には数多くの定型作業が存在するため、それらを支援する AI Agent を構築することは難しさを伴いますが、GenAIIC との協業により、ビジネスロジックの開発に集中できる状態に到達しています。 Amazon Bedrock AgentCore は実行基盤にあたる Runtime だけではなく、他の機能も備えているため、WHI では今後の活用を検討しています。また、AI Agent はモデルの変更によって挙動もコストも変わります。今回のプロジェクトを通じて、処理が実行可能であることまで確認ができたため、 今後も継続してモデルの検証を行いコスト最適化を実施する予定です。

2025 年の年末は、長い休憩を取って南半球の素晴らしい夏を楽しむことができました。休暇から戻り、私にとって 2026 年最初の記事を書いているのですが、この記事は AWS ニュースブログで私が書く最後の記事でもあります (これについては後ほど説明したいと思います)。 AWS コミュニティは、世界中で開催されているさまざまな AWS re:invent re:Caps で今年も好調なスタートを切っています。また、既に AWS Community Day イベント を開催しているコミュニティもあり、先週は AWS Community Day Tel Aviv 2026 が行われました。 2026 年 1 月 12 日週のリリース 2026 年 1 月 12 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Kiro CLI の最新機能 – Kiro CLI が、ウェブフェッチ URL のきめ細かな制御、カスタムエージェントのためのキーボードショートカット、強化された差分ビューなどを提供するようになりました。これらの機能強化により、許可リストまたはブロックリストを使用してエージェントがアクセスできる URL を制限したり、単一のセッションで複数の専門エージェントを使用するときのシームレスなエクスペリエンスを確保したりするなど、さまざまなアクションが可能になります。 AWS European Sovereign Cloud – 2023 年に発表された、新しい独立したクラウドインフラストラクチャを構築する計画 に続き、すべてのお客様に対する AWS European Sovereign Cloud の一般提供が発表されました。このクラウドでは、包括的な一連の AWS サービスを使用して、ヨーロッパのお客様の最も厳しい主権要件を満たす体制が整えられています。 Amazon EC2 X8i インスタンス – 以前に AWS re:Invent 2025 でプレビュー版としてリリース された、新しいメモリ最適化 Amazon Elastic Compute Cloud (Amazon EC2) X8i インスタンスの一般提供が先週発表されました。X8i インスタンスは、3.9 GHz の持続的なオールコアターボ周波数を備えたカスタム Intel Xeon 6 プロセッサを搭載しており、利用できるのは AWS 上のみです。これらの SAP 認定インスタンスは、クラウド内の同等の Intel プロセッサの中でも最高のパフォーマンスと最速のメモリ帯域幅を提供します。 その他のアップデート これらのプロジェクト、ブログ記事、ニュース記事も目に留まりました。 5 core features in Amazon Quick Suite – AWS VP Agentic AI である Swami Sivasubramanian が、ほとんど何にでも Amazon Quick Suite を使用する方法について語ります。2025 年 10 月、業務上の質問にすばやく回答し、インサイトをアクションに変換する新しいエージェンティックチームメイトとして Amazon Quick Suite が発表されました。Amazon Quick Suite は、1 つのトピックに関して多角的な視点を提供するだけでなく、さまざまなトピックに関するリサーチにも役立つ、お気に入りの生産性向上ツールの 1 つになりました。 Deploy AI agents on Amazon Bedrock AgentCore using GitHub Actions – 2025 年、Amazon Bedrock AgentCore が発表されました。これは、Amazon Bedrock でホストされているか他の環境でホストされているかにかかわらず、さまざまなフレームワークやモデルで AI エージェントをシームレスに作成し、管理できるようにする柔軟なサービスです。GitHub Actions ワークフローを使用して、AgentCore Runtime で AI エージェントのデプロイを自動化する方法を学びましょう。このアプローチは、エンタープライズレベルのセキュリティ制御を備えたスケーラブルなソリューションを提供し、継続的インテグレーションとデリバリー (CI/CD) の完全な自動化を実現します。 近日開催予定の AWS イベント 1 月 28 日または 29 日 (タイムゾーンによって異なります) に行われる Best of AWS re:Invent に参加しましょう。この無料バーチャルイベントは、AWS re:Invent からの最もインパクトのある発表と、一番人気のセッションをお届けするイベントです。オープニングセッションでは、AWS VP 兼 Chief Evangelist の Jeff Barr がハイライトをご紹介します。 25 万 USD の賞金と AWS クレジットを獲得できる Global 10,000 AIdeas Competition への応募が締め切られる 1 月 21 日まであとわずかになりました (「AIdeas」の「I」は「Idea」の「I」で、「L」の小文字ではありません)。コードはまだ必要ないので、アイデアだけを提出してください。セミファイナリストに選ばれた場合は、 AWS 無料利用枠 の範囲内で Kiro を使用してアプリを構築することになります。賞金の獲得や、 AWS re:Invent 2026 で特集される可能性以外にも、次世代 AI ツールを実際に使用する経験を積み、世界中のイノベーターとつながることができます。 1 月の初めに、 コミュニティビルダープログラムの 2026 年の申し込みが開始されました 。申し込みは 1 月 21 日の午後 24 時 (太平洋標準時) までとなっています。このプログラムに参加する最後のチャンスをお見逃しなく。 こうした機会に興味がある場合は、 AWS Builder Center に参加して、AWS コミュニティのビルダーとともに学びましょう。 以上で、私がここ AWS で過ごした最も有意義な章の 1 つを締めくくりたいと思います。皆さんのために記事を書くことは、私にとって本当に素晴らしい経験でした。チームと私が全力を傾けて書いた記事を読むために時間を取ってくださった皆さんに感謝しています。ローンチチームとの緊密なコラボレーションと、皆さんからのフィードバックは、私が成長する糧となりました。サハラ以南のアフリカ (SSA) コミュニティは大きく成長しており、私はこのコミュニティに集中する時間を増やしたいと考えています。とは言うものの、AWS での仕事は続けていくので、お近くのイベントで皆さんとお会いできるのを楽しみにしています! 2026 年 1 月 26 日週の Weekly Roundup もお楽しみに! – Veliswa Boya 原文は こちら です。

こんにちは。ソリューションアーキテクトの柴田です。 2025 年 11 月 21 日に「Security for App Builders @ Loft #1」イベントを目黒の AWS Startup Loft Tokyo にて開催しました。こちらは AWS 上のアプリケーションそのものや、SDLC (ソフトウェア開発ライフサイクル) におけるセキュリティの考え方にフォーカスした、開発者・セキュリティエンジニアの方向けのイベントです。第一回では特に Coding Agent が生成したコードの安全性の確保という課題に焦点を当てて開催しております。ご参加いただきました皆様には、改めて御礼申し上げます。 本ブログでは、当日の内容を簡単にご紹介しつつ、発表資料を公開いたします。 イベント概要 AI を活用した開発プロセスが浸透するに従い、必ずしもセキュリティに精通したエンジニアが関与できない状況で技術的な判断をする機会が増えつつあります。これにより、時に生成 AI や Coding Agent が生成したコードの安全性をどのように説明するかという点で、多くの開発者が悩みを抱えています。 本イベントは、こうした課題を抱えるアプリケーション開発者向けに、セキュリティの原理原則とプラクティスを学んでいただくことを目的にセッションを実施いたしました。セキュリティ組織の方々にとっても、開発現場とのコミュニケーションを円滑にするための知見を得られる内容となっています。また、セッション終了後はネットワーキングということで、各社プロダクトのセキュリティに関心を持つ方同士での情報交換も行われました。 以下、各セッションの概要と当日の様子を紹介いたします。 セッションの紹介 Opening Session : なぜ今アプリケーションセキュリティなのか アマゾン ウェブ サービス ジャパン 合同会社 技術統括本部 デジタルサービス技術本部 ISV/SaaS ソリューション部 部長 大場 崇令 イベントの冒頭では、大場より、AI がコードを書く時代における新たなセキュリティ課題について解説しました。イベント直前に RC1 が公開された OWASP Top10:2025 をピックアップし、アプリケーションセキュリティにおいては、アクセスコントロールの欠陥、設計上の欠陥、サプライチェーン攻撃など、考慮すべき要素が時代と共に変化していることにも触れつつ、AWS 上でセキュアに開発を行うための考え方について全体感を説明しました。 セッション資料 ビルダーのための脅威モデリング アマゾン ウェブ サービス ジャパン 合同会社 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクト 泉 航 SDLC では不具合の修正は早いほどコストが低いと言われています。本セッションでは設計フェーズにおいて構造的欠陥を見つけ出す手段である脅威モデリングについて、どのような流れで進めるのか、効果的なアプローチや進めるためのフレームワークについて泉より解説しました。EC サイトに対する脅威を例に、STRIDE フレームワークによる脅威モデリングの進め方をご案内すると共に、これまで労力のかかっていた脅威モデリングの取り組みについても Kiro を用いることでより少ない準備時間でも脅威モデリングが実施できることを紹介しました。 セッション資料 セキュリティのシフトレフト アマゾン ウェブ サービス ジャパン 合同会社 技術統括本部 デジタルサービス技術本部 ソリューションアーキテクト 吉田 裕貴 吉田からは、SDLC の各フェーズにおけるセキュリティの実践について、その重要性とどのようなツールが利用できるかを解説しました。DevSecOps の登場当時は一定の対応難易度の高さがあったものの、2025 年時点においては SAST / DAST などのツールが検出した結果を元に AI と対話しながら開発者自身で理解を進めることができるようになっています。こうした時代において、改めて Amazon Q Developer を用いた静的レビュー、パイプライン上での SCA、デプロイ後の監視など複数のツールを組み合わせて開発チームとしてシフトレフトの仕組みを実現する方法を紹介しました。 セッション資料 マネージドサービスによるアプリケーションセキュリティの実装 アマゾン ウェブ サービス ジャパン 合同会社 技術統括本部 デジタルサービス技術本部 シニアソリューションアーキテクト 柴田 龍平 最後のセッションでは、柴田より AI Coding 時代に求められる開発チームとセキュリティチーム間のコラボレーションについて触れ、「セキュリティガーディアン」と呼ばれる AWS 内部のプログラム をご紹介しながら、どのようにセキュリティを確保しながら AI による開発をスケールさせるかというお話をしました。セッションの後半では、認証や認可を例に可能な限りマネージドサービスを活用することで、Undeferenciated Heavy Lifting を減らすというお話をしました。本番稼働させるアプリケーションにおいては、安全性のため、そして将来のメンテナンス時のコンテキストのためにも、全てを AI に作り込ませず、可能な限りマネージドサービスや、スタンダードな技術を活用するよう Agent をコントロールしていくことの重要性をお伝えしました。 セッション資料 まとめ 本イベントではセッション後はネットワーキングの場もあり、参加された方からも「今回のセッションは意識付け、仕組みの導入など自社に必要なものが多く参加してよかった」「脅威モデリングを社内に広めていきたい」「セキュリティについて特別な対策はなく、今まで通りの考え方が重要であることが改めて理解できて良かった」とポジティブなフィードバックをいただきました。 本イベントをきっかけに、多くの開発者の皆様に AI Agent を活用しながらより安全で信頼性の高いアプリケーションを構築するためのヒントを得ていただければ幸いです。本文内へリンクされた各セッション資料も是非ご参考ください。各セッションでセキュリティ改善にも AI 自体を活用する、という点に触れておりましたが、12月に行われた re:Invent 2025 では SDLC 全体のアプリケーション保護を行うための フロンティアエージェント として AWS Security Agent もプレビューとして発表されておりますので、ぜひこちらもご確認ください。今後も、お客様のアプリケーション開発におけるセキュリティ向上を支援するため、このようなイベントを継続的に企画・開催してまいります。AWS のサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、 こちらのリンク からぜひお申し込みください。 アマゾン ウェブ サービス ジャパン ソリューションアーキテクト 柴田 龍平

&nbsp; Deutsch | English | Español | Français | Italiano 私は欧州市民として、特に公共部門の組織や規制の厳しい業界におけるデジタル主権の重要性を身をもって理解しています。2026 年 1 月 14 日、 AWS European Sovereign Cloud の一般提供が、すべてのお客様に対して開始されたことをお知らせいたします。 弊社は、この新しい独立したクラウドインフラストラクチャを構築する計画を 2023 年に初めて発表しましたが 、2026 年 1 月 14 日、 包括的な一連の AWS サービスにより 、欧州のお客様の極めて厳格な主権要件を満たす準備が整いました。 ブランデンブルク門 (ベルリン) の夕焼け 欧州の主権要件への対応 欧州全域の組織は、データレジデンシー、運用上のコントロール、ガバナンスの独立性に関する、ますます複雑化する規制要件に直面しています。今日において、極めて厳しい主権要件を満たす必要がある欧州の組織が、従来のオンプレミス環境や、サービスと機能が制限されたオファリングにがんじがらめになっている例は枚挙にいとまがありません。この重要なニーズに応えるため、AWS European Sovereign Cloud は、強力な技術的なコントロール、主権保証、法的保護に裏付けられた、独立運用されるフル機能の唯一のソブリンクラウドです。規制の厳しい業界の公共部門や企業は、最新のクラウドサービスに期待されるイノベーション、セキュリティ、信頼性を維持する、強化された主権コントロールを提供するクラウドインフラストラクチャを必要としています。これらの組織は、データと運用が欧州の管轄下にあり、明確なガバナンス構造と欧州連合 (EU) 内での運用の自律性を確実に実現する必要があります。 欧州向けの新しい独立したクラウドインフラストラクチャ AWS European Sovereign Cloud は、物理的および論理的に独立したクラウドインフラストラクチャであり、すべてのコンポーネントが完全に EU 内に配置されています。AWS European Sovereign Cloud の最初の AWS リージョン はドイツのブランデンブルク州にあり、2026 年 1 月 14 日より一般公開されています。このリージョンは、既存の AWS リージョンとは独立して運用されます。このインフラストラクチャは、冗長化された電源とネットワーキングを備えた複数のアベイラビリティーゾーンを特徴としており、世界との接続が中断された場合でも継続して稼働するように設計されています。 当社は、厳格な分離、国内のデータレジデンシー、低レイテンシーの要件をサポートするため、AWS European Sovereign Cloud のフットプリントを、ドイツから EU 全体に拡張することを計画しています。これは、ベルギー、オランダ、ポルトガルにある新しいソブリン ローカルゾーン から始まる予定です。さらに、AWS European Sovereign Cloud インフラストラクチャは、 AWS 専有ローカルゾーン 、 AWS AI Factory 、または AWS Outposts を利用して、選択した場所 (お客様独自のオンプレミスデータセンターを含む) で拡張できるようになる予定です。 AWS European Sovereign Cloud とそのローカルゾーンは、独自の運用モデルを通じて、強化された主権コントロールを提供します。AWS European Sovereign Cloud は、EU 内に所在する EU 居住者によってのみ運用されるようになる予定です。これには、日常的な運用、技術サポート、カスタマーサービスなどの活動が含まれます。弊社は現在、AWS European Sovereign Cloud を、 EU 内に所在する EU 市民によってのみ運用される ように段階的に移行しています。この移行期間中、当社は引き続き EU 居住者と EU 内に所在する EU 市民から成る混合チームで業務を継続していく予定です。 インフラストラクチャは、ドイツの法令に基づいて設立された専用の欧州法人を通じて管理されます。2025 年 10 月、AWS は、EU 在住の EU 市民である Stéphane Israël 氏を Managing Director に任命しました。Stéphane 氏は、インフラストラクチャ、テクノロジー、サービスを含む AWS European Sovereign Cloud の管理と運用を担当するとともに、AWS のより広範なデジタル主権の取り組みを主導していく予定です。また、2026 年 1 月、AWS は Stefan Hoechbauer 氏 (AWS、Vice President, Germany and Central Europe) を AWS European Sovereign Cloud の Managing Director に任命しました。Hoechbauer 氏は、Stéphane Israel 氏とともに、AWS European Sovereign Cloud を率いていく予定です。 EU 市民のみで構成され、独立した第三者である代表者 2 名を含むアドバイザリーボードが、主権に関する問題について、追加的な監督と専門知識を提供します。 強化されたデータレジデンシーとコントロール AWS European Sovereign Cloud は、包括的なデータレジデンシーの保証を提供するため、極めて厳格なデータレジデンシー要件を満たすことができます。世界中の既存の AWS リージョンと同様に、お客様が別途選択しない限り、すべてのコンテンツはお客様が選択したリージョン内に保存されたままとなります。また、コンテンツに加えて、ロール、許可、リソースラベル、設定など、お客様が作成したメタデータも、EU 内にとどまります。このインフラストラクチャは、その独自の専用 AWS Identity and Access Management (IAM) と課金システムを備えており、すべて欧州圏内で独立して運用されています。 インフラストラクチャに組み込まれた技術的なコントロールにより、 EU 域外からの AWS European Sovereign Cloud へのアクセスが防止 されます。このインフラストラクチャには、 認証期間の運用のための専用の欧州トラストサービスプロバイダー が含まれており、専用の Amazon Route 53 ネームサーバーを使用します。これらのサーバーは、 自身の名前に European Top-Level Domains (TLD) のみを使用します。AWS European Sovereign Cloud は、EU 域外の人員やインフラストラクチャに重大な依存関係を有していません。 セキュリティとコンプライアンスのフレームワーク AWS European Sovereign Cloud は、暗号化、キー管理、アクセスガバナンス、コンピューティング分離のための AWS Nitro System など、お客様が AWS に期待するのと同じコアセキュリティ機能を維持しています。これは、EC2 インスタンスが、暗号的に検証されたプラットフォームの完全性と、ハードウェアで強制された境界から恩恵を享受し、パフォーマンスを犠牲にすることなくデータへの不正アクセスを防止して、ワークロードに必要な主権制御と計算能力の両方を提供することを意味します。インフラストラクチャは、ISO/IEC 27001:2013、SOC 1/2/3 レポート、 Federal Office for Information Security (BSI) C5 認証などのコンプライアンスプログラムに準拠した、 独立したサードパーティー監査 を受けています。 AWS European Sovereign Cloud: Sovereign Reference Framework は、ガバナンスの独立性、運用上のコントロール、データレジデンシー、技術的分離にわたる具体的な主権制御を定義します。このフレームワークは AWS Artifact で利用でき、SOC 2 認証を通じてエンドツーエンドの可視性を提供します。 包括的なサービス可用性 AWS European Sovereign Cloud では、提供開始時から幅広い AWS サービスにアクセスいただけます。これには、人工知能および機械学習 (AI/ML) ワークロード向けの Amazon SageMaker や Amazon Bedrock が含まれます。コンピューティングには、 Amazon Elastic Compute Cloud (Amazon EC2) と AWS Lambda をご利用いただけます。コンテナオーケストレーションは、 Amazon Elastic Kubernetes Service (Amazon EKS) と Amazon Elastic Container Service (Amazon ECS) を通じてご利用いただけます。データベースサービスには、 Amazon Aurora 、 Amazon DynamoDB 、 Amazon Relational Database Service (Amazon RDS) が含まれます。ストレージオプションには、 Amazon Simple Storage Service (Amazon S3) と Amazon Elastic Block Store (Amazon EBS) 、 Amazon Virtual Private Cloud (Amazon VPC) を封じたネットワーキング、 AWS Key Management Service (AWS KMS) と AWS Private Certificate Authority を含むセキュリティサービスが含まれます。最新のサービスリストについては、AWS Builder Center で最近公開された AWS Capabilities の表 をご覧ください。 AWS European Sovereign Cloud は、お客様が主権要件を満たすのを支援することに尽力している AWS パートナーによってサポートされています 。Adobe、Cisco、Cloudera、Dedalus、Esri、Genesys、GitLab、Mendix、Pega、SAP、SnowFlake、Trend Micro、Wiz などのパートナーが、AWS European Sovereign Cloud でソリューションを提供しており、セキュリティ、データ分析、アプリケーション開発、業界固有のワークロードの分野で必要なツールとサービスを提供しています。この幅広いパートナーサポートは、AWS サービスと信頼できるパートナーテクノロジーを組み合わせたソブリンソリューションを構築するのに役立ちます。 欧州のインフラストラクチャへの多額の投資 AWS European Sovereign Cloud は、インフラストラクチャ、雇用創出、スキル開発に対する 78 億 EUR の投資によって支えられています。この投資は、2040 年までに欧州経済に 172 億 EUR の貢献をもたらし、現地の企業で年間約 2,800 人のフルタイム相当の雇用を支えると見込まれています。 技術的な詳細 AWS European Sovereign Cloud は、所在地を問わず、すべてのお客様にご利用いただけます。インフラストラクチャには、 パーティション 名である aws-eusc とリージョン名である eusc-de-east-1 を使用してアクセスできます。パーティションは、AWS リージョンのグループです。各 AWS アカウントは、1 つのパーティションにスコープされます。 インフラストラクチャは、 AWS マネジメントコンソール 、 AWS SDK 、 AWS コマンドラインインターフェイス (AWS CLI) など、すべての標準的な AWS アクセス方法をサポートしているため、既存のワークフローやオートメーションに簡単に統合できます。AWS European Sovereign Cloud パーティション用の新しいルートアカウントを作成したら、このインフラストラクチャ固有の新しい IAM ID とロールを作成することから始めます。これにより、欧州ソブリン環境内のアクセス管理を完全に制御できます。 今すぐ始めましょう AWS European Sovereign Cloud は、AWS のイノベーションと機能へのアクセスを維持しながら、強化された主権コントロールを欧州の組織に提供します。Amazon Web Services EMEA SARL を通じてサービス契約を締結できます。料金は EUR 建てで、請求は 今日サポートされている 8 つの通貨 のいずれかで行われます。このインフラストラクチャは、使い慣れた AWS アーキテクチャ、サービスポートフォリオ、API を使用しているため、アプリケーションの構築と移行が容易です。 AWS European Sovereign Cloud の補遺 には、AWS European Sovereign Cloud に関する追加の契約上のコミットメントが記載されています。 欧州人である私にとって、今回のリリースは、私たちの大陸特有のニーズに応え、業界全体にわたってイノベーションを推進するクラウド機能を提供するという AWS のコミットメントを表しています。AWS European Sovereign Cloud について、そしてお客様の組織が主権要件を満たすのにそれがどのように役立つのかについて、ぜひ詳しくご確認ください。「 Overview of the AWS European Sovereign Cloud 」を読んで、設計目標とアプローチの詳細をご確認いただき、 新規アカウントにサインアップ して、今すぐ最初のワークロードのデプロイを計画しましょう。 – seb 原文は こちら です。 ドイツ語版 Start der AWS European Sovereign Cloud Als Bürger Europas weiß ich aus eigener Erfahrung, wie wichtig digitale Souveränität ist, insbesondere für unsere öffentlichen Einrichtungen und stark regulierten Branchen.Ich freue mich, Ihnen heute mitteilen zu können, dass die AWS European Sovereign Cloud nun für alle Kunden allgemein verfügbar ist. Wir haben unsere Pläne zum Aufbau dieser neuen unabhängigen Cloud-Infrastruktur erstmals im Jahr 2023 vorgestellt .Heute ist diese Infrastruktur bereit, mit einem umfassenden Angebot an AWS-Services die strengsten Souveränitätsanforderungen europäischer Kunden zu erfüllen. Berlin, Brandenburger Tor bei Sonnenuntergang Erfüllung europäischer Souveränitätsanforderungen Organisationen in ganz Europa sehen sich mit zunehmend komplexen regulatorischen Anforderungen in Bezug auf Datenresidenz, operative Kontrolle und Unabhängigkeit der Governance konfrontiert.Europäische Organisationen mit höchsten Souveränitätsanforderungen sind heutzutage allzu oft in veralteten lokalen Umgebungen oder Angeboten mit eingeschränkten Services und Funktionen gefangen.Die AWS European Sovereign Cloud ist die Antwort auf diesen dringenden Bedarf.Sie ist die einzige unabhängig betriebene souveräne Cloud mit vollem Funktionsumfang, die durch strenge technische Kontrollen, Souveränitätszusicherungen und rechtlichen Schutz abgesichert ist.Einrichtungen des öffentlichen Sektors und Unternehmen in stark regulierten Branchen benötigen eine Cloud-Infrastruktur, die erweiterte Souveränitätskontrollen bietet und gleichzeitig die von modernen Cloud-Services erwartete Innovation, Sicherheit und Zuverlässigkeit gewährleistet.Diese Organisationen benötigen die Zusicherung, dass ihre Daten und Aktivitäten unter europäischer Zuständigkeit bleiben, mit klaren Governance-Strukturen und operativer Autonomie innerhalb der Europäischen Union (EU). Eine neue unabhängige Cloud-Infrastruktur für Europa Die AWS European Sovereign Cloud ist eine physisch und logisch getrennte Cloud-Infrastruktur, deren Komponenten sich vollständig innerhalb der EU befinden.Die erste AWS-Region in der AWS European Sovereign Cloud befindet sich im deutschen Bundesland Brandenburg und ist ab heute allgemein verfügbar.Diese Region arbeitet unabhängig von bestehenden AWS-Regionen.Die Infrastruktur umfasst mehrere Availability Zones mit redundanter Stromversorgung und Netzwerkverbindung, die auch bei einer Unterbrechung der Verbindung zum Rest der Welt einen kontinuierlichen Betrieb gewährleisten. Wir beabsichtigen, die Präsenz der AWS European Sovereign Cloud von Deutschland aus EU-weit auszuweiten, um strenge Anforderungen hinsichtlich Isolierung, Datenresidenz innerhalb einzelner Länder und geringer Latenz zu erfüllen.Dies beginnt mit neuen souveränen Local Zones in Belgien, den Niederlanden und Portugal.Darüber hinaus können Sie die Infrastruktur der AWS European Sovereign Cloud mit dedizierten AWS Local Zones , AWS AI Factories oder AWS Outposts an Standorten Ihrer Wahl, einschließlich Ihrer eigenen lokalen Rechenzentren, erweitern. Dank ihres einzigartigen Betriebsmodells bieten die AWS European Sovereign Cloud und ihre Local Zones erweiterte Souveränitätskontrollen.Der Betrieb der AWS European Sovereign Cloud wird ausschließlich von EU-Bürgern mit Wohnsitz in der EU sichergestellt.Dies umfasst Aktivitäten wie den täglichen Betrieb, den technischen Support und den Kundenservice.Wir stellen die AWS European Sovereign Cloud schrittweise so um, dass als Betriebspersonal ausschließlich EU-Bürger mit Wohnsitz in der EU zum Einsatz kommen .Während dieser Übergangsphase werden wir weiterhin mit einem gemischten Team aus in der EU ansässigen Personen und in der EU lebenden EU-Bürgern arbeiten. Die Infrastruktur wird durch spezielle europäische juristische Personen nach deutschem Recht verwaltet.Im Oktober&nbsp;2025 berief AWS Stéphane Israël , einen in der EU ansässigen EU-Bürger, zum Geschäftsführer.Stéphane wird für das Management und den Betrieb der AWS European Sovereign Cloud verantwortlich zeichnen.Dies umfasst die Bereiche Infrastruktur, Technologie und Services sowie die Federführung bei den breit angelegten Initiativen von AWS auf dem Gebiet der digitalen Souveränität.Im Januar&nbsp;2026 ernannte AWS zudem Stefan Hoechbauer (Vice President, Germany and Central Europe, AWS) zum Geschäftsführer der AWS European Sovereign Cloud.Er wird gemeinsam mit Stéphane Israel die Leitung der AWS European Sovereign Cloud innehaben. Ein Beirat, dem ausschließlich EU-Bürger, einschließlich zwei unabhängigen externen Vertretern, angehören, fungiert als zusätzliche Kontrollinstanz und bringt Fachwissen in Fragen der Souveränität ein. Verbesserte Datenresidenz und -kontrolle Die AWS European Sovereign Cloud bietet umfassende Garantien hinsichtlich der Datenresidenz, sodass Sie selbst die strengsten Anforderungen in diesem Bereich erfüllen können.Wie auch bei unseren bestehenden AWS-Regionen weltweit verbleiben alle Ihre Inhalte in der von Ihnen ausgewählten Region, sofern Sie keine anderen Einstellungen vornehmen.Neben den Inhalten verbleiben auch die vom Kunden erstellten Metadaten, einschließlich Rollen, Berechtigungen, Ressourcenbezeichnungen und Konfigurationen, innerhalb der EU.Die Infrastruktur verfügt über ein eigenes AWS Identity and Access Management (IAM) und ein eigenes Abrechnungssystem – beides wird innerhalb der europäischen Grenzen unabhängig betrieben. In die Infrastruktur integrierte technische Kontrollen verhindern den Zugriff auf die AWS European Sovereign Cloud von außerhalb der EU .Die Infrastruktur umfasst einen dedizierten europäischen Trust Service Provider für Zertifizierungsstellen und nutzt dedizierte Amazon-Route-53 -Namenserver.Diese Server verwenden ausschließlich europäische Top-Level-Domains (TLDs) für ihre eigenen Namen .Die AWS European Sovereign Cloud unterliegt keinen kritischen Abhängigkeiten hinsichtlich Personal oder Infrastruktur außerhalb der EU. Sicherheits- und Compliance-Framework Die AWS European Sovereign Cloud bietet dieselben zentralen Sicherheitsfunktionen, die Sie von AWS erwarten.Dazu gehören Verschlüsselung, Schlüsselverwaltung, Zugriffskontrolle und das AWS Nitro System für die Isolierung von Rechenressourcen.Dies bedeutet, dass Ihre EC2-Instanzen von einer kryptografisch verifizierten Plattformintegrität und hardwaregestützten Grenzen profitieren, die unbefugten Zugriff auf Ihre Daten verhindern, ohne die Leistung zu beeinträchtigen.So erhalten Sie sowohl die Souveränitätskontrollen als auch die Rechenleistung, die Ihre Workloads erfordern.Die Infrastruktur wird unabhängigen Audits durch Dritt e unterzogen.Die Compliance-Programme umfassen ISO/IEC 27001:2013, SOC-1/2/3-Berichte und das C5-Zertifikat des Bundesamtes für Sicherheit in der Informationstechnik (BSI) . Das AWS European Sovereign Cloud: Sovereign Reference Framework definiert spezifische Souveränitätskontrollen in den Bereichen Governance-Unabhängigkeit, operative Kontrolle, Datenresidenz und technische Isolierung.Dieses Framework ist in AWS Artifact verfügbar und bietet durch SOC-2-Zertifizierung durchgängige Transparenz. Umfassende Serviceverfügbarkeit Von Beginn an steht Ihnen in der AWS European Sovereign Cloud eine breite Palette von AWS-Services zur Verfügung – darunter Amazon SageMaker und Amazon Bedrock für Workloads im Bereich Künstliche Intelligenz und Machine Learning (KI/ML).Für die Rechenleistung stehen Ihnen Amazon Elastic Compute Cloud (Amazon EC2) und AWS Lambda zur Verfügung.Die Container-Orchestrierung ist über den Amazon Elastic Kubernetes Service (Amazon EKS) und den Amazon Elastic Container Service (Amazon ECS) verfügbar.Zu den Datenbank-Services gehören Amazon Aurora , Amazon DynamoDB und Amazon Relational Database Service (Amazon RDS) .Die Speicheroptionen umfassen Amazon Simple Storage Service (Amazon S3) und Amazon Elastic Block Store (Amazon EBS) mit Vernetzung über Amazon Virtual Private Cloud (Amazon VPC) und Sicherheits-Services wie AWS Key Management Service (AWS KMS) und AWS Private Certificate Authority .Eine aktuelle Liste der Services finden Sie in der AWS-Funktionsmatrix , die kürzlich im AWS Builder Center veröffentlicht wurde. Die AWS European Sovereign Cloud wird von AWS-Partnern unterstützt , die es sich zur Aufgabe gemacht haben, Ihnen bei der Erfüllung Ihrer Souveränitätsanforderungen zur Seite zu stehen.Partner wie Adobe, Cisco, Cloudera, Dedalus, Esri, Genesys, GitLab, Mendix, Pega, SAP, SnowFlake, Trend Micro und Wiz stellen ihre Lösungen in der AWS European Sovereign Cloud zur Verfügung und bieten Ihnen die Tools und Services, die Sie in den Bereichen Sicherheit, Datenanalyse, Entwicklung von Anwendungen und branchenspezifische Workloads benötigen.Dank dieser umfassenden Unterstützung durch Partner können Sie eigenständige Lösungen, die AWS-Services mit bewährten Partnertechnologien kombinieren, entwickeln. Erhebliche Investitionen in die europäische Infrastruktur Hinter der AWS European Sovereign Cloud steht eine Investition in Höhe von 7,8&nbsp;Milliarden Euro in Infrastruktur, die Schaffung von Arbeitsplätzen und die Entwicklung von Kompetenzen.Diese Investition wird bis 2040 voraussichtlich 17,2&nbsp;Milliarden Euro zur europäischen Wirtschaftsleistung beitragen und jährlich rund 2&nbsp;800 Vollzeitstellen in lokalen Unternehmen sichern. Einige technische Details Die AWS European Sovereign Cloud steht allen Kunden zur Verfügung, unabhängig davon, wo sie sich befinden.Sie können mit dem Partitionsnamen aws-eusc und dem Regionsnamen eusc-de-east-1 auf die Infrastruktur zugreifen.Eine Partition ist eine Gruppe von AWS-Regionen.Jedes AWS-Konto ist auf eine Partition beschränkt. Die Infrastruktur unterstützt alle gängigen AWS-Zugriffsmethoden, einschließlich der AWS Management Console , AWS SDKs und der AWS Command Line Interface (AWS CLI) , sodass sie sich problemlos in Ihre bestehenden Workflows und Automatisierungsprozesse integrieren lässt.Nachdem Sie ein neues Root-Konto für die Partition der AWS European Sovereign Cloud erstellt haben, beginnen Sie mit der Erstellung neuer IAM-Identitäten und -Rollen, die speziell für diese Infrastruktur vorgesehen sind.Dadurch erhalten Sie die vollständige Kontrolle über die Zugriffsverwaltung innerhalb der europäischen souveränen Umgebung. Erste Schritte Die AWS European Sovereign Cloud bietet europäischen Organisationen erweiterte Souveränitätskontrollen und gewährleistet gleichzeitig den Zugriff auf die Innovationen und Funktionen von AWS.Sie können Services über Amazon Web Services EMEA SARL in Auftrag geben.Die Preise werden in Euro angegeben und die Abrechnung erfolgt in einer der acht Währungen, die wir derzeit unterstützen .Die Infrastruktur basiert auf der bekannten AWS-Architektur, dem AWS-Serviceportfolio und den AWS-APIs, wodurch die Entwicklung und Migration von Anwendungen vereinfacht wird. Der AWS European Sovereign Cloud Addendum enthält die zusätzlichen vertraglichen Verpflichtungen für die AWS European Sovereign Cloud. Für mich als Europäer symbolisiert dieser Launch das Engagement von AWS, den spezifischen Anforderungen unseres Kontinents gerecht zu werden und Cloud-Funktionen bereitzustellen, die Innovationen in allen Branchen vorantreiben.Ich lade Sie ein, mehr über die AWS European Sovereign Cloud zu erfahren und zu entdecken, wie sie Ihrer Organisation dabei helfen kann, ihre Souveränitätsanforderungen zu erfüllen.Lesen Sie die Übersicht über die AWS European Sovereign Cloud und erfahren Sie mehr über die Designziele und den Ansatz. Registrieren Sie sich für ein neues Konto und planen Sie noch heute die Bereitstellung Ihrer ersten Workload. – seb フランス語版 Ouverture de l’AWS European Souvereign Cloud En tant que citoyen européen, je mesure personnellement l’importance de la souveraineté numérique, en particulier pour nos organisations du secteur public et les industries fortement réglementées.Aujourd’hui, j’ai le plaisir d’annoncer que l’ AWS European Sovereign Cloud est désormais disponible pour l’ensemble de nos clients. Nous avions annoncé pour la première fois notre projet de construction de cette nouvelle infrastructure cloud indépendante en 2023 , et elle est aujourd’hui prête à répondre aux exigences de souveraineté les plus strictes des clients européens, avec un large ensemble de services AWS . Berlin, porte de Brandebourg au coucher du soleil Répondre aux exigences européennes en matière de souveraineté Partout en Europe, les organisations sont confrontées à des exigences réglementaires de plus en plus complexes en matière de résidence des données, de contrôle opérationnel et d’indépendance de la gouvernance.Trop souvent aujourd’hui, les organisations européennes ayant les besoins de souveraineté les plus élevés se retrouvent contraintes de rester sur des environnements sur site, ou de recourir à des offres cloud aux services et fonctionnalités limités.Pour répondre à cet enjeu critique, l’AWS European Sovereign Cloud est le seul cloud souverain entièrement fonctionnel, exploité de manière indépendante, et reposant sur des contrôles techniques robustes, des garanties de souveraineté et des protections juridiques solides.Les acteurs du secteur public et les entreprises des secteurs fortement réglementés ont besoin d’une infrastructure cloud offrant des contrôles de souveraineté renforcés, sans renoncer à l’innovation, à la sécurité et à la fiabilité attendues des services cloud modernes.Ces organisations doivent avoir l’assurance que leurs données et leurs opérations restent sous juridiction européenne, avec des structures de gouvernance claires et une autonomie opérationnelle au sein de l’Union européenne (UE). Une nouvelle infrastructure cloud indépendante pour l’Europe L’AWS European Sovereign Cloud repose sur une infrastructure cloud physiquement et logiquement distincte, dont l’ensemble des composants est situé exclusivement au sein de l’UE.La première région AWS de l’AWS European Sovereign Cloud est implantée dans le Land de Brandebourg, en Allemagne, et est disponible dès aujourd’hui.Cette région fonctionne de façon indépendante par rapport aux autres régions AWS existantes.L’infrastructure comprend plusieurs zones de disponibilité, avec des systèmes redondants d’alimentation et de réseau, conçus pour fonctionner en continu même en cas d’interruption de la connectivité avec le reste du monde. Nous prévoyons d’étendre l’empreinte de l’AWS European Sovereign Cloud depuis l’Allemagne à l’ensemble de l’UE, afin de répondre aux exigences strictes d’isolation, de résidence des données dans certains pays et de faible latence.Cette extension débutera avec de nouvelles Local Zones souveraines situées en Belgique, aux Pays-Bas et au Portugal.En complément, vous pourrez étendre l’infrastructure de l’AWS European Sovereign Cloud à l’aide des AWS Dedicated Local Zones , des AWS AI Factories ou d’ AWS Outposts , dans les sites de votre choix, y compris au sein de vos propres centres de données sur site. L’AWS European Sovereign Cloud et ses Local Zones offrent des contrôles de souveraineté renforcés grâce à un modèle opérationnel unique.L’AWS European Sovereign Cloud est exploité exclusivement par des résidents de l’UE basés dans l’UE.Cela couvre notamment les opérations quotidiennes, le support technique et le service client.Nous sommes en train d’opérer une transition progressive afin que l’AWS European Sovereign Cloud soit exploité exclusivement par des citoyens de l’UE résidant dans l’UE .Durant cette période de transition, nous continuons de travailler avec une équipe mixte composée de résidents de l’UE et de citoyens de l’UE basés dans l’UE. L’infrastructure est gérée par des entités juridiques européennes dédiées, établies conformément au droit allemand.En octobre 2025, AWS a nommé Stéphane Israël , citoyen de l’UE résidant dans l’UE, au poste de directeur général.Stéphane est responsable de la gestion et de l’exploitation de l’AWS European Sovereign Cloud, couvrant l’infrastructure, la technologie et les services, ainsi que de la direction des initiatives plus larges d’AWS en matière de souveraineté numérique.En janvier 2026, AWS a également nommé Stefan Hoechbauer (Vice-président, Allemagne et Europe centrale, AWS) comme directeur général de l’AWS European Sovereign Cloud.Il travaillera aux côtés de Stéphane Israël pour piloter l’AWS European Sovereign Cloud. Un conseil consultatif, composé exclusivement de citoyens de l’UE et incluant deux représentants indépendants, apporte un niveau supplémentaire de supervision et d’expertise sur les questions de souveraineté. Résidence des données et contrôle renforcés L’AWS European Sovereign Cloud fournit des garanties complètes en matière de résidence des données afin de répondre aux exigences les plus strictes.Comme dans les régions AWS existantes à travers le monde, l’ensemble de vos contenus reste dans la région que vous sélectionnez, sauf indication contraire de votre part.Au-delà des contenus, les métadonnées créées par les clients — telles que les rôles, les autorisations, les étiquettes de ressources et les configurations — restent également au sein de l’UE.L’infrastructure dispose de son propre système dédié de AWS Identity and Access Management (IAM) et de facturation, opérant de manière totalement indépendante à l’intérieur des frontières européennes. Des contrôles techniques intégrés à l’infrastructure empêchent tout accès à l’AWS European Sovereign Cloud depuis l’extérieur de l’UE .L’infrastructure comprend un prestataire européen de services de confiance dédié pour les opérations d’autorité de certification et utilise des serveurs de noms Amazon Route 53 dédiés.Ces serveurs n’utilisent que des domaines de premier niveau (TLD) européens pour leurs propres noms .L’AWS European Sovereign Cloud ne présente aucune dépendance critique vis-à-vis de personnels ou d’infrastructures situés en dehors de l’UE. Cadre de sécurité et de conformité L’AWS European Sovereign Cloud conserve les capacités de sécurité fondamentales attendues d’AWS, notamment le chiffrement, la gestion des clés, la gouvernance des accès et le système AWS Nitro pour l’isolation des charges de calcul.Concrètement, vos instances EC2 bénéficient d’une intégrité de plateforme vérifiée cryptographiquement et de frontières matérielles, empêchant tout accès non autorisé à vos données sans compromis sur les performances.Vous bénéficiez ainsi à la fois des contrôles de souveraineté et de la puissance de calcul nécessaires à vos charges de travail.L’infrastructure fait l’objet d’audits indépendants réalisés par des tiers , et s’inscrit dans des programmes de conformité incluant ISO/IEC 27001:2013, les rapports SOC 1/2/3, ainsi que l’attestation C5 de l’ Office fédéral allemand pour la sécurité de l’information (BSI) . Le AWS European Sovereign Cloud: Sovereign Reference Framework définit précisément les contrôles de souveraineté couvrant l’indépendance de la gouvernance, le contrôle opérationnel, la résidence des données et l’isolation technique.Ce cadre est disponible dans AWS Artifact et offre une visibilité de bout en bout via une attestation SOC 2. Disponibilité étendue des services Dès son lancement, l’AWS European Sovereign Cloud donne accès à un large éventail de services AWS, notamment Amazon SageMaker et Amazon Bedrock pour les charges de travail d’intelligence artificielle et de machine learning (IA/ML).Pour le calcul, vous pouvez utiliser Amazon Elastic Compute Cloud (Amazon EC2) et AWS Lambda .L’orchestration de conteneurs est disponible via Amazon Elastic Kubernetes Service (Amazon EKS) et Amazon Elastic Container Service (Amazon ECS) .Les services de bases de données incluent Amazon Aurora , Amazon DynamoDB et Amazon Relational Database Service (Amazon RDS) .Les options de stockage comprennent Amazon Simple Storage Service (Amazon S3) et Amazon Elastic Block Store (Amazon EBS) , avec des capacités réseau via Amazon Virtual Private Cloud (Amazon VPC) et des services de sécurité tels que AWS Key Management Service (AWS KMS) et AWS Private Certificate Authority .Pour obtenir la liste la plus à jour des services disponibles, consultez la matrice des capacités AWS récemment publiée sur l’AWS Builder Center. L’AWS European Sovereign Cloud est supporté par de nombreux partenaires AWS engagés à vous aider à répondre à vos exigences de souveraineté.Des partenaires tels qu’Adobe, Cisco, Cloudera, Dedalus, Esri, Genesys, GitLab, Mendix, Pega, SAP, SnowFlake, Trend Micro et Wiz rendent leurs solutions disponibles sur l’AWS European Sovereign Cloud, vous offrant ainsi les outils et services nécessaires dans les domaines de la sécurité, de l’analyse de données, du développement applicatif et des charges de travail spécifiques à certains secteurs industriels.Cet ensemble de partenaires vous permet de construire des solutions souveraines combinant les services AWS et des technologies de partenaires de confiance. Un investissement majeur dans l’infrastructure européenne L’AWS European Sovereign Cloud s’appuie sur un investissement de 7,8 milliards d’euros dans l’infrastructure, la création d’emplois et le développement des compétences.Cet investissement devrait contribuer à hauteur de 17,2 milliards d’euros à l’économie européenne d’ici 2040 et soutenir environ 2.800 emplois équivalent temps plein par an au sein des entreprises locales. Quelques détails techniques L’AWS European Sovereign Cloud est accessible à tous les clients, quel que soit leur lieu d’implantation.Vous pouvez accéder à l’infrastructure en utilisant le nom de partition aws-eusc et le nom de région eusc-de-east-1 .Une partition correspond à un ensemble de régions AWS.Chaque compte AWS est rattaché à une seule partition. L’infrastructure prend en charge toutes les méthodes d’accès AWS standards, y compris la console de gestion AWS , les AWS SDKs et la AWS Command Line Interface (AWS CLI) , ce qui facilite son intégration dans vos flux de travail et vos automatisations existants.Après avoir créé un nouveau compte racine pour la partition AWS European Sovereign Cloud, vous commencez par définir de nouvelles identités et rôles IAM spécifiques à cette infrastructure, vous donnant un contrôle total sur la gestion des accès au sein de l’environnement souverain européen. Pour commencer L’AWS European Sovereign Cloud offre aux organisations européennes des contrôles de souveraineté renforcés tout en leur permettant de continuer à bénéficier de l’innovation et des capacités d’AWS.Vous pouvez contractualiser les services via Amazon Web Services EMEA SARL, avec une tarification en euros et une facturation possible dans l’une des huit devises que nous prenons en charge aujourd’hui .L’infrastructure repose sur une architecture, un portefeuille de services et des API AWS familiers, ce qui simplifie le développement et la migration des applications. L’ avenant AWS European Sovereign Cloud précise les engagements contractuels supplémentaires propres à l’AWS European Sovereign Cloud. En tant qu’Européen, ce lancement illustre l’engagement d’AWS à répondre aux besoins spécifiques de notre continent et à fournir les capacités cloud qui stimulent l’innovation dans tous les secteurs.Je vous invite à découvrir l’AWS European Sovereign Cloud et à comprendre comment il peut aider votre organisation à satisfaire ses exigences de souveraineté.Consultez Overview of the AWS European Sovereign Cloud (en anglais) pour en savoir plus sur les objectifs de conception et l’approche retenue, créez un nouveau compte et planifiez dès aujourd’hui le déploiement de votre première charge de travail. – seb イタリア語版 Lancio di AWS European Sovereign Cloud Come cittadino europeo, conosco benissimo l’importanza della sovranità digitale, in particolare per le nostre organizzazioni del settore pubblico e dei settori altamente regolamentati.Oggi sono lieto di annunciare che AWS European Sovereign Cloud è ora generalmente disponibile per tutti i clienti. Abbiamo annunciato per la prima volta i nostri piani per la creazione di questa nuova infrastruttura cloud indipendente nel 2023. Finalmente oggi è pronta a soddisfare i più rigorosi requisiti di sovranità dei clienti europei con un set completo di servizi AWS . Berlino, Porta di Brandeburgo al tramonto Soddisfare i requisiti di sovranità europea Le organizzazioni di tutta Europa devono far fronte a requisiti normativi sempre più complessi in materia di residenza dei dati, controllo operativo e indipendenza della governance.Troppo spesso, le organizzazioni europee con i più elevati requisiti di sovranità sono bloccate a causa di offerte o ambienti on-premises legacy con funzionalità e servizi ridotti.In risposta a questa esigenza fondamentale, l’AWS European Sovereign Cloud rappresenta l’unico cloud sovrano con funzionalità complete e a gestione autonoma. supportato da solidi controlli tecnici, garanzie di sovranità e protezioni legali.Gli enti pubblici e le aziende di settori altamente regolamentati necessitano di un’infrastruttura cloud che fornisca controlli di sovranità avanzati che garantiscano l’innovazione, la sicurezza e l’affidabilità che si aspettano dai moderni servizi cloud.Queste organizzazioni devono essere certe che i propri dati e le proprie operazioni restino sotto la giurisdizione europea, con chiare strutture di governance e autonomia operativa nell’ambito dell’Unione europea (UE). Una nuova infrastruttura cloud indipendente per l’Europa L’AWS European Sovereign Cloud rappresenta un’infrastruttura cloud separata fisicamente e logicamente, con tutti i componenti situati interamente all’interno dell’UE.La prima Regione AWS nell’AWS European Sovereign Cloud, situata nello stato di Brandeburgo (Germania) e ora disponibile a livello generale, opera indipendentemente dalle Regioni AWS esistenti.L’infrastruttura presenta diverse zone di disponibilità con risorse di alimentazione e rete ridondanti, progettate per funzionare continuamente anche in caso di interruzione della connettività con il resto del mondo. Abbiamo intenzione di estendere la presenza dell’AWS European Sovereign Cloud dalla Germania all’intera UE per supportare i rigorosi requisiti di isolamento, residenza dei dati all’interno di un determinato Paese e bassa latenza.Inizieremo con nuove zone locali sovrane situate in Belgio, nei Paesi Bassi e in Portogallo.Inoltre, sarà possibile estendere l’infrastruttura AWS European Sovereign Cloud con Zone locali AWS dedicate , AWS AI Factories o AWS Outposts in posizioni selezionate, inclusi i data center on-premises. L’AWS European Sovereign Cloud e le relative zone locali forniscono controlli sovrani avanzati tramite un modello operativo esclusivo.L’AWS European Sovereign Cloud sarà gestito esclusivamente da residenti UE che si trovano nell’UE.Ciò copre attività come operazioni quotidiane, supporto tecnico e servizio clienti.Stiamo gradualmente trasformando l’AWS European Sovereign Cloud in modo che sia gestito esclusivamente da cittadini UE che si trovano nell’UE .Durante questo periodo di transizione, continueremo a lavorare con un team misto di residenti e cittadini comunitari che si trovano nell’UE. L’infrastruttura è gestita da entità giuridiche europee dedicate, costituite secondo il diritto tedesco.Nell’ottobre 2025, AWS ha assegnato l’incarico di managing director a Stéphane Israël , cittadino comunitario residente nell’UE.Sarà responsabile della gestione e delle operazioni dell’AWS European Sovereign Cloud, inclusi infrastruttura, tecnologia e servizi, oltre a guidare le più ampie iniziative di sovranità digitale di AWS.Nel gennaio 2026, AWS ha inoltre nominato managing director dell’AWS European Sovereign Cloud Stefan Höchbauer (vicepresidente, Germania ed Europa centrale, AWS).Collaborerà con Stéphane Israël per guidare l’AWS European Sovereign Cloud. Un comitato consultivo composto esclusivamente da cittadini comunitari, inclusi due rappresentanti terzi indipendenti, fornirà ulteriore supervisione e competenza in materia di sovranità. Ottimizzazione del controllo e della residenza dei dati L’AWS European Sovereign Cloud offre garanzie complete sulla residenza dei dati in modo da poter soddisfare i requisiti più rigorosi in materia.Come per le nostre Regioni AWS esistenti a livello mondiale, tutti i contenuti restano all’interno della Regione selezionata, a meno che non si scelga diversamente.Oltre ai contenuti, anche i metadati creati dai clienti, tra cui ruoli, autorizzazioni, etichette delle risorse e configurazioni, restano nell’ambito dell’UE.L’infrastruttura è dotata di un proprio sistema AWS Identity and Access Management (AWS IAM) e di fatturazione dedicato, completamente gestito in modo indipendente all’interno dei confini europei. I controlli tecnici integrati nell’infrastruttura impediscono l’accesso all’AWS European Sovereign Cloud dall’esterno dell’UE .L’infrastruttura include un provider di servizi fiduciari europeo dedicato per le operazioni delle autorità di certificazione e utilizza nameserver Amazon Route 53 dedicati.Questi server utilizzeranno solo domini di primo livello (TLD) europei per i propri nomi .L’AWS European Sovereign Cloud non ha dipendenze fondamentali da personale o infrastrutture non UE. Framework di sicurezza e conformità L’AWS European Sovereign Cloud mantiene le stesse funzionalità di sicurezza di base di AWS, tra cui crittografia, gestione delle chiavi, governance degli accessi e AWS Nitro System per l’isolamento computazionale.Ciò significa che le istanze EC2 beneficiano dell’integrità della piattaforma verificata a livello di crittografia e dei limiti imposti dall’hardware che impediscono l’accesso non autorizzato ai dati senza compromettere le prestazioni, offrendo i controlli di sovranità e la potenza di calcolo richiesti dai carichi di lavoro.L’infrastruttura è sottoposta ad audit di terze parti indipendenti , con programmi di conformità che includono ISO/IEC 27001:2013, report SOC 1/2/3 e attestazione C5 dell’ Ufficio Federale per la Sicurezza Informatica (BSI) . L’ AWS European Sovereign Cloud: Sovereign Reference Framework definisce i controlli di sovranità specifici in termini di indipendenza della governance, controllo operativo, residenza dei dati e isolamento tecnico.Questo framework è disponibile in AWS Artifact e fornisce visibilità end-to-end tramite l’attestazione SOC 2. Disponibilità completa del servizio Dal momento del lancio, sarà possibile accedere a un’ampia gamma di servizi AWS nell’AWS European Sovereign Cloud, tra cui Amazon SageMaker e Amazon Bedrock per carichi di lavoro di intelligenza artificiale e machine learning (IA/ML).Per i calcoli, è possibile utilizzare Amazon Elastic Compute Cloud (Amazon EC2) e AWS Lambda .L’orchestrazione di container è disponibile tramite Amazon Elastic Kubernetes Service (Amazon EKS) e Amazon Elastic Container Service (Amazon ECS) .I servizi di database includono Amazon Aurora , Amazon DynamoDB e Amazon Relational Database Service (Amazon RDS) .Le opzioni di storage includono Amazon Simple Storage Service (Amazon S3) e Amazon Elastic Block Store (Amazon EBS) , con connessione in rete tramite Amazon Virtual Private Cloud (Amazon VPC) e servizi di sicurezza tra cui Servizio AWS di gestione delle chiavi (AWS KMS) e Autorità di certificazione privata AWS (AWS Private CA) .Per un elenco aggiornato dei servizi, è possibile consultare l’ elenco delle funzionalità AWS pubblicato di recente su AWS Builder Center. L’AWS European Sovereign Cloud è supportato dai partner AWS , che aiutano a soddisfare i propri requisiti di sovranità.Partner come Adobe, Cisco, Cloudera, Dedalus, Esri, Genesys, GitLab, Mendix, Pega, SAP, SnowFlake, Trend Micro e Wiz stanno rendendo disponibili le loro soluzioni nell’AWS European Sovereign Cloud, fornendo gli strumenti e i servizi necessari per la sicurezza, l’analisi dei dati, lo sviluppo di applicazioni e i carichi di lavoro specifici del settore.Questo ampio supporto dei partner aiuta a creare soluzioni sovrane che combinano i servizi AWS con tecnologie di partner affidabili. Investimenti significativi nelle infrastrutture europee L’AWS European Sovereign Cloud è sostenuto da un investimento di 7,8 miliardi di euro destinati a infrastrutture, creazione di posti di lavoro e sviluppo delle competenze.Si prevede che questo investimento contribuirà con 17,2 miliardi di euro all’economia europea fino al 2040 e sosterrà circa 2.800 posti di lavoro equivalenti a tempo pieno all’anno nelle aziende locali. Alcuni dettagli tecnici L’AWS European Sovereign Cloud è disponibile per tutti i clienti, indipendentemente da dove si trovino.È possibile accedere all’infrastruttura utilizzando il nome della partizione aws-eusc e il nome della Regione eusc-de-east-1.Una partizione è un gruppo di Regioni AWS.Ogni account AWS è associato a una partizione. L’infrastruttura supporta tutti i metodi di accesso AWS standard, tra cui la Console di gestione AWS , gli SDK AWS e l’ interfaccia della linea di comando AWS (AWS CLI) , semplificando l’integrazione nell’automazione e nei flussi di lavoro esistenti.Dopo aver creato un nuovo account root per la partizione Di AWS European Sovereign Cloud, si inizia creando nuove identità e ruoli IAM specifici per questa infrastruttura, che consentiranno di avere il controllo completo sulla gestione degli accessi all’interno dell’ambiente sovrano europeo. Nozioni di base L’AWS European Sovereign Cloud fornisce alle organizzazioni europee controlli di sovranità avanzati pur mantenendo l’accesso all’innovazione e alle funzionalità di AWS.È possibile contrattare servizi tramite Amazon Web Services EMEA SARL, con prezzi in EUR e fatturazione in una delle otto valute supportate oggi .L’infrastruttura utilizza l’architettura AWS, il portafoglio di servizi e le API tradizionali, semplificando la creazione e la migrazione delle applicazioni. L’ addendum di AWS European Sovereign Cloud include gli impegni contrattuali aggiuntivi per l’AWS European Sovereign Cloud. Per me come europeo, questo lancio rappresenta l’impegno di AWS per soddisfare le esigenze specifiche del nostro continente e fornire le funzionalità cloud che guidano l’innovazione in tutti i settori.Invito tutti a scoprire di più sull’AWS European Sovereign Cloud e su come può aiutare le organizzazioni a soddisfare i requisiti di sovranità.Nella Panoramica di AWS European Sovereign Cloud sono disponibili maggiori informazioni sugli obiettivi e sull’approccio di progettazione, creare un nuovo account &nbsp;e pianificare l’implementazione del primo carico di lavoro oggi stesso. – seb スペイン語版 Apertura de AWS&nbsp;European Sovereign Cloud Como ciudadano europeo, comprendo de primera mano la importancia de la soberanía digital, especialmente para las organizaciones de nuestro sector público y las industrias altamente reguladas.Hoy me complace anunciar que la AWS European Sovereign Cloud ya está disponible de forma generalizada para todos los clientes. Anunciamos por primera vez nuestros planes de crear esta nueva infraestructura de nube independiente en 2023 , y hoy está lista para cumplir los requisitos de soberanía más estrictos de los clientes europeos con un exhaustivo conjunto de servicios de AWS . Berlín, Puerta de Brandeburgo al atardecer Cumplimiento de los requisitos de soberanía europeos Las organizaciones de toda Europa se enfrentan a unos requisitos normativos cada vez más complejos en relación con la residencia de los datos, el control operativo y la independencia de la gobernanza.Hoy en día, con demasiada frecuencia, las organizaciones europeas con los requisitos de soberanía más estrictos se ven atrapadas en entornos locales heredados u ofertas con servicios y funcionalidades reducidos.En respuesta a esta necesidad crítica, la AWS European Sovereign Cloud es la única nube soberana independiente con todas las características que está respaldada por sólidos controles técnicos, garantías de soberanía y protecciones legales.Las entidades del sector público y las empresas de industrias altamente reguladas necesitan una infraestructura en la nube que proporcione controles de soberanía mejorados que mantengan la innovación, la seguridad y la fiabilidad que se esperan de los servicios modernos en la nube.Estas organizaciones necesitan la garantía de que sus datos y operaciones permanecen bajo la jurisdicción europea, con estructuras de gobernanza claras y autonomía operativa dentro de la Unión Europea (UE). Una nueva infraestructura de nube independiente para Europa La AWS European Sovereign Cloud es una infraestructura de nube separada de manera física y lógica, en la que todos los componentes están ubicados íntegramente dentro de la UE.La primera región de AWS de la AWS European Sovereign Cloud se encuentra en el estado de Brandeburgo (Alemania) y ya está disponible para el público en general.Esta región opera de forma independiente de las regiones de AWS existentes.La infraestructura cuenta con varias zonas de disponibilidad con fuentes de alimenacion y redes redundantes, diseñadas para funcionar de forma continua incluso si se interrumpe la conectividad con el resto del mundo. Tenemos previsto ampliar la presencia de la AWS European Sovereign Cloud de Alemania a toda la UE para cumplir los requisitos de aismlamiento estrictos, residencia de los datos dentro del país y baja latencia.Esto comenzará con nuevas zonas locales soberanas ubicadas en Bélgica, los Países Bajos y Portugal.Además, podrá ampliar la infraestructura de la AWS European Sovereign Cloud con zonas locales dedicadas de AWS , AWS AI Factories o AWS Outposts en las ubicaciones que elija, incluidos sus propios centros de datos locales. La AWS European Sovereign Cloud y sus zonas locales proporcionan controles soberanos mejorados a través de su modelo operativo único.La AWS European Sovereign Cloud será operada exclusivamente por residentes de la UE ubicados en la UE.Abarca actividades como las operaciones diarias, la asistencia técnica y el servicio de atención al cliente.Estamos realizando una transición gradual de la AWS European Sovereign Cloud para que se opere exclusivamente por ciudadanos de la UE ubicados en la UE .Durante este período de transición, seguiremos trabajando con un equipo mixto de residentes de la UE y ciudadanos de la UE ubicados en la UE. La infraestructura se administra a través de entidades jurídicas europeas especializadas constituidas en el marco de la legislación alemana.En octubre de 2025, AWS nombró director general a Stéphane Israël , ciudadano de la UE que reside en la UE.Stéphane será responsable de la administración y las operaciones de la AWS European Sovereign Cloud, lo que incluye la infraestructura, la tecnología y los servicios, además de liderar los esfuerzos más amplios de AWS en materia de soberanía digital.En enero de 2026, AWS también nombró a Stefan Hoechbauer (vicepresidente de AWS para Alemania y Europa Central) director general de la AWS European Sovereign Cloud.Stefan dirigirá la AWS European Sovereign Cloud junto con Stéphane Israël. Un consejo consultivo compuesto exclusivamente por ciudadanos de la UE, que incluye a dos representantes independientes externos, proporciona supervisión y experiencia adicional en materia de soberanía. Mejor control y residencia de datos La AWS European Sovereign Cloud ofrece amplias garantías de residencia de datos para que pueda cumplir los requisitos más estrictos en materia de residencia de datos.Al igual que ocurre con nuestras regiones de AWS existentes en todo el mundo, todo el contenido permanece dentro la región que elija, a menos que decida lo contrario.Además del contenido, los metadatos creados por los clientes, incluidos los roles, los permisos, las etiquetas de recursos y las configuraciones, también permanecen dentro de la UE.La infraestructura cuenta con su propio sistema dedicado de AWS Identity and Access Management (AWS IAM) y facturación, que funciona de forma independiente dentro de las fronteras europeas. Los controles técnicos integrados en la infraestructura impiden el acceso a la AWS European Sovereign Cloud desde fuera de la UE .La infraestructura incluye un proveedor de servicios de confianza europeo dedicado para las operaciones de las autoridades de certificación y utiliza servidores de nombres de Amazon Route 53 dedicados.Estos servidores solo usarán dominios de nivel superior europeos para sus propios nombres .La AWS European Sovereign Cloud no tiene dependencias críticas de personal o infraestructura fuera de la UE. Marco de seguridad y cumplimiento La AWS European Sovereign Cloud mantiene las mismas capacidades de seguridad básicas que cabe esperar de AWS, como el cifrado, la administración de claves, la gobernanza del acceso y AWS Nitro System para el aislamiento de la computación.Esto significa que sus instancias de EC2 se benefician de la integridad de la plataforma verificada criptográficamente y de los límites impuestos por el hardware que impiden el acceso no autorizado a sus datos sin comprometer el rendimiento, lo que le proporciona tanto los controles de soberanía como la potencia computacional que requieren sus cargas de trabajo.La infraestructura se somete a auditorías independientes externas , con programas de cumplimiento que incluyen la norma ISO/IEC 27001:2013, informes SOC 1/2/3 y la certificación C5 de la Oficina Federal de Seguridad de la Información . El marco de referencia de soberanía de la AWS European Sovereign Cloud define los controles de soberanía específicos en relación con la independencia de la gobernanza, el control operativo, la residencia de datos y el aislamiento técnico.Este marco está disponible en AWS Artifact y proporciona visibilidad total a través de la certificación SOC 2. Disponibilidad total del servicio Puede acceder a una amplia variedad de servicios de AWS en la AWS European Sovereign Cloud desde su lanzamiento, incluidos Amazon SageMaker y Amazon Bedrock para cargas de trabajo de inteligencia artificial y machine learning.Para el procesamiento, puede usar Amazon Elastic Compute Cloud (Amazon EC2) y AWS Lambda .La orquestación de contenedores está disponible a través de Amazon Elastic Kubernetes Service (Amazon EKS) y Amazon Elastic Container Service (Amazon ECS) .Los servicios de bases de datos incluyen Amazon Aurora , Amazon DynamoDB y Amazon Relational Database Service (Amazon RDS) .Dispone de opciones de almacenamiento como Amazon Simple Storage Service (Amazon S3) y Amazon Elastic Block Store (Amazon EBS) , con redes a través de Amazon Virtual Private Cloud (Amazon VPC) y servicios de seguridad como AWS Key Management Service (AWS KMS) y AWS Private Certificate Authority .Para obtener una lista actualizada de los servicios, consulte la matriz de capacidades de AWS que se ha publicado recientemente en AWS Builder Center. La AWS European Sovereign Cloud cuenta con el respaldo de los socios de AWS , que se comprometen a ayudarle a cumplir sus requisitos de soberanía.Socios como Adobe, Cisco, Cloudera, Dedalus, Esri, Genesys, GitLab, Mendix, Pega, SAP, SnowFlake, Trend Micro y Wiz ofrecen sus soluciones en la AWS European Sovereign Cloud, lo que le proporciona las herramientas y los servicios que necesita en materia de seguridad, análisis de datos, desarrollo de aplicaciones y cargas de trabajo específicas del sector.Este amplio apoyo de los socios le ayuda a crear soluciones soberanas que combinan los servicios de AWS con tecnologías de socios de confianza. Inversión importante. en la infraestructura europea La AWS European Sovereign Cloud está respaldada por una inversión de 7.800 millones de EUR en infraestructura, creación de empleo y desarrollo de habilidades.Se espera que esta inversión aporte 17.200 millones de EUR a la economía europea para 2040 y ayude a crear el equivalente a aproximadamente 2.800 puestos de trabajo a tiempo completo por año en empresas locales. Algunos detalles técnicos La AWS European Sovereign Cloud está disponible para todos los clientes, independientemente de dónde se encuentren.Puede acceder a la infraestructura utilizando el nombre de partición aws-eusc y el nombre de región eusc-de-east-1.Una partición es un grupo de regiones de AWS.Cada cuenta de AWS tiene limitado su alcance a una sola partición. La infraestructura admite todos los métodos de acceso estándar de AWS, como la Consola de administración de AWS , los AWS SDK y la Interfaz de la línea de comandos de AWS (AWS CLI) , lo que facilita la integración en sus flujos de trabajo y automatización existentes.Tras crear una nueva cuenta raíz para la partición de la AWS European Sovereign Cloud, primero deberá crear nuevas identidades y roles de IAM específicos para esta infraestructura, lo que le permitirá tener un control total sobre la administración del acceso en el entorno soberano europeo. Cómo empezar La AWS European Sovereign Cloud proporciona a las organizaciones europeas controles de soberanía mejorados, al tiempo que mantiene el acceso a la innovación y las capacidades de AWS.Puede contratar los servicios a través de Amazon Web Services EMEA SARL, con precios en EUR y facturación en cualquiera de las ocho divisas que admitimos actualmente .La infraestructura utiliza la arquitectura, la cartera de servicios y las API habituales de AWS, lo que facilita la creación y la migración de aplicaciones. La adenda de la AWS European Sovereign Cloud contiene los compromisos contractuales adicionales para la AWS European Sovereign Cloud. Para mí, como europeo, este lanzamiento representa el compromiso de AWS de satisfacer las necesidades específicas de nuestro continente y proporcionar las capacidades en la nube que impulsan la innovación en todos los sectores.Le invito a descubrir más sobre la AWS European Sovereign Cloud y cómo puede ayudar a su organización a cumplir sus requisitos de soberanía.Lea la descripción general de la AWS European Sovereign Cloud para obtener más información sobre los objetivos y el enfoque del diseño, regístrese para obtener una nueva cuenta y planifique hoy mismo el despliegue de su primera carga de trabajo. – seb

エージェントが IDE のエラーを見逃す理由 初期のコーディングエージェントには大きな問題がありました。AI が生成したコードは一見正しく見えても、IDE が検出したエラーがエージェントには見えないのです。エージェントは追加のツールを実行しない限り、これらのエラーを認識できませんでした。その結果、エージェントは自信を持って次のタスクに進む一方で、コードベースには技術的負債が蓄積されていきました。 これは、診断情報を活用していないコーディングエージェントに共通する根本的な課題です。 現代の IDE のほとんどは、リアルタイムでエラーを検出する高度な言語解析ツールを継続的に実行しています。しかし、エージェントがこの豊富な情報に効率的にアクセスできなければ、コード検証のために（コストのかかる）ビルド/テストコマンドを実行せざるを得ません。これは実行速度が遅く、トークンを消費し、開発環境がすでに提供している詳細なフィードバックを見逃してしまいます。結果として、必要以上にリソースを消費するコード検証プロセスになってしまうのです。 診断情報なしでコードを生成するコスト エージェントが IDE の診断情報を参照できない場合、品質向上のための反復改善ができません。代わりに、正しいと思われるコードを生成して次のタスクに進んでしまいます。その結果、開発者がエージェントの品質保証を担うことになります。型エラーの手動修正（例：実際のプロパティは user.name なのに user.getName() を呼び出している）、不足しているインポートの追加（ Button を使用しているのに import { Button } from '@/components/ui/button' を忘れている）、リンティング違反の解決（未使用の変数、一貫性のないインデント）などです。これは開発速度を低下させるだけでなく、エージェントが生成したコードへの信頼を損なう結果にもつながります。 Kiro におけるフィードバックループの完結 現代の IDE は、高度な言語解析インフラストラクチャで動作しています。言語サーバーがコードベースをリアルタイムで解析します。例えば、TypeScript 拡張機能は型チェックを実行し、ESLint はコードスタイルを検証し、Java 拡張機能は即座にコンパイルフィードバックを提供します。また、CloudFormation や Terraform の拡張機能は、デプロイ前にリソースプロパティ、必須引数、リソース参照などのインフラストラクチャ設定を検証します。 この解析はコーディング中に継続的に実行され、エラーを 診断情報 として表示します。エディタで見る赤い波線や問題マーカーがそれです。これらの診断情報は、コードの正確性に関する即座で正確なフィードバックの貴重な情報源となっています。 しかし、初期の AI コーディングアシスタントは、この情報にアクセスできませんでした。代わりに、ビルドコマンド（ npm run build 、 npm test など）を実行してコードを検証していましたが、1 回の実行に数秒から数分かかることもありました。 仕様駆動開発を通じて AI コーディングに構造をもたらすエージェント型 IDE である Kiro では、エージェントに IDE 診断情報への直接アクセスを提供することで、この課題を解決しました。現在、Kiro がコードを書くと、開発者が見るのと同じエラーを即座に確認し、レビュー前に修正できます。コード品質への影響は顕著で、手動修正が減り、プロジェクトの品質基準への準拠が向上しました。Kiro のコーディングエージェントは、これらのクライアント側の診断情報と緊密に統合され、コードの理解と生成の両方を強化します。IDE を動かすのと同じ言語サーバーへの接続を通じて、エージェントはコンパイル時エラー、型警告、リンティング結果をリアルタイムで読み取り、解釈できるようになりました。Kiro がコードを生成または変更すると、この診断情報を参照して正確性を検証します。例えば、Java の不足しているシンボルや Python の構文エラーを検出し、そのフィードバックに基づいて出力を自動的に改善できます。 ワークフローの比較 従来のアプローチは、遅い反復サイクルを繰り返します。エージェントがコードを生成し、時間のかかるビルド（および/またはテスト）コマンドを実行します。ビルドがエラーで失敗すると、エージェントは修正を生成し、再度ビルドコマンドを実行します。この重いプロセスは、ビルドが成功するまで繰り返されます。 診断駆動型アプローチははるかに高速です。コード生成後、エージェントは 35 ミリ秒未満で診断情報をチェックします。行番号と説明を含む具体的なエラーが提供されます。エージェントはターゲットを絞った修正を生成し、さらに 35 ミリ秒で診断を介して検証してから、検証済みのコードで続行します。 時間差は、複数ステップのタスクで複合的に拡大します。仕様駆動開発では、Kiro が数十のタスクを実装する際、診断ツールは vibe-coding モードと比較して約 4 倍の頻度で呼び出されます。これは、各タスクの境界で受け入れ基準が満たされていることを確認する必要があるためです。これにより、実装プロセス全体を通じて継続的な検証が実現されます。 実際の効果 本番環境での使用と制御されたベンチマークを通じて、診断統合の効果を測定しました。結果は、測定可能なコード品質の向上とともに、大幅な効率改善を示しています。効率面では、ビルド/テストコマンドの削減により、コマンド実行が 29% 削減されました。この指標は、診断機能の導入前後の数日間にわたる本番環境でのエージェントのインタラクション統計を比較することで算出されました。エンドツーエンドのレイテンシを削減しながら、コード品質が向上しました。 言語に依存しないアーキテクチャ 診断システムの強みは、その汎用性にあります。各言語用にカスタム解析を構築するのではなく、Kiro は、すでに多数の IDE 機能を支えている Language Server Protocol（LSP）と拡張 API を活用しています。本番環境のデータは、これが多様な技術スタックで機能することを実証しています。例えば、TypeScript、Python、Rust などの汎用言語や、SQL、YAML、GraphQL などのドメイン固有言語の 人気のある拡張機能 は、型チェックとリンティング情報を提供します。さらに、主要なビルドツール（Maven、Make、Cargo など）やプログラマティック設定ファイル（Terraform、Kubernetes YAML、Dockerfile など）の拡張機能により、セットアップとデバッグの体験が向上します。 活用シナリオ 本番環境での使用分析により、診断ツールが既存または新規生成されたコードの品質を向上させる一般的なパターンが明らかになりました。 シナリオ 1 [構文エラー]： 分析用の Python コードベースで、エージェントがウィンドウ集計の新機能を実装します。 診断ツールは、正規表現エラー（ missing ), unterminated subpattern at position 13 ）を発見し、エージェントが修正します。再検証により、エラーが解消されたことが確認されます。診断ツールがない場合、エージェントはコマンドラインでテストを作成・実行して問題をチェックする必要があります。 シナリオ 2 [ハルシネーションの回避]： TypeScript コードベースで、Kiro がコンポーネントに変更を加え、即座に検証します。 診断ツールは、即座に 2 つの 型の不一致 （ Type 'number' is not assignable to type 'string' と Cannot assign to read-only 'executionTime' ）と プロパティのハルシネーション （ Property 'itemAge' does not exist on type 'StackProps' ）を報告します。これらの問題を基に、エージェントは修正を生成し、変更を再検証します。このパターン（生成 → 検証 → 改善）は、型エラーが一般的ですが言語サーバーで簡単に検出できる静的型付け言語で頻繁に見られます。 シナリオ 3 [型検証]： Swift プロジェクトで、Kiro が新しい機能を追加し、編集されたファイルの診断をチェックします。 診断により、ファイルの 1 つに 型エラー があることが判明します。エージェントは問題を修正し、影響を受けたファイルを再検証して、修正が正しいことを確認します。 シナリオ 4 [Infrastructure as Code — IaC]： 診断検証は、アプリケーションコードを超えて機能します。ユーザーが Kiro に Terraform 設定 のチェックを依頼します。 これは、診断システムが従来のプログラミング言語だけでなく、ドメイン固有言語や設定フォーマットでも機能することを示しています。 エージェント開発のメリット コード生成とコード検証を統合することで、診断ツールは次の改善を実現します： 認知負荷の軽減： AI が生成したコードを手動で検証する時間が減ります。Kiro が「診断エラーなし」と報告すると、開発者はより高い信頼性を持って作業を続行できます。 高速な反復： bash コマンドの実行頻度の削減は、具体的な時間の節約につながります。 コード品質の向上： 問題が発生した時点で即座に対処することで、よりクリーンで高品質なコードが実現します。 まとめ IDE 診断情報は、コード検証のための重要な即時フィードバックの源です。診断情報を Kiro のエージェントワークフローに直接統合することで、初期のコーディングエージェントが抱えていたコード生成と検証の間のギャップを解消しました。 結果は明確です。コマンド実行の削減、高速な検証サイクル、多様な技術スタックにわたるコード品質の向上を実現しました。エージェントに遅くてコストのかかるビルド/テストコマンドに依存させるのではなく、Kiro は、すでに現代の IDE を支えている高度な言語解析インフラストラクチャを活用します。TypeScript の型チェックから Terraform の設定検証まで幅広く対応しています。 この診断駆動型アプローチは、エージェントのフィードバックループを高速化します。盲目的にコードを生成して動作を期待するのではなく、Kiro は開発者が見るのと同じエラーを確認し、積極的に修正します。結果として、手動修正が少なく、開発者の信頼を得られるコードが実現します。 この違いを体験する準備はできましたか？ Kiro を無料で始めて 、診断機能を備えたエージェントが開発ワークフローをどのように変革するかを確認してください。 Discord のコミュニティに参加して、フィードバックを共有し、質問をし、AI 支援コーディングで開発している他の開発者とつながりましょう。 謝辞 クレジット（アルファベット順）：Al Harris、Nathan Jones、Nikhil Swaminathan、Siwei Cui、Varun Kumar

Kiro を最初にローンチしたとき、私たちは初期ユーザーの一部を困惑させる意図的な決断を下しました。「すべてのタスクを一括実行」ボタンを実装しなかったのです。各タスクの後に必ずエージェントと確認する必要がありました。これは見落としではありません。意図的な設計でした。 スピードとコントロールの間の緊張 「なぜ仕様のすべてのタスクを一度に実行できないのか？」は、6 か月前のローンチ後に最も多く寄せられた質問の 1 つでした。このリクエストは理にかなっていました。仕様には 5 個、10 個、時には 20 個以上のタスクが含まれることがよくあります。それぞれを個別にクリックするのは面倒に感じられました。エージェントは、できるだけ手を離せるようにするためのものではないのでしょうか？はい、でもいいえでもあります。 Kiro における私たちの基本的な考え方は、開発者が可視性とコントロールを維持することで AI 開発が最も効果的に機能するというものです。何が起こっているかを確認し、各タスクの実行を理解し、問題を早期に発見してほしかったのです。その対極にある選択肢、つまりコーヒーを取りに行っている間に AI がコードベース全体を自動実行するというのは、無謀に思えました。内部テストでは、エージェントが自律的にうまく機能するケースもありましたが、失敗するケースもあり、その場合ユーザーは問題の発生箇所を特定し、修正するために多くの時間を費やすことになりました。 そこで私たちはノーと言いました。そして、リクエストが積み重なってもノーと言い続けました。 まず基盤を構築する ユーザーの要望を急いで実装する代わりに、私たちは「すべて実行」を本当に 安全 にするための基盤構築に集中しました。過去数か月間、Kiro の信頼性を根本的に向上させる一連の機能を着実にリリースしてきました。 プロパティベーステスト（PBT） – 「このタスクは私が望むことをしているか？」 ：コードが実行されるだけでなく、仕様の要件を満たしていることを検証するプロパティベーステストを生成するようになりました。これらは単純なユニットテストではありません。コードがさまざまな入力にわたって正しく動作することを保証する不変条件チェックです。PBT により、エージェントは次に進む前に、タスクの実装が期待どおりに動作することを確認できます。 開発サーバー と LSP 診断 – 「実装は実際に機能するか？」 ：タスクが実行中のサーバーに対してテストされ、言語サーバー診断で分析される実際の検証環境です。コードは、ランタイムの動作と静的な正確性の両方について検証され、メインブランチに到達する前に問題をキャッチします。 サブエージェント – 「エージェントはコンテキストの腐敗に迷うことなく軌道に乗り続けるか？」 ：独自のローカルコンテキストを維持しながら、特定のタスクを処理する特殊なエージェントです。メインエージェントが仕様を進めるにつれて、サブエージェントはコンテキスト管理を分散して集中させることで、過負荷になるのを防ぎます。 これらの機能を組み合わせることで、Kiro はコードを 生成 するツールから、コードを 検証 するツールへと変貌しました。これにより、複数のタスクを実行することが単に高速であるだけでなく、安全であるという確信が得られました。 すべてのタスクを一括実行：ついに利用可能に 本日、皆さんが求めていたものを公開します。1 回のクリックで仕様のすべてのタスクを実行する機能です。この機能は、皆さんが求めていたものの精神に従っていますが、私たちの実装により、必要なだけ頻繁に使用できる自信が得られます。 「すべてのタスクを実行」を押すと、単にコードをより速く実行するだけではありません。検証の試練を通してコードを実行します。 各タスクの出力は、プロパティベーステスト（PBT）に対して検証されます コードは開発サーバーに対して検証され、LSP 診断でチェックされます サブエージェントは、集中したローカルコンテキストを維持するため、メインエージェントは仕様全体で効果的に機能し続けます 各ステップで何が起こっているかをリアルタイムで確認できます 結果は？慎重に監視された開発の信頼性を備えた自動実行のスピードが得られます。 これは、エージェントを手取り足取り導きたくない小規模な機能仕様に最適だと考えています。そして、いつものように、プロンプトに基づいて Kiro が考え出した仕様を事前に少し時間をかけて検証することで、実際に必要なコードをより速く全体的に公開できるようになります。 「すべてのタスクを実行」は、単に追加したボタンではありません。これは、バッチ実行を実際に信頼できるものにするための数か月の作業の集大成であり、事後により複雑な混乱を修正する必要なく、タスクを実行しながら時間と労力を節約できます。 「すべてのタスクを実行」は、現在すべての Kiro ユーザーが利用できます。 次の仕様で試して 、 ご意見をお聞かせください 。

AWS re:Invent 2025 での プレビューリリース でお知らせしたとおり、メモリ最適化された新しい Amazon Elastic Compute Cloud (Amazon EC2) X8i インスタンスが一般提供されることを発表します。これらのインスタンスは、AWS でのみ利用可能な 3.9 GHz の持続的なオールコアターボ周波数を備えたカスタム Intel Xeon 6 プロセッサを搭載しています。これらの SAP 認定インスタンスは、クラウドにおける同等の Intel プロセッサの中でも最高のパフォーマンスと最速のメモリ帯域幅を提供します。 X8i インスタンスは、高いコンピューティングパフォーマンスと大規模なメモリフットプリントを必要とする SAP HANA などのインメモリデータベース、従来の大規模データベース、データ分析、Electronic Design Automation (EDA) など、メモリを大量に消費するワークロードに最適です。 これらのインスタンスは、前世代の X2i インスタンス と比較して 1.5 倍のメモリ容量 (最大 6 TB) と 3.4 倍のメモリ帯域幅を提供します。また、これらのインスタンスは X2i インスタンスと比較して最大 43% 高いパフォーマンスを実現し、一部の実際のワークロードではより高いパフォーマンスを発揮します。SAP Application Performance Standard (SAPS) のパフォーマンスが最大 50%、PostgreSQL のパフォーマンスが最大 47%、Memcached のパフォーマンスが最大 88%、AI 推論のパフォーマンスが最大 46% 向上します。 プレビュー中、 RISE with SAP などのお客様は、最大6 TB のメモリ容量を活用し、X2i インスタンスと比較してコンピューティングパフォーマンスが 50% 向上しました。これにより、SAP HANA ワークロードのトランザクション処理が加速し、クエリ応答時間が短縮されました。 Orion は、パフォーマンスのしきい値を維持しながら、X2idn インスタンスと比較して X8i インスタンスのアクティブコア数を削減し、SQL Server のライセンスコストを 50% 削減しました。 X8i インスタンス X8i インスタンスでは、3 つの大きいインスタンスサイズ ( 48xlarge 、 64xlarge 、 96xlarge ) を含む 14 のサイズが用意されているため、アプリケーションのスケールアップに適したサイズを選択できます。また、物理リソースに直接アクセスできるワークロードをデプロイするために 2 つのベアメタルサイズ ( metal-48xl と metal-96xl ) を選択できます。X8i インスタンスは、 Elastic Fabric Adapter (EFA) のサポートによる最大 100 Gbps のネットワーク帯域幅と、 Amazon Elastic Block Store (Amazon EBS) への最大 80 Gbps のスループットを備えています。 X8i インスタンスの仕様は次のとおりです。 インスタンス名 vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) x8i.large 2 32 最大 12.5 最大 10 x8i.xlarge 4 64 最大 12.5 最大 10 x8i.2xlarge 8 128 最大 15 最大 10 x8i.4xlarge 16 256 最大 15 最大 10 x8i.8xlarge 32 512 15 10 x8i.12xlarge 48 768 22.5 15 x8i.16xlarge 64 1,024 30 20 x8i.24xlarge 96 1,536 40 30 x8i.32xlarge 128 2,048 50 40 x8i.48xlarge 192 3,072 75 60 x8i.64xlarge 256 4,096 80 70 x8i.96xlarge 384 6,144 100 80 x8i.metal-48xl 192 3,072 75 60 x8i.metal-96xl 384 6,144 100 80 X8i インスタンスは、他の第 8 世代インスタンスタイプと同じく インスタンス帯域幅設定 (IBC) 機能をサポートしており、ネットワークと EBS 帯域幅の間でリソースを柔軟に割り当てることができます。ネットワークまたは EBS の帯域幅を最大 25% まで拡張できるため、データベースのパフォーマンス、クエリ処理速度、ログ記録効率が向上します。これらのインスタンスは第 6 世代の AWS Nitro Card を使用しており、CPU の仮想化、ストレージ、ネットワーキング機能を専用のハードウェアとソフトウェアにオフロードし、ワークロードのパフォーマンスとセキュリティを強化します。 今すぐご利用いただけます Amazon EC2 X8i インスタンスは現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト) の AWS リージョン でご利用いただけます。リージョンの提供状況と今後のロードマップについては、 [リージョン別の AWS 機能] の [CloudFormation リソース] タブでインスタンスタイプを検索してください。 これらのインスタンスは、 オンデマンドインスタンス 、 Savings Plans 、 スポットインスタンス として購入できます。詳細については、 Amazon EC2 の料金ページ をご覧ください。 Amazon EC2 コンソール でぜひ X8i インスタンスをお試しください。詳細については、 Amazon EC2 X8i インスタンスのページ をご覧ください。また、 AWS re:Post for EC2 に、あるいは通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

私は年初に、その年の最も重要な抱負を設定するようにしています。自分が達成したいことに集中するためです。AI とクラウドコンピューティングが抱負リストに含まれている場合、 AWS 無料利用枠 アカウントを作成して、最大 200 USD のクレジットを受け取り、6 か月間リスクなしで AWS サービスを試すことをご検討ください。 この期間中は、コンピューティング、ストレージ、データベース、AI/ML にまたがる重要なサービスを利用できるほか、毎月の使用制限内で 30 以上の常時無料のサービスにアクセスできます。6 か月後に、スタンダード AWS アカウントにアップグレードするかどうかを決定できます。 キャリアの選択肢を模索している学生も、スキルセットを拡大している開発者も、クラウドテクノロジーを使用し構築を行っているプロフェッショナルも、この実践的なアプローチにより、最も重要なこと、つまり自分が情熱を注いでいる分野で真の専門知識を育むことに集中できます。 1 月 5 日週のリリース 私が 1 月 12 日週に注目したリリースをご紹介します。 AWS Lambda – .NET 10 をマネージドランタイムとコンテナベースイメージの両方として使用するサーバーレスアプリケーションの作成のサポート を開始しました。更新が利用可能になり次第、AWS はマネージドランタイムとベースイメージに自動的に更新を適用します。 このブログ記事 で詳細をご覧ください。 Amazon ECS – EC2 起動タイプに加えて、 AWS Fargate および Amazon ECS マネージドインスタンスで実行されている Linux タスクに tmpfs マウントのサポート を追加しました。tmpfs を使用すると、タスクストレージにデータを書き込むことなく、コンテナ化されたワークロード用のメモリバックアップのファイルシステムを作成できます。 AWS Config – Amazon EC2、Amazon SageMaker、Amazon S3 Tables などの主要なサービス全体で、 追加の AWS リソースタイプ を発見、評価、監査、修正できるようになりました。 Amazon MQ – RabbitMQ ブローカー向けに HTTP ベースの認証を導入 しました。このプラグインは、関連する構成ファイルを変更することでブローカーに設定できます。また、RabbitMQ ブローカー向けの 相互 TLS を使用した証明書ベースの認証のサポート を開始しました。 Amazon MWAA – Amazon Managed Workflows for Apache Airflow (MWAA) を使用して Apache Airflow バージョン 2.11 環境を作成 できるようになりました。このバージョンの Apache Airflow には、Apache Airflow 3 へのアップグレードの準備に役立つ変更が導入されています。 Amazon EC2 – M8i 、 C8i と C8i-Flex 、 R8i と R8i-Flex 、 I7ie のインスタンスを、他の AWS リージョンでも利用 できるようになりました。 AWS Client VPN – 新しいクイックスタートにより、クライアント VPN エンドポイントのセットアップに必要なステップの数を削減 しました。 Amazon Quick Suite – AI エージェント向けの統合を、組み込みアクションライブラリに追加 しました。例えば、これらには現在、GitHub、Notion、Canva、Box、Linear、Hugging Face、Monday.com、HubSpot、Intercom などが含まれます。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 AWS Transform を使用した AWS SDK for Java v1 から v2 へのアップグレードの自動化 – 手動による介入や潜在的なエラーを最小限に抑えながら、Java アプリケーションの効率的なモダナイズをサポートします。 AWS Advanced JDBC Wrapper を使用して標準 JDBC ドライバーで Amazon Aurora の高度な機能を活用 – オープンソースの標準 JDBC ドライバーを使用する既存のアプリケーションを強化し、最小限のコード変更で Aurora と AWS クラウドの機能を活用できます。 Amazon Aurora DSQL のマルチリージョンエンドポイントルーティングの実装 – 手動で設定を変更することなく、データベーストラフィックを別のリージョンのエンドポイントにリダイレクトする自動ソリューションです。 Amazon Nova マルチモーダル埋め込みを使用したクロスモーダル検索 – 埋め込みの生成、クエリの処理、パフォーマンスの測定を行うことで、クロスモーダル検索システムを実装する方法です。実用的なコード例とこれらの機能をアプリケーションに追加するためのヒントをご紹介します。 今後の AWS イベント 1 月 28 日または 29 日 (タイムゾーンによって異なります) に Best of AWS re:Invent にご参加ください。これは、AWS re:Invent での最も影響力が大きい発表と上位セッションをお届けする無料のバーチャルイベントです。オープニングセッションでは、AWS VP 兼 Chief Evangelist の Jeff Barr がハイライトをご紹介します。 1 月 21 日まで、25 万 USD の賞金と AWS クレジットを獲得できる Global 10,000 AIdeas Competition にご参加いただけます (「AIdeas」の「I」は「Idea」の「I」で、小文字の「l (L)」ではありません)。コードはまだ必要ありません。アイデアを送信するだけです。セミファイナリストに選ばれた場合は、 AWS 無料利用枠 の範囲内で Kiro を使用してアプリを構築します。 AWS re:Invent 2026 での賞金獲得や注目の出展の可能性だけでなく、次世代 AI ツールの実地経験を積み、世界中のイノベーターとつながることができます。 これらの機会にご興味がおありの場合は、 AWS Builder Center に参加して AWS コミュニティのビルダーと一緒に学びましょう。 1 月 12 日週のニュースは以上です。1 月 19 日週の Weekly Roundup もお楽しみに! – Danilo 原文は こちら です。

本ブログは 株式会社デジナーレ 様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクト 伊勢田氷琴です。 セキュリティ脆弱性への対応は、現代のソフトウェア開発において避けて通れない重要な業務です。しかし、日々公開される膨大な脆弱性情報を収集し、自社システムへの影響を分析する作業は、多くの企業にとって大きな負担となっています。この記事では、株式会社デジナーレ様が Amazon Bedrock 、 Strands Agents 、 Amazon Bedrock AgentCore Runtime を活用して、脆弱性情報の収集から分析、レポート作成までを完全自動化したシステムを構築した事例をご紹介します。 多くの企業が直面するセキュリティ脆弱性管理の課題 株式会社デジナーレは、新サービス・UI 企画開発、UI プロトタイピング、自社事業展開を手がける企業です。同社では、自社で開発・運用するシステムのセキュリティを維持するため、日々公開される脆弱性情報を継続的に監視する必要がありました。 従来の脆弱性管理プロセスでは、エンジニアが複数の脆弱性情報サイトを手動で巡回し、関連する情報を収集・分析していました。この作業には毎日数時間が必要で、特に重要な脆弱性が公開された際には、迅速な対応が求められるため、担当者の負担は大きなものでした。また、情報の見落としや分析の遅れが、セキュリティリスクの増大につながる可能性もありました。 デジナーレ様が構築した脆弱性情報自動収集システムは、これらの課題を解決し、エンジニアが本来の開発業務に集中できる環境を実現しました。 生成 AI エージェントによる自動化を選択した理由 デジナーレ様は、この課題を解決するために、生成 AI エージェント技術の活用を検討しました。AWS を選択した理由は以下の通りです。 まず、Amazon Bedrock が提供する高性能な基盤モデルにより、複雑な脆弱性情報の理解と分析が可能になると判断しました。特に Claude などのモデルは、技術文書の読解と要約に優れた性能を発揮します。 次に、Strands Agents フレームワークの存在が大きな決め手となりました。Strands Agents は、複雑なエージェントループやツール利用の実装を抽象化し、開発者が本質的なビジネスロジックに集中できる環境を提供します。特に Agent Workflows 機能により、複数のエージェントを協調させた段階的な処理を簡潔に実装できる点が魅力的でした。 さらに、AgentCore Runtime により、開発したエージェントを AWS クラウド上に迅速かつセキュアにデプロイできることも重要なポイントでした。サーバーレスアーキテクチャにより、運用負荷を最小限に抑えながら、スケーラブルなシステムを構築できます。 ソリューションの概要 デジナーレ様が構築したシステムは、脆弱性情報の自動収集エージェントを中心に、フロントエンドとバックエンドで構成されています。 システム全体は、 AWS Lambda 、 Amazon DynamoDB 、 Amazon Cognito 、 Amazon S3 、 Amazon CloudFront 、 Amazon API Gateway で構成されています。フロントエンドは S3 と CloudFront から配信され、バックエンドは Lambda 関数と API Gateway で構成されます。過去の調査ログやレポートは DynamoDB に保存され、いつでも参照可能です。 図1: 脆弱性情報収集システムのアーキテクチャ Strands Agents で実装したエージェントは AgentCore Runtime にデプロイされており、定時実行により前日に公開された脆弱性情報を自動的に収集・分析します。 協調する 3 つの AI エージェントによる段階的処理 脆弱性情報収集エージェントは、Strands Agents の Agent Workflows 機能を使用して実装された 3 段階のワークフローで構成されています。この設計により、脆弱性調査という定型作業を再現性のある「決定的なワークフロー（Deterministic Workflow）」に迅速に落とし込むことができました。 図2: 調査、執筆、校正の3段階で構成されるエージェントワークフロー 図2に示すように、システムは以下の3つのエージェントで構成されています。 第1段階：調査エージェント エントリーポイントとなる調査エージェントは、以下の3つのツールを持っています。 RSS ツール ：複数の脆弱性公表サイトを RSS として登録し、最新情報を取得 脆弱性対応状況検索ツール ：各脆弱性への対応状況を調査 Web 検索ツール ：関連情報を補完的に取得 これらのツールを組み合わせることで、脆弱性情報を体系的に調査します。 第2段階：執筆エージェント 調査結果は、次の執筆エージェントにコンテキストとして渡されます。執筆エージェントはファイル編集ツールを持った編集特化のエージェントであり、指定された形式で読みやすいレポート記事を作成します。 第3段階：校正エージェント 最後に、執筆エージェントの出力を校正エージェントが確認します。事前に指定した要件に合致しているかを判定し、例えば報告内容の脆弱性が既に対応済みであったり、古い情報を参照している場合には、調査エージェントにフィードバックして再調査・再作成を行います。 このフィードバックループにより、常に最新かつ正確な情報がレポートに含まれることが保証されます。 調査業務の完全自動化による業務変革 このシステムの導入により、デジナーレ様は大きな成果を得ることができました。 開発者の業務効率化 最も顕著な効果は、脆弱性情報の調査にかかる時間の削減です。Strands Agents と AgentCore Runtime により、従来は担当者が毎日数時間を費やしていた調査作業が、事実上ゼロ時間になりました。エンジニアは、システムが自動生成したレポートを確認し、必要な対応を判断するだけで済むようになったのです。 また、情報収集の網羅性と即時性も向上しました。人手による巡回では見落としの可能性がありましたが、自動化により複数のソースから漏れなく情報を収集できるようになりました。さらに、定時実行により、毎朝最新の脆弱性情報がレポートとして用意されているため、迅速な対応判断が可能になりました。 生成されるレポートの品質 システムが自動生成するレポートは、セキュリティ担当者が必要とする情報を網羅的かつ簡潔にまとめています。 図3: システムが自動生成した脆弱性情報レポートのサンプル 図3に示すように、生成されるレポートには以下の特徴があります。 脆弱性の詳細情報 ：CVE 番号、影響を受けるバージョン、公開日などの基本情報が明確に記載 影響範囲の可視化 ：リスクの説明が色分けにより強調され、一目で重要度を把握可能 対応方針の明示 ：SDK のアップデート手順など、具体的な解決策がチェックリスト形式で提示 一次情報へのアクセス ：参照リンクが記載されており、詳細な技術情報への導線を確保 このように構造化された情報提示により、セキュリティ担当者は必要な情報に素早くアクセスし、適切な対応判断を下すことができます。 システムによる価値提供 レポート品質の向上は、Strands Agents の複数の特性が複合的に作用した結果です。エージェントの動作を完全に制御でき、カスタムツール（RSS、Web検索、ファイル編集など）を確実に統合でき、基盤モデルを各段階に最適なものに選択できるという特性により、3段階のワークフローで情報の収集、整理、検証が体系的に行われ、常に一定の品質を保ったレポートが生成されるようになりました。 組織への展開と影響 このソリューションは、デジナーレ様のグループ会社にも展開され、セキュリティ担当者を中心に約 10 名のメンバーに活用されています。各社のセキュリティ担当者が同じフォーマットのレポートを参照することで、グループ全体でのセキュリティ対応の標準化と効率化が実現されました。 生成 AI エージェント活用の今後の展開 デジナーレ様は、今回の成功を踏まえて、生成 AI エージェント技術のさらなる活用を検討しています。 脆弱性情報収集システムについては、現在は取得する一次情報のソースが固定化されているため、特定の情報が取得できないケースがあります。今後は、アカウント単位で取得元をカスタマイズできる機能の実装を予定しています。また、デフォルトの一次情報取得元を増やすとともに、より広範なネットワーク検索を行う仕組みの実装も検討しています。 Strands Agents と AgentCore Runtime の組み合わせにより、エージェント開発から本番運用までのサイクルが短縮されたことで、新しいアイデアを迅速に試すことができる環境が整いました。 お客様の声 本システムの開発を主導した安原氏（役職 x）は、今回の開発を振り返り次のようにコメントしています。 「Strands Agents を使用したシステムの構築を初めて行いましたが、様々な可能性を感じています。Strands Tools やオリジナルのツールを使って AI エージェントの動作を担保できる点が、今までとは違います。ワークフローでそれぞれのエージェントに専門性を持たせることによって、より精度の高いものが出来上がっていると感じました。」 まとめ デジナーレ様の事例は、Strands Agents と AgentCore Runtime を活用することで、複雑な業務プロセスを効果的に自動化できることを示しています。 特に注目すべき点は、Agent Workflows による段階的な処理の実装により、調査、執筆、校正という明確な役割分担を持つエージェント群を構築できたことです。これにより、各エージェントの責務が明確になり、保守性の高いシステムを実現しています。 脆弱性管理をはじめとするセキュリティ業務の自動化は、多くの企業にとって重要な課題です。生成 AI エージェント技術は、こうした課題に対する有力な解決策となり得ます。 株式会社デジナーレ：CTO 津村 忠助様（左）、SE 安原 大喜様 様（右） ソリューションアーキテクト 伊勢田氷琴

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。今年の目標は Kiro にどんどん業務をオフロードしていくことです。まずは Kiro powers を作るための Power Builder power に入門してみようと思います。 それでは、1 月 12 日週の生成 AI with AWS界隈のニュースを見ていきましょう。昨年実施したイベントの報告やBedrock のコスト分析を楽にするアップデートなどさまざまなアップデートが発表されております。 さまざまなニュース ブログ記事「 弥生株式会社様の AI-DLC Unicorn Gym 開催レポート: 開発プロセスの再設計による生産性の限界突破への挑戦 」を公開 弥生株式会社様とAWS Japanが共同で実施したAI-DLC Unicorn Gymの実践レポートです。2025年12月10日から12日の3日間、実際のプロダクトを対象にAI-DLC（AI駆動開発ライフサイクル）を実践し、通常1ヶ月以上かかる開発を2.5日で完了させました。「まず会議」から「まず AI」への転換、ロールを越えたコラボレーション、並列開発における統合の課題など、実践から得られた学びが詳しく紹介されています。 ブログ記事「 【開催報告】企業の生成 AI 活用を加速する Dify Enterprise on AWS 〜セキュアなデータの活用とパートナー導入事例〜 」を公開 2025年11月21日に開催されたDify Enterprise on AWSイベントの開催報告です。Difyの最新機能（MCP、ナレッジパイプライン、トリガー機能など）の紹介に加え、Snowflakeとの連携によるセキュアなデータ活用、AWS上でのDify構築の選択肢、リコー様によるパートナー導入事例が紹介されています。 ブログ記事「 [資料公開 &amp; 開催報告] Amazon Q Developer &amp; Kiro Meetup #5 を開催しました 」を公開 2025年12月15日に開催されたAmazon Q Developer &amp; Kiro Meetup #5の開催報告です。AWS re:Invent 2025でのKiroアップデート情報に加え、ゼンリンデータコム様のIAM IdCとルールファイルによる組織展開事例、NTTドコモ様のPOPLAR開発での活用事例、リクルート様のAI-DLC導入事例が紹介されています。 ブログ記事「 Agentic workflowを使用したAmazon Nova Premierによるコード移行の効率化 」を公開 レガシーなCコードを最新のJava/Springフレームワークに移行する際の課題と、Amazon Bedrock Converse APIとAmazon Nova Premierを活用したagentic workflowによる解決方法を紹介しています。複数の専門エージェント（コード分析、変換、セキュリティ評価、検証など）を組み合わせることで、移行時間とコストを削減し、コード品質を向上させる実践的なアプローチが解説されています。 ブログ記事「 VMware マイグレーションの加速: AWS Transform の新しいエクスペリエンス 」を公開 AWS Transform for VMwareの新機能を紹介しています。AI駆動のアプローチにより、VMware環境からAmazon EC2へのエンドツーエンド移行を支援します。検出、移行計画、ネットワーク変換（Cisco ACI、Palo Alto、Fortinetのサポート追加）、サーバー移行の各ステップで、チャットベースの操作とマルチアカウントサポートを提供し、移行プロセスを大幅に簡素化します。 ブログ記事「 Amazon Q Business と Amazon Bedrock によるSAP データ価値の最大化 – パート 2 」を公開 Amazon Bedrock Knowledge Bases for Structured Dataを使用して、SAPデータに自然言語で質問する方法を解説しています。Amazon Redshiftにロードしたサンプルの自転車販売データを例に、構造化データ用ナレッジベースの設定から、基盤モデルを使った自然言語によるデータ分析までをステップバイステップで紹介しています。 サービスアップデート Amazon Lex が英語向けに改善された音声認識モデルを提供開始 Amazon Lexが英語向けのニューラル自動音声認識（ASR）モデルを提供開始しました。複数の英語ロケールのデータで訓練されたこのモデルは、非ネイティブスピーカーや地域アクセントを含む多様な話し方のパターンを認識する精度が向上しています。これにより、エンドカスタマーが繰り返し話す必要性が減り、セルフサービスの成功率が向上します。 Amazon Lex が音声活動検出感度の設定機能を提供開始 Amazon Lexが3段階の音声アクティビティ検出（VAD）感度レベル（デフォルト、高、最大）を提供開始しました。デフォルトは一般的な背景ノイズレベルに適しており、高は忙しいオフィスや小売スペースなどの一貫した中程度のノイズレベル向け、最大は製造現場や建設現場などの非常にノイズの多い環境向けです。Amazon ConnectのConversational AI designerでボットロケールを作成または更新する際に設定できます。 AWS Data Exports が Amazon Bedrock モデル使用の詳細な操作可視性を追加 AWS Data Exportsが、Amazon Bedrockの操作タイプをコストレポートで区別できるようになりました。これまでの汎用的な「Usage」ラベルに代わり、「InvokeModelInference」や「InvokeModelStreamingInference」などの具体的な操作タイプが表示されます。FinOpsチームやコスト最適化担当者にとって、Amazon Bedrockを使用する組織の詳細な請求分析が可能になります。 AWS Transform custom が AWS PrivateLink サポートを追加し、欧州（フランクフルト）リージョンに拡大 AWS Transform customがAWS PrivateLinkをサポートし、欧州（フランクフルト）リージョンで利用可能になりました。AWS Transform customは、言語バージョンのアップグレード、APIマイグレーション、フレームワーク更新などの反復的な変換タスクを自動化することで、組織の技術的負債を削減します。AWS PrivateLinkサポートにより、パブリックインターネットを経由せずにAmazon VPCからAWS Transform customにアクセスでき、セキュリティとコンプライアンス要件を満たすことができます。 Amazon SageMaker HyperPod がコンソールでのクラスター作成前にサービスクォータを検証 Amazon SageMaker HyperPodコンソールが、クラスター作成を開始する前にAWSアカウントのサービスクォータを検証するようになりました。大規模なAI/MLクラスターを作成する際、インスタンス、ストレージ、ネットワークリソースに十分なクォータがあることを確認する必要がありますが、これまでは複数のAWSサービスにわたる手動チェックが必要でした。新しいクォータ検証機能は、インスタンスタイプの制限、EBSボリュームサイズ、VPC関連のクォータなど、クラスター構成に対してアカウントレベルのクォータを自動的にチェックし、クォータ超過の可能性がある場合は警告とService Quotasコンソールへの直接リンクを提供します。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航&nbsp; (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近見たドラマは「ストレンジャーシングス」です。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 2026年になり、早 3 週間近くが過ぎましたね。皆様、今年の目標は立てましたか？ 私は今年、英会話を再開しようと計画しています。昨年末にもお伝えしましたが、 AWS 認定試験の受験支援キャンペーン が2026年2月15日で終了します。このキャンペーンでは、期間中に初回受験を済ませれば、万が一不合格でも2026年3月31日までに同じ試験を1回無料で再受験できます。新年の目標にAWS資格取得を掲げた方は、このチャンスをぜひ活用してください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年1月12日週の主要なアップデート 1/12(月) Amazon Inspector が Java Gradle サポートを追加し、エコシステムカバレッジを拡張 Amazon Inspector が Java Gradle サポートと新たなエコシステムカバレッジを追加しました。Lambda 関数や ECR イメージのスキャンで、従来の Java Maven に加えて Gradle プロジェクトの依存関係も自動検出できるようになり、MySQL や PHP、Jenkins-core なども対象に含まれます。これにより、パッケージマネージャー外でインストールされたソフトウェアの脆弱性も発見できるため、より包括的なセキュリティ対策が可能です。詳細は こちらの Amazon Inspector ページをご参照ください。 Amazon Lex が音声アクティビティ検出感度設定を開始 Amazon Lex で各ボットのロケール毎に音声アクティビティ検出 (VAD) の感度を 3 段階で設定できるようになりました。デフォルトのレベルは典型的な背景ノイズレベルの環境、高レベルは忙しいオフィスや店舗などの中程度の騒音環境、最大レベルでは製造現場、建設現場、屋外など高騒音環境に対応します。これまで騒音の多い環境では音声認識の精度が落ちる課題がありましたが、環境に応じた感度調整により、様々な場所でのチャットボット活用が可能になります。詳細は こちらのドキュメントをご参照ください。 1/13(火) Amazon Connect Cases が AWS CloudFormation をサポート開始 Amazon Connect Cases が AWS CloudFormation に対応し、ケース管理の設定を Infrastructure as Code で管理できるようになりました。従来は手動で行っていたテンプレートやフィールド、レイアウトの設定を、CloudFormation テンプレートで自動化できます。これにより複数の Connect インスタンス間で一貫した設定が可能になり、設定ミスの削減や運用効率の向上が期待できます。詳細は こちらのドキュメントをご参照ください。 Amazon RDS for PostgreSQL がマイナーバージョン 12.22-rds.20251114 および 11.22-rds.20251114 の延長サポートを発表 Amazon RDS for PostgreSQL でマイナーバージョン 12.22-rds.20251114 と 11.22-rds.2025111412.22 の延長サポートが提供開始されました。延長サポートでは、コミュニティサポート終了後も最大 3 年間、Amazon RDS が重要なセキュリティ・バグ修正を提供するため、急なメジャーバージョンアップグレードの負担を軽減できます。自動マイナーバージョンアップグレード機能も活用でき、運用負荷を削減しながら最新の修正を適用可能です。詳細は こちらのドキュメントをご参照ください。 1/14(水) Amazon VPC IPAM ポリシーが RDS と Application Load Balancer をサポート Amazon VPC IPAM で RDS インスタンスと Application Load Balancer (ALB) のポリシー機能がサポート開始されました。これにより IP 管理者が中央でこれらのリソースの IP 割り当て戦略を設定・強制できるようになります。従来はデータベース管理者やアプリケーション開発者に IP 割り当て要件を教育し、ベストプラクティスの遵守に頼る必要がありましたが、今回のアップデートで確実に特定の IPAM プールから IP が割り当てられるため、セキュリティグループやファイアウォールでの IP ベースフィルタリングを安心して実装できます。詳細は こちらのドキュメントをご参照ください。 1/15(木) AWS Data Exports が Amazon Bedrock モデル使用量の詳細なオペレーション可視性を追加 AWS Data Exports で Amazon Bedrock の操作タイプが詳細に表示されるようになりました。従来は「Usage」という曖昧な表示でしたが、「InvokeModelInference」や「InvokeModelStreamingInference」など具体的な操作名で区別できます。CUR レポートや Cost Explorer で利用でき、FinOps チームや組織がコスト分析や最適化を効率的に行えるようになります。詳細は こちらのドキュメントをご参照ください。 Amazon RDS が Microsoft SQL Server の最新 CU および GDR アップデートをサポート Amazon RDS for SQL Server で Microsoft SQL Server の最新セキュリティアップデートが利用可能になりました。SQL Server 2016、2017、2019、2022 の各バージョンに対応し、重要なセキュリティ脆弱性 CVE-2025-59499 が修正されています。これにより、データベースのセキュリティが大幅に強化され、安心してビジネスクリティカルなアプリケーションを運用できます。既存の RDS インスタンスも簡単にアップグレード可能で、コンソールや CLI から数クリックで最新の安全な環境に移行できます。詳細は こちらのドキュメントをご参照ください。 AWS Lambda が DynamoDB Streams のクロスアカウントアクセスを発表 AWS Lambda で DynamoDB Streams のクロスアカウントアクセスが可能になりました。これまで複数の AWS アカウント間で DynamoDB のデータ変更イベントを共有するには、複雑なデータレプリケーション仕組みが必要でした。今回のアップデートにより、リソースベースポリシーを設定するだけで、別アカウントの Lambda 関数から DynamoDB Streams にアクセスできます。マルチアカウント環境での運用が大幅に簡素化され、運用負荷を削減できます。詳細は こちらのドキュメントをご参照ください。 Amazon EC2 メモリ最適化 X8i インスタンスの発表 AWS がメモリ最適化された新しい EC2 X8i インスタンスを発表しました。従来の X2i と比較して 43% 高いパフォーマンスと 1.5 倍のメモリ容量 (最大 6TB) を提供します。SAP HANA や大規模データベース、データ分析などのメモリ集約的なワークロードに最適で、PostgreSQL では 47% 高速化、AI 推論では 46% の性能向上を実現します。現在バージニア北部、オハイオ、オレゴン、フランクフルトリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 AWS データベースが Vercel の v0 で利用可能になりました Vercel の AI 駆動型 UI 生成ツール v0 で、Amazon Aurora PostgreSQL、Amazon Aurora DSQL、Amazon DynamoDB が利用可能になりました。自然言語でプロンプトを入力するだけで、フロントエンドからバックエンドまで含むフルスタック Web アプリを数分で構築し、AWS データベースに自動接続できます。新規 AWS アカウントには 100 ドルのクレジットが付与され、DynamoDB のオンデマンドモードなど使用量ベースの課金により、リクエストがない時はコストを最小限に抑えられるため、プロトタイプ開発や本格運用まで幅広く活用できます。詳細は こちらのドキュメントをご参照ください。 1/16(金) AWS Outposts ラックが複数の LGW ルーティングドメインをサポート AWS Outposts ラックで複数の LGW (ローカルゲートウェイ) ルーティングドメインがサポートされました。1 つの Outpost につき最大 10 個の独立したルーティングドメインを作成でき、各ドメインは独自のルートテーブルと BGP セッションを持ちます。これにより部門やビジネスユニット間でネットワークトラフィックを完全に分離できるようになり、セキュリティとガバナンスが大幅に向上します。第 2 世代 Outposts ラックで追加料金なしに利用可能です。詳細は こちらの Blog 記事をご参照ください。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

トラフィックの変動に対して自動的にキャパシティを調整する Auto Scalingと、安全なデプロイメントを実現する Blue/Green デプロイ戦略の組み合わせは、可用性と運用効率を両立する構成です。今回のテーマである Amazon ECS を利用する際に採用しているユーザーも多いのではないでしょうか。 しかし一方、Auto Scaling と Blue/Green デプロイ戦略を併用する場合、両機能が同時に作用するタイミングで複雑な相互作用が発生します。そのため、「Blue/Green デプロイメント中は Auto Scaling を停止している」といった声や「リスクが少ない夜間に更新を行う判断をしている」という声を複数聞きます。もちろん、組織の状況や運用するシステムの特性にもよるため、必ずしも悪い運用ではありませんが、もしかしたら相互作用の機序を明らかにすることで、労力を削減する余地があるかもしれません。 本記事ではまず、本テーマで扱う課題について詳しくない方に向けて Auto Scaling と Blue/Green デプロイを併用する際の相互作用について解説します。次に、2025年7月に発表された ECS built-in Blue/Green デプロイの技術的特徴にフォーカスし、 Auto Scaling との併用に焦点をあて安全かつ効率的に併用する実装方法の例を示します。 ※本記事では最新の ECS built-in Blue/Green デプロイ戦略にフォーカスしますが、記事の大部分については CodeDeploy を利用したデプロイ戦略やカスタムデプロイ戦略を採用する場合にも当てはまります。また、厳密には ECS の新しいデプロイ戦略は ECS Blue/Green デプロイや ECS native Blue/Green デプロイといった表記をされることがありますが、本記事では ECS built-in Blue Green デプロイという表記で統一します。 Auto Scaling と Blue/Green デプロイの相互作用を理解する ECS Service をベースに Auto Scaling と Blue/Green デプロイを併用している際の複雑さについて解説します。 まず、複雑になるタイミングについて、Auto Scaling は常に対象のサービスのメトリクスを読み取りスケールを判断しています。一方、Blue/Green デプロイメントは、アプリケーションの更新時のデプロイ戦略の一つであるため、デプロイタイミングで一時的にデプロイ中という状態が発生します。 従って、ユーザー視点では Blue/Green デプロイが行われるアプリケーションの更新時に、ECS Service の状態が複雑になります。 上記タイミングで発生する相互作用の複雑さの原因は、大別すると 2 つに分けられます。1 つ目は Blue/Green デプロイの環境のリソース数です。Auto Scaling は環境の情報を元にスケールアウト、スケールインを判断しますが、Blue/Green デプロイ時はユーザーのリクエストはそのままに、環境に含まれるリソースの数は一時的に 2 倍となります。そのため、環境全体ではユーザーリクエストに対して一時的に 2 倍のリソースが存在することとなり、Auto Scaling からは過剰にリソースをプロビジョンしているように見えてしまう場合があります。 2 つ目はリソースの内部状態です。Green 環境のリソースはデプロイ後十分に初期化処理が終了するまでは不安定な状態にあります。Green 環境には最初トラフィックが流れないため、リソースの使用量が少ないことが想定されますが、初期化処理によってはリソースが激しく消費され、追加のリソースが必要、と判断されてしまう可能性があります。 なお、2 つの複雑さを説明しましたが、多くの場合 1 つ目の複雑さ、つまり Blue/Green 中のリソース数の一時的な増加による、本来より小さいメトリクスの値の報告の方が重要度が高い場合が多いです。後者はスケールアウトを招く可能性がある一方、前者であるこれはスケールインを招くことから、サービスの提供そのものに影響を与える可能性があるからです。 ECS Service における Application Auto Scaling と Blue/Green デプロイメント戦略の詳細 前章では、一般的な Blue/Green と Auto Scaling の併用による複雑さについて説明しました。 具体的なサービスや機能ではこれらの点を部分的にカバーしている場合もあります。ECS で本テーマについて考える際には、以下 5 つの点を押さえる必要があります。 1. デフォルトのメトリクスは Blue 環境と Green 環境のリソースを統合的に扱う ECS のターゲット追跡ポリシーで提供するデフォルトのメトリクス設定のうち、「ALBRequestCountPerTarget」は現時点で Blue/Green デプロイに対応していません。残りの「ECSServiceAverageMemoryUtilization」、「ECSServiceAverageCPUUtilization」は、いずれも ECS Service がディメンションであるメトリクスです。つまり ECS Service に含まれる、各 ECS Task のリソース使用率の平均を元にスケールを判断します。つまり、Blue/Green 中はタスクが 2 倍になることで本来の値より低い値となる可能性があります。 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html ブルー/グリーンデプロイタイプでは、ターゲット追跡スケーリングポリシーの ALBRequestCountPerTarget メトリクスはサポートされません。 2. ECS はデプロイメント中はスケールインのみ無効化する ECS Service のデプロイ中は、外部デプロイコントローラーを使用する場合を除き、スケールインのみ無効化されます。これは Application Auto Scaling による意図しないタスク削除を防ぐための保護メカニズムで、スケールアウトは通常通り動作を継続します。 対象となる ECS Service における Blue/Green の切り替えにかかる時間が非常に短い場合、こちらの性質を活用するだけで十分な可能性もあります。 https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-auto-scaling.html#service-auto-scaling-deployments Application Auto Scaling は、 Amazon ECS デプロイの進行中 にスケールインプロセスをオフにします。ただし、スケールアウトプロセスは、中断しない限り、デプロイ中に引き続き発生します。 注意点として、デプロイが終了した時点からスケールインのプロセスも有効になります。スケールイン実施判断に使用されるメトリクスは Blue/Green 中に出力されたメトリクスを含むため、厳密にはデプロイ完了直後において本来必要のないスケールインが発生するリスクが存在します。こちらは 4 で解説します。 3. ロールバック機能 Blue/Green デプロイメントではロールバックの機能がありますが、これはデプロイメントプロセス中の中で行われます。したがってロールバックが終了するまでがデプロイメントの範囲となるため、スケールインは無効化されます。 そのため、ロールバックの発生に関して特別な設定は必要ありません。しかし、ロールバックを選択する際は、通常のデプロイが意図通り成功しなかったと言うことであり、デプロイにかかっている時間が増加している可能性があります。そういった場合に意図せずスケールインされないかについては確認する必要があります。 4. ターゲット追跡スケーリングの参照範囲とデプロイ時間の関係 ECS のターゲット追跡ポリシーで提供するデフォルトのメトリック設定を適用した場合、スケールアウト方向には過去3データポイント（3分間）のメトリックが、スケールイン方向には過去15データポイント（15分間）のメトリックを対象に基準値との相違点や距離を判定します。 Blue/Green によるデプロイ時間が短い場合は問題ないと考えられる一方、15分以上デプロイに時間がかかる場合、本来より低いメトリックの値が15分以上記録されることになります。 2. で述べたとおり ECS ではデプロイ中のスケールインは無効化されているものの、デプロイ明け直後にはスケールインが可能となるため、デプロイ明け直後にスケールインが走るリスクがある場合は、ポリシーを見直す必要があるでしょう。 5. ECS で推奨されるユーザーのカスタマイズ範囲 以下の通り、ECS Service に対して Auto Scaling を設定する際は、事前定義された設定を利用する、もしくは Auto Scaling でカスタムのメトリクスを利用する方法の 2 種類になります。 &nbsp; この際、以下の通り自動で作成される Amazon CloudWatch Alarm の設定の変更については推奨されていません。つまり、アラームの発火に使用するデータポイント数の設定などの変更が現状は非推奨であるため、スケールインに使用されるデータポイントの期間の範囲が15分であることの変更等は現時点では難しい、といった状況に注意する必要があります。なお、ステップスケーリングではデータポイントの数の変更については明記されていませんので注意してください。 ターゲットメトリクスを使用して Amazon ECS サービスをスケールする https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html ターゲット追跡スケーリングポリシーのためにサービスの自動スケーリングが管理する CloudWatch アラームを編集または削除しないでください。スケーリングポリシーを削除するときに、サービスの自動スケーリングはアラームを自動的に削除します。 ECS Service における Application Auto Scaling と Blue/Green デプロイメント戦略の併用の例 ここまでの内容を踏まえると、まずは ECS のデフォルトの仕組みで十分対応可能であるかどうかについて検討する必要があります。失敗時のケース等を含め、デプロイ時間が十分に短い等、リスクを許容し併用するといった意思決定もありうると思います。 スケールイン等のリスクが許容できない場合、Green リソースの追加による一時的なリソースの増加に対応する必要があります。ここからは特にスケールインのリスクに対する対応の例を3つ示します。これらの例で対応可能な場合は併用を採用し、それでも要件上難しい場合は併用しないといった意思決定をとることになります。 なお、以下説明で頻出する、ECS Service におけるカスタムのメトリクスやアラームを設定する具体的な方法については以下のブログを参考ください。 カスタムメトリクスに基づいた Application Auto Scaling による Amazon ECS サービスのオートスケール | Amazon Web Services ブログ https://aws.amazon.com/jp/blogs/news/autoscaling-amazon-ecs-services-based-on-custom-metrics-with-application-auto-scaling/ パターン1: 「本来のタスク数をベースとしたリソース使用率を算出するカスタム設定されたアラーム」を使用するターゲット追跡スケーリングポリシーを設定する この方法は、スケールインの懸念に対する対応として有効です。 ECS のメトリクスでは、Blue/Green 中も値が変化しないメトリクスとして、DesiredTaskCount が利用可能です。そのため、例えば Container Insights のメトリクスを利用し、以下のような式に対してアラームを設定することで、本来のタスク数を分母とした CPU 使用率に近い値を導出することができます。 式 CPUUtilization * RunningTaskCount / DesiredTaskCount 各メトリクスの説明 DesiredTaskCount: ECS Service で設定した必要なタスクの数 RunningTaskCount: 現在 RUNNING 状態にあるタスクの数 CPUUtilization サービスに属するタスクで使用されている CPU ユニットの総数を、サービスに属するタスク用に予約されている CPU ユニットの総数で割った値 パターン2: 「バックエンド ECS Task に依存しないカスタムメトリクスを活用するカスタムアラーム」を使用するターゲット追跡スケーリングポリシーを設定する ECS Task の前段に配置される ALB の TargetResponseTime や NewConnectionCount などのメトリクスは、Blue/Green 中もリソースの状態が変化しません。そのため、実際のリソース使用状況ではなく間接的な値となるものの、これらを利用することで この方法は、 ECS Task の状態に依存しないため、スケールイン方向、スケールアウト方向いずれの方向においても一貫した値をベースにBlue/Green 中もスケールを判断することができます。 式 TargetResponseTime NewConnectionCount パターン3: ECS Service に対して複数のターゲット追跡スケーリングポリシーを設定する ECS では一つの ECS Service に対して複数のターゲット追跡スケーリングポリシーを設定できます。この場合、スケールアウト方向にはいずれか 1 つのメトリックが閾値を超えれば良いのに対し、スケールインでは全てのメトリックが条件を満たす必要があります。 ターゲットメトリクスを使用して Amazon ECS サービスをスケールする – Amazon Elastic Container Service https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html Amazon ECS サービスに対して複数のターゲット追跡スケーリングポリシーを設定できます。ただし、各ポリシーがそれぞれ異なるメトリクスを使用している必要があります。サービスの自動スケーリングの目的は常に可用性を優先することであるため、その動作は、スケールアウトまたはスケールインに対するターゲット追跡ポリシーの準備が整っているかどうかに応じて異なります。ターゲット追跡ポリシーのいずれかでスケールアウトする準備ができると、サービスがスケールアウトされますが、すべてのターゲット追跡ポリシー (スケールイン部分がオン) でスケールインする準備ができている場合にのみスケールインされます。 従って、現在設定しているポリシーに追加で、Blue/Green 中に発火しにくい、低い値のターゲット追跡スケーリングポリシーを設定することで、スケールアウト方向にはこれまでと同じ速度である一方、スケールインについてはより緩やかな実施を実現することが可能です。この方法はこれまでのパターンと併用することが可能です。 まとめ 本記事では、ECS built-in Blue/Green デプロイメントとApplication Auto Scaling の効果的な併用方法について包括的に解説しました。従来の運用では、Auto Scaling と Blue/Green の併用時に発生する技術的課題を回避するため、デプロイ中の Auto Scaling 停止という対処法が一般的でしたが、これによりトラフィック増加への対応不可、デプロイ頻度の制限、運用工数の増加といった新たな課題が生じていました。 本記事では、サービスによっては既存の ECS の仕組みに任せたり、カスタムのメトリクスを設定することで Auto Scaling と ECS Blue/Green デプロイを設定変更せず併用する余地があることを示しました。また、その背景となる Auto Scaling と Blue/Green デプロイの相互作用の仕組みを明らかにし、ユーザーのより高度な活用の基礎となる要素を示すことができたと考えています。 ECS built-in Blue/Green デプロイメントと Auto Scaling の組み合わせは、現代のクラウドネイティブアプリケーション運用において、可用性、効率性、アジリティのすべてを同時に向上させる強力なソリューションです。ビジネスやサービスの要件に応じて適切な選択をする際に、本記事がその一助となれば幸いです。