メインコンテンツへスキップ

【AWSデイリーアップデート 9件】S3 Lifecycleの複製失敗対応、AWS Agent Registryのプレビュー、RDS ProxyのBlue/Greenデプロイ対応など

· loading · loading ·
kiitosu
著者
kiitosu
aws community builder. 画像処理やデバイスドライバ、データ基盤構築からWebバックエンドまで、多様な領域に携わってきました。地図解析や地図アプリケーションの仕組みにも経験があり、幅広い技術を活かした開発に取り組んでいます。休日は草野球とランニングを楽しんでいます。
目次

本日の主なトピック
#

  • Amazon S3 Lifecycle: レプリケーション(複製)に失敗したオブジェクトに対する失効・移行アクションを自動的に一時停止するようになり、データの意図しない損失を防止。
  • AWS Agent Registry: AIエージェントやツールを組織内で集中管理・発見できるカタログ機能がプレビュー公開。MCPサーバーのメタデータ自動取得にも対応。
  • Amazon RDS Proxy: RDS Blue/Green Deployments を正式サポート。切り替え時のDNS伝播待ちを回避し、アプリケーションの回復時間をさらに短縮。
  • Amazon OpenSearch Serverless: Zstandard (zstd) 圧縮に対応し、インデックスサイズを最大32%削減可能に。
  • Amazon Location Service: 等高線の密度調整や3D地形、球体表示などのマップスタイリング機能が大幅に強化。



Amazon S3 Lifecycle、複製に失敗したオブジェクトに対するライフサイクルアクションを一時停止
#

投稿日: 2026年4月9日

何ができるようになったのか
#

Amazon S3 Lifecycleにおいて、レプリケーション(複製)に失敗したオブジェクトに対する「有効期限(失効)」や「ストレージクラスの移行」のアクションが自動的に一時停止されるようになりました。これにより、複製設定や権限のミスでコピーが完了していないデータが、意図せずソースバケットから削除されたり移行されたりすることを防げます。

何が嬉しいのか
#

これまでは、複製に失敗していてもライフサイクルルールの条件を満たせば削除や移行が実行されていました。今回のアップデートにより、複製が成功するまでライフサイクルアクションが保留されるため、データの整合性を維持しつつ安全にライフサイクル管理を行えます。設定ミスを修正した後に S3 Batch Replication などで複製を再試行し、成功すればライフサイクルが自動的に再開されます。

これまでとどう変わるのか
#

  • これまで: レプリケーションステータスが FAILED であっても、ライフサイクルルールに合致すればオブジェクトは削除(期限切れ)または移行されていました。そのため、バックアップ(複製先)が作成されないまま元のデータが失われるリスクがありました。
  • これから: レプリケーションに失敗したオブジェクトは、ライフサイクルアクションが自動的に保留されます。複製が正常に完了した後に、設定されたルールに従って処理されます。

具体的なユースケース
#

  • データ保護: 法令遵守やバックアップ目的で S3 Replication を使用している際に、設定ミスにより複製が滞っている状態でも、元のデータをライフサイクルによる削除から守りたい場合。
  • トラブルシューティング: 複製失敗の原因(IAM権限不足など)を特定し、修正して S3 Batch Replication で再試行するまでの間、データの状態を維持したい場合。

Amazon Location Service、等高線の密度調整や3D地形表示などのマップスタイリング機能を強化
#

投稿日: 2026年4月2日

何ができるようになったのか
#

Amazon Location Serviceにおいて、地図の視覚的な表現をより細かくカスタマイズできる新しいスタイリング機能が追加されました。等高線の密度の選択、渋滞箇所のみを強調するトラフィック表示、3D地形(Terrain)や球体(Globe)表示、そして既存機能の追加マップスタイル(モノクロ、ハイブリッド、サテライトなど)への対応が含まれます。

何が嬉しいのか
#

開発者は用途に合わせて最適な地図を提供できるようになります。例えば、標高差を強調したい場合は等高線の密度を高め、交通状況を簡潔に伝えたい場合は「渋滞のみモード」を利用できます。また、3D地形や大気エフェクト付きのGlobe表示により、より没入感のあるユーザー体験を構築できます。

これまでとどう変わるのか
#

  • これまで: 地形の詳細度や交通状況の表示、3D表現のカスタマイズ性が限定的でした。
  • これから: 等高線の密度を3段階(低、中、高)から選択可能になり、3D TerrainやGlobe Viewを利用した高度な可視化が可能になります。また、ダーク/ライトモード、公共交通機関やトラック向けの地図スタイルがより多くのベースマップで利用できるようになりました。

具体的なユースケース
#

  • アウトドア・登山アプリ: 3D地形や等高線の「高」密度設定を利用して、複雑な地形を分かりやすく表示する。
  • 物流・配送管理: 「渋滞のみモード」を利用して、交通インシデントが発生しているエリアのみをドライバーや管理者に際立たせて表示する。

Amazon OpenSearch Serverless、Zstandard(zstd)によるインデックス圧縮に対応
#

投稿日: 2026年4月9日

何ができるようになったのか
#

Amazon OpenSearch Serverlessにおいて、インデックスの保存時に Zstandard (zstd) コーデックによる圧縮が利用可能になりました。これにより、デフォルトの LZ4 コーデックと比較してインデックスサイズを最大 32% 削減でき、マネージドストレージのコストを抑えることができます。

何が嬉しいのか
#

大規模なログ分析、オブザーバビリティ、タイムシリーズ(時系列)データなど、データ量が多いワークロードにおいて、ストレージ効率の向上によるコスト削減が期待できます。圧縮レベルを調整(レベル1からレベル6など)することで、書き込み(インデキシング)速度とストレージ削減量のバランスを細かくチューニングできます。

これまでとどう変わるのか
#

  • これまで: デフォルトの LZ4 コーデックが使用されており、圧縮率のカスタマイズ性は限られていました。
  • これから: Zstandard コーデックの zstd および zstd_no_dict モードを選択できるようになりました。
  • パフォーマンス: 低い圧縮レベル(レベル1など)では、インデキシングやクエリのレイテンシへの影響を最小限に抑えつつストレージを削減でき、高いレベル(レベル6など)では、書き込み速度と引き換えに圧縮率を最大化できます。

具体的なユースケース
#

  • 長期ログ保存: 大規模なシステムログやアクセスログを長期間保持する場合のストレージコスト削減。
  • 高頻度データ処理: データの取り込み(Ingest)量が多いワークロードにおいて、データの増加スピードに応じたコスト効率の向上。

AWS Agent Registry、AIエージェントの集中管理と発見を可能にする新機能がプレビュー公開
#

投稿日: 2026年4月9日

何ができるようになったのか
#

Amazon Bedrock AgentCore において、組織内のAIエージェント、ツール、スキル、MCP (Model Context Protocol) サーバーなどのリソースを一括して登録・管理できる「AWS Agent Registry」のプレビュー公開が開始されました。管理者はリソースの承認フローを設定でき、開発者は自然言語(セマンティック検索)やキーワードを使って既存のリソースを迅速に見つけることができます。

何が嬉しいのか
#

組織全体でAIリソースの可視性が高まり、チーム間での機能の重複開発を防げます。また、IAMやOAuth(カスタムJWT)によるアクセス制御、CloudTrailによる監査ログの記録により、ガバナンスを効かせたAI活用が可能になります。さらに、MCPサーバーやエージェントエンドポイントからメタデータを自動取得する「URLベースの発見機能」も備えています。

これまでとどう変わるのか
#

  • これまで: 各チームが独自にエージェントやツールを開発しており、組織全体でどのようなリソースが存在するかを把握・共有する標準的な仕組みが不足していました。
  • これから: 集中管理カタログ(Registry)を通じて、既存のエージェントやスキルを発見・再利用しやすくなります。IDEから直接Registryをクエリして呼び出すことも可能になります。

具体的なユースケース
#

  • 全社的なAI資産管理: 異なる部署が作成した便利なAIエージェントや共通ツールを一つのカタログにまとめ、社内共有を促進する。
  • ガバナンスの強化: 開発者が作成したエージェントを本番環境や社内向けに公開する前に、管理者が内容をレビューして承認するワークフローを確立する。

AWS Marketplace、製品や価格情報へのプログラムアクセスを可能にする「Discovery API」を発表
#

投稿日: 2026年4月9日

何ができるようになったのか
#

AWS Marketplaceにおいて、カタログデータの取得を自動化できる「Discovery API」が提供されました。これにより、SaaS、AIエージェント、AMI、コンテナ、機械学習モデルなどの製品説明、カテゴリー、価格情報(パブリックおよびプライベートオファー)、提供条件などにプログラムから直接アクセスできるようになります。

何が嬉しいのか
#

買い手(バイヤー)は、社内ポータルや調達ツールにAWS Marketplaceの最新価格や条件を埋め込むことができ、ベンダー評価や購買ワークフローを効率化できます。売り手(セラー)やパートナーは、自社のWebサイトやストアフロントに製品リストや価格情報を直接表示させ、顧客がマーケットプレイスに移動することなく検討・購入を進められるシームレスな体験を構築できます。

これまでとどう変わるのか
#

  • これまで: 製品や価格情報を取得するには、主に AWS Marketplace コンソールの画面上での操作や限定的な方法が必要でした。
  • これから: AWS SDK を通じてプログラムからカタログ情報を取得可能になり、独自のアプリケーションやワークフローへの統合が容易になります。

具体的なユースケース
#

  • 社内調達ポータルの統合: 自社の社内システム上で、AWS Marketplaceで利用可能なソフトウェアの比較や価格確認を行えるようにする。
  • パートナー向けストアフロントの構築: ソフトウェア販売代理店が自社サイト内にマーケットプレイス製品のカタログ機能を構築し、顧客が使い慣れたUIで製品を探せるようにする。

Amazon Bedrock Data Automation、専門用語やブランド名の認識を向上させるカスタムボキャブラリをサポート
#

投稿日: 2026年4月3日

何ができるようになったのか
#

Amazon Bedrock Data Automation (BDA) において、特定の業界用語や専門用語の認識精度を向上させる「カスタムボキャブラリ(Custom Vocabulary)」機能が追加されました。オーディオやビデオコンテンツの処理時に、ブランド名、略語、技術用語、医療用語などのリストを提供することで、それらを正確に認識・抽出できるようになります。日本語を含む11言語に対応しており、追加料金なしで利用可能です。

何が嬉しいのか
#

ヘルスケア、法務、金融サービスなど、一般的な音声認識では誤認識されやすい専門用語を多用する分野において、書き起こしや分析の精度が大幅に向上します。また、認識された用語を特定の形式(例: 「electrocardiogram」を「ECG」と表示)で出力する「表示形式の指定」も可能です。

これまでとどう変わるのか
#

  • これまで: BDA の標準的な音声認識モデルを使用しており、特定の業界特有の用語や最新の固有名詞については認識が不安定な場合がありました。
  • これから: ユーザーが独自の単語リスト(Data Automation Library)を定義できるようになり、コンテキストに合わせた高精度なデータ抽出が可能になります。

具体的なユースケース
#

  • 医療分野の音声分析: 患者と医師の会話に含まれる特定の病名や薬剤名を、カスタムボキャブラリとして登録して正確に記録する。
  • コンタクトセンターの分析: 業界特有の略語や製品名を正しく書き起こし、顧客対応の傾向分析をより正確に行う。

Amazon EC2 Capacity Manager、タグベースのディメンションに対応し分析の柔軟性を向上
#

投稿日: 2026年4月9日

何ができるようになったのか
#

Amazon EC2 Capacity Managerにおいて、リソースに付与されたタグをディメンション(切り口)として利用可能になりました。これにより、オンデマンドインスタンス、スポットインスタンス、キャパシティ予約などの使用状況を、環境(Environment)やチーム(Team)といった独自のタグでグループ化・フィルタリングして分析できるようになります。

何が嬉しいのか
#

組織内の複数のチームやプロジェクトにまたがるEC2リソースの利用状況を、タグを活用してより詳細に、かつ実態に即した形で把握できます。最大5つのカスタムタグを有効化でき、既存のディメンション(リージョン、インスタンスタイプなど)と組み合わせて使用可能です。また、S3へのデータエクスポート時にタグ情報を追加の列として出力することも可能になります。

これまでとどう変わるのか
#

  • これまで: キャパシティ分析は、リージョンやインスタンスタイプなどの組み込みディメンションに限定されていました。
  • これから: カスタムタグキー(例: cost-center)を有効化し、それに基づいた詳細な分析が可能になります。また、新しく「アカウント名」も組み込みディメンションとして追加されました。

具体的なユースケース
#

  • コスト・リソース配分の最適化: 特定の「プロジェクト」タグが付いたインスタンスの使用状況のみを抽出し、そのプロジェクトにおけるリソース消費量を正確に把握する。
  • 大規模環境の管理: 「開発環境」や「本番環境」といったタグでリソースを分類し、環境ごとのキャパシティ充足度を監視する。

Amazon OpenSearch Service、Managed Prometheus と AIエージェントのトレーシング機能を統合し、オブザーバビリティを強化
#

投稿日: 2026年4月9日

何ができるようになったのか
#

Amazon OpenSearch Service において、メトリクス、ログ、トレースを一箇所で統合して管理できるオブザーバビリティ(可観測性)機能が大幅に強化されました。Amazon Managed Service for Prometheus とのネイティブ統合により、OpenSearch の画面上で PromQL を使ってメトリクスを直接クエリできるようになります。また、OpenTelemetry のセマンティック・コンベンションに基づいた AIエージェント(LLMエージェントなど)のトレーシングもサポートされました。

何が嬉しいのか
#

複数のツールを使い分ける「コンテキスト・スイッチ」やデータの重複保存によるコストを削減し、単一のインターフェースでシステム全体の状況を把握できます。例えば、遅延が発生しているトレースから関連するログを特定し、同時に Prometheus のメトリクスを重ねて分析するといった一連のトラブルシューティングを効率的に行えます。

これまでとどう変わるのか
#

  • これまで: メトリクス監視には Prometheus、ログ分析には OpenSearch など、ツールが分散していることが多く、分析の際にツール間の行き来が必要でした。
  • これから: OpenSearch UI の「Observability」ワークスペース上で、Prometheus のメトリクス、REDメトリクス(レート、エラー、期間)、および AIエージェントの実行トレースをシームレスに横断して分析できます。

具体的なユースケース
#

  • アプリケーション・パフォーマンス監視: 特定のリクエストにおけるエラーをトレースで特定し、その時点のサーバーメトリクス(CPU使用率など)を Prometheus から取得して原因を調査する。
  • AIエージェントのデバッグ: LLM(大規模言語モデル)を使用したアプリケーションにおいて、エージェントの意思決定プロセスや実行フローを詳細にトレースする。

Amazon RDS Blue/Green Deployments、RDS Proxy をサポートし切り替え時間をさらに短縮
#

投稿日: 2026年4月9日

何ができるようになったのか
#

Amazon RDS のマネージドな移行環境である「Blue/Green Deployments」において、Amazon RDS Proxy が正式にサポートされました。Blue/Green デプロイメントの「切り替え(Switchover)」時に、RDS Proxy が自動的にターゲットデータベースを監視し、新しい本番環境(Green)への接続を迅速にリダイレクトします。

何が嬉しいのか
#

DNSの伝播待ちを回避できるため、アプリケーションの回復時間がさらに短縮されます。RDS Proxy を使用している場合、開発者はアプリケーション側のドライバ設定やエンドポイント情報を変更することなく、データベースのアップグレードやパッチ適用をより安全かつ迅速に完了できます。

これまでとどう変わるのか
#

  • これまで: Blue/Green デプロイメントの切り替え後、アプリケーションが新しいデータベースエンドポイント(Green)を認識するまでに、DNSの名前解決などでわずかなタイムラグが生じる場合がありました。
  • これから: RDS Proxy が環境の切り替えを能動的に検知し、即座に接続を切り替えるため、よりシームレスな移行が可能になります。Aurora (MySQL/PostgreSQL) および RDS (MySQL/PostgreSQL/MariaDB) で利用可能です。

具体的なユースケース
#

  • 高可用性が必要なアプリケーションのアップグレード: データベースのエンジンバージョンアップやインスタンスクラスの変更を、ダウンタイムを最小限に抑えながら実行したい場合。
  • メンテナンス時の安全な切り替え: 新しい設定のテスト(Green環境)から本番への切り替えを、RDS Proxy を活用して迅速かつ安定的に行いたい場合。
Reply by Email

関連記事

【AWSデイリーアップデート 9件】Amazon Bedrock AgentCore の OS 操作対応や EKS ウォームプール対応など多岐にわたる更新
· loading · loading
【AWSデイリーアップデート 13件】S3 Filesの発表、ACM検索対応、Amazon Q連携Cost Explorerなど
· loading · loading
【AWSデイリーアップデート 14件】CloudWatch OTel ネイティブ対応や ECS Managed Daemons など
· loading · loading