【イベントレポート】JAWS-UG東京 ランチタイムLT会 #19 #jawsug_tokyo

いつも記事を読んでいただきありがとうございます！
モブエンジニア（[@mob-engineer](https://qiita.com/mob_engineer))です！

今回は2025.01.28に開催した**JAWS-UG東京 ランチタイムLT会 #19**へ参加したので、アウトプットの一環としてイベントレポートを執筆しました。

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

:::note info
誤字脱字、分かりづらい表現などはなくすように心がけていますが、リアルタイムで執筆しているため、誤字脱字があるかもしれません。
:::

#### イベントページ

https://jawsug.connpass.com/event/340374/

# 目次
- CloudFormationで気を付けたいポイントをまとめてみた
- GitLab Self ManagedをCodePipelineのソースにするためのネットワーク構成を考える
- 消し忘れリソースゼロへ！私のResource Explorer活用法
- ELB vs API Gateway vs CloudFront / 結局何を選べばいいの？
- まとめ

## CloudFormationで気を付けたいポイントをまとめてみた

#### 参考サイト

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/Welcome.html

- 自己紹介
    - CTCテクノソリューションズ社の2年目の方
    - AWS環境の構築・運用を担当されている
- テーマのきっかけ
    - CloudFormationで地雷を踏んだ経験から
- CloudFormationとは
    - AWSリソースのモデル化およびセットアップサービス
    - 制御を楽に行える
    - 今回の構成はマルチスタック構成
- CloudFormation時のトラブル
    - 管理アカウントでドリフト検出が正しく行えていなかった
        - 理由はサブアカウントの情報が見えていなかった
    - ロールバックの挙動に関して
        - Ver3リリース時にエラーとなった
        - ロールバックするテンプレートバージョンが直前で手を加えてたバージョンではなかった
        - 単純に旧バージョンに戻るわけではない
- まとめ
    - 詳細についてはQiitaへ投稿予定

## GitLab Self ManagedをCodePipelineのソースにするためのネットワーク構成を考える

#### 参考サイト

https://dev.classmethod.jp/articles/gitlab-aws-202310-kidapan/

- 自己紹介
    - ARアドバンストテクノロジの2年目の方
    - 業務としてサーバーレスアーキテクチャの設計構築担当
    - 趣味はアニメ・カラオケ
- テーマの背景
    - CodeCommitの新規利用終了に伴うソース管理先の検討
    - CodePipelineへフォローしているGitLabを選定した
- GitLabの概要
    - Gitを用いたソース管理サービス
        - SaaSとオンプレミス版がある
        - CI/CDも利用可能
        - 今回はオンプレミス版を利用した
    - オンプレミス版の選定理由
        - 自社ストレージで管理可能
        - セキュリティ向上
- 構成
    - GitLab⇒CodeBuild⇒CodeDeploy
    - GitLab↔CodePipelineの接続を考える必要がある
- 工夫ポイント
    - GitHubのHTTPS化
        - GitLabの使用として登録するURLがHTTPS出ないといけなかった
        - 対策として間にALBを設置⇒証明書を設定
    - アクセス元IPアドレスの固定化
        - Internetゲートウェイを設置して固定化
- まとめ
    - パイプライン構築時にはHTTPS通信が必要になる
    - インターネットを経由せずに確立する方法を模索

## 消し忘れリソースゼロへ！私のResource Explorer活用法

#### 参考サイト

https://techblog.ap-com.co.jp/entry/resource-explorer-cost-reduce

- 自己紹介
    - APコミュニケーション社のエンジニアの方
- 対象者
    - 個人利用後のリソース削除漏れに困っている方
    - コスト通知するようにしたけど、対処がめんどくさい方
    - そんな方向けにResource Explorerの利用をお勧めする
- Resource Explorer
    - ざっくり言えばリソース検索画面
    - よく利用するものはクエリからビューを作成することが可能
- 利用時のユースケース
    - デフォルトリソースと常駐リソースを非表示にしておく
        - 消し忘れリソースをすぐに見つけられる
- メリット
    - 1画面でリソース一覧を確認可能
    - 無駄なリソースによる課金を未然に防止
    - IAMロールなどの非課金リソースの整理も可能
- 注意
    - 反映までに時間がかかる
    - 一部リソースは未対応

## ELB vs API Gateway vs CloudFront / 結局何を選べばいいの？

#### 参考ブログ

https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/

https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/welcome.html

https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/Introduction.html

https://zenn.dev/acntechjp/articles/8bde90d02ff2ef

- 自己紹介
    - アクセンチュアのエンジニアの方
    - AWS・GC認定資格全冠の方（つよつよ）
- きっかけ
    - エンジニア経験が浅いとインフラアーキテクチャの選定難易度が高い
    - 選定するための基準を整理する目的でLT発表した
- 比較対象
    - Elastic Load Balancer
        - AZ内の複数のターゲットのヘルスチェックを行い受信したトラフィックを分散させる
    - Amazon API Gateway
        - APIを通じたアクセスをフォロー（REST API利用アプリ向け？）
    - Amazon CloudFront
        - エッジロケーションへコンテンツを配置し低レンテンシーなアクセスを実現
- 各構成のパターン
    - ELBのみ構成
        - ヘルスチェックを行いながらリクエストを均一で分散させる
        - レイテンシーは最適化されているわけではない
    - ELB＋CloudFront
        - ELBのみと比較しレイテンシーを低くすることが出来る
    - NLB＋API GateWay
        - API経由でのアクセスがある場合の構成
        - レイテンシーを向上させるのであればCloudFrontを利用

## まとめ

どのセッションも私が知らないサービス利活用について取り上げていたので、新たな発見がありました。また、新卒2年目の方が積極的に登壇チャレンジされていたので**凄い**といった印象を強く持ちました。

私も、今後アウトプット活動を積極的に行っていきたいと思っていますので、モチベーション向上につながりました。

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