AMI の作成と共有に Service Quotas が設けられました!

AMI の作成と共有に Service Quotas が設けられました!

Clock Icon2022.10.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Amazon Machine Image (以降、AMI) は Amazon EC2(以降、EC2)起動に必要な情報をイメージとして保存する機能で、EC2 を利用する上ではコアな機能です。

今回 AMI の作成と共有に関して Service Quotas 上で、3つの Quotas が設けられました。

今まで AMI 作成や共有には制限が設けられておらず、ミス等により意図しない数の AMI を作成してしまうというリスクが内在していたようです。(コア機能と書いておきながら、リリース記事の中で初めて知りました)
今回制限を設けるのは、その対策のためとのことです。(ありがたい)

Previously, you could generate an unlimited number of AMIs and share them publicly using one AWS account. However, a run-away script could potentially create tens of thousands of AMIs, causing significant clean-up costs and efforts. These new quotas help govern the total number and shares of AMIs, reducing accumulation of resources and associated costs.

↓↓↓ 機械翻訳 ↓↓↓

以前は、無制限の数の AMI を生成し、1 つの AWS アカウントを使用してパブリックに共有できました。ただし、ランナウェイ スクリプトは潜在的に何万もの AMI を作成する可能性があり、多大なクリーンアップ コストと労力を引き起こします。これらの新しいクォータは、AMI の総数とシェアを管理するのに役立ち、リソースの蓄積と関連コストを削減します。

今回、追加された Quotas は下記の通りです。

Quotas 名 デフォルト値(リージョン単位) 説明
AMIs 50,000 パブリックおよびプライベート AMI の最大数
(使用可能な AMI と保留中の AMI、およびごみ箱内の AMI が含む)
Public AMIs 5 ごみ箱内のパブリック AMI を含むパブリック AMI の最大数
AMI sharing 1,000 AMI を共有できるエンティティ (組織、OU、およびアカウント) の最大数
(AMI を組織または OU と共有する場合、組織または OU 内のアカウントの数はクォータにカウントされない)

いづれもワークロードのユースケースによっては、注視すべき Quota となるかと思います。

引用①: Amazon Elastic Compute Cloud User Guide for Linux Instances - AMI quotas
引用②: AWS 全般のリファレンス リファレンスガイド - Amazon EC2 エンドポイントとクォータ

Service Quotas での確認

Service QuotasAWS のサービスAmazon Elastic Compute Cloud (Amazon EC2) > AMI で検索

新しく追加された 3つの Quota が表示されました。

上限緩和申請

試しに、上限緩和申請を行ってみます。

Public AMIs を選択 > クォーターの引き上げをリクエスト

クォータ値を変更: へ入力 > リクエスト

Service Quotasクォータリクエスト履歴 > ステータスが「保留中」であることを確認

ステータスが「承認されたクォータリクエスト」になってことを確認

Service QuotasAWS のサービスAmazon Elastic Compute Cloud (Amazon EC2) > AMI で検索

上限緩和が承認され、値が更新されました!

Service Quotas 値の監視

いつの間にか上限に達して、サービスに影響が出ないように、一部の Service Quotas の値は CloudWatch により監視・通知の設定が行えます。

今回追加になった Service Quotas については、私の環境では、メトリクスを見つけることが出来ませんでした。(2022.10.17 時点)
検証環境で AMI が一つも潜在せず、記事作成中に作成したため、メトリクス取得のサイクルを満たしていないのか(後ほど改めて確認してみたいと思います)、元々対象外なのかが明確に確認出来ませんでしたが、対象となる場合は上記手順を利用して状況を確認することで予期せぬトラブルを未然に防ぐことが可能です。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.