2024/6/26 9:00:00 ~ 2024/6/27 9:00:00 (JST)
最近の発表
Amazon マネージドサービス for Apache Flink では、アプリケーションで実行されたオペレーションを可視化するための ListApplication Operations と DescribeApplication Operation API が導入されました。これらの API では、操作の開始日時、現在のステータス、成功または失敗、操作によってロールバックがトリガーされたかどうかなどの詳細が表示され、フォローアップアクションを実行できるようになります。\n Apache Flink 向け Amazon マネージドサービスでは、Apache Flink を使用してストリーミングデータをリアルタイムで簡単に変換および分析できます。Apache Flink は、データストリームを処理するためのオープンソースのフレームワークおよびエンジンです。Amazon マネージドサービス for Apache Flink は、Apache Flink アプリケーションの構築と管理の複雑さを軽減し、組み込みのコネクタを使用して、Apache Kafka (Amazon MSK) 向けアマゾンマネージドストリーミング (Amazon MSK)、Amazon Kinesis データストリーム、Amazon OpenSearch サービス、Amazon DynamoDB ストリーム、Amazon Simple Storage Service (Amazon S3)、カスタム統合などと統合されています。
Amazon Managed Service for Apache Flink now supports system-rollback
Amazon Managed Service for Apache Flink にはシステムロールバック機能が導入されており、コードまたは設定エラーがあった場合に、Flink ジョブの送信中にアプリケーションを以前の実行中のアプリケーションバージョンに自動的に戻すことができます。この機能にオプトインしてアプリケーションのアップタイムを向上させることができるようになりました。アプリケーションの更新、Flink のバージョンアップグレード、またはスケーリングアクションを実行すると、権限が不十分、互換性のないセーブポイント、その他のエラーなどのエラーが発生することがあります。システムロールバックは、ジョブの送信時にこれらのエラーを特定し、アプリケーションへの不正な更新を防ぎます。これにより、アプリケーションに変更をより迅速に反映できるという確信が高まります。\n Apache Flink 向け Amazon マネージドサービスでは、Apache Flink を使用してストリーミングデータをリアルタイムで簡単に変換および分析できます。Apache Flink は、データストリームを処理するためのオープンソースのフレームワークおよびエンジンです。Amazon マネージドサービス for Apache Flink は、Apache Flink アプリケーションの構築と管理の複雑さを軽減し、組み込みのコネクタを使用して、Apache Kafka (Amazon MSK) 向けアマゾンマネージドストリーミング (Amazon MSK)、Amazon Kinesis データストリーム、Amazon OpenSearch サービス、Amazon DynamoDB ストリーム、Amazon Simple Storage Service (Amazon S3)、カスタム統合などと統合されています。
Amazon Route 53 アプリケーションリカバリコントローラ (Route 53 ARC) のゾーンオートシフトが AWS GovCloud (米国東部および米国西部) リージョンで一般的に利用できるようになりました。AWS GovCloud (米国) リージョンで事業を展開している AWS のお客様と AWS パートナーは、ゾーン自動シフトを使用できるようになりました。この機能を有効にすると、アベイラビリティーゾーン (AZ) に影響する可能性のある障害が AWS によって特定されたときに、そのアベイラビリティーゾーン (AZ) からアプリケーションのトラフィックを安全かつ自動的に移動できます。停電やネットワークの停止などの障害では、ゾーン自動シフトによりアプリケーショントラフィックが影響を受けた AZ から正常な AZ にシフトされるため、アプリケーションの可用性が向上します。\n まず、コンソール、SDK、CLI、または Amazon CloudFormation テンプレートを使用して、クロスゾーン設定を無効にした状態で、アプリケーションロードバランサーとネットワークロードバランサーのゾーンオートシフトを有効にできます。有効にすると、Amazon はアプリケーショントラフィックを影響を受けた AZ から自動的に移動させ、障害が解決された後に元に戻します。ゾーンオートシフトには練習実行が含まれています。これは、影響を受けるアベイラビリティーゾーンからシフトした後でも、アプリケーションが正常に動作するのに十分なキャパシティが各 AZ にあるかどうかを事前にテストする機能です。ゾーンシフトを自動的に適用するように練習実行を設定します。これにより、アプリケーションが AZ のキャパシティ損失に耐えられるかどうかが定期的に確認されます。
Amazon OpenSearch Ingestion adds supports to ingest streaming data from Confluent Cloud
Amazon OpenSearch Ingestion では、サードパーティのデータコネクタを必要とせずに、Confluent Cloud Kafka クラスターからのストリーミングデータを Amazon OpenSearch Service マネージドクラスターまたはサーバーレスコレクションにシームレスに取り込むことができるようになりました。この統合により、Amazon OpenSearch Ingestion を使用して Confluent Cloud から取り込まれたデータをほぼリアルタイムで集約、サンプリング、異常検出できるようになりました。これにより、複雑なオブザーバビリティのユースケースを強化する効率的なデータパイプラインを構築できます。\n Amazon OpenSearch インジェストパイプラインは、Confluent Kafka クラスター内の 1 つ以上のトピックからのデータを使用し、Amazon OpenSearch Service または Amazon S3 に書き込む前にデータを変換できます。Amazon OpenSearch Ingestion を介して Confluent Kafka クラスターからデータを読み取る際に、トピックごとのコンシューマー数を設定したり、優先度の高いデータと低いデータの異なるフェッチパラメータを調整したりできます。オプションで Confluent Schema Registry を使用してデータスキーマを指定し、取り込み時にデータを動的に読み取ることもできます。この機能の詳細については、Confluent によるこのブログ投稿もご覧ください。
Amazon CloudWatch Logs now supports account level subscription filter in 4 additional regions
Amazon CloudWatch Logs は、さらに 4 つのリージョンで put-account-policy API を使用してアカウントレベルのサブスクリプションフィルターを作成できるようになったことを発表できることを嬉しく思います。この新機能により、Amazon CloudWatch Logs に取り込まれたリアルタイムのログイベントを Amazon Kinesis データストリーム、Amazon Kinesis Data Firehose、または AWS Lambda に配信して、単一のアカウントレベルのサブスクリプションフィルタを使用してカスタム処理、分析、または他の宛先への配信を行うことができます。\n 多くの場合、お客様はログの全部または一部を、さまざまな分析ユースケースのために Amazon OpenSearch や、さらに他のシステムにストリーミングするために Amazon Kinesis Data Firehose などの AWS サービスに転送する必要があります。現在、お客様はロググループごとにサブスクリプションフィルタを設定する必要があります。ただし、アカウントレベルのサブスクリプションフィルターでは、アカウント全体に 1 つのサブスクリプションフィルターポリシーを設定することで、顧客は複数またはすべてのロググループに取り込まれたログを出力できます。これにより、時間が節約され、管理オーバーヘッドが軽減されます。アカウントレベルのサブスクリプションフィルターは、既存のロググループと、設定に一致する将来のロググループの両方に適用されます。各アカウントはアカウントレベルのサブスクリプションフィルターを 1 つ作成できます。 CloudWatch Logs アカウントレベルのサブスクリプションフィルタが AWS GovCloud (米国東部) および (米国西部) リージョン、イスラエル (テルアビブ)、カナダ西部 (カルガリー) で利用できるようになりました。詳細については、CloudWatch Logs アカウントレベルのサブスクリプションフィルターに関するドキュメントを参照してください。
AWS CloudShell now supports Amazon Virtual Private Cloud (VPC)
本日、AWS は AWS CloudShell の Amazon 仮想プライベートクラウド (VPC) サポートの一般提供を発表しました。これにより、VPC 内に CloudShell 環境を作成できるため、追加のネットワーク設定を必要とせずに、VPC 内の他のリソースと同じサブネット内で CloudShell を安全に使用できます。\n 今回のリリース以前は、CloudShell を使用してインターネットへのネットワークフローを制御するメカニズムはありませんでした。今回のリリースでは、VPC で CloudShell を安全かつ便利に起動し、VPC 内のリソースにアクセスできるようになりました。 AWS CloudShell はブラウザベースのシェルで、AWS リソースの安全な管理、探索、操作を簡単に行うことができます。CloudShell はコンソールの認証情報を使用して事前認証されます。一般的な開発ツールはプリインストールされているため、ローカルにインストールしたり設定したりする必要はありません。CloudShell では、AWS コマンドラインインターフェイス (AWS CLI) でスクリプトを実行したり、AWS クラウド開発キット (AWS CDK) でインフラストラクチャを定義したり、AWS SDK を使用して AWS サービス API を試したり、その他のさまざまなツールを使用して生産性を向上させることができます。
AWS CloudShell での VPC 接続の詳細については、当社のドキュメントを参照してください。
Amazon Linux announces availability of AL2023.5 with new versions of PHP and Microsoft .NET
本日、IPAクライアントとmod-phpに加えて、PHPと.NETの最新バージョンを含むAL2023の最新の四半期アップデートが利用可能になったことを発表します。\n お客様は新しいバージョンの PHP と.NET を活用して、アプリケーションの安全性と効率性を確保できます。さらに、AL2023.5には、それぞれWebサーバーのパフォーマンスを向上させ、ID管理統合を簡素化できるmod-phpやIPAクライアントなどのパッケージが含まれており、開発ワークフローをさらに合理化し、システム全体の効率を高めることができます。 AL2023.5 のその他の機能について詳しくは、リリースノートを参照してください。 Amazon Linux 2023 は通常、AWS GovCloud (米国) リージョンと中国リージョンを含むすべての AWS リージョンでご利用いただけます。Amazon Linux 2023 の詳細については、AWS ドキュメントを参照してください。
Amazon Athena Provisioned Capacity now available in South America (São Paulo) and Europe (Spain)
本日、Amazon Athena は南米 (サンパウロ) とヨーロッパ (スペイン) のリージョンでプロビジョニングキャパシティを利用できるようにしました。Provisioned Capacity は Athena の機能の 1 つで、フルマネージド型の専用サーバーレスリソースで SQL クエリを固定料金で実行でき、長期契約は必要ありません。Provisioned Capacity を使用すると、クエリに処理キャパシティを選択的に割り当て、クエリの同時実行性やコストなどのワークロードパフォーマンス特性を制御できます。容量はいつでもスケーリングでき、支払いは必要な容量とそれがアカウントで有効だった時間に対してのみ行われます。\n Athena はサーバーレスのインタラクティブなクエリサービスで、ペタバイト規模のデータを簡単かつ柔軟に分析できます。Provisioned Capacity には、インタラクティブなクエリワークロードの優先順位付け、分離、スケーリングに役立つワークロード管理機能が備わっています。たとえば、Provisioned Capacity を使用すると、同時に多数のクエリを実行できるようにキャパシティを拡張したり、重要なクエリをアカウントで実行中の他のクエリから切り離したりできます。まず、Athena コンソール、AWS SDK、または CLI を使用してアカウントのキャパシティをリクエストし、そのキャパシティを使用したいクエリのワークグループを選択します。 Provisioned Capacity は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京)、アジアパシフィック (シドニー)、アジアパシフィック (シンガポール)、ヨーロッパ (アイルランド)、ヨーロッパ (ストックホルム) の AWS リージョンでもご利用いただけます。 詳細については、Amazon Athena ユーザーガイドの「クエリ処理能力の管理」を参照してください。料金の詳細については、Athena の料金表ページをご覧ください。
EventBridge Scheduler adds more universal targets including Amazon Bedrock
イベントブリッジスケジューラーには、650以上のAWS APIアクションを含むユニバーサルターゲットが追加され、Amazon Bedrockを含めて合計で7000以上になりました。\n EventBridge Scheduler では、基盤となるインフラストラクチャをプロビジョニングしたり管理したりしなくても、AWS サービス全体で何百万もの予定されたイベントやタスクを作成して実行できます。EventBridge Scheduler は、1 回限りのスケジュールと定期的なスケジュールをサポートしています。これらのスケジュールは cron、rate、特定の時間などの一般的なスケジューリング表現を使用して作成でき、タイムゾーンや夏時間にも対応しています。追加ターゲットのサポートにより、テキストモデル、画像モデル、埋め込みモデルの推論を特定の時点で実行するようにBedrockモデルをスケジューリングするなど、より多くのユースケースを自動化できます。
Amazon Redshift Serverless with lower base capacity available in additional regions
Amazon Redshift では、AWS ヨーロッパ (ストックホルム) および米国西部 (北カリフォルニア) リージョンの 8 つの Redshift プロセッシングユニット (RPU) という低いデータウェアハウスの基本容量構成で Amazon Redshift Serverless を使い始めることができるようになりました。Amazon Redshift Serverless はデータウェアハウスの容量を RPU で測定し、お支払いいただくのは、実行したワークロードの期間 (RPU 時間) を秒単位で表したものです。以前は、Amazon Redshift サーバーレスを実行するために必要な最小基本容量は 32 RPU でした。基本容量が最低 8 RPU と低くなったため、価格とパフォーマンスの要件に基づいて、複雑度が小さいものから大きいものまで、さまざまなワークロードをより柔軟にサポートできるようになりました。RPU は 8 RPU 単位で増減できます。\n Amazon Redshift Serverless では、データウェアハウスクラスターをプロビジョニングして管理しなくても分析を実行したりスケーリングしたりできます。Amazon Redshift Serverless では、データアナリスト、開発者、データサイエンティストを含むすべてのユーザーが Amazon Redshift を使用してデータから数秒で洞察を得ることができます。新しい低容量構成では、ワークロードに少量のコンピューティングが必要な場合に、本番環境、テスト、開発環境に Amazon Redshift Serverless を最適な価格で使用できます。 開始するには、Amazon Redshift サーバーレス機能ページ、ユーザードキュメント、および API リファレンスを参照してください。
AWS Control Tower introduces an API to discover landing zone operations
AWS Control Towerのお客様は、作成、更新、リセット、削除など、過去 90 日間に完了したすべてのランディングゾーン操作のリストをプログラムで取得できるようになりました。出力には、操作識別子、操作タイプ、ステータスなどの概要情報が含まれており、開始された操作を識別するのに役立ちます。\n これまで、顧客がランディングゾーンのオペレーションを取得できるのは、オペレーション識別子でリクエストするか、すべてのオペレーションを調べた場合のみでした。同じチームの API ユーザーは、同じランディングゾーンで他のユーザーが実行した操作を確認できなかったため、コンテキストが失われ、すべての操作の可視性が低下していました。これで、お客様はランディングゾーン全体の操作を簡単に表示、監査、トラブルシューティングできるようになり、操作の重複を防ぎ、全体的な運用効率を向上させることができます。 これらの API の詳細については、『AWS Control Tower ユーザーガイド』の「ランディングゾーン API の設定」と「API リファレンス」を参照してください。新しい API は、AWS コントロールタワーが利用可能な AWS リージョンで利用できます。AWS コントロールタワーが利用可能な AWS リージョンのリストについては、AWS リージョン表を参照してください。
AWS Blogs
Amazon Web Services ブログ (日本語)
- VPC Lattice サービスネットワーク内での SaaS サービス接続
- 【開催報告】生成 AI で教育を加速 ! 最新トレンドと実践ガイド(2024/05/29)
- サルソニード様の AWS 生成 AI 事例「Amazon Bedrock と Amazon Kendra の RAG 環境で法律関連オウンドメディア記事作成を効率化」のご紹介
- AWS Marketplace に初掲載の日本語 LLM ! オルツの LHTM-OPT を利用する手順解説
- AWS と EvolutionaryScale によるジェネレーティブ・バイオロジー（生成生物学）の革新