フォーム読み込み中
2025年2月17日掲載
Amazon EC2 Capacity Blocks for ML が東京など複数の新しいリージョンで利用可能に
Amazon Elastic Compute Cloud (Amazon EC2) の Capacity Blocks for ML が、新しいリージョンと既存の場所での新しいインスタンスタイプで利用可能になりました。
EC2 Capacity Blocks を使用すると、Amazon EC2 UltraClusters 内の需要の高い GPU インスタンスを、機械学習 (ML) ワークロードの実行に必要な時間だけ、将来の日付で予約できます。
最大8週間前から最大6か月間、1〜64インスタンスのクラスタサイズで GPU キャパシティを予約できるため、幅広い ML ワークロードを実行できます。短期間の事前トレーニングや微調整ワークロード、迅速なプロトタイピング、推論需要の急増への対応に適しています。
EC2 Capacity Blocks for ML は、P5、P5e、P5en インスタンスタイプで複数のリージョンで利用可能になりました。また、P4d インスタンスタイプも一部のリージョンで利用可能です。さらに、Trn2 および Trn1 インスタンスタイプも特定のリージョンで利用できます。
Amazon Redshift Serverless がサブネットごとの IP アドレス要件を 3 つに削減
Amazon Redshift Serverless のサブネットごとの IP アドレス要件が 3 つに削減されました。Enhanced VPC Routing (EVR) を有効にせずに Amazon Redshift Serverless を使用する場合、Amazon VPC の各サブネットで必要な空き IP アドレスは 3 つだけです。
この改善により、Amazon Redshift Serverless の利用開始が容易になり、Amazon VPC サブネットネットワークの空き IP アドレスを心配する必要がなくなりました。
以前は、Amazon Redshift Serverless ワークグループの作成時に少なくとも 9 つの空き IP アドレスが必要でした。また、Redshift Processing Units (RPU) のワークグループ更新時には、サブネットに少なくとも 10 の空き IP アドレスが必要でした。
今回のアップデートにより、EVR なしでワークグループを作成または更新する際に必要な空き IP アドレスは 3 つだけになりました。これは、ベース RPU のサイズ(8 から 1024 RPU)や、AI 駆動のスケーリングと最適化を有効にしたワークグループの RPU 使用量に関係なく適用されます。
既存のワークグループも、ベース RPU サイズや RPU 使用量に関係なく、IP アドレス要件の削減の恩恵を受けます。これには AI 駆動のスケーリングと最適化を有効にしたワークグループも含まれます。
ワークグループの RPU が増加しても、空き IP アドレスの要件が大幅に削減されたため、管理オーバーヘッドが軽減され、IP アドレスを解放するための手順を踏む必要がなくなりました。
Amazon OpenSearch Serverless が最大100TBの時系列ワークロードをサポート
Amazon OpenSearch Serverless が、時系列コレクションで最大100TBのデータを扱うワークロードをサポートするようになりました。OpenSearch Serverless は、インフラストラクチャー管理を意識せずに検索と分析のワークロードを実行できるAmazon OpenSearch Service のサーバーレスデプロイメントオプションです。
大規模なデータセットのサポートにより、OpenSearch Serverless は、ログ分析、セキュリティ分析、リアルタイムアプリケーション監視などのデータ集約型のユースケースにも対応できるようになりました。
OpenSearch Serverless のインデックス作成と検索に使用されるコンピューティング容量は、OpenSearch Compute Units (OCUs) で測定されます。大規模なデータセットに対応するため、インデックス作成と検索操作を独立してスケーリングし、最大1700 OCUsまで使用できるようになりました。検索とインデックス作成の最大OCU制限を個別に設定してコストを管理できます。また、CloudWatch メトリクスを使用してリアルタイムのOCU使用量を監視し、ワークロードのリソース消費をより詳細に把握することができます。
Amazon Connect Contact Lens が保留時間とエージェント対応時間に基づく自動アクションを実行可能に
Amazon Connect の Contact Lens に、お客さまの保留時間とエージェントの対応時間のパターンに基づいてルールを作成する機能が追加されました。これにより、以下のような自動アクションが可能になります:
- コンタクトの分類
- エージェントのパフォーマンス評価
- スーパーバイザーへの通知
マネージャーは、エージェントがお客さまを保留にする際のガイドラインの遵守状況を確認するルールを作成できます。例えば、エージェントがお客さまを5分以上保留にする前に、保留時間の見込みを説明したかどうかを確認できます。
また、エージェントの対応時間が十分に長かったかどうかを確認し、お客さまとの関係構築や問題の根本原因分析などの複雑な行動を評価することができます。30秒未満の短いコンタクトを除外することで、自動コンタクト分類やエージェントのパフォーマンス評価からより意味のある洞察を得ることができます。
Amazon Connect Contact Lens がエージェントのパフォーマンス評価に関する集計インサイトを提供するダッシュボードを追加
Contact Lens に、エージェントのパフォーマンス評価ダッシュボードが追加されました。マネージャーは、エージェントのパフォーマンスの集計や、時間の経過に伴うエージェントグループの洞察を確認できます。
このアップデートにより、マネージャーは評価スコア、生産性(処理したコンタクト数、平均処理時間など)、運用指標を含むエージェントのパフォーマンスを統合ダッシュボードで確認できます。チームおよび個人レベルの詳細なパフォーマンススコアカードを通じて、特定のパフォーマンス基準を深く掘り下げ、類似のグループとの比較や時系列での比較を行い、エージェントの強みと改善の機会を特定できます。
また、ダッシュボードはエージェントの時間配分とコンタクト処理の効率性に関する洞察を提供し、マネージャーがエージェントの生産性向上を推進するのに役立ちます。
Amazon EC2 M7g インスタンスが大阪など追加リージョンで利用可能に
Amazon Elastic Compute Cloud (Amazon EC2) の M7g インスタンスが、アジアパシフィック (ジャカルタ、メルボルン、大阪) および AWS GovCloud (US-East) リージョンで利用可能になりました。これらのインスタンスは AWS Graviton3 プロセッサを搭載し、AWS Graviton2 プロセッサと比較して最大25%優れたコンピューティング性能を提供します。また、AWS Nitro System 上に構築されており、効率的で柔軟かつセキュアなクラウドサービスを提供します。
Amazon EC2 Graviton3 インスタンスは、同等の性能の EC2 インスタンスと比較して最大60%少ないエネルギーで動作し、クラウドのカーボンフットプリントを削減します。スケーラビリティ向上のため、ベアメタルを含む9つの異なるインスタンスサイズが用意されており、最大30 Gbpsのネットワーク帯域幅と、Amazon Elastic Block Store (EBS) への最大20 Gbpsの帯域幅を提供します。
AWS Lambda が Java と .NET ランタイム向けにアプリケーションパフォーマンスモニターリング(APM)を追加
AWS Lambda が、Java と .NET のマネージドランタイムに対して Amazon CloudWatch Application Signals をサポートするようになりました。これは、アプリケーションパフォーマンスモニターリング (APM) ソリューションです。開発者と運用者は、Lambda を使用して構築されたサーバーレスアプリケーションの健全性とパフォーマンスを簡単に監視できるようになります。
この機能により、Java 11、Java 17、Java 21、および .NET 8 の Lambda マネージドランタイムを使用する Lambda 関数で Application Signals を有効にできます。有効にすると、Application Signals は、重要なアプリケーションメトリクス(スループット、可用性、レイテンシー、障害、エラーなど)、相関トレース、Lambda 関数と依存関係(他の AWS サービスなど)との相互作用に関する、事前構築された標準化されたダッシュボードを提供します。これにより、開発者による手動の計装やコード変更は不要です。
運用者は、アプリケーションの健全性を一元的に把握でき、パフォーマンスの異常の根本原因を特定するためにドリルダウンできます。
Lambda コンソールの「設定」タブにある「モニターリングと運用ツール」セクションで、ワンクリックで関数の Application Signals を有効にできます。
Application Signals for Lambda は、Lambda と CloudWatch Application Signals が利用可能な全ての商用 AWS リージョンで利用できます。
Amazon ECS が短い ARN から長い ARN へのサービスの更新を可能に
Amazon Elastic Container Service (Amazon ECS) で、短い Amazon リソースネーム (ARN) を使用する既存のサービスを、再作成せずに長い ARN に更新できるようになりました。これにより、長期実行中の Amazon ECS サービスにタグを付けることができ、コスト配分の改善、可視性の向上、およびこれらのサービスに対するきめ細やかなリソースレベルのアクセス許可の定義が可能になります。
2018年以降、長い ARN 形式(ARN にクラスタ名を含む)を使用する Amazon ECS サービスにタグを付けることができましたが、古い短い ARN 形式で作成されたサービスにタグを付けるには、サービスを削除して再作成する必要がありました。今回のアップデートにより、古い短い ARN 形式で作成されたサービスを再作成せずにタグ付けできるようになりました。
この機能を有効にするには、以下の2つのステップを完了する必要があります:
1. タスクとサービスの長い Amazon リソースネーム (ARN) 形式にアカウントをオプトインする
2. TagResource API アクションを使用して、長い ARN 形式に移行するサービスにタグを付ける
これらのステップを完了すると、ECS はサービスの ARN を長い ARN 形式に更新し、サービスにタグを付けます。長い ARN 形式を使用するようにサービスを更新することで、IAM でリソースベースのアクセスポリシーを定義し、Cost & Usage Report や Cost Explorer でサービスのコストを詳細に監視できるようになります。
AWS コンソール、CLI、および API を使用して、全ての AWS リージョンで短い ARN を持つサービスを長い ARN に更新できます。
Amazon RDS for SQL Server が 2025年1月期のマイナーバージョンをサポート
Amazon RDS for SQL Server に Microsoft SQL Server の新しいマイナーバージョンが導入されました。このアップデートには、パフォーマンスの向上とセキュリティの修正が含まれています。
SQL Server 2022 の最新マイナーバージョン(SQL Server 2022 CU17 - 16.0.4175.1)が、Express、Web、Standard、Enterprise の各エディションでサポートされるようになりました。
Amazon RDS Management Console または AWS CLI を使用して、数回のクリックでデータベースインスタンスをアップグレードできます。お客さまの都合の良いタイミングでアップグレードすることをおすすめします。
Amazon RDS for SQL Server は、クラウド上での SQL Server デプロイメントの設定、運用、スケーリングを簡素化します。
Amazon RDS for PostgreSQL が最新のマイナーバージョン 17.3、16.7、15.11、14.16、13.19 をサポート
Amazon Relational Database Service (RDS) for PostgreSQL が、最新のマイナーバージョン 17.3、16.7、15.11、14.16、13.19 をサポートするようになりました。これらの最新マイナーバージョンへのアップグレードにより、以前のバージョンの既知のセキュリティ脆弱性が修正され、PostgreSQL コミュニティーによるバグ修正の恩恵を受けることができます。
今回のリリースには、pg_active 2.1.4、pg_cron 1.6.5、pg_partman 5.2.4 などの PostgreSQL 拡張機能の更新も含まれています。
自動マイナーバージョンアップグレード機能を使用すると、スケジュールされたメンテナンスウィンドー中に自動的にデータベースを最新のマイナーバージョンにアップグレードできます。また、物理レプリケーションを使用した Amazon RDS Blue/Green デプロイメントを利用して、マイナーバージョンのアップグレードを行うこともできます。
Amazon RDS for PostgreSQL は、クラウド上で PostgreSQL デプロイメントの設定、運用、スケーリングを簡単に行えるようにします。
Amazon RDS for MySQL が Extended Support マイナーバージョン 5.7.44-RDS.20250103 を発表
Amazon Relational Database Service (RDS) for MySQL が、Amazon RDS Extended Support マイナーバージョン 5.7.44-RDS.20250103 をリリースしました。このバージョンには、以前の MySQL バージョンで知られているセキュリティ脆弱性やバグの修正が含まれているため、アップグレードが推奨されます。
Amazon RDS Extended Support は、新しいメジャーバージョンへのアップグレードに最大3年の猶予を提供し、ビジネス要件に対応します。コミュニティーがメジャーバージョンのサポートを終了した後も、Amazon RDS は RDS for MySQL データベースに対して重要なセキュリティおよびバグ修正を提供します。
Amazon RDS for MySQL は、クラウド上で MySQL デプロイメントの設定、運用、スケーリングを簡単に行えるようにします。完全マネージド型の Amazon RDS データベースは、Amazon RDS マネジメントコンソールで作成または更新できます。
Amazon DynamoDB がクォータ調整の自動承認をサポート
Amazon DynamoDB のアカウントレベルおよびテーブルレベルのスループットクォータ調整を、AWS Service Quotas を使用して要求できるようになりました。これにより、数分以内に自動承認されます。
以前は、クォータ調整を要求する際、Service Quotas で DynamoDB のクォータと希望する調整値を指定し、AWS サポートがリクエストを確認して承認していました。今回のアップデートにより、AWS Service Quotas を使用して DynamoDB のアカウントレベルおよびテーブルレベルのスループットクォータを更新すると、数回のクリックで自動的に承認され調整されます。
Amazon DynamoDB は、規模に関係なくミリ秒単位のパフォーマンスを実現する、サーバーレスで完全マネージド型の NoSQL データベースです。
AWS CodePipeline が CloudWatch メトリクスのサポートを追加
AWS CodePipeline の V2 パイプラインで Amazon CloudWatch メトリクスとの統合が可能になりました。これにより、パイプラインレベルとアカウントレベルの両方のメトリクスを AWS アカウント内で直接監視できるようになりました。
この統合では、以下の新しいメトリクスが導入されました:
1. パイプライン実行時間メトリクス:パイプライン完了の総実行時間を追跡
2. パイプライン失敗メトリクス:パイプライン実行失敗の頻度を監視
これらのメトリクスは、CodePipeline コンソールと CloudWatch メトリクスコンソールの両方で追跡でき、パイプラインの健全性を積極的に監視することができます。
この機能は、AWS GovCloud (US) リージョンと中国リージョンを除く、AWS CodePipeline がサポートされている全てのリージョンで利用可能です。
Amazon SES が Virtual Deliverability Manager の段階的価格設定を導入
Amazon Simple Email Service (SES) が Virtual Deliverability Manager (VDM) の新しい価格体系を導入しました。これにより、使用量が多いお客さまはより低い料金で利用できるようになります。
新しい価格体系では、アカウント設定、送信方法、請求設定を変更することなく、VDM の総料金を削減できます。使用量が増えるにつれて、VDM の総所有コストを低減できる可能性があります。
以前は、VDM を利用する全てのお客さまが送信メッセージごとに固定料金を支払っていました。必要に応じて VDM のオン/オフを切り替えることができ、コミットメントや固定月額料金なしで使用分のみを支払う仕組みでした。
新しい価格体系では、毎月の送信量が特定のしきい値を超えると、VDM のメッセージ当たりの料金が減少します。各しきい値を超えた後、VDM で処理される以降のメッセージはより低い料金で課金されます。これにより、大量送信を行うお客さまの VDM 利用における総コストが削減されます。
AWS AppSync がリゾルバーテストを包括的なコンテキストオブジェクトのモックで強化
AWS AppSync(フルマネージドGraphQLサービス)が、EvaluateCodeとEvaluateMappingTemplate APIの改善を発表しました。この更新により、開発者はリゾルバーと関数のユニットテスト中に、コンテキストオブジェクトの全てのプロパティを包括的にモックできるようになりました。これには、ID情報、スタッシュ変数、エラー処理が含まれます。
また、明確で実用的なエラーメッセージを持つ改善されたJSON入力検証が導入され、開発者がコンテキスト設定の問題を特定して修正しやすくなりました。
これらの改善により、セットアップと設定要件が簡素化されました。開発者はテスト環境でリゾルバースタッシュ(ctx.stash)とエラートラッキング(ctx.outErrors)にアクセスして検証することで、効率的に関数とリゾルバーをテストできるようになりました。
更新されたコンソールエクスペリエンスは、リゾルバーのテスト結果をより可視化し、開発者がリゾルバーの実装をより効果的にトラブルシュートおよび最適化できるようサポートします。
AWS AppSync GraphQL が高速な GraphQL API レスポンスのためのオペレーションレベルキャッシュを導入
AWS AppSync GraphQL に、GraphQL クエリ操作のレスポンス全体をキャッシュできる新機能「オペレーションレベルキャッシュ」が追加されました。この機能により、開発者は読み取りの多い GraphQL API を最適化し、応答時間の短縮とアプリケーションパフォーマンスの向上を実現できます。
AWS AppSync GraphQL のオペレーションレベルキャッシュは、クエリレスポンス全体を保存することでキャッシュプロセスを効率化します。この方法は、複雑なクエリや高トラフィックのシナリオで特に有効で、レイテンシーを大幅に削減し、全体的なユーザーエクスペリエンスを向上させることができます。オペレーションレベルでキャッシュすることで、開発者はコードを変更することなく、API の効率を簡単に向上させ、より応答性の高いアプリケーションを作成できます。
この機能は、AWS AppSync GraphQL コンソールまたは AWS CLI を通じてキャッシュ設定を行うことで、すぐに利用を開始できます。
Amazon Q Developer が Java 21 へのアップグレードをサポート
Amazon Q Developer の変換機能が拡張され、Maven を使用した Java アプリケーションを Java 21 にアップグレードできるようになりました。開発者は Amazon Q Developer の生成系AI 機能を活用して、Java 21 へのコードアップグレードを加速できます。
Java Development Kit (JDK) 21 のサポートが追加されたことで、Maven を使用している Java アプリケーションのバージョンを、ソースバージョン 8、11、17、または 21 からターゲットバージョン 17 または 21 にアップグレードできます。また、JDK バージョンをアップグレードせずに、Java 17 または Java 21 互換アプリケーションで使用されているライブラリやフレームワークをアップグレードすることも可能です。
Java 変換機能は、IDE(Visual Studio Code と JetBrains IntelliJ IDEA)と CLI(Linux と MacOS)の両方で利用できます。
CloudWatch Application Signals が .NET アプリケーション向けのランタイムメトリクスをサポート
Amazon CloudWatch Application Signals で .NET アプリケーション向けのランタイムメトリクスが一般提供されました。これは CloudWatch の OpenTelemetry (OTel) 互換のアプリケーションパフォーマンスモニターリング (APM) 機能です。
ソースコードの変更なしで、.NET アプリケーションからガベージコレクションやヒープ使用量などのランタイムメトリクスを収集し、EKS、EC2、ECS、オンプレミスサーバーで実行されているアプリケーションのメトリクス、トレース、ログと相関付けることができます。
ランタイムメトリクスにより、メモリや CPU 使用量などのアプリケーションのリソース消費をリアルタイムで監視できます。開発者や SRE は、ランタイムメトリクスの異常がエラー、レイテンシ、スループットなどの主要なアプリケーションメトリクスに影響を与えているかどうかを判断できます。
例えば、サービスのレイテンシスパイクがガベージコレクションの一時停止の増加によるものかどうかを、これらのメトリクスグラフを並べて表示することで特定できます。さらに、スレッドの競合を識別し、メモリ割り当てパターンを追跡し、アプリケーションの遅延やエンドユーザーエクスペリエンスに影響を与える可能性のあるメモリや CPU のスパイクを特定することができます。
ランタイムメトリクスのサポートは、Java、Python、そして今回 .NET アプリケーションで利用可能になりました。
Amazon CloudWatch が Aurora PostgreSQL のロック競合診断機能を提供開始
Amazon CloudWatch Database Insights が Aurora PostgreSQL インスタンスのロック競合診断機能を提供するようになりました。この機能により、進行中および過去のロック競合問題の根本原因を数分で特定できます。ロック競合診断機能は、CloudWatch Database Insights の Advanced モードでのみ利用可能です。
この機能により、Database Insights コンソールでロック状態を視覚化し、ブロッキングセッションと待機セッションの関係を表示できます。この視覚化により、ロック競合の原因となる主要なセッション、クエリ、オブジェクトを素早く特定できます。さらに、過去のロックデータを15カ月間保持するため、過去のロック状態を分析・調査することができます。カスタムクエリを手動で実行したり、アプリケーションログに頼ったりする必要がなくなり、トラブルシューティングプロセスが効率化されます。
Aurora サービスコンソール、AWS API、または AWS SDK を使用して、Aurora PostgreSQL クラスタで CloudWatch Database Insights の Advanced モードを有効にすることで、この機能を利用開始できます。CloudWatch Database Insights は、フリートレベルで集約されたデータベースの健全性監視と、詳細なデータベースおよび SQL クエリ分析のためのインスタンスレベルのダッシュボードを提供します。
CloudWatch Database Insights は vCPU ベースの価格設定を提供しています。
AWS CloudTrail の VPC エンドポイントに対するネットワークアクティビティイベントが一般提供開始
AWS CloudTrail の VPC エンドポイントに対するネットワークアクティビティ機能が導入されました。これにより、VPC エンドポイントを通過する AWS API アクティビティの可視性が向上し、データ境界の強化とより優れた検出コントロールの実装が可能になりました。
VPC エンドポイントのネットワークアクティビティイベントは、Amazon S3、Amazon EC2、AWS Key Management Service (AWS KMS)、AWS Secrets Manager、AWS CloudTrail の 5 つの AWS サービスで有効化できます。
この機能により、ネットワーク内のリソースにアクセスしている人物の詳細を確認でき、データ境界内の悪意のある、または不正な行為を特定して対応する能力が向上します。例えば、VPC エンドポイントの所有者は、VPC エンドポイントポリシーによって拒否されたアクションのログを表示したり、データ境界外のアクターが S3 バケット内のデータにアクセスしようとしているかどうかを判断したりできます。
AWS CloudTrail コンソール、AWS CLI、SDK を使用して、VPC エンドポイントのネットワークアクティビティイベントのログ記録を有効にできます。新しい証跡やイベントデータストアを作成する際、または既存のものを編集する際に、監視したいサポート対象サービスのネットワークアクティビティイベントを選択できます。全ての API 呼び出しをログに記録するか、accessDenied 呼び出しのみをログに記録するように設定でき、高度なイベントセレクターを使用して追加のフィルターリングコントロールを行うこともできます。
VPC エンドポイントのネットワークアクティビティイベントは、全ての商用 AWS リージョンで利用可能です。
AWS Deadline Cloud が Service-Managed Fleets で Adobe After Effects をサポート
AWS Deadline Cloud に Adobe After Effects のサポートが追加されました。AWS Deadline Cloud は、コンピューターグラフィックスやビジュアルエフェクトを作成するチームのためのレンダリング管理を簡素化する完全マネージドサービスです。
この新機能により、独自のレンダーファームインフラストラクチャーを管理することなく、After Effects プロジェクトを Deadline Cloud に送信できるようになりました。統合機能には、カスタムフォントのサポートやタスクごとにレンダリングする画像シーケンスフレーム数の調整機能が含まれており、After Effects 内で直接ワークフローに合わせたジョブを送信できます。
AWS Deadline Cloud は、After Effects プロジェクトのレンダリングに必要なコンピューティングリソースのプロビジョニングと弾力的なスケーリングを自動的に処理します。Service-Managed Fleets は数分で設定でき、すぐにレンダリングを開始できます。
AWS Transfer Family の Web アプリケーションが AWS CloudFormation でサポートされたことを発表
AWS Transfer Family の Web アプリケーションを AWS CloudFormation テンプレートで作成および管理できるようになりました。これにより、インフラストラクチャー・アズ・コードを通じて Transfer Family の Web アプリケーションを定義およびデプロイし、大規模な一元管理を自動化できます。
CloudFormation テンプレートを使用することで、Transfer Family の Web アプリケーション、関連するカスタマイズ、S3 アクセス許可を単一のデプロイメントでプログラムによってプロビジョニングおよび設定できます。これにより、時間のかかる手動設定が不要になり、部門全体で一貫性のある安全な実装を維持できます。
バージョン管理されたインフラストラクチャーテンプレートを通じて、厳格なセキュリティとコンプライアンス基準を維持しながら、ファイル転送インターフェースを数百から数千のユーザーに迅速にスケールアップできます。
Network Load Balancer がアベイラビリティーゾーンの削除をサポート
Network Load Balancer (NLB) の既存のアベイラビリティーゾーン (AZ) を削除する機能が追加されました。これまでは、既存の NLB に AZ を追加することはできましたが、削除はできませんでした。
この新機能により、お客さまはアプリケーションスタックの場所を変更し、アベイラビリティーゾーン間で迅速に移動できるようになりました。企業合併・買収、事業分割、データレジデンシーのコンプライアンス要件、特定のリージョンでのキャパシティ考慮など、ビジネスニーズの変化に対応できます。
お客さまは ELB API、CLI、またはコンソールを使用して、有効なサブネットのリストを更新するだけで、NLB から1つ以上のアベイラビリティーゾーンを削除できます。
ゾーンを削除すると、NLB のゾーン別 Elastic Network Interface (ENI) が削除されます。そのゾーンのバックエンドターゲットへのアクティブな接続は全て終了し、ゾーン別 IP(および EIP)が解放され、ゾーン別 DNS 名が削除されます。また、削除されたゾーンのバックエンドターゲットは「未使用」となります。
Amazon Inspector がコンテナイメージスキャンのセキュリティエンジンを強化
Amazon Inspector のコンテナイメージスキャンエンジンがアップグレードされました。このアップグレードにより、コンテナイメージで使用されているサードパーティーの依存関係の脆弱性をより包括的に把握できるようになります。
エンジンの強化は自動的に行われ、既存のワークフローに影響を与えることはありません。既存のお客さまは、新しいエンジンがリスクを再評価するため、一部の検出結果がクローズされる一方で、新しい脆弱性が表示されることが予想されます。
Amazon Inspector は、AWS ワークロード(Amazon EC2 インスタンス、コンテナイメージ、AWS Lambda 関数など)のソフトウェアの脆弱性、コードの脆弱性、意図しないネットワーク露出を継続的にスキャンする脆弱性管理サービスです。
AWS Secrets and Configuration Provider が Amazon EKS の Pod Identity と統合
AWS Secrets Manager は、AWS Secrets and Configuration Provider (ASCP) が Amazon Elastic Kubernetes Service (Amazon EKS) Pod Identity と統合されたことを発表しました。この統合により、AWS Secrets Manager からシークレットを、または AWS Systems Manager Parameter Store からパラメーターを取得する際の、Amazon EKS での IAM 認証が簡素化されます。
この新機能により、Kubernetes アプリケーションの IAM 許可をより効率的かつ安全に管理でき、シークレットに対するロールセッションタグを通じてきめ細やかなアクセス制御が可能になります。
ASCP は、業界標準の Kubernetes Secrets Store CSI Driver のプラグインです。Kubernetes ポッドで実行されるアプリケーションが、カスタムコードを必要とせず、シークレットのローテーション時にコンテナを再起動することなく、AWS Secrets Manager からシークレットを簡単に取得できるようにします。
AWS EKS Pod Identity は、Kubernetes アプリケーションの IAM 許可の設定プロセスをより効率的かつ安全に合理化します。この統合により、Amazon EKS 環境でのシークレット管理が強化されます。
以前は、ASCP は認証に IAM Roles for Service Accounts (IRSA) を使用していました。新しいオプションパラメーター "usePodIdentity" を使用することで、IRSA と Pod Identity のどちらかを IAM 認証に選択できるようになりました。この柔軟性により、セキュリティ要件と運用ニーズに最適な認証方法を採用できます。
Amazon FSx for Lustre が Lustre バージョンのアップグレードをサポート
Amazon FSx for Lustre が、既存のファイルシステムの Lustre バージョンをアップグレードする機能を追加しました。これにより、新しい Lustre バージョンの機能強化を既存のファイルシステムで利用できるようになります。
FSx for Lustre は、Lustre コミュニティーがリリースする複数の長期サポート Lustre バージョンをサポートしています。新しい Lustre バージョンは、パフォーマンスの向上、新機能の追加、クライアントインスタンスの最新 Linux カーネルバージョンのサポートなどの利点があります。
AWS マネジメントコンソールまたは AWS CLI/SDK を使用して、数分でファイルシステムを新しい Lustre バージョンにアップグレードできます。
Amazon Elastic Block Store (EBS) がコンソールとAPIでスナップショットの完全なサイズ情報を追加
Amazon Elastic Block Store (Amazon EBS) で EBS スナップショットの完全なサイズが表示されるようになりました。この機能強化により、新しいフィールド「full-snapshot-size-in-bytes」を使用して DescribeSnapshots API を通じてプログラムで完全なスナップショットサイズを取得できます。また、EBS スナップショットコンソールの新しい「Full snapshot size」列にも完全なスナップショットサイズが表示されます。
EBS スナップショットは増分的な性質を持つため、時間の経過とともにボリュームの複数のスナップショットを取得すると、各スナップショットは新しいブロックや変更されたブロックのみを保存し、以前のスナップショットから変更されていないブロックへの参照を維持します。「full snapshot size」フィールドは、そのスナップショットに直接保存されているブロックと以前のスナップショットから参照されている全てのブロックを含む、スナップショットを構成する全てのブロックの合計サイズを示します。
例えば、50 GB のデータを持つ 100 GB のボリュームがある場合、最初のスナップショットであるか後続のスナップショットであるかに関わらず、「full snapshot size」は 50 GB と表示されます。
「full snapshot size」フィールドは、アーカイブ層のスナップショットの総サイズや、スナップショット作成時にソースボリュームに書き込まれたデータ量など、EBS スナップショットストレージに関する重要な情報を提供します。これは、特定のスナップショットに保存された新しく変更されたブロックのサイズのみを指す増分スナップショットサイズとは異なることに注意してください。
Amazon EFS がファイルシステム当たり最大10,000のアクセスポイントをサポート
Amazon Elastic File System (Amazon EFS) のアクセスポイント制限が、ファイルシステム当たり1,000から10,000に10倍増加しました。これにより、共有データセットへのアプリケーション固有のアクセス管理がさらに容易になり、単一のEFSファイルシステムで数千ユーザーへのアクセス管理をシームレスにスケーリングできるようになりました。
Amazon EFSは、AWSクラウドでファイルワークロードの設定と実行を簡単にする完全な弾力性を持つファイルストレージサービスです。アクセスポイントは、ユーザーIDとルートディレクトリーを強制し、アプリケーション間でデータを論理的に分離するアプリケーション固有のエントリーポイントです。
新しいEFSアクセスポイント制限は、全てのファイルシステムに自動的に適用され、お客さまの操作は不要です。
今週のWeekly AWSは、以上です。最後までお読みいただき、ありがとうございました。
ソフトバンクはAWS アドバンストティアサービスパートナーです
「はじめてのAWS導入」から大規模なサービス基盤や基幹システムの構築まで、お客さまのご要望にあわせて最適なAWS環境の導入を支援します。
MSP(Managed Service Provider)サービスは、お客さまのパブリッククラウドの導入から運用までをトータルでご提供するマネージドサービスです。
条件に該当するページがございません