AWSの全体像が2日で掴めた!初学者が「AWS JumpStart 2025 」で得たアーキテクチャ思考

この記事は 弥生 Advent Calendar 2025 の2日目の記事です。


はじめに

こんにちは!2025年に弥生に新卒入社いたしました、川上と申します。

9月にAI・データ戦略部のデータプラットフォームチームに配属され、早3ヶ月。
現在はAWSの Glue や Athena、S3 を駆使してデータ分析を行っております。

「AWSを活用できている」

そう思われるかもしれませんが、正直に白状します。


「データのことは理解が深まってきた一方で、
それ以外のAWS(インフラやアプリ)のことは、実は全体像が見えていない…

普段触っているのは「データ基盤」というAWSのほんの一部。

  • 「なぜこのサービスをここに配置するのか?」

  • 「システム全体の安定性をどう保っているのか?」

といった、設計の思想や全体像については自信を持って語れないという課題を抱えていました。

そんな私が、AWS主催の初学者向け研修「AWS JumpStart 2025」に参加。

たった2日間で、「自分の担当領域(データ)が、システム全体の中でどのように位置づけられているのか」という全体像をクリアに把握できた体験を共有します。


目次


Before:参加前の私のAWSスキルセット

現在の業務と知識のバランスは以下の通りでした。

分野 スキルセット
現在の業務 Glue, Athena, S3を使ったデータ抽出・加工(ETL)など。
課題分野 EC2、VPC、ロードバランサーなどのWebアプリ構築周りの基礎。システムの「インスタンス」や「可用性」といった概念への理解が曖昧。

つまり、データという「点」は扱えるものの、システム全体という「面」を俯瞰できていない状態でした。


AWS JumpStartで得た「3つの重要な理解」

研修は2日間。手を動かすハンズオン、チームでの設計ワークショップを通じて学びを深めました。

ここで私が得た「3つの重要な理解」を紹介します。

1. 「データが生まれる場所」の解像度が上がった

普段、私は「すでにS3にあるデータ」を扱っていますが、初日のハンズオンではその上流、つまり「ユーザーの操作からデータが生成されるまで」のシステムをチームで構築しました。

  • Webサーバーを立ち上げ、データベースを構築し、ロードバランサーでトラフィックを分散させる。

自分で構築したアプリが動いたとき、「普段扱っているデータは、このような工程を経てS3に格納されているのか」と、データ発生源(業務の上流工程)の解像度が向上しました。

2. 「可用性」のメカニズムを体感した

最も学びが深かったのが、「データベースを意図的に停止させる」実験です。稼働中のメインDB(Writer)を強制停止させました。

「これでシステムが停止する」と予想した瞬間、裏で待機していた予備DB(Reader)が瞬時にプライマリに昇格(フェイルオーバー)し、アプリケーションは稼働し続けました。

システムが自動で復旧する様子をCloudWatchのグラフで確認し、「これが可用性を担保する仕組みなのか」と、そのメカニズムを肌で感じることができました。

3. 「アーキテクチャ設計」における議論と協調の価値

2日目はチームで「ECサイトのアーキテクチャ設計」に挑みました。

議論を通して一つ大きな収穫がありました。それは「自分の専門分野がチームの貢献につながる」という実感です。

最初はアプリ側の議論に追いつくのに必死でしたが、議論が「データの分析・活用」に及んだ時、

「アプリのログやイベントデータは、EventBridge経由でGlueに流し、Athenaで分析できる構成にしましょう」

と、私が普段業務で使っている、この構成を提案することができました。

チームで2時間かけて作ったアーキテクチャ図:ELBがVPCの外にあるなど、正確ではないところもありました💦

  • アプリ担当メンバー: 「FargateやAuroraを使って、安定稼働するWebアプリを設計しよう」
  • 私(データ担当): 「その裏側で、GlueやAthenaを活用して分析基盤を構築する役割を担おう」

各自の知識が1枚の図の中で繋がり、「自分もシステム全体に貢献できている」という確かな手応えを感じました。


After:得られた変化

たった2日間でしたが、システムに対する認識は大きく変化しました。

  • 全体像の把握: 自分の担当する「データ基盤」が、AWS全体のコンテキストの中でどこに位置しているのかを明確に理解できました。
  • 対話力の向上: インフラ側の話題が出ても、基本的な用語やサービスの関係性がわかるため、チームメンバーとの建設的な会話ができるようになりました。
  • 思考習慣の変化: 単にサービスを使うだけでなく、「なぜこのサービスを選ぶのか?」というサービスの選定理由を言語化する意識が芽生えました。

実際に、この研修の後に弥生のAWSアーキテクチャ図を見ましたが、拒否感が一切なく、どうしてこの設計になっているのかという疑問が出るようになっていました。
研修を受ける前から考えると大きな進歩だと思います。


さいごに

今回の研修を通し、「GlueとAthenaの専門家」という専門性を保ちながらも、「AWSのシステム全体像を俯瞰できるエンジニア」として視野を広げることができたと感じています。

弥生には、こうして自分の専門外の領域でも「基礎から学びたい」と手を挙げれば、背中を押してくれる環境があります。

データエンジニアとして、インフラ(アプリ側)の理解は、より堅牢で価値あるデータ基盤を作るための大きな武器になります。今回の学びを活かし、チームに貢献できるよう頑張ります!

弥生では一緒に働く仲間を募集しています。
www.yayoi-kk.co.jp
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp