aws_whats_new_2025-08-08 AWS Lambda が GitHub Actions による関数デプロイを簡素化 他

はじめに

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

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

---

OpenSearch UI が SAML 属性による Fine Grained Access Control (FGAC) をサポート

投稿日: 2025年8月8日

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

Amazon OpenSearch Service が、IAM フェデレーション経由でアクセスする OpenSearch UI において、SAML を使用した Fine Grained Access Control (FGAC) をサポートするようになりました。これにより、SAML 認証および認可時に IdP から提供されるユーザー属性に基づいて、属性マッピングを構成し、OpenSearch バックエンドロールに適用できるようになります。これらのロールは、特定の OpenSearch ドメインおよびサーバーレスコレクションにスコープ設定でき、より詳細なデータアクセス制御のためにインデックスレベルの権限やドキュメントレベルのセキュリティを定義できます。

何が嬉しいのか

この機能により、動的かつきめ細やかなアクセス制御が可能になり、マルチテナントデプロイメントや規制産業におけるデータガバナンス要件への対応が容易になります。既存の IdP でユーザーやグループを管理するだけで、OpenSearch データソースの権限が SAML アサーションに基づいて自動的に適用されるため、管理上の手間が軽減されます。さらに、ユーザーのアクションが IAM ロールだけでなく SAML 属性にも紐付けられるため、監査証跡がより明確になり、データガバナンスが簡素化されます。

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

• これまで OpenSearch UI へのアクセスにおいて、SAML 属性に基づいた動的なアクセス制御は直接サポートされていませんでした。マルチテナント環境や規制が厳しい業界でのデータガバナンスの要件を満たすためには、より複雑な設定や管理が必要でした。

• これから SAML 属性マッピングにより、IdP からのユーザーロールや属性に基づいて OpenSearch バックエンドロールを動的に設定できるようになります。これにより、きめ細やかなアクセス制御が可能になり、管理のオーバーヘッドが削減され、セキュリティとコンプライアンスが向上します。

具体的なユースケース

• マルチテナント環境でのデータ分離とアクセス管理
• 金融、医療などの規制産業における厳格なデータガバナンス要件への対応
• ユーザーのロールや属性に基づいた、インデックスレベルおよびドキュメントレベルでのアクセス権限の動的な適用

Amazon EKS がクラスターの誤削除を防ぐための安全制御を追加

投稿日: 2025年8月7日

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

Amazon Elastic Kubernetes Service (EKS) がクラスターの削除保護をサポートするようになり、EKS クラスターの意図しない終了を防ぐのに役立ちます。削除保護が有効になっている場合、クラスターを削除する前に明示的に無効化する必要があります。これにより、重要な環境に対する追加の安全制御が提供されます。

何が嬉しいのか

この機能により、特に複数のユーザーがクラスター管理の責任を共有する環境において、自動化エラーや誤ったコマンドによって意図しない削除が発生するのを防ぐことができます。

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

• これまで
  EKS クラスターは、追加の確認手順なしに直接削除可能であり、誤って削除されるリスクがありました。

• これから
  クラスターを削除するには、まず削除保護を無効化する必要があります。これにより、2段階の検証プロセスが追加され、意図しない削除を防ぎます。

具体的なユースケース

• 重要な EKS クラスターの意図しない終了の防止
• 複数のユーザーがクラスター管理を共有する環境での安全性の向上

AWS Lambda が GitHub Actions による関数デプロイを簡素化

投稿日: 2025年8月7日

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

AWS Lambda が GitHub Actions を使用して、GitHub リポジトリへのコードや設定のプッシュ時に Lambda 関数を自動的にデプロイできるようになりました。これにより、サーバーレスアプリケーションの継続的インテグレーションおよび継続的デプロイメント (CI/CD) パイプラインが合理化されます。

何が嬉しいのか

この機能により、サーバーレスアプリケーションの CI/CD パイプラインが簡素化され、ビルド、テスト、デプロイの自動化が可能になります。手作業による定型コードの繰り返し、新規開発者のオンボーディング時間の増加、デプロイメントエラーのリスクを排除し、コードパッケージング、IAM 統合、エラー処理を自動的に行います。

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

• これまで
  サーバーレスアプリケーションを Lambda で構築する開発チームは、GitHub Actions から Lambda 関数を更新するためにカスタムスクリプトや AWS CLI コマンドを作成する必要がありました。これには、関数コード成果物の手動パッケージング、AWS Identity and Access Management (IAM) の権限設定、エラー処理のセットアップが必要でした。

• これから
  新しい GitHub アクションにより、GitHub Actions ワークフローファイルで宣言的な設定を使用して Lambda 関数への変更をデプロイする簡単な方法が提供され、手動デプロイメント手順の複雑さが解消されます。

具体的なユースケース

• サーバーレスアプリケーションの CI/CD ワークフローの自動化
• GitHub Actions からの Lambda 関数のデプロイ
• 新規開発者向けのデプロイメントの簡素化

今まではCDKやCLIでdeployしてましたよね。
これからはgithub actions で lambdaをdeployする方法が増え、以下のようなアクション定義でdeployできるようになります。

name: Deploy Lambda Function

on:
  push:
    branches: 
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write # Required for OIDC authentication
      contents: read  # Required to check out the repository
    steps:
      - uses: actions/checkout@v3
      
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionRole
          aws-region: us-east-1
      
      - name: Deploy Lambda Function
        uses: aws-actions/aws-lambda-deploy@v1
        with:
          function-name: my-lambda-function
          code-artifacts-dir: ./dist

小さい独立したlambdaだけをdeployする時に便利なのでしょうか。

AWS Outposts サーバーがサービスリンクの静的設定をサポート

投稿日: 2025年8月7日

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

AWS Outposts サーバーが、サービスリンクおよび DNS IP アドレスの静的ネットワーク構成をサポートするようになりました。これにより、インストール中に Outposts サーバーのサービスリンクインターフェイスと DNS IP アドレスを静的 IP アドレスで構成できるようになります。これにより、データセンターでの DHCP サーバーの要件がなくなります。

何が嬉しいのか

この機能は、データセンターで DHCP サーバーを使用できない、厳格なネットワークセキュリティ要件を持つ顧客にとって価値があります。これらの顧客は、セキュリティ基準を維持しながら、サービスリンク接続の IP アドレスを手動で構成できるようになります。

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

• これまで
  AWS Outposts サーバーは、サービスリンクおよび DNS IP アドレスの構成のために、データセンターの DHCP サーバーを必要としていました。

• これから
  顧客は、インストール中に静的 IP アドレスを手動で構成できるようになり、DHCP サーバーが不要になります。

具体的なユースケース

• データセンターで DHCP サーバーの使用が禁止されている、厳格なネットワークセキュリティ要件を持つ顧客
• Outposts サーバーのネットワーク構成の柔軟性とセキュリティの向上

---

Amazon Bedrock がアジアパシフィック (メルボルン) リージョンで利用可能に

投稿日: 2025年8月7日

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

Amazon Bedrockがアジアパシフィック（メルボルン）リージョンで利用可能になりました。これにより、さまざまな基盤モデル（FM）を使用して、生成AIアプリケーションを簡単に構築およびスケールできます。

何が嬉しいのか

セキュリティ、プライバシー、責任あるAIを組み込んだ生成AIアプリケーションを構築するための、ガードレールやモデルのカスタマイズといった幅広い機能を利用できます。これにより、顧客の信頼とデータガバナンスを確保しながら、さまざまな業界の複数のユースケースに合わせたアプリケーションを構築でき、生成AIによる持続的な成長を促進します。

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

• これまで
  アジアパシフィック（メルボルン）リージョンではAmazon Bedrockは利用できませんでした。
• これから
  アジアパシフィック（メルボルン）リージョンでもAmazon Bedrockが利用可能になり、この地域のユーザーはより低いレイテンシーでサービスにアクセスできるようになります。

具体的なユースケース

• さまざまな業界（金融、ヘルスケア、小売など）における、それぞれのニーズに合わせたカスタム生成AIアプリケーションの開発。
• オーストラリア国内のデータレジデンシー要件を満たす必要があるアプリケーションでの利用。

---

Amazon Location のジオフェンシングがマルチポリゴンと除外ゾーンをサポート

投稿日: 2025年8月7日

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

Amazon Location Serviceのジオフェンシングで、マルチポリゴンと除外ゾーンがサポートされるようになりました。これにより、複雑な境界の作成とジオフェンシングが簡素化されます。

何が嬉しいのか

連続していないエリア（例えば、カリフォルニア州の境界とカタリナ島のような沖合の領土を含む）のジオフェンスを作成できます。これにより、より現実に即した複雑な地理的エリアを定義し、管理することが容易になります。これらの強化されたジオフェンスは、既存のワークフローと完全に統合されており、AWSコンソールおよびAPI/SDKを介してプログラムでアクセスできます。

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

• これまで
  複雑な形状や、飛び地を含むような非連続的なエリアのジオフェンスを作成するには、複数のジオフェンスを組み合わせるなど、複雑な管理が必要でした。
• これから
  1つのジオフェンス定義で、マルチポリゴンや除外ゾーンを使って複雑な境界を表現できるようになり、管理が簡素化されます。

具体的なユースケース

• 複数の区画にまたがる配送エリアの定義。
• 公園や湖などを除外した都市部のサービスエリア設定。
• 複数の島を含む行政区画の管理。

---

Amazon EC2 M7i インスタンスが中東 (UAE) リージョンで利用可能に

投稿日: 2025年8月7日

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

第4世代Intel Xeonスケーラブルプロセッサ（コードネーム：Sapphire Rapids）を搭載したAmazon EC2 M7iインスタンスが、中東（UAE）リージョンで利用可能になりました。

何が嬉しいのか

これらのAWS専用カスタムプロセッサは、他のクラウドプロバイダーが利用する同等のx86ベースのIntelプロセッサよりも最大15%優れたパフォーマンスを発揮し、M6iインスタンスと比較して最大15%優れた価格性能を提供します。ゲームサーバー、CPUベースの機械学習（ML）、ビデオストリーミングなど、最大のインスタンスサイズや継続的な高いCPU使用率を必要とするワークロードに最適です。

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

• これまで
  中東（UAE）リージョンではM7iインスタンスは利用できませんでした。
• これから
  中東（UAE）リージョンでもM7iインスタンスが利用可能になり、この地域のユーザーはより高性能なインスタンスを低レイテンシーで利用できるようになります。

具体的なユースケース

• 高性能なゲームサーバーのホスティング
• CPUベースの機械学習推論・トレーニング
• 高品質なビデオストリーミング配信
• データ操作の効率的なオフロードと高速化を促進する組み込みIntelアクセラレータ（Data Streaming Accelerator、In-Memory Analytics Accelerator、QuickAssist Technology）を活用したワークロード

---

AWS Budgets がクロスアカウントのコスト監視のための Billing View をサポート

投稿日: 2025年8月7日

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

AWS BudgetsでBilling Viewがサポートされ、管理アカウントへのアクセスを必要とせずに、複数のメンバーアカウントにまたがる予算を作成できるようになりました。

何が嬉しいのか

この機能強化により、組織のビジネス構造や運用ニーズに合わせて支出の監視をより適切に行えるようになります。コスト配分タグや組織内の特定のAWSアカウントに基づいてフィルタリングされたコスト管理データのビューに基づいて予算を作成できます。例えば、エンジニアリングリーダーはコスト配分タグでフィルタリングされたビューを使用して複数のアカウントにまたがるアプリケーションの予算を作成でき、FinOpsチームはフィルタリングされていないビューを使用して組織全体の予算を作成できます。これにより、管理アカウントへのアクセスを最小限に抑えながらセキュリティのベストプラクティスを維持しつつ、予算管理を合理化できます。

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

• これまで
  複数のアカウントにまたがる予算を作成するには、管理アカウントへのアクセスが必要でした。
• これから
  管理アカウントへのアクセスなしに、Billing Viewを使用してクロスアカウントの予算を作成・管理できるようになります。

具体的なユースケース

• エンジニアリングリーダーが、コスト配分タグでフィルタリングされたビューを使用して、複数のアカウントにまたがるアプリケーションの予算を作成する。
• FinOpsチームが、フィルタリングされていないビューを使用して、組織全体の予算を作成する。

---

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

投稿日: 2025年8月7日

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

最大3.8TBのローカルNVMeベースSSDブロックレベルストレージを備えたAmazon EC2 R7gdインスタンスが、アフリカ（ケープタウン）、アジアパシフィック（ソウル）、ヨーロッパ（ミラノ）、イスラエル（テルアビブ）リージョンで利用可能になりました。

何が嬉しいのか

R7gdインスタンスは、AWS Graviton3プロセッサとDDR5メモリを搭載し、AWS Nitro System上に構築されています。オープンソースデータベース、インメモリキャッシュ、リアルタイムビッグデータ分析などのメモリ集約型ワークロードに最適で、高速・低遅延のローカルストレージへのアクセスが必要なアプリケーションに適しています。同等のGraviton2ベースのインスタンスよりも最大45%向上したリアルタイムNVMeストレージパフォーマンスを提供します。また、Graviton3ベースのインスタンスは、同等のEC2インスタンスと比較して同じパフォーマンスで最大60%少ないエネルギーしか使用しないため、クラウドでの二酸化炭素排出量を削減できます。

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

• これまで
  アフリカ（ケープタウン）、アジアパシフィック（ソウル）、ヨーロッパ（ミラノ）、イスラエル（テルアビブ）リージョンではR7gdインスタンスは利用できませんでした。
• これから
  これらのリージョンでもR7gdインスタンスが利用可能になり、この地域のユーザーは高性能なローカルストレージを備えたインスタンスを低レイテンシーで利用できるようになります。

具体的なユースケース

• オープンソースデータベース（MySQL, PostgreSQLなど）のホスティング
• インメモリキャッシュ（Redis, Memcachedなど）の運用
• リアルタイムビッグデータ分析（Apache Spark, Prestoなど）
• 高速なローカルストレージを必要とするアプリケーション（ビデオエンコーディング、科学技術計算など）

---

Amazon EC2 M7gd インスタンスがアジアパシフィック (ソウル) リージョンで利用可能に

投稿日: 2025年8月7日

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

最大3.8TBのローカルNVMeベースSSDブロックレベルストレージを備えたAmazon EC2 M7gdインスタンスが、アジアパシフィック（ソウル）リージョンで利用可能になりました。

何が嬉しいのか

これらのGraviton3ベースのインスタンスはDDR5メモリを搭載し、AWS Nitro System上に構築されており、高速・低遅延のローカルストレージへのアクセスが必要なアプリケーションに最適です。同等のGraviton2ベースのインスタンスよりも最大45%向上したリアルタイムNVMeストレージパフォーマンスを提供します。また、Graviton3ベースのインスタンスは、同等のEC2インスタンスと比較して同じパフォーマンスで最大60%少ないエネルギーしか使用しないため、クラウドでの二酸化炭素排出量を削減できます。

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

• これまで
  アジアパシフィック（ソウル）リージョンではM7gdインスタンスは利用できませんでした。
• これから
  アジアパシフィック（ソウル）リージョンでもM7gdインスタンスが利用可能になり、この地域のユーザーは高性能なローカルストレージを備えたインスタンスを低レイテンシーで利用できるようになります。

具体的なユースケース

• スクラッチスペース、一時ファイル、キャッシュのための一時的なデータストレージを必要とするアプリケーション
• 高速なローカルストレージを必要とするアプリケーション（ビデオエンコーディング、科学技術計算など）
• メモリ集約型ワークロード（オープンソースデータベース、インメモリキャッシュ、リアルタイムビッグデータ分析など）

R7gdとM7gdインスタンスは、どちらもAWS Graviton3プロセッサとDDR5メモリを搭載し、高速なローカルNVMeストレージを備えたインスタンスです。
一般的なEC2インスタンスの命名規則に基づくと、主な違いは以下の通りです。

• R7gd: メモリ最適化インスタンスファミリーに属します。メモリを大量に消費するワークロード（例：インメモリデータベース、リアルタイムビッグデータ分析）に最適化されています。CPUに対するメモリの比率が高いのが特徴です。
• M7gd: 汎用インスタンスファミリーに属します。コンピューティング、メモリ、ネットワークリソースのバランスが取れており、さまざまなワークロードに対応できます。

M は Multi-purpose、R は RAM の頭文字だと考えると覚えやすいです。

---

Amazon OpenSearch Serverless がハイブリッド検索、AIコネクタ、自動化をサポート

投稿日: 2025年8月7日

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

Amazon OpenSearch Serverlessで、ニューラル検索、ハイブリッド検索、ワークフローAPI、AIコネクタがサポートされるようになりました。これにより、RAG（Retrieval Augmented Generation）やセマンティック検索などのユースケースが容易になります。

何が嬉しいのか

ニューラル検索は、ユーザーがベクトルを直接操作することなく、テキストや画像をそのまま用いてセマンティッククエリを実行できるようにします。ハイブリッド検索は、字句検索、ニューラル検索、k-NN（ベクトル）検索を組み合わせて検索関連性を向上させます。ワークフローAPIを使用すると、モデル、コネクタ、パイプラインなどのOpenSearch AIリソースをテンプレートにパッケージ化して、ニューラル検索などのAI機能を有効にするために必要な複数ステップの設定を自動化し、Amazon Bedrock、Cohere、OpenAI、DeepSeekなどの特定のモデルプロバイダーとの統合を簡素化できます。これにより、開発者はクエリのたびにテキストや画像をベクトルに変換する手間が省け、より直感的に高度な検索機能をアプリケーションに組み込むことができます。

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

• これまで
  RAGや高度なセマンティック検索を実装するには、複雑な設定や外部サービスとの連携を手動で行う必要がありました。
• これから
  OpenSearch Serverless内で直接、ニューラル検索やハイブリッド検索などの高度なAI検索機能を、自動化されたワークフローとAIサービスへのコネクタを通じて簡単に利用できるようになります。

具体的なユースケース

• 大規模言語モデルと連携した、より高度なRAGアプリケーションの構築
• テキストや画像を使ったセマンティック検索機能の実装
• 複数の検索手法を組み合わせた、精度の高い検索システムの開発

ベクトル化しなくてもセマンティック検索ができるようになるんですね。
取捨選択して使用すればいいのでいろいろな方法が提供されるのは嬉しいですね。

---

Amazon EC2 M7i および M7i-flex インスタンスがアジアパシフィック (大阪) リージョンで利用可能に

投稿日: 2025年8月6日

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

第4世代Intel Xeonスケーラブルプロセッサ（コードネーム：Sapphire Rapids）を搭載したAmazon EC2 M7iおよびM7i-flexインスタンスが、アジアパシフィック（大阪）リージョンで利用可能になりました。

何が嬉しいのか

• M7i-flexインスタンス: ほとんどの汎用ワークロードで価格性能のメリットを簡単に得られる方法です。M6iインスタンスと比較して最大19%優れた価格性能を提供します。M7i-flexインスタンスは、largeから16xlargeまでの最も一般的なサイズを提供し、Webサーバー、アプリケーションサーバー、仮想デスクトップ、バッチ処理、マイクロサービスなど、すべてのコンピューティングリソースを完全には利用しないアプリケーションに最適です。
• M7iインスタンス: M6iインスタンスと比較して最大15%優れた価格性能を提供します。M7iインスタンスは、大規模なゲームサーバー、CPUベースの機械学習（ML）、ビデオストリーミングなど、最大のインスタンスサイズや継続的な高いCPU使用率を必要とするワークロードに最適です。

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

• これまで
  大阪リージョンではM7iおよびM7i-flexインスタンスは利用できませんでした。
• これから
  大阪リージョンでもこれらのインスタンスが利用可能になり、西日本のユーザーはより低レイテンシーで高性能なインスタンスを利用できるようになります。

具体的なユースケース

• M7i-flex: Webサーバー、アプリケーションサーバー、仮想デスクトップ、バッチ処理、マイクロサービス
• M7i: 大規模なゲームサーバー、CPUベースの機械学習、ビデオストリーミング、データ操作の効率的なオフロード

---

AWS Private CA が FIPS エンドポイントへの AWS PrivateLink サポートを拡張

投稿日: 2025年8月6日

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

AWS Private Certificate Authority (AWS Private CA) が、商用AWSリージョンおよびAWS GovCloud (US) リージョンで利用可能なすべてのAWS Private CA FIPSエンドポイントでAWS PrivateLinkをサポートするようになりました。

何が嬉しいのか

これにより、パブリックインターネット経由で接続する代わりに、仮想プライベートクラウド (VPC) と AWS Private CA FIPS エンドポイント間にプライベート接続を確立できます。これは、パブリックインターネット接続を制限するという組織のビジネス、コンプライアンス、および規制要件を満たすのに役立ちます。

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

• これまで
  AWS Private CA の FIPS エンドポイントへの接続は、パブリックインターネットを経由する必要がありました。
• これから
  AWS PrivateLink を使用して VPC から直接プライベートに接続できるようになり、セキュリティとコンプライアンスが向上します。

具体的なユースケース

• 高いセキュリティ要件を持つ政府機関や金融機関などが、プライベートネットワーク内で証明書を管理する。
• コンプライアンス要件により、パブリックインターネットへのアクセスが厳しく制限されている環境での証明書発行・管理。

---

AWS Private CA が FIPS エンドポイントへの AWS PrivateLink サポートを拡張

投稿日: 2025年8月6日

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

AWS Private Certificate Authority (AWS Private CA) が、商用AWSリージョンおよびAWS GovCloud (US) リージョンで利用可能なすべてのAWS Private CA FIPSエンドポイントでAWS PrivateLinkをサポートするようになりました。

何が嬉しいのか

これにより、パブリックインターネット経由で接続する代わりに、仮想プライベートクラウド (VPC) と AWS Private CA FIPS エンドポイント間にプライベート接続を確立できます。これは、パブリックインターネット接続を制限するという組織のビジネス、コンプライアンス、および規制要件を満たすのに役立ちます。

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

• これまで
  AWS Private CA の FIPS エンドポイントへの接続は、パブリックインターネットを経由する必要がありました。
• これから
  AWS PrivateLink を使用して VPC から直接プライベートに接続できるようになり、セキュリティとコンプライアンスが向上します。

具体的なユースケース

• 高いセキュリティ要件を持つ政府機関や金融機関などが、プライベートネットワーク内で証明書を管理する。
• コンプライアンス要件により、パブリックインターネットへのアクセスが厳しく制限されている環境での証明書発行・管理。

FIPS とは機密情報を保護する暗号化モジュールに関するセキュリティ要件を規定する米国およびカナダの政府の規格です。

https://aws.amazon.com/jp/compliance/fips/

FIPSエンドポイントでは、通常のAWSエンドポイントと異なり、FIPS準拠の暗号モジュールでTLS通信が行われます。またエンドポイントURLに -fips が付きます。（例：https://dynamodb-fips.us-east-1.amazonaws.com）

さいごに

OpenSearchの開発が活発ですね。LLMと相性が良いからでしょうか。FGAC、ハイブリッド検索、AIコネクタなど使えるシーンが多そうです。

他にはEC2のインスタンスタイプの追加のニュースが多いです。

個人的にはlambdaをgithub actionsから簡単にdeployできるようになったのが気になりますが、用途はあまりピンとこないですね。