2025/2/13 9:00:00 ~ 2025/2/14 9:00:00 (JST)

最近の発表

AWS Deadline Cloud now supports Adobe After Effects in Service-Managed Fleets

AWS Deadline クラウドのサービスマネージドフリートに Adobe After Effects のサポートが含まれるようになりました。AWS Deadline Cloud は、映画、テレビ、放送、ウェブコンテンツ、デザイン向けに Adobe After Effects などの業界標準のグラフィックツールで作成されたコンピューター生成グラフィックや視覚効果を作成するチームのレンダリング管理を簡素化する完全マネージド型サービスです。\n この新機能により、独自のレンダリングファームインフラストラクチャを管理しなくても、After Effects プロジェクトを Deadline Cloud に送信できます。この統合では、カスタムフォントのサポートが組み込まれており、タスクごとにレンダリングされる画像シーケンスフレームの数を調整できるため、ワークフローに合わせたジョブを After Effects 内で直接送信できます。AWS Deadline Cloud は、After Effects プロジェクトのレンダリングに必要なコンピューティングリソースのプロビジョニングとエラスティックスケーリングを自動的に処理します。サービスマネージドフリートは数分で設定できるため、すぐにレンダリングを開始できます。 Deadline クラウドの After Effects サポートは、Deadline クラウドが提供されているすべての AWS リージョンで利用できます。 詳細については、Deadline クラウド製品ページと AWS Deadline クラウドのドキュメントをご覧ください。

AWS Network Load Balancer now supports removing availability zones

本日、既存のネットワークロードバランサー (NLB) のアベイラビリティーゾーン (AZ) を削除する機能をリリースします。今回のリリース以前は、お客様は既存の NLB に AZ を追加できましたが、AZ を削除することはできませんでした。この機能により、お客様はアプリケーションスタックの場所を変更したり、アベイラビリティーゾーン間ですばやく移動したりできるようになりました。\n 合併や買収、事業売却、データレジデンシーのコンプライアンス要件、特定の地域におけるキャパシティに関する考慮事項など、ビジネスニーズの変化は、既存の NLB から AZ を削除する必要があるユースケースの一部です。この機能を使用すると、お客様は ELB API、CLI、またはコンソールを使用して有効なサブネットのリストを更新するだけで、NLB から 1 つ以上のアベイラビリティーゾーンを削除できます。 他の削除操作と同様に、ゾーンの削除は操作の中断を招く可能性があります。ゾーンを削除すると、NLB ゾーンの Elastic Network Interface (ENI) が削除されます。そのゾーン内のバックエンドターゲットへのアクティブな接続 (他のゾーン経由で接続しているクライアントを含む) はすべて終了し、ゾーン IP (および EIP) は解放され、ゾーン DNS 名は削除され、削除されたゾーンのバックエンドターゲットは「未使用」になります。この機能を安全に使用する方法に関する規範的なガイダンスについては、製品ドキュメントと AWS ブログ投稿を参照してください。 この機能は、すべての AWS 商用リージョンと AWS GovCloud (米国) リージョンで利用できます。

Amazon RDS for PostgreSQL supports minor versions 17.3, 16.7, 15.11, 14.16, 13.19

PostgreSQL 用アマゾンリレーショナルデータベースサービス (RDS) は、最新のマイナーバージョン 17.3、16.7、15.11、14.16、13.19 をサポートするようになりました。以前のバージョンの PostgreSQL の既知のセキュリティ脆弱性を修正し、PostgreSQL コミュニティによって追加されたバグ修正の恩恵を受けるには、最新のマイナーバージョンにアップグレードすることをお勧めします。このリリースには、pg_active 2.1.4、pg_cron 1.6.5、pg_partman 5.2.4 などの PostgreSQL エクステンションのアップデートも含まれています。\n マイナーバージョン自動アップグレードを使用すると、定期メンテナンス期間中にデータベースを最新のマイナーバージョンに自動的にアップグレードできます。マイナーバージョンのアップグレードでは、物理レプリケーションを使用して RDS for PostgreSQL に Amazon RDS Blue/Green デプロイメントを使用することもできます。マイナーバージョンの自動アップグレードや Blue/Green デプロイなど、データベースインスタンスのアップグレードについて詳しくは、Amazon RDS ユーザーガイドをご覧ください。 Amazon RDS for PostgreSQL を使用すると、クラウドで PostgreSQL デプロイメントを簡単にセットアップ、運用、およびスケーリングできます。価格の詳細とリージョンの提供状況については、Amazon RDS for PostgreSQL の料金表をご覧ください。Amazon RDS マネジメントコンソールで、フルマネージド型の Amazon RDS データベースを作成または更新します。

Amazon Q generative SQL is now available in additional regions

Amazon Q ジェネレーティブ SQL が、米国東部 (オハイオ) およびアジアパシフィック (ソウル) リージョンの Amazon Redshift クエリエディタで利用できるようになりました。この機能により、Amazon Redshift のウェブベースのクエリエディタでの SQL クエリオーサリングが強化され、自然言語を使用して SQL クエリを記述し、インテリジェントな SQL コード推奨を受け取ることができるようになります。Amazon Q ジェネレーティブ SQL を使うと、SQL の専門知識に関係なく、Amazon Redshift データベースクエリをより利用しやすく効率的に行うことができます。\n Amazon Q ジェネレーティブ SQL は、ジェネレーティブ AI を使用してユーザーの意図、SQL クエリパターン、スキーマメタデータを分析し、Amazon Redshift 内の一般的なクエリパターンを特定します。会話型インターフェイスにより、ユーザーは既存のデータ権限を維持したまま SQL クエリを自然言語で送信できます。たとえば、「地域別の総収益を検索」と尋ねると、関連する Amazon Redshift テーブルを結合して適切な SQL コードをシステムが自動的に提案するので、開発時間が短縮され、エラーの可能性も減ります。ユーザーは提示されたクエリを直接受け入れることも、フォローアップの質問を繰り返し実行して結果を絞り込むこともできます。 価格について詳しくは、Amazon Q 開発者料金ページをご覧ください。開始するにはドキュメントを参照してください。

Amazon RDS for MySQL announces Extended Support minor 5.7.44-RDS.20250103

MySQL 用アマゾンリレーショナルデータベースサービス (RDS) が Amazon RDS 延長サポートマイナーバージョン 5.7.44-RDS.20250103 を発表しました。MySQL の以前のバージョンにあった既知のセキュリティ脆弱性やバグを修正するには、このバージョンにアップグレードすることをお勧めします。このバージョンのバグ修正とパッチの詳細については、Amazon RDS ユーザーガイドをご覧ください。\n Amazon RDS 延長サポートでは、ビジネス要件を満たすのに役立つ新しいメジャーバージョンへのアップグレード期間が最大 3 年延長されます。延長サポート期間中は、コミュニティがメジャーバージョンのサポートを終了した後に、Amazon RDS が RDS for MySQL データベースの重要なセキュリティおよびバグ修正を提供します。Amazon RDS では、メジャーバージョンの標準サポート終了日から最大 3 年間、延長サポートを利用して MySQL データベースを稼働できます。延長サポートの詳細については、Amazon RDS ユーザーガイドと料金に関するよくある質問をご覧ください。 Amazon RDS for MySQL を使用すると、クラウドでの MySQL デプロイのセットアップ、運用、およびスケーリングが簡単になります。価格の詳細とリージョンの提供状況については、Amazon RDS for MySQL の料金表をご覧ください。Amazon RDS マネジメントコンソールで、フルマネージド型の Amazon RDS データベースを作成または更新します。

Amazon OpenSearch Serverless expands support for time-series workloads up to 100TB

Amazon OpenSearch サーバーレスが、時系列コレクションで最大 100 TB のデータのワークロードをサポートするようになったことを発表できることを嬉しく思います。OpenSearch Serverless は Amazon OpenSearch Service のサーバーレスデプロイオプションで、インフラストラクチャ管理について考える必要なく、検索と分析のワークロードを簡単に実行できます。OpenSearch Serverless は、大規模なデータセットをサポートするようになったため、ログ分析、セキュリティ分析、リアルタイムのアプリケーションモニタリングなど、よりデータ量の多いユースケースに対応できるようになりました。\n インデックス作成と検索に使用されるOpenSearch Serverlessの計算能力は、OpenSearch コンピュートユニット (OCU) で測定されます。OpenSearch Serverless では、大規模なデータセットに対応するため、インデックス作成と検索の操作を個別にスケーリングして、最大 1700 個の OCU を使用できるようになりました。コストを管理するために、検索とインデックス作成の最大 OCU 制限を個別に設定できます。また、CloudWatch メトリクスを使用して OCU の使用状況をリアルタイムでモニタリングし、ワークロードのリソース消費量をより的確に把握することもできます。 Amazon OpenSearch サービスの可用性に関する詳細については、AWS 地域サービスリストを参照してください。OpenSearch サーバーレスの詳細については、ドキュメントを参照してください。

Introducing Amazon EC2 C6in instances in Chicago and New York City Local Zones

Amazon Elastic Compute Cloud (Amazon EC2) C6in インスタンスがシカゴとニューヨーク市のローカルゾーンで利用できるようになりました。C6in インスタンスは、オールコアのターボ周波数が最大 3.5 GHz の第3世代インテル Xeon スケーラブルプロセッサーを搭載しています。x86 ベースの Amazon EC2 コンピューティング最適化インスタンスで、最大 200 Gbps のネットワーク帯域幅を提供します。インスタンスは AWS Nitro System 上に構築されています。AWS Nitro System は専用の軽量ハイパーバイザーで、ホストハードウェアのコンピューティングリソースとメモリリソースをインスタンスに提供して、全体的なパフォーマンスとセキュリティを向上させます。高いネットワーク帯域幅を活用して、AWS ローカルゾーンで実行される幅広いワークロードのパフォーマンスをスケーリングできます。\n ローカルゾーンは、コンピューティング、ストレージ、データベース、その他の特定のサービスを、AWS リージョンが存在しない大勢の人口、業界、IT センターの近くに配置する AWS インフラストラクチャのデプロイメントです。ローカルゾーンを使用すると、リアルタイムゲーム、ハイブリッド移行、メディアとエンターテインメントのコンテンツ制作、ライブビデオストリーミング、エンジニアリングシミュレーション、金融サービスの支払い処理、資本市場運用、AR/VR などのユースケースで、1 桁ミリ秒のレイテンシーを必要とするアプリケーションを実行できます。 まず、Amazon EC2 コンソールまたは ModifyAvailabilityZoneGroup API でシカゴローカルゾーン us-east-1-chi-2a とニューヨークシティローカルゾーン us-east-1-nyc-2a を有効にし、インスタンスに C6 をデプロイできます。詳細については、AWS ローカルゾーンの概要ページと Amazon EC2 インスタンスタイプをご覧ください。

Amazon ECS now enables you to update services from short to long ARNs

短い Amazon リソースネーム (ARN) を使用する既存の Amazon Elastic Container Service (Amazon ECS) サービスを、サービスを再作成しなくても長い ARN を使用するように更新できるようになりました。これにより、長期間稼働している Amazon ECS サービスにタグを付けることができるため、コスト配分が容易になり、可視性が向上し、これらのサービスに対するきめ細かなリソースレベルのアクセス権限を定義できるようになります。\n 2018 年以降、お客様は長い ARN 形式 (ARN にクラスター名を含む) を使用する Amazon ECS サービスにタグを付けることができましたが、古い短い ARN 形式で作成されたサービスにタグを付ける場合は、サービスを削除して再作成する必要がありました。ECS では、サービスを再作成しなくても、古い短い ARN 形式で作成されたサービスにタグを付けることができるようになりました。これを有効にするには、2 つのステップを実行する必要があります。1 つは、タスクとサービス用に長い Amazon リソースネーム (ARN) 形式にアカウントをオプトインすることと、TagResource API アクションを使用して長い ARN 形式に移行するサービスに2/タグを付けることです。これらの手順を完了すると、ECS はサービスの ARN をロング ARN 形式に更新し、サービスにタグを付けます。ロングARN形式を使用するようにサービスを更新すると、IAMでリソースベースのアクセスポリシーを定義し、Cost & Usage ReportとCost Explorerでサービスのコストをきめ細かく監視できるようになります。 AWS コンソール、CLI、API を使用して、すべての AWS リージョンの短い ARN のサービスを長い ARN に更新できます。詳細については、当社のドキュメントをご覧ください。

AWS Blogs

Amazon Web Services ブログ (日本語)

AWS News Blog

AWS Big Data Blog

AWS Database Blog

AWS for Industries

The Internet of Things on AWS – Official Blog

AWS Machine Learning Blog

AWS for M&E Blog

Networking & Content Delivery

Open Source Project

AWS CLI

Amazon EKS Anywhere