omuronの備忘録

個人的な備忘録

「JAWS-UG CDK支部 #1 〜初回拡大版〜」 #jawsug_cdk 受講メモ

JAWS-UG CDK支部 #1 〜初回拡大版〜

jawsug-cdk.connpass.com

セッション

AWS Summit Online re:Cap - CDK & BLEA

Yukitaka Ohmuraさん

  • AWS Summit Online の CDK&BLEA 関連セッション
    • CI/CD Live Coding (developer zone) : みんなのエディターが違うのにも注目
    • AWS-17 : 手順書は30分位かかったけど、コード経由ですると14分程度
    • AWS-19 : BLEA につながるセキュリティのお話
    • AWS-22 : Baseline Environment on AWS (BLEA)
      • AWS のセキュリティベストプラクティスを実装した OSS のサンプルテンプレート
      • BLEA を使って AWS 環境のガバナンスを効かす
      • GitHub から fork してカスタマイズして利用すると良い
        • カスタマイズすることが前提
  • BLEA Updates
    • CDK Pipelines を使用するサンプルが追加された

BLEA って知りませんでした。
セキュリティはやらなきゃいけないけどお金もそこそこかかるしバランス取りながら進めないと。

CDKでお手軽カスタムリソース!

かわごえさん

  • CDK : CFn が生成されてデプロイされる -> CFn 非対応は使えない
  • VPC + Networkfirewall + ルートテーブルなどをまとめたかった
    • EndpointIds の順序が担保されてなくて困った
      • 公式もカスタムリソース使ってるし...
  • AwsCustomResource を使うと Lambda を自身で作らなくてもカスタムリソース作れる
    • getResponseField() で他リソースから参照できる
  • カスタムリソースを本当に使う必要があるかはよく検討を

カスタムリソース使ったこと無いや...諦めて CLI でやっちゃう。

インフラエンジニアがCDK on TypeScriptを推す理由

あんどぅさん

www.docswell.com

  • CDK のいいところ
    • プログラミング言語AWS リソースを抽象化
    • CFn 間の依存関係を定義できたり、デプロイ順を CLI で解決
    • L2 Construct 最高
    • AWS サポートあり(CFn になるので)
  • TypeScript を推す理由
    • CDK のソース自体が TypeScript
    • パラメータ補完と渡し間違い防止
    • インフラデプロイ時に環境成約を型に定義できる
      • 設定を必ずして欲しいものとか、値の指定とかできる
        • ECS のソフトリミットの設定を必須にしたりとかできる
  • CDK で型があると IDE で対話しながら進めれて開発者体験が良い

私も CDK のために TypeScript 勉強した口です。

はじめてのプルリク - BLEA 編

watanyさん

speakerdeck.com

  • AWSConfigRole が非推奨で AWS_ConfigRole が推奨になった
    • BLEA をみると非推奨を使っている
      • コントリビュートしたい
  • CONTRIBUTING.md を読む
    • fork して修正してテストして明確なメッセージでコミットして...
      • コミットでエラー、 git secrets 戻らないので awslabs/git-secrets インストール
      • README_ja.md にちゃんと書いてあった
    • プルリクを main ブランチでしてしまったので修正
    • Author おかしいとツッコまれたので修正
    • 無事コントリビューターになれた

コントリビュートするのがすごい!

AWS Amplify で触れる AWS CDK

tacckさん

speakerdeck.com

  • Amplify:サービスとしての Amplify と OSS ツールの Amplify の2つに別れてる
  • Amplify + CDK
    • re:Invent で Amplify Studio 発表
      • 同時に Amplify に機能が沢山追加された
  • Amplify Custom : Amplify の機能に無いものを追加できる
  • Amplify のリソースは Amplify CLI で準備
    • それ以外はどうする?
      • コンソール:お試し、手作業が必要であれば
      • CFn:アプリの人は辛い
      • CDK:アプリの人でも使いやすい、AWS知らないと辛い
      • Amplify + CDK:アプリの人でも使いやすい、アプリとAWSの繋がりを意識する必要あり
  • Amplify + CDK の課題:フルスタック寄りのスキル必要
    • 個人や小規模で素早くするならフィットする
    • 人数が多かったり開発者がメンテしないなら CDK 使ったほうが良さそう

Amplify ちょっと使うには便利なイメージ。
公開しないちょっとした社内向けの便利ツールとかがマッチするとかかな。

Construct Hub に自作ライブラリを公開しよう with projen

hayao_kさん

speakerdeck.com

  • Construct Hub:コミュニティやAWS/パートナーが後悔する Construct Library レジストリ
    • 3つの条件:JSII-compatible, OSS, CDK Keyword 利用で npm Rregistry に公開
      • projen 使うと意識しなくていい
  • Projen:Construct の考え方をプロジェクト構成に適用
    • プロジェクト構成をコードで定義し、維持するためのツール
      • プロジェクトの雛形作るだけじゃなく、それを継続維持できる
    • いろいろなプロジェクトの雛形がビルドインされている
    • projen new awscdk-construct して .projenrc.js に設定を定義する
      • GitHub Actions の CI/CD 設定 yaml も組み込まれてるので簡単に使える

projen 知りませんでした。

CDKを活用して年間700万円以上のコストを削減した話

ゆっきーさん

https://winteryukky.github.io/slides-cost-cut-using-aws-cdk/1

  • コスト削減の実現に CDK を使った話
  • Trusted Advisor で削減可能コストを見る
    • 低使用率 の EC2 を検知
      • 不要なのに常設していた
  • EC2 に 25万/月 + 監視に 35万/月かかっていて、年720万のコスト
    • 朝昼1回しか動かず、監視も CloudWatch で取れるものだった
    • Step Functions + ECS にアーキテクチャ変更
  • Step Functions のつらみ
    • GUI だと利用リソースの画面と行ったり来たりしないとだめ
    • CFn だとフローが把握が難しいし、量が増えて読みにくい
  • CDK で Step Fucntions のつらみを解決
    • CDK だとフローをイメージしやすい
      • .next .when とかで簡単に書けるし
    • IAM Role の設定も不要
    • CFn -> CDK でコード量が数%程度まで圧縮される

CDK のコード量の少なさは圧倒的!
TypeScript さえ覚えれば戦える。

所感

CDK 便利ですよね!
AWS を知った上で、CloudFormation が使えて、さらに TypeScript も書けないと辛い部分も感じますが、それを乗り越える価値はあると思ってます。

「サーバーレス LT vol.2」 #r_serverlesslt 登壇&受講メモ

サーバーレス LT vol.2 #r_serverlesslt

rakus.connpass.com

今月は勉強会ブログがあまり書けてないですが、久しぶりの登壇です!

セッション

サーバレスとiOSアプリ

y.hira1234 さん

  • Cloud Functions for Firebase
  • iOS からの利用
    • メリット:オートスケール、ランニングコスト抑えれる
    • デメリット:コールドスタート遅い 2-7sec

Lambda の GCP 版みたいなやつですね。

5分でわかるサーバーレスのセキュリティリスク

morioka12さん

  • サーバーレスの種類
    • BaaS: 認証やDBなどの機能利用
    • FaaS: 関数単位でデプロイ、実行
  • サーバーレスのセキュリティリスク
    • 設定ミス: 認証の不備
    • アプリの脆弱性: インジェクション
  • OWASP Serverless Top 10
  • AWS
    • BaaS: Cognito
      • User Pool のロジック不備
        • CLI 経由で自己サインアップできたり
      • ID Pool のアクセス制御不備
    • FaaS: Lambda
  • サーバレスでもオンプレなどと同様にセキュリティ対策しましょう

サーバーレスだからといって脆弱性対応しないでいいわけじゃないので通常通りやりましょう。

「お役立ち Twitter Bot を作りながら学ぶ AWS ドリル」を元に作ったBotを紹介します

nikkieさん

「お役立ち Twitter Bot を作りながら学ぶ AWS ドリル」を元に作ったBotを紹介します

金澤さんの builders.flash は素晴らしいですね。
いつも参考にしてます。

Kubernetes・サーバレスの知識ゼロのエンジニアがKnative Eventing構築してみた

ijikemanさん

k8s つらすぎる...

Google I/O 2022から見る最新のFirebase事情

hyoshさん

  • Firebase: M(Mobile)BaaS, モバイルと相性いい
  • Firebase Extensions: 3rdパーティ SDK を統合、独自にカスタマイズできる Events 追加
  • Firebase Hosting: 手軽に公開できるホスティングサービス
  • Firebase Crashlytics: アプリのバグを収集レポしてくれる、超強力!
  • Swift 対応
  • Firebase AppDistribution: テスターにリリースできる、更新通知可能に
  • Firebase Performance Monitoring: アプリパフォーマンス解析
  • Firebase AppCheck について
    • 認証されたアプリからの通信を保証
    • 正規アプリか、正規ルートか、正規デバイスからアクセスかをチェック
    • 任意タイミングで有効化できる、移行状況も可視化できる
  • 詳しくは公式ブログで: https://firebase.blog/posts/2022/05/whats-new-at-google-io

Firebase いまだに触ったことありません。

AWS Glue 触ってみた

私の発表です。

speakerdeck.com

Glue 思ったより簡単に触れました。

IaCのCI/CDを実現するSpaceliftを触ってみた

yuta_forさん

speakerdeck.com

Spacelift って全然知りませんでした。
日本語化記事もほぼ無いのがつらそう。

Amplifyで自社サービスを開発してみた

NkawaKさん

www.slideshare.net

  • Sylphina: 自社サービス、Amazon Connect を拡張したブラウザフォン
  • Amplify でよかったところ
    • バックエンドをいい感じで作ってくれる
      • init として add auth で Cognito 認証できて、add apiAPI 追加
      • WebSocket のリアルタイム処理も簡単
      • UI/UX に集中して開発できる
    • GitHub と連携で簡単に CI/CD 連携可能
    • スケールが容易
      • AppSync, Lambda, APIG, DynamoDB などと連携するのでスケールできる
  • Amplify のつらみ
    • AWS への理解必要

Amplify 便利ですよね。
簡単なものを作るには最適と思いますが、Amazon Connect と連携してこんな凝ったこともできるのか。

Azure ADによるAPI Gatewayのアクセス管理

cryercryerさん

  • とある Web アプリにアクセス制限をかけたい
  • 構成
    • React + APIG/Lambda + Azure AD
    • APIG はオープンな状態で作成される
      • AzureAD で認証認可を管理
      • APIG とある AzureAD を連携
        • GUI だけで設定できる

Auth0 と連携して試したりはしたことあるけど、GUI だけでできるの知らなかった。

所感

ラクス様のイベント初登壇でした。
サーバーレスの話ですが、やっぱり AWSGCP の話題が中心になりますね。

「JAWS-UG朝会 #33」 #jawsug_asa 受講メモ

JAWS-UG朝会 #33

jawsug-asa.connpass.com

GW 開けでボケた状態での早起きでしたが起きることができました。

セッション

セッション① 実務経験ほぼゼロの私がAWSを触るためにやってきたこととこれから

藤田直幸さん

speakerdeck.com

  • AWS を知るためにやってきたこと
    • JAWS-UG の各勉強会に参加
    • クラウドラクティショナー取得
    • SAA 取得のために AWS アカウント作成して合格
      • 無料枠を使いまくる
    • CLI 専門支部参加、復習ブログ書く
    • LT に間違って登壇登録したのをきっかけに登壇開始
  • とにかく AWS を触るのが一番!
    • それをアウトプットする!

セッション② RDSがIPv6をサポートしたため調査・検証してみた

クラスメソッド株式会社 たかくにさん

  • 2022/04/29 Amazon RDS が IPv6 サポート
    • IPv6 のみはできない、デュアルスタックモードのみ
    • 「パブリックアクセス」と「IPv6サポート」はどちらかのみ有効化可能
    • 設定変更時はダウンタイム発生
    • Aurora は非対応
  • RDS のパブリックアクセス設定とは
    • DNS の回答値にパブリック IP アドレスを含めるかどうか
      • RDS と同じ VPC から名前解決
        • プライベート IP 優先して返す
      • RDS と違う(VPC Peering 設定している)VPC などから名前解決
        • パブリック IP を優先して返す
        • VPC Peering の設定でプライベート IP 返すことも可能

LT① DataSyncの構築/運用時に気づいたこと

クラスメソッド株式会社 あしさん

speakerdeck.com

  • AWS DataSync とは
    • オンプレミスから AWS ストレージや、AWS ストレージ間の転送ができるサービス
    • 他のサービスと違い
      • DataSync : オンラインで大量ファイル
      • Snowball Edge:オフラインで大量のサービス
      • Storage Gateway:アクセス提供
  • タスクの実行ステータスを監視
    • 通知できないパターンがあるので考慮が必要

LT② AWSの基礎を学ぼうで学んだ9種類のDBを勝手にふりかえる

98lerrさん

speakerdeck.com

  • 毎週月曜昼にエバンジェリストの亀田さんがしている勉強会
  • グラレコで絵を買いてまとめてた
    • RDS
    • DynamoDB
    • DocumentDB:MongoDB 互換、DynamoDB と比べてちゃんと JSON 扱える
    • Keyspaces:Apache Cassandra 互換、Key に対して Table がつく
    • ElastiCache:インメモリ DB、 memcached, Redis 互換
    • MemoryDB:Redis の高耐久性版
    • Neptune:グラフ DB、SNS の繋がり表現とかが得意
    • Timestream:時系列に特化した DB
    • QLDB:台帳 DB、意図しない変更がないか保証する

LT③ 簡単にできるコスト異常検出(Cost Anomaly Detection)

emiさん

speakerdeck.com

  • AWS コスト管理」から「コスト異常検出」設定ができる
    • Budgets は予算枠を超えたら通知
    • コスト異常検出は、機械学習を用いた検知
      • 毎日利用料金を監視し、突発的な料金が発生した場合などを検知できる
      • 検知した値をしきい値設定が超えた場合に通知する設定ができる

所感

今日の内容は知らないことばかりで面白かった。
結構マニアックな内容と感じたのは私だけでしょうか?
RDS のパブリック設定とか、「RDS を一般公開する設定なんかするのか?」というような勘違いをしてました。

「AWSの基礎を学ぼう 第八十三回 Network Access Analyzer」 #awsbasics 受講メモ

awsbasics.connpass.com

Network Access Analyzer のデモの回でした。

セッション

Network Access Analyzer

講師:アマゾン ウェブ サービス ジャパン、シニアエバンジェリスト 亀田氏

Network Access Analyzer 概要

  • 特定の通信経路が空いて無いかの確認に使える
    • 2つのサブネット間
    • Resource Groups (タグ)間
    • 特定 CIDR 以外から
    • Network Firewall を経由しないインターネット
    • NAT Gateway を経由しないインターネット
    • SG を持つ ENI 間
  • Reachability Analyzer より強力
    • 通信できるかどうかの確認ができる
    • なぜ通信できないかはわからない
  • 実際のパケットを通すわけではない
    • VPC フローログは汚れない

所感

外から Ping 打っても AWS は基本返さないので、これを使うと外からの疎通確認が簡単にできますね。

「nakanoshima.dev #25 サーバーレスでのIaC/CI/CD 」 #nakanoshima_dev 受講メモ

nakanoshima.dev #25 サーバーレスでのIaC/CI/CD

nakanoshima-dev.connpass.com

セッション

AWS SAMを使ったIaCとCI/

ポール氏

speakerdeck.com

なぜサーバレスで IaC や CI/CD が重要か

  • 本来の価値提供に注力したい
    • より早く安全に提供することが重要
    • IaC や CI/CD を活用する

What is CI/CD

SAM

  • サーバーレスアプリケーション構築用フレームワーク
  • CloudFormation をベースとして定義を抽象化
  • SAM CLI で操作
    • sam init -> sam build -> sam package -> sam deploy

SAM Pipelines

  • SAM Pipelines で CI/CD パイプラインの雛形が生成できる
    • CodePipeline だけじゃなく GitHub Actions, GitLab CI/CD, Jenkins なども対応
  • sam pipeline bootstrap -> sam pipeline init -> sam deploy でテンプレートに --template codepipeline.yaml を設定する

CDKで実現する、お手軽で安全なLambdaの管理

shukim氏

Lambda 管理の課題

  • オンラインエディタを使うと手元のコードと剥離する
  • 各関数の設定を把握しきれない
  • IaC で解決する

CDK の紹介

  • TypeScript などでインフラを定義できる
    • ループや条件分岐、関数化やライブラリ化で生産性向上できる
  • CLI とライブラリ (aws-cdk-lib) で提供
    • CLI はデプロイなどの基本操作
    • ライブラリはコード内でのリソース定義
  • Lambda のコードも TypeSqcript でかける
    • JavaScript に変換されてデプロイされる

所感

SAM は、それだけで事足りことが少ないので使わなくなっちゃいました。
CDK は便利だからよく使うようになりました。
ただ、デプロイに時間がかかる部分が困るんですよね。
public.ecr.aws/sam/build-xxx の Docker Image がどれも重くて CodeBuild とかで走らせると遅いし料金が嵩むのをなんとか解決したい。
キャッシュうまく使いつつ、イメージが古くなったらちゃんと更新するということを考えないとだめなのかな...?

「AWSInfrastructure as Code 談議 2022 」 #AWSDevLiveShow 受講メモ

Infrastructure as Code 談議 2022

www.youtube.com

  • スピーカー
    • 内田 大樹氏 (アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト)
    • 吉田 祐樹氏 (アマゾン ウェブ サービス ジャパン合同会社 プロフェッショナルサービス)
  • 進行
    • 杉山 祐介氏 (アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト)

セッション

  • 構成ツール
    • サーバー構成ツール:Ansible, Chef, Puppet
    • インフラストラクチャ構成ツール:Terraform, CloudFormation
  • なぜ IaC ?
    • ダイナミックインフラストラクチャの台頭
      • プログラムを使ってインフラを管理できるプラットフォーム
    • インフラの変更管理を容易にするため
  • IaC の原則
    • 簡単に再現できるシステム:CI/CD
    • 使い捨てにできるシステム:CD からデプロイされるサーバ環境
    • 統一的なシステム:Git での管理
    • 反復できるプロセス:パイプライン
    • 絶えず変化するデザイン:開発者の思い
  • IaC という言葉の初出は2008年

なぜ IaC を行うのか?

  • 手作業と比較して安全で楽しい
    • 手作業=手順書作成で辛く楽しくない
    • IaC は楽しい
  • リリースへのリードタイムを短くする
    • ビジネスではリードタイムの短縮はとても重要

IaC の教育は?

  • IaC だからといって特別な教育が必要なわけではない
    • 輪読会など通常の技術のキャッチアップをすればいい
  • IaC は依存関係も含めて書かれているので理解しやすい
  • 手順書のほうが教育が大変
    • 順番が書いているだけなので理解が難しい
    • 暗黙的に行われることが多い
  • 組織文化が大事
    • 失敗するたびに承認プロセスが増えるような文化はダメ
    • 小さな失敗を繰り返して改善していくアジャイルな文化がいい
  • IaC でドキュメントがいらないというわけではない
    • README で残す
  • アーキテクチャ図と実際のインフラは DrawIO などで同時に GGit管理する
    • 再利用性とバージョン管理ができるのがいい

引き継ぎはどうする?

  • いつでも引き継げるようにドキュメント化&コード化
    • 日常的に準備しておく
  • 複数人やペアプロで対応するのが理想
    • 教育もセットでできるといい
  • アジャイルでは引き継ぎは発生しない
    • 開発の中で常に共有する
    • 手順書だからといって引き継ぎできるわけではない
  • IaC は DryRun で試すことができる

どうやって IaC に踏み出す?

  • 全部 IaC 化を考えず簡単なところから始める
  • 最初に変なのを作るとそれが増産されるので注意する
    • 最初にいい素材を入れるために経験者など外部リソースに頼るのもいい

IaC で解決できないツラミは?

  • DB の中身をいじるなどできない
  • ランタイムのアップデート後のロールバックでのダウングレードなどは失敗しがち
  • 破棄して作り直しが簡単
  • ブルーグリーンデプロイなどを活用しよう

まとめ

  • 数ヶ月に1度のデプロイのほうが危険
    • 脆弱性対応などでもっとデプロイ回数が多いハズ
  • 毎日デプロイして本番とずらさないのが一番安全!

所感

CloudFormation 大好きなんで、内容的にはすごく同意できるんですが、布教活動が難しいんですよね。
この楽しさを上手に言語化して使える人を増やして引き継いで行きたい。

「AWSの基礎を学ぼう 第八十二回 VPC Reachability Analyzer」 #awsbasics 受講メモ

awsbasics.connpass.com

これまた使ったこと無いサービスの VPC Reachability Analyzer の回です。

セッション

VPC Reachability Analyzer

講師:アマゾン ウェブ サービス ジャパン、シニアエバンジェリスト 亀田氏

VPC Reachability Analyzer 概要

  • VPC 内部での到達性を確認できるサービス
    • どこで止まっているか可視化するサービス

対応リソース

所感

これを使いこなすためには VPC の勉強も必要なので、あわせてやると良さそうですね。
$0.1/回 程度の値段で安いですが、何度もするとそこそこお金かかりそう。