自己紹介
おじクラ＠51歳（レベル2）です。
名前の由来は「おじさんがクラウドを構築してるからおじクラ」。
長年、仮想化製品のプリセールスをメインに経験し、50歳でSI現場に“異世界転生”。 マイクロサービス案件のPLを務めながら、10ヶ月でAWS認定全冠達成しました。今回は、そんな“おじクラ”がAWS Summit 2025に参加して感じたことを、何番煎じになるかわからない現地レポートを“ひねくれ目線”でお届けします！
本記事は全3回に分割して記載します。
Day 1 (6月25日)
基調講演
※指定席をゲットできたので講演を拝聴してきました。色々な方が記載しているので詳細な報告はワシからは特にないです！
ワシ：昨年よりAI推しが増えてきた。もうAIはどの分野でも避けられないところまで来とる気がする。
AWC Community Stageで釘付けになるの巻
基調講演が終わって、次のAWSセッションまで時間もあるのであちこちのブースをさまようことに。そんな折、前から気になっていたステージに足を運ぶことになる。
ーそう、AWC Community Stage
※参考情報：https://qiita.com/issy929/items/e02154bea72c4cff3106
※本記事中では登壇者・関係者の氏名には敬称を省略しております。あらかじめご了承ください。
ワシ：後でコミュニティ配布のシールをもらって帰ろう ←
AWS コミュニティプログラムと日本のユーザーグループのご紹介
-
登壇者： AWS 沼口繁
-
概要: A全国65支部・26専門支部からなる巨大ユーザーグループ「JAWS-UG」の全貌と、AWSが展開するグローバルコミュニティプログラムの実情に迫るセッション。
-
なぜこのセッションを選んだか
元々X（旧Twitter）のTLで勉強会の情報は見ていたが、まさかここまでの規模とは知らなかった。案件で技術的に詰まったときに、こうした地域・専門支部の勉強会がよりどころになると気づき、関心を持っていたところだった。 -
印象に残ったポイント
-
全国65支部、専門26支部という圧倒的ネットワーク
北海道から沖縄までの地域支部に加えて、CDK、SRE、CLI、AI/MLなどの分野別支部が存在し、2024年には年間500回以上のイベント開催。
→ 「どこかしらで毎日開催」は冗談じゃなく現実だった！ -
世界とつながるアウトプットの場
JAWS-UGの活動に加えて、AWS Community BuildersやAWS Heroesなど、世界規模の貢献制度の紹介も。
→ ワシにはまだ無縁の話だが、こういった目標が設定されているのはモチベーション向上につながるよい制度。 -
敷居の低さが魅力
「話す・書く側」に進むためのルートがしっかり整備されており、初学者支部や女子会支部など、誰でも参加しやすい雰囲気が強調されていた。
→ まずは“見る専門”から“話す・書く側”への一歩を後押ししてくれる場だと感じた。
-
-
ワシのつぶやき
ワシ：登壇資料を見てるだけだったけど、次回から当日オンラインで参加してみよう（怖そうだけどｗ）
AWS Well-Architectedなインシデントレスポンスを実装しよう
-
登壇者： AWS HERO 山口 正徳
-
概要: AWSが提供するベストプラクティスに基づき、インシデント対応を自動化・標準化するためのセッション。
-
資料: https://speakerdeck.com/kinunori/implementing-incident-response-with-aws-well-architected
-
なぜこのセッションを選んだか
ワシ自身、直近のプロジェクトでセキュリティインシデント対応の設計を担当。Lambdaで頑張って作成していたが、このセッションのテーマがまさに「欲しかった知見」だったからです。 -
印象に残ったポイント
-
封じ込め・収集を標準化するStep Functionsの威力
IAM Roleのデタッチ、ASGからの切り離し、EBSスナップショットの取得など、対応フローを自動化した「Essential Incident Response Tasks」のState Machineが紹介。GitHubで公開されており、すぐにでも取り入れられる点がありがたい。
→ https://github.com/masanoriyamaguchi/Well-Architected-incident-response-state-machine -
Step Functionsは「非開発者」に優しい
可視化しやすく、コードを書かずに処理フローを構築できるStep Functionsは、インフラエンジニアにも扱いやすいと実感。プログラマでなくても“運用可能な自動化”が組めるのは強み。 -
ドキュメントが散在していても「まとめて提示」
AWS公式の各ガイドが分散して存在しており、それが実装の障壁になっていたが、セッションでは主要な対処ポイントが俯瞰的に整理されていて、脳内のパズルがハマった気分に。
-
-
ワシのつぶやき
ワシ：頑張って作りこみしたplaybookの内容をStepfanctionに合わせて加筆修正しようかなー
（やるやる詐欺発動中）
25分で解説する「最小権限の原則」を実現するための「AWSポリシー」大全
-
登壇者： AWS HERO 波田野 裕一
-
概要: IAMポリシーを「運用設計」の観点から整理し、最小権限を設計するための本質を25分で駆け抜ける密度濃いセッション。
-
資料: https://speakerdeck.com/opelab/20250625-aws-summit-aws-policy
-
なぜこのセッションを選んだか
2024年の「20分で分かるIAM全機能」資料でIAM設計に目覚め、過去プロジェクトでも参考にしまくったワシ。その発表者本人が登壇とあれば、これは見逃せんと即決参加。
「最小権限の原則なんて設計できない」って声が多いけど、このセッションを聞いて出来ないなんて、いわせないって言葉が印象に残りました。 -
印象に残ったポイント
-
IAM認可の三要素を構造化して解説
「誰が・何を・何に」という三大要素を軸に、ホワイトリスト型（Allow中心）とブラックリスト型（Deny中心）評価の違いを視覚的に整理。
→ IAMを“設計する”立場として、このあたりの整理が曖昧だと事故の元になる。まさに案件中に使いたかった資料。 -
「認証」と「認可」は分けて考えろ
最小権限といえば認可にばかり意識が行きがちだが、認証も含めた設計が本質。
→ セッションポリシーやSCP、条件キー（Condition）の活用など、実務に即したTIPSが満載。 -
Organizations/SCP/STSなどの俯瞰図が神
IAMだけでなく、組織レベルの制御（SCP）、一時的認可（STS）、越境アクセス（クロスアカウント）までが網羅され、まさに「大全」。
→ IAMをただのJSON書きではなく“インフラの運用設計”と捉える感覚を得た。
-
-
ワシのつぶやき
ワシ：ソラでこの資料の内容が説明できるようにならないといけないなー。
AWS アーキテクチャー作図入門 2025年 Summer Ver.
-
登壇者： AWS HERO 松下 享平 (Max)
-
概要: AWS公式の作図ルールと“伝わる図解”の極意を学ぶ貴重なセッション。アイコンの使い方からネーミング、改行、さらには背景色に合わせた配色選定まで、実務に直結するディテールが満載。
-
資料: https://speakerdeck.com/ma2shita/aws-architecture-diagram-101
https://blog.soracom.com/ja-jp/2025/06/30/aws-architecture-diagram-101-in-aws-summit-japan-2025/ -
なぜこのセッションを選んだか
正直、今まで「なんとなく」でアーキテクチャ図を描いてきたワシにとって、“見よう見まね”から脱却できるきっかけを求めていた。 -
印象に残ったポイント
-
正式名称での記載と2行ルール
略称NG、改行位置NG、行数オーバーNG――そんな細かいルールがAWSの作図にはある。しかも改行は“単語の途中で折らない”のが正解。
→ 自分の過去の図を思い返して、ちょっと赤面。 -
アイコンは最新であること＆背景色とのマッチング必須
ダーク背景にライト用アイコンを使うと、それだけで“読みにくさ”が倍増。
→ 作図の信頼性は“視認性”にも支えられていると再認識。 -
作図チェックリストが神ツール
「作図の健康診断」ができるこのチェックリストは、次のプロジェクトでも即導入確定。
-
-
ワシのつぶやき
ワシ：作図に限らず設計書でもAmazon Simple Storage Service (以下Amazon S3)と記載するか
迷ったんだけど、記載しておけばよかったなあ。次からは必ず！
米国国防総省の DevSecOps ライフサイクルをAWSのセキュリティサービスとOSSで実現
-
登壇者： AWS HERO 吉江 瞬
-
概要: 米国DoD（国防総省）が定義するDevSecOpsライフサイクルをモデルに、AWSサービスとOSSを駆使して“本当に使える”セキュリティ設計を解説したハイレベルなセッション。
-
なぜこのセッションを選んだか
CI/CD基盤やセキュリティ対策の設計に関わった経験から「この内容は絶対に刺さる」と直感。過去にSASTやDAST導入で迷走した経験があり、体系的な知見が得られそうだったので参加を即決。 -
印象に残ったポイント
-
静的解析・動的解析をどう組み込むか
SASTにsemgrep、DASTにZAPやBurp Suite、さらにCI/CDパイプラインにSecurity as Codeを組み込む具体例が豊富。OPAやtrivyによるポリシー強制も実案件に即したリアリティがあった。 -
AWS Signer × GitHub Actions でコード署名
コード署名が実際のDevSecOpsにどのように組み込まれるかが示されていた点が目から鱗。アカウント間での信頼性確保やソフトウェアサプライチェーンの保護にも役立ちそう。 -
Amazon Q Developer × セキュアコーディング支援
生成AIを使って脆弱性コードを検出・改善する事例はPoCレベルを超えており、現場実装のイメージも湧きやすかった。
-
-
ワシのつぶやき
ワシ：Codepipelineを頑張って使っていたけどGithubActionの方が使いやすいって言われたのは大きかったな。次からはCodepipelineはやめよう！
Amazon ECS & AWS Fargate 運用アーキテクチャ 2025
-
登壇者： AWS HERO 新井雅也
-
概要: AWS上のコンテナ運用を実践的に解説。ロギング、トレース、監視に加えて生成AIの活用まで踏み込んだ超実務的セッション。
-
資料: https://speakerdeck.com/iselegant/amazon-ecs-and-aws-fargate-ops-architecture-2025
-
なぜこのセッションを選んだか
登壇された新井さんの著書『Amazon ECS/コンテナ設計本』には、前プロジェクト中も何度も助けられてきた。
その筆者ご本人が登壇されると知り、これは行くしかないと全力で確保。
ワシ自身、Fargate × Fluent Bitでガチ設計した経験があるので、知識のアップデートと裏話を期待して参加。 -
印象に残ったポイント
-
Fluent Bit × FireLens の構成選定は慎重に
「CloudWatch Logsだけで運用すると破産するぞ」という言葉が刺さる。
ログ転送にはFireLens構成を検討すべきだが、公式イメージがv1.9.10ベースでEOLという罠がある。
→ 運用前のバージョン確認・アップデート対応が超重要。 -
コンテナメトリクスは“Container Insights”の強化版で
CloudWatch AgentやADOTの比較を交えつつ、Enhanced Telemetryの導入による可視化レベルの向上を紹介。
「トレース＝X-Ray」一択だった認識を覆され、ADOTで拡張可能な構成のほうが実践的という示唆も。 -
生成AIをデバッグに使う“ラストワンマイル”革命
MCP Server + Claudeを組み合わせ、Terraform変更提案まで出すデモが衝撃。
本番環境への導入は慎重さが求められるが、開発フェーズでの活用は非常に有用。
生成AI＝PoC止まりの空気がある中、具体的な使いどころが提示された貴重な例。
-
-
ワシのつぶやき
ワシ：コンテナ本の改訂版を早く読みたい！
Day1の〆
気づいていたらずっとCommunity Stageで有益な話に夢中になっていたワシ。
それと同時に１年の間に随分幅広いことを未経験者の癖にやらされていたんだなあと何とも言えない気持ちになりました。
あの時の戦地から無事に生きて帰ってくれた自分に拍手を送りながら、今日得た知見を是非次のプロジェクトに活かしたいと思った。
いわゆる幕張メッセの硬いコンクリートの床にやられた為、コミュニティのシールをもらうことなく明日に備えて早々の離脱！ｗ
（Day2に続きます）
Views: 0
