インフラ担当が AWS DVA を取るべきか｜迷って調べた結論

この記事を読む前に：私はDVAをまだ受験していない

まずここを確認してください。私はDVA（Developer – Associate）をまだ受験していません。

私は情シス出身のインフラ担当で、2022年にSAA（ソリューションアーキテクト アソシエイト）、2024年にSAP（ソリューションアーキテクト プロフェッショナル）を取得しました。コードはほとんど書かず、業務はネットワーク設計・アカウント設計・移行支援が中心です。CloudFormationテンプレートを読んで修正する程度はできますが、自分でコードを書いてアプリを作った経験はありません。

そんな私が、DVAを取るかどうかを1年近く迷った末に、取る方向で準備を始めました。この記事は「なぜ迷ったか」「何を考えたか」「どう判断したか」を書いたものです。DVAの合格体験記でも試験対策の解説でもありません。インフラ担当で同じように迷っている方の、判断の材料になれば十分だと思っています。

DVAの難易度や試験範囲の全体像はDVAの難易度と試験範囲に書いています。DVAの勉強法についてはDVAの勉強法・コードが書けない人が最初にやることに別途まとめました。

---

なぜSAPを取った後に迷ったか

SAPを取った後、次に何を取るかを考えたとき、候補として名前が上がったのがDVAとSOAでした。どちらを先に取るべきか、あるいはそもそも取る必要があるのかを、数か月単位で考えていました。

SOAを先に取ろうと思っていた時期

SAPを取った後、最初はSOA（SysOps Administrator – Associate）を検討していました。SAPの勉強中に「運用まわりの知識が薄い」と感じた場面があったので、その補強としてSOAに進むのが自然だと思っていたからです。

SAPでは、CloudWatchのメトリクスやシステムズマネージャー、イベント通知のフローなど、「運用寄りの常識」として出てくる設問がありました。そのあたりをSOAで体系的に学んでおけばよかったと感じた場面が試験中に何度かあり、SAPを取った直後は「次はSOAで運用を補強する」という方針を持っていました。

SOAの試験ガイドも一度ざっと確認しました。内容は自分の業務とかなり近い部分が多く、「これなら既存の知識を使いながら勉強できる」という感触がありました。モニタリング、セキュリティ対応、コスト管理、自動化といった項目は、日常の業務で触れている概念と重なっていたのです。

DVAが視野に入ったきっかけ

転換点は、担当している移行案件でアプリ担当との連携が急に増えてきたことです。オンプレから移行するシステムに、Lambda・API Gateway・DynamoDBを組み合わせたサーバーレスの処理が含まれていたのです。設計会議でアプリ担当が話す内容が、インフラ担当の自分には細部がよくわからない状態が続きました。

一番印象に残っているのは、ある設計会議でアプリ担当から「DynamoDBのGSIをもう一つ追加したい」という話が出たときです。私はGSI（グローバルセカンダリインデックス）が何かはSAAで覚えていましたが、なぜ今その判断が必要なのか、追加することでコストやパフォーマンスにどういう影響があるのかを、その場で説明できませんでした。

「DynamoDBのGSIを追加する手順」はインフラ担当として調べればわかります。でも「アプリ側がなぜGSIを使いたいのか」「その判断が設計として適切かどうか」を理解して会話に参加するには、アプリ開発の観点からDynamoDBを理解する必要があると感じました。

同じような場面がその後も続きました。LambdaとSQSの組み合わせでエラーハンドリングをどうするかという話のとき、アプリ担当が「DLQを使いたい」と言いました。DLQ（デッドレターキュー）の存在は知っていましたが、Lambda関数の何が失敗したときにDLQに入るのか、Visibility Timeoutとの関係はどうなのかを答えられませんでした。こういった場面が数回積み重なって、「DVAを先に取った方が今の業務に合っているかもしれない」という判断に傾いていきました。

---

DVAを取る理由として考えたこと

迷いながらも、DVAを取る方向に傾けた理由をまとめます。一つひとつの理由の重さは、業務の状況によって変わります。

理由1：アプリ側の言葉がわかると設計の会話が変わる

インフラ担当がSAAとSAPを取っても、アプリ側の設計判断の根拠を説明されたときにわからないことがあります。特に、LambdaやDynamoDBのような、アプリ開発者が日常的に使うサービスの「開発者的な使い方」は、インフラ担当には見えにくい部分があります。

DVAの試験範囲には、Lambda関数のメモリとタイムアウトの設定判断、API Gatewayのレスポンスキャッシュと認証フロー、DynamoDBのクエリ設計とインデックス戦略、Elastic BeanstalkやCodeシリーズを使ったデプロイフローなど、アプリ担当が「当たり前」として扱う知識が体系的に含まれています。これを一度勉強しておくと、会議での会話の解像度が上がる可能性があります。

具体的には、「なぜLambdaのタイムアウトを3秒に設定しているのか」「DynamoDBのホットパーティション問題がなぜ起きるのか」「API Gatewayのステージ変数とは何か」「SQSのVisibility Timeoutをどう設定するべきか」といった問いに対して、自分なりに仮説を持ちながら会議に参加できるようになることを期待しています。インフラ側への影響を判断した上で意見を言える立場になる、というのが理想のイメージです。

理由2：移行案件でアプリ担当と話す機会が増えた

もともと私の業務はインフラ寄りでしたが、移行案件のスコープが広がるにつれて、アプリ担当との接点が増えました。オンプレで動いていたバッチ処理をLambdaに載せ替える際の設計検討、API Gatewayを挟んだ認証フローの整理など、インフラとアプリの境界線が曖昧な場面が増えています。

こういう状況では、「自分はインフラ担当だからアプリのことはわからない」という立場を続けるよりも、アプリ側の基本的な知識を持って会話に参加できるほうが、案件全体の進行がスムーズになると感じています。

ただし、この「接点が増えた」という状況は私の場合の話です。インフラ担当でもアプリとの接点がほとんどない業務の場合、状況は変わります。自分の業務の実態を確認した上で判断することが大切です。

理由3：SAAとSAPで培った基礎知識がDVAにも使える

DVAはアプリ開発者向けの試験ですが、インフラ担当がSAAやSAPで学んだ知識と重なる部分があります。IAMのポリシー構造・ロールの考え方、VPCのネットワーク設計、CloudWatchのメトリクスとアラーム設定などは、DVAにも出題されるエリアです。

SAAを取っていれば、DVAの基礎部分は既知の知識として扱えます。ゼロから勉強するよりも、積み上げられる知識がある状態でのスタートになります。DVAの試験範囲の詳細を確認したところ、SAAで学んだサービスが前提知識として出てくる設問も多くあり、その部分は新たに覚える量が少なく済みます。インフラ担当にとっての「得意領域」がDVAにも存在している、という点は取りやすい理由の一つです。

理由4：「インフラとアプリの両方を話せる」立場の実用性

純粋なインフラ担当だけでなく、アプリ側の設計も理解できる立場の人は、チームの中では数が少ない傾向があります。両方を話せると、仕様の整理や設計検討の場で声がかかりやすくなります。

これが転職に直結するわけではありませんが、今いるチームでの動きやすさには影響すると感じています。転職での資格の評価についてはAWS資格は転職でどう評価されるかに書きましたが、DVA単体よりも「SAAとSAPとDVAを持っている、インフラとアプリの両方を一通り理解できる人材」という説明のほうが、転職の文脈でも使いやすいと考えています。職務経歴書への書き方はAWS資格の職務経歴書への書き方を参考にしてください。

---

DVAを取らない理由として考えたこと

取る理由と同じくらい、取らない理由も真剣に考えました。思考の過程を省かずに書きます。

取らない理由1：業務で使わない領域に時間をかけるのが妥当か

DVAの勉強時間として、私は100〜200時間を見ています。SAAが120時間、SAPが200時間だったので、コードの補強を含めた場合に100〜200時間というのは現実的な見込みだと思っています。ただし実際に受験していないので、この見込みが正確かどうかはわかりません。

インフラ担当がDVAを取っても、日常業務でDVAの知識を使う機会が限られるなら、勉強した内容は定着しにくいです。AWS認定の有効期限は3年（有効期限と再認定参照）なので、取った後に使わない知識は3年以内に薄れていきます。更新するためにまた時間をかけることになるかもしれません。

「勉強したこと＝使える知識」にならないケースは、どの試験でも起きます。SAPを取った後も、試験勉強で覚えた一部の知識は業務で使う機会がなく、半年後には細部を忘れていた経験があります。使わない領域の資格を維持するコストは、取得した時点よりも3年後のほうが大きくなります。

取らない理由2：SAPの知識を定着させる時間に使った方が良い

SAPを取った後は、取得した知識を業務で実際に使いこなしていく段階があります。SAPで覚えたOrganizations・SCPを使ったガバナンス設計、マルチアカウント構成のベストプラクティス、移行戦略の選定基準など、試験では覚えたけれど業務でまだ使いきれていない知識があります。

次の試験に急ぐより、今持っている知識を業務で使い倒す時間を取ることも、長期的なキャリアには意味があります。SAPの難易度と勉強量についてはSAPの難易度に書きましたが、取得後も知識を業務で使い続けないと薄れていきます。

取らない理由3：SOAの方が業務に直結する可能性

SAPで感じた「運用まわりの知識が薄い」という課題は、SOAで解決できる可能性があります。インフラ担当なら、アプリ開発寄りのDVAよりも運用寄りのSOAのほうが、知識の定着率が高いかもしれません。

SOAの試験範囲には、モニタリング・ロギング・自動化・セキュリティ対応・高可用性構成など、インフラ担当が日常的に扱うテーマが多く含まれています。業務で使いながら定着させやすいという意味では、DVAよりSOAの方が適しているケースがあります。

取らない理由4：コードを書く経験がない状態での学習効率

DVAはLambdaのコード実装やSDKの使い方など、実際にコードを書いた経験があると理解が深まる分野があります。コードをほとんど書かないインフラ担当の場合、実際に動かして確認できない分、頭で理解するだけになる場面が増えます。テキストや問題集で「こういうコードになる」と学んでも、自分でコードを書いて確認できる人と比べると、実感を持って覚えにくい部分があります。これは覚悟が必要なコストです。

---

私の判断：取る方向で準備を始めた理由

迷った末に、私はDVAを取る方向で準備を始めました。

決め手は「業務での接点の実態」

SOAではなくDVAを選んだ理由は、現在の担当案件でアプリ担当との会話が具体的に増えていたからです。設計会議でついていけない場面が複数回あり、「これは試験を取る前に、知識として入れる必要がある」と感じたことが直接のきっかけです。

業務上の必要性がないまま「いつか役立つかもしれない」という理由だけでDVAを取ろうとしていたなら、もう少し悩んでいたと思います。「業務で実際にそういう場面がある」という事実が、判断を後押しした一番の要因です。

「取ったあとに何をするか」を先に書いた

申込みを決める前に、メモに「DVAを取ったら何をするか」を3行書きました。「Lambda・API Gatewayを使った移行の設計検討で、アプリ担当の判断に根拠を持って意見できるようになる。設計会議で受け身ではなく自分から意見を言える場面を作る。GSIの設計判断やDLQの設定理由を自分で説明できるようになる」と書きました。

この3行が書けたことで、取る理由が「ぼんやりしたスキルアップ」ではなく「具体的な業務の改善」になりました。SAAのときも、SAPのときも同じやり方をしていましたが、自分には合っていると思っています。資格の意味について考えたい方はAWS資格の独学と意味も読んでみてください。

SOAの位置づけ

DVAを選んだからといって、SOAをやめたわけではありません。DVAの次にSOAを取る候補として残しています。今の業務状況ではDVAを先にする意味があると判断しましたが、状況が変わればSOAが先になる可能性もあります。

資格の取り方の考え方全般についてはAWS認定の選び方と順番にも整理しています。

---

DVAを取ることで変わること・変わらないこと

DVAを取ると決めたとはいえ、過度な期待は禁物だと思っています。取ることで変わることと、取っても変わらないことを整理しておきます。

変わると思っていること

まず、アプリ担当との会話に「根拠のある仮説」を持って参加できるようになると思っています。今は「DLQが必要だと言っているけど自分にはよくわからない」という受け身の状態ですが、DVAを勉強した後なら「DLQを使う場合、LambdaのリトライはMaximumRetryAttemptsでコントロールできるから、そこを3回に設定した上でDLQにメッセージが入る設計にしている、ということかな」と自分なりに解釈を持てるようになると期待しています。

次に、アプリ担当に確認するときの質問の精度が上がると思っています。今は「それはどういう意味ですか？」という漠然とした質問になりがちですが、「このタイムアウトはLambda関数側の設定ですか、API Gateway側の設定ですか？」というように、論点を絞った聞き方ができるようになるはずです。

変わらないと思っていること

DVAを取っても、私はアプリ担当にはなりません。自分でコードを書いてLambda関数を実装する機会が増えるわけでもないと思います。あくまでも「インフラ担当が、アプリ側の設計を会話できる程度に理解する」という範囲での変化です。

DVAを取ったことで「自分にもアプリ側の業務が回ってくる」ことを期待しすぎると、実際の業務とのギャップに戸惑うかもしれません。資格は「知識を持っていること」の証明であって、「業務を変える」ものではないという点は、SAAもSAPも取った上で感じていることです。

---

迷っているインフラ担当に伝えたい判断軸

取るかどうか迷っている方向けに、私が整理した判断軸をまとめます。どれか一つだけで決まるものではなく、複数の軸を重ねて考えることで判断がしやすくなると思っています。

判断軸1：アプリ担当との会話で詰まる場面があるか

「詰まる」とは、相手が何を話しているかはわかるけど、自分の側から意見が言えない状態のことです。アプリ担当から設計の選択肢を提示されたときに、インフラ側への影響を判断できない状態が繰り返されているなら、DVAを取る意味があります。

逆に、アプリ担当との接点がほとんどなく、日常の業務でLambdaやDynamoDBの話が出ない環境なら、SOAや他の方向性の方が優先度が高いかもしれません。業務の実態を先に確認することが、判断の出発点です。

判断軸2：3年後もアプリ側との接点がある業務にいるか

AWS認定の有効期限は3年です。取った知識を業務で使えている状態なら更新コストは低いですが、使わないままだと更新の際に一から学び直しになります。

3年後もアプリ担当との連携が続く業務にいる見通しがあるなら、DVAを取っておく意味があります。有効期限の考え方についてはAWS認定の有効期限と再認定で書きました。

判断軸3：勉強時間のコストを他の選択肢と比べる

DVAに100〜200時間かけるなら、その時間で何ができるかを考えます。試験の勉強は知識を体系的に身につけるルートの一つですが、業務で実際にLambdaを触って手を動かすことも別の学びになります。

試験勉強のコスト感についてはSAAの難易度と勉強時間も参考になります。SAAとDVAの比較で、どちらに先に時間をかけるかを決める材料にしてください。

判断軸4：受験料と会社の補助制度を確認する

受験料はAssociateで150 USD（2026年8月1日時点・公式サイト確認）です。会社に補助制度がある場合、年間の補助回数に上限があることもあります。DVAとSOAのどちらに補助を使うかも含めて先に確認しておくのがよいと思います。受験料の詳細はAWS認定の受験料まとめにまとめています。

補助制度の有無や上限を確認した上で、使い所を考えることで、勉強に投じるエネルギーの優先順位も変わってきます。

判断軸5：自分がどのキャリア方向に進みたいかを先に確認する

DVAを取るかSOAを取るかの判断は、「今の業務で役立つか」だけでなく「3〜5年後にどういう人材でありたいか」という観点からも見ておくと、判断がしやすくなります。

インフラ寄りのスペシャリストとして深めていくなら、SOAやSAPの深掘り、さらにはNetworkingやSecurityのSpecialtyへ進む道があります。一方でインフラとアプリの両方を俯瞰できる人材を目指すなら、DVAを取っておくことで「両方を話せる」立場の幅が広がります。どちらの方向性も正解で、自分の状況と好みで決めることです。転職の文脈でどちらが有利かは個人差があります。AWS資格と転職の評価にも参考になる内容を書いているので確認してみてください。

---

まとめ

DVAの具体的な勉強法はDVAの勉強法・コードが書けない人が最初にやることにまとめています。試験の申込み手順はSAAの申込み手順と受験の流れが参考になります（DVAも手順は基本的に同じです）。

合否や業務への影響には個人差があります。この記事は私が迷って判断した過程をそのまま書いたもので、誰にでも当てはまる正解として書いたわけではありません。