AWS What's New Digest

Appearance

2026年09月18日 ​

[Bedrock] The new AgentCore Runtime is now available in Amazon Bedrock AgentCore ​

概要 ​

Amazon Bedrock AgentCore の次世代 AgentCore Runtime (V2) が一般提供開始されました。メモリの動的割当・解放とスナップショットベースの起動により、コスト低減とコンテナイメージサイズに依存しない一貫したコールドスタートを実現します。

変更内容・新機能の詳細 ​

新しい AgentCore Runtime (V2) は serverless なマイクロVM 実行環境で、以下の主要機能を提供します。

  • Elastic メモリ管理: 各セッションは小さな初期メモリプロファイルで開始し、ワークロードの需要に応じて追加メモリを動的に割り当てます。使用されなくなったメモリはセッション終了まで保持せずに再利用（reclaim）されるため、ピークではなく実際の使用量に基づいて課金される可能性があります。

  • スナップショットによる一貫したコールドスタート: 初回にエージェント環境を準備してスナップショットを作成し、新しいインスタンスはそのスナップショットを復元する方式により、コンテナイメージサイズや同時性に依存しない一貫したコールドスタート時間を実現します。テストでは、200MB〜2GB のイメージで P75 コールドスタートが 1.9–2.0 秒（旧 V1 は 5.4–30 秒）と報告されています。

  • serverless モデルの継承: プロビジョニング不要、スケール・トゥ・ゼロ、ハードウェアで強制されるセッション分離（マイクロVM による隔離）、使った分だけ支払う課金モデルは継続。V2 によりこれらがより低コストかつ高速に動作します。

  • 利用方法: ランタイム作成または更新時に platformVersion を "V2" に設定して有効化します。

  • リージョン: us-east-1, us-east-2, us-west-2, eu-west-1, ap-northeast-1 で利用可能。

影響範囲・利用シーン ​

  • 対象ユーザー: Bedrock AgentCore を使ってエージェントやカスタムコンテナを実行する開発者、SRE、プラットフォーム運用チーム
  • 利用シーン: レイテンシに敏感なエージェント起動（インタラクティブAPI、リアルタイム推論）、バースト的なワークロード、イメージサイズが大きいコンテナを使う場合の起動改善
  • 運用効果: メモリ使用に基づく料金がピークではなく実使用量に近づくためコスト削減が期待でき、コールドスタートのばらつきが減ることで SLA 達成やユーザ体験が安定化する

技術的な注意点 ​

  • IAM権限: ランタイムの作成/更新には Bedrock/AgentCore の作成権限が必要です。既存のポリシーで platformVersion の指定が許可されているか確認してください
  • リージョン制限: 現時点での利用可能リージョンは us-east-1, us-east-2, us-west-2, eu-west-1, ap-northeast-1 のみ
  • 設定方法: 新規作成または既存ランタイム更新時に platformVersion を "V2" に設定して有効化します
  • 互換性/アプリ変更点: 起動時の初期化処理がスナップショットに含まれるため、初回の初期化とスナップショット復元後の初期化の差異に注意してください（起動時に生成される一時データやホスト固有の設定をスナップショットに含めない等、初期化処理を冪等にすることを推奨）
  • コスト: メモリがオンデマンドで割当・解放されるため従来より低コストとなる可能性がありますが、正確な料金体系は AgentCore の料金ページで確認してください（ワークロード特性によっては効果が限定的です）
  • モニタリング: メモリ使用量の増減やコールドスタート時間を監視し、必要に応じてメモリリクエスト/上限やアプリケーションのメモリ使用パターンを調整してください
  • デバッグ: スナップショット復元により初回フル起動のログが再現されない場合があるため、初期化ロギングやヘルスチェックの設計を見直してください

参考情報 ​

概要 ​

AWS PrivateLinkに新しいVPCエンドポイント型「トンネルエンドポイント」が追加され、別のVPC／アカウント内のネットワークセグメント（CIDR）へプライベートかつ安全にトンネリングしてアクセスできるようになりました。リソース単位での共有をせずにセグメント単位でアクセス権を付与できます。

変更内容・新機能の詳細 ​

トンネルエンドポイントは新しいタイプのVPCエンドポイントで、作成者がResource ConfigurationとしてVPC内のCIDRレンジを定義し、それをAWS Resource Access Manager（RAM）で他アカウント（例：外部ベンダー）に共有することで利用できます。アクセス側のアカウントは共有を受けてトンネルエンドポイントを作成し、GENEVE（汎用トンネリング）でカプセル化して共有先VPC内の指定CIDRへトンネルを張り、当該CIDR内に配置されたデータベースやアプライアンス等のリソースへIPレベルでアクセスできます。これにより、従来の“リソースごとのResource Configuration作成”が不要になり、セグメント単位での一括共有が可能になります。課金はトンネルエンドポイントの時間課金（時間単位）と、処理したデータ量に対するGB単位課金が発生します。機能は多数のリージョンで利用可能（記事記載の地域一覧を参照）で、詳細／導入手順はAWS PrivateLinkの公式ドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: マルチアカウント環境で外部ベンダーや別アカウントへネットワークアクセスを提供するクラウド/ネットワークエンジニア、SRE、マネージドサービス事業者
  • 利用シーンまたは効果: ベンダー向けの限定的なネットワークアクセス（例えば運用用ツール、監視エージェント、DBアクセスなど）を個別リソースではなくCIDR単位で共有して管理負荷を下げる
  • 運用効果: リソース単位での繰り返し共有作業を削減し、アクセス管理が単純化。プライベート経路での接続によりセキュリティが向上。ただし時間課金＋データ転送課金があるためコスト管理が必要

技術的な注意点 ​

  • IAM権限: RAMの共有操作やエンドポイント作成に関する権限が必要（例: ram:CreateResourceShare, ram:AcceptResourceShareInvitation, ec2:CreateVpcEndpoint, ec2:DeleteVpcEndpoints 等）。導入前に最小権限のIAMポリシーを設計してください
  • リージョン制限: 本機能は限定リージョンで利用可能（US East (N. Virginia)、US East (Ohio)、US West (N. California)、US West (Oregon)、Africa (Cape Town)、Asia Pacific各リージョン（Hong Kong, Hyderabad, Jakarta, Malaysia, Melbourne, Mumbai, Osaka, Seoul, Singapore, Sydney, Tokyo）、Canada (Central), Canada West (Calgary), Europe各リージョン（Frankfurt, Ireland, London, Milan, Paris, Spain, Stockholm, Zurich）、Mexico (Central), South America (São Paulo)）。実際の利用可否はコンソール/ドキュメントで最新情報を確認してください
  • コスト: トンネルエンドポイントは時間単位の稼働料金と、トンネルを通過するデータ量に対するGB単位の料金が発生します。長時間常時接続や大量データ転送はコスト増につながるため設計段階で見積もりを行ってください
  • ネットワーク設定: トンネルはGENEVE（デフォルトUDPポート6081が使われることが一般的）を使用するため、セキュリティグループ／NACLで該当UDPポートを許可する必要がある場合があります。また、アクセス先でのセキュリティグループ、NACL、ルートテーブルがトンネル経由のトラフィックを許可していることを確認してください
  • 名前解決 / DNS: トンネルはIPレベルのアクセスを提供するため、必要に応じてPrivate Hosted Zoneや内部DNSを設定する必要があります（従来のPrivateLinkのエンドポイントDNS挙動とは異なる運用になる可能性があります）
  • CIDRとルーティング考慮: 共有するCIDRレンジは設計上重複がないように管理してください。オーバーラップがあるとルーティングや到達性に問題が生じます
  • セキュリティ運用: トンネル先のアクセスはCIDR単位で許可されるため、最小アクセス原則を適用し、ログ取得（フローログ等）やモニタリングを併用して不正アクセスを検知してください

参考情報 ​

[Elastic Load Balancing] AWS Transfer Family now supports source IP preservation for SFTP servers behind a Network Load Balancer (NLB) ​

概要 ​

AWS Transfer Familyが、VPCホスト型エンドポイントのSFTPサーバーをNLB（Network Load Balancer）の背後に配置した際に、Proxy Protocol v2 (PPv2) を使ってクライアントのソースIPを保持できるようになりました。これによりログやカスタムIDプロバイダーで実際のクライアントIPを利用できるようになります。

変更内容・新機能の詳細 ​

技術的には、Transfer FamilyのSFTPサーバーごとに「ソースIP保持」を有効にすると、NLBが送信するProxy Protocol v2ヘッダからクライアントの元の送信元IPを受け取り、Transfer Familyのログ・イベントおよび認証時にカスタムIDプロバイダーへそのIPを渡すようになります。従来はNLBがクライアントのソースIPを自身のプライベートIPに置き換えてしまったため、Transferのログやイベント、認可フローではNLBのアドレスが記録されていました。本機能により、IPベースのアクセス制御、監査、コンプライアンス要件を満たすために実際のクライアントIPを利用できます。設定は各Transfer Familyサーバー単位でコンソール、AWS CLI、またはAPIから有効化可能です。NLB側はPPv2を送出するように設定しておく必要があります。この記事公開時点では、Transfer Familyが利用可能な全リージョンで本機能が提供されています。

影響範囲・利用シーン ​

  • 対象ユーザー: SFTPをNLB経由で運用しているクラウドエンジニア、セキュリティ/監査担当者、DevOpsチーム
  • 利用シーン: IPベースのアクセス制御や認可（例: カスタムIDプロバイダーでクライアントIPに基づく許可判定）、監査ログの正確な記録、フォレンジック調査
  • 運用効果: ログやイベントに実際のクライアントIPが記録されることで、不正アクセス検出やコンプライアンス証跡の信頼性が向上し、IP条件による細かい認可ポリシーが適用可能になる
  • セキュリティ: Geo-blockingやIPレピュテーションベースのブロックなど、ソースIPに依存するセキュリティ対策が正常に機能するようになる

技術的な注意点 ​

  • IAM権限: Transfer Familyサーバーの変更（UpdateServer）や、NLBの属性変更を行うIAM権限が必要です。CLI/SDK操作を行うIAMロール/ユーザーに該当権限を付与してください
  • NLB設定: NLB側でProxy Protocol v2を有効にする必要があります。NLBはTCP(SSH/SFTP)を透過する構成で、ターゲットにPPv2を送信するよう設定してください
  • セキュリティグループ/ネットワークACL: NLB経由でクライアントの実IPがバックエンドに到達するため、セキュリティグループやNACLのルールがクライアントIPを許可するよう適切に設定する必要があります
  • カスタムIDプロバイダー: 認可処理でクライアントIPを参照する場合、プロバイダー側のロジックやマッピングがTransferから渡されるソースIPを期待する形式で受け取れるように確認・調整してください
  • ログ/監査: ソースIPはTransfer Familyのログ・イベントに記録されますが、CloudWatch LogsやS3へのログ出力設定が有効であることを確認してください
  • リージョン制限: AWS Transfer Familyが利用可能な全リージョンで本機能が利用可能です（記事公開時点）
  • コスト: 本機能自体に追加料金は明示されていませんが、NLBの利用やデータ転送、ログ保存（CloudWatch/S3）に伴う通常の料金が発生します
  • 互換性/制約: Proxy Protocol v2はTCP向けのヘッダです。NLBがPPv2を送信するよう正しく設定されていることが前提であり、プロキシ設定が不整合だと接続/認証に影響が出る可能性があります

参考情報 ​

[Omics] AWS HealthOmics now supports IAM session policies ​

概要 ​

AWS HealthOmicsがIAMセッションポリシーをサポートしました。これにより、個々の実行（run）ごとに権限を絞り込み、テナントごとや単発のジョブごとに専用のIAMロールを作成・管理する必要がなくなります。

変更内容・新機能の詳細 ​

IAMセッションポリシーはそのセッション（ここでは単一のHealthOmics実行）に適用されるインラインポリシーで、基礎となるサービスロールの権限を変更せずに実行時の最大許可範囲を制限します。実行時の有効な権限は、識別子ベースのポリシー（ロールやユーザーに付与されたポリシー）とセッションポリシーの「共通部分（intersection）」になります。これにより、マルチテナント環境では、各テナントのS3バケットへのアクセスをそのテナント用の専用ロールを作ることなくセッションポリシーで限定したり、単一実行に対して特定のS3オブジェクトへの一時的アクセスのみを許可するといった運用が可能です。HealthOmicsはHIPAA準拠が可能なサービスであり、今回の機能は機密データへのアクセス分離や最小特権の実装を容易にします。IAMセッションポリシーのサポートは、HealthOmicsが利用可能なすべてのリージョン（US East (N. Virginia, Ohio)、US West (Oregon)、Europe (Frankfurt, Ireland, London)、Israel (Tel Aviv)、Asia Pacific (Tokyo, Singapore, Seoul)）で利用可能です。設定方法や使い方はAWS HealthOmicsのユーザーガイドのPermissionsセクションを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: ヘルスケア/ライフサイエンスの開発者、SRE、プラットフォーム運用者、マルチテナントSaaS提供者
  • 利用シーン: テナント単位でS3アクセスを限定するマルチテナントワークフロー、単一実行に対する一時的なオブジェクトアクセス付与、機密データへのアクセス分離
  • 運用効果: IAMロールの数を削減して管理負荷を軽減し、実行ごとの最小権限を適用してセキュリティ境界（blast radius）を小さくできる
  • コンプライアンス効果: HIPAA対応ワークフローで実行単位のアクセスを細かく制御でき、監査やデータ分離要件の実現が容易になる

技術的な注意点 ​

  • IAM権限: 実行を開始する主体がsts:AssumeRole等の適切な権限を持っている必要があります。また、セッションポリシーは基礎ロールの権限を超えて権限を付与できないため、基礎ロール側に必要な権限が事前に付与されていることを確認してください。
  • リージョン制限: 本機能はHealthOmicsが提供されているリージョン（US East (N. Virginia, Ohio)、US West (Oregon)、Europe (Frankfurt, Ireland, London)、Israel (Tel Aviv)、Asia Pacific (Tokyo, Singapore, Seoul)）で利用可能です。その他のリージョンでは未対応の可能性があるため、使用前にドキュメントで確認してください。
  • ポリシーの制限: セッションポリシーにはサイズや構文の制限があります（IAM/STSの仕様に依存）。ポリシーが複雑すぎる場合は分割や簡素化を検討してください。セッションポリシーはあくまで「権限の絞り込み」であり、基礎ポリシーで許可されていない操作は付与できません。
  • 監査・ログ: 実行ごとのアクセスを追跡するためにCloudTrailやS3アクセスログ、HealthOmicsの実行ログを併用して監査記録を残すことを推奨します。
  • コスト: 本機能自体による追加料金は明示されていませんが、運用ポリシー変更に伴う管理コスト削減やIAM運用の簡素化は期待できます。権限設定ミスによる意図しないデータアクセスを避けることでリスク低減に寄与します。

参考情報 ​

[General] AWS Batch now supports bulk job cancellation and termination ​

概要 ​

AWS Batchが一度に最大50件のジョブをキャンセルまたは終了できるバルク操作をサポートしました。複数ジョブに対する単一API呼び出しで個別の結果を受け取れるため、大規模バッチ運用の運用負荷を低減します。

変更内容・新機能の詳細 ​

新たに CancelJobs、TerminateJobs、TerminateServiceJobs の3つのAPIが追加され、いずれも一度に最大50件のジョブIDを受け付けます。CancelJobsはSUBMITTED、PENDING、RUNNABLE状態のジョブに対して使用し、TerminateJobs/TerminateServiceJobsはSTARTINGやRUNNINGを含む任意の状態のジョブを強制終了できます。これらは単一のレスポンスでジョブごとの処理結果（成功・失敗など）を返します。個別ジョブだけでなく配列ジョブ(array jobs)にも対応しています。さらに、ListJobs APIはisCancelledとisTerminatedフィールドを返すようになり、ListServiceJobsはisTerminatedフィールドを返すようになったため、ジョブのライフサイクル状態を取得しやすくなっています。これらの機能はAWS CLIおよびAWS SDK経由で利用可能で、AWS Batchが利用可能な全リージョンで有効です。

影響範囲・利用シーン ​

  • 対象ユーザー: バッチワークロードを大量に運用するSRE/運用チーム、データ処理パイプライン担当者
  • 利用シーン: 大量のジョブを一括でキャンセル・終了したい場合（障害対応、誤投入ジョブの一括中止、ジョブ群のロールバック等）
  • 運用効果: 手動またはループで個別APIを叩く必要がなくなり、オペレーション手順が簡潔に。ジョブ単位の結果がまとまって得られるため自動化・監査が容易になる

技術的な注意点 ​

  • IAM権限: CancelJobs/TerminateJobs/TerminateServiceJobsを呼び出すためのbatch:CancelJobs、batch:TerminateJobs、batch:TerminateServiceJobs等の権限が必要
  • API制限: 1リクエストあたり最大50件のジョブIDを指定可能（これを超える場合は分割して呼び出す必要あり）
  • 状態制約: CancelJobsはSUBMITTED、PENDING、RUNNABLE状態に対して使用。TerminateJobsおよびTerminateServiceJobsはSTARTINGやRUNNINGを含む任意状態に対して使用可能
  • 配列ジョブ対応: 個別ジョブとarray jobsの両方に対応。配列ジョブを部分的に指定する場合はジョブIDの取り扱いに注意
  • レスポンス: 単一レスポンスでジョブごとの結果を返す（成功/失敗の詳細はAPIレスポンスを確認）
  • CLI/SDK: AWS CLIおよび各言語のAWS SDKから利用可能。CLIコマンド名はドキュメント参照
  • リージョン制限: AWS Batchが利用可能な全リージョンで提供（ただしリージョンごとのサービス可否は事前確認推奨）
  • コスト: これらのAPI自体に追加料金は想定されないが、既に実行済みのジョブに対する計算リソース使用分の料金は返金されない点に注意
  • その他注意点: 大量ジョブの一括操作は意図しないジョブ停止につながるリスクがあるため、事前にジョブ一覧の状態確認やテスト環境での検証を推奨

参考情報 ​

[Ec2] Introducing Amazon EC2 T8i instances ​

概要 ​

Amazon EC2の低コストバースタブルインスタンス「T8i」が一般提供開始されました。第6世代のカスタムIntel Xeon 6プロセッサと第6世代Nitroカードを採用し、従来のT3より価格性能比が最大30%向上しています。

変更内容・新機能の詳細 ​

T8iインスタンスはAWS専用のカスタム第6世代Intel Xeon 6プロセッサを搭載し、第6世代AWS Nitroカード上で動作するバースタブル（Tシリーズ）ファミリの新世代です。提供サイズは nano、micro、small、medium の4種で、T3世代比で最大70%高い計算性能、ネットワーク帯域は1.25倍、EBS帯域は2.4倍向上するとされています。CPUクレジット方式はT3と同じくStandardおよびUnlimitedモードをサポートするため、既存のT3ユーザーは操作を変えずに移行でき、より良い価格性能によるTCO低減が期待できます。T8i.micro と T8i.small はAWS Free Tier対象。購入は現時点でオンデマンドとスポットが利用可能で、Savings Planは近日対応予定です。対応リージョンは米東（北バージニア、オハイオ）、米西（オレゴン、北カリフォルニア）、欧州（フランクフルト、アイルランド、ロンドン、パリ）、アジア太平洋（ハイデラバード、マレーシア、ムンバイ、ソウル、シンガポール、シドニー、東京）、カナダ（中部）等。主に低〜中程度のCPU利用率を想定したワークロード（データ処理、ログインゲートウェイ、小規模DB、バッチ、イベント駆動関数、CI/CD、マイクロサービス、低トラフィックWebなど）に最適化されています。

影響範囲・利用シーン ​

  • 対象ユーザー: 低〜中程度CPU負荷の一般的なクラウドワークロードを運用する開発者、SRE、システム管理者、スタートアップ
  • 利用シーン: 小規模データ処理、ログイン/認証ゲートウェイ、小規模データベースやキャッシュ、バッチ処理、CI/CDランナー、マイクロサービス、低〜中トラフィックのWebサイトやAPIホスティング
  • 運用効果: T3からの移行で同等または低コストで性能向上（最大30%の価格性能改善、計算性能最大70%向上）を狙えるため、インスタンスコスト削減とレスポンス改善が期待できる
  • 導入判断: 新規環境やオンプレ移行のエントリポイントとしてコスト効率が高く、Free Tier対象サイズを使って評価検証が容易
  • リージョン影響: 公開されているリージョンで利用可能だが、利用予定のリージョンや可用ゾーンでのリソース供給状況は事前確認が必要

技術的な注意点 ​

  • IAM権限: インスタンス起動・タイプ変更には通常のEC2起動／変更権限（ec2:RunInstances, ec2:ModifyInstanceAttribute 等）が必要です
  • リージョン制限: 記載のリージョン（米東、米西、欧州、アジア太平洋、カナダ中部）で提供。その他リージョンは未対応の可能性があるため事前確認を推奨
  • コスト: T3より価格性能比は改善するが利用量・モード（Standard/Unlimited）やEBS/ネットワーク利用によって総コストは変動します。Savings Planは近日対応予定のため長期割引を使う場合は時期を確認
  • CPUクレジット: T3と同じCPUクレジット方式（Standard/Unlimited）を引き継ぐため、バースト挙動やクレジット消費設計は従来と同様です
  • 購入オプション: 現時点でオンデマンドとスポットが利用可能。リザーブドインスタンス/Savings Planの対応状況は今後の発表をチェックしてください
  • 互換性/移行: T3ベースの運用設計（クレジット想定、スケーリングポリシー等）は基本的にそのまま利用可能。ただし実際のCPU/ネットワーク/ストレージパフォーマンスは向上するため、モニタリング設定やアラート閾値は見直し推奨
  • 注意点: AZごとの在庫状況やインスタンスタイプ上限（アカウントクォータ）により即時起動できない場合があります。特にスポットは可用性変動があるため重要バッチ等は冗長化設計を検討

参考情報 ​

AI要約はOpenAI APIによって生成されています。

Copyright © 2026