継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

AWS WAF Classic に Rule で複数条件を指定するとどんな挙動を取るかを確認した

タダです.

マネージドサービスの挙動はドキュメントだけでなく動かして運用してみて理解できることや実感できることが多いのではないでしょうか.AWS WAF Classic の挙動を理解する機会があったのでこの記事で整理していきます.

今回のケースの詳細

WAF のホワイトリストのルールを作り,そこにIP一致条件を複数指定して特定のIPアドレスからのリクエストを許可する設定を意図した環境があるとします.

f:id:sadayoshi_tada:20200328151745p:plain

WAF ルールの中身

WAF ルールの中身を見ると下の画像のように複数条件が定義されています.条件との間にあるAndという表記を覚えておいてください.

f:id:sadayoshi_tada:20200328212004p:plain

さて,この設定で WAF の環境にリクエストを送った時にルールに定義している条件に一致するリクエストはあるのでしょうか? 結論からすると,マッチする IP アドレスからのリクエストはないです.つまり,ルール2つに両方マッチする IP アドレスからのリクエストが同時に送られることないので,マッチしないことになります.

ホワイトリストに定義できるがブロックされる原因

ホワイトリストのルールが定義できるが挙動としてはマッチしないリクエストとして評価されないのはなぜでしょうか? その理由はAnd条件にあります.AWS WAF Classic の仕様ではRule の判定はAnd条件,条件に全てマッチしないとリクエストが通らないような判定の挙動となるためです.そのため,2つの IP アドレスが一致するリクエストがない限り通らないことになります.AWS WAF Classic で事象を回避する場合は,リクエストが通っている Rule 1つに全て条件を包含するか,別の Rule にして分けるのが対策となります.ちなみに,AWS WAF v2 ではOR条件を指定できるようになっているため柔軟な制御が可能になりました.

まとめ

AWS WAF Classic Rule の判定条件の挙動を理解する機会になった事象と情報を整理しました.新しい AWS WAF も今後使っていく時にナレッジができたら記事にしていきたいと思います.

『Amazon Builder's Library』オンライン輪読会 第7回開催レポート

タダです.

Amazon Builder's Library」オンライン輪読会の第7回目を開催しましたのでレポートします.

開催経緯

開催の経緯は, kdnakt さんがまとめてくれています. kdnakt.hatenablog.com

第7回の記事

今回の輪読は,[分散システムのリーダー選挙]を選びました.オライリー分散システムデザインパターンを買って積読になっていたのでこの機会に勉強したいと思い,このテーマにしました.

aws.amazon.com

資料

所感

分散システムの文脈でリーダー選挙って言われてどんなものなのかや Amazon が使っている「リース」がどんなものかを理解するためにそもそも分散システムの入門情報として次の資料を参考にさせていただきました.

www.slideshare.net

www.slideshare.net

gigazine.net

リーダー選挙のメリットとデメリットの部分で,デメリットを回避するためにシャーディングを使うことが紹介されていた理由も皆さんのおかげで理解が深まりました.シャーディングによって例えば1000あるデータを10個のキーで分割した場合,たとえサーバーに障害があってもデータの損失などの影響範囲が小さくすることに役立つためと理解しました.

輪読会中に参考させていただいた記事 qiita.com

また,Amazon がどうリーダー選挙しているかや事例を踏まえて少し自分の中でリーダー選挙の理解が深まりました.ただ,全体としてリーダーをどう選ぶかやロックをどう保持するかを確認する方法等は実装してみないと想像の域を出ないので「分散システムデザインパターン」を読みつつ手を動かして理解を深めたいです.

まとめ

分散システムのリーダー選挙」輪読会のレポートでした.次回は「アベイラビリティーゾーンを使用した静的安定性」を読みます.担当はkdnakt さんです.よろしくお願いします!

aws.amazon.com

20200323 追記

シャーディングを利用する目的が耐障害性を高めるためと行った記述をしましたが、誤りでしたので文章を修正しました. シャーディングでデータを分割はしていても耐障害性向上に役立つわけではなく,データの損失影響範囲を小さくするのに役立つと修正しています.

過去の開催レポート

『The Amazon Builder's Library』オンライン輪読会 第1回開催レポート kdnakt.hatenablog.com

Amazon Builder's Library』オンライン輪読会 第3回開催レポート sadayoshi-tada.hatenablog.com

『The Amazon Builder's Library』オンライン輪読会 第5回開催レポート kdnakt.hatenablog.com

プロキシ環境で 別アカウントの S3 へ VPC エンドポイント経由でアクセスする

タダです.

前回記事同様プロキシ環境で EC2 から AWS CLIVPC エンドポイント経由での別アカウント S3 につなぐ対応を行なったのでこの記事でその内容をまとめます.

関連記事 sadayoshi-tada.hatenablog.com

結論

接続元の EC2 の環境変数に次の設定を行って S3 への通信は VPC エンドポイントのみを経由するようにしました.

HTTP_PROXY=http://[プロキシの URL]
HTTPS_PROXY=http://[プロキシの URL]
NO_PEOXY=s3.ap-northeast-1.amazonaws.com,169.254.169.254

ドキュメントに記載の通り,VPC エンドポイントはアカウントまたぎであっても AWS 内部ネットワークを通じて対象のバケットに到達する仕様になっているので,セキュリティグループのアウトバウンドを解放してルートテーブルに S3 への経路を定義しておけばネットワークの設定は事足ります.

[ドキュメント抜粋]

エンドポイントには、Amazon S3 リソースにアクセスするエンドポイントの使用を管理するポリシーがあります。デフォルトのポリシーでは、任意の AWS アカウントからの認証情報を使用して、VPC 内のユーザーまたはサービスによる、任意の Amazon S3 リソースへのアクセスが許可されます。これには、VPC が関連付けられているアカウントとは別の AWS アカウントの Amazon S3 リソースが含まれます。

ハマったこと

NO_PEOXYに S3 の接続先リージョンのサービスエンドポイント指定をしていないとプロキシに接続できないといったメッセージと 503 エラーが発生しました.トラブルシュートのページにもありますが,S3 への接続にプロキシを介する必要がない場合はNO_PROXYを指定する必要があったので指定したら事象は解消しました.

[ドキュメント抜粋]

プロキシサーバーを使用する場合、必ず VPC 接続を許可してください。S3 にプロキシサーバーを使用しない場合、S3 バケットにアクセスする際に次のコマンドを使用してプロキシサーバーを迂回します。

export no_proxy = mybucket.s3-us-west-2.amazonaws.com

aws.amazon.com

まとめ

プロキシ環境で VPC エンドポイント経由で別のアカウントのバケットにつなぐ時の対応をまとめました.アカウントまたぎでも通信が AWS 内部に閉じているのでインターネットへ通信を出したくないといった要件にも適用可能です.

プロキシ環境で AWS CLI の STS コマンドタイムアウトを回避する方法

タダです.

AWS 外との通信をプロキシサーバーに任せている環境で EC2 から AWS CLISTS のコマンド aws sts get-caller-identityタイムアウトする事象に遭遇しました.他の AWS CLI コマンドは実行できているため,STS 関連の調査を行なったのでこの記事で対応方法をまとめます.

結論

コマンドオプションで --endpoint-url で東京リージョンを明示的に指定して実行したらタイムアウトの事象が解消しました.

aws sts get-caller-identity --endpoint-url https://sts.ap-northeast-1.amazonaws.com

原因

タイムアウトが発生した環境では AWS CLI がバージョン1だったのですが,ドキュメントを確認したところ STS のサービスのエンドポイントはグローバルエンドポイントを利用するのがデフォルト設定です.

[ドキュメント引用文]

AWS CLI クライアントが AWS Security Token Service (AWS STS) と通信するために使用する AWS サービスエンドポイントを AWS CLI が判別する方法を指定します。

AWS CLI バージョン 1 のデフォルト値は legacy です。

legacy – 以下の AWS リージョンについては、グローバル STS エンドポイント sts.amazonaws.com を使用します: ap-northeast-1、ap-south-1、ap-southeast-1、ap-southeast-2、aws-global、ca-central-1、eu-central-1、eu-north-1、eu-west-1、eu-west-2、eu-west-3、sa-east-1、us-east-1、us-east-2、us-west-1、および us-west-2。他のすべてのリージョンでは、それぞれのリージョンエンドポイントが自動的に使用されます。

そのため,エンドポイントを明示的に --endpoint-url で指定するか,CLI の config で sts_regional_endpoints で指定するもしくは AWS_STS_REGIONAL_ENDPOINTS を指定して対応します.

docs.aws.amazon.com

今回, AWS CLIコマンドラインオプション--endpoit-url を指定してコマンドを実行したところタイムアウトせずにレスポンスが返ってきました.

まとめ

サービスによってはリージョンのエンドポイント指定が必要な場合があることを知る機会になったので,この記事で整理しました.同様にコマンド実行でタイムアウトが起こった時の参考になれば幸いです.

【本編一部公開!】『実践 AWS CDK - TypeScript でインフラもアプリも!』を技術書典 応援祭で公開しました!

タダです.

3/7 からの技術書典 応援祭で Silverworks は電子版のみですが,「実践 AWS CDK - TypeScript でインフラもアプリも!」を出展しました!Booth にも出しています.

技術書典 応援祭のページ

techbookfest.org

Booth

booth.pm

この記事では以前出した記事からアップデートした目次と本書を検討している方の参考情報として一部本編の内容を公開します.

目次

CI/CD の章が追加されて全体で8章構成となりました.

  • 第1章 AWS CDK の概要
    • 1.1 AWSCDKとは
    • 1.2 CDKのメリットとデメリット
  • 第2章 AWS CDK のはじめかた
    • 2.1 なぜCDKを使うのか?
    • 2.2 CDK環境の構築
    • 2.3 CDKプロジェクトの作成
    • 2.4 CDKアプリのデプロイ
    • 2.5 まとめ
  • 第3章 TypeScript 入門
    • 3.1 Playgroundではじめよう
    • 3.2 TypeScript の型
    • 3.3 クラスとオブジェクト
  • 第4章 Step Functions 入門
    • 4.1 概要
    • 4.2 ステートマシン
    • 4.3 ステートへの入出力
  • 第5章 感情分析システムを作ろう
    • 5.1 システムの概要
    • 5.2 プロジェクトの作成
    • 5.3 入出力バケットの作成
    • 5.4 メール通知の実装
    • 5.5 ワークフローの作成
    • 5.6 入力バケットとワークフローの連携
    • 5.7 タスクの作成
    • 5.8 ワークフローを組み立てよう
    • 5.9 ソースコート
  • 第6章 AWS CDK のデバッグとテスト
  • 第7章 AWS CDK の CI/CD
    • 7.1 CI/CD概要
    • 7.2 CDK における CI/CD パイプライン
  • 第8章 AWS CDK Tips
    • 8.1 AWS Core モジュール よく使う機能
    • 8.2 スタックの呼び出し時にカスタム値を渡す
    • 8.3 リソース定義の分割
    • 8.4 環境によってコンテキスト値を変更
    • 8.5 機密情報の管理
    • 8.6 SAMCLIとの連携
  • 付録 A
    • A.1 CDK CLIコマンド
    • A.2 本書で利用した AWS サービス
    • A.3 参考文献

本編一部公開

1章,2章,5章の内容を一部を公開します!

第1章 AWS CDK の概要

AWS CDK は、AWS 上のインフラ構成をプログラミング言語で定義し、CloudFormation を通じてデプロイするためのフレームワークです。一般的なプログラミング手法が利用可能 なため、開発効率の向上が期待できます。本章では、AWS CDK の概要を説明します。

1.1 AWS CDK とは

AWS CDK(以降、CDK)は、AWS 上のインフラ構成をプログラミング言語で定義し、 CloudFormation を通じてデプロイするためのフレームワークです。対応しているプログラミ ング言語は、TypeScript、JavaScriptPythonC#Java です。インフラ構成をプログラ ミング言語で定義できるため、アプリケーションからインフラまで一貫した開発体験が得られます。 CDK は GitHub 上でオープンソースとして公開されており、ライセンス費用がかかりま せん。無償で利用出来ますが、CloudFormation と同じく、デプロイしたリソースの利用料に 対して料金が発生します。

CDK の主要なコンポーネントとして「Core Framework」、「Construct Library」、「CDK CLI」があります。

1.1.1 Core Framework

Core Framework は CDK のコアコンセプトです。CDK アプリケーションは、App、Stack、 Construct の 3 つの要素で構成されます。Construct は抽象化された AWS リソースを表し ます。Construct は、他の Construct を含むことが可能なため再利用しやすく、Construct は Stack に包含されています。Stack は更に App に含まれる関係となります。

f:id:sadayoshi_tada:20200309001423p:plain

App

App は CloudFormation テンプレートの生成とデプロイに利用する最上位要素です。App は複数の Stack とその依存関係を定義します。

Stack

Stack は CloudFormation スタックに該当し、Stack と CloudFormation は 1:1 で対応し ています。デプロイは Stack 単位となります。

Construct

Construct は Stack に作成される AWS リソースを指します。後述する「Construct Li- brary」を使用して Stack に AWS リソースを定義することが可能です。

上記 3 つの要素を具体化してみましょう。例えば、Amazon S3 および Amazon SQS のリ ソースを作りたい場合、Construct でそれらのリソース定義を行い、Construct をまとめた Stack、その上位である App から CloudFormation テンプレートを生成します。生成された テンプレートを使って、CloudFormation で AWS リソースをデプロイします。

f:id:sadayoshi_tada:20200309001559p:plain

1.1.2 Construct Library

Construct Library は Construct で作成する VPC や EC2 等の AWS リソースに対応 したライブラリです。Construct Library はパッケージマネージャーで提供されています。 Construct Library には次の 3 つの種類があります。

  • High-level Construct - intent-based API
  • Low-level Construct - CFN Resource
  • Patterns

High-level Construct - intent-based API

High-level Construct は、よく利用される AWS リソースを抽象化したライブラリです。便利なデフォルト値を提供してくれているため、CDK の開発にはこのライブラリを利用するの が良いでしょう。例えば、「Bucket」クラスの「addLifeCycleRule」メソッドを使用すること で、ライフサイクルルールが適用されたバケットを定義可能です。ただ、すべてのリソース が High-level Construct に対応しているわけではないため、使いたいリソースの対応状況は API リファレンスの確認が必要です。

Low-level Construct - CFN Resource

Low-level Construct は、Cfn プレフィクスがついたライブラリで CloudFormation で利用 可能なすべての AWS リソースを生成することが可能です。例えば、「s3.CfnBucket」と定義した場合は、「AWS::S3:Bucket」を表します。Low-level Construct を利用する場合、すべて のリソースプロパティを明示的に指定する必要があり、High-level Construct で利用可能なリ ソースは High-level Construct で構成するのがオススメです。

Patterns

更に高いレベルの抽象化を定義するために Patterns があります。Patterns では、複 数のリソースを含む AWS の一般的なタスクの実行に向いています。例えば「aws-ecs- patterns.LoadBalancedFargateService」では、ALB を前面に構えた Fargate のアーキテク チャを構成できます。

1.1.3 CDK CLI

CDK CLI は、CDK のコマンドラインインターフェースです。CDK CLI を使用すると、 CDK アプリケーションの作成からデプロイまで行えます。CDK CLI では主に次の操作が可能です。

  • CDK アプリケーションの初期化(init)
  • 定義済みスタックの一覧表示(list)
  • Stack を CloudFormation テンプレートとして生成(synth)
  • 実行中のスタックインスタンスと 定義済みスタックの差分確認(diff) • AWS に CloudFormation スタックのデプロイ(deploy)
  • デプロイした CloudFormation スタックの削除(destroy)

コマンドの詳細は、「A.1 CDK CLI コマンド」(p.123) を参照ください。

第2章 AWS CDK のはじめかた

CDK アプリケーションは専用のコマンドラインインターフェースを利用します。なぜ CDK を使うのか、そのメリットを踏まえて CDK に必要な環境を構築します。その後に CDK アプリケーションを作成して、プロジェクトに必要な設定を行います。最後にいくつ かの CDK CLI コマンドを確認します。 本章をとおして、CDK 開発の流れをつかみましょう。

2.1 なぜ CDK を使うのか?

環境を構築をする前に、CDK を使うメリットをもう一度考えてみます。 なぜ、AWS リソースの構築に、スクリプト(SDKCLI)や CloudFormation ではなく、 CDK を使うのでしょうか? CDK は、普段使い慣れているプログラム言語で AWS リソースを記述できます。プログ ラムで記述できるということは、普段使い慣れている統合開発環境(IDE)を利用できるとい うことで、コードの入力支援やシンボル参照、リファクタリング、デバッグ実行など、多くの 便利な機能が利用できるということです。

インフラ構築の生産性を向上

これこそが CDK を使う大きなメリットといえるでしょう。CDK を学習するコストを考え ると、従来のやり方に比べて、少し程度の生産性の向上では旨味がありません。生産性の向上 を最大限に享受できる CDK 環境を考えます。

2.1.1 プログラム言語

プログラム言語は静的型付けに対応した言語を利用します。静的型付けはコンパイル時に型 チェックを行います。これに対して動的型付けは実行時に型チェックを行います。両者を整理 します。

言語 静的型付け 動的型付け
型宣言 する しない
型チェックのタイミング コンパイル時 実行時
メリット コーディング中にエラー検知しやすい 気軽に始めることができる
デメリット コード量が動的型付けに比べて増える 実行してみてエラーかどうかわかる

ここ 10 年ほどで登場した人気のあるプログラム言語を見ると、いずれも静的型付け言語 です。昔に比べてプログラム環境はどんどん便利になっています。しかし、それと同時にプロ グラムは複雑かつ肥大化傾向にあります。そのような影響で静的型付け言語の需要が増えてき ているということでしょう。

静的型付け言語であれば、IDE 上でコードの入力補完機能や静的解析ツールなどをフ ルに利用することができます。CDK で静的型付け言語に対応しているのは、TypeScript、 Java、.NET です。 この中で、「TypeScript」をお勧めします。TypeScript は Microsoft が開発した JavaScript のスーパーセットで、「静的型付け」「型推論」「Null 安全性」を備えたモダンな言語です。フ ロントエンドでは AltJS*3 として広く普及していますが、バックエンド側でも徐々に普及し つつあります。CDK 自体も TypeScript で作成されており、オープンソースとして公開され ています。また、公式の CDK サンプルも TypeScript で書かれたものが多いため、学習しや すい環境が整っています。

第5章 感情分析システムを作ろう

本章では、Step Functions を使って自然言語解析処理を実行する「感情分析システム」の 簡単なワークフローを開発します。節ごとにリソースを定義し、段階的に目的のシステムに 近づけていきます。プログラミングの要領でインフラの構築とデプロイができる様子を体感 してください。

5.1 システムの概要

本章で作成する「感情分析システム」の概要を説明します。最終形として目指すシステムの 概要図は、図 5.1 のとおりです。

f:id:sadayoshi_tada:20200309003100p:plain

テキストファイルの入出力に S3 バケットを使用します。感情分析で使う入力ファイルがバ ケットにアップロード(PUT)されたことをトリガーとして、感情分析のワークフローが実 行されます。入力ファイルは次のような JSON 形式ファイルを入力用 S3 バケットにアップ ロードする必要があります。

{
 "id": "ipxhhBgjbE4cWvLZvqZUHZ",
 "topic": "silverwokrs",
 "language": "ja",
 "content": "我々、Silverworksは技術書典8を通じてみなさんと多くのことを学び、多くの成⻑のチャンスをゲットしていきたいと思っています。共に笑い、共に泣き、共に成⻑していきましょう!"
}

ワークフローでは、大きく 2 つの処理を行なっています。1 つ目は、感情分析の実行と、そ の結果を出力ファイルとして S3 バケットに出力することです。2 つ目は、感情分析の結果の メール通知です。処理の成功と失敗を利用者に通知するようにしています。

感情分析の自然言語解析には Amazon Comprehend(以降、Comprehend)を利用しま す。Comprehend はいくつかの自然言語解析 API を公開しており、言語検出やキーフレーズ 検出などが利用可能です。今回利用するのは感情分析(Sentiment Analysis)の API です。 感情分析後の出力ファイルは次のように JSON 形式で入力ファイルのデータに sentiment および score が追加されて出力されます。

{
 "id": "ipxhhBgjbE4cWvLZvqZUHZ",
 "topic": "silverwokrs",
 "language": "ja",
 "content": "我々、Silverworksは技術書典8を通じてみなさんと多くのことを学び、多くの成⻑のチャンスをゲットしていきたいと思っています。共に笑い、共に泣き、共に成⻑していきましょう!",
  "sentiment": "POSITIVE",
  "score": {
    "positive": 0.6059253811836243,
    "negative": 0.018713347613811493,
    "neutral": 0.3752780854701996,
    "mixed": 8.320642518810928e-05
 } 
}

おわりに

本書は僕たちが体感した、CDK の良さや実務で得られた知見 や実践例を知ってもらえるように書きました.CDK に関する書籍はまだ世にないので,ネットやドキュメントだけで得られない情報をふんだんに詰め込みました. 本書を読むことで CDK に興味がある人が開発 を始めるきっかけとなったり,CDK の開発を実践していくきっかけとなれば嬉しいです.