月曜日, 7月 7, 2025
月曜日, 7月 7, 2025
- Advertisment -
ホームニューステックニュース【51歳ぼっち】51歳のおじさんが実際にAWS Summit 2025に参加して楽しめたか実体験してみた件 Day2 #イベントレポート - Qiita

【51歳ぼっち】51歳のおじさんが実際にAWS Summit 2025に参加して楽しめたか実体験してみた件 Day2 #イベントレポート – Qiita



【51歳ぼっち】51歳のおじさんが実際にAWS Summit 2025に参加して楽しめたか実体験してみた件 Day2 #イベントレポート - Qiita

タイトルなし.png

こちらの記事が100いいね頂きました。読んで頂きありがとうございました!
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
【51歳転生】AWS未経験/パート勤務/SI復帰15年ぶりおじさん──マイクロサービスのPLをやりながら10ヶ月でAWS全冠を取得。そしてAWSからスカウトされるまで(https://qiita.com/ossacloud_aws/items/a98987db5ba28d6b8920)

自己紹介

おじクラ@51歳(レベル2)です。
名前の由来は「おじさんがクラウドを構築してるからおじクラ」。
長年、仮想化製品のプリセールスをメインに経験し、50歳でSI現場に“異世界転生”。 マイクロサービス案件のPLを務めながら、10ヶ月でAWS認定全冠達成しました。今回は、そんな“おじクラ”がAWS Summit 2025に参加して感じたことを、少し何番煎じになるかわからない現地レポートを“ひねくれ目線”でお届けします!

本記事は全3回に分割して記載します。

Day 2 (6月26日)

基調講演
※この日は午前中所用が入ってしまったため午後から参加。おそらくこの日の基調講演も色々な方が記載しているのでおじクラからは特にないです!
この日は展示ブースを多めに見て回ることに。聞きたいセッションも気になりつつ、やっぱり時間が足らないことを痛感w

※本記事中では登壇者・関係者の氏名には敬称を省略しております。あらかじめご了承ください。

社内コミュニティによる企業文化創り~MAWS-UGの挑戦とこれから~

  • 登壇者: AWS Community Builder 小川 雄喜

  • 概要: 三菱電機グループ内で立ち上がったAWSユーザーグループ「MAWS-UG」の挑戦を通じて、単なる情報共有から“企業文化”へと進化していくプロセスが語られた熱量の高いセッション

  • 資料: https://speakerdeck.com/yukiogawa/aws-summit-japan-2025-she-nei-komiyuniteiniyoruqi-ye-wen-hua-chuang-ri-maws-ugnotiao-zhan-tokorekara

  • なぜこのセッションを選んだか
    ワシもかつてプロジェクトの中で技術TipsをShareしていたが、誰にも刺さらず空振り続き…。だからこそ、「情報提供先が合っていないのでは?」という悩みに激しく共感した。ワシの場合は全体ではなく刺さる個人にフォーカスを充てて改善したが、他にアプローチがあるかなという答えが知りたくて参加

  • 印象に残ったポイント

    • Viva Engageでの発信と仲間探し
      社内SNSに地道に投稿し続けるも最初は反応が薄く、「何かが足りない」と悩み続けた末に辿り着いたのが“仲間”の存在。AWSイベントや社内外の勉強会を通じて、熱意ある仲間が自然と集まり始め、そこから一気にコミュニティとして加速した流れが印象的だった。

    • MAWS-UGの成長と成果
      立ち上げからわずか1年強で510人超えのメンバーを抱えるまでに拡大し、社内限定イベントやLT、外部登壇まで展開。特に、AWS認定取得数が右肩上がりで増加し、コミュニティを通じて職場全体のスキル・モチベーション・エンゲージメントが上がったという事実に唸った。

    • 社内コミュニティは“第三の居場所”
      職場業務(成果コミット)と社外コミュニティ(自由なアウトプット)の“いいとこ取り”ができる場所として社内コミュニティを再定義。これは新しい価値観であり、エンジニアが安心してアウトプットできる貴重な土壌になると確信した。

  • ワシのつぶやき

ワシ:無反応でも半年ぐらいは発信し続けることは非常に大事かな、と。巻き込み力は鍛えよう。

15分で分かる Terraform で実現する AWS 自動化

  • 登壇者: 加藤将宏(HashiCorp Japan)

  • 概要: HCP Terraformの紹介をしつつ自動化の概要にふれるセッション

  • なぜこのセッションを選んだか
    Terraformのセッションって、正直「お作法説明」で終わりがちだけど、この15分は違った。
    自動化の現場に刺さる“実践”の詰め合わせ。15分で叩き込まれたのは、IaCの技術そのものというより「どう使えば仕事がラクになるか」って視点だった。ワシ自身、TerraformはS3バックエンド+ローカルCLI運用が中心で、HCP Terraformは名前だけ知ってる状態。Sentinel?プライベートモジュール?ああ、便利そうだけどどうせ有料やろ、でスルーしてた。

  • 印象に残ったポイント

    • Infrastructure as Codeの本質、再確認
      コード化すれば、構成ミスのやり直しがいらない。
      「EC2起動したけど、IAMロール指定忘れてた」──あるある過ぎるやつ。
      Terraformならテンプレ化→再利用→レビュー可能。属人化を潰す構成。

    • HCP Terraformでチーム利用が一気に現実的に
      マルチテナント設計とRBAC(認可制御)が“最初からある”。
      Web UIから操作、モジュール共有もできる。CLIだけの世界から脱却できる。

    • コスト最適化のリアル
      高スペックEC2の“削除し忘れ”問題に対して、Ephemeralワークスペース+ガードレールで一発解決。
      → 一時環境をコードで生成・削除できるのはデカい。時間=コスト。

    • セキュリティベストプラクティスも自動化
      SentinelでS3やCloudWatchの構成ミスを“事前”に検知。
      「後から怒られるセキュリティ事故」を潰せる構成に。

    • アカウント払い出しまで自動化
      AWS Organizations+Terraformで、研修・検証用のアカウントをスピンアップ&クリーンアップ。
      → トレーニング環境の構築が「依頼不要」になるのは、運用チームにとって神。

  • ワシのつぶやき

ワシ:コードは「読まれるもの」前提。ゴールデンテンプレート化で設計の質を底上げしたい。次回のPJでは、
HCP Terraform有料プランを前提に、運用設計から逆算したIaC構成を検討したいなあ。このセッション、技術と
いうより「仕組みでどれだけ運用負荷を減らせるか」という話だった。

ドワンゴに学ぶ、現実を突きつけられたときのセキュリティ対応のリアル

  • 登壇者: 岡田 直之さん(ドワンゴ)
  • 概要: クラウド移行=ゴールではなかった──。
    むしろ“セキュリティ再設計のスタート地点”だったことを、ドワンゴの事例から学ばされたセッション。
  • 資料: https://aws.amazon.com/jp/blogs/news/overview-niconico-security-governance-on-aws/
  • なぜこのセッションを選んだか
    今回の事例セッションの一番の目玉じゃないかな。
    事前予約が取れなくてワシも当日席で1時間前から並んだけど、開場時間ちかくにはかなりの人数が当日待ちで殺到していたと思う。あのニコニコ乗っ取り騒動を当事者がどんな目で見て、どんな行動をとったのか。その全貌を、AWS全面移行の最中に起きた「まさかの一撃」として、“何もわからない状況で何ができるのか”という極限下の意思決定のリアルが詰まっていました。
  • 印象に残ったポイント

    • 出来そうで出来ない初動対応
      特に印象深かったのは、「攻撃なのかどうかすらわからない」という状態でまずネットワークを遮断した初動対応。オンプレとAWSを接続していたDirect Connectも、インターネット越しの通信もすべて即時に遮断。あとから「やりすぎだったか?」という葛藤ではなく、「まず守る」判断を徹底できる胆力。これは教科書じゃなく、現場でしか磨かれないものだと思いました。さらに、IAMやSSHキーなど**すべての認証情報を即座に無効化して“AWS環境を人が触れないレベルまで隔離”**した対応。自分が同じ立場だったらここまで踏み込めるのか?と考えさせられます。

    • 多層防御の再構築:予防と検知のダブル構成
      そしてCloudTrailやAthenaでのログ解析、GuardDutyとDetectiveの活用、EventBridgeでのアラート統合。AWSのセキュリティスタックをフル活用して“異常をあぶり出す”仕組みを日頃から整えていたからこそ、攻撃を受けても動けた。これは「ツールの導入」ではなく「文化の構築」ができていた証拠でしょう。

    • セキュリティの統一ではなく適応という考え方
      印象的だったのは、「マルチアカウント構成において、各チームが自律的に選択したAWSサービスに応じたセキュリティガイドラインを提供する」という姿勢。“統一”ではなく“適応”することで、全体最適を狙うアーキテクチャと組織設計のバランス感覚が素晴らしいと感じました。設計側としては「統一」させたいところを、それぞれのチームのポリシーを包括したところに凄みを感じた。

    • AWSのSecurity Incident Responseの導入
      さらっと触れていたけど昨年のre:Invent 2024 で発表されたこのサービスを導入済みなのでがびっくりした。そういう意味では利用できるサービスは全て利用するという決意表明に似たものを感じた。

  • ワシのつぶやき
ワシ:最も大切なのは「人と技術を組み合わせた体制構築」。AWSだけでは守れない部分をどう設計するかが肝。
何気なく触れている初動対応ができたことがただただすごい!

Day2の〆

昨日はCommunity Stageに夢中になってしまったので(これ自体は悪いことではない)、展示ブースを見に出かけたり、バランスよくセッションを見て回りました。
帰りの混雑も気になったので早めに撤退。計画が甘かった割には発見が多かったAWS Summitじゃった。
帰り道盛り上がってる集団をみて羨ましいとか思ったのは内緒じゃ!

(Day3に続きます)





Source link

Views: 0

RELATED ARTICLES

返事を書く

あなたのコメントを入力してください。
ここにあなたの名前を入力してください

- Advertisment -