はじめに

本記事はAWS SAAの合格体験記ですが、SAAに特化した内容ではありません。
当日の時間配分や、模試サイトと本番の難易度差といった、受験直前の方に役立つ情報は載っていません。
一方、「AWS、似たようなサービスが多すぎてもうよくわからん！！」となっている方には持ち帰っていただける情報があるかもしれません。

自己紹介と勉強方法

自己紹介
- 新卒5年目（文系学部卒・プログラミング未経験で入社）
- アプリケーションエンジニア（Java・Linux環境）
- AWSは構築・運用共に未経験
勉強時間
- 3ヶ月
- 週8時間くらい
- 合計100時間くらい
勉強方法
- Udemy（多少ハンズオンあり）
- Ping-t（模擬問題＆テキスト。一番ウエイト高め）
- Claude（適宜）

試験勉強で感じていた限界

AWS SAAは、AWS独自の言葉や概念の知識が必要なので、未経験の筆者の場合、触れたことのない知識の大量インプットが必要でした。

これまでもいくつか資格試験を受けてきましたが、いつも無防備な大量インプットに頼っており、限界を感じていました。

具体的には、問題を解くたびに、知識が汚染されていく感覚に陥っていました。
知識体系がソースコードだとすると、新しい知識の継ぎ足しでスパゲッティ化していく感覚です。

具体例：知識のスパゲッティ化とはどういう現象か

S3へのアクセス権限の話を例に挙げます。

勉強の序盤、ある問題を通じて私はこう覚えました。

S3にアクセスするには、アクセスする側とされる側の両方で許可を出す必要がある。
アクセスする側（IAM）だけでなく、される側（バケットポリシー）でも許可がいる。

なるほど、と思って頭の中に、こういう1行が刻まれます。

if (S3にアクセスしたい) # 両方で許可が必要

ところが後日、別の問題でこう出てきます。同一アカウント内なら、アクセスする側の許可だけでアクセスできる、と。……あれ？両方必要じゃなかったのか？前に覚えたことと食い違います。

正しくは「クロスアカウント（別のアカウント間）なら両方の許可が必要」で「同一アカウントなら片方でよい」、という話でした。最初に覚えたのは、たまたまクロスアカウントを前提にした知識で、私はそこに「クロスアカウントのとき」という条件のラベルを貼り忘れていたのです。

だから、頭の中の1行はこう書き換わる。

if (S3にアクセスしたい) {
    if (クロスアカウント) # 両方で許可が必要
    else (同一アカウント) # アクセスする側だけでよい
}

これだけなら、大した話ではありません。分岐が1つ増えただけです。

問題は、これがAWSの学習中、あらゆる場面で起き続けることにあります。新しい問題を解く度、前に覚えた知識に条件が見つかり、分岐が増えていく。しかもAWSは似たようなサービスがやたら多いので、あらゆる分野で似たような課題が生じます。そのたびに私は、既存のコードに新しいif文を継ぎ足していきます。

気づけば、覚えたAWS知識は、見通しの悪いスパゲッティコードになっています。

知識もリファクタリングが必要

ここでいうリファクタリングとは、知識を自分の覚えやすい形に整理するようなイメージです。

「そんなの当たり前だろう」と言われたらその通りで、目新しいことは何も言っていません。

ではなぜこんな当たり前のことを主張するのか。

「問題を解くだけ」で受かる人と受からない人がいる

技術系の資格合格体験記でよく目にするのが、「黒本だけでOK」「座学から入るのはコスパ悪し」「模試を先に解きながら覚えた方が良い」など、「問題を解くだけで実力がつく」という説です。

元から試験範囲のバックグラウンドを持っていたり、自然と積み上がった知識を整理できる人ならこの方法が最適解のように思われます。

私も実務経験のあるJavaの資格試験では問題集をひたすら解いていたのですが、AWS SAAにそれは通用しなかったのです。

何も意識せずに問題だけ解いていると、積み上がった知識が整理されないまま記憶してしまう。参照に時間がかかり、タイムアウト（試験時間終了）。

意識的なリファクタリングの工程を省いて「問題を解いていればいつの間にか体系的な知識が身についている」というわけにはいきませんでした。

今回は筆者が試した知識のリファクタリング方法を二つ紹介します。
一つ目は簡単で効果も安定、二つ目は難しいが未知の問題にも効く、といった感じです。

リファクタリング①：正規化

一つ目の方法は、データベースの正規化と同じ発想です。

たとえば私は、AWSのDBサービス同士の違いが、なかなか覚えられませんでした。勉強中の頭の中は、こんなふうに個別の知識がバラバラに書き込まれた状態でした。

{
  "RDS": "マネージドなRDB。自動バックアップとスナップショットがある。マルチAZ構成にできる。PITRができる",
  "Aurora": "RDSより速いらしい。クラスタ構成。継続的バックアップとPITR。スナップショットも取れる。リードレプリカが多く作れる",
  "DynamoDB": "NoSQL。サーバーレス。PITRがある。オンデマンドバックアップというのもある。キャパシティモードが2種類",
  "//": "……問題を解くたびに、こういうメモが増えていく"
}

一つひとつは、間違ってはいませんが、これらは私の頭の中でサービスごとに独立したメモとして並んでいるだけでした。だから、いざ問題で「DynamoDBのPITRで復元できるのは何日か」と問われると、「これはRDSの話だっけ、DynamoDBの話だっけ」と混乱して正解を引っ張ってこれませんでした。

問題なのは、暗記の軸がサービス単位しかなく、「DBに備わっているべき機能」の観点がないことでした。

そこで、サービスを表に落とし込みます。行にサービス、列に機能の観点を取って、格子状に並べ直します。

観点	RDS	Aurora	DynamoDB
種別	RDB（マネージド）	RDB（AWS独自エンジン）	NoSQL
冗長化	マルチAZ配置（スタンバイは待機のみ）	3AZに6つのデータコピー	3つのAZに自動保存
読み取り拡張	リードレプリカ最大15台	Auroraレプリカ最大15台（自動フェイルオーバー兼任）	自動でスケール
PITR	あり（最大35日）	あり（最大35日）	あり（最大35日）
手動バックアップ	スナップショット（無期限）	スナップショット（無期限）	オンデマンドバックアップ（1日〜永続）
保管時の暗号化	作成時のみ有効化可	作成時のみ有効化可	デフォルトで有効

※2026年7月時点の仕様です。

表にすると、似たようなサービス同士を丸ごと比較する必要がなくなり、各観点ごとに比較できます。

例）
PITRは3つとも最大35日(サービスごとに覚える必要がない)
暗号化の観点だと、RDB系が作成時のみ有効化可、DynamoDBがデフォルトで有効

多数派の特徴と少数派の差分だけを押さえることで、覚える総量が減ります。

正規化の作業は、軸を二つとってしまえば、あとは事実を流し込んでいくだけなのでそこまで大変な作業ではありません。その割に、知識の見通しは良くなります。

紙に書くのがおすすめ

筆者の場合は。試験直前に以下のような表を書いていたらそのあたりの問題が出て助かりました（無理して全部埋める必要はないです）。

リファクタリング②：抽象化

正規化が知識を横に並べる作業だとすると、もう一つは縦に掘る作業です。こちらの方が難易度が高いです。

SAAには、稼働中のリソースを途中で設定変更できるか、それとも作り直しが必要か、というたぐいの問題が出ます。そのたぐいの知識をかき集めると、以下のような知識の束が出来ます。

{
  "RDSを後から暗号化したい": "不可。スナップショットから作り直す",
  "EBSを後から暗号化したい": "不可。スナップショットから作り直す",
  "EBSの容量を増やしたい": "可。稼働中でも拡張できる",
  "EC2のインスタンスタイプを変えたい": "可。停止すれば変更できる"
}

作り直しが要るものと、そのまま変えられるもの。正規化で横並びを揃えても、結局その一つ一つを覚えるのは苦痛です。
そこで、「これら個々の特徴を自然に導き出せる上位概念がないか？」と疑ってかかります。

とはいえ素人の自分だけでは上位概念を見つけ出せないので、この知識の束をClaudeに投げつけます。

そしたらこんな感じの回答が（抜粋）↓↓

上記の知識の束の上位概念として、「その変更はデータの中身を書き直すか否か」という観点が手に入ります。

これを知った状態だと、例えば「RDSのDBエンジンをMySQLからPostgreSQLに変えたい」みたいな問題が出たときに、仕様を知らなくても「データの格納形式が変わるから途中変更不可のはず（作り直しが必要なはず）」と導き出せます。

正規化は既知の知識を整理して覚えやすくする一方、未知の問題には対処できません。抽象化は未知の問題でも当たりをつけられる可能性があります。

抽象化は継続的なリファクタリングが必要

正規化に比べると、抽象化は難易度が高いです。
一度抽象化に成功して上位概念を手に入れたと思っても、問題を解いているとすぐにその反例にぶち当たります（暗澹たる気持ちになります）。

そしたら、また反例となる問題をClaudeに投げつけて更なる上位概念を出してもらいます。この作業は反例が見つかるたびに繰り返しとなります。そして、このリファクタリング作業は試験日までに終わりません。

抽象化は正規化に比べると正確性が保証されないし時間もかかるという弱点がありますが、結局はこのClaudeとの会話が一番知識の地盤を固めてくれたような気がします（音声入力で本当に会話していました）。

終わりに

今回二つの「リファクタリング」方法をご紹介しましたが、記事を書き終えてみると、もしかすると今までも自然にやってきた方法かもしれないと思いました。
とはいえ、今回こうして明示的にラベルをつけたことで、便利な道具を引き出しやすくなった側面はあるはずだと自分を励ますことにします。

試験勉強を始める前は、仕事でAWSの話題になると、途端に解像度が下がってストレスを感じていましたが、資格勉強を通じて「何の話をしているのか」くらいは分かる瞬間が増えましたし、AWS構成図にアレルギーがなくなったのも大変良かったことです。

また、AWS SAAの勉強を通じて得られるものは何もAWS固有の知識ばかりではなく、ネットワーク、認証技術などの基礎知識も含まれます。エンジニア一般の知識の底上げにもなる点が満足度の高い資格だと思いました。

とはいえ筆者自身はまだAWS周りの技術について具体的に語れることはなく、技術知識そのものというよりはその覚え方を残しておくほうが意義のあることだと思いましたので、この記事を書きました。

筆者が学生時代に嫌っていた自己啓発というジャンルの読み物に図らずも本記事の内容が寄ってしまったことを皮肉に感じつつ、記事の締めくくりとさせていただきます。