Amazon ECS で IPv6-only サブネットでのタスク実行がサポートされました
従来は IPv4 アドレスが必須だったため、大規模にコンテナを展開するアプリケーション環境では IPv4 アドレス不足がボトルネックになることがありました。
今回のアップデートによりIPv4を必要とせず、IPv6 のみでの運用が可能になりました。
IPv4からIPv6の移行戦略を考えてみると
ALBやNLBに接続されていないサービス
そのまま移行することが可能です。
Amazon ECSのupdateService APIを使用して、既存のIPv4サブネットとセキュリティグループを同等のIPv6リソースに置き換えられます。
ALBやNLBに接続されているサービス
この場合、サービスをそのまま移行することも可能ですが、受信トラフィックのルーティングが複雑になるため、推奨されません。
代わりに、新しいIPv6のAmazon ECSサービスを作成し、既存のIPv4サービスと並行して実行することをお勧めします。その後、トラフィックを段階的にIPv4サービスから新しいIPv6サービスに移行します。
デュアルスタックのALBを使用する場合
新しいIPv6ベースのターゲットグループを設定し、最初はIPv6ターゲットグループにはトラフィックを流さず、すべてのトラフィックを元のIPv4ターゲットグループとAmazon ECSサービスに流します。
ALBの重み付きターゲットグループを使用して、徐々にトラフィックを新しいIPv6ターゲットグループにシフトします。
DNSレイヤーを通じたトラフィック移行:
新しいデュアルスタックのALBをプロビジョニングし、IPv6ターゲットグループと新しいIPv6 ECSサービスをロードバランサーに接続します。
元のIPv4 ECSサービスは、元のIPv4ロードバランサーの背後で引き続き実行。
Amazon Route 53の重み付きルーティングポリシーやAmazon CloudFrontを使用して、トラフィックを元のIPv4ロードバランサーから新しいデュアルスタックロードバランサーに段階的にシフトします。
Amazon ECS Managed Instances が発表されました
この機能により、ユーザーはECSクラスター内のインスタンスのライフサイクル管理をAWSに任せることができます。インスタンスのプロビジョニング、パッチ適用、スケーリング、および廃棄が自動化され、運用負荷が軽減されます。
クラスターの作成時に選択できる
自動プロビジョニング
必要なインスタンスを自動で作成。
パッチ管理
セキュリティパッチや更新プログラムを自動適用。
スケーリング
需要に応じた自動スケーリング。
廃棄管理
不要になったインスタンスの自動廃棄。
AWS Transfer Family で VPC エンドポイントポリシーと FIPS 対応 VPC エンドポイントがサポートされました
これまで、VPC エンドポイント経由で Transfer Family API にアクセスする際はAPIの細かい制御ができませんでしたが、今回のVPCエンドポイントポリシーサポートにより CreateServer や DeleteServer など、 詳細なAPI 操作制御ができるようになりました。
キー Environment と値 Test でタグ付けされたものを除くすべてのリソースに対して、すべての AWS Transfer Family API アクションへのアクセスを許可する例引用
AWS Transform for VMware が VMware 環境からネットワーク構成のIaCを自動生成する選択肢として、これまでのCloudFormation と CDKに加えてTerraform サポート
VMware 環境からクラウドへの移行時、既存の Terraform ベースのデプロイメントパイプラインをそのまま活用できるため、移行作業の効率が大幅に向上します。
AWS Transform for VMwareは、以下のプロセスでネットワーク構成をIaC化します。
環境のディスカバリー
サーバーやネットワークを含む、オンプレミスのVMware環境全体を検出します。アプリケーションの依存関係マッピングも行います。
ネットワークの変換
検出されたネットワーク構成を分析し、VPC、サブネット、トランジットゲートウェイ、インターネットゲートウェイといったAWSのネイティブな構成要素に変換します。
IaCテンプレートの生成
変換された設定に基づいて、Terraform、CloudFormation、またはCDKのテンプレートを生成します。
Amazon CloudWatch と Amazon OpenSearch Service の統合分析エクスペリエンスが、大阪を含む5つのリージョンで新たに利用可能
従来、OpenSearch Service でのCloudWatchのログ分析にはストレージへのコピーや ETL パイプラインが必要だったのを不要にします。
CloudWatch Logs のログ分析にCloudWatch Logs Insights QLだけではなく SQL や OpenSearch PPL が使えるようにするものです。
追加になったのは、
・Asia Pacific (Osaka)
・Asia Pacific (Seoul)
・Europe (Milan)
・Europe (Spain)
・US West (N. California)
Amazon CloudWatch でApplication mapがGAしました
Application mapはアプリケーションパフォーマンス監視 (APM) 機能で、設定や関係性に基づいて関連サービスを自動的に検出しグループに整理できます。
Application Signals(APM)→「Application Map」を選択
Application Map例
引用
Application Signalsのデフォルトのグループ化は、下流の依存関係に基づいてサービスを自動的に整理します。
Amazon Managed Workflows for Apache Airflow (MWAA) で Apache Airflow 3.0 がサポートされました
直感的なワークフロー管理
新しいしいユーザーインターフェース (UI) により、ワークフローの管理がより簡単になりました。
外部イベント対応の強化
Airflow 3.0 では、外部イベントへの対応能力が向上しており、様々な連携が可能になります。
サポートされているバージョン一覧
引用
Amazon ECS がAWS Management Console で直接イベント取得とイベント履歴クエリを利用可能になりました
従来はタスクの停止理由やサービスのイベント履歴を確認するのにCloudWatch Logsなど複数のサービスのコンソールを行き来する必要がありました。
今回のアップデートによりこれが不要になり、ECS コンソール内で完結したトラブルシューティングが可能になります。
イベントキャプチャを有効にするには
ECS コンソールで [クラスターの詳細] ページに移動し、[構成] タブを見つけて、[イベントキャプチャを有効にする] ボタンをクリックします。
AWS Builder ID の作成時に Google アカウントを使ったサインインが可能になりました
AWS Builder ID は Kiro、 AWS Training や re:Post などを含む AWS アプリケーションにアクセスするための、AWSアカウントの認証とは独立した個人プロファイルです。
今回のサポートにより、Google アカウントでワンクリックサインインできるようになり、パスワード管理の手間を省けます。
請求書の修正をセルフサービスで行える機能がGAしました
これまで請求書の住所変更等はサポートに依頼して、作業の待ち時間が発生していました。
今回の機能によりAWS Billing and Cost Management のコンソールから、購入注文番号や会社名、住所などの請求書情報を直接編集可能になりました。
編集するには、「請求書」から「請求書」タブを選択した上で、修正したい箇所を選択できます。
EC2 Image Builder に連続失敗後に自動でパイプラインを無効化する機能とカスタムロググループ設定の2つの管理機能が追加されました
連続失敗後に自動でパイプラインを無効化する機能
この機能は、スケジュール実行するパイプラインで指定した回数（最大10回）連続してビルドに失敗した場合、そのパイプラインを自動的に無効化するものです。
カスタムロググループ設定
この機能により、Image Builderのログを既存のAmazon CloudWatch Logsのロググループに送信できるようになります。
・ログ管理の統合
Image Builderのログを、組織のログ管理ポリシーに合わせた特定のCloudWatch Logsロググループに統合できます。
・カスタマイズの強化
ログの保持期間や暗号化設定を、組織の要件に合わせて柔軟にカスタマイズできます。
・ロググループの作成
カスタムロググループを使用するには、まずCloudWatch Logsでロググループを作成する必要があります。