0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

aws_whats_new_2025-08-06 SQSの最大メッセージペイロードサイズが1MiBに拡張 他

Posted at

はじめに

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

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


Amazon RDS io2 Block Expressがすべての商用リージョンで利用可能に

投稿日: 2025年8月5日

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

Amazon RDS io2 Block Expressボリュームが、AWS GovCloud (US)リージョンとAWS Chinaリージョンを除くすべての商用リージョンで利用可能になりました。Amazon RDS io2 Block Expressボリュームは、ミッションクリティカルなワークロードに対して一貫したサブミリ秒のレイテンシを提供します。

何が嬉しいのか

  • 高性能なデータベースワークロードへの対応: 高性能、高スループット、一貫した低レイテンシを要求する重要なデータベースワークロードに対応
  • 業界トップクラスの性能: 主要クラウドプロバイダーの中で最も低いp99.9のI/Oレイテンシと優れた外れ値レイテンシ制御を実現
  • 高耐久性: 99.999%の耐久性を提供
  • 大容量対応: 最大64 TiBのボリュームサイズをサポート
  • 高スループット: 4,000 MB/sのスループットを実現
  • 高IOPS: 最大256,000のプロビジョンドIOPSを提供
  • コスト効率: Amazon RDS io1ボリュームと同じ価格で利用可能
  • ダウンタイムなしのアップグレード: ModifyDBInstance APIを使用して、Amazon RDS io1ボリュームからio2 Block Expressへのアップグレードをダウンタイムなしで実行可能

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

  • これまで

    • io2 Block Expressは一部のリージョンでのみ利用可能で、リージョン選択に制限があった
    • ミッションクリティカルなワークロードに対しては、リージョンの制約により最適なストレージ選択ができない場合があった
  • これから

    • ほぼすべての商用リージョンでio2 Block Expressが利用可能になり、グローバルなワークロード配置が容易に
    • リージョンの制約に左右されずに、一貫した高性能ストレージをすべての商用リージョンで利用可能

具体的なユースケース

  • 大規模なトランザクション処理: 銀行システムやECサイトなどでの大量トランザクション処理
  • リアルタイム分析: リアルタイムでのデータ分析とレポート生成
  • 高頻度なデータベース操作: 高頻度な読み書きを伴うアプリケーション
  • ミッションクリティカルな業務システム: 停止が許されない重要な業務システムのデータベース

最も低いp99.9のI/Oレイテンシ が理解できなかったのですが、99.9パーセンタイルのレイテンシがその他のメジャーなクラウドプロバイダと比較して最も低いということですね。具体的な数値は示されていませんでした。

AWS Parallel Computing ServiceがIPv6をサポート

投稿日: 2025年8月5日

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

AWS Parallel Computing Service (PCS)がSlurmエンドポイントでInternet Protocol Version 6 (IPv6)をサポートするようになりました。これにより、顧客はIPv6のみまたはデュアルスタックのAmazon Virtual Private Cloud (VPC)でワークロードを実行できるようになります。

何が嬉しいのか

  • IPv6コンプライアンス要件の満たしやすさ: IPv6コンプライアンス要件を満たすことが可能になる
  • 柔軟なネットワーク構成: IPv6のみまたはIPv4/IPv6デュアルスタック環境でのワークロード実行が可能
  • HPCワークロードの簡素化: 高性能コンピューティング(HPC)ワークロードの実行とスケーリングが容易に
  • 使い慣れた環境での作業: Slurmを使用した科学技術モデルの構築が可能
  • 運用負担の軽減: マネージドアップデートと組み込みの監視機能によりクラスタ運用が簡素化

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

  • これまで

    • PCSはIPv4環境でのみ利用可能で、IPv6環境での利用ができなかった
    • IPv6コンプライアンス要件を満たすために追加のネットワーク設定が必要だった
  • これから

    • IPv6ネイティブ環境やデュアルスタック環境でPCSを直接利用可能
    • 追加のネットワーク変換やトンネリングなしでIPv6ワークロードを実行できる

具体的なユースケース

  • IPv6ネイティブのHPC環境: 次世代ネットワーク環境での高性能計算
  • 政府機関や大企業のIPv6移行: IPv6必須要件を持つ組織でのHPCワークロード
  • モダンな研究環境: 最新のネットワークプロトコルを活用した学術研究
  • グローバルな科学計算: 国際的な研究プロジェクトでの大規模並列計算

AWS Elastic BeanstalkがFIPS 140-3対応のインターフェースVPCエンドポイントをサポート

投稿日: 2025年8月5日

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

AWS Elastic Beanstalkが、Federal Information Processing Standard (FIPS) 140-3プログラムで検証されたVPCEエンドポイントをサポートするようになりました。FIPS 140-3検証済みの暗号モジュールを使用して安全な接続を必要とする場合に、AWS PrivateLinkを使用してElastic Beanstalkエンドポイントに簡単にアクセスできるようになりました。

何が嬉しいのか

  • FIPSセキュリティ要件の満たしやすさ: 米国連邦政府と契約する企業がFIPSセキュリティ要件を満たすことが可能に
  • 機密データの暗号化: サポートされるリージョンで機密データの暗号化要件を満たせる
  • セキュアな接続: FIPS 140-3検証済みの暗号モジュールを使用した安全な接続が可能
  • 米国商用リージョンでの利用: 米国のすべてのAWS商用リージョンで利用可能

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

  • これまで

    • Elastic BeanstalkはFIPS 140-3対応のVPCエンドポイントをサポートしておらず、セキュリティ要件を満たすのが困難だった
    • FIPS要件を満たすために追加のセキュリティ設定や回避策が必要だった
  • これから

    • FIPS 140-3検証済みのVPCエンドポイントを直接利用可能になり、コンプライアンス要件を簡単に満たせる
    • AWS PrivateLinkを通じてセキュアな接続を標準的な方法で実現可能

具体的なユースケース

  • 政府関係のシステム開発: 米国連邦政府との契約におけるアプリケーション開発
  • 金融機関のコンプライアンス対応: 厳格なセキュリティ要件を満たす金融系アプリケーション
  • 機密情報を取り扱う企業システム: 社内外の機密データを扱う業務システム
  • セキュリティ重視のWebアプリケーション: 高度なセキュリティが求められるWebサービスのデプロイ

AnthropicのClaude Opus 4.1がAmazon Bedrockで利用可能に

投稿日: 2025年8月5日

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

AnthropicのClaude Opus 4.1がAmazon Bedrockで利用可能になりました。Claude Opus 4.1はAnthropicの現時点での最も知能的なモデルで、コーディングとエージェント分野で業界をリードしています。

何が嬉しいのか

  • 優れた性能と精度: Opus 4のドロップインリプレースメントとして、現実世界のコーディングとエージェントタスクで優れた性能と精度を提供
  • 高度なコーディング機能: 複雑なエンドツーエンドの開発タスクを独立して計画・実行し、スタイルに適応しながら高品質を維持
  • 改善されたフロントエンドコード生成: 複雑なロジックを効果的に処理しながら、強力なビジュアル出力品質を提供
  • 長期タスク処理能力: 長期的な推論と長 chains of actions に適した理想的なバーチャルコラボレーター
  • AIエージェント性能の向上: 複雑なマルチステップタスクをピーク精度で処理するエージェントを可能に
  • 幅広い応用分野: エージェント検索・研究、コンテンツ作成、メモリとコンテキスト管理に優れる

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

  • これまで

    • Amazon BedrockではClaude Opus 4が利用可能だったが、より高度な機能を求めていた
    • 複雑な開発タスクや長期的な推論が必要な場合、既存モデルでは限界があった
  • これから

    • Claude Opus 4.1により、より高度なコーディング能力とエージェント性能を活用可能
    • 複雑なロジック処理や長期的なタスク管理がより効率的に実行可能

具体的なユースケース

  • ソフトウェア開発: 複雑なアプリケーション開発の自動化と支援
  • AIエージェント構築: 高精度なマルチステップタスクを処理するAIエージェントの開発
  • コンテンツ作成: 高品質なコンテンツの自動生成と編集
  • 研究開発: 複雑な研究課題の分析と洞察の合成
  • ビジネス分析: 大規模データの包括的な分析とレポート作成

Amazon Elastic VMware Service (Amazon EVS)が一般提供開始

投稿日: 2025年8月5日

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

Amazon Elastic VMware Service (Amazon EVS)が一般提供開始され、Amazon Virtual Private Cloud (Amazon VPC)内で直接VMware Cloud Foundation (VCF)を実行できるようになりました。

何が嬉しいのか

  • 既存スキルの活用: 使い慣れたVCFソフトウェアと既存のスキルを維持しながらAWSのスケール、弾性、パフォーマンスを活用可能
  • 再構築不要: 移行中にアプリケーションの再プラットフォーム化や再設計の必要がなくなります
  • 柔軟な管理選択: インフラストラクチャをセルフ管理するか、AWSパートナーの専門知識を活用してVCF環境を管理・運用可能
  • 完全な管理アクセス: クラウドでのVMwareアーキテクチャを完全に制御し、環境への完全な管理アクセスを保持
  • 柔軟な統合: 好みの外部ストレージ、バックアップ、災害復旧ソリューションを統合可能
  • 柔軟な消費モデル: オンデマンド、1年、3年オプションなど柔軟な消費モデルでコスト最適化を実現
  • ライセンス移植性: VCFライセンスをAmazon EVSに持ち込むことが可能
  • 200以上のAWSサービス利用: 次世代AI機能から基本的なコンピュート、ストレージ、データベースサービスまで200以上の完全機能サービスを利用可能

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

  • これまで

    • VMware環境をAWS上で実行するには、既存のVMwareスキルや環境を活用しつつ移行する手段が限られていた
    • 移行時にアプリケーションの再構築や再設計が必要になる場合があった
  • これから

    • Amazon EVSにより、既存のVMware環境をそのままAWS上で実行可能になり、移行が容易に
    • セルフ管理またはパートナー管理の選択肢により、柔軟な運用が可能

具体的なユースケース

  • VMware環境のクラウド移行: 既存のVMwareワークロードをAWSへシームレスに移行
  • ハイブリッドクラウド構築: オンプレミスとクラウド間で一貫したVMware環境を維持
  • 災害復旧環境の構築: AWS上にVMwareベースのDR環境を迅速に構築
  • 一時的なワークロード対応: 需要変動に応じてVMwareワークロードをスケールアウト
  • 開発・テスト環境の構築: 本番と同等のVMware環境をAWS上で迅速に構築

AWS Resource Explorerが120の新しいリソースタイプをサポート

投稿日: 2025年8月5日

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

AWS Resource Explorerが、Amazon API Gateway, Amazon Bedrock, Amazon Kendra, Amazon Sagemakerなどを含むサービスから120の新しいリソースタイプをサポートするようになりました。

サポートされるようになったリソースタイプは以下の通りです。

  1. apigateway:restapis/deployments
  2. apigateway:restapis/resources/methods
  3. apigateway:restapis/resources
  4. apigateway:restapis/stages
  5. apigateway:apis
  6. apigateway:apis/routes
  7. apigateway:apis/stages
  8. appmesh:mesh/virtualGateway/gatewayRoute
  9. appmesh:mesh/virtualRouter/route
  10. appmesh:mesh/virtualGateway
  11. appmesh:mesh/virtualRouter
  12. apprunner:autoscalingconfiguration
  13. apprunner:connection
  14. autoscaling:autoScalingGroup
  15. backup-gateway:hypervisor
  16. batch:job-definition
  17. bedrock:agent
  18. bedrock:application-inference-profile
  19. bedrock:data-automation-project
  20. bedrock:flow
  21. bedrock:guardrail
  22. bedrock:knowledge-base
  23. bedrock:prompt
  24. bedrock:prompt-router
  25. chime:app-instance
  26. chime:app-instance/bot
  27. chime:app-instance/user
  28. chime:media-insights-pipeline-configuration
  29. chime:media-pipeline
  30. chime:media-pipeline-kinesis-video-stream-pool
  31. chime:sma
  32. chime:vc
  33. config:config-rule
  34. connect:instance/operating-hours
  35. dms:cert
  36. eks:eks-anywhere-subscription
  37. eks:podidentityassociation
  38. emr-containers:jobtemplates
  39. emr-containers:virtualclusters/endpoints
  40. emr-containers:securityconfigurations
  41. events:api-destination
  42. gamelift:script
  43. guardduty:detector
  44. guardduty:malware-protection-plan
  45. guardduty:detector/publishingDestination
  46. inspector2:filter
  47. iot:billinggroup
  48. iot:fleetmetric
  49. iot:scheduledaudit
  50. iot:thinggroup
  51. iot:thingtype
  52. iotfleethub:application
  53. iotsitewise:access-policy
  54. iotsitewise:portal
  55. iotsitewise:project
  56. iotwireless:Destination
  57. iotwireless:DeviceProfile
  58. iotwireless:FuotaTask
  59. iotwireless:MulticastGroup
  60. iotwireless:SidewalkAccount
  61. iotwireless:WirelessDevice
  62. iotwireless:WirelessGateway
  63. iotwireless:WirelessGatewayTaskDefinition
  64. ivs:playback-key
  65. kendra:index/access-control-configuration
  66. kendra:index/data-source
  67. kendra:index/faq
  68. kendra:index/featured-results-set
  69. kendra:index/query-suggestions-block-list
  70. kendra:index/thesaurus
  71. kendra:index/experience
  72. kinesisvideo:channel
  73. license-manager:grant
  74. mediapackage-vod:assets
  75. mediastore:container
  76. mediatailor:channel
  77. mediatailor:liveSource
  78. memorydb:snapshot
  79. mobiletargeting:templates/SMS
  80. mobiletargeting:templates/PUSH
  81. mobiletargeting:templates/EMAIL
  82. mq:configuration
  83. profile:domains
  84. proton:environment-template
  85. proton:service-template
  86. redshift:hsmclientcertificate
  87. s3:multiregionaccesspoint
  88. sagemaker:action
  89. sagemaker:algorithm
  90. sagemaker:app
  91. sagemaker:artifact
  92. sagemaker:code-repository
  93. sagemaker:context
  94. sagemaker:endpoint-config
  95. sagemaker:experiment
  96. sagemaker:experiment-trial
  97. sagemaker:experiment-trial-component
  98. sagemaker:human-task-ui
  99. sagemaker:image-version
  100. sagemaker:inference-component
  101. sagemaker:inference-experiment
  102. sagemaker:model-package-group
  103. sagemaker:model-package
  104. sagemaker:model-card
  105. sagemaker:notebook-instance-lifecycle-config
  106. sagemaker:project
  107. sagemaker:space
  108. sagemaker:user-profile
  109. sagemaker:workforce
  110. sagemaker:cluster
  111. sagemaker:flow-definition
  112. sagemaker:hub
  113. sagemaker:mlflow-tracking-server
  114. sagemaker:studio-lifecycle-config
  115. sagemaker:workteam
  116. ses:dedicated-ip-pool
  117. ssm:session
  118. synthetics:canary
  119. transfer:server
  120. transfer:user

何が嬉しいのか

  • 検索範囲の拡大: AWS環境全体で検索できるリソースの種類が大幅に増加し、リソースの発見と管理が容易になります。
  • 主要サービスのサポート強化: API Gateway, Bedrock, Kendra, SageMakerなどの重要なサービスのリソースが検索対象となり、これらのサービスを利用した開発や運用が効率化されます。
  • 迅速なリソース特定: タグや名前、IDなどを使って、多種多様なリソースを迅速に特定できるようになります。

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

  • これまで

    • Resource Explorerで検索できるリソースタイプは限られており、サポートされていないリソースは各サービスのコンソールやCLIで個別に探す必要があった。
    • 特に新しいサービスや複雑なサービスのリソース管理が煩雑だった。
  • これから

    • 120の新しいリソースタイプが追加されたことで、より多くのリソースを単一の検索インターフェースから横断的に検索できるようになる。
    • アカウントやリージョンをまたいだリソースの可視性が向上し、管理が簡素化される。

具体的なユースケース

  • API管理: 特定のAPI Gatewayのデプロイメントやリソースを素早く検索。
  • AI/MLリソース管理: Amazon Bedrockのエージェントやナレッジベース、Amazon SageMakerのモデルや実験などを一元的に検索。
  • エンタープライズサーチ: Amazon Kendraのインデックスやデータソースを効率的に管理。
  • インシデント対応: 問題が発生した際に、関連するリソースを迅速に特定し、影響範囲を把握。
  • コスト管理: 特定のプロジェクトやチームに関連するリソースを検索し、コスト配分を分析。

AWS IoT SiteWiseがアセットモデルインターフェースを導入

投稿日: 2025年8月5日

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

AWS IoT SiteWiseにアセットモデルインターフェースが導入されました。これにより、産業顧客は同様の機器やプロセスタイプ間で標準化されたプロパティとメトリクスを定義・維持しつつ、機器のバリエーションに対応する柔軟性を保つことができます。

何が嬉しいのか

  • データモデリングの標準化: 複数のアセットタイプにわたって必要なプロパティとメトリクスを定義する標準化されたインターフェースを作成できます。
  • 一貫性の確保: インターフェースがテンプレートとして機能し、データモデリングの一貫性を確保しながら、個々のアセットが独自の特性を維持できます。
  • 管理の簡素化: 自動プロパティマッピング、標準化されたメトリック計算、簡素化されたロールアップメトリック管理により、産業オペレーション全体のデータ集約と分析が容易になります。
  • スケーラビリティの向上: AWS IoT SiteWiseアセットモデルのプロパティと階層のサービスクォータが増加し、より大規模な産業オペレーションをサポートします。

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

  • これまで

    • プロパティ、メトリクス、階層を個々のアセットモデルレベルで定義する必要があり、数百または数千のアセットにスケールする際にプロセスが煩雑でした。
    • 類似の機器間で定義を再利用するのが難しく、一貫性の維持が困難でした。
  • これから

    • 標準化されたインターフェースを使用して、複数のアセットタイプに共通の定義を一度に行うことができます。
    • データモデリングの一貫性が向上し、大規模なアセット群の管理が簡素化されます。

具体的なユースケース

  • 製造業: 同じ種類の製造ラインにある異なるメーカーの機器を、標準化されたインターフェースでモデル化し、パフォーマンスを比較分析する。
  • エネルギー産業: 風力タービンなど、多数の類似アセットの監視とメンテナンスを標準化し、運用効率を向上させる。
  • スマートビルディング: ビル内の複数のHVACユニットを共通のインターフェースで管理し、エネルギー消費を最適化する。
  • プロセス産業: 化学プラントなどの複雑なプロセスにおいて、類似の反応器やポンプのデータを標準化し、プロセス全体の効率を分析する。

AWS IoT Site Wiseとは

AWS IoT SiteWise は産業機器からのデータの大規模な収集、保存、整理、モニタリングを簡単にし、より優れた意思決定をデータに基づき行えるようにするマネージド型サービスです。AWS IoT SiteWise を使用すれば、全施設にわたる運用のモニタリングや、一般的な産業パフォーマンスメトリクスの迅速なコンピューティングが可能なほか、産業機器データを分析するアプリケーションを作成して、コストのかさむ機器の問題を予防したり、生産のギャップを減らしたりできます。

https://aws.amazon.com/jp/iot-sitewise/

Systems Manager Run Commandが環境変数へのパラメータ補間をサポート

投稿日: 2025年8月5日

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

AWS Systems Manager (SSM) Run Commandで、コマンド実行前にパラメータを環境変数に補間できるようになりました。

何が嬉しいのか

  • コマンドインジェクションの防止: パラメータをリテラル文字列として扱うことで、意図しないコマンドインジェクションを防ぎやすくなります。
  • スクリプトの可読性向上: コマンド内に直接パラメータを埋め込むのではなく、環境変数として渡すことで、スクリプトがクリーンになり、可読性が向上します。
  • パラメータ管理の簡素化: 複雑なコマンドや複数のパラメータを扱う際に、環境変数を利用することで管理が容易になります。

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

  • これまで

    • パラメータはコマンド文字列に直接埋め込む必要があり、特殊文字のエスケープ処理などが煩雑で、コマンドインジェクションのリスクがありました。
    • スクリプトが複雑になりがちで、メンテナンス性が低い場合がありました。
  • これから

    • パラメータを安全に環境変数として渡し、スクリプト内で参照できるようになります。
    • SSM Command Documentのスキーマバージョン2.2以上と、SSM Agentバージョン3.3.2746.0以上を使用することで、この機能を利用できます。

具体的なユースケース

  • 安全なパッチ適用: パッチ適用の対象となるパッケージ名やバージョンをパラメータとして渡し、スクリプト内で安全に利用する。
  • 設定ファイルの動的生成: データベースの接続情報などをパラメータとして渡し、環境変数経由で設定ファイルに書き込む。
  • ユーザー入力の安全な処理: ユーザーが入力した値をパラメータとして受け取り、コマンドインジェクションのリスクを低減しながらスクリプトを実行する。

Amazon ECRがリポジトリあたり100,000イメージをサポート

投稿日: 2025年8月4日

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

Amazon Elastic Container Registry (ECR) が、リポジトリあたり100,000イメージをサポートするようになりました。これは以前の制限である20,000から増加しました。

何が嬉しいのか

  • スケーラビリティの向上: 成長ニーズに合わせて、より多くのイメージを単一のリポジトリで管理できるようになります。
  • 時間節約: 100,000イメージに達するまで制限緩和をリクエストする必要がなくなり、時間を節約できます。
  • 柔軟性: 100,000イメージ以上が必要な場合でも、追加の増加をリクエストする柔軟性が維持されます。

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

  • これまで

    • 1つのリポジトリに保存できるイメージは最大20,000でした。
    • 20,000を超えるイメージを保存するには、制限緩和のリクエストが必要でした。
  • これから

    • デフォルトで1つのリポジトリに100,000イメージまで保存可能になります。
    • この新しい制限は、既存のレジストリにも既に適用されています。

具体的なユースケース

  • 大規模なCI/CDパイプライン: 頻繁にビルドが行われ、多数のコンテナイメージが生成される大規模な開発プロジェクト。
  • マルチテナントアプリケーション: 各テナントごとに多数のイメージバージョンを管理する必要があるSaaSアプリケーション。
  • 長期的なイメージ保管: 長期間にわたって多数のイメージバージョンをアーカイブする必要があるプロジェクト。

Amazon OpenSearch Serverless がバックアップとリストアに対応しました

投稿日: 2025年8月5日

記事のリンク: https://aws.amazon.com/jp/about-aws/whats-new/2025/08/amazon-opensearch-serverless-backup-restore/

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

Amazon OpenSearch Serverless でバックアップと復元のサポートが追加されました。システムはアカウント内のすべてのコレクション/インデックスを自動的に毎時間バックアップします。バックアップは14日間保持され、API を使用してインデックスを復元できます。この機能は自動的に有効になり、ユーザーによる設定は不要です。

何が嬉しいのか

この機能により、OpenSearch Serverless ユーザーは、バックアップの自動化と簡単な復元機能により、データ保護と災害復旧を簡素化できます。

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

  • これまで
    手動でのバックアップと復元プロセスは複雑であったか、利用できませんでした。
  • これから
    毎時間の自動バックアップが14日間保持され、API を介して復元が可能になります。この機能は自動的に有効になります。

具体的なユースケース

  • 災害復旧: 誤って削除または破損した場合にデータを復元する。
  • コンプライアンス: ポイントインタイムバックアップを持つことで、データ保持ポリシーを満たす。
  • 開発/テスト: テスト目的でデータの以前の状態を簡単に復元する。

Amazon SQS が最大メッセージペイロードサイズを 1 MiB に拡張

投稿日: 2025年8月4日

記事のリンク: https://aws.amazon.com/jp/about-aws/whats-new/2025/08/amazon-sqs-max-payload-size-1mib/

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

Amazon Simple Queue Service (Amazon SQS) で、最大メッセージペイロードサイズが 256 KiB から 1 MiB に増加しました。これにより、顧客は Amazon SQS 標準キューおよび FIFO キューを通じて、より大きなメッセージを送受信できるようになります。AWS Lambda の SQS 用イベントソースマッピングも 1 MiB ペイロードをサポートするように更新されました。

何が嬉しいのか

この増加により、顧客はデータをオフロードしたりメッセージを分割したりする必要なく、最大 1 MiB のメッセージペイロードを送受信できるようになります。これにより、個々のメッセージでより大量のデータを交換する必要があるアプリケーション統合、IoT、人工知能 (AI) のユースケースが簡素化されます。Lambda との統合により、これらのより大きなペイロードのシームレスな処理も保証されます。

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

  • これまで
    最大メッセージペイロードサイズは 256 KiB でした。
  • これから
    標準キューおよび FIFO キューで、最大メッセージペイロードサイズが 1 MiB になりました。Lambda 統合もこれらのより大きなペイロードをサポートします。

具体的なユースケース

  • アプリケーション統合: マイクロサービス間でより大きなデータペイロードを送信する。
  • IoT: IoT デバイスからより多くのデータを単一のメッセージで送信する。
  • AI/ML: より大きなデータセットやモデルパラメータをメッセージで交換する。
  • バッチ処理: より大きなデータバッチを処理のために送信する。

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

投稿日: 2025年8月5日

記事のリンク: https://aws.amazon.com/jp/about-aws/whats-new/2025/08/amazon-ec2-c8g-instances-available-additional-regions/

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

Amazon Elastic Compute Cloud (Amazon EC2) の C8g インスタンスが、アジアパシフィック (ソウル、ジャカルタ、ハイデラバード、バンコク) リージョンで利用可能になりました。これらのインスタンスは AWS Graviton4 プロセッサを搭載し、AWS Graviton3 ベースのインスタンスと比較して最大 30% 高いパフォーマンスを提供します。Amazon EC2 C8g インスタンスは、ハイパフォーマンスコンピューティング (HPC)、バッチ処理、ゲーム、ビデオエンコーディング、科学モデリング、分散分析、CPU ベースの機械学習 (ML) 推論、広告配信などのコンピューティング集約型ワークロード向けに構築されています。これらのインスタンスは、CPU仮想化、ストレージ、およびネットワーク機能を専用のハードウェアとソフトウェアにオフロードすることで、ワークロードのパフォーマンスとセキュリティを強化する AWS Nitro System 上に構築されています。

何が嬉しいのか

  • パフォーマンス向上: AWS Graviton4 プロセッサにより、Graviton3 ベースのインスタンスと比較して最大 30% 高いパフォーマンスを実現します。
  • コンピューティング集約型ワークロードへの対応: HPC、バッチ処理、ゲーム、ビデオエンコーディングなど、CPU パワーを大量に必要とするワークロードに最適です。
  • AWS Nitro System による強化: 高いパフォーマンスとセキュリティを提供します。
  • より大きなインスタンスサイズ: Graviton3 ベースの Amazon C7g インスタンスと比較して、最大 3 倍の vCPU とメモリを備えたインスタンスサイズが利用可能です。
  • 幅広いワークロードへの最適化: データベース、Web アプリケーション、大規模 Java アプリケーションなどで、Graviton3 プロセッサよりも高速なパフォーマンスを発揮します。
  • ネットワークと EBS の帯域幅: 最大 50 Gbps の拡張ネットワーキング帯域幅と、Amazon Elastic Block Store (Amazon EBS) への最大 40 Gbps の帯域幅を提供します。

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

  • これまで
    • EC2 C8g インスタンスは、指定されたアジアパシフィック地域では利用できませんでした。
  • これから
    • AWS Graviton4 プロセッサを搭載した EC2 C8g インスタンスが、アジアパシフィック (ソウル、ジャカルタ、ハイデラバード、バンコク) リージョンで利用可能になり、パフォーマンスと機能が向上しました。

具体的なユースケース

  • ハイパフォーマンスコンピューティング (HPC)
  • バッチ処理
  • ゲーム
  • ビデオエンコーディング
  • 科学モデリング
  • 分散分析
  • CPU ベースの機械学習 (ML) 推論
  • 広告配信

さいごに

SQSのペイロードサイズが1MiBに拡張されるのは、設計の幅が広がりそうですね。とは言え程度問題になるので、根本的にそこに頼るのはかなりきちんとした設計が必要にはなりそうです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?