omuronの備忘録

個人的な備忘録

（小ネタ）Nat Gateway is not available in this availability zone ...

小ネタ AWS

CloudFormation で Nat Gateway 作成時にエラーが発生しました。

Nat Gateway is not available in this availability zone

そのまんまですが、Nat Gateway がサポートされていないアベイラビリティゾーンがあります。

原因

docs.aws.amazon.com

制約のあるアベイラビリティーゾーン (当社による拡張に制限があるゾーン) で NAT ゲートウェイを作成しようとしている可能性があります。

解決策

これらのアベイラビリティーゾーンでは NAT ゲートウェイはサポートされていません。別のアベイラビリティーゾーンで NAT ゲートウェイを作成し、それを制約のあるゾーンのプライベートサブネットで使用できます。リソースを制約のないアベイラビリティーゾーンに移動し、リソースと NAT ゲートウェイのアベイラビリティーゾーンを同じにすることができます。

違うアベイラビリティゾーンで作成するしか無いですね。
AWS アカウントによって、論理的なアベイラビリティゾーン（ ap-northeast-1a など ）と、物理的なアベイラビリティゾーン ID（ apne1-az1 など ）は異なるので一概にどのアベイラビリティゾーンで使えないかは事前にわかりにくい仕様です。
素直に別のアベイラビリティゾーンを指定して再構築しましょう。

「AWSの基礎を学ぼう 第四十四回 Amazon TransitGateway」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

フォージビジョン様提供の Zoom になって参加者枠に余裕が出ました！
専用線を準備しないと勉強できない TransitGateway です。

セッション

Amazon TransitGateway

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

Amazon TransitGateway

  • リージョナルサービス
    • リージョン単位で設定
  • 50Gbps, 数千の VPC / VPN / Direct Connect 接続可能
  • TGW 用語
    • アタッチ： VPC/VPN の接続をおこなうこと
    • アタッチメント： 上記アタッチにより作成
    • アソシエート： アタッチメントを TGW の Route Table に紐付け
    • プロパゲート： TGW の Route Table へ経路を伝搬させること
      • TGW -> VPC のみ、VPC -> TGW は個別 VPC で設置
  • TGW で VPC をたくさんまとめれる
    • VPC をたくさん使わないならお金だけかかる
  • MTU はオンプレ間とは1500固定
    • TGW での VPC 間は8500まで伸ばせる
  • TGW を中心に配置し、リージョナルルーターとして経路を集中管理
    • セキュアにしやすい構造になる（使うだけでセキュアになる訳ではない）
  • Shared services の VPC を一度経由させることでセキュリティ管理させる
    • VPC どうしを直接通信させないルートテーブルを作る

AWS HyperPlane

  • VPC を司る基盤
  • AZ 単位で NIC を生成する

Transit Gateway 冗長化

  • Direct Connect を2本引く
    • TY1 と OS1 など
  • ソフトウェア VPN を準備しておく
    • 物理線障害時向け

Transit Gateway アタッチメントの設計

  • TGW アタッチメント ENI に専用サブネットを作る
    • サブネットの数は AZ に2個固定ではないので増やせばいい

所感

後半は「へーこういのがあるんだ」という感じで聞くだけになってしまいました。
Transit Gateway は使うことが今の所なさそうな気がするので、とりあえず「こういうのがあるんだ」というレベル感で覚えておこうと思います。

「AWSの基礎を学ぼう 第四十三回 Amazon Route 53」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

DNS 全般の話と、Route53 に特化した話があったので、Route53 の部分をメインでメモ。

セッション

Amazon Route 53 / Amazon Route 53 Resolver

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

DNS とは

  • Name Server
  • Full Service Resolver
    • いわゆる一般的な DNS サーバー
  • Stub Resolver
    • ネイテイブアプリなどが利用
  • Forwarder
    • 問い合わせ元で処理をかえる
    • 社内向けと社外向けとか
      • for Internet / for VPC / for On-premise

Route53 Hosted Zone

  • Public Hosted Zone
    • インターネット向け
  • Private Hosted Zone
    • VPC / On-premise 向け

Route53 Resolver

  • VPC 標準の DNS サーバー（ Forwarder + Full Service Resolver ）
  • VPC 作る際にデフォルトで有効化されている
    • VPC 毎に有効無効設定可能
    • IP アドレスが自動で DHCP で配布される
  • FQDN で必ずアクセスすべき
    • IP アドレスが変わってもアクセスできるようにしておく

Route53 Resolver for Hybrid Clouds

  • エンドポイントが２つできる
    • Outbound/Inboud の ENI が作成される
      • SG で53ポートを開ける必要あり
    • Outbound
      • AWS からオンプレ向けの名前解決
    • Inboud
      • オンプレから AWS 向けの名前解決

レジストラ連携：ドメイン登録

Zone Apex

ルーティングポリシー

  • シンプル
  • 荷重
    • 比率で分配
    • A/B テストや B/G デプロイに利用
  • フェイルオーバー
    • ヘルスチェック結果で利用可能なリソースへ分配
  • 複数値回答
    • 複数まとめて返すのでユーザー側で処理
    • yahoo とかが利用している
  • レイテンシー
    • 近い場所を返す
    • 一定期間中に実行されたレイテンシーの測定値に基づくので変化していく
  • 位置情報
    • IP アドレスベースの位置情報の近いものを返す
  • 物理的近接性

DNSSEC

  • 攻撃者が違う DNS をスプーフィングしたときに防ぐ機能
    • アプリが対応してないと意味がない
    • 企画倒れ？

所感

この勉強会では Chime の250人制限が問題になっているので
「Zoom エンタープライズで500人入れるので持ってる人は貸して欲しい。」 とのこと。
特典がすごい！必ず聞ける＋亀田さんが特別講演してくれるそうです！

逆引きの読みは「ぎゃくびき？」「さかひき？」と話題になりましたが、亀田さん以外は「ぎゃくびき」と読んでいるみたいなので、亀田さんも今後は「ぎゃくびき」派へ。

Route53 のおかげで DNS がとても簡単に SLA 100% で扱えるようになりました。
AWS のリソースはエイリアスレコードで登録しておくことだけ抑えておけば、通常の利用では問題ないと思っています。
最近は、VPC プライベートゾーン向けも活用して、エンドポイントとなる Interface と AWS リソースとなる Repository の物理層を依存させないように気をつけるようにしています。

「JAWS-UG 初心者支部#37 しくじりLT大会続き」 #jawsug_bgnr 受講メモ

AWS 勉強会

jawsug-bgnr.connpass.com

前回 の亀田さんセッションの続きが気になったのでそこだけのメモです。

セッション

15分LT：AWS勉強中に勘違いしがちなこと しくじりリターンズ

講師：AWSJ 亀田 治伸さん

Lambda はバッチ処理基盤

  • 物理 -> 仮想 -> コンテナ -> サーバーレス
    • Bare Metal -> VM -> Container -> Serverless
  • バッチ処理
    • 元はメインフレーム用語
    • ひとまとまりのデータを一括して処理する方式
    • 日本では夜間バッチをイメージ
      • 数珠つなぎで処理していく
      • イベントドリブンじゃなくて時間で動くなど
  • Stateless、イベントドリブンを意識
    • 冪等性も大事
    • ステートを引き回したければ Step Functions / MWAA のいずれかを使う

CloudFront の通信費用８倍

  • GB 単位の単価
    • ビットレート(bps) で計算する場合は bit なので 1/8 する必要あり
    • bit と byte の違い

インスタンスストアってなに？

  • EC2 内のストレージ
    • EC2 Hosts のストレージ
    • EC2 Shutdown で消える
    • 無償！
  • ストレージ(EBS) や ネットワークは仮想化されている
    • EC2 内でネットワークコマンドを叩くと VPC の正しい情報は取れない
    • ネットワークは aws コマンド利用する必要あり

所感

今でこそ Fargate でやっちゃいますが、Lambda って cron で動かしたりもできるしバッチ処理基盤と考えてしまいそうですね。
「バッチ処理とは」も含めて用語は勘違いしないようにしないと。

インスタンスストアってすっかり使わなくなりましたね。
EBS も含めてスペックが上がったしあまり困ることがなくなった感じでしょうか？
無償なので上手いこと使うといいのですが、消えて事故りやすいので注意は必要です。

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

AWS 勉強会

JAWS-UG朝会 #21

jawsug-asa.connpass.com

セッション

セッション① URL 正規化処理を Lambda@Edge から CloudFront Functions に移行した話

講師：伊藤嘉洋さん

speakerdeck.com

前提

  • CloudFront + S3 で静的サイト配信が前提
  • L@E で URL 正規化していた
    • この処理を CF Functions へ移行
  • Viewer Request 時に実行
    • / 終わり URL 時に /index.html 補完
    • /index.html を明示的に着た時は / にリダイレクト
    • / が無い場合は / にリダイレクト
  • URL 統一で SEO 対策にもなる

CloudFront Functions

  • Node.js -> JavaScript
    • EC 5.1 準拠
  • メモリ2M
  • 最大実行時間 1msec
    • L@E では 0.7msec 程度の処理時間だったので移行できるだろう
  • CLI v1.19.64 以降 / v2.2.2 以降

CLI

  • aws cloudfront
    • describe-function
    • create-function
    • test-function
    • publish-function
  • CF との紐付けは update-distribution 利用

セッション② Amazon SQSを勉強しなおしてみた

講師：藤田直幸さん

SQS 概要と設定

  • メッセージキューイングサービス
    • AWS 最初のサービス
    • プル型
      • コンシューマーがポーリングする必要あり
      • SNS はプッシュ型
  • 標準キュー
    • トランザクション数無制限
    • 同じメッセージが2回配信可能性あり
      • DynamoDB で重複防いだり、冪等性たもつようにしたり対策がいる
  • FIFO キュー
  • ポーリング
    • ショートとロング（デフォルト）
      • すぐ返すか一定時間待ってから来た場合に返すか
  • 可視性タイムアウト
    • 受診時に他のコンシューマーから見えなくする時間

ハンズオンやってみた

  • ファンアウト構成
    • SNS から SQS 2つになげて、 Lambda 2つで並行処理が可能に

LT

LT① AWS WAF Bot Controlを触ってみたので紹介します！

講師：中野雅之さん

slides.com

WAF

Bot Control

  • マネージドルールの1つ
  • Bot からのアクセスか判断
    • Bot の傾向を知ることができる
  • WAF + Bot Control それぞれ課金される
  • ログは Kineesis Firehose で取得

LT② Amazon Linux 2 を試してみた

講師：伊藤真司さん

AL2

  • systemd が動いている
  • ルーツは CentOS7
  • リモートデスクトップ接続できる
  • EC2 Serial Console (New!)
    • トラブルシュートできる
  • rpm パッケージが S3
    • インターネットアクセス不要
    • VPC エンドポイント設定は必要
  • SSM エージェント、aws コマンドが導入済み
  • 2023/06 までサポート
    • それ以降未定なのでどうなる？

LT③ securityhubとeventbridgeの関係性を調べてみた

講師：株式会社ターンアンドフロンティア 富松 広太さん

www.slideshare.net

Securityhub

  • セキュリティ系サービスから Security Hub へ集約
  • CloudWatch などへ検出結果を流す
    • Event 製造機
  • Security hub を通すと ASFF に整形される
    • 直接 EventBridge に連携できるものも通すことでフォーマット ASFF に統一できる
  • リソース毎に Event 設定を変えれる
    • 一度吟味すれば通知を止めたりできる
  • 複数アカウントの制御はカスタムアクションで可能
  • リージョナルサービス
    • リージョン切り替え面倒
      • SIEM on Amazon Elasticsearch Service を利用してまとめて見れる

所感

CloudFront Functions はすでに よっしーさんブログ を参考にして実装していました。 L@E より値段的にも安くなるし、同じ CloudFront 内で管理ができるからわかりやすくなっていいですね。

SQS は、SAA 取得の時に勉強した記憶を思い出しました。 普段利用していないから内容を忘れているところもあり、良い振り返りになりました。

WAF のマネージドルールの設定はまだちゃんと見てないので Bot Control も含めて調べる必要がありそうです。

AL2 のサポート期限の短さはなんとかしてほしいですよね。 自分で使う分にはなんとでもなる気がして気にしなくても良いのですが、納品している人は大変そう。

Security Hub は全く知らなかったので、概要を掴むことができました。 EventBridge 自体も使ってないからこれも含めて慣れていかないと。

「はてなブログ DevBlog Online Meetup」 #devblog 受講メモ

勉強会

blog.hatenablog.com

3社に訊く、技術ブログの活用・運用法

  • モデレーター
  • 登壇者
    • エムスリー株式会社 執行役員VPoE/PdM 山崎聡氏
    • 富士通株式会社 研究本部 先端融合技術研究所 主任研究員 横田耕一氏
    • LINE株式会社 Developer Successチーム 桃木耕太氏

セッション

企業によるブログを活用した技術情報のアウトプット

ブログの目的

  • エムスリー
    • 圧倒的採用目的
    • テック系で知られてなかった
    • 書くのを楽しむ人が増えた、エンジニア同士のコミュニケーションにも
    • 月7-14本
  • 富士通
    • 技術ブランディング目的
    • ビジネス寄りとは切り離して純粋に技術寄り
    • 月1-2本
  • LINE
    • 採用とブランディング
    • 知ってもらうため
      • 会社は知られてても中で何しているかは知られてない
    • 月1-7本

KPI

  • エムスリー
    • 明確にはない
    • なんとなく減った時に盛り上げるようにリーダーが促す
    • ブログを書くのも社への貢献
    • 仲間を増やすのが KGI
      • 面接でも「ブログ見ました」が増えているのでいい感じ
    • 評価には組み込んでいる
      • 採用貢献を目標設定に持っている人などにとっては書くことが KPI だったりする
  • 富士通
    • 明確な KPI は止めとこうになった
      • 数字を追うのが目的にならないように
      • 計測はしている
    • ブログを出すことに価値がある
  • LINE
    • PV とかは追ってない
    • ブログの何がトリガーかは追えないのでやらない
    • 数字を追うよりフワッとしてるほうがいい

立ち上げ・運用のコツ

  • エムスリー
    • 立ち上げ
      • 認知度をどうやってあげるかから議論
      • エンジニアにリーチできるからはてなを利用
      • はてなランキングに乗ると社内も盛り上がる
    • 運用
      • ブログに書ける新しいことをやる
        • 続けると文化として定着
        • 新しいことを聞くとブログ化へ
      • ブログを書くことは負担なので気持ちよく書いて欲しい
        • ゴールは採用を押さえれば好きなことを書いていい
        • エンジニアのやらされ感をなくす
      • 公開時間は昼前の11時とかにして流入増を狙う
      • 品質管理はSlackチャンネルで公開していいかの観点だけチェックをする
        • 山崎取締役が直接見ているので経営陣への説明責任は問題なし
        • 8割ぐらいでドラフトをあげて、みんなでレビューして面白くする
  • 富士通
    • 立ち上げ
      • 何故やるのかを議論
      • ブランディング、セキュリティ的なことを中心に調整
      • 最後までやりきる
      • エンジニアはてぶと親和性が高いからはてなを選んだ、安いのもある
    • 運用
      • 執筆メンバーが固定化してしまうのが問題
      • 品質管理は部署内でOKなら良い
        • 一人称で書いて、自分の気持ちを出すのが大事
      • 月曜木曜がPV増狙える
  • LINE
    • 運用
      • アウトプットすることに価値がある
        • 出すほどじゃないとエンジニアが尻込みするのは課題
      • 組織によって積極的な場合とそうじゃない場合のムラがある
        • 現場が出したくても上が出したくないとか逆のパターンとか
        • 組織が大きいので文化のムラが出ている
      • 広告で流入を増やす
        • 出して終わりにしない
      • 品質管理は課題、ガイドラインを上げるとモチベが下がる

企業による技術ブログの価値

  • エムスリー
    • toC だが医者じゃないと見れない製品
      • ブログを書かないと技術力を見せれない
      • 何の会社か知ってもらうため
    • YouTube やカンファレンスに登壇でも知ってもらえるけど...
      • ブログだからこその価値もある
      • SEO 効果
      • エムスリーを検索するとエンジニア向けの情報がでる
      • ブログは資産
        • 情報の共有のため紹介できる
        • 1次面接受かると2次面接対策でブログ読んでもらえたり
  • 富士通
    • 大きな会社で一人ひとりが見えにくい会社
    • 具体的にやっていることを外に見えるようにしたい
    • 発信したい人を止めずにアウトプットの場を作る
    • ブログ以外はTwitterやプレスリリースはあるが...
      • ソフトを書いている人に届けるために
      • 書くことにより社内でも知ってもらえる
    • 検索で流入して知りたかったことを自社が取り組んでいることがわかる
  • LINE
    • LINE アプリのメッセンジャー機能は知られているけどそれだけじゃない
    • 知られてない機能も多いのでその差を埋めるため
    • エンジニアに取って価値があって伝わればいい
      • 日本語がおかしくても問題ではない

所感

「ブログは資産！」名言ですね。
技術ブログは継続的に続けないと逆効果になっちゃうので、気軽に取り組むのは難しいと思います。
エンジニアな文化でアウトプットを喜んでできる仲間が沢山いないと、スタートラインに立つこともできなさそうです。

「はてなブログ for DevBlog」 600円/月で安い！
はてな界隈にリーチできるし、技術ブログ始めるのに選ぶのもわかりますね。

「AWSの基礎を学ぼう 第四十二回 AWS Network Firewall のおさらい」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

え、セキュリティグループとは違うの？というレベルで受講しました。

セッション

AWS Network Firewall のおさらい

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

AWS Network Firewall

AWS Network Firewall 機能一覧

  • パケットフィルタリング
    • ステートレス設定
    • ステートフル設定
    • Deny ファースト
      • どっかで禁止されてればそっちが優先
  • 見える化＆レポート
    • CloudWatch、flow log, Kinesis Firehose...
  • 一元管理
    • CFn, Terraform...

AWS Network Firewall 概要

  • VPC のサブネットごとにエンドポイントを準備する必要あり
  • Network Firewall 専用のサブネットを切ることをおすすめ
    • Firewall Subnet - Public Subnet - Private Subnet
    • いわゆるオンプレでの DMZ ライクな実装

AWS Network Firewall 設定

  • Firewall
  • Firewall endpoint
  • Firewall subnet
  • Rule group
  • Firewall policy
  • Rule group capacity
    • ステートレス : 10,000
    • ステートフル : 30,000
  • Stateless 5-tuple filter
  • Stateful 5-tuple filter
    • 優先度は指定不可、パスルールが優先
    • 許可と拒否を併記する場合、許可が優先される
  • Stateful Dmain list filter
  • Stateful Suricata compatible IPS rule group

通信プロトコルとしてのステートフル/ステートレスと通信制御の観点でのステートフル/ステートレスの話を混ぜてしまうと混乱を招くとのこと。

SNI と Encrypted SNI

  • SNI : 1台で複数の異なる証明書を利用する

所感

恥ずかしながら、AWS Network Firewall 全然知らずに受けました。 セキュリティグループと勘違いしてた。

DMZ を配置するような感じで利用できるんですね。
セキュリティを集中管理し、ログもちゃんと分析するには準備したほうがいいのでしょうが、そのレベルに達するにはまだまだ修行が必要そうです。