AWSの新規顧客は現在、Google、GitHub、Appleのログインでサインアップでき、Free Tierのクレジット$100から開始し、AWSとコーディングエージェントが自動的に権限を設定する「プロジェクト」内で開発を進められるようになりました。有料プロジェクトには毎月の支出上限が設定され、最低$20から始まります。上限に達したプロジェクトはさらなる課金が発生する前に停止されます。後で複数リージョンや一元的なガバナンスが必要になったオーナーは、移行作業なしでAWSのフル機能セットを有効化できます。この展開は段階的に行われ、対象は新規顧客のみとなっています。
新規アカウントが得られるもの
新規のAWS顧客は、何かを構築する前に環境を設定する必要がありません。サインアップは既存のGoogle、GitHub、Appleのアカウントで行うことができ、ほとんどの新規顧客はクレジットカードを入力する必要もありません。各アカウントは「プロジェクト」として立ち上がります。これは1つのAWSアカウントと、それを共有するための設定をまとめたものです。AWSはサインアップ時にこの構造を構築し、詳細が公表されていないセキュリティ制御も追加します。
AWSのシニアソリューションアーキテクトであるMicah Walter氏は、この一連の流れを試してみました。Googleアカウントでサインインしたところ、数秒でプロジェクトの準備が整ったといいます。最初の画面には、コーディングエージェント用のテキストブロックが表示され、Walter氏はそれを貼り付けました。すると程なくしてエージェントがログインを済ませ、AWS Command Line InterfaceとAgent Toolkit for AWSがインストールされ、セットアップ手順をまとめたCLAUDE.mdファイルがプロジェクト内に用意されていました。
続けて彼は、リクエストのたびに新しい連番IDを返すAPIをエージェントに依頼しました。エージェントはアーキテクチャの選択肢を提示した後、AWS Lambda関数、Amazon DynamoDBテーブル、Amazon API Gatewayエンドポイントを作成してデプロイしました。数分後には、IDを払い出す公開URLが出来上がっており、Walter氏は一度も権限ルールを書くことはありませんでした。この仕組みでは、従来はアカウントオーナーの管轄だった2つの判断――どのユーザーや何が各リソースにアクセスできるか、そして支出をいつ打ち切るか――が、いまやデフォルト設定によって決められています。自社アプリの稼働継続をユーザーに期待されている立場の人は、こうしたデフォルト設定がどこで限界を迎えるのかを把握しておく必要があります。
上限に達するとプロジェクトは停止する
新規アカウントはすべて、Free Tierのクレジット$100からスタートします。Walter氏のプロジェクトでは、Lambda関数をデプロイした際にさらに$20分のクレジットが付与されました。ただし、すべての新規アカウントが同じように追加ボーナスを得られるのかどうかについては、公開されているリリース資料に記載がありません。
有料プランへの移行には、支払い方法の追加と、プロジェクトごとの毎月の支出上限の設定が必要で、最低額は月$20からです。この上限は料金そのものではなく、あくまで上限額として機能します。上限額を$50に設定したプロジェクトがその月に$32分のサービスを利用した場合、請求額は$32に税金を加えた額となります。AWSは過去の利用実績に基づいて上限額を提案しますが、オーナーはそれを承認することも、今後の成長を見込んでより高い金額を入力することもできます。
プロジェクトが上限に近づくと通知が届きます。支出が上限に達すると、「課金を積み上げ続けるのではなく、プロジェクトを一時停止します」とされており、オーナーが上限を引き上げれば作業を再開できます。予算はプロジェクトごとに設定されるため、オーナーは使い捨てのアイデア用プロジェクトを$20の下限に据え置く一方で、利用者を獲得しつつあるプロジェクトにはより多くの余裕を持たせることができます。
停止されたプロジェクトが稼働中の公開エンドポイントにどのような影響を与えるかについては、明記されていません。プロジェクトが実際のユーザーにサービスを提供している場合は、この上限を安全網として扱う前に、事前に確認しておくべきでしょう。アプリを稼働させ続ける価値を生むトラフィックこそが、まさに予算を消費するトラフィックでもあるからです。
アクセスルールを書くのはエージェント
チームメンバーはメール招待を通じて参加します。IAMユーザー(AWS Identity and Access Managementが通常、誰が何をできるかを判断するために使う名前付きIDのこと)を作成する必要はなく、招待された各メンバーは、オーナーが指定したプロジェクトのみを閲覧できます。プロジェクトの追加はクリック一つで完了します。
リソースの権限設定も同様の仕組みです。コンソールのワークフローとコーディングエージェントが、対応するサービス間のアクセス権を自動的に設定します。Walter氏が使った3つのサービスが、ポリシーに一切触れることなく連携できたのもこの仕組みによるものです。どのサービスが対応対象に含まれるかは公表されていません。実際のところ、コードをデプロイしたエージェントが、そのコードがアクセスできる範囲も設定しているということになります。後になってアカウントを確認する人は、人間が選んだものだと決めつけず、こうした権限付与の内容をきちんとチェックすべきでしょう。
デフォルト設定からの卒業
プロジェクトの中には、複数のAWSリージョンや、多数のアカウントを一元的なルールで管理するサービスであるAWS Organizations上のカスタムポリシーを必要とするものもあります。そうしたプロジェクトは、追加費用なしで高度な機能を有効化できます。アカウントは、ワークロードを移動させたりオフラインにしたりすることなく、設定済みのAWS Organization内に配置されます。
切り替え前に設定されていた内容はすべてそのまま維持され、公開されているリリース資料では、最初の1週間にエージェントが書き上げたアクセスルールについて、特に除外規定などは設けられていません。そうしたルールは、次にそのアカウントを管理することになる人にとっての出発点となるのです。
翻訳元: https://www.helpnetsecurity.com/2026/09/17/aws-spend-limit-agent-set-permissions/