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

awsbasics.connpass.com

CloudFront と何が違うねん...と理解が難しい Global Accelerator です。

セッション

AWS Global Accelerator

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

AWS Global Accelerator

• CloudFront のエッジサービス
  • ブラックベルトは無い
• インターネットは輻輳遅延が起きる
  • 早めにエッジロケーションで受け止めて、AWS のグローバルネットワークで効率よく配信する

AWS Global Accelerator がないとき

• 複数リージョンデプロイ時
  • Route53 で近くのリージョンへ配信
    • DNS キャッシュ問題あり
      • しばらくは古いものにアクセスする
      • Global Accelerator で回避できる！

AWS Global Accelerator: Key features

• 固定 IP 設定
  • 固定 IP でもマルチリージョン可能
  • IP Anycast 利用で全リージョンへ同じ IP でアクセスできる
    • Route53 の DNS キャッシュ問題も回避できる
    • 同じ IP で違う内部 IP に変換
• インテリジェントなトラフィック分散
• フォールトトレラントの強化
• TCP/UDP サポート
• 即時リージョンフェイルオーバー
• 詳細なトラフィックコントロール
• NLB, ALB, EIP のサポート
  • EIP が使えるので EC2 が使える

様々な機能

• 最適なエンドポイントの選択
  • 5 tuple 情報で分配
  • ALB では 5 tuple をハッシュ化してスティッキーセッションなどに利用
• トラフィックダイアル
  • 明示的に配信リージョンを指定できる
• エンドポイントウェイト
  • 荷重を指定して配信リージョンや ALB に分配
• ヘルスチェック
• Client IP Preservation
  • Client の IP をバックエンドに引き継げる
• DDoS プロテクション
  • AWS Shield 有効
• Transit Gateway + Accelerated Site-toSite VPN
• スピードテストツール
  • https://speedtest.globalaccelerator.aws

CloudFront との違い

Key Features	CloudFront	Global Accelerator
Description	L7 HTTP/S	L4 TCP/UDP
Protocol Support	HTTP(S)	TCP or UDP
Content caching	Yes	No
Routing	DNS-based	Anycast
IP	Dynamic IP, 固定 IP SSL オプション	2 global static IP, with Bring Your Own IP (/24;IPv4)
Failover	HTTP エラーコード、タイムアウト、Route53 DNS	30秒以内の origin failover, DNS TTLs に依存せず
Application hosting	S3, HTTP, Amazon MediaStore	ALB, NLB, EC2, EIP

所感

最後の表のおかげで、CloudFront との違いがとても理解しやすくわかりました。
固定 IP を利用したいために NLB を使ってたケースでは、Global Accelerator を利用することにより、より良く対応ができそうです。
CloudFront は一方通行、Global Accelerator は双方向のイメージとのこと。
DNS キャッシュ問題にならない IP Anycast がいいですね。

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

JAWS-UG朝会 #22

jawsug-asa.connpass.com

セッション

セッション① lexが日本語対応したのでAmazon Connectと一緒に使ってみた

講師：富松 広太さん

• Lex の概要
  • Chat bot サービス
• Amazon Connect の概要
  • ポチポチでコールセンターを作れる
    • GUI で分岐処理を作っていく
• Lex + Connect
  • Lex を呼び出せる = 自然な会話ができる
    • Lex で大事な情報を聞いておく (slot)
  • 後続の処理を Lambda で処理できる
    • Lambda で大事な情報を連携 (slot)
      • Slack へ送付など
• Lex v2 は Connect と連携できない

セッション② 最近のDDoS回りなど。AWS Shield threat landscape reviewより

講師：アマゾン ウェブ サービス ジャパン株式会社 松本 照吾さん

最近のDDoS回りなど。AWS Shield threat landscape reviewより from Shogo Matsumoto

www.slideshare.net

• OSI 参照モデル
  • アップセットね、デーブ（覚え方、頭文字上から順）
  • 今日は L7,L4,L3 (アプリ、トランスポート、ネットワーク)の話
• 今日は こちらの話
  • インフラストラクチャに対する攻撃は継続的に利用される傾向
    • DNSリフレクション15.5%、TCP SYNフラッド13.8%
  • アプリケーションレイヤに対する攻撃：増加傾向、検知困難
    • 処理能力を超えるWebリクエスト送信
      • DDos なのかスパイクなのか判断が難しい
  • DDos 攻撃は、1年間で53日間警告があった
    • 99%tile（全体の極少数）にあたる55件は大量トラフィック(50,000rps)
  • ゲームが一番攻撃(16%)されている
    • UDP でブロックが困難
  • "R"（ランサムウェア） DDoS が復活
    • 攻撃されたくなければ金払え
    • AWS 的にはスケールさせて防ぐが基本だが、受け止めても金かかる

LT① API Gateway からDynamoDBを直接操作してみた

講師：藤田直幸さん @amarelo_n24

zenn.dev

• 山下さん主催の「ヤマムギ」で勉強した内容
• APIG - Post(PutItem/GetItem) -> DynamoDB
  • APIG に DynamoDB への IAM 設定
  • mapping parameterでparamからキー情報を取得して JSON に変換して DynamoDB に投げる

LT③ CloudFormationへの憧れと現実

講師：運用設計ラボ合同会社 波田野 裕一さん

• CloudFormation の特徴と理想
  • 特徴
    • テキストでバージョン管理可能
    • 誰が見ても同じ構成
    • 同一のAWSリソースを作成可能
  • 理想
    • すべての AWS リソースをテキストファイルで構成
    • CFn スタックの作製や更新で実施
    • 復旧より作り直しでサービス再開
      • クラウドの特徴だから CFn でなくてもよくない？
• IaC の引き継ぎをうまく行っている話を現場で聞いたことがない
  • IaC を引き継ぐなら退職したくなる
• アンチパターンと思うところ
  • テンプレートを手書き
  • テンプレートをマスターとしてバージョン管理
  • パラメータ利用

所感

IaC の引き継ぎは世間では死ぬらしいけど「CloudFormation そんなに辛いかな？」と思っています。
納品されたのがほぼ CFn で書かれていたので、それを全部読んで何があるか把握する必要があって、それから CFn 書けるようになって好きにはなりました。
以降、プログラム書く時間より YAML と戦う時間が長くなっているのは事実ではありますが、簡単に壊して作り直せるのに便利さは感じています。
依存関係があると遡って変更していかないと駄目なのがめんどくさいのは確かで、そこは未だに辛いとは思っています。

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

awsbasics.connpass.com

AWS の中では比較的歴史も古く2008年からある CDN サービスの CloudFront です。

セッション

Amazon CloudFront

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

エッジサービス

• CloudFront はエッジロケーションから提供されるサービス
  • それ以外にも Route53, GlobalAccelerator, WAF, Shield, L@E など
• インターネット間のルーティング（利用区間）をなるべく短くする
  • AWS global network を長めにしてより安定感をだす

CloudFront

• ユーザーに近いエッジロケーションで配信を高速化
• エッジサーバーでキャッシングを行いオリジンの負荷をオフロード
  • キャッシュは必須じゃないが基本はキャッシュして高速化する
• 用語集
  • Viewer : クライアントやWebブラウザ
  • Distribution : コンテンツ配信の設定単い
    • Origin : コンテンツの提供元、S3 や VPC、オンプレなど
    • Behavior : キャッシュ動作設定、パスパターン毎に作成

リージョン別エッジキャッシュ（REC）

• ユーザーからのリクエストを REC で集約しオリジンにリクエスト
  • エッジロケーションに近い REC を利用
  • オリジンインフラの保護のため

CloudFront 設定

• Distribution
  • Route53, ACM
  • ACL, Log Bucket, CloudWatch
• Distribution 関連
  • Custom Error Responses : 500 を 200 にとか
  • Restrictions : 特定国のIPを弾く
  • Invalidation : キャッシュ削除
  • WAF 連携
• Origin
  • Custom origin
  • S3
  • Origin Group
• Behavior
  • Cache Policy, Origin Request Policy
  • Realtime Log config, : Kineesis Data Streams 経由で取得
  • Key groups

レポート

• マネージメントコンソール
• CloudWatch (数分ディレイ)
• S3
• Realtime Log (New! )
  • Kinesis Data Stremas で1分以内のログ処理が可能

Origin Shield

• リージョナルエッジキャッシュが多段化されるイメージ
• オリジンの付加をより下げることができる

カスタムオリジンのタイムアウト

• デフォルトは30秒
  • 4-60秒で設定可能
  • ブラウザは60秒がデフォルトなのでそれより短い

オリジンカスタムヘッダー

• Shared-Secret 利用で、CF からのアクセスと判断など
  • S3 へのアクセスを制限する場合は OAI を利用する
• CF を利用することで脆弱性対策（直接オリジンに攻撃させない）にもなる

Origin Group によるオリジンフェイルオーバー

• オリジンが500を返したときにフェイルオーバーさせる

Behavior : キャッシュコントロール

• GET/HEAD/OPTION がキャッシュ対象
• 単一リクエストの最大サイズは20GB
• きめ細かなキャッシュコントロール
  • ワイルドカード指定可能
    • img/* は30日
    • api/item* は10分
    • • はしない

Behavior, Cache Policy : エッジでの Gzip, Brotli 圧縮

• エッジで圧縮して、ブラウザで復元
  • ブラウザでの復元のオーバーヘッドより通信のコストのほうが大きいので効果あり

Lambda@Edge

• バージニアリージョンで作成
  • 数秒で使えるようになるが各リージョンへの伝搬はもう少し時間がかかる
• キャッシュされるエッジ側(Regional edge caches)で実行される

CloudFront Functions

• (L@Eより)超軽量処理向け
• エッジサーバー（Edge locations）で処理される

所感

CloudFront はよく使うので知っている機能は多いかなと思いながら聞いてましたが、「Egional edge caches」というのは把握してませんでした。
2016年の re:Invent で発表された機能です。

aws.amazon.com

いつものクラスメソッドさんブログ記事の解説がわかりやすく解説しております。

dev.classmethod.jp

一言で言うと「エッジロケーションとオリジンの間にもう一段キャッシュサーバ郡を組み込んだもの」と理解してよいと思います。

知っているつもりでも、新機能（といっても4年以上たちます）が追いきれてなくて、新たな勉強になって助かりました。

それ以外にも Amazon のエラー画像の犬の写真のエピソードも聞けました。
アメリカのオフィスは犬を連れていけて、社員証を発行されるのでその写真を利用しているとのこと。
プライムセール中なので、比較的エラーには遭遇しやすい時期ですね。

（小ネタ）制約のある AZ (ID: apne1-az3) の利用で RDS の起動に失敗した

6/9 の続き。
やっと DB クラスターが作成できました。

結論から言うと、制約のある AZ (ID: apne1-az3) で、インスタンスを起動していたのが問題でした。

実装方法

AWS::RDS::DBInstance の Properties にて以下の設定をしていました。

      AvailabilityZone: !Select [ 0, !GetAZs ]

!GetAZs にて利用可能な AZ を a から順番に列挙し、 !Select で0番目の要素を取得して利用するという指定です。
この結果、インスタンスの起動が ap-northeast-1a 固定となっておりました。

今回は、 ap-northeast-1a が制約のある AZ(ID: apne1-az3) だったため、インスタンスの起動に失敗し、クラスターが作成できていなかったようです。

以下の指定に変更することにより、無事に起動しました。

      AvailabilityZone: !Select [ 1, !GetAZs ] # 0 に当たる ap-northeast-1a は制約がある AZ(ID: apne1-az3)  なので使わない

原因がわかってよかったのですが、 AvailabilityZone は必須ではないため、未指定でも動作に問題はなかったと思います。

ZoneName と ZoneID の確認

現在利用しているアカウントがどの ZoneName で apne1-az3 を利用しているか否かについては、以下のコマンドで確認できます。

$ aws ec2 describe-availability-zones   --region ap-northeast-1   --query 'AvailabilityZones[].{ZoneName:ZoneName, ZoneId:ZoneId}'   --output table
----------------------------------
|    DescribeAvailabilityZones   |
+------------+-------------------+
|   ZoneId   |     ZoneName      |
+------------+-------------------+
|  apne1-az3 |  ap-northeast-1a  |
|  apne1-az4 |  ap-northeast-1b  |
|  apne1-az1 |  ap-northeast-1c  |
|  apne1-az2 |  ap-northeast-1d  |
+------------+-------------------+

!GetAZs と !Select のドキュメント

docs.aws.amazon.com

docs.aws.amazon.com

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

awsbasics.connpass.com

Zoom になったおかげで、300人を超える受講者がいました。
素晴らしい集客力ですね。

セッション

AWS Direct Connect

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

AWS Direct Connect

• （ざっくりとした説明としては）専用線接続サービス
  • AWS パートナーから購入してつなぐ
  • グローバル・サービスのためリージョンから独立している
    • Direct Connect ロケーションは AWS リージョンの障害を受けない
• ルーティングは BGP(Border Gateway Protocol) のみ
  • ISPなどの相互接続時にお互いの経路情報をやり取りするために使われる経路制御プロトコル
• 冗長化はしたほうがいいが、Active/Active にすると距離の影響を受けるので注意
  • Active/Standby として、障害時に Standby に切り替え
    • Standby でインターネット VPN 利用するのもありだけど遅くなる
• BGP テスト
  • Direct Connect フェイルオーバーテスト機能が追加されたのでテスト可能

VIF

• Connection : 物理接続
• VIF(Virtual Interface) : Connection を通して AWS にアクセスする論理インターフェース
  • VIF 単位で小分けで別 AWS アカウントに貸すこともできる

LAG

• Link Aggregation Group
• 複数の Connection を１つの VIF にできる

Direct Connect ゲートウェイ (DXGW)

• プラベート VIF を用いた接続で中国リージョン以外の VPC と閉域接続できる
• VPC 間通信が必要な場合
  • リージョン内は PrivateLink、Transit Gateway
  • リージョンまたぎは VPC ピアリング

所感

参加すると参加者向けに資料は公開されますが一般公開はされておりません。
その理由としては
「昨年は 2300+回のアップデートがあったが、資料は公開時の情報であり追従しないので一般公開はしない。AWS のドキュメントをまず見ましょう。」
とのことでした。
Zoom 利用により余裕も出たので、参加者特典の資料のためにも参加しないと！

前回の Transit Gateway に引き続き、利用することは当分なさそうな機能ですので、触りだけ覚えておくようにしたいと思います。
BGP テストできる機能が備わっているのはすごいと思いました。
障害時に障害対策が動かないケースって稀によくあるのでテスト必須ですしね。

Chatbot の話で「JAWS-UG CLI専門支部 #182R SNS入門」に登壇しました #jawsug_cli

jawsug-cli.connpass.com

JAWS-UG CLI専門支部に参加して、1年以上たったので LT で登壇しました。

ハンズオン

SNS

今回のハンズオン対象の Simple Notification Service の概要です。

• AWS のプッシュメッセージサービス
• メール / WebAPI / SQS / Mobile に一斉通知可能
• Pub / Sub モデル
  • Publish すると subscriber へ push される

ML で勝手にサブスクリプションが解除されちゃう問題

以下の対応策を参考に、認証を必要とする E メールサブスクリプションをセットアップする。

aws.amazon.com

登壇内容

まだ EMail で消耗している？
~SNS は Slack へ~

speakerdeck.com

CloudFormation YAML

スライドに使用した CloudFormation の YAML はこちらを参照ください。

github.com

Chatbot で利用できる通知

Chatbot では利用できる通知が限られている ので注意ください。
aws sns publish コマンドで SNS Topics を発行しても、Chatbot には通知されません。
利用できる Topics は以下になります。

• AWS Billing and Cost Management
• AWS CloudFormation
• Notifications for AWS developer tools
• Amazon CloudWatch alarms
• Amazon EventBridge
• Tutorial: Creating an Amazon EventBridge rule that sends notifications to AWS Chatbot
• AWS Config
• Amazon GuardDuty
• AWS Health
• AWS Security Hub
• AWS Systems Manager Incident Manager
• AWS Systems Manager

さいごに

一ヶ月半振りの登壇でした。
登壇だけでも大変なのに、運営も含めてコンスタントにこなせる方々は本当にすごいと思います。
オンラインでの登壇は、初めこそやりにくかったところもありましたが、一方的に話すだけならオフラインに比べて楽な気もしてきました。
これからもコレぐらいのペースで登壇できたらいいなと思っております。

（小ネタ）The availability zone requested is not supported by the DB Cluster ...

昨日 の続き。
今度は CloudFormation で RDB 作成時にエラーが発生しました。

The availability zone requested is not supported by the DB Cluster. Available options: [ap-northeast-1b, ap-northeast-1c, ap-northeast-1d]

こちらは トラブルシューティングのドキュメント に見つけれなかったのですが、Nat Gateway 同様に Aurora クラスターの作成がサポートされていないアベイラビリティゾーンがあるみたいです。

CloudFormation では3つのサブネットを指定していましたが、 private-subnet-2-id もしくは private-subnet-3-id のどちらか一つコメントアウトすると掲題のエラーが出なくなりました。

# DB サブネットグループ
DBSubnetGroup:
  Type: AWS::RDS::DBSubnetGroup
  Properties:
    DBSubnetGroupName: db-subnet-group-name 
    DBSubnetGroupDescription: hoge
    SubnetIds:
      - Fn::ImportValue: private-subnet-1-id
      - Fn::ImportValue: private-subnet-2-id
      #- Fn::ImportValue: private-subnet-3-id # クラスター作成に対応してない AZ？

上記の修正の結果、掲題のエラーが出なくなっただけでキャパシティエラーが発生して RDS の作成はできなかったんですけどね。

Couldn't create cluster: insufficient capacity in requested AZs

この CloudFormation テンプレートがあっているか不安になってきた。