JAWS DAYS 2025に行ってきました。
定員オーバーに諦めかけていたところ増員に伴い参加可能に！
イベントの概要
JAWS-UG（AWS User Group – Japan）は、日本全国に60以上の支部を持つ Amazon Web Services（以下AWS）のユーザーグループです。全国の各支部では、AWSに関する技術交流や人材交流が毎週のように行われ、AWSユーザーの技術力向上およびビジネスの拡大に寄与しています。
JAWS DAYSは主催JAWS-UG、後援アマゾン ウェブ サービス ジャパン合同会社で行われるJAWS-UG最大のイベントです。全国のJAWS-UGメンバーが中心となってイベントの企画、準備を行い、最新技術からビジネス、ライフスタイルなどAWSに関わる幅広いテーマでセッションが予定されています。
AWS初心者から上級者までのエンジニア、経営者や人事、マーケティング、エンタープライズからスタートアップ、中小企業など職種や業態・会社規模を問わず、たくさんの方に参加いただけるイベントです。
引用：
イベント参加の背景
持ち帰るところの多かったセッションメモ
気になるセッションが多すぎて朝１から所用により昼過ぎまで。
- Next-Generation Software Development
・Jeff Barrさん
チーフエバンジェリストとしてAWSで構築しているものを紹介している。
初回2010年JAWS-UGミーティングにも参加。
ニュースブログ、ソーシャルメディアなどを通してオーディエンスに説明している。
・白幡さん
今のAWSジャパンを作っているのはビルダーだと思っている。
多くのビルダーがコミュニティに参加し、コミュニケーションを通じて、作り上げている。
その１つの象徴としてJAWSがある。
ビルディングブロックから始まっている。お客様が求めるものをブロックを積み上げて構築していく。
生成AIのようなソリューションのためにブロックを積み上げるのもビルダー。
今までお客様と一緒にIoTをやってきた。
お客様と一緒に問題解決をすることを志向している。
問題解決のためのアイデアをブロックとともに組み立てたい。
・Jeff Barrさん
キャリアを通じて様々な役割でテクノロジーに触れた。
プログラマーとして、各時代のHW、SWに触れてきた。
テクノロジーは時代によって変わり新しいものが生まれていく。
それは開発に使えて、未来を示すものである。
過去に敬意を払い、未来に対してオープンであることが大事だと思っている。
新しいものに触れると、ビジネス上でも求められた時に活用できる。
AIに対して開発者には不透明さに対する恐れがあることを感じている。
ただ、新しいものではないことを知って欲しい。
人間がまだツールに対するコントロール権を持っている。
人がソフトウェア開発者になるにはより多くの背景・スキルを持つ。
非正式な開発者は自己学習的。科学的な背景で体系的な学習を行った人。
テクノロジーを開発するに当たり各ステップにフォーカスを当てる。
ヴァーチャスサイクル。HW領域においては、開発者が強いプロセッサーを作れば開発の時間がより短くなる。
このサイクルが近年より早くなってきている。
似たことがソフトウェア開発の領域でも起こっている。
開発したソフトウェアを使ってソフトウェアを開発する、ということがある。
AIを使った開発も同じ文脈に乗っている。
AIの台頭はディベロッパーの役割を奪うのではなく、強くするためにある。
私たちディベロッパーのそもそもの仕事とは、要件を満たすコードを生成すること。
プログラムが、正しく、速く、保守拡張可能、優良であること。
ツールが重要なのは、巨人の肩に乗ること。
ツールは何層にも重なることが起きる。交流、重ね、コンピューターをうまく使えるようになる。
ツールディベロッパーの課題は生産性。
過去振り返って、役に立つツールが多くあった。
過去のツールの成長のステップは、そのステップにAIが含まれることが分かる。
人間は課題があったらツールを作って解決を考えてきた。
AIに対してもリスペクトを払い便利なものとして利用する必要がある。
AIにはまだディベロッパーからのインプットが必要。
どこに向かうか。
継続して学び続けること。
AI駆動型コードアシスタントを試してみる。
自動推論・検証などの理解を深め、実践につなげていく。 - IAMのマニアックな話 2025 IAMのベストプラクティスは5年間でどう変わったのか？
2019年に技術同人誌としてIAMを纏めた。
6年間でベストプラクティスが変わってきている。
重要な機能だが、シンプルに作られている。
当時。ポリシー、IAMグループのデザインパターン等書いていた。
IAMユーザの最小化、最小権限設定、MFA強制適用、Rootアカウントの厳格管理、IPアドレス制限。
最小権限のジレンマ、Admin持っている人しか最小権限の追求ができない。
ユーザ管理の煩雑さ＆マルチアカウントへの対応困難。IdP+SSO。
今。
IAM Access Analyzer。ポリシー分析＆生成。使いやすさに課題。AIとの組み合わせに期待。
属性ベースのアクセス制御（ABAC）。ポリシー管理の動的反映の希求から。設計負荷高いのが課題。
リソースコントロールポリシー。リソースごとの設定が可能。
AWS Verified Access。リクエストを評価してポリシーベースのアクセス制御が可能。
これからのベストプラクティス。
運用方針：IAM Identify Centerを活用し、IAMユーザーをゼロに。
ポリシーの設計変化：動的制御、組織制御で最適化。
監査強化：リアルタイム監査＋AI提案。
ゼロトラスト対応：動的認証制御、デバイスベース、AIとの組み合わせによる高度な認証制御。
アカウント単位から全体最適に。
40分バージョンも。
詳細は技術書典18に。 - 開発組織を進化させる！AWSで実践するチームトポロジー
疎結合なシステムを作るために組織を疎結合にするために、逆コンウェイにする。
そのために４つのチームから作り上げる。
ストリームアラインドチームを主軸に、支援役の３つのチームがある。
チーム同士は３つのかかわり方をする。
動的に組織を進化させる。状況に応じて支援チームのかかわり方が変わる。
AWSユーザーの実践。
想定される課題。
・１つのチームで開発サイクルを回せない：ストリームアラインドチーム
・新技術を学習する余裕がない：イネイブリングチーム
・環境構築・運用：プラットフォームチーム、提供サービス利用
・複雑な技術にとりかかれない：コンプリケイテッドサブシステムチーム、外部サービス
実例。
・１つのチームで開発サイクルを回せない→運用をDEVに委譲
・新技術を学習する余裕がない：OPSチームで調査・DEVへの委譲
・環境構築・運用、複雑な技術：OPSチームで検討・提案、DEVに委譲
実積し、開発組織を進化させる。 - あなたが人生で成功するための5つの普遍的法則
社会から受け取る報酬から成功をする。成功は科学できる。
・パフォーマンスが成功を促す。
・パフォーマンスには上限あるが、成功には上限が無い。
・過去の成功×適応度=未来の成功
コミュニティでの研鑽・貢献が成功に紐づく。
AWSスキルを軸にしたITエンジニア転職サービスを開始。
メンタリングを行う。スキルアップできるコミュニティを作る。 - 三度の飯よりCognito
つらみの供養。
・属性設計
カスタム属性を考えずに作ると修正削除できない。やり直すためには作り直しが必要。
・必須属性の選択
ユーザー登録時の必須。後からの修正不可。
Lambdaトリガーで対策はできるが、管理方法の考慮が必要。
・ミュータブルパラメータ
Falseにするとフェデレーションサインインが失敗する。
CloudFormationではデフォルトfalse。
・ALBの癒着
CognitoにWAFかけるとALBからの認証リクエストでNGとなる
CockieのSameSite属性がNone固定。Cognito+CloudFrontは設定可能。
・認証記録
CloudTrailにユーザーIDベースで出力。
・API分かりづらい
/logoutでもクッキー削除のみ。JWT消えない。
設計ミスが致命的になりやすい。運用設計難しい。扱いづらい。
改善アップデートも多く、AWSで認証認可を考えると、通る道。
- 会社と若手を強くするコミュニティの活用法
・個人の学び
社内の業務だけでは70%分しか成長できない。
社外のコミュニティから学ぶことが多くある。
・組織の成長
学習する人の方が労働に対する幸福度が高い。
社外学習を行う人の方が労働生産性高い。
コミュニティからの学習を組織に還元できる。
参加、インプット強化、知識の平準化、アウトプット。結果組織が強化される。
インプット：アウトプットの比率は３：７が良い。
アウトプットに対するフィードバックのサイクルを作れると、
それに対するアクションを通すことで、より知識が深まる。
業務に反映されると可視化される。周囲に対する影響も発生する。 - AWSではじめるWeb APIテスト実践ガイド：品質とセキュリティを支えるためのポイント
WEB API実践ガイド。
インテグレーション層を指す。
APIに対するセキュリティテストはまだ実施割合が低い状況。
・機能テスト
コントラクトテスト：API提供者・利用者間の合意同意に動くことのテスト
コントラクトの不一致によるAPIドリフト問題がある。
冪等性、バージョンごとの独立性・互換性を守る。
正常系と同様に異常系のテストが大事。ネガティブテストもしっかりやる。
セキュリティ。OWASP API Security TOP10を気にする。
認証・認可設定。OWASP10の内3件認可周り。
過剰なデータ漏洩。HTTPヘッダのセキュリティ設定は先人の知恵。
パフォーマンス。高負荷・長時間処理時の確認。
パフォーマンスも重要なユーザー体験。
レイテンシ、スループット、エラーレート、システムリソース使用状況を見る。
スケーラビリティの確認をする。
WEB APIには様々なアーキテクチャスタイルがある。
プロトコルによって使い分ける。
HTTPにはバージョンがあり、通信内容によって変わる。HTTP2が現状メジャー。
AWSサービスを利用したAPIにも、利用サービスによるバリデーションがある。
API Gatewayではバリデーションチェックが可能。
OpenAPIでAPIスキーマを一元管理するメリットが多くある。
API GatewayでのINP/EXP可能。但し、標準のままだと関連サービス（Lamdba）の関連付けがされないので注意。 - Platform Engineeringでクラウドの「楽しくない」を解消しよう
AWS学習の負荷高い。
適度な学習負荷なら好奇心が勝って楽しいが、高まり過ぎると辛くなる。
コンテキストスイッチ多すぎるとつらい。
注力したいタイミングで嵌りたくない。
面倒くさい＝認知負荷。結果、開発生産性が下がっている。
分業で解消する。但し、開発と運用での溝が生まれる。
DevOpsで解消に向けていた。ただ、デプロイによってシステム障害が生まれる。
また、異なる役割で人が分かれていると、フィードバックに時間がかかる。
コードを書いた人がその責任を負う。書いた人が直すと早い。
フルサイクルディベロッパー。フルサービスオーナーシップ。
開発者が利用者に近づくことで、直接的なフィードバックループが生まれ、アジリティが上がる。
結果、分業をどうするか。
フルサイクルを実現しつつ、分業をどうするかを考える。
チームトポロジーが重要となる。
分業のためにチームとインタラクションの方法について整理する。
AWSの文脈において、その道のプロはPlatformTeam。
それを体系立てて作り上げていくのが、PlatformEngineering。
開発者体験と生産性を向上させるために環境を整える。
PlatformEngineeringを成功させることは、プラットフォームを忘れること。
面倒くさいを、楽しい、に変えるのがプラットフォームエンジニアリング。
ファシリテーション：勉強会、テンプレ・サンプル提供、ゴールデンパス実現
コラボレーション：ストリームアラインドチームと一緒にやることで無駄を作らない
XaaS：スケールするためにコラボは距離感を大事にし一時的にする。1:nのためにXaaSする
プラットフォームは追い求めない。追い求めるべきものは開発者体験。
第一に開発者体験を追い求めること。第二に信頼関係を作ること。
信頼関係が無い人が作ったものは使えない。
続けることが大事。作って終わりだと持続できない。持続して信頼が築ける。
Platform as a Product。プロダクトを創るように携わる。
- 2024 Japan AWS Jr. Champions×AWS Academyによる学生向けイベント企画コミュニティを立ち上げた話
JrChampionは自発的にオーナーシップを持ってアウトプットを行っている。
すべてのコミュニティが並行して動いている。
現在、学生向け企画が動いている。
飲み会の場での発案だったが、企画書書いて提案した。
なぜ学生向けか。AWSとの出会いで人生が大きく変わったが、運が良かった。
たまたまではなく機会を提供できるようにしたい。
学校とのMTG。検討提案。登壇。
出展ブース
AWSのイベントということもあって、セキュリティや脆弱性やコスト関係を扱う企業様が多かった印象。学びになります。
Postmanさんのブースでは今までずっと気になっていた絵本を頂いてしまいました。
これは本当にうれしいです。
感想とまとめ
はじめてのJAWS DAYS。はじめてのAWS関係のイベント。
その熱量の高さにコミュニティが持つエンジニア文化やテクノロジーの発展に対する影響力をひたすら感じました。
１つの大きなフロアで敷居を設けずいろいろな人たちが発表をする形が熱量を上げている気がする。
最初こそにわかAWSユーザーの自分がはたして参加してよいのだろうか的にびくついていましたが、結果とても楽しかったです。
特にキーノートでのJeff Barrさんのお話は、エンジニアの１つ１つの取り組みが未来を形作っていることを実感して胸が熱くなりました。
AIは今までの我々の築いてきたことの先にあるものであり、そのオーナーシップを持つのは我々である。
この先にいったい何があるかが楽しくなりました。
PostmanさんのAPIのセッション内容はすぐ現場で展開したいし、
jacopenさんのプラットフォームエンジニアリングのお話が首がもげるほど痛感でした。
IAMのお話もCognitoのお話も興味深かったし、物理→経験→知識→共有知のような重要さを感じました。
後はやっぱりコミュニティの重要性。
ハレとケじゃないけど、日常の業務からだけでは学べないことはあり、その学べない知識のるつぼがコミュニティにあるとしたら、それを体感することは日常をより見え方が違うものにしてくれると実感しました。
誰かの経験からの学びは、誰かの知識になり成長につながる。
