【参加レポート】JAWS-UG朝会 #64 #jawsug_asa

Posted at 2024-12-08

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

今回は12/09（月）に参加したJAWS-UG朝会へ参加しましたので、
アウトプットとしてイベントレポートを執筆いたしました。

すき間時間で読める分量で執筆いたしますので、お気軽に読んでいただけますと幸いです。

セッションを聞きながら執筆しているため、誤字脱字・認識相違があると思います。極力防ぐように執筆を行っていますが、ありましたら、温かくコメントいただけますと幸いです。

セッション① CCoEって何？AWSでは何をするべき？
セッション② AWSの「genai-quickstart-pocs」を使ってお手軽に生成AIのPoCを始めよう！
LT① Amazon GuardDuty Malware Protection for Amazon S3導入してみた
LT② 大規模サーバ移行を成功に導くための事前調査フェーズの工夫事例
LT③ (仮)Systems Managerを利用したインベントリ収集

セッション① CCoEって何？AWSでは何をするべき？

CCoEに関する概念的な話
自己紹介
- 日系Sierでデータ分析・新規サービス立ち上げ経験
- 現在はCCoE担当を行っている
クラウドを利用する理由
- アジリティ（俊敏性）が高い
  - ハードウェア・データベースなどを自前調達する必要が不要
  - 従量課金による手軽な構築が可能
  - 実業務でオンプレ環境構築を経験した時に待ち時間が多いと感じた
- アジリティの高さによるDX推進をスピーディに行える
  - リソース調達をスピーディに行える
- 管理面も考慮する必要がある
  - アジリティを重視すぎるとリソース管理が煩雑になる
  - 権限管理が複雑化し、抜け漏れが発生するリスクが高くなる
CCoEとは
- 組織でクラウドを利用推進する立場
  - アカウント管理・ハンズオン環境構築・コスト管理など多岐にわたる
  - 人材育成として資格取得推進・ハンズオン企画なども役割としてある
- CCoE組成について
  - 現場・情報セキュリティ部門・人事部門と連携する必要がある
  - やり方１：情報システム部門から役割を切り出す
  - やり方２：現場部門からボトムアップしていく
AWSを活用したCCoE活動について
- 具体的な方法（例）
  - アカウント分離（マルチアカウント化）
    - 部署間でAWS Accountを分ける⇒部署間は不干渉
  - AWS Organizationsを用いた複数アカウント管理
    - 予算・コストなどを一元管理する
  - Amazon ConfigやGuard Dutyを活用して規制を入れることも大切
まとめ
- アジリティの高さゆえにセキュリティ管理が難しい
- AWSでマルチアカウント管理機能を提供しているので、それらサービスを利用することがある

セッション② AWSの「genai-quickstart-pocs」を使ってお手軽に生成AIのPoCを始めよう！

要旨
- 生成AIを活用したPoCの手段説明
- PoC成功の観点は対象外
- アプリケーションの詳細については別途ブログ紹介
自己紹介
- 2023年にアイレッドへ新卒入社された方
- Python/Laravelなどを用いたバックエンド開発
生成AIのPoC
- DX動向2024でも実証実験数が増加していることを示唆している
- 大きく3ステップに分けられる
  - ゴールのすり合わせ（As-Is,To-Beの定義）
  - 検証に関する方式検討・検証作業
  - 検証結果をレポート化☞意思決定を行っていく
  - 今回のLTでは検証へフォーカスを入れていく
genai-quickstart-pocsとは
- 生成AIを活用したアプリケーションを作成・検証するためのOSS
  - Pythonで試す場合、Gitクローン⇒ライブラリインストール⇒実行のみで完了
- プロジェクト構成に関してもシンプルにまとめられている
  - カスタマイズすることで機能拡張することができる
まとめ
- AWSのOSSを活用すれば、生成AIのPoCをシンプルに実装することができる
- 使い方は十人十色（テンプレート化することで、アイデアをすぐに実装できる）

LT① Amazon GuardDuty Malware Protection for Amazon S3導入してみた

社内向け生成AIアプリケーション開発を行っている方
GuardDuty Malware Protection for S3とは
- S3に保存されたオブジェクトを自動スキャン⇒ウィルス判定とタグ判定を実施
- 設定有効後のオブジェクトしか利用できない
利用シーン
- 顧客から転送されるファイルサーバ
- データ数が月間10件程度なので、コスト最適で済ませたい
選択肢
- フルマネージドなサービスであること
  - メンバーの9割がインフラエンジニアのためセキュリティ専門家がいない
- CloudFormationから実装可能なこと
  - クラウド管理をCloudFormationで行っている
しくじりポイント
- 気軽に大容量データを置かないこと
  - 容量単位で課金されるため
運用してみたことでの発見
- ウイルス検知時の運用フローを決めておく
  - エスカレーションをどうするのか
  - 検知されたファイルを読み取れないようにする方法を考えておく

LT② 大規模サーバ移行を成功に導くための事前調査フェーズの工夫事例

要旨
- サーバ移行に関するお話
自己紹介
- 直近でクラウドへのサーバ移行の経験を行った
サーバ移行フェーズ
- アセスメント
  - 移行対象を調査・分析
- 計画
  - 移行計画を行う
- マイグレーション
  - クラウド環境へ移行する
アセスメントでの課題
- サーバの構成管理・性能情報を把握できていない
- 情報収集を自動プロセスで管理できない
- AWS ADSを活用した
工夫ポイント
- 閉域網経由でリソース情報を収集する構成にした
- スクリプト経由で情報収集を行っていく
- データベースサーバを活用して収集した情報を管理

LT③ (仮)Systems Managerを利用したインベントリ収集

自己紹介
- ビックツリー社の新卒3年目エンジニア
- 官公庁案件を経験している
AWS SSMとは
- サーバ構成情報（インベントリ）を取得することが出来る
- ダッシュボード上から情報を確認でき、脆弱性対応をスムーズに行える
  - 調査対象が多い場合はCSV出力して調査したほうがいい
課題
- 削除済みのEC2リソースが表示されてしまう
  - ダッシュボード上からリソースの状態が分からない
  - 原因としてS3で情報を累積管理していること（=古い情報が残り続ける）
対策
- EC2削除イベントをもとにCloudTrail⇒Lambda経由でデータ削除する
コンテナ管理の場合
- SSMの利用は推奨されていない
  - 脆弱性がないコンテナイメージのスキャンを定期的に実施⇒再作成を行う
  - Inspectorを用いる方法もある

参考ドキュメント

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

【参加レポート】JAWS-UG朝会 #64 #jawsug_asa

目次

セッション① CCoEって何？AWSでは何をするべき？

セッション② AWSの「genai-quickstart-pocs」を使ってお手軽に生成AIのPoCを始めよう！

LT① Amazon GuardDuty Malware Protection for Amazon S3導入してみた

LT② 大規模サーバ移行を成功に導くための事前調査フェーズの工夫事例

LT③ (仮)Systems Managerを利用したインベントリ収集

参考ドキュメント

CCoE関連（セッション①）

生成AIとPoC（セッション②）

GuardDuty Malware Protection for S3（LT①）

AWS Application Discovery Service（LT②）

AWS Systems Manager（LT③）