はじめに

#

AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。

本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。

まとめと気付き

#

Amazon Bedrock AgentCore Runtime、Browser、およびCode InterpreterがVPC、AWS PrivateLinkをサポートしました。AIエージェントの世界をVPC内に完全に隔離して管理できるようになるのは安心ですね。

AWS X-Ray がアダプティブサンプリングを導入し、エラー検出を自動で最適化される機能が追加されました。個人的にはX-Rayはデバッグ時に一時的に有効化するなど用途が限られていました。今回の機能追加でコスト最適化できればX-Rayの活用用途が広がりそうです。

Amazon CloudWatchが標準メトリクスの監視時にリソースタグをサポートしました。状況に合わせてEC2を立ち上げたりするときに、個々のインスタンス情報を使わずにタグで監視対象にしたり外したりできるのは便利そうです。

Amazon S3 コンソールで Amazon S3 テーブルをプレビューできるようになりました。昔はS3クエリを使ったりしていましたが、これからはS3テーブルを使うようにしていかないとですね。

AWS Network Firewall がアプリケーション層のトラフィック制御を強化

#

投稿日: 2025年09月25日

AWS NETWORK FIREWALL ENHANCES APPLICATION LAYER TRAFFIC CONTROLS

aws.amazon.com

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

#

AWS Network Firewall が、TLSクライアントハローや複数のパケットに分割されたHTTPリクエストを処理するための強化されたデフォルトルールを提供するようになりました。これにより、新しいアプリケーション層のドロップおよびアラート確立ステートフルアクションが導入されます。

何が嬉しいのか

#

複雑なカスタムルールを作成することなく、堅牢なセキュリティポリシーを実装できるようになります。最新のTLS実装や大規模なHTTPリクエストをサポートしながらセキュリティ制御を維持でき、詳細なロギングオプションを通じて可視性を保ちつつ、複数のパケットに分割された主要な情報を含むトラフィックを効果的に検査・フィルタリングできます。

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

#

• これまで
  • 最新のTLSや複数のパケットに分割された大規模なHTTPリクエストのトラフィックを検査・フィルタリングすることが困難で、複雑なカスタムルールが必要になったり、セキュリティギャップが生じる可能性がありました。
• これから
  • Network Firewallが強化されたデフォルトルールとステートフルアクションにより、これらの複雑なトラフィックパターンを自動的に処理し、セキュリティポリシーの実装を簡素化し、可視性を向上させます。

具体的なユースケース

#

• 最新のプロトコルと暗号化標準を使用するアプリケーション（特にTLSクライアントハローや複数のパケットに分割された大規模なHTTPリクエストを持つもの）のセキュリティを確保したい組織。
• 複雑なルール管理なしに、堅牢なアプリケーション層トラフィック検査を必要とする組織。

Amazon RDS Database Preview EnvironmentでPostgreSQL 18.0が利用可能に

#

投稿日: 2025年09月25日

POSTGRESQL 18.0 IS NOW AVAILABLE IN AMAZON RDS DATABASE PREVIEW ENVIRONMENT

aws.amazon.com

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

#

Amazon RDS Database Preview EnvironmentでPostgreSQL 18.0が利用可能になりました。これにより、フルマネージドデータベースサービスの利点を活用しながら、PostgreSQL 18.0の最新機能を評価できるようになります。

PostgreSQL 18.0には以下の新機能が含まれます。

• マルチカラムB-treeインデックスの「スキップスキャン」サポート。
• ORおよびIN条件のWHERE句処理の改善。
• 並列Generalized Inverted Index (GIN) 構築の導入。
• 結合操作の更新。
• タイムスタンプベースの順序付けと従来のUUIDのユニークさを組み合わせ、高スループット分散システムでのパフォーマンスを向上させるUniversally Unique Identifiers Version 7 (UUIDv7) のサポート。
• クエリ実行中のバッファ使用量、インデックスルックアップ、接続ごとのI/O利用率メトリクスを表示する可観測性の改善。

何が嬉しいのか

#

本番環境に導入する前に、PostgreSQL 18.0の最新機能をサンドボックス環境で安全にテストし、評価することができます。これにより、アプリケーションの互換性を確認し、新機能の活用計画を事前に立てることが可能になります。特に、UUIDv7による分散システムでのパフォーマンス向上や、インデックス・クエリ処理の効率化、詳細な可観測性メトリクスを活用して、より効率的で高性能なデータベース運用を目指せます。

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

#

• これまで
  • PostgreSQL 18.0の最新機能を、フルマネージドサービス環境で一般提供前に評価することはできませんでした。UUIDv7のようなパフォーマンス向上機能や、高度なインデックス、クエリ処理の改善、詳細な可観測性機能は利用できませんでした。
• これから
  • Amazon RDS Database Preview EnvironmentでPostgreSQL 18.0の最新機能を、本番環境に導入する前にテスト・評価できるようになりました。これにより、アプリケーションの互換性確認や新機能の活用計画を立てることが可能になります。特に、UUIDv7による分散システムでのパフォーマンス向上や、インデックス・クエリ処理の効率化、詳細な可観測性メトリクスを活用できます。

具体的なユースケース

#

• 新バージョンのPostgreSQLへのアップグレードを計画している企業が、本番環境への影響を事前に検証する。
• UUIDv7を活用して、高スループットな分散システムにおけるデータ挿入性能を向上させる。
• 複雑なクエリのパフォーマンスチューニングのために、新しい可観測性機能（バッファ使用量、インデックスルックアップ、I/O利用率）を利用してボトルネックを特定する。
• マルチカラムB-treeインデックスのスキップスキャンや、OR/IN条件のWHERE句処理改善により、特定のデータ検索クエリの実行速度を向上させる。
• 並列GINインデックス構築を利用して、大規模なテキスト検索やJSONBデータに対するインデックス作成時間を短縮する。

Amazon EC2 の許可された AMI 設定に、AMI ガバナンスを強化するための新しいパラメータが追加

#

投稿日: 2025年09月25日

AMAZON EC2 ALLOWED AMIS SETTING ADDS NEW PARAMETERS FOR ENHANCED AMI GOVERNANCE

aws.amazon.com

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

#

Amazon EC2 のアカウント全体の設定である「許可された AMI (Allowed AMIs)」に、以下の4つの新しいパラメータが追加され、AMI の検出と使用を制限できるようになりました。

• マーケットプレイスコード (marketplace codes)
• 非推奨化時間 (deprecation time)
• 作成日 (creation date)
• AMI 名 (AMI names)

これにより、組織全体で AMI ガバナンスをより詳細に設定できるようになります。

何が嬉しいのか

#

これらの新しいパラメータを使用することで、意図せず非準拠または不正な AMI を使用してインスタンスを起動してしまうリスクをさらに低減できます。より厳格なルールを適用し、AMI のライフサイクルと命名規則に基づいたガバナンスを強化することで、セキュリティとコンプライアンスの向上に貢献します。

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

#

• これまで
  • 許可された AMI の設定では、信頼するアカウントや所有者のエイリアスのみを指定できました。
• これから
  • アカウントや所有者のエイリアスに加えて、マーケットプレイスコード、非推奨化時間、作成日、AMI 名といった詳細な基準を定義できるようになり、よりきめ細やかな AMI の使用制限が可能になります。

具体的なユースケース

#

• 特定のマーケットプレイス AMI の使用のみを許可し、それ以外のマーケットプレイス AMI の使用を制限する。
• 作成日が古い AMI や非推奨化時間が設定された AMI の使用を禁止し、常に最新かつ承認された AMI のみを使用させる。
• 特定の命名パターンを持つ AMI のみを使用可能とし、組織の命名規則に準拠しない AMI の使用を制限する。
• 宣言型ポリシー (Declarative Policies) を活用して、組織全体でこれらのパラメータを構成し、一元的な AMI ガバナンスを実施する。

Amazon Bedrock AgentCore Runtime、Browser、およびCode InterpreterがVPC、AWS PrivateLink、CloudFormation、およびタグ付けをサポート

#

投稿日: 2025年09月25日

AMAZON BEDROCK AGENTCORE RUNTIME, BROWSER, AND CODE INTERPRETER ADD SUPPORT FOR VPC, AWS PRIVATELINK, CLOUDFORMATION, AND TAGGING

aws.amazon.com

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

#

Amazon BedrockのAgentCore Runtime、Browser、およびCode Interpreterサービスが、Amazon Virtual Private Cloud (VPC) 接続、AWS PrivateLink、AWS CloudFormation、およびリソースタグ付けをサポートするようになりました。これにより、開発者は強化されたエンタープライズセキュリティとインフラストラクチャ自動化機能を備えたAIエージェントをデプロイできるようになります。

何が嬉しいのか

#

• セキュリティの向上: VPCとAWS PrivateLinkのサポートにより、AIエージェントがインターネットに公開されることなく、プライベートなリソース（データベース、内部APIなど）に安全に接続できるようになります。
• インフラストラクチャの自動化: CloudFormationのサポートにより、AIエージェントのインフラストラクチャをコードとして自動的にプロビジョニングおよび管理できます。
• 運用管理の強化: リソースタグ付けにより、コスト配分、アクセス制御、リソースの整理を包括的に実施でき、大規模なデプロイメントの管理が容易になります。

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

#

• これまで
  • Amazon Bedrock AgentCoreサービスは、VPC内でのプライベートなリソースへの直接的かつセキュアな接続、AWS PrivateLinkによるプライベート接続、CloudFormationによるインフラストラクチャのコード化、および包括的なリソースタグ付けの機能が限定的でした。これにより、エンタープライズ環境でのセキュリティ要件の厳しいワークロードや、大規模な自動化されたデプロイメントが困難な場合がありました。
• これから
  • VPC、AWS PrivateLink、CloudFormation、およびリソースタグ付けのサポートにより、AIエージェントをよりセキュアで、自動化され、管理しやすい方法でデプロイできるようになります。これにより、機密性の高いデータへのアクセスや、厳格なコンプライアンス要件を持つエンタープライズアプリケーションでのAIエージェントの利用が促進されます。

具体的なユースケース

#

• 機密データへのセキュアなアクセス: 顧客データベースや内部APIなど、インターネットに公開できないプライベートネットワーク内の機密データにAIエージェントが安全にアクセスする。
• インフラストラクチャの自動デプロイ: CloudFormationを使用して、AIエージェントの実行環境や関連リソースをコードとして定義し、自動的にプロビジョニングおよび更新する。
• コスト管理とアクセス制御: リソースタグ付けを活用して、AIエージェントのデプロイメントごとにコストを追跡し、特定のチームやプロジェクトにアクセス権限を細かく設定する。
• セキュアなウェブインタラクション: AgentCore Browserを使用して、社内ウェブアプリケーションでのフォーム入力、データ抽出、QAテストなどを、VPC内で安全に実行する。
• エージェント生成コードの安全な実行: AgentCore Code Interpreterを使用して、AIエージェントが生成したコードを、隔離されたセキュアな環境（VPC内）で実行し、潜在的なリスクを軽減する。

AWS上のResearch and Engineering Studio 2025.09が利用可能に

#

投稿日: 2025年09月25日

RESEARCH AND ENGINEERING STUDIO ON AWS 2025.09 IS NOW AVAILABLE

aws.amazon.com

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

#

• フラクショナルGPUのサポートが追加され、Amazon EC2 g6f インスタンスが利用可能になりました。
• Systems Manager Parameter AliasによるAMI IDのサポートが導入され、AMI管理が簡素化されました。
• 既存のAmazon Cognitoユーザープールとの統合や、AWS CloudFormationテンプレートでのCIDR範囲のカスタマイズが可能になり、デプロイの柔軟性が向上しました。
• アジアパシフィック (大阪)、アジアパシフィック (ジャカルタ)、中東 (UAE)、南米 (サンパウロ) の4つのAWS商用リージョンで利用可能になり、リージョン展開が拡大されました。

何が嬉しいのか

#

• グラフィック集約型ワークロードにおいて、GPUリソースをより効率的に利用できるようになります。
• プロジェクト固有のAMIの管理が簡素化され、運用負担が軽減されます。
• 認証設定が合理化され、既存の認証基盤との連携が容易になります。
• ネットワーク計画の柔軟性が高まり、既存のネットワークリソースとの統合がスムーズになります。
• より多くのリージョンでResearch and Engineering Studio (RES) を利用できるようになり、地理的な要件に対応しやすくなります。

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

#

• これまで
  • GPUリソースはインスタンス単位で割り当てられるため、グラフィック集約型ワークロードでリソースの利用効率が低い場合がありました。
  • AMIの管理は手動またはより複雑なプロセスを必要とし、プロジェクト固有のイメージの管理が煩雑になることがありました。
  • デプロイ時の認証設定やネットワーク計画の柔軟性が限られていました。
  • 利用可能なAWSリージョンが限定されていました。
• これから
  • フラクショナルGPUのサポートにより、Amazon EC2 g6f インスタンスでGPUリソースをより細かく、効率的に利用できるようになります。
  • Systems Manager Parameter Aliasを使用することで、プロジェクト固有のAMIの管理が簡素化され、更新やデプロイが容易になります。
  • 既存のAmazon Cognitoユーザープールとの統合や、CloudFormationテンプレートでのCIDR範囲のカスタマイズにより、デプロイ時の認証設定とネットワーク計画の柔軟性が大幅に向上します。
  • アジアパシフィック (大阪)、アジアパシフィック (ジャカルタ)、中東 (UAE)、南米 (サンパウロ) の4つのリージョンが追加され、より広範な地域でRESを利用できるようになります。

具体的なユースケース

#

• 科学シミュレーション、エンジニアリング設計、3Dレンダリングなど、グラフィック集約型ワークロードを効率的に実行したい研究者やエンジニア。
• 複数の研究プロジェクトや開発チームで異なるAMIを使用しており、その管理とデプロイプロセスを簡素化したい管理者。
• 既存のAmazon Cognitoユーザープールを利用して、Research and Engineering Studioへの認証プロセスを統合し、ユーザー管理を効率化したい組織。
• 特定のネットワーク構成やIPアドレス範囲の要件がある環境にResearch and Engineering Studioをデプロイし、既存のインフラストラクチャとシームレスに連携させたい管理者。
• アジアパシフィック (大阪)、アジアパシフィック (ジャカルタ)、中東 (UAE)、南米 (サンパウロ) リージョンに拠点を持ち、クラウドベースの研究・エンジニアリング環境を構築したい企業や研究機関。

AWS X-Ray がアダプティブサンプリングを導入し、エラー検出を自動で最適化

#

投稿日: 2025年09月25日

AWS X-RAY INTRODUCES ADAPTIVE SAMPLING FOR AUTOMATIC OPTIMIZED ERROR DETECTION

aws.amazon.com

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

#

AWS X-Rayがアダプティブサンプリングを提供するようになりました。これにより、ユーザー定義の制限内でサンプリングレートを自動的に調整し、必要なときに最も重要なトレースを確実にキャプチャできるようになります。サンプリングブースト（異常が検出されたときに一時的にサンプリングレートを上げる）と、アノマリースパンキャプチャ（フルトレースがサンプリングされない場合でも、異常に関連するスパンを常にキャプチャする）の2つのアプローチをサポートしています。

何が嬉しいのか

#

インシデント発生時に包括的なトレースデータを提供することで、根本原因分析にかかる平均解決時間（MTTR）を短縮し、通常の運用時にはコスト効率の良いサンプリングレートを維持できます。

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

#

• これまで
  • DevOpsチーム、SRE、アプリケーション開発者は、サンプリングレートの設定において困難なトレードオフに直面していました。レートを低く設定しすぎるとインシデント時に重要なトレースを見逃すリスクがあり、高く設定しすぎると通常の運用時にオブザーバビリティコストが不必要に増加していました。
• これから
  • アダプティブサンプリングにより、サンプリングレートが自動的に調整されるため、インシデント発生時に重要なトレースを確実にキャプチャしつつ、通常の運用時には高コストを回避できるようになります。

具体的なユースケース

#

• インシデント発生時の平均解決時間（MTTR）の短縮。
• オブザーバビリティコストの最適化。
• 異常発生時に重要なトレースを確実にキャプチャする。

Amazon EC2 I7i インスタンスが欧州 (ミラノ) および米国西部 (北カリフォルニア) で利用可能に

#

投稿日: 2025年09月25日

AMAZON EC2 I7I INSTANCES NOW AVAILABLE IN AWS EUROPE (MILAN) AND AWS US WEST (N. CALIFORNIA)

aws.amazon.com

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

#

AWS Europe (ミラノ) および米国西部 (北カリフォルニア) リージョンで、高性能ストレージ最適化型 Amazon EC2 I7i インスタンスが利用可能になりました。これらのインスタンスは、第5世代 Intel Xeon プロセッサを搭載し、第3世代 AWS Nitro SSDs を使用しており、最大45TBのNVMeストレージを提供します。また、最大16KBのブロックサイズをサポートする「torn write prevention」機能も利用できます。

何が嬉しいのか

#

I7i インスタンスは、前世代の I4i インスタンスと比較して、最大23%優れたコンピューティング性能と10%以上の価格性能向上を実現します。ストレージ面では、最大50%優れたリアルタイムストレージ性能、最大50%低いストレージI/Oレイテンシー、最大60%低いストレージI/Oレイテンシー変動性を提供し、データベースのパフォーマンスボトルネックを解消できます。

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

#

• これまで
  • 第4世代のIntel Xeonプロセッサを搭載したI4iインスタンスが主流で、ストレージ性能やコンピューティング性能に限界がありました。特に、I/O集中型でレイテンシーに敏感なワークロードでは、より高い性能が求められていました。
• これから
  • 第5世代Intel Xeonプロセッサと第3世代AWS Nitro SSDsを搭載したI7iインスタンスにより、コンピューティング性能とストレージ性能が大幅に向上します。これにより、I/O集中型およびレイテンシーに敏感なワークロードにおいて、より高いパフォーマンスと安定性を提供できるようになります。

具体的なユースケース

#

• 非常に高いランダムIOPS性能とリアルタイムレイテンシーを必要とするI/O集中型およびレイテンシーに敏感なワークロード
• 中小規模のデータセットにアクセスするアプリケーション
• データベースのパフォーマンスボトルネックを解消したい場合
• 高速なストレージI/Oと安定した性能が求められるエンタープライズアプリケーション

Amazon S3 コンソールで Amazon S3 テーブルをプレビューできるようになりました

#

投稿日: 2025年09月25日

YOU CAN NOW PREVIEW AMAZON S3 TABLES IN THE S3 CONSOLE

aws.amazon.com

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

#

Amazon S3 コンソール内で、SQLクエリを記述することなくAmazon S3 テーブルを直接プレビューできるようになりました。S3 テーブルに保存されているテーブルのスキーマとサンプル行を表示し、セットアップなしでデータに関する主要な情報を迅速に理解し、収集できます。

何が嬉しいのか

#

これまでSQLクエリを書く必要があったデータの内容確認が、S3コンソールから直接、かつ迅速に行えるようになります。これにより、データ理解のプロセスが簡素化され、時間と労力を節約できます。また、テーブルの一部を読み取るためのS3リクエストに対してのみ料金が発生するため、コスト効率も向上します。

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

#

• これまで
  • S3テーブルのスキーマや内容を確認するには、SQLクエリを記述したり、外部のデータ処理ツールやサービスを使用する必要がありました。
• これから
  • S3コンソールから直接、SQLクエリなしでテーブルのスキーマとサンプル行を視覚的に確認できるようになります。

具体的なユースケース

#

• データアナリストが、新しいS3テーブルの構造と内容を素早く把握し、分析の準備を進める。
• データエンジニアが、ETLパイプラインの出力として生成されたS3テーブルのデータ品質を迅速に検証する。
• 開発者が、アプリケーションがS3に書き込んだデータのスキーマが期待通りであるかを確認する。
• データガバナンス担当者が、特定のS3テーブルに含まれるデータの種類やフォーマットを簡単に監査する。

Amazon CloudWatchが標準メトリクスの監視時にリソースタグをサポート

#

投稿日: 2025年09月25日

AMAZON CLOUDWATCH NOW SUPPORTS RESOURCE TAGS WHEN MONITORING VENDED METRICS

aws.amazon.com

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

#

Amazon CloudWatchが、AWSリソースタグを使用してメトリクスを監視し、アラームを設定するための新しいタグベースのテレメトリーエクスペリエンスをサポートするようになりました。これにより、リソースの変更に合わせてアラームやメトリクス分析が自動的に調整されるため、大規模なクラウドインフラストラクチャの監視が簡素化されます。

何が嬉しいのか

#

DevOpsエンジニアやクラウド管理者は、既存のAWSリソースタグを活用して、組織構造に合わせた動的な監視ビューを作成できるようになります。タグベースのクエリフィルタリングにより、デプロイ後のアラームやダッシュボードの手動更新のオーバーヘッドが不要になり、チームはメンテナンスではなくイノベーションに集中できます。これにより、チームがシステムをどのように整理しているかに合わせた、より迅速で的を絞ったインサイトが得られ、問題のトラブルシューティングが容易になり、運用上の可視性を維持できます。

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

#

• これまで
  • デプロイ後にアラームやダッシュボードを手動で更新する必要があり、運用上のオーバーヘッドが大きかった。
  • リソースの変更に合わせて監視設定を調整するのが困難で、大規模なインフラストラクチャの監視が複雑だった。
  • 組織構造に合わせた動的な監視ビューを作成するのが難しかった。
• これから
  • リソースタグに基づいてアラームやメトリクス分析が自動的に調整されるため、手動更新の必要がなくなる。
  • 既存のAWSリソースタグを使用して、組織構造に合わせた動的な監視ビューを簡単に作成できる。
  • より迅速で的を絞ったインサイトが得られ、問題のトラブルシューティングと運用上の可視性維持が容易になる。

具体的なユースケース

#

• 大規模なクラウドインフラストラクチャの監視を簡素化し、運用効率を向上させる。
• 既存のAWSリソースタグを活用して、組織の部門やアプリケーションごとに動的な監視ダッシュボードやアラームを自動生成する。
• デプロイやリソースの変更後も、アラームやダッシュボードを手動で更新することなく、常に最新の監視状態を維持する。
• 特定のタグを持つリソース群に絞ってメトリクスをクエリし、迅速なトラブルシューティングと問題特定を行う。

Amazon Redshift Concurrency Scaling が10の追加AWSリージョンで利用可能に

#

投稿日: 2025年09月25日

Amazon Redshift Concurrency Scaling is now available in 10 additional AWS Regions

aws.amazon.com

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

#

Amazon Redshift Concurrency Scaling が、AWS アフリカ (ケープタウン)、アジアパシフィック (香港)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (大阪)、アジアパシフィック (タイ)、欧州 (ミラノ)、中東 (バーレーン)、メキシコ (セントラル)、および AWS GovCloud (米国西部) の10の追加AWSリージョンで利用可能になりました。

何が嬉しいのか

#

数千の同時ユーザーと同時クエリをサポートし、一貫して高速なクエリパフォーマンスを提供できるようになります。クエリ処理能力が弾力的にスケールされ、数百の同時クエリに対して一貫して高速なパフォーマンスを提供します。Concurrency Scaling リソースは数秒で透過的にRedshiftクラスターに追加されるため、待機時間を最小限に抑えつつ、同時実行性を高めてクエリを処理できます。ほとんどの顧客の同時実行ニーズに十分な、最大1時間の無料の Concurrency Scaling クレジットを獲得でき、分析需要の変動期間中でも、予測可能な月々のコストで利用できます。

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

#

• これまで
  • これらの新しいリージョンでは、Amazon Redshift Concurrency Scaling が利用できなかったため、同時実行性の高いワークロードを処理する際に、パフォーマンスのボトルネックが発生したり、手動でのリソース管理が必要になったりする可能性がありました。
• これから
  • これらのリージョンでも Concurrency Scaling が利用可能になったことで、数千の同時ユーザーやクエリに対して、自動的かつ弾力的にリソースがスケールされ、一貫して高速なパフォーマンスと予測可能なコストでデータ分析を実行できるようになります。

具体的なユースケース

#

• 多数のユーザーが同時にデータ分析クエリを実行するBIダッシュボードやレポートシステム。
• キャンペーン期間中など、分析需要が一時的に急増するイベントドリブンなデータ分析ワークロード。
• 特定のユーザーグループやワークロードに対して、リソース使用量を細かく制御し、コストを最適化したい場合。

Amazon EC2 C8gn インスタンスが追加リージョンで利用可能に

#

投稿日: 2025年09月25日

AMAZON EC2 C8GN INSTANCES ARE NOW AVAILABLE IN ADDITIONAL REGIONS

aws.amazon.com

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

#

最新世代のAWS Graviton4プロセッサを搭載したAmazon EC2 C8gnインスタンスが、欧州 (フランクフルト、ストックホルム)、アジアパシフィック (シンガポール) リージョンで利用可能になりました。これらのインスタンスは、Graviton3ベースのAmazon EC2 C7gnインスタンスと比較して最大30%優れたコンピューティング性能を提供します。また、最新の第6世代AWS Nitro Cardを搭載し、ネットワーク最適化されたEC2インスタンスの中で最高の最大600 Gbpsのネットワーク帯域幅を提供します。さらに、最大48xlargeのインスタンスサイズ、最大384 GiBのメモリ、Amazon Elastic Block Store (EBS) への最大60 Gbpsの帯域幅を提供し、スケーラビリティが向上しました。特定のインスタンスサイズではElastic Fabric Adapter (EFA) ネットワーキングもサポートします。

何が嬉しいのか

#

強化されたネットワーキング機能により、ネットワーク集約型ワークロードのパフォーマンスとスループットを向上させながら、コストを最適化できます。また、密結合クラスターにデプロイされたワークロードでは、低レイテンシーとクラスターパフォーマンスの改善が期待できます。

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

#

• これまで
  • C8gnインスタンスはこれらのリージョンで利用できず、Graviton3ベースのC7gnインスタンスや他のインスタンスタイプが使用されていました。ネットワーク集約型ワークロードにおいて、C8gnが提供するような高いコンピューティング性能、ネットワーク帯域幅、スケーラビリティは利用できませんでした。
• これから
  • 欧州 (フランクフルト、ストックホルム)、アジアパシフィック (シンガポール) リージョンで、Graviton4プロセッサを搭載したC8gnインスタンスを利用できるようになります。これにより、最大30%向上したコンピューティング性能と最大600 Gbpsのネットワーク帯域幅を活用し、ネットワーク集約型ワークロードのコストパフォーマンスとスケーラビリティを大幅に向上させることが可能になります。

具体的なユースケース

#

• ネットワーク仮想アプライアンス
• データ分析
• CPUベースの人工知能 (AI) および機械学習 (ML) 推論
• 密結合クラスターにデプロイされるワークロード

AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド]

¥3,520

Amazonで見る

Reply by Email