AWS SAA の学習を始める前にやったこと
AWS SAA（Solutions Architect - Associate）の学習を始める前にやったことと、こうしておけばよかったと後悔した失敗をまとめました。 私自身うっかりしていたところがあったので、もっとお得に始めるための話と、高額請求のような最悪の事態にならないためのリスクマネジメントを含めています。
きっかけ
講座を買う前に Udemy のレビューを眺めていたら、こんな投稿があった。
先日こちらで受講したのですが、誤って ElastiCache を削除し忘れてしまい、本日 17 万円も請求が来ていた
学習用に数時間動かすつもりのリソースを消し忘れただけで、受講料の 100 倍近い請求になる。 「気をつける」では防げない類の失敗なので、講座を始める前に仕組みで止める準備をすることにした。
始める前からすでに失敗していた
まずは、「やったこと」というよりは「やってしまったこと」から。 「多分そのうち AWS をやると思う」という理由で、2 年前にアカウントだけ作ってあった。 作ったこと自体をすっかり忘れていて、今回ログインしようとして初めて思い出した。 当時の無料利用枠はアカウント作成から 12 か月間が対象だったので、何も触らないまま無料枠が消えるという残念なことになりました。
さらに痛いのは、2025 年 7 月 15 日に無料利用枠の仕組みが変わったこと。
| 2025 年 7 月 15 日より前に作ったアカウント | それ以降に作ったアカウント | |
|---|---|---|
| 無料枠 | 従来どおり 12 か月の無料利用枠 | 最大 200 ドル分のクレジット（サインアップで 100 ドル + 対象サービスの利用で 100 ドル） |
| 期間 | 作成から 12 か月 | 無料プランは 6 か月 |
| プラン | 選択なし | 「無料プラン」と「有料プラン」を選ぶ。無料プランはクレジットを使い切るか 6 か月で終了 |
今から作れば 200 ドル分のクレジットで講座のハンズオンをほぼ賄えたはずが、自分のアカウントは旧制度のまま無料枠も終わっている。
関心を持つことはとっても良いことなのですが、「多分やる」「興味ある」の段階でアカウントを作るのは無料で使える機会を無駄にするだけでした。 アカウントは AWS 資格の学習を始める直前に作成すればよかったです。
参考:
Udemy はセールを待つべし
Udemy の講座はちょいちょいセールをやっているので、定価よりも安く買えることが多いです。
セールのタイミングを狙って 2,600 円 → 1,800 円で購入できました。
SAA の講座は 2,600 円と全体で見ると安い価格なので、ついつい待てずにポチりそうですが、セールを利用するのがオススメです。
あとはセール情報のメール通知を ON にするのも良いかもしれません。 Udemy の通知の設定で「オファーとプロモーション」にチェック。
ちなみに買ったのは コレ↓
【SAA-C03版】これだけでOK! AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座。
高額請求になりうるサービスを AI と洗い出し
講座を始める前に、AI（Claude・ChatGPT）を壁打ち相手にして「学習中に高額請求される可能性が 1% でもあるサービス」を洗い出しました。 よく「消し忘れによる高額請求」というワードを技術ブログで見るものの、「いや高額請求するようなサービスを企業は喜んで使っているの？」など疑問点が多かったからです。
| サービス | 危険ポイント |
|---|---|
| NAT Gateway | 使っていなくても時間課金 + 通信量課金。VPC を作る手順で何気なく立ち、消し忘れやすい。高額請求の原因として最も多く挙がる |
| ElastiCache | ノードが動いている限り時間課金。レビューの 17 万円はこれ |
| RDS / Aurora | インスタンスが動いている限り時間課金。停止しても 7 日で自動的に再起動する |
| OpenSearch Service | ドメインを作るとノード単位で時間課金。検証で作ると高い |
| EC2 | 止め忘れ。インスタンスを停止しても EBS ボリュームの料金は残る |
| Elastic IP | インスタンスに紐づいていない状態で放置すると課金される |
| ALB / NLB | ターゲットがなくても存在するだけで時間課金 |
| EKS | クラスターを作った時点で時間課金。ノードとは別 |
どうやら作った瞬間から時間課金が始まり、使っていなくても止まらないみたい。 講座のセクションを中断・終了するときに、作ったリソースをその場で必ず消す。
ちなみに、こんな危険なサービスを企業はなぜ使うのか
洗い出しの途中で一番引っかかったのがこの疑問でした。 「個人が設定をミスっただけで数十万円、場合によっては数百万円の請求が発生するサービスを、なぜ企業は積極的に採用するのか？」 人々が「クラウド破産」「高額請求」と後悔し、嘆くようなサービスをなぜ企業は喜んで使うのか全く理解できていませんでした。
答えは予算、可用性、スケーラビリティの 3 つでした。（※多分もっとある）
- 予算: サーバーをオンプレで管理したり面倒を見る人件費より、時間課金の方が安いかも。17 万円は個人には大金だけど、企業の予算感では小さい
- 可用性: 自前のサーバーは落ちたら自分で直す。マネージドサービスは落ちにくく、落ちても勝手に戻る
- スケーラビリティ: アクセスが増えたら設定一つで増やせて、減ったら戻せる。本とかでよく見る水平スケーリングのやつ。「止めるまで課金が続く」はこの裏返しってことですね
そして企業には予算アラートなどのコスト管理の仕組みがあるので、消し忘れても早く気づける。
エンタープライズや大規模サービスにはもってこいな雰囲気が掴めたね。
予算アラートを 2 種類の設定
消し忘れを「気をつける」で防ぐのは無理なので、請求額が動いた時点で通知が来るようにした。 AWS Budgets で予算を作る。予算の作成と通知だけなら無料。 今回の学習ではだいたい 3,000 円ぐらいを予算にして、上限 15 ドルで設定。
| 種類 | 設定 | 狙い |
|---|---|---|
| ゼロ支出予算 | 実績が 0.01 ドルを超えたら通知 | 「何かが課金され始めた」ことを最速で知る |
| 年額予算 | 上限 15 ドル。実績 50%、実績 80%、予測 100% の 3 段階で通知 | 消し忘れで積み上がる前に止める |
年額予算の方は、しきい値を 3 つ設定した。
ただしこれには注意。
- Budgets のデータ更新は 1 日最大 3 回。通知が来た時点で数時間分は課金されている。日次の上限管理には向かない
- 通知先のメールアドレスは普段見るものにする。見ないアドレスに送っても意味がないし、迷惑メールに振り分けられる可能性もある
実際、アラート設定の確認メールは Gmail の迷惑メールフォルダに届いた。 しかも「このメールは危険である可能性があります」の赤い警告付き。 実際のアラートメールは未検証だけど迷惑メールフォルダに気づかないまま放置すると、アラートの意味なし。
参考:
ルートユーザーを封印
高額請求のもう一つの経路は、アカウントの乗っ取り。 ルートユーザーの認証情報が漏れてマイニングとかされたら激痛。
やったことは 2 つ。
- ルートユーザーに MFA を設定した。コンソール右上のアカウント名 →「セキュリティ認証情報」から Google Authenticator を登録して、パスワードだけではログインできない状態にした
- IAM ユーザーを作り、普段はそちらでログインする。ルートユーザーは請求設定など、ルートでしかできない作業のときだけ使う
MFA 設定でつまずいたこと
MFA の設定画面で、6 桁の数字を 2 回求められるところでつまずいた。 コードは 30 秒ごとに切り替わるので、1 個目を入れたら切り替わるのを待って、新しい方を 2 個目に入れる。
MFA コード 2 は、1 個目を入れたあとに認証アプリに表示される次の数字だよ！
IAM ユーザーの作成
- ユーザーの詳細を指定
IAM →「ユーザー」→「ユーザーの作成」。ユーザー名を入れ、「AWS マネジメントコンソールへのユーザーアクセスを提供する」にチェック
パスワードは「カスタムパスワード」で自分で決める。「次回のサインイン時に新しいパスワードを作成」は外してよい
- 許可を設定
「ポリシーを直接アタッチする」→
AdministratorAccess。学習用なので割り切る
- 確認して作成 → パスワードを取得
完成画面のコンソールサインイン URL
https://<アカウント ID>.signin.aws.amazon.com/consoleをブックマーク
このとき URL にアクセスするのは別ブラウザにすることをオススメする。同じブラウザで開くとルートのセッションが切れて、コンソールから追い出される - IAM ユーザーにも MFA を付ける
「セキュリティ認証情報」→「MFA デバイスの割り当て」。ルートと同じく認証アプリで
- 請求情報へのアクセスを許可する
ルートのまま「アカウント」→「IAM ユーザーおよびロールによる請求情報へのアクセス」をアクティブ化。これをしないと IAM ユーザーから Budgets が見えない
- IAM ユーザーでログインし直す
ルートからサインアウトし、控えた URL から IAM ユーザーでログインできることを確認
アクセスキーは作らない。CLI を使う段階になったら、SignInLocalDevelopmentAccess ポリシーを付けて aws login でブラウザ認証する方が、長期キーを手元に置かずに済む。
まとめ
- Udemy はセールを待って買う
- AWSアカは学習開始直前 or 講座を買った日に作る
- アカウントを作ったその日に、ルートユーザーに MFA を設定し、IAM ユーザーを作る
- 予算アラートを設定する
- 高額請求になりうるサービスを調べておく
- リソース消し忘れ防止する
正直洗い出しをやる前の段階では、どのタイミングで課金されるのか料金体系が全くわかっていませんでした。