2026/9/10 9:00:00 ~ 2026/9/11 9:00:00 (JST)

最近の発表

AWS Lambda recursive loop detection is now available in Europe Sovereign Cloud

AWS Lambda 再帰ループ検出が、ヨーロッパソブリンクラウドで実行される関数でサポートされるようになりました。再帰ループ検出は、Lambda 関数と他のサポート対象サービス間の再帰呼び出しを自動的に検出して停止し、意図しない再帰ループによる予期しない請求を防ぎます。 \n お客様は Amazon S3、Amazon SQS、Amazon SNS などのイベントソースを使用して、Lambda 関数をトリガーするイベント駆動型アプリケーションを構築します。設定ミスやコード欠陥により、Lambda 関数をトリガーしたのと同じソースにイベントが送り返され、再帰ループや意図しない使用が発生する可能性があります。このようなループが検出されると、再帰ループ検出により自動的にイベントの処理が停止され、トラブルシューティングの手順が記載された AWS Health Dashboard 通知が送信されます。

サポートされている SDK バージョンを使用する Lambda 関数では、再帰ループ検出がデフォルトで有効になっています。関数が意図的に再帰ループを使用している場合は、PutFunctionRecursionConfig API を使用して Lambda 関数の再帰ループ検出を無効にすることができます。

再帰ループ検出について詳しくは、Lambda ドキュメントをご覧ください。

AWS Transform for .NET now generates unit tests for modernized code

本日、AWS は AWS Transform for .NET がモダナイズしたコードの単体テストを自動的に生成できることを発表しました。AWS Transform を有効にすると、ビジネスロジックやコントローラーなど、変換後の.NET アプリケーション内のテスト可能なクラスを対象とした単体テストが生成され、移行を実行する同じジョブの一部として、最新化されたコードに対するテストセーフティネットを自動化できます。\n .NET Framework アプリケーションを最新の .NET にモダナイズすると、変換されたビルド可能なコードベースが生成されますが、これまで、チームはそのモダナイズされたコードのテストカバレッジを手作業で作成する必要がありました。今回のリリースにより、AWS Transform は標準の.NET 評価と並行してアプリケーションのテスト容易性を評価し、どのクラスとメソッドを対象とするかを計画し、対応する単体テストコードを生成するので、すでに実施されているテストで移行を完了できます。ユニットテストの生成はオプトインです。ジョブの開始時または変換の完了後に有効にできます。

.NET 用 AWS Transform のユニットテスト生成は、Visual Studio エクステンション用 AWS ツールキットでサポートされています。.NET 用 AWS Transform がサポートされているすべての AWS リージョンで利用できます。まず、Visual Studio の AWS Transform for .NET を使用して.NET トランスフォームを実行し、ユニットテストを生成することを選択してください。詳細については、『AWS Transform ユーザーガイド』の「IDE での.NET のモダナイゼーション」を参照してください。

Amazon API Gateway now supports 1 MB execution logs with configurable delivery destinations

Amazon API Gateway は、REST API 実行ログの設定可能な配信先とより大きなログイベントをサポートするようになりました。以前は、実行ログは API ゲートウェイが管理する 1 つの CloudWatch Logs ロググループに配信され、ログイベントは 1 KB に切り捨てられていたため、リクエストとレスポンスのデータが見えにくかったです。\n 最大 1 MB の実行ログをお客様自身の Amazon CloudWatch ログロググループ、Amazon S3 バケット、または Amazon Data Firehose ストリームにルーティングし、複数の宛先に同時に配信できるようになりました。たとえば、実行ログを Apache Parquet 形式で Amazon S3 にルーティングすると、Amazon Athena でコスト効率の高い長期保存と分析を行うと同時に、構造化された JSON ログを CloudWatch ログに配信してリアルタイムのアラートを生成できます。 この機能は、AWS GovCloud (米国) リージョンを含め、API ゲートウェイ REST API が利用可能なすべての AWS リージョンで利用できます。この機能を通じて配信される実行ログは、自動販売のログ料金で請求されます。料金の詳細については、Amazon CloudWatch 料金表を参照してください。API ゲートウェイコンソール、AWS CLI、または AWS CloudFormation を使用して配信を設定できます。開始するには、Amazon API Gateway のドキュメントと AWS ブログ投稿を参照してください。

AWS Lambda durable functions integrates with Pydantic AI

本日、AWS Lambda 耐久性関数が Python で AI エージェントを構築するためのオープンソースフレームワークである Pydantic AI との統合を発表しました。AWS Lambda の耐久性関数は Pydantic AI エージェントの実行中の進行状況を保存するため、タイムアウトなどの中断が発生すると、エージェントは最初からやり直すのではなく、最後に完了したステップから再開します。チェックポイントを記述してロジックを自分で再試行しなくても、エージェントは耐障害性を得ることができます。\n この統合により、エージェントが行う各モデルとツールの呼び出しは永続的な実行ステップになるため、実行が中断されても、すでに完了した呼び出しが繰り返されることはありません。これは、一連のモデル呼び出しで一連の文書をレビューしたり、多数のソースにわたってトピックを調査したりする場合など、繰り返し作業にコストがかかる場合に重要です。最初からやり直すには、同じ作業を行うためのトークンに対して再度支払いが必要になります。また、顧客に 2 回請求するといった、実行再開時の望ましくない副次的影響を回避するのにも役立ちます。エージェントは AWS Lambda 上で実行されるため、サーバーを管理する必要はなく、使用したコンピューティング分のみを支払います。

このインテグレーションは、どの Python AWS Lambda 耐久性関数でも使用できます。AWS Lambda 耐久性関数が利用できるすべての AWS リージョンで利用できます。開始するには、Pydantic AI をインストールし、その AWS Lambda 耐久性ページに従ってください。統合の詳細は、耐久実行SDKリファレンスにも記載されています。AWS Lambda 耐久性関数の詳細については、開発者ガイドと AWS Lambda 製品ページを参照してください。

Amazon MQ now supports RabbitMQ 4.3

Amazon MQ は RabbitMQ バージョン 4.3 をサポートするようになりました。このバージョンでは、コンパクション、優先度レベルの向上、ネイティブ遅延再試行、グレースフルコンシューマータイムアウトなどのクォーラムキュー機能の強化が追加されています。RabbitMQ 4.3 には、メモリ管理に関するさまざまなバグ修正とパフォーマンスの向上も含まれています。\n RabbitMQ 4.3 のクォーラムキューでは、キューのディスク使用量を減らすために圧縮が実行され、以前の RabbitMQ バージョンでサポートされていた相対的な 2 つの優先レベルと比較して、32 の厳密な優先レベルがネイティブサポートされています。クォーラムキューは、失敗したメッセージを自動的に脇に置き、設定したクールダウン遅延後に配信を再試行できるようになりました。コンシューマータイムアウトはグローバルプロトコルチャネルからクォーラムキューに移行し、プロトコル固有に設定できるようになりました。コンシューマータイムアウトと遅延リトライはどちらも RabbitMQ Policies で設定および管理できます。一時的な非排他的キュー、グローバル QoS、クラシックキュー v1 ストレージは RabbitMQ 4.3 ではサポートされなくなりました。コンシューマータイムアウトはクラシックキューにも適用されません。

Amazon MQ で RabbitMQ 4.3 を使い始めるには、AWS マネジメントコンソール、AWS CLI、または AWS SDK から m7g インスタンスタイプを使用して新しいブローカーを作成するときに RabbitMQ 4.3 を選択するだけです。Amazon MQ では RabbitMQ 4.3 ブローカーのパッチバージョンアップグレードが自動的に管理されるため、指定する必要があるのはメジャー.マイナーバージョンのみです。RabbitMQ 4.3 の変更点の詳細については、Amazon MQ リリースノートと Amazon MQ 開発者ガイドを参照してください。このバージョンは、Amazon MQ m7g タイプのインスタンスが現在利用できるすべてのリージョンで利用できます。

Announcing second-generation single-rack AWS Outposts

本日、AWSは、第2世代のシングルラックAWS Outpostsの一般提供を発表しました。これは、コンピューティング、ストレージ、ネットワーキングを1つのコンパクトなユニットに統合する自己完結型の42Uラックで、低レイテンシー、ローカルデータ処理、およびスペースと電力に制約のある場所でのデータ常駐を必要とするワークロード向けに構築されています。シングルラックのアウトポストは、最大 2,688 個の vCPU と 100 TB の Amazon エラスティック・ブロック・ストア (Amazon EBS) ストレージを提供します。さらに、マルチラックアウトポストと同様に、シングルラックアウトポストは、汎用（M7i、M8i）、コンピューティング最適化（C7i、C8i）、メモリ最適化（R7i、R8i）、およびアウトポスト高速ネットワーク（BMN-Sf2e、BMN-CX2、BMN-CX3a）インスタンスなど、最新のx86搭載EC2インスタンスをサポートします。\n 製造業、ゲーム、その他の業種など、ラックスペースが限られている場所で事業を行う組織の場合、シングルラックの Outposts は最新の AWS コンピューティング、ストレージ、ネットワーキング機能をオンプレミスで提供し、お客様が現在利用可能なスペースと電力を活用しながらモダナイズへの直接的な道筋を提供します。シングルラックとマルチラックのOutpostsは、AWSリージョンとオンプレミスロケーション全体で同じ AWS API、管理コンソール、自動化、ガバナンスポリシー、およびセキュリティコントロールを使用して一貫したエクスペリエンスをお客様に提供します。

Outposts ラックがサポートされている AWS リージョンと国/地域の最新リストについては、Outposts ラックに関するよくある質問ページをご覧ください。開始するには、AWS Outposts コンソールを開いてください。

Amazon OpenSearch Serverless is now available on v0 by Vercel

Vercel による Amazon OpenSearch Serverless on v0 を使用すると、フルスタックの検索および AI アプリケーションを数分で構築できます。このプラットフォームは AI 搭載プラットフォームで、アイデアを本番環境ですぐに使えるウェブアプリケーションに変換できます。OpenSearch Serverless では、インフラストラクチャの管理が不要になり、必要に応じて容量を自動的にスケールアップ/スケールダウンできるため、クラスターの管理ではなく構築に集中できます。今回のローンチにより、自然言語プロンプトを使用して OpenSearch Serverless を搭載したアプリケーションを構築できます。これにより、v0 インターフェースから離れることなく、Retrieval-Augmented Generation (RAG) ワークロードの全文検索とベクター検索が可能になります。\n 始めるには、v0 の自然言語プロンプトを使用して構築したいものを記述するか、v0 の OpenSearch Serverless にアクセスして Amazon OpenSearch Serverless があらかじめ選択されている状態から始めてください。v0 は完全なフルスタックアプリケーションを生成し、Amazon OpenSearch Serverless コレクションを自動的にプロビジョニングし、データをコレクションにインデックスし、Amazon OpenSearch Serverless エンドポイントを使用して検索クエリを処理します。v0 は必要な環境変数と構成を処理し、プロバイダーをロードします。推奨に従ったコードを生成するための特定のエージェントスキルパターン。v0 に新しい AWS アカウントで Amazon OpenSearch サーバーレスリソースをプロビジョニングするように求めることも、既存の AWS アカウントにリンクすることもできます。

Amazon OpenSearch Serverless で v0 の Vercel アプリを作成できます。米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、米国西部 (オレゴン)、米国西部 (北カリフォルニア)、カナダ (中部)、南米 (サンパウロ)、ヨーロッパ (アイルランド)、ヨーロッパ (ロンドン)、ヨーロッパ (パリ)、ヨーロッパ (フランクフルト)、ヨーロッパ (ストックホルム)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、およびアジアパシフィック (大阪)詳細については、Vercel の発表を確認するか、Amazon OpenSearch サーバーレスのドキュメントをご覧ください。

Amazon ECS expands IAM condition key support for RunTask and StartTask APIs

アマゾンエラスティックコンテナサービス (Amazon ECS) は、RunTask API と StartTask API の CPU リソースとメモリリソースの IAM 条件キーをサポートするようになりました。管理者はこれらのキーを使用して、ECS タスクを起動するあらゆる方法で CPU とメモリの制限を一貫して適用できます。これにより、組織は予期せぬコスト超過を防ぎ、ワークロードをリソースポリシーに沿った状態に保つことができます。\n 以前は、ecs: task-cpu と ecs: task-memory の条件キーは RegisterTaskDefinition、CreateService、およびUpdateService API でのみ使用できました。これらの条件キーは RunTask API と StartTask API で拡張されるようになりました。これで、これらの条件キーを参照する IAM ポリシーは、RunTask や StartTask を通じてタスクを起動したときにも評価されるようになりました。これにより、管理者は ECS 環境全体でのリソース割り当てを制御する単一の統一されたメカニズムを利用できるようになりました。

この機能強化は、Amazon ECS が利用可能なすべての AWS リージョンで、追加費用なしで利用できます。Amazon ECS での条件キーの使用の詳細については、ドキュメントを参照してください。

Amazon Redshift RG instances now available in Europe (Zurich) Region

AWS Graviton プロセッサを搭載した Amazon Redshift RG インスタンスが AWS ヨーロッパ (チューリッヒ) リージョンで利用できるようになりました。RG インスタンスはパフォーマンスが向上し、データウェアハウスとデータレイクのワークロードを前世代の RA3 インスタンスの最大 2.4 倍の速度で実行でき、vCPU あたりの価格も 30% 低く抑えられます。RG インスタンスには、クラスターノード上の Apache Iceberg と Parquet のデータを処理する Redshift のカスタムビルドのベクトル化されたデータレイククエリエンジンが含まれており、単一のエンジンを使用してデータウェアハウスとデータレイク全体で SQL 分析を実行できます。\n RG インスタンスには、rg.large、rg.xlarge、rg.4xlarge、rg.12xlarge の 4 つのインスタンスサイズがあります。既存の RA3 クラスターをお持ちのお客様は、スナップショットと復元、Elastic Resize、またはクラシックリサイズを使用して RG にアップグレードできます。RG インスタンスには、オンデマンド、1 年および 3 年のリザーブドインスタンスの、全前払い、一部前払い、前払いなしの支払いオプションなど、柔軟な料金オプションが用意されています。料金の詳細については、Amazon Redshift の料金表ページをご覧ください。 開始するには、以下のリソースを参照してください。

Amazon Redshift RG インスタンスドキュメンテーション

RA3 から RG へのアップグレードガイド

Amazon Redshift 料金ページ

Amazon CloudWatch now supports network health indicator for TGW inter-Region peering using synthetic monitors

Amazon CloudWatch ネットワークモニタリングの合成モニターを使用すると、AWS Transit Gateway のリージョン間ピアリング接続を経由するパス上のネットワークパフォーマンスの問題が、AWS ネットワークが原因であるかどうかを判断できるようになりました。これにより、ネットワーク事業者とアプリケーション開発者は、これらの経路の劣化の原因を特定するために費やす時間を短縮できます。\n 以前は、合成モニターの場合、ネットワークヘルスインジケーター (NHI) は AWS Direct Connect 経由で接続するパスのみを対象としていました。今回のリリースでは、Synthetic モニターが Transit Gateway のリージョン間ピアリングを介して、ピアリングされたリージョンの宛先に到達するパスまで拡張しました。これらのパスの場合、インジケーターはトランジットゲートウェイピアリング接続までの AWS ネットワークパスの状態を反映し、Amazon CloudWatch アカウントに公開されるので、ダッシュボードを作成したりアラームを設定したりできます。

AWS ワークロードのネットワークモニタリングを利用できる AWS リージョンの全リストについては、リージョンリストをご覧ください。詳細については、Amazon CloudWatch ネットワークモニタリングのドキュメントをご覧ください。

AWS Elemental Inference now generates contextual metadata from live video in real time

AWS Elemental Inference は、カスタム機械学習インフラストラクチャなしで AI を使用してシーンレベルのインテリジェンスを生成することで、ライブ動画ストリームからコンテキストメタデータをリアルタイムで生成できるようになりました。この新機能は、ライブビデオをエンコードと並行して分析し、インタラクティブ広告局 (IAB) のコンテンツ分類カテゴリ、グローバルアライアンスフォーレスポンシブルメディア (GARM) ブランド適合性シグナル、検出されたオブジェクトとアクション、ショットレベルとシーンレベルの説明を抽出します。放送局とコンテンツプラットフォームは、サーバーレスのフルマネージド AI を使用して、コンテクストに基づく広告の意思決定、メディアアセットのエンリッチメント、コンテンツ発見のワークフローを強化できるようになりました。\n コンテキスト広告の場合、AWS Elemental MediaLive は要素推論フィード ID をライブストリームの (ケーブル通信技術者協会) SCTE-35 広告マーカーに埋め込みます。広告が終わるたびに、AWS Elemental MediaTailor は収益化関数を使用してそのフィード ID のシーンレベルのシグナルを取得し、それを広告サーバーが期待するターゲティングパラメータに変換します。これにより、カスタム統合作業なしでコンテキストに応じた広告の意思決定が可能になり、状況に応じたディールキュレーションやブランド適合性スコアなどのユースケースがサポートされるため、パブリッシャーの収益化成果が向上します。メディアアセットの管理、オブジェクトやアクションの検出、ショットやシーンレベルの説明では、すべてのシーンとショットについて構造化されたメタデータを自動的に生成し、より充実したアーカイブを構築して、コンテキストに応じたコンテンツの発見、支援付き編集ワークフロー、パーソナライズされたコンテンツの推奨などを手動でロギングしたりポストプロダクションのメタデータを入力したりする必要がありません。

コンテキストメタデータは、AWS Elemental Inference が利用できるすべての AWS リージョンの AWS Elemental MediaLive コンソールで、本日ご利用いただけるようになりました。

AWS Elemental MediaTailor now offers Yield Optimization to automatically fill ad breaks with Amazon Ads demand

AWS Elemental MediaTailor では、ライブストリームのサーバー側広告挿入 (SSAI) 中に Amazon 広告の需要に応じて未使用の広告インベントリを自動的に収益化する新機能である利回り最適化が提供されるようになりました。Amazon Publisher Services (APS) ストリーミングテレビ番組のパブリッシャーのみが利用できる利回りの最適化は、追加のインフラストラクチャを必要とせずに、追加費用なしで広告ブレイクを収益化されたインプレッションに変えます。\n 広告は視聴者に届く前にストリームに直接埋め込まれるため、どのデバイスでもシームレスに再生されます。主なハイライト:

-規模に合わせた設計：収益の最適化は、プロリーグ選手権などの大規模なライブイベント向けに設計されており、レイテンシーが低く応答時間が短いため、視聴者数のピーク時に広告が最大化されます。

-ブランドセーフ:同じ広告ブレーク内での競合を避けるため、需要はカテゴリ別にフィルタリングされます。パブリッシャーは独自の最低価格とカテゴリルールを設定して、ストリームに掲載する広告を完全に管理できるようにしています。

-簡単に有効化できる:MediaTailor API またはコンソールから収益の最適化を設定できます。追加のインフラストラクチャーやクライアント側の変更は必要ありません。

-パフォーマンスの可視性:Amazon CloudWatch の MediaTailor メトリクスを使用して、広告フィルレートの向上をモニタリングできます。APS パブリッシャーポータルで収益と収益を追跡できます。

AWS Elemental MediaTailor 利回り最適化は、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (ハイデラバード、マレーシア、メルボルン、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、パリ、ストック) など、MediaTailor が利用可能なすべての AWS リージョンで追加料金なしで利用できます。ホルム）、中東（UAE）、南米（サンパウロ）。詳細については、AWS Elemental MediaTailor のドキュメントをご覧ください。

AWS Elemental MediaLive adds support for A/B forensic watermarking

AWS Elemental MediaLive が A/B フォレンジックウォーターマーキングをサポートするようになり、コンテンツ所有者はライブ動画コンテンツの不正再配信のソースを追跡できるようになりました。1 つの MediaLive チャネルから 2 つの同期出力バリアントが生成され、それぞれに視覚的に透明なウォーターマークが付いており、再エンコードや画面キャプチャを行っても透かしが残ります。ダウンストリームのパッケージングと CDN インフラストラクチャは、これらのバリアントをセッションごとの固有のシーケンスにまとめ、リークされたコンテンツの出所を特定します。\n フォレンジックウォーターマーキングは、DASH 業界フォーラム (DASH-IF) のA/B ウォーターマーキング仕様 (欧州電気通信標準化機構 (ETSI) TS 104 002) に準拠しており、標準に準拠したパッケージャーや CDN インフラストラクチャとの相互運用性を確保しています。お客様は、MediaLive API またはコンソールを使用して、Common Media Application Format (CMAF) インジェスト出力グループのウォーターマークを設定できます。MediaLive は、CMAF インジェストを介して AWS Elemental MediaPackage またはサードパーティのパッケージャーにウォーターマーク付き A および B バリアントを配信し、Amazon CloudFront を含む互換性のある CDN インフラストラクチャを通じてセッションごとのダウンストリームウォーターマークアセンブリを可能にします。

詳細については、AWS Elemental MediaLive ユーザーガイドをご覧ください。

A/B フォレンジックウォーターマーキングは、AWS Elemental MediaLive が利用できるすべての AWS リージョンでご利用いただけます。

AWS Elemental MediaTailor now supports Low-Latency HLS ad insertion

AWS Elemental MediaTailor は、HLS インタースティシャルを使用した低レイテンシー HTTP ライブストリーミング (LL-HLS) 広告挿入をサポートするようになりました。MediaTailor は、ライブストリーム、リニアチャネル、ビデオオンデマンドコンテンツを収益化する動画プロバイダー向けのチャンネルアセンブリおよびパーソナライズされた広告挿入サービスです。今回のローンチにより、動画プロバイダーは、視聴者が期待する低レイテンシーを維持しながら、低レイテンシーのライブストリームに広告を挿入できるようになります。\n LL-HLS は、一部のセグメントを配信し、次のセグメントの準備ができるまでプレーヤーがプレイリストのリクエストを開いたままにしておくことで、ライブレイテンシーを削減します。これには、メディアプレイリストを Content Delivery Network (CDN) エッジでキャッシュできるようにする必要があります。MediaTailor は HLS インタースティシャルを使用してこれをサポートしています。HLS インタースティシャルは、広告を各視聴者のメディアプレイリストにつなぎ合わせるのではなく、個別のプレイリストとして参照します。すべての視聴者が同じキャッシュ可能なプレイリストを受け取るため、MediaTailor はレイテンシーの低い再生を大規模に維持し、広告デシジョンサーバーの呼び出しをマニフェストリクエストパスから遠ざけます。この機能は、視聴回数が数百万回に上るスポーツ中継イベントの制作で実証されており、レイテンシーが製品要件となるスポーツ中継、ニュース、ベッティングと賭け、ウォッチパーティー、インタラクティブなライブフォーマットに最適です。

低レイテンシー HLS 広告挿入は、AWS Elemental MediaTailor が利用できるすべての AWS リージョンで利用できます。詳細については、AWS Elemental MediaTailor 製品ページと MediaTailor サーバーガイド付き広告挿入ドキュメントをご覧ください。開始するには、MediaTailor コンソールにサインインしてください。

AWS Elemental introduces Dynamic Multiview for live video

AWS Elemental MediaPackage では、複数のライブ動画ソースを視聴者が選択したタイルレイアウトにオンデマンドで合成するサーバー側の機能であるダイナミックマルチビューが提供されるようになりました。コンテンツプロバイダーは、マルチアングル、マルチゲーム、パーソナライズされた視聴体験を標準の HLS (HTTP ライブストリーミング) および DASH (Dynamic Adaptive Streaming over HTTP) ストリームとして提供でき、カスタムプレーヤーを開発しなくても最新のコンシューマーデバイス、テレビ、セットトップボックスで再生できます。\n Dynamic Multiview は完全に圧縮された領域で動作し、再エンコードや合成を行わずに個別にエンコードされたソースを組み合わせます。顧客は AWS Elemental MediaLive を通じて各ソースを一度エンコードし、MediaPackage は視聴者の要求があった場合にのみオンデマンドでコンポジションを組み立てるため、組み合わせを事前にエンコードする必要がありません。出力は標準の HLS と DASH なので、アプリを変更したり SDK を統合したりすることなく、既存のデバイスやプレーヤーでネイティブに再生できます。この機能は AVC および HEVC コーデック、DRM 暗号化、SCTE-35 広告マーカーパススルー、フルスクリーン広告置換をサポートしています。

詳細については、『エレメンタル・ダイナミック・マルチビュー・リファレンス・ガイド』を参照してください。

ダイナミックマルチビューは、AWS Elemental MediaPackage と MediaLive が利用できるすべての AWS リージョンで利用できます。

AWS Storage Gateway now supports FIPS-compliant private connectivity for Amazon S3 File Gateway

AWS ストレージゲートウェイは、Amazon S3 ファイルゲートウェイ用 AWS PrivateLink 経由で FIPS 140-3 検証済みのエンドポイントをサポートするようになりました。以前は、ファイルゲートウェイの FIPS エンドポイントはパブリックインターネット経由でのみ利用可能でした。FIPS 準拠のトラフィックをプライベート AWS ネットワーク上で維持できるようになったため、規制対象のワークロードに Storage Gateway をより簡単に使用できるようになりました。\n 今回のローンチにより、ファイルゲートウェイは VPC 内の FIPS インターフェイス VPC エンドポイントを経由して Storage Gateway サービスのエンドポイントにプライベートにアクセスできるようになります。また、S3 FIPS インターフェイスエンドポイントを介して Amazon S3 に到達する NFS および SMB ファイル共有を作成することもできます。これにより、エンドツーエンドのファイル転送ワークロードで FIPS 準拠のプライベート接続が可能になります。まず、ストレージゲートウェイと Amazon S3 の FIPS インターフェイスエンドポイントを VPC に作成し、ゲートウェイをアクティベートしてファイル共有を設定するときに FIPS VPC エンドポイントオプションを選択します。FIPS PrivateLink エンドポイントを使用してゲートウェイをアクティブ化するには、ゲートウェイでソフトウェアバージョン 2.1.10 以降が実行されている必要があります。

今回のローンチは、Storage Gateway が FIPS エンドポイントを提供する 8 つの AWS リージョン (米国東部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、カナダ (中部)、カナダ西部 (カルガリー)、AWS GovCloud (米国東部)、AWS GovCloud (米国西部)、AWS GovCloud (米国西部) でご利用いただけます。詳細については、AWS Storage Gateway ユーザーガイドまたは製品ページをご覧ください。

Amazon EVS is now available in more regions

本日、Amazon Elastic VMware Service (Amazon EVS) がアジアパシフィック (大阪)、アジアパシフィック (台北)、ヨーロッパ (スペイン)、イスラエル (テルアビブ) の各リージョンで利用できるようになったことをお知らせします。この拡張により、AWS の規模と柔軟性を活用して VMware ワークロードをクラウドで実行するためのオプションが増えました。\n Amazon EVS では、AWS Nitro を搭載した EC2 ベアメタルインスタンス上の Amazon 仮想プライベートクラウド (VPC) 内で VMware Cloud Foundation (VCF) を直接実行できます。わずか数時間で完全な VCF 環境を設定できるため、AWS への迅速なワークロード移行が可能になり、老朽化したインフラストラクチャの排除、運用上のリスクの軽減、データセンターの撤退に関する重要なスケジュールの遵守が可能になります。このリリースでは、メモリ階層化などの VMware の最新機能を活用するための VCF 9.0 と 9.1 のサポートを含む、既存の Amazon EVS 機能がすべてサポートされます。 これらのリージョンでの可用性の向上により、エンドユーザーとの距離が近いため、VMware ワークロードのレイテンシーが短縮され、データレジデンシー要件または主権要件への準拠が可能になり、冗長戦略を強化するための高可用性と耐障害性のオプションが追加されます。 開始するには、Amazon EVS 製品詳細ページとユーザーガイドをご覧ください。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS Open Source Blog

AWS Architecture Blog

AWS Cloud Financial Management

AWS Big Data Blog

AWS for Industries

Artificial Intelligence

AWS for M&E Blog

Open Source Project

AWS CLI

AWS CDK

Amplify for iOS

Firecracker

Amazon EKS Anywhere