皆さん、こんにちは。五味 なぎさです。前回のブログでは、AWS re:Invent2023の開催概要と現地での交流内容を共有しました。まだ、前編を読まれていない方は是非、こちらからご覧ください。
さて後編では、会期中に公表された気になるアップデートについてまとめてご紹介していきます。少し長くなってしまいますが、最後までお付き合いいただければ幸いです。
re:Inventでは、例年、基調講演（keynote）で大型のサービス追加、アップデートが発表されることが多く、今年も『Amazon Q』『Amazon Aurora Limitless Database』など多くの発表がありました。Keynoteの内容は現在オンデマンドで配信されており、公式情報を初め多くの情報が公開されていますので、是非そちらをご確認ください。
今回はせっかくですので、keynote以外で私が特に気になったアップデート情報5つをご紹介します。
AWS上で疑似障害を発生させ、アプリケーションのパフォーマンス、オブザーバビリティ、回復性を確認することができるサービスであるAWS Fault Injection Service（FIS）が、 AZ Availability: PowerとCross-Region: Connectivityの2つのシナリオに対応しました。
AZ Availability: Powerは、単一のAZで停電が発生した場合にマルチAZアプリケーションがどのように動作するかを確認することができます。一方で、Cross-Region: Connectivityでは、アプリケーションが別リージョンのリソースにアクセスできない場合にマルチリージョン構成が上手く動作するかを確認することができます。これまでマルチAZやマルチリージョンの動作テストを行う場合は、意図的にリソースを止めるなどで疑似的にテストを行うしかなく、またその場合も再現しきれない部分があり確認が困難でしたが、今回FISがこれらのケースに対応したことで、マルチAZやマルチリージョンの障害時動作確認が容易になりました。
マネージド型脅威検出サービスであるAmazon GuardDutyが、ECS on Fargate、ECS on EC2、EC2におけるランタイムモニタリングに対応しました。
GuardDutyのランタイムモニタリング機能では、ファイルアクセス、プロセス実行、ネットワーク接続など、個々のOSやコンテナのランタイムイベントを分析し、異常パターンを検出します。また、コンソールへの表示だけでなく、複数のAWSサービス（AWS Security Hub、Amazon EventBridge、Amazon Detective、等）と連携することも可能です。これまでEKS on EC2のみの対応で、ECSやEC2のランタイムモニタリングを行う場合にはサードパーティツールの導入を検討せざるを得なかったため、対応を待ち望んでいた方も多かったのではないでしょうか？私としても嬉しいアップデートの1つでした。
AWSのロードバランサーサービスの1つであるApplication Load Balancer（ALB）がAutomatic Target Weightsに対応しました。
一般的にロードバランサーでは、ヘルスチェックを用いてノードの健全性を確認し、ヘルスチェックがNGの場合に振り分け先から除外されます。しかし、ヘルスチェックで利用しているパスへの応答は正常に返っているのにも関わらず、実際のユーザに提供されているパスへの応答がエラーになっている、というケースに遭遇したことがある方も多いのではないでしょうか？
今回ALBがAutomatic Target Weightsに対応したことにより、5XXエラーや接続エラーなどの情報を元に異常と判定されたターゲットに送信されるトラフィック量を自動的に減らし、ユーザ影響を軽減することが可能となりました。また、ターゲット回復後には自動的にトラフィック量が元の状態に回復します。Automatic Target Weightsを利用するためには、ルーティングアルゴリズム（トラフィックの設定）で「Weighted random（加重ランダム）」を選択の上、「Anomaly mitigation（異常緩和）」の設定を有効にします。
なお、異常検出を行うためにはターゲットグループ内に少なくとも3つのターゲットが必要です。
Amazon CloudWatch Logsが低頻度アクセスログクラスに対応しました。
これまでは標準ログクラスのみだったため、予算的な問題からCloudWatch Logsへのログ転送ができず、S3等への保管となっていたケースがあったのではないかと思います。低頻度アクセスクラスでは、価格を標準ログクラスの50%に抑えた上で、転送・保管だけでなくLogs Insightを用いた検索が行えるため、これまでログの確認のために複数サービスを跨いでいたところを1つのサービスにまとめられるケースができたのではないかと思います。
ただし、標準ログクラスと比較して利用できる機能は限られるため（サブスクリプションフィルターやS3へのエクスポート、メトリクスフィルターなどは利用不可）、以下の参考ページ等で制約を確認した上で、利用検討することが必要です。
IDEとコマンドラインのためのAI搭載生産性向上ツールであるAmazon CodeWhispererがIaC（Infrastructure as Code）に対応しました。AWS CloudFormation、AWS CDKだけでなく、HashiCorp Terraformにも対応しており、活躍の場面が多そうです。
Terraformコード生成を実際に試してみたところ（Visual Studio CodeにAWS Toolkitを導入する形で検証）、コメントを元に作成対象のresourceブロックの候補が表示され、確定すると更にresource内のパラメータが表示されました。
そのため、ユーザ自身がコマンドを入力しなくても、補完されるコードの確定と詳細なパラメータ値の入力のみでIaCコード生成を容易に行うことができそうです。また、コード生成の支援だけではなくセキュリティスキャン機能にも対応しており、IaCで作成されるリソースに対するセキュリティ上の問題も指摘してくれるようですので、そういった目的での利用もできそうです。
いかがだったでしょうか？今回の前後編に渡るイベントレポートを通じて、少しでも皆様のAWS活用の参考になれば幸いです。今後もパブリッククラウドに関する情報を発信していきますのでよろしくお願いします。
