年末の駆け込みで、なんとかAWS Certified Solutions Architect Professional（SAP-C02）に合格することができました！嬉しい！
この記事ではSAPで出題される各分野の振り返りと雑感を書いていこうと思います。AIライティングはしてません。僕の文章です。
試験の出題分野は、AWS公式の試験ガイド（シラバス）から参照します。
なぜ受験したのか
普段はバックエンドエンジニアとして、GoとAWSを使った開発の仕事をしています。
AWSの仕事をもっともっと任せてもらえるようになるために、少なくともSAPに合格できるくらいの知識と粘り強さを見せないとダメだなと考え、取得を目指しました。
ゼロからインフラアーキテクチャを構築するような経験はまだないのですが、既存のインフラのバージョンアップや数値の見直し、LambdaとSQSの追加、アラート対応、IaCとCI/CDを使ったデプロイ作業などは実務で担当させていただきました。サービスでいうと、Lambda、SQS、Aurora、DynamoDB、ECS、CloudWatch、CloudFormation、CDK、CodeBuild、CodePipelineあたりです。
SAPの試験範囲には、こうしたモダンな構成だけでなく、オンプレミス環境からの移行や大規模なネットワーク再構築といった内容が数多く含まれます。
オンプレを触ったりクラウドへの移行作業をしたりすることは当面なさそうで、SAPで勉強した内容がダイレクトに実務で活きるとは思えませんが、クラウド（AWS）の良いところ・悪いところを知るには、クラウドのことを勉強するだけでなく、オンプレのことも知る必要があるなと思い、SAPに合格する程度のオンプレのことは勉強しておこうと考えました。
1. 複雑な組織に対応する設計
ネットワーク接続戦略を設計する。
Transit GatewayやDirect Connect、Route53 Resolverなど、オンプレとAWSを連携させるいかにもSAPっぽい内容です。私の担当しているプロジェクトではVPCが何十個・何百個とあるわけでもなく、オンプレを運用する場面もないので、なかなかイメージがつきづらい分野だなー…と思いながら勉強していました。
この分野については、みのるん（@minorun365）さんのスライドが非常にわかりやすくて、SAPの勉強中には何度も読み返しました。問題を解くときも、スライドの図解を頭の中で浮かべながら、「この場合はこうなって、だからこの選択肢が正しいはず」と考えて解くようにしていました。
おかげでSAPの問題はある程度解けるようになったので、みのるんさんには大感謝です。
セキュリティコントロールを規定する。
IAM Identity Center、IAM Access Analyzerなど、IAMに関する現在のベストプラクティスをキャッチアップする良い機会になりました。AWSのベストプラクティスって数年ごとに変わりますからね。
IAMについて体系的にまとまったものが欲しいと思い、佐々木拓郎（@dkfj）さんの『IAMのマニアックな話』を買いました。正直全部は読めていないですが、SAPで出題される内容の整理に役立ちました。実務でもIAMは触ることが時々あるので、必要なときにまた読み返そうかなと思います。
IAM以外の部分でいえば、既存のデータを暗号化したい場合の対応についての説明が面白かったですね。「S3のデフォルト暗号化を設定しても、既存オブジェクトには適用されない」という仕様は、実務でも絶対にハマる人がいそう、というか知らなかったら自分がハマってたはずです。
このあたりはランサムウェア対策とも関連しており、被害が増加している近年において、ちゃんと勉強したいなと思いました。
信頼性と耐障害性に優れたアーキテクチャを設計する。
災害やシステム障害に対応できるシステムをどうやって構築する？、という内容です。いわゆるDR戦略ですね。ここではオンプレミスも絡めたDR戦略について出題されます。
SAPの勉強前はバックアップとマルチリージョンしか知らなかったのですが、パイロットライトとウォームスタンバイという中間の手法もあることを知りました。AWSブログ以下の画像がわかりやすかったです。
また、以下の記事もコンパクトにまとまっていて知識の整理に役立ちました。
DR戦略の概念や対処方法はわかったものの、現実としてマルチサイトやっている企業ってどれくらいあるんだろう、どれくらい予算いるんだろう、みたいな疑問は残っています🤔（日本自体が大変な状況に陥っているときに即時で動く必要があるのか等）。追々調べていこうかなと思います。
マルチアカウント AWS 環境を設計する。
ここも近年のベストプラクティスであるマルチアカウントについて知れる良い機会になりました。OrganizationsとControl Towerについてですね。
個人用のAWSアカウントでマネコンからOrganizationを使ってOUを作ったりSCPを適用させたりしながら勉強しました。お金もかからなかったはずなので、これから勉強する方は実際に自分でポチポチ触ってみることをおすすめします。
SCPを触ってみて理解したのは、「SCPは許可を与えるものではなく、ガードレール（境界線）を引くもの」だということです。IAMでどんなに強い権限を持っていても、SCPで制限されていれば何もできない。教科書どおりの内容ですが、実際にマネコンを触っているとたしかにそれが分かりました。
あと、クラスメソッドさんの動画が分かりやすかったです。座学ばかりだと疲れちゃうので、移動中にラジオとして聞くのによかったです。
今後新たにAWS環境を構築する際はマルチアカウントにしたいねと社内でも話していたので、もしその機会が来た時にはSAPで勉強した内容を活かしたいなと思います。
コスト最適化と可視化の戦略を決定する。
マルチアカウントならタグ付けによるコストの整理ちゃんとやろうねと学んだのと、Trusted AdvisorとCompute Optimizerの違いについて理解したくらいです。あとはSAP勉強前の知識で解けたのでそんなに勉強は力入れませんでした。
2. 新しいソリューションのための設計
ビジネス要件を満たすデプロイ戦略を設計する。
IaC、CI/CD、ブルー/グリーンデプロイメントなどDevOps的な内容。今担当しているプロジェクトでCloudFormationとCDK、Codebuild、CodePipelineを使っているので、馴染み深い内容でした。（逆に馴染みのない人には難しい分野かもしれません）
ブルーグリーン/デプロイ中にトラフィックを移行する方法として、カナリアデプロイメント、Linearデプロイメント、一括デプロイメントがありますが、それぞれ名前からどんなデプロイ手法なのか連想できるのでそこまで難しくないです。
個人的にCloudFormationよりもCDKの方が好きなのですが、SAPではさすがにCloudFormationに関することの方が出題は圧倒的に多いですねー。
事業の継続性を確保するソリューションを設計する。
DR戦略についてですが、オンプレの文脈というよりは、AWSのRoute53やAPI GatewayなどAWSのお馴染みのサービスを深掘った内容でした。
お馴染みのサービスではあるものの、Route53のフェイオーバールーティング、RDSのリードレプリカ、S3のクロスリージョンレプリカなど、DR文脈で意識しないと知らない機能がよく出てくるので、お馴染みのサービスだから大丈夫やろ〜と高をくくっていると問題解けずに焦ります。
要件に基づいてセキュリティコントロールを決定する。
ALB、NLB、Global Accelerator、WAF、Shield Advanced、Firewall Managerなどなど。ネットワークセキュリティ、認証認可、データ保護、外部脅威対策など幅広い分野が問われます。情報処理安全確保支援士（セキスペ）で学ぶ内容と一部被るように思います。
外部脅威をアプリケーションレイヤーでブロックするのかネットワークのレイヤーでブロックするのかなど、TCP/IP・OSI参照モデルなどネットワークに関して全体像のイメージを持っていないと、この分野はとっつきづらいのではないかと思います。僕も不安な部分がいくつかあり、SAP受験の後にセキスペの受験も見据えていたので、本棚に眠っていた『ネットワークはなぜつながるのか』を取り出して、気になる部分はしっかり理解するようにしました。
信頼性の要件を満たす戦略を策定する。
高負荷時に落ちないシステム設計としてのスケールアウト・スケールアップに関する内容や、NAT Gatewayの冗長構成について触れられていました。
SAPの勉強中に、ちょうどNAT Gatewayをリージョンレベルで利用できるようにアップデートされました。まさにホットな話題！（アップデートにより、別AZのNAT Gatewayをターゲットに指定できるようになりました。これまではAZ障害に備えて各AZにNAT Gatewayを置くのが鉄則でしたが、コスト優先で1台に集約しつつ、耐障害性を確保するという選択肢が増えました）
あとDynamoDBに関しても出題は多かったですね。DynamoD Accelerator、グローバルテーブルなど。（SAPではPK/SK、GSI/LSIといった話は全く出てきませんでした。これらはDVAやDOP向けの内容ですね）
パフォーマンス目標を満たすソリューションを設計する。
RDSのクロスリージョンリードレプリカ、DynamoDBのグローバルテーブル、EC2インスタンスのプレイスメントグループ、Route53のルーティングポリシー、Auroraのグローバルデータベース、DynamoDB Acceleratorなどなど。
SAPの勉強で難しかったのが、RTO/RPOについて、単に「目標復旧時間」「目標復旧時点」という言葉を知っているだけではダメなんですよね。「RTO/RPOが〇〇分の場合は、この構成が正解」という、具体的な時間感覚を持たないといけないです。
私なりの整理ですが、RTOが「数時間ならパイロットライト」、「数分〜数十分ならウォームスタンバイ」、「ほぼゼロならマルチサイト」という基準で選択肢を絞り込んでいました。
ソリューションの目標と目的を達成するためのコスト最適化戦略を決定する。
「このネットワーク帯域とデータ量の場合、どうやってオンプレからクラウドにデータ移行する？なるべく影響を最小限におさえながら。」みたいな問題が出てきます。
となると、「ネットワーク帯域100Mbps、1Gbps、10Gbpsってどう違う？」「データ量が1TB、10TBってどれくらいでかい？」といった感じで、ネットワーク帯域とデータ量の感覚がないと難しい気がしました。
3. 既存ソリューションの継続的な改善
全体的な運用上の優秀性を高めるための戦略を作成する。
ログ監視、運用の自動化、障害対応など。SRE的な内容といえるでしょうか。
Amazon Data FirehoseとAmazon Kinesis Data Streamsの違いは頻出でしたね。それに関連して、データストアのクエリパフォーマンス向上についても問われました。
イベント対応の自動化としては、EC2 Auto Scalingのライフサイクルフック、Amazon EventBridge、AWS Systems Managerドキュメントが出てきました。EventBridgeを使うべきタイミングと、使わなくても済むタイミングの見極めが難しく、正直なところ今もまだあまり腑に落ちていないです🤔
セキュリティを向上させるための戦略を決定する。
Systems ManagerパラメータストアとSecrets Managerの違いは、頻出of頻出でしたね。いま私が携わっているプロジェクトでも両方を使い分けているので、この問題は得点源でした。
パフォーマンスを改善するための戦略を決定する。
主要サービスにおけるパフォーマンス改善の機能が出題されます。DynamoDBならAuto Scaling、S3ならTransfer Accelerationとマルチパートアップロード、EC2ならAuto Scalingのスケールイン保護、SQSなら可視性タイムアウトとDLQ。
Auto Scalingと聞くとEC2のAuto Scalingから可用性の維持！障害耐性！と思ってしまいますが、DynamoDBのAuto Scalingはスループットの向上が目的という罠。
信頼性を向上させるための戦略を決定する。
実務でも使っているLambdaですが、SAPでは同時実行数のクォータやVPC内LambdaがプライベートサブネットのIPアドレスを枯渇させるリスクなど、大規模運用を想定した制約がよく問われましたね。
Lambdaならスケールすると単に考えるのではなく、バックエンドのRDSなどの接続数上限とのバランス（RDS Proxy）の必要性をセットで考える必要があり、実際にAmazon RDS Proxyに関する問題は頻出で、SAPでよく出題されました。
AWSに限らず、データベースには最大接続数の制限という課題がつきものですが、今回の学習を通してそのあたりの理解を深められたのは良き収穫でした。
コスト最適化の機会を特定する。
NAT Gatewayの料金が高い問題については、実務でも関係しそうな分野なので力を入れて勉強しました。転送コストを抑えるために、VPCエンドポイントを使うようにしたり、同一リージョン内のAZ間をまたぐデータ転送を避けたりなど、工夫がいりますね…。
あと、Trusted AdvisorとCompute Optimizerの違いについても出題されたので、マネコンから実際に確認して違いを理解するようにしました。
4. ワークロードの移行とモダナイゼーションの加速
移行が可能な既存のワークロードとプロセスを選択する。
オンプレからクラウドへの移行もいかにもSAPっぽい内容ですね。SAPの勉強前は移行に関する具体的なサービスは全く知らなかったので、完全に初めましての勉強でした。
これからSAPを受験する方は、Migration EvaluatorとApplication Discovery Serviceの違いは頻出なので押さえておくといいと思います。前者は「evaluate（評価）」なのでコストを見積もるために活用するもので、経営者や意思決定者向け。後者は「discovery（発見）」なのでサーバーの詳細な情報を検出するもので、技術者向けと私は覚えました。
Migration Hubは、実際に個人用AWSアカウントでマネコンを触りながら使用感を試しました。バラバラのサーバー資産を自動連携・グループ化したり、集約したデータを一つのダッシュボードで可視化したり。（なんだかマネーフォワード MEみたいだなと思いました）
VMware製品についても問題文の中でよく出てきて、最初は何これ？となりました。VMware自体は触ったことがなかったものの、macOSにUTMを入れて仮想的にWindowsやLinuxを動かしたことがあったので、その経験のおかげでイメージはつきやすかったです。
既存ワークロードの最適な移行アプローチを決定する。
オンプレからAWSに具体的にどう移行するのっていう内容です。
コンピューティングサービスやデータベースの移行は、素直に問題を解けば難しくはないのですが、ファイルサーバの移行については、私がそもそもWindowsのSMBやLinuxのNFSに関して詳しくなかったので、難しく感じましたね…。自宅サーバやNASを構築するような経験があればすんなり理解できていたのかな…。
あと、EKSの問題もちらほら出てきました。Dockerには馴染みがあるものの、Kubernetesはほとんど知らなかったので、最初は問題文（ノードやポッドなど）の意味が全く分かりませんでした。せっかくなので、個人用AWSアカウントのEKSでクラスターを実際に作成して操作感を試すなどし、簡単ではありますがEKSの基礎概要を理解するようにしました。ただ、クラスターの削除を数日間サボっていたせいで、時間課金によるコントロールプレーン代として数千円請求されました👼
既存ワークロードの新しいアーキテクチャを決定する。
AWS側でのアーキテクチャ設計の話なので、AWSの主要サービスに関して理解できていれば、ここは難しくありませんでした。
問題を解くうえでは、オーバーエンジニアリングな選択肢に注意しました。4択のうち2択まで絞り、残りの2つから「システムの要件を過不足なく満たすのはこっち。もう一方も間違ってはいないが、無駄に複雑で高性能すぎる」と判断して、1択に絞り込むイメージです。
モダナイゼーションと機能強化の機会を決定する。
サーバーレス、コンテナ、統合サービス（SQS、SNS、EventBridge、Step Functions等)に関する内容です。
SQSとLambdaを組み合わせた非同期処理の黄金パターンは、実務でも使っていたため得点源でした。白石さんの解説がとても分かりやすかったです。
SAPの問題を解くうえでは、Step Functionsをどういう時に使うべきか、逆にどういう時は向いていないのかを見極めるのが、得点を左右しそうだなと思いました。思っている以上にStep Functionsでできることが多く、SAP受験後も勉強をしたいトピックの1つです。（2025年のre:Inventでも話題に挙がっていましたが、Lambdaを介さずにStep Functionsから直接DynamoDBを操作するといったこともできますね）
おわりに
いかがだったでしょうか？
これからクラウドエンジニアとして極めたいなど明確な目標があるわけではないですが、少なくともいま目の前でAWSの仕事があり、より求められるような人間になりたいなという思いがあるので、SAPに留まらず技術の勉強と経験を引き続きしていきたいなと思います。
Discussion