AWS What's New Digest

Appearance

2026年10月06日 ​

概要 ​

AWS Certificate Manager (ACM) が ACME 公開証明書の発行で AWS PrivateLink をサポートしました。VPC インターフェイスエンドポイント経由で ACME 発行トラフィックを AWS ネットワーク内に留めて、プライベート経路で証明書の要求・更新が可能になります。

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

ACM は ACMEv2 互換クライアントによる公開 TLS 証明書の発行で AWS PrivateLink をサポートします。利用手順は概ね次のとおりです：まず ACM でマネージド ACME エンドポイントを作成し、その後 VPC コンソール／AWS CLI／CloudFormation を使って標準の VPC インターフェイスエンドポイントを作成します。VPC 内の Private DNS により既存の ACME ディレクトリ URL が自動的にインターフェイスエンドポイントのプライベート IP に解決されるため、既存の ACME クライアント設定やディレクトリ URL に変更は不要です。アカウント作成、オーダー作成、ドメイン検証、ファイナライズ、証明書取得といった発行処理は PrivateLink 経由で流れ、全て ACM コンソールから確認でき、AWS CloudTrail ログや Amazon CloudWatch メトリクスも使用可能で監査性が確保されます。サービスは全ての商用 AWS リージョンで利用可能です。コスト面では VPC インターフェイスエンドポイントに対する標準の PrivateLink 料金が適用され、ACM の課金体系も別途適用されます。既に ACME を利用しているケースではクライアント側の設定変更は不要で移行が容易です。

影響範囲・利用シーン ​

  • 対象ユーザー: インフラ/セキュリティ/SRE チーム、プライベートネットワーク運用者、コンプライアンス要件でアウトバウンド制限がある組織
  • 利用シーンまたは効果: 社内 VPC から公開 TLS 証明書を発行・更新する際にトラフィックをインターネット経由ではなく AWS ネットワーク内に閉じることで、ネットワークセキュリティとコンプライアンスを強化
  • 運用効果: クライアント設定の再構成不要で既存の ACME ワークフローをそのまま PrivateLink 経由に移行可能、CloudTrail/CloudWatch による監査ログやメトリクスで可視化が維持される
  • コスト影響: VPC インターフェイスエンドポイントの PrivateLink 料金が発生（リージョン・時間・データ転送に依存）、既存の ACM 課金は継続適用

技術的な注意点 ​

  • IAM権限: VPC エンドポイント作成（ec2:CreateVpcEndpoint 等）および ACM の ACME 操作に必要な権限を付与してください
  • Private DNS: インターフェイスエンドポイント作成時に Private DNS を有効にすることで既存の ACME ディレクトリ URL が自動解決されます。Private DNS を無効にした場合はクライアント側で DNS 設定が必要です
  • ネットワーク構成: インターフェイスエンドポイントは ENI をサブネットに配置します。選択するサブネット、セキュリティグループ、NACL がエンドポイント通信を許可するよう設定してください
  • ACME クライアント互換性: ACMEv2 準拠クライアントは基本的に再設定不要ですが、ネットワークや DNS ポリシーによってはクライアント側の接続先解決動作を確認してください
  • リージョン制限: 記事時点で全ての商用 AWS リージョンで利用可能とされています。AWS GovCloud や中国リージョン等の特殊リージョンは個別に確認してください
  • 監査/ログ: 発行操作は ACM コンソールで確認でき、CloudTrail と CloudWatch メトリクスにより監査とモニタリングが可能です
  • コスト: PrivateLink（インターフェイスエンドポイント）に対する標準料金が適用されます。ACM 自体の課金も別途適用されるためコスト試算を行ってください

参考情報 ​

[Redshift] Amazon Redshift adds support for creating and refreshing Apache Iceberg materialized views ​

概要 ​

Amazon RedshiftがApache Iceberg形式のマテリアライズドビュー（MV）の作成とリフレッシュをサポートしました。MVの結果はS3上のIcebergテーブルとして保存され、Glue Data Catalogに登録されるため、他のIceberg対応エンジンから即座に参照できます。

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

主な機能は以下のとおりです。Redshiftで CREATE MATERIALIZED VIEW ... USING ICEBERG の構文を使ってマテリアライズドビューを作成すると、集計や高コストな結合の結果を一度計算してApache Icebergテーブル（S3上）に格納します。格納された結果はAmazon Athena、Apache Spark（EMR/AWS Glue上）、Trino、Snowflakeなど、Iceberg互換のどのエンジンからでも読み取り可能です。Redshift側では変更分だけを再計算する「インクリメンタル（差分）リフレッシュ」を手動で行えるため、大量データの全再計算を避けられます。生成されるIcebergテーブルはGlue Data Catalogに登録されるため、データカタログ管理や探索（データガバナンス）が容易です。さらに、最もパフォーマンスを重視するダッシュボード向けには、これらのテーブルをRedshift Managed Storage（RMS）に取り込み、ネイティブRMSマテリアライズドビューとして利用することも可能です。対応リージョンはRedshift ServerlessおよびGravitonプロビジョンドインスタンスをサポートするリージョンとされています。

影響範囲・利用シーン ​

  • 対象ユーザー: データエンジニア、データプラットフォームチーム、BI/アナリティクスユーザー、SRE/運用チーム
  • 利用シーン: 高コストな結合・集計を一度だけ計算して複数ユーザー／ツールで共有する分析パイプライン、単一エンジンでのETL→集計→配信を完結させたいワークフロー、Iceberg互換エンジン間でのデータ共有
  • 運用効果: 同じ集計を複数チームが繰り返し実行することを防ぎ、クエリ負荷とコストを低減。パイプラインのエンジン差異によるセマンティックのズレを軽減し、データ共有が容易に

技術的な注意点 ​

  • IAM権限: S3（PutObject、ListBucket 等）、AWS Glue（CreateTable/UpdateTable等）、およびRedshiftでのCREATE MATERIALIZED VIEW実行権限が必要。Lake Formationを使う場合は追加の権限設定が必要となる可能性あり
  • リージョン制限: Redshift ServerlessおよびプロビジョンドGravitonインスタンスをサポートするリージョンで利用可能（地域によって未対応の可能性あり）
  • コスト: S3ストレージ、Glue Data Catalogのエントリー、Redshiftのクエリ／ストレージ（およびRMSに取り込む場合はRMSコスト）が発生。リフレッシュ処理はコンピュートコストを消費
  • 更新方式: 現状は「差分を再計算する手動インクリメンタルリフレッシュ」。自動継続更新（常時バックグラウンド更新）は明示されていないため、更新トリガやスケジューリングはユーザー側で管理する必要あり
  • 互換性と発見性: 出力は標準的なIcebergテーブルであり、他エンジンから読み取り可能。ただし各エンジンのIcebergサポート状況やバージョン差により一部機能（例えばメタデータの扱い、時間旅行や削除のサポート）に違いが出る可能性あり
  • 運用上の注意: パーティション設計やIcebergの書き込みプロパティがパフォーマンスに影響するため、スキーマ・パーティション戦略を検討すること。大量リフレッシュ時はS3とGlueカタログへの負荷やコストを考慮すること

参考情報 ​

[Bedrock] GLM 5.3 by Z.ai is now generally available on Amazon Bedrock ​

概要 ​

Amazon BedrockでZ.aiのGLM 5.3が一般提供（GA）になりました。エージェント的なコーディングや長期のソフトウェア工学ワークに適した大規模モデルが、AWSのセキュリティ／コンプライアンス下で利用可能になっています。

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

GLM 5.3はZ.aiのフラッグシップで、Mixture-of-Experts（MoE）アーキテクチャを採用し合計7530億パラメータ（トークンあたりアクティブになるのは約400億パラメータ）を持ちます。GLM 5.2と同じ基礎モデルをベースに、スケール後のポストトレーニングで改良されています。主な技術仕様として、コンテキストウィンドウは最大100万トークン（1,000,000トークン）、出力は最大128Kトークンまで対応します。推論時には“reasoning（推論）”が常に有効で、複数の努力レベル（effort levels）を選べるため、レイテンシとトークン消費量を性能とトレードオフできます。Bedrock側のサポートとしては、システムプロンプトやメッセージに対する明示的なプロンプトキャッシュ（キャッシュポイント）を提供し、複数のモデル呼び出しで文脈を再利用する際の入力コストとレイテンシを低減できます。配布は対象のエンタープライズ顧客向けで、USおよびGlobalのクロスリージョン推論プロファイル経由でアクセス可能です。利用はAmazon BedrockコンソールまたはサポートされているBedrock API経由で行えます。リージョン、エンドポイント、対応API、機能、推論プロファイル、料金詳細は公式のAmazon Bedrockドキュメントを参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: エンタープライズの開発チーム、AI研究者、SRE/運用チーム、ソフトウェアエンジニア（特に大規模コードベースや長文ドキュメントを扱うチーム）
  • 利用シーン: エージェント駆動の自動コーディング、リファクタリングや大規模なコードベースの解析、長期会話・長文ドキュメントの要約と推論、テストケース生成や設計支援など長ホライズンのソフトウェア工学タスク
  • 運用効果: 大きなコンテキストウィンドウと高性能推論により、複数ファイル/長文を跨いだ一貫した推論が可能。プロンプトキャッシュにより繰り返し利用時のレイテンシと入力トークンコストを削減できる
  • 制約/導入条件: 提供は対象のエンタープライズ顧客に限定されるため、利用には事前のアクセス許可や契約が必要。利用可能リージョンは限定（USおよびGlobalクロスリージョンプロファイル）されている点に注意

技術的な注意点 ​

  • IAM権限: Bedrockのモデル利用には適切なIAMポリシー／ロールが必要。モデルアクセスと推論用API呼び出しの権限を事前に確認してください
  • リージョン制限: GLM 5.3は対象エンタープライズ向けで、USおよびGlobalクロスリージョン推論プロファイル経由での提供。全リージョンで利用可能とは限りません。ドキュメントで対応リージョン／エンドポイントを確認してください
  • コスト: 1Mトークンのコンテキストや最大128K出力はトークンコストに大きく影響します。MoEの設計によりトークンあたりアクティブパラメータは限定されますが、推論の努力レベルや出力量により料金が増大するため事前に見積もり・モニタリングを行ってください。プロンプトキャッシュは入力トークンコスト削減に有効です
  • API／エンドポイント: Bedrockコンソールのほか、サポートされるAmazon Bedrock APIでプログラム的に利用可能。使用するAPI、エンドポイント、推論プロファイルはドキュメントで確認してください
  • 動作特性: 努力レベルの選択でレイテンシ／品質のトレードオフが発生します。MoE由来の出力非決定性やレスポンス時間のばらつきに留意し、必要に応じてベンチマークやA/Bテストを実施してください
  • 推奨運用: 大きなコンテキストを活かすためにプロンプト設計とキャッシュ戦略を整備し、コストとレイテンシを管理するためのメトリクス（トークン消費、レイテンシ、エラー率）を監視してください

参考情報 ​

[Iam Identity Center] AWS IAM Identity Center now supports network access controls for Identity Store ​

概要 ​

AWS IAM Identity Center（Identity Store）は、Identity Store API と SCIM API に対して送信元ネットワークに基づくアクセス制御をサポート開始しました。VPCエンドポイント、ソースVPC、IPレンジを使って各APIごとに異なる制限を適用できます（既定は無効）。

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

Identity Store はユーザーとグループ情報を保持し、カスタムアプリやプロビジョニングワークフローは Identity Store API を、外部アイデンティティプロバイダは SCIM API を利用して同期します。今回の追加機能により以下が可能です:

  • Identity Store API に対して、許可したアカウント/組織の VPC エンドポイント経由のみ、または特定のソース VPC からのリクエストのみを許可。
  • Identity Store API および SCIM API の両方について、特定の IP 範囲からのリクエストのみを許可（各 API に対して別々の制限を設定可能）。
  • 同一設定内で API ごとに異なるアクセス要件を適用可能（例：Identity Store API は VPC エンドポイント必須、SCIM は外部IdPの公開 IP レンジ許可）。
  • ネットワークアクセス制御は任意機能でデフォルトはオフ。AWS が代行して実行するサービス側のリクエストは例外として免除されます。
  • 設定は Identity Store API を通じて AWS SDK または AWS CLI で行います。
  • 本機能は IAM Identity Center が提供されているすべての AWS リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: IAM Identity Center を利用してユーザー/グループ管理や自動プロビジョニングを行うクラウドエンジニア、SRE、ID管理チーム
  • 利用シーン: カスタムアプリやプロビジョニングワークフローからの Identity Store API 呼び出しを社内ネットワークや特定の VPC だけに限定する場合、外部 IdP（SCIM）からの同期を特定 IP レンジのみに制限する場合
  • 運用効果: ID 関連 API へのアクセスをネットワーク層で限定することで攻撃面を縮小し、コンプライアンス要件（アクセス元制御）やセキュリティポリシーに対応可能

技術的な注意点 ​

  • IAM権限: ネットワークアクセス設定を変更するには Identity Store API を呼べる IAM 権限（Identity Center/Identity Store の更新権限）が必要です。最小権限での設定を推奨します。
  • 設定手段: 現時点では AWS SDK / AWS CLI から Identity Store API を使って設定します。コンソールでの設定は案内されていません（記事記載の通り）。
  • デフォルト/例外: ネットワークアクセス制御はオプションでデフォルトはオフ。AWS サービスが代行して行うリクエストは適用除外となります。
  • VPCエンドポイント/コスト: VPC エンドポイント（Interface VPC Endpoint / PrivateLink）を利用する場合、エンドポイント作成・データ転送に対する料金が発生します。コスト影響を事前に確認してください。
  • IPレンジ/外部IdP対応: 外部 IdP が SCIM を使う場合、その公開 IP レンジをホワイトリストに追加する必要があります（動的 IP の場合は注意）。
  • ソースVPC/組織: アカウントまたは組織内の許可済み VPC エンドポイントやソース VPC を指定できます。クロスアカウント構成時はネットワーク設計と権限を確認してください。
  • 運用上の注意: 誤った制限設定はプロビジョニングやアプリのユーザー取得を遮断する可能性があるため、ステージング環境で検証したうえで本番適用を行ってください。
  • リージョン制限: 記事によれば IAM Identity Center が提供されるすべてのリージョンで利用可能とされていますが、利用するリージョンでのサービス提供状況を念のため確認してください。

参考情報 ​

[General] AWS Continuum for Penetration Testing now supports continuous penetration testing integrated directly into your CI/CD pipeline ​

概要 ​

AWS Continuum for Penetration Testing（旧AWS Security Agent）がパブリックプレビューでCI/CDパイプラインに直接統合され、ペネトレーションテストをデプロイ時の自動検証に移行できます。開発者はパイプライン出力で所見（重大度、影響エンドポイント、修復ガイダンス）を受け取り、自動再検証までパイプライン内で完結します。

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

主な変更は、継続的ペネトレーションテストを既存のCI/CDワークフローに直接組み込める点です。パブリックプレビューとして提供され、サービスはデプロイ時にテストを実行して所見をパイプライン出力へ返します。導入は自動生成されるパイプラインスニペットを既存パイプラインへ貼り付けるだけで、初期設定は数分で完了します。初回実行時にアプリケーションコンテキストを自動でブートストラップするため、事前の完全なペネトレーションテストは不要です。非セキュリティ変更ではパイプラインに大きな遅延を発生させず、修復後はパイプラインが自動で再テストして検証を行います。開発者は発見事項の重大度、影響を受けるエンドポイント、具体的な修復手順を受け取り、セキュリティ専門家でなくても利用可能です。これによりセキュリティ検証が“左寄せ（shift-left）”され、デプロイ頻度の高い開発サイクルでも継続的に脆弱性検出と修復確認が行えます。

影響範囲・利用シーン ​

  • 対象ユーザー: アプリ開発チーム、SRE/運用チーム、セキュリティエンジニア
  • 利用シーン: CI/CDパイプライン内でのデプロイ時自動ペネトレーションテスト（デイリーや頻繁なデプロイに伴う継続的検査）
  • 運用効果: デプロイ時に脆弱性を早期検出してその場で修復・再検証できるため、脆弱性の流出リスクと修正サイクルが短縮される
  • 導入工数: 自動生成スニペットを貼るだけで数分～数十分で初期導入が可能（初回のアプリコンテキスト自動構築あり）

技術的な注意点 ​

  • プレビュー状態: 現在パブリックプレビューで提供されており、機能やインターフェース、利用規約が変更される可能性があります。正式リリース時の仕様差分に注意してください。
  • IAM権限: パイプライン実行ロールやサービスロールに対して、Continuumがテスト対象リソースへアクセスし結果を出力できる十分な権限が必要です。具体的な最小権限はドキュメントで確認してください。
  • リージョン制限: 公開プレビューのため一部リージョンでのみ利用可能な場合があります。利用前に対応リージョンを確認してください。
  • コスト: Continuumの利用または追加のログ／ストレージ・データ送信に伴う料金が発生する可能性があります。料金ページ／ドキュメントで課金体系を確認してください。
  • パイプライン統合: 自動生成されるスニペットを既存CI/CDへ組み込む形で動作します。パイプライン内でのテスト実行タイミングやゲート条件は環境に合わせて調整してください。
  • テスト副作用: ペネトレーションテストは負荷を発生させるため、実稼働システムではWAFやIPSの誤検知、レート制限、サービス負荷に注意が必要です。スコープ設定やステージ環境での検証を推奨します。
  • スコープと同意: 他社所有のサービスや第三者エンドポイントを誤ってスキャンしないようにスコープを明確に設定してください。組織のポリシーや法的制約を事前に確認する必要があります。
  • 検出精度: 自動化ツール固有の誤検知／見落としがあり得ます。重要所見は手動レビューや追加検査で確証を取る運用を推奨します。

参考情報 ​

[RDS] AWS Advanced Ruby Driver Wrapper is generally available ​

概要 ​

AWS Advanced Ruby Driver WrapperがGAになりました。Amazon RDSおよびAmazon Aurora（PostgreSQL／MySQL互換）向けのRubyドライバラッパーで、フェイルオーバー／スイッチオーバー時の接続切り替えを高速化し、複数の認証方式をサポートします。

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

このラッパーはコミュニティのpg（PostgreSQL）とmysql2（MySQL）ドライバの上に構築され、RDS/Auroraクラスターの状態をネイティブに監視して、予期せぬフェイルオーバーやBlue/Green／Aurora Globalのスイッチオーバー発生時に速やかに昇格されたwriterノードへ再接続します。AWS Secrets Manager認証およびIAMトークン（token-based authentication）を含む複数の認証方式をサポートし、ActiveRecord向けに提供されるaws_postgresqlおよびaws_mysql2アダプタを使うことでアプリケーションコードの変更なしに導入できます。オープンソース（Apache 2.0）で公開されており、GitHubの手順に従って導入・設定します。

影響範囲・利用シーン ​

  • 対象ユーザー: Ruby/Railsアプリ開発者、SRE/運用チーム、データベース管理者（RDS/Auroraを利用）
  • 利用シーン: RDS Blue/Greenスイッチオーバー、Aurora Globalデータベースのスイッチオーバー、通常のデータベースフェイルオーバー時にアプリの接続復旧を高速化したい場合
  • 運用効果: フェイルオーバー／スイッチオーバーによるダウンタイム短縮、アプリケーション可用性の向上、手動再接続や暫定パッチの削減
  • 対応DB: Amazon RDSおよびAmazon AuroraのPostgreSQLとMySQL互換エンジン
  • 導入前提: Rubyアプリでpgまたはmysql2を使用、ActiveRecordを利用していると最小変更で導入可能

技術的な注意点 ​

  • IAM権限: IAMベースのトークン認証を利用する場合は必要なIAM権限（rds-db:connect等）を付与する必要があります。またSecrets Managerを利用する場合はGetSecretValue等の権限が必要です
  • リージョン制限: 特定のリージョン制限は記事に明記されていませんが、利用可否は対象のRDS/Auroraサービスが提供されているリージョンに依存します
  • 互換性: ラッパーはpgおよびmysql2ドライバ上で動作します。利用前に既存のドライバ／ActiveRecordのバージョン互換性を確認してください（詳細はGitHubのREADME参照）
  • 導入影響: ActiveRecord用アダプタ（aws_postgresql、aws_mysql2）によりアプリケーションコード変更は不要とされていますが、本番導入前にステージング環境で接続確認とフェイルオーバーテストを実施してください
  • コスト: ドライバ自体はOSSですが、AWS Secrets Managerを使用する場合はシークレット保管・API呼び出しに関する料金が発生する可能性があります。IAMトークンの利用自体は追加料金はないがAPI呼び出しやログ収集等による間接コストに注意してください
  • 運用上の注意: フェイルオーバー検知と再接続ロジックはラッパーにより自動化されますが、接続プール設定（タイムアウト、リトライ、プールサイズなど）やアプリケーション側のエラーハンドリング設定は最適化が必要です

参考情報 ​

[Client Vpn] AWS Client VPN now supports device posture assessment ​

概要 ​

AWS Client VPNがデバイスポスチャ（端末のセキュリティ状態）評価をサポートしました。接続前および接続中に端末の準拠状況を自動で評価し、準拠しない端末をネットワークから切断または監視できます。

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

この新機能により、Client VPNは既存の認証方式（証明書／SAML／Active Directory）に加えて、CrowdStrike、Jamf、JumpCloudといったデバイスポスチャプロバイダーと連携して端末のセキュリティ信号（コンプライアンススコア、暗号化状態、リスクレベル等）を評価できます。管理者はCedarポリシーで接続許可条件を細かく定義でき、Client VPNに用意されたTest Policyツールでポリシー作成と検証を支援します。評価はセッション中も継続的に再評価され、端末が基準を満たさなくなった場合は自動で切断されます。また、まずは影響を確認するために評価結果をログに記録する「監視のみ（monitoring-only）モード」も利用可能です。デバイスポスチャ評価は既存の認可ルールと併用して多層防御を実現します。機能はAWS Client VPNが提供されている全リージョンで利用可能で、追加料金は発生しません。利用にはAWS VPN Clientバージョン6.2.0以降が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク管理者、セキュリティチーム、SRE/運用チーム
  • 利用シーン: リモートワーカーやBYOD端末の接続前チェック、エンドポイントコンプライアンス強制、サードパーティのEDR/MDM製品と連携したアクセス制御
  • 運用効果: 攻撃対象となり得る非準拠端末の接続を未然に防止できるため、内部ネットワークやクラウドリソースのリスク低減とコンプライアンス遵守の強化が可能

技術的な注意点 ​

  • VPNクライアント: AWS VPN Client バージョン6.2.0以上が必要です
  • 外部プロバイダー依存: CrowdStrike、Jamf、JumpCloud等のアカウント、エージェント導入、及び当該プロバイダー側の設定が前提となります
  • Cedarポリシー: 接続許可条件はCedarポリシーで定義します。ポリシー構文と評価ロジックに習熟してから運用することを推奨します（Test Policyツールで検証可能）
  • 運用影響: コンプライアンス逸脱時は自動切断が発生するため、ユーザー体験（セッション中断）や業務影響を考慮したポリシー段階導入を検討してください
  • 監査／ログ: 監視モードで評価ログを記録できます。ログの取り扱いや監査ワークフローとの連携設計が必要です（詳細は管理ガイド参照）
  • IAM権限: Client VPN設定とCedarポリシー管理に必要なIAM権限（管理者権限や特定API呼び出し権限）を適切に付与してください
  • リージョン制限: Client VPNが提供されているすべてのリージョンで利用可能とされていますが、各リージョンでのサービス可用性はAWSのリージョンページで確認してください
  • コスト: 新機能そのものに追加料金は発生しないと明示されていますが、外部プロバイダーのライセンス費用やエージェント運用コストは別途発生します

参考情報 ​

[General] AWS Batch now supports Amazon EKS access entry authentication ​

概要 ​

AWS Batch が Amazon EKS クラスターへのアクセスエントリ（access entry）による認証をサポートしました。これにより、aws-auth ConfigMap に直接書き込むことなく、API 駆動で Batch のクラスターアクセスを管理できます。

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

技術的には、AWS Batch のコンピュート環境で EKS の access entry を利用した認証が可能になりました。具体的には、CreateComputeEnvironment または UpdateComputeEnvironment API で compute environment の accessEntry.desiredState を ENABLED に設定すると、AWS Batch が対象の EKS クラスターごとに 1 つの access entry を作成し、AWSBatchClusterPolicy をその access entry に関連付けます。これにより、IAM プリンシパル（この場合は AWS Batch の役割）が API ベースでクラスターにアクセスできるようになり、従来の aws-auth ConfigMap による手動設定やライフサイクル管理の負担が軽減されます。設定は AWS CLI、AWS SDK、または AWS マネジメントコンソールから行えます。今回の機能は AWS Batch が利用可能なすべてのリージョンでサポートされています。

影響範囲・利用シーン ​

  • 対象ユーザー: AWS Batch と Amazon EKS を組み合わせてバッチワークロードを実行するクラウドエンジニア、SRE、プラットフォームチーム
  • 利用シーン: EKS 上でのバッチワークロード実行におけるクラスタ認証設定の自動化（Compute Environment を作成/更新するだけで access entry を有効化）
  • 運用効果: aws-auth ConfigMap の手動編集が不要になり、アクセス権の付与・撤回が API ベースで一元管理できるため、構成ミスや運用負荷の低減、ライフサイクル管理の簡素化が期待できる
  • 移行影響: 既存で aws-auth を使っている環境では、access entry と併用するか移行方針を検討する必要がある（重複付与や想定外の権限範囲を避けるため）

技術的な注意点 ​

  • 有効化方法: CreateComputeEnvironment / UpdateComputeEnvironment API の accessEntry.desiredState を ENABLED に設定する（CLI/SDK/Console から可能）
  • IAM権限: EKS の access entry を作成・管理するための権限（EKS の access entry 関連アクション）および Compute Environment を操作するための AWS Batch 権限が必要。AWSBatchClusterPolicy が access entry にアタッチされるため、その内容を確認して最小権限を検討すること
  • 既存設定への影響: aws-auth ConfigMap を使った既存のノード/ロール割当と併用する場合、二重付与や衝突が起きないようアクセス設計を確認すること
  • リージョン制限: AWS Batch が提供されている全リージョンでサポートされています（記事時点）
  • コスト: access entry 自体に追加課金は通常発生しませんが、EKS クラスターや AWS Batch のリソース利用に伴う標準料金は発生します
  • 監査・可観測性: access entry の作成/更新は AWS CloudTrail で記録されるため、変更監査に利用可能
  • 検証ポイント: 有効化後に Batch のコンピュート環境が正しくクラスターに接続できるか、必要な RBAC 権限（Pod/ServiceAccount など）やポリシーの適用範囲を検証すること

参考情報 ​

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

Copyright © 2026