# JAWS-UG浜松+Hamamatsu.js 勉強会202504

## 注意事項
- 場所は18時まで
- 懇親会もあります
- 近くで古本市がやってます
- 多少押しても大丈夫よ
- 懇親会まだ入れる？・・・確認中
- 次回は余裕があれば電源タップ持ってこよう

## Amplify Gen2の話
- ゲストユーザーへの認可がうまくいかない・・・らしいよ
- やりたかったこと・・・位置情報を活用したSPAを作りたい
- ログインユーザー使わずゲストユーザーのみの機能にしたい
- よくわからんエラーが出る
- Cognite IdentityPool使ってゲストユーザーのAPIKEY発行をしようとしている
- うまくかんかった・・・
- Amplifyとしてはユーザー権限なないとだめで、ゲストユーザーだとだめとのこと
- Amplifyめんどくさいところがある
- 使うたびになにかにハマる
- ドキュメントに載っている方法から外れるとつらい感じ
- ホスティングが便利
- AWS SDKで一時クレデンシャルを発行して、うまく動くようになった

### QA
- 公式のドキュメントは？
- Amplify Gen2とかで探すと一番上に出てくるらしいよ
- https://docs.amplify.aws/

## 七輪ライブラリー Claude AIで作るNext.jsアプリ

- 七輪・・・aikoコピーバンド
- 七輪の活動を調べられるWebアプリを作った
- 20年もやってるとメンバーが入れ替わっていく。
- モバイルでも過去のライブ活動内容を振り返ることができるようにしたい
- おすすめのAWS勉強法は、作りたいアプリをまず作ってみること(Slackで聞いた)
- Claude AI使ってる人結構いる〜
- いままでやったライブの履歴、統計情報が見える！
- グラフかっこいいな
- 総ライブ回数86回はすごいな
- 一番演奏したのは花火
- 動画も開けるようになっている
- 開発プロセスの紹介は省略！
- データ管理は静的データにしてアプリに内包している
- ライブ開催ごとに更新

### Claudeについて
- 基本的には優秀
- ファイルサイズが大きくなりがち
- ミスの傾向が同じ

### Amplifyへのデプロイ
- githubにpushした後のビルドがコケる…
- ローカルで手動ビルドしてデプロイする方式にした
- Vercelもおすすめ

### まとめ
- 実用アプリが開発できた
- あとでQRコードを貼り付けします

### QA
- 皆Claude AIでどんなことができるか、どうやって使うか気になる様子
- 音楽やる人は欲しがる
- デザインとかはAIに丸投げ
- 最初からだいぶいい感じにやってくれました
- カラーコードとかをAIにヒントとして与えている
- AIデザイン侮れない
- Amplifyの文句・・・ログがコピペしづらい
- 進みをSlackで報告します

## 空気のようなクラウドとAWS構成

- インフラ構成は意識されない、でも存在しないとシステムは動かせない
- 顧客案件でAWSと初めて出会った
- とりあえずマルチAZ、ELB、EC2配置で構成…
- お高いが安全安心
- アプリケーションサーバー障害時に、即時切り替わらなくていい
- 24時間利用ではない
- メリット、デメリットを整理。シンプルな構成のほうがよかった
- Lambdaでコスト対策
- シングルAZ構成にした
- シングルAZでも強固なバックアップ体制を構築

### まとめ

- マルチAZが必ずしも正解ではない
- コスト、運用、可用性のバランスを見極める
- オンプレ時代の経験が生きている
- きれいに動いていてよかった

### QA

- 手こずったところ
- 手動運用にします、といったことを顧客に承認してもらうのが難しかった
- 急に空気がなくなるとこまる
- AWSのせいにできるのはでかい

## OpenAPI✕AWSで仕様迷子をゼロに

- 無理やりAWSと絡めました
- 仕様書がExcelだとがっくり来る…
- 属人化しないチームを作るのが夢
- 障害調査、仕様説明で時間が溶けていく＞＜
- OpenAPIで仕様書を書いて、そっから
- 設計→モック→実装→・・・
- 仕様書あるんだけどよく読んだら実際の実装とは違うよ、というのを防げる
- AWS CDKでそのままデプロイできる
- スピード、品質、外部連携にメリットが有る
- OpenAPIがくれる"壊れない"API
- 共通コンポーネントで表記ゆれがない
- 信頼できる仕様を育てよう

### 自社の宣伝
- 副業OK
- 育休できます

### QA
- フロントエンド＜ー＞バックエンド間の通信仕様はOpenAPIを使っていれば壊れない
- OpenAPIジェネレーターというのもある。コードも生成してくれる

## バックエンドエンジニアにジョブチェンジして苦労した話

- 静岡市から！
- Yakumoプロジェクト・・・米国市場向けのKintone.com開発プロジェエクト
- AWS上で動かそうとしている
- すでに運用フェーズ
- AWSのいろんなサービスを使っている
- 国内版はk8sで動いている。そのままAWSに持っていける

- もともとはアプリ担当だったからバックエンドは大変だった…
- どのサービスをどこで動かしているのかわからない
- コードリーディング会やドキュメント改善会で理解していった
- ログの種類が多すぎる。ドキュメント化した
- やっとトラブル対応と新規開発ができるようになった
- これからシンプルなシステム構成にしたい

- データのマイグレーション用のAPIを用意している。
- システムの切替時に停止しないように工夫している
- DBサーバーのメンテのときは止める…が多重構成にしているので停止時間が短い

## AmplifyGen2お試し

- 好きなAWSサービスはStepFunctions
- Copilotに聞いたらいろいろ親切に教えてくれたが・・・うまくいかなかった
- クイックスタートから初めて…TODOアプリ的なやつが即できて動いた
- AmazonQに修正依頼を出したところ…やってくれたがここまでで力尽きた
- 孫の初凧あげます
- 質問されても答えられないかも
- Amplifyで画面が出るまで…だいたい30分くらいでできた
- 長男が生まれると浜松市は凧をあげる風習がある
- 浜松市知らない人には全然わからない
- まあまあ金かかった

----

## ！懇親会集金タイム！

----

## Serverless Framework から AWS CDKに乗り換えた

- AWS Cloud Development Kit
- プログラミング言語を使ってAWSリソースを定義、デプロイできるツール
- AWS CDKは公式でサポートしていることがうれしい
- 新サービスへの対応が早い
- Serverless Framework v3 to v4 だと不具合をふんだりしてうまくいかなかった
- あんまり情報が他のツールと比べて少ない
- 公式問い合わせしても情報が来なかったりした
- Terraform
- AWS CDKとどちらを使うか一番迷った
- マルチクラウド対応しているのは強い
- 新しい機能に追従するのが遅い
- AWS CDK
- AWS公式のサポートが受けれる
- デプロイに時間がかかる
- コードとリソースの実態の差分を検知する機能がCDKにはない
- Cloudformationのリソース制限を継承
- 便利なところ
- カスタムリソースが作成できる

### まとめ

- AWS CDKにした
- AWS公認でサポートされている安心感
- TypeScript未経験者でもそれなりに作れた

### QA
- 移行コストは思ったより高くないです
- 問い合わせたけどどうにもならなかったこともあった
- 困ったときに助けてもらえる、というのが選定の一番大きい材料だった
- Change MindってGCPのサポートから送られてきたときはびっくりした

## S3バケットポリシーの解説
- 磐田支部から来ました!
- S3で以下を保管したい
- 公開コンテンツの保管
- 各種文書の保管
- ログ保管
- ファイルの保護はS3バケットポリシーで行う
- JSONで記述できる
- IAMポリシーとは別物
- 普通にJSON形式で書くとわかりにくい
- 暗黙的な拒否がある。明示的に書かないと拒否されないことがある
- アクセスポイントを併用すると管理が複雑になる
### まとめ
- S3バケットポリシーでアクセス制御ができます
### JAWS-UG磐田勉強会 7/19
- 生成AI(AWS GenAI)の話
### QA
- バケットポリシー書いたことない人は図解しないと難しい
- JSONの検証は、実際にグローバルAPIを固定して使えるか試した
----
## 休憩
----
## 面倒なことはAWS CDKにやらせよう
- AWSで面倒なことといえば…
- IAM Policyのアクセス設定!
- IAM Policyは基本にして重要な要素。失敗すると許可してはいけないものが許可されてしまう
- 慣れないと設定が難しい。いけないユーザーを許可してしまいがち
- アクセス設定、もっと楽にできないの
- AWS CDKで楽にできるよ
- 大半のリソースにgrantXXXというメソッドが用意されている
- IAMポリシー1行も書かなくても設定ができる
- grantで許可するアクションも指定できる
- 最終的に出力されるIAM PolicyをCDKで確認できない。CDK自体はソースコードであるため。
- 最小権限の原則に沿っているかは確認が必要
- 人的な設定不備について、100％解決できるわけではない
- CDKは単体テストが実施できるのがメリット

### まとめ
- AWS CDK grantメソッドっでIAM Policyを定義せずにアクセス設定が行える
- 銀の弾丸ではない。定義されたポリシーの確認が必要

### Live Codingやってみた
- LiveCoding
- リアルタイムでプログラムを記述しながら音楽やビジュアルエフェクトを演出するパフォーマンス
- Unagi.pyの懇親会でもりあがった
- React Three Fiberを試した
- カスタムのシェーダーを組み込むことが可能、GPU上で演算が可能

### まとめ
- 実際やってみると面白いけど結構むずい。道程は長い
- マシンスペック要求される

## AZ名とAZ IDの違いを何度でも言うよ

- 先週の障害の話からネタを
- 札幌から来ました。暑くて死にそう

- リージョンとアベイラビリティーゾーン
- 日本には東京都大阪にリージョン。
- さらに細かい単位としてアベイラビリティーゾーンがある
- 今このAZはいっぱいらしい。増えるかも？…

- どのAZを使っているか把握していますか
- AWSのサービスはEC2上に乗って動いているので、この前はいろんなサービスに障害があった

- アカウントごとにAZ名が違う。AZ IDで会話したほうがいい

- AWS RAMでAZ IDを確認することができます

- AZ IDの分布を調べようとした
- 分布してないと障害対応が大変かもしれない

----
## !あとで記念写真取るよ!
----

- うなぎは雄踏の"はじめ"で食べました

## AWSマルチアカウント戦略で考えるべきこと

- マルチアカウントにする理由
- シングルアカウントだとユーザーごとにポリシーを細かく設定する必要がある
- 面倒なので全員Adminを与えてしまいがち

- マルチアカウントでもアイデンティティーセンターで入口を1つにできる
- アクセス権限セットでOU、アカウント単位で管理できる

- SSO管理アカウントでOrganizationを作成し、管理対象アカウントをメンバーアカウントにする
- SSO有効化
- MS365のIDを使うこともできる

- OUの概念
- AWSアカウント群をOU(Organizational Unit)という単位でグルーピングできる
- OUごとにSCPを設定することで下位に権限を継承できる
- 公式のOUの分割設計は参考になる…がこの通りにやっていないところも多い

- OUを本番と本番以外で分けたり、機能ごとに分けたりしているサンプルもある
- 合理的な根拠がある設計であれば基本は自由
- ある程度確立されたパターンがあるので参考になる
- 最低限本番とそれ以外で分ける

## QA
- IAMユーザーは親ユーザーに作るのか
- 基本的には親ユーザーに作る
- IAMロール自体は作る
- SCPで管理して下の階層に権限をもたせる
- リソースに対しての制限をもたせる
- ログインのときにロールの切り替えができてしまうので便利
- アカウントの設定をガチガチにすると崩れがち
- これからガチガチに維持できるかトライしていく
- OUは実際の組織と同じにしてはいけない。組織変更があると大変。
- 機能と一致した形にしておいたほうがベター

## 宣伝

### シンハママツ計画

- 明日情報がオープンされる？…
- デジ庁人員募集中
- 副業OK。週1時間みたいなエントリもある
- 悪い組織ではないと思う

### RubyKaigi 2026
- 函館でやるらしい

### SHIZUOKATECH#1

### Synth Maker Meetup #4

### IT自動化ネタライトニングトーク

### TsKaigi
- typescriptのカンファレンス