【イベントレポート】JAWS-UG東京 Presents 400 #jawsug_tokyo

いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！

今回は2025.04.23（水）に開催したJAWS-UG東京 Presents 400へ参加しましたのでアウトプットとしてイベントレポートを執筆しました。

初見の方でもサクッと読めるように平易な表現で執筆しておりますので、お気軽に読んでいただければ幸いです。

誤字脱字、わかりづらい表現、認識相違などは極力なくすように心がけています。そのうえで、リアルタイムで執筆しておりますので、誤字脱字、わかりづらい表現、認識相違などがあるかもしれません。

イベントページ

目次

• 読んで学ぶ Amplify Gen2 / Amplify と CDK の関係を紐解く
• CodePipelineのアクション統合から学ぶAWS CDKの抽象化技術
• コスト最適重視でAurora PostgreSQLのログ分析基盤を作ってみた
• Security Hubの利用者調査と?お悩み相談をやってます！
• まとめ

読んで学ぶ Amplify Gen2 / Amplify と CDK の関係を紐解く

参考サイト

• 自己紹介
  • コープさっぽろでソフトウェアエンジニアをされている方
  • Amplifyコミュニティ・CBsの方
  • 好きなフィギュアスケートの技はスプレッドイーグル
• お伝えすること
  • AmplifyとCDKがどのように連携しているかコードレベルで知る
    • （個人的意見）コードレベルで見るのは大切ですね
  • 気になった方はOSSのコードを読むきっかけになる
• 確認していくこと
  • Amplify CLIの挙動・処理の呼出し時の挙動など
    • （個人的意見）挙動周りは気になりますね
    • （個人的意見）Amplifyは触れていないから触らないといけないなぁ
    • （個人的意見）Type Scriptは気になっているから触らないとなぁ
• Amplify Gen2からの変化
  • AWS CDKとの連携が改善した
    • ざっくり言えばCDKに依存した形で構築できるようになった
    • （個人的意見）Sandbox機能は良すぎる
  • AI Kitのgenerationをデプロイ
    • デプロイするためにやることとしてリソース実装などがある
    • （個人的意見）ワンコマンド実行で構築できるようにするのが大切そうね
  • 実行結果はcdk.outが出力されAssemblyクラスで取得できる
    • （個人的意見）Terraformm感を感じますね
    • （個人的意見）Type Scriptだから型安全も担保されているからいいですね
• CLIコマンド（ampx）としての実装
  • yargsでオプション解釈している
  • 呼出し自体は抽象化されているためCDK以外も呼出し可能にしたい
    • （個人的意見）抽象化していると実装で考えることが減るんですよね
• AmplifyリソースをCDKリソースへ置き換える
  • 各カテゴリごとに変換処理を行っていく
    • Dataカテゴリの場合：GraphQL Schemaへ変換していく
      • （個人的意見）実装を見ると力技感を感じますね
      • （個人的意見）関数と使用法についてはキャッチあぷしないとなぁ
    • CDK Toolkit利用についてはまだできない状況
      • コード自体は存在しているため時間の問題
      • （個人的意見）リファクタリングの重要度を感じるようになるんですよね
    • （個人的意見）コードを読む力は重要ですね

CodePipelineのアクション統合から学ぶAWS CDKの抽象化技術

参考サイト

• 自己紹介
  • AWS DevTools Heroの方
  • 自作OSS・AWS CDK Top Contributorの方
• Code Pipelinetとは
  • ざっくり言えばCI/CDのジョブを構成する
    • ステージ：パイプラインを構成する論理ユニット
    • アクション：Source・Build・Testなど7種類ある
      • （個人的意見）Approvalを使ってパイプライン構築を行いたいんですよね
    • アーティファクト：アクションによって処理されるファイル群
  • DockerfileのチェックについてもInspectorを利用すればできる
    • （個人的意見）AWS Signerを組み込めたりするのかしら
    • Code BUildを利用しなくてもアクションを利用することでソースコード取得・脆弱性チェックが行える
• アーキテクチャ例を選んだ理由
  • CDKでコントリビュートした内容だったから
• CDKによるメリット
  • CloudFormationで執筆しようとしたらコード量が多くなる
    • CDK対応することで本体とアクションを分離させることができる
  • プロパティ指定するだけでActionsを実行することができる
    • （個人的意見）この話を聞くとCDK コントリビュート再開しないとなぁと思いますね～
  • Action（CloudFormation）とIAction（CDK）の土台が同じため継承可能
    • （個人的意見）必要なIAM権限付与もコード側に任せられる
    • （個人的意見）社内の新人研修でも触らせたいですね（リソース料金の問題もありつつ）
  • 条件に応じて作成する権限が自動的に定まっていく
  • プロパティの中には分岐（ソースコードスキャン or ECRイメージスキャン）が発生する場合、処理を洗練させる必要がある
    • （個人的意見）洗練させないとネスト状態につながりますからね
• Variable（変数）の形式隠蔽と補完
  • CodePipeline特有の記述方法に合わせて可変してくれる
• 抽象化によるメリット
  • コード数を約1/10に削減することができる

コスト最適重視でAurora PostgreSQLのログ分析基盤を作ってみた

参考サイト

• 自己紹介
  • クラスメソッド所属のエンジニアの方
  • 好きなサービスはAmazon FSx for NetApp ONTAP
• CloudWatch Logsに流しているDB費用問題
  • （個人的意見）ログ出力のチューニングから始めますね～
    • 特定ログだけCloudWatch LogsへエクスポートしたいがPostgreSQLログとしてまとめてしまう
    • ログは最大7日間しか保持できないため、監査対応を考えると難しい
  • 結論としてCloudWatch Logsへ垂れ流す方法になる
    • よくあるケースとしてFirehose⇒S3へ流すパターンだが
      • ログの保管料金は安くなるが全体を見るとコストがかかる
  • アーキテクチャについて再考する必要がある
• アーキテクチャ検討
  • 月10TBペースで出力される
  • Logs Insightを利用することで約月117万円かかる場合も
    • AuroraのログファイルはDBインスタンス内に出力される
  • Logs IAに流す
    • 手間がかからず欠損リスク少ない
    • メトリクスフィルターを利用できない、半額レベルのコスト最適しか実現できない
  • 自作DBでS3へ流す
    • コスト最適化の視点であれば最高だが手間がかかる
  • 運用イメージが付いていないのであればログを取得しないという選択肢もある
• ログまわりの対策
  • LastWrittenによる絞り込みを行う
    • 重複ログを削減できる
    • （個人的意見）絞り込みに関しては実装が難しいから手法が知れるのはありがたい
  • stderr形式で出力させる
    • CSVログでも出力できるが、stderrも出力されるためストレージ圧迫につながる
    • 枯渇したことでスケールアップさせるのはもったいない
  • S3オブジェクトの圧縮
    • 圧縮対応を行うことでストレージ保管料金・スキャン料金を削減できる
• コスト削減のその先
  • 仕組みを利用することで117万/月が4,500/月に削減できる
  • ログ保管だけでなくログ分析に生かしていくことが重要
    • スモールスタートであればAthenaを利用するのがベター
  • ピンポイントで分析したほうがスキャン料金がかからない
    • （個人的意見）パーティション分けを推奨する理由を今理解できた
    • （個人的意見）性能比較するのは大切なんですよね
• DuckDBでのユースケース
  • テーブルコピーだけで処理が完結する
    • （個人的意見）AWSでの処理が少なくて済むのはうれしいですね
• まとめ
  • 目的のないログ取得はランニングコスト/対応コストがかかる
    • （個人的意見）分かりみが深すぎる

Security Hubの利用者調査と?お悩み相談をやってます！

• 自己紹介
  • クラスメソッド所属のシニアソリューションアーキテクトの方
  • AWS Security Heroの方
• Security-JAWSでの取り組み
  • AWSセキュリティのベストプラクティスの実態調査を行っている
  • （個人的意見）GuardDutyは個人では入れているが社内ではなぁ
• Security Hubの悩み
  • AWSの様々なセキュリティ対策を取りまとめている
    • 主に設定ミス防止に利用されることが多い
    • 初心者から熟練者まで幅広く利用できるようにしている
  • Security HubのTIPS
    • ガバナンスを考えて実装していくと効果的に進められる
      • （個人的意見）確かに個々で進めていくのは非効率的ですからね
    • 組織で対応方針を決めておくことでSecurity Hubをうまく実装できる
• 利用実態
  • 組織、部門、利用状況、成功体験、失敗体験など
    • （個人的意見）回答することで気づきを得られるのはいいアンケートすぎる
  • お悩み相談、レベルなど
    • （個人的意見）困りごとを可視化することで共有しやすくなりますね
    • （個人的意見）フィードバックは本当に大切ですからね！

まとめ

Level 400のセッションを聞く機会は少ないので非常に学びになりました。

そのうえで、CDK開発・セキュリティ・ログ設計などに関してもまだまだキャッチアップしないといけないところが多数あると気づかされました。

引き続き、キャッチアップしていかないといけないなぁと思いました！！

最後まで記事をお読みいただきありがとうございます！！