2026年01月29日
[EKS] Amazon EKS and Amazon EKS Distro now supports Kubernetes version 1.35
- 公開日: 2026-01-29 (JST)
- カテゴリ: EKS
- リンク: https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-eks-distro-kubernetes-version-1-35
概要
Amazon EKS と Amazon EKS Distro が Kubernetes 1.35 をサポート開始しました。新規クラスタ作成や既存クラスタのアップグレードが EKS コンソール、eksctl、IaC ツールで可能になり、1.35 の新機能が使用できます。
変更内容・新機能の詳細
Kubernetes 1.35 のサポートにより、EKS と EKS Distro を使って以下の主要な改善点とバグ修正が利用可能になります。主な新機能は次のとおりです。In-Place Pod Resource Updates:Pod を再起動せずに CPU/メモリのリソース要求・制限を更新できるため、オンラインでのリソース調整が容易になります。PreferSameNode Traffic Distribution:トラフィック配分でローカルなエンドポイントを優先し、リモートノードへのルーティングを抑えることでレイテンシを低減します。Node Topology Labels via Downward API:Pod が API サーバーに問い合わせなくてもノードのリージョン/ゾーン等のトポロジ情報を取得可能にします。Image Volumes:OCI コンテナイメージを用いて AI モデル等の大きなデータアーティファクトを配布・マウントできる仕組みを提供します。EKS 側では、すべての EKS 対応リージョン(AWS GovCloud を含む)で 1.35 が利用可能になり、EKS Distro のビルドは ECR Public Gallery と GitHub で入手可能です。クラスタのアップグレード手順やサポートされる Kubernetes バージョン一覧、EKS バージョンライフサイクルポリシーは公式ドキュメントに記載されています。アップグレード前には EKS Cluster Insights 等で事前チェックを推奨します。
影響範囲・利用シーン
- 対象ユーザー: Kubernetes クラスタを運用するプラットフォーム/クラウドエンジニア、SRE、アプリケーション開発者
- 利用シーン: ライブ環境でのリソース調整(インプレース更新)、高スループット/低レイテンシを要求するサービスでのローカル優先トラフィック、AI/ML モデルや大容量アーティファクトの配布
- 運用効果: Pod 再起動を伴わないリソース変更でダウンタイムを低減、トラフィックのローカル化によるレイテンシ改善、OCI ベースのイメージでデータ配信の標準化が可能
技術的な注意点
- IAM権限: クラスタバージョンの更新には eks:UpdateClusterVersion 等の適切な EKS 権限が必要です
- eksctl/CLI/コンソール: アップグレードを行う場合は使用するツール(eksctl、AWS CLI、コンソール、IaC)の最新版を使用してください。古いクライアントは新 API に未対応の可能性があります
- kubectl バージョン互換性: クライアントとサーバーのバージョン整合性を確認してください(通常はマイナー差 1 程度のバージョンスキューを推奨)
- アドオン/コントローラ互換性: CNI(例: AWS VPC CNI)、CSI ドライバ、Ingress コントローラ、メトリクス/監視エージェント、カスタムコントローラ等の互換性を事前に検証してください。アップグレード前にサードパーティの対応状況を確認すること
- ノードイメージ: マネージドノードや Bottlerocket/AL2 ベースの AMI を使用している場合、必要に応じてノード側の AMI/ランタイムを更新する必要があります(コンテナランタイムや kubelet の互換性に注意)
- ダウンタイム/ロールアウト: コントロールプレーンは EKS が管理しますが、ワーカーノードのアップグレードでは Pod 再スケジューリングや一時的なリソース不足が発生する可能性があるためローリング更新戦略を設定してください
- 監視と事前チェック: EKS Cluster Insights や既存の CI/CD/テスト環境でアップグレード検証を行い、既知の問題を事前に洗い出してください
- リージョン制限: EKS は記事記載の通り全 EKS 対応リージョン(GovCloud を含む)で 1.35 をサポートしていますが、特定リージョンでのアドオン提供やサードパーティ統合物の対応状況は確認が必要です
- コスト: EKS のコントロールプレーン課金体系は変わりませんが、ノード入替・テスト環境構築・追加監視等により一時的なインスタンスコストや ECR ダウンロードコストが発生する可能性があります
- EKS Distro: EKS Distro の 1.35 ビルドは ECR Public Gallery と GitHub で入手可能です。自前での利用やカスタムビルド時はライフサイクルポリシーとセキュリティパッチの適用計画を確認してください
参考情報
- https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-eks-distro-kubernetes-version-1-35
- https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html
- https://github.com/aws/eks-distro
- https://kubernetes.io/docs/home/
[Ec2] Amazon EC2 R7gd instances are now available in Europe (Paris) Region
- 公開日: 2026-01-29 (JST)
- カテゴリ: Ec2
- リンク: https://aws.amazon.com/about-aws/whats-new/2026/01/r7gd-instances-available-in-paris
概要
Amazon EC2のR7gdインスタンス(最大3.8TBのローカルNVMeベースSSDを搭載)が Europe (Paris) リージョンで利用可能になりました。Graviton3プロセッサー+DDR5+AWS Nitro Systemを採用し、メモリ集約型ワークロードと低レイテンシなローカルストレージを必要とする用途に最適です。
変更内容・新機能の詳細
R7gdはAWS Graviton3(Arm64アーキテクチャ)を採用し、DDR5メモリとAWS Nitro System上で動作するインスタンスタイプです。各インスタンスは最大3.8TBのローカルNVMeブロックレベルSSD(インスタンスストア)を提供し、高IOPS・低レイテンシな一時ストレージが必要な用途に適しています。代表的なユースケースはオープンソースデータベース(キャッシュやレプリカ)、インメモリキャッシュ、リアルタイムのビッグデータ解析、スクラッチ領域や一時ファイル、キャッシュ保持などです。インスタンスストアはエフェメラル(停止/終了でデータ消失)なので、永続化が必要なデータはEBSやS3へバックアップ・レプリケーションする設計が必要です。導入にあたってはArm64対応のAMIs(Amazon Linux 2、主要なLinuxディストリビューションのarm64版など)を選び、NVMeドライバやカーネルのサポート状況を確認してください。起動はAWSマネジメントコンソールやCLIから可能で、利用可否や料金はリージョンごとに異なるため事前に確認してください。
影響範囲・利用シーン
- 対象ユーザー: メモリ集約型アプリケーション開発者、DB管理者、SRE/運用チーム
- 利用シーン: 高速ローカルストレージを必要とする一時データ(スクラッチ領域、キャッシュ)を多用するワークロード、インメモリデータベースやリアルタイム解析
- 運用効果: ローカルNVMeによる低レイテンシI/Oでレスポンス改善とコスト効率向上(Graviton3の性能効率により同等x86インスタンスよりコスト低減が期待できる場合あり)
技術的な注意点
- IAM権限: ec2:RunInstances等のインスタンス起動権限や関連リソース(セキュリティグループ、IAMロール、キーペア)への権限を事前に用意してください
- リージョン制限: 本リリースは Europe (Paris) リージョンで利用可能になった旨。他リージョンでは未提供の可能性があるためリージョン毎の提供状況を確認してください
- コスト: インスタンス時間課金にローカルNVMeは含まれるが、バックアップや冗長化のためEBS/S3を併用する場合は追加コストが発生します。価格はリージョンとサイズに依存します
- OS/AMI互換性: Graviton3はArm64ベースのため、Arm64対応のAMIを使用してください。主要ディストリビューションのarm64版(Amazon Linux 2、Ubuntu等)を推奨します
- データ永続性: インスタンスストアはエフェメラル(インスタンスの停止/終了でデータ消失)です。重要データはEBS/S3への同期やスナップショット戦略を設計してください
- 暗号化: インスタンスストアのデータはホスト側で自動的に暗号化されないため、必要に応じてインスタンス内での暗号化(例: dm-crypt)やアプリレベルの暗号化を実施してください
- クォータ/可用性: 新しいインスタンスファミリーは初期にリージョンごとに容量制限があることがあるため、サポートやService Quotasで上限確認・引き上げ申請を検討してください
参考情報
- https://aws.amazon.com/about-aws/whats-new/2026/01/r7gd-instances-available-in-paris
- https://aws.amazon.com/ec2/instance-types/r7gd/
- https://console.aws.amazon.com/ec2/
[Msk] Amazon MSK Replicator is now available in Asia Pacific (New Zealand)
- 公開日: 2026-01-29 (JST)
- カテゴリ: Msk
- リンク: https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-msk-replicator-asia-pacific-new-zealand
概要
Amazon MSK Replicatorがアジアパシフィック(ニュージーランド)リージョンで利用可能になりました。MSKクラスタ間でストリーミングデータと関連するKafkaメタデータを自動で非同期レプリケートできます。
変更内容・新機能の詳細
MSK ReplicatorはAmazon MSKの機能で、同一リージョン内または異なるリージョン間のMSKクラスタ間でデータを数クリックで信頼性高く複製します。自動非同期レプリケーションを提供し、トピックデータに加えトピック設定、Access Control Lists (ACL)、コンシューマグループのオフセット等のKafkaメタデータも複製します。インフラのプロビジョニングやカスタムコード、明示的なクロスリージョンネットワーク設定をユーザが用意する必要がなく、基盤リソースは自動的にスケールされるためオンデマンドでの複製が可能です。異常発生時は別リージョンにフェイルオーバーして処理を再開でき、管理はAWSマネジメントコンソールまたはAWS CLIから開始できます。今回の拡張により、MSK Replicatorは合計36リージョンで利用可能になりました。
影響範囲・利用シーン
- 対象ユーザー: Kafkaを利用するアプリケーション開発者、SRE、プラットフォーム/運用チーム
- 利用シーン: リージョン間のDR(ディザスタリカバリ)構成、リージョン冗長なストリーミングアプリケーション、クロスリージョン集計やデータ移行、テスト/検証環境へのデータ同期
- 運用効果: カスタムレプリケーションコードや専用インフラの削減により運用負荷が低下し、フェイルオーバー時にコンシューマオフセットを保持することで処理のシームレスな再開が可能
- パフォーマンス影響: 非同期レプリケーションのためレプリケーション遅延(レプリケーションラグ)が生じる可能性があるが、MSK側でスケール管理されるためスループットのボトルネックは緩和されやすい
- リージョン可用性: アジアパシフィック(ニュージーランド)での利用が可能になり、グローバル利用の選択肢が拡大
技術的な注意点
- IAM権限: MSK Replicatorを利用するには、MSKおよび関連リソースに対する適切なIAM権限(MSKの読み取り/書き込みや関連するサービスロールの作成許可など)が必要です。詳細はドキュメントで確認してください。
- リージョン制限: 本リリースによりアジアパシフィック(ニュージーランド)で利用可能。利用可能リージョンは今後も変動するため公式のリージョン一覧を確認してください。
- ネットワーク/セキュリティ: AWSバックボーン経由のクロスリージョン複製を提供しユーザー側でのクロスリージョンVPCピアリング等は不要とされていますが、クラスタの暗号化設定(TLS/SASL)、VPCエンドポイントやセキュリティグループの設定、IAM認証の互換性等は事前に確認してください。
- データ整合性/遅延: レプリケーションは自動非同期で動作するため、ソースとターゲットの完全同期には遅延が発生します。RPO/RTO要件に合わせて遅延許容性を評価してください。
- メタデータ対応: トピック設定、ACL、コンシューマグループのオフセット等が複製されるため、フェイルオーバー後の処理継続が容易になりますが、カスタムメタデータや外部システム依存の設定は別途確認が必要です。
- コスト: レプリケーション利用には追加料金が発生します(リージョン間通信・処理リソース等)。料金はMSKのReplicator向け料金ページで確認してください。
- 運用/監視: 自動スケーリングされますが、レプリケーションのヘルスやラグ、スループットは監視対象に入れてください。ログやメトリクスの収集設定を確認してください。
参考情報
- https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-msk-replicator-asia-pacific-new-zealand
- https://aws.amazon.com/msk/
- https://docs.aws.amazon.com/msk/latest/developerguide/
- https://aws.amazon.com/msk/pricing/
[Developer Tools] AWS announces Deployment Agent SOPs in AWS MCP Server (preview)
- 公開日: 2026-01-29 (JST)
- カテゴリ: Developer Tools
- リンク: https://aws.amazon.com/about-aws/whats-new/2025/01/aws-announces-deployment-agent-sops-in-aws-mcp-server-preview
概要
AWS MCP Server(プレビュー)で、AIエージェントが自然言語の手順(Agent SOPs)に従ってWebアプリを自動でインフラ作成からデプロイ、CI/CD構築まで行える「Deployment Agent SOPs」が発表されました。開発プロトタイプをワンプロンプトでプレビュー〜本番用パイプラインまで移行しやすくする機能です。
変更内容・新機能の詳細
Agent SOPsは構造化された自然言語の手順で、MCP対応のIDE/CLI(例: Kiro、Kiro CLI、Cursor、Claude Code)からのプロンプトでAIエージェントが複雑な多段階作業を確実に実行できるようにします。SOPに従ってエージェントはプロジェクト構成を解析し、AWS CDKでインフラコードを生成し、CloudFormationでスタックをデプロイします。プレビュー環境は静的WebホスティングとしてAmazon S3とAmazon CloudFront上に構築され、準備が整ったらAWS CodePipelineを用いてソースリポジトリからの自動化された本番デプロイ(CI/CD)を設定します。生成プロセスではAWSの推奨セキュリティ設定を反映したIAMロールやパイプライン設定が作成され、リポジトリ内にデプロイ手順のドキュメントも自動生成されるため、将来のデプロイ自動化やログ調査、セッションの再開が可能です。対応フレームワークにはReact、Vue.js、Angular、Next.jsなどの一般的なフロントエンドフレームワークが含まれます。現在はプレビューとして米国東部(バージニア北部)リージョンで提供され、MCP Serverプレビュー自体に追加料金はなく、利用者は作成したAWSリソースとデータ転送分の料金のみを負担します。
影響範囲・利用シーン
- 対象ユーザー: フロントエンド開発者、フルスタック開発者、DevOps/Platformエンジニア、SRE
- 利用シーン: プロトタイプから本番への迅速な移行、プレビュー環境の自動生成、リポジトリ→本番のCI/CD自動化構築
- 運用効果: デプロイ手順の標準化と高速化によりリードタイム短縮、手動ミスの削減、再現可能なデプロイで運用負荷を低減
技術的な注意点
- IAM権限: エージェントがCDK/CloudFormation、S3、CloudFront、CodePipeline等を作成/変更するための十分なIAM権限(ロールの作成やポリシー付与を含む)が必要です。生成されるIAMポリシーはレビュー推奨。
- リージョン制限: プレビューは米国東部(バージニア北部)リージョンで提供されています。その他リージョンへ展開する前に対応状況を確認してください。
- コスト: MCP Serverのプレビュー自体に追加料金はないが、作成されるAWSリソース(S3、CloudFront、CodePipeline、CodeBuild、CloudFormationで作られるリソース等)とデータ転送に対して通常の料金が発生します。
- 対応フレームワーク: React、Vue.js、Angular、Next.jsなど静的/フロントエンド中心のフレームワークをサポート。ただしサーバーサイドのバックエンドや複雑なマイクロサービス構成は追加設定が必要な場合があります。
- リポジトリアクセス: ソースリポジトリ(GitHub/GitLab等)の読み書き権限やWebhook設定が必要になることがあります。認証情報やシークレットの扱いは明示的に設計してください。
- セキュリティレビュー: 自動生成されたCDK/CloudFormationやCI設定はそのまま適用せず、IAMロール、公開設定、CORS、ログ出力、機密情報の扱い(Secrets Manager/Parameter Store使用)を事前確認してください。
- プレビュー注意: プレビュー機能のため仕様変更や制限が将来発生する可能性があります。自動生成物は運用前に手動で検証・承認するワークフローを推奨します。
参考情報
- https://aws.amazon.com/about-aws/whats-new/2025/01/aws-announces-deployment-agent-sops-in-aws-mcp-server-preview
- https://docs.aws.amazon.com/mcp-server/latest/userguide/
[Gamelift] Amazon GameLift Servers now supports automatic scaling to and from zero instances
- 公開日: 2026-01-29 (JST)
- カテゴリ: Gamelift
- リンク: https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-gamelift-servers-automatic-scaling
概要
Amazon GameLift Serversがインスタンス数をゼロまで自動でスケールダウン/ゼロから自動でスケールアップできるようになり、非稼働時間のインフラコストを削減しつつ、プレイヤー要求に応じた自動復帰を可能にします。
変更内容・新機能の詳細
これまでFleetのオートスケーリングは少なくとも1台のインスタンスが稼働していることを前提としており、トラフィックが無い時間帯でもインスタンスを維持する必要がありました。本機能により、GameLift Serversは最小キャパシティを0に設定でき、実際にゲームセッションやプレイヤー接続要求が発生した際に必要なインスタンスを自動でプロビジョニングしてスケールアップします。技術的には、スケーリングポリシー(ターゲットトラッキングやスケジュール/ステップスケーリング)で最小値を0に設定でき、GameLift側でゼロ→稼働状態へのインスタンス起動と登録処理を自動化します。結果として、オフピーク時のインスタンス課金が発生せず、ピーク時には自動でキャパシティを確保することができます。また、GameLift Serversをサポートするすべてのリージョンで利用可能です(公式発表)。
影響範囲・利用シーン
- 対象ユーザー: マルチプレイヤーゲーム開発者、サーバー運用者、スタジオのSREチーム
- 利用シーン: ピーク・オフピークの差が大きいタイトル、季節イベントやローンチ直後の不確実なトラフィック、地域別稼働が異なるゲーム運用
- 運用効果: オフピーク時のインスタンス課金を削減し、コスト最適化が可能。手動介入を減らして自動的に需要に追従
- パフォーマンス影響: ゼロからのスケールアップ時にサーバー起動や配置(AMI/起動時間、コンテナ起動、ゲームサーバープロセスの初期化)によるウォームアップ遅延が発生する可能性があるため、適切なプレバッファやマッチメイキングのキュー戦略が必要
技術的な注意点
- IAM権限: オートスケーリング設定やFleet更新を行うためのGameLift関連API操作権限を確認してください(運用用ロールに適切なgamelift権限を付与)
- リージョン制限: 発表によればGameLift Serversをサポートする全リージョンで利用可能です。ただし利用前に対象リージョンでのサービス有無を確認してください
- コスト: アイドル状態のインスタンス課金は削減されるが、スケールアップ時の一時的なインスタンス起動コストや、頻繁なスケール操作による短時間インスタンスのコスト増が発生する場合があるためポリシーとウォームアップ戦略で調整してください
- 冷スタート(ウォームアップ): ゼロから立ち上げる際のプロビジョニング時間(OS/コンテナの起動、ゲームサーバー初期化)を考慮し、プレバッファインスタンスやマッチメイキング遅延緩和策を検討してください
- 設定/運用: 最小キャパシティを0に設定するためのスケーリングポリシー調整、ターゲット指標(PlayerSessions、接続リクエスト数、キュー長など)の選定、監視アラートの設定を推奨します
- テスト: 本番導入前にステージングでスケールイン/スケールアウトの挙動(遅延、失敗時のリトライ、健康チェック)を検証してください