AWS What's New Digest

Appearance

2026年03月05日 ​

[Opensearch Service] Amazon OpenSearch Service introduces capacity optimized blue/green deployments ​

概要 ​

Amazon OpenSearch Serviceは、青/緑（blue/green）デプロイにCapacity Optimizedオプションを追加しました。インスタンス不足時でもインクリメンタルなバッチ方式でドメイン更新を完了できるようになり、更新失敗や待機を減らします。

変更内容・新機能の詳細 ​

従来、OpenSearch Serviceの青/緑デプロイは更新対象クラスターと同等のインスタンス容量を事前に確保する（100%キャパシティ）必要があり、十分な空き容量がなければ更新を再試行する必要がありました。今回追加されたCapacity Optimizedオプションでは、まずフルスワップ（従来どおり）を試み、利用可能なインスタンスが不足する場合は自動的にバッチ（段階的）デプロイへフォールバックします。バッチサイズはクラスター規模と利用可能インスタンスに基づいてOpenSearch Service側で自動決定され、更新は分割された小さなグループごとに順次適用されます。これにより、更新中に必要となる追加インスタンス数を減らせますが、フルスワップよりも総所要時間は長くなる可能性があります。ユーザーはコンソールまたはAPIでデプロイ戦略（Full Swap（デフォルト）またはCapacity Optimized）を選択できます。30ノード以上のクラスターではCapacity Optimizedの利用が推奨されています。全てのOpenSearchおよびElasticsearchのバージョンで利用可能で、OpenSearch Serviceが提供されているすべてのAWS商用リージョンでサポートされます。

影響範囲・利用シーン ​

  • 対象ユーザー: OpenSearch/Elasticsearchを運用するクラウドエンジニア、SRE、プラットフォームチーム、DB管理者
  • 利用シーンまたは効果: インスタンス容量が限られた環境でのドメインアップデート（バージョンアップ、設定変更、ノードタイプ変更など）において、更新を待つことなく段階的に適用できる
  • 運用効果: フルキャパシティを一時的に確保できない場合でもデプロイを進められるため、メンテナンス遅延と手動の再試行が減少する
  • パフォーマンス/可用性への影響: バッチ適用中は更新が段階的に行われるため、フルスワップに比べて更新完了までの時間が長くなる可能性があるが、既存環境はフォールバック先として保持されるためダウンタイム最小化は維持される
  • コスト影響: 一時的に必要となる追加インスタンス数が減ることで短期的な追加料金を抑えられる。一方、更新に要する時間が延びる場合はオペレーション時間やモニタリングコストに影響する可能性がある

技術的な注意点 ​

  • IAM権限: ドメイン更新を行うためのOpenSearch Service関連のIAM権限が必要（例: es:UpdateElasticsearchDomainConfig 等）。コンソール/API操作に必要な権限を事前に確認してください
  • リージョン制限: OpenSearch Serviceが提供されているすべてのAWS商用リージョンで利用可能とされていますが、利用前に対象リージョンでのサポート状況を確認してください
  • コスト: フルスワップ時は更新中に同等分の追加インスタンスを確保するためコスト増。Capacity Optimizedは追加インスタンス数を削減できるが、デプロイ時間延長による間接コストが発生する可能性があります
  • バッチ設定: バッチサイズはサービス側で自動決定され、ユーザーが明示的にバッチサイズを指定するオプションは提供されていません
  • 推奨ノード数: AWSは30ノード以上のクラスターでCapacity Optimizedの利用を推奨しています（小規模クラスターではフルスワップのほうが高速）
  • バージョン互換性: すべてのOpenSearchおよびElasticsearchバージョンで利用可能と明記されていますが、特定の変更（例: インデックス設定やプラグイン）による影響がないかドキュメントで事前確認してください
  • 運用上の注意: バッチデプロイは更新期間が長くなるため、メンテナンスウィンドウやモニタリング／アラートの調整を検討してください

参考情報 ​

[Connect] Introducing Amazon Connect Health, Agentic AI Built for Healthcare ​

概要 ​

Amazon Connect Healthが一般提供を開始しました。医療向けに設計されたエージェント型AIを通じて、患者対応と診療現場の業務を自動化・効率化し、患者の迅速な受診導線と臨床スタッフの事務負荷軽減を目指します。

変更内容・新機能の詳細 ​

Amazon Connect Healthは、患者アクセス（コンタクトセンター）やEHR、テレヘルス等の既存ワークフローに短期間で統合可能な“エージェント”群を提供します。ローンチ時に利用可能なエージェントは以下のとおりです： ・Patient verification（GA）: EHRレコードとリアルタイム突合して患者本人確認を実施し、予約情報の照会を行うことで着信対応時間を短縮します。 ・Appointment management（Preview）: 自然言語の音声対話で24/7の予約受付を行い、リアルタイムの保険適格性チェックを組み合わせて時間外予約を可能にします。 ・Patient insights（Preview）: 診療前に関連する患者履歴や臨床コンテキストをサーフェイスし、診療前準備の時間を削減します。 ・Ambient documentation（GA）: 診療時の患者–医師会話をキャプチャしてリアルタイムに臨床ノートを作成します（サマリーや構造化ノート生成）。 ・Medical coding（Preview）: 診療後の臨床ノートからICD-10/CPTコードを自動生成し、監査トレイルを保持します。 機能はAmazon Connectとネイティブ統合され、管理画面（Amazon Connect Healthアプリ）から数分で設定・カスタマイズできます。診療現場向けの機能（Ambient documentation, Patient insights, Medical coding）は統一SDK経由でEHRや臨床向けアプリへ組み込めます。すべての機能は責任あるAIのベストプラクティスとセーフガードに従い、HIPAA適格（eligible）として設計されており、AWSのセキュリティ・信頼性基準が適用されます。

影響範囲・利用シーン ​

  • 対象ユーザー: 医療機関（病院／診療所）、患者アクセスセンター、臨床医、医療事務スタッフ、ヘルスケア向けソフトウェア開発者
  • 利用シーン: コンタクトセンターでの本人確認と予約受付の自動化、EHR連携による診療前情報の提示、診療中の自動記録作成、診療後のコード自動生成と請求準備の効率化
  • 運用効果: 着信/受付対応時間の短縮、夜間・時間外の予約受付による患者アクセス向上、臨床スタッフの書類作業削減で診療時間を増加、コーディングの自動化で請求精度とスループット向上

技術的な注意点 ​

  • IAM権限: Amazon Connectおよび関連サービス（S3、KMS、CloudWatch、Amazon Transcribe/Transcribe Medical、Comprehend Medical等）にアクセスできる適切なIAMロール・ポリシーが必要です
  • リージョン制限: 現時点では US East (N. Virginia) と US West (Oregon) で提供されています。その他リージョンは未対応のため展開前に確認してください
  • コスト: Amazon Connect利用料に加え、トランスクリプション、NLP/Comprehend系処理、ストレージ、API呼び出し等の使用量に基づく追加料金が発生します。Preview機能は将来の料金変更の対象となる可能性があります
  • データ保護／コンプライアンス: HIPAA-eligible とされているものの、実稼働でPHIを扱う場合はCovered Entity／Business Associate Agreement（BAA）や組織側のデータ保護ポリシーの整備が必要です
  • Preview機能: Appointment management、Patient insights、Medical codingはPreviewステータスのため、機能仕様や動作範囲が変わる可能性があります。運用前に十分な検証を行ってください
  • EHR連携: リアルタイム照合や患者コンテキスト提示にはEHR側のAPI/接続設定、データマッピング（患者ID、予約レコード、保険情報など）の実装が必要です。FHIR等の標準フォーマット対応状況を確認してください
  • 監査／ガバナンス: Medical coding等は自動生成に監査トレイルを保持しますが、臨床的妥当性確認のためヒューマンレビューやワークフローの組み込みを推奨します
  • 運用監視: 音声認識精度やAI判断のモニタリング、ログ保存ポリシー（S3バケットライフサイクル、暗号化）を設計してください
  • SDK/開発: Point-of-care機能は統一SDKで提供されます。既存アプリへの組み込みには開発リソースとEHRシステムとの認証連携が必要です

参考情報 ​

[Healthlake] AWS HealthLake announces data transformation agent for automated CCDA-to-FHIR data conversion (Preview) ​

概要 ​

AWS HealthLake のプレビュー機能「data transformation agent」は、CCDA 形式の既存臨床文書を自動で FHIR R4 リソースに変換する機能です。AI 支援のテンプレート編集、即時検証、スケーラブルな一括取り込みを組み合わせ、従来数か月かかっていた変換作業を数日〜数日に短縮します。

変更内容・新機能の詳細 ​

主な機能は次のとおりです。- CCDA 2.1 -> FHIR R4 の変換テンプレートを用意し、デフォルトテンプレートで多くのケースをカバーします。- 同期変換 API とコンソールワークフローにより、個別の CCDA ファイルを送信すると数秒で FHIR Bundle を返却し、結果のプレビューと変換品質の対話的検証が可能です。- 一括インポートワークフローはアップロードされた CCDA ファイルを自動検出し、選択中のテンプレートを適用して患者識別子に基づくマッチ／和解（reconciliation）を行い、生成した FHIR リソースを指定の AWS HealthLake データストアへインジェストします。取り込み処理は詳細なログを出力します。- テンプレートのカスタマイズは AI による自然言語操作が可能で、例えば「status が entered-in-error の薬剤を無視する」「procedure の日付を performedPeriod ではなく performedDateTime にマッピングする」といった指示を与えると、AI がテンプレートを自動修正します。もちろんパワーユーザー向けに手動編集（細かなマッピングの調整）も可能で、変更はサンプルファイルで即時テストして反復・公開できます。- すべての機能はコンソールおよびプログラム的な API 経由で利用でき、既存の取り込みパイプラインに統合できます。- プレビューリリースであり、利用条件・機能仕様は将来変更される可能性があります。- 現時点で HealthLake とデータ変換エージェントは以下リージョンで利用可能です: 米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、アジアパシフィック（ムンバイ、シドニー）、ヨーロッパ（ロンドン、アイルランド）。

影響範囲・利用シーン ​

  • 対象ユーザー: 医療機関のデータエンジニア／データ統合チーム、ヘルスケアアプリ開発者、SRE/運用チーム
  • 利用シーン: レガシー CCDA 文書からの長期的患者記録（longitudinal record）作成、集団健康分析（population health analytics）、臨床データ交換のための FHIR 化パイプライン構築
  • 運用効果: 手動マッピングの工数低減と変換スピードの大幅改善により、データ移行や分析プロジェクトの立ち上げが短期間で可能
  • データ品質への影響: AI テンプレートは迅速に初期マッピングを提供するが、識別子の不整合やローカル慣習に対しては手動検証・調整が必要
  • コスト影響: 同期 API 呼び出し、一括インポートによるストレージ・転送・インジェスト料金や、HealthLake の通常利用料金が発生する可能性があるためコスト見積りが必要

技術的な注意点 ​

  • IAM権限: HealthLake データストアの読み書き、インポート操作、S3（アップロード）アクセス、CloudWatch ログ出力、必要に応じて KMS 暗号化キーの使用権限を含む適切な権限が必要です
  • リージョン制限: プレビュー時点での対応リージョンは記事記載のとおり（米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、アジアパシフィック（ムンバイ、シドニー）、ヨーロッパ（ロンドン、アイルランド））。その他リージョンでは未提供の可能性があるため AWS Region Table を確認してください
  • コスト: 変換 API の使用、バッチ取り込みによるデータ転送・ストレージ・インジェスト処理、ログ保管に対する料金が発生します。プレビュー機能は料金体系や無料枠が将来変わる可能性があります
  • コンプライアンス/セキュリティ: AWS HealthLake は HIPAA 対応（HIPAA-eligible）サービスだが、プレビュー機能の利用可否や BAA（Business Associate Agreement）適用範囲については事前確認が必要です。機密 PHI を扱う場合は暗号化（KMS）・アクセス制御・監査ログの設計を行ってください
  • 変換品質: AI ベースのテンプレートは多くのケースを自動化しますが、ローカルの CCDA 仕様差分や施設固有のデータ慣習により誤マッピングが発生するため、サンプル検証とステージングでの検証を必須としてください
  • 識別子マッチング: 患者のマッチ/和解は識別子依存のため、identifier の正規化や重複解消ポリシーの設計が必要です
  • 同期/非同期の特性: 個別ファイルは同期 API で即時変換が可能（数秒）だが、大量ファイルの一括インポートは非同期処理・キューイングが行われるためスループットとエラーハンドリング設計が必要です
  • ログ/監査: 取り込み処理は詳細ログを提供するため、問題発生時のトレースは可能ですが、ログの保持期間とコストを設計に含めてください

参考情報 ​

[Lambda] Accelerate Lambda durable functions development with new Kiro power ​

概要 ​

AWSは、KiroのAIエージェント開発環境向けに「Lambda durable functions Kiro power」を公開しました。ローカル開発環境でAIエージェント支援を受けながら、長時間実行のマルチステップアプリケーションやAIワークフローを高速に構築できます。

変更内容・新機能の詳細 ​

Kiro用のLambda durable functionsパワーは、耐久性のある（durable）関数の開発知見をKiroのエージェント型開発ワークフローに取り込みます。AIエージェントは開発時に関連するガイダンスやベストプラクティスを動的にロードし、再現モデル（replay model）運用、step/wait操作、並列実行（map/parallelパターン）や同時実行、リトライ戦略や補償トランザクションを含むエラー処理パターン、テストパターン、そしてデプロイ（AWS CloudFormation、AWS CDK、AWS SAM）までの一連のフローを支援します。これにより、受注処理パイプライン、人間承認を含むAIエージェントのオーケストレーション、決済調整ワークフローなどの長時間・多段ステップ処理を、ローカルでAIの助けを受けつつ迅速にプロトタイピング／実装できます。Kiro IDEおよびKiroのPowersページからワンクリックでインストール可能で、GitHubとLambdaの開発者ガイドへの参照リンクが提供されています。

影響範囲・利用シーン ​

  • 対象ユーザー: サーバーレス/アプリケーション開発者、AIエージェント開発者、SRE／運用チーム
  • 利用シーン: 長時間実行・マルチステップワークフロー（例：注文処理パイプライン、AIエージェントオーケストレーション、決済調整、人間の承認を挟むワークフロー）の開発・テスト・デプロイ
  • 運用効果: 開発速度の向上（アイデア→動作するdurable functionへの短縮）、ベストプラクティスに基づく堅牢なエラー処理と同時実行管理、テストとデプロイの自動化により運用負荷と障害リスクを低減

技術的な注意点 ​

  • IAM権限: CloudFormation/CDK/SAMでのデプロイやLambda・関連サービスの操作に必要なIAM権限（Lambdaの作成、IAMロールの作成、CloudFormationのスタック操作等）を事前に準備してください
  • リージョン制限: 公開記事ではリージョン固有の制限は明記されていませんが、利用するLambda機能や関連サービス（例：長時間実行を支えるサービス）のリージョン対応を確認してください
  • コスト: 長時間実行・同時実行パターンや関連リソース（Lambda、Step Functions、呼び出す外部API、データストア等）でコストが発生します。開発・テスト時の実行回数や実行時間に注意してください
  • 認証／ローカル設定: KiroエージェントからAWSにデプロイやテスト実行を行う場合、ローカルのAWS認証情報（プロファイル／環境変数）や適切な権限設定が必要です
  • セキュリティ: AIエージェントがコードやデプロイ設定にアクセスするため、機密情報（シークレットやキー）の扱い、最小権限の適用、監査ログの有効化を検討してください
  • 必要なツール: Kiro IDE（該当パワーのインストール機能）、AWS CLIやAWS CDK／AWS SAMの適切なバージョンが必要になる場合があります。GitHubリポジトリや開発者ガイドの前提要件を確認してください

参考情報 ​

[IAM] AWS simplifies IAM role creation and setup in service workflows ​

概要 ​

AWSコンソールのサービスワークフロー内でIAMロールを直接作成・設定できるようになり、別タブでIAMコンソールに移動せずに権限のカスタマイズが可能になりました。まずは米国東部（バージニア北部）リージョンで利用可能です。

変更内容・新機能の詳細 ​

サービスのコンソール操作中にロール設定用のパネルが表示され、デフォルトポリシーの選択または簡易ステートメントビルダーを使ってカスタム権限を作成できます。これにより一時的な認証情報でサービス間の安全な接続を行うIAMロールを、その場で作成・割り当てでき、ハードコーディングされたアクセスキーの回避や手動でIAMコンソールを行き来する手間を削減します。機能はIAMの既存のロール管理機能（信頼ポリシー、インライン/マネージドポリシー、権限境界、タグ付け等）と互換性があり、CloudTrailによる監査ログ等も引き続き記録されます。現在サポートされているサービスには Amazon EC2、AWS Lambda、Amazon EKS、Amazon ECS、AWS Glue、AWS CloudFormation、AWS Database Migration Service、AWS Systems Manager、AWS Secrets Manager、Amazon RDS、AWS IoT Core が含まれ、対応サービス・リージョンは順次拡大予定です。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウドエンジニア、アプリ開発者、DevOps/SRE、運用チーム
  • 利用シーン: サービス作成やデプロイ時に必要なIAMロールをその場で作成・カスタマイズして割り当てする場面（例: Lambda関数、ECSタスク、EKSワークロードの権限設定）
  • 運用効果: コンソール操作の手順短縮、権限設定のミス削減、IAMコンソール間の切替コスト削減により導入・運用の生産性向上
  • 対応サービス: 初期対応は EC2、Lambda、EKS、ECS、Glue、CloudFormation、DMS、Systems Manager、Secrets Manager、RDS、IoT Core（今後拡大予定）
  • リージョン: 現時点では米国東部（北バージニア）リージョンで利用可能。順次他リージョンへ拡張予定

技術的な注意点 ​

  • IAM権限: ロール作成・ポリシー添付には iam:CreateRole、iam:PutRolePolicy、iam:AttachRolePolicy、iam:PassRole などの権限が必要です。事前に管理者や運用ロールで権限を確認してください。
  • リージョン制限: 初期提供は us-east-1（米国東部（バージニア北部））のみ。その他リージョンは順次対応予定のため、利用前に対象リージョンを確認してください。
  • コスト: この機能自体に追加料金は発生しませんが、作成するロールに紐づくサービス利用やデータ転送等は通常の料金が発生します。
  • 監査/ログ: ロール作成・ポリシー変更はCloudTrailに記録されます。自動化や変更管理のために監査ログを確認する運用を推奨します。
  • ポリシー設計上の注意: 簡易ビルダーを使用して作成したポリシーでも最小権限の原則（least privilege）を維持してください。権限境界や条件付きポリシーの利用検討を推奨します。
  • 既存ロールへの影響: コンソールで新規作成・割当が行われるだけで、既存ロールが自動的に上書きされるわけではありません。既存ロールを使い回す場合は明示的に選択・変更してください。
  • サービス対応: 全てのAWSサービスやコンソールフローで即時利用できるわけではありません。個別サービスのユーザーガイドで対応状況を確認してください。

参考情報 ​

[General] Amazon SageMaker HyperPod now provides comprehensive observability for Restricted Instance Groups ​

概要 ​

Amazon SageMaker HyperPodがRestricted Instance Groups (RIG)向けに包括的な可観測性機能を提供開始しました。これにより、Nova Forgeで基盤モデルを学習するチームはGPUやネットワーク、クラスタ状態を単一のダッシュボードで容易に監視・診断できます。

変更内容・新機能の詳細 ​

今回の機能は、Amazon Managed Grafana（事前設定ダッシュボード）とAmazon Managed Service for Prometheusをバックエンドにして、RIGクラスタとそのワークロードに関するメトリクスとログを一元的に可視化します。GPU利用率、NVLink帯域、CPUプレッシャー、FSx for Lustre利用状況、Podのライフサイクルなどが監視可能で、メトリクスはGPU性能、ホスト（OS）レベルの健全性、ネットワークファブリック、Kubernetesオブジェクト状態という4つのエクスポータ群から収集されます。加えて、エポック進捗やステップ単位の学習ログ、パイプラインエラー、Pythonトレースバックなどのキュレートされたログがダッシュボード上で参照でき、学習失敗の素早い原因特定に寄与します。新しいRIGクラスタ作成時は自動で有効化され、既存クラスタにもHyperPodクラスタ管理コンソールから数クリックで有効化できます。機能はSageMaker HyperPod RIGをサポートする全リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: MLエンジニア、データサイエンティスト、SRE/運用チーム
  • 利用シーン: 基盤モデル（Nova Forge等）学習時のGPU/ネットワーク/ストレージ/クラスタ状態の一元監視と障害解析
  • 運用効果: メトリクスとログの手作業での収集・相関が不要になり、学習ジョブ失敗の原因特定やパフォーマンスボトルネックの可視化が迅速化
  • コスト管理: Managed Grafana / Managed Prometheus の課金対象となるため、監視データの保持ポリシーやサンプリング頻度の見直しでコスト最適化が可能
  • 導入負荷低減: 新規クラスタは自動有効化、既存クラスタも数クリックで有効化できるため導入の運用負荷が小さい

技術的な注意点 ​

  • IAM権限: Managed Grafana、Managed Service for Prometheus、CloudWatch Logs、SageMaker HyperPod管理操作に関する適切なIAM権限が必要。ダッシュボード表示用のロール/ユーザー権限も確認してください
  • リージョン制限: SageMaker HyperPod RIGをサポートするリージョンで利用可能。未対応リージョンでは利用不可です
  • コスト: Amazon Managed Grafana と Amazon Managed Service for Prometheus の利用料金（データ取り込み/保存、ダッシュボード利用等）が発生します。またメトリクス収集によるエージェントのCPU/ネットワーク負荷によりインスタンス費用やパフォーマンス影響を評価してください
  • エクスポータとオーバーヘッド: メトリクスは「GPU性能」「ホスト健全性」「ネットワークファブリック」「Kubernetesオブジェクト状態」の4つのエクスポータ群から収集されます（例: DCGM/node exporter/ネットワークエクスポータ/kube-state-metrics 等）。エクスポータの動作によるリソース使用とネットワークトラフィックを考慮してください
  • ログ保持とプライバシー: キュレートされた学習ログやトレースバックがダッシュボードから参照可能になるため、ログの保持期間や機密情報の取り扱い方針を確認してください
  • 有効化手順: 新規RIGクラスタは自動有効化。既存クラスタはHyperPodクラスタ管理コンソールから有効化（数クリック）可能。ロールやセキュリティグループ等の事前設定を確認するとスムーズです

参考情報 ​

[Lightsail] Amazon Lightsail now offers OpenClaw, a private self-hosted AI assistant ​

概要 ​

Amazon Lightsailで、プライベートなセルフホスト型AIアシスタント「OpenClaw」をワンクリックでデプロイできるようになりました。組み込みのセキュリティ機能やHTTPS、スナップショットなど運用に必要な機能が予め構成されています。

変更内容・新機能の詳細 ​

LightsailのOpenClawは、ユーザーのLightsailインスタンス上に自己管理型のAIアシスタントを簡単かつ安全に立ち上げるためのパッケージです。各インスタンスにはセッションを隔離するサンドボックス、ワンクリックで有効化するHTTPS（TLS）アクセス、デバイスペアリングによる認証、継続的な自動スナップショットが組み込まれています。デフォルトのモデルプロバイダーはAmazon Bedrockで、必要に応じて別モデルへ切り替えたり、Slack／Telegram／WhatsApp／Discordと連携させることが可能です。Lightsailは15リージョンで提供されており（例：米国東部(N. Virginia)、米国西部(Oregon)、欧州(Frankfurt)、欧州(London)、アジア太平洋(東京)、アジア太平洋(ジャカルタ)）、コンソールから開始できます。料金や導入手順はLightsailの価格ページとクイックスタートドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者、SRE/運用チーム、中小企業や個人でプライベートAIを素早く立ち上げたいユーザー
  • 利用シーン: 社内向けアシスタント、カスタマーサポートの補助、チャットボットのプロトタイプ、チーム内ツール連携（Slack等）
  • 運用効果: セキュリティ制御と自動バックアップにより導入と運用の工数を削減し、ワンクリックHTTPSやデバイスペアリングで安全なアクセス管理が容易になる
  • 制約・留意点: デフォルトでAmazon Bedrockを利用するため、推論はBedrock側へ送信される点を考慮したデータガバナンスが必要

技術的な注意点 ​

  • IAM権限: Lightsailコンソールの操作権限に加え、Bedrockを利用する場合はBedrockへのアクセス権（適切なIAMポリシー）が必要です。事前に権限を確認してください。
  • リージョン制限: Lightsail OpenClawはLightsailがサポートする15リージョンで提供されていますが、すべてのリージョンで利用可能とは限りません。利用前にコンソールで地域対応状況を確認してください（例：東京・ジャカルタは対応済み）。
  • コスト: Lightsailのインスタンス料金、スナップショット（ストレージ）料金に加え、デフォルトモデルプロバイダーであるAmazon Bedrockの推論利用料が別途発生します。モデル変更や外部連携（Slack等）で追加の通信やAPI費用がかかる場合があります。
  • データ取扱い: OpenClaw自体はLightsail上で動作しますが、モデル推論をBedrockに委託する場合はリクエストデータがBedrock側へ送信されます。データレジデンシー・コンプライアンス要件は設計時に確認してください。
  • ネットワーク/アクセス: ワンクリックHTTPSによりTLSはLightsail側で提供されますが、必要に応じてファイアウォール（Lightsailのネットワーキング設定）やポート制限の確認を推奨します。
  • 連携サービス: Slack/Telegram/WhatsApp/Discordなどと接続する際は各プラットフォームのAPIキーやWebhook設定が必要です。
  • バックアップ: 自動スナップショットで設定や状態を保護しますが、スナップショット保持ポリシーと復元手順を運用ドキュメントに明記してください。

参考情報 ​

[Opensearch Service] Amazon OpenSearch Ingestion now supports Amazon Managed Service for Prometheus as a sink ​

概要 ​

Amazon OpenSearch IngestionがAmazon Managed Service for Prometheus（AMP）を新しいsinkとしてサポートしました。これにより、カスタム転送基盤なしで、ログ／トレースと同じパイプラインインフラでメトリクスのフルマネージド取り込みが可能になります。

変更内容・新機能の詳細 ​

今回のアップデートで、OpenSearch Ingestionのパイプラインから直接Amazon Managed Service for Prometheus（AMP）へメトリクスを書き込めるようになりました。これにより、ログやトレースはAmazon OpenSearch Serviceへ、時系列メトリクスはAMPへ、というように観測データごとに最適な送信先を使い分けられます。OpenSearch Ingestion側の変換・エンリッチ機能を使ってメトリクスを整形・正規化した上でAMPワークスペースへ転送できるため、データ品質や一貫性を保ったままPrometheus互換の時系列ストレージに取り込めます。取り込まれたメトリクスはPrometheus Query Language（PromQL）で解析でき、アラートルールやAmazon Managed Grafanaでの可視化に連携可能です。設定はAWSマネジメントコンソールまたはAWS CLIから、パイプライン設定に新しいAMP sinkを追加するだけで開始できます。この記事のとおり、本機能はOpenSearch Ingestionが利用可能なすべてのリージョンでサポートされています。

影響範囲・利用シーン ​

  • 対象ユーザー: SRE、プラットフォームエンジニア、観測（Observability）担当者
  • 利用シーンまたは効果: ログ/トレースはOpenSearch、時系列メトリクスはAMPへ振り分けることで、それぞれのサービスの得意領域を活かした観測パイプラインを構築可能
  • 運用効果: カスタム転送インフラを不要にし、運用負荷と障害箇所を削減。データ整形を一元化できるためダッシュボードやアラートの信頼性が向上
  • 適用範囲: 既存のOpenSearch Ingestionパイプラインを変更して利用開始可能（コンソール／CLIでsink追加）

技術的な注意点 ​

  • IAM権限: OpenSearch IngestionからAMPへ送信する際に必要なIAM権限（ワークスペースへの書き込み等）を事前に確認・付与してください
  • リージョン制限: 本機能はOpenSearch Ingestionが利用可能なリージョンでサポートされていますが、AMPワークスペースが同リージョンで利用可能かを確認してください
  • コスト: AMPのストレージ・クエリ料金およびOpenSearch Ingestionの処理・転送に伴う料金が発生します。データ取り込み量・保持期間を設計してください
  • データ形式/互換性: OpenSearch IngestionでPrometheus向けに適切なメトリクス名・ラベル設計（ラベルの正規化、型の一貫性）を行う必要があります。変換結果を検証してPromQLで期待通りに検索・集計できるか確認してください
  • 設定/運用: パイプラインのテスト取り込み、エラーハンドリング（リトライ／DLQ相当）やスキーマ変更時の挙動を事前検証してください
  • 監視/可視化: AMPに取り込んだメトリクスはPromQLでクエリ可能です。アラートやGrafanaダッシュボードの設定も合わせて準備してください

参考情報 ​

[Opensearch Service] Amazon OpenSearch Ingestion now supports unified ingestion endpoint for OpenTelemetry data ​

概要 ​

Amazon OpenSearch Ingestion（AOI）が、OpenTelemetryの3種類の観測信号（ログ、メトリクス、トレース）を単一のパイプライン／エンドポイントで受け取れる『統一OpenTelemetry受信エンドポイント』をサポートしました。これにより、複数パイプラインの管理が不要になり、観測データの集約と相関が容易になります。

変更内容・新機能の詳細 ​

従来はログ・メトリクス・トレースそれぞれに対して個別のパイプラインを作成・管理する必要がありましたが、今回の機能追加により1つのパイプラインが任意の組み合わせのOpenTelemetry信号を受け付けられるようになりました。具体的には、パイプライン設定で新しい「統一OpenTelemetryソース（unified OpenTelemetry source）」を選択し、OpenTelemetryクライアントを新しい統一受信エンドポイントに向けることで、同一パイプライン内で複数信号の受信・処理・転送を行えます。これにより、信号間の相関分析がしやすくなり、パイプラインの数や運用負荷、アクセス制御やライフサイクル管理の複雑さを低減できます。導入はAWS Management ConsoleまたはAWS CLIから行え、この記事の時点でAOIが利用可能なすべてのリージョンでサポートされています。段階的導入も容易で、まず1種類の信号で始めて後から別の信号を追加する際にパイプライン再構成が不要な点も特徴です。

影響範囲・利用シーン ​

  • 対象ユーザー: 開発者、SRE/運用チーム、プラットフォームエンジニア、Observability担当者
  • 利用シーン: ログ・メトリクス・トレースを統合した中央集約型観測パイプラインの構築、マイクロサービスの障害相関分析やSLA監視
  • 運用効果: 管理するパイプライン数削減による運用負荷低減、アクセス制御や監視設定の一元化で運用品質向上、段階的なOpenTelemetry導入が可能になり移行コストを低減

技術的な注意点 ​

  • IAM権限: パイプライン作成・更新・削除やソースの利用にはAOI関連のIAM権限が必要です。事前に組織のIAMポリシーで権限を確認してください。
  • リージョン制限: 記事のとおり、AOIが利用可能なリージョンではサポートされていますが、リージョンごとのサービス提供状況は確認してください。
  • コスト: パイプライン数削減により運用インフラコストは下がる可能性がありますが、受信データ量や転送・保管に対するAOIや下流ストレージの課金は従来どおり発生します。データ量と処理（フィルタ/変換）コストを評価してください。
  • 認証・アクセス制御: OpenTelemetryクライアントが統一エンドポイントへ送信する際の認証（エンドポイントのアクセス制御やAWS側の承認設定）を確認してください。クライアント設定（エンドポイントURL）を更新する必要があります。
  • プロトコル互換性: OpenTelemetryの送信方法（OTLPのHTTP/gRPCなど）や受信ポート/プロトコルについて、AOIがサポートするトランスポートを事前に確認してください。
  • データ処理とルーティング: 単一パイプライン内で信号種別ごとの処理（例：異なる受信者へのルーティング、異なる変換/フィルタ）を行う必要がある場合は、パイプライン内でのプロセッサ設定を適切に設計してください。分離が必要な場合は引き続き別パイプラインを使う選択肢もあります。
  • 監視・障害対応: 統一パイプラインに障害が発生すると複数信号に影響するため、パイプラインのヘルス監視とアラート設計を強化することを推奨します。
  • マイグレーション: 既存の個別パイプラインから移行する際は、受信エンドポイントの切替計画、クライアント設定の更新、テストフェーズを設けて段階的に移行してください。

参考情報 ​

AI要約はOpenAI GPT-5-miniによって生成されています。

Copyright © 2026