ToC
Amazon EventBridgeとは…
Amazon EventBridge は、CloudWatch Eventsと呼ばれていたサービスをベースに
機能拡張されたサービスです。
イベントソースとしてAWSサービスを指定するだけでなく、独自アプリケーションやサードパーティの
イベントソースを利用できるサービスです。
Amazon EventBridgeのリソースについて調査と実験をしてみました。
リソース関連図
EventBridgeを構成する主要なリソースは、大きく分けると下記の５つになります。
- Event Source
- Event
- Event Bus
- Rule
- Target
Event Source
Eventを発行する元のリソース。大きく分けて下記の３種類のソースを設定可能。
- AWSサービス: EventBridgeに対応した AWSサービス
- サードパーティサービス:
- Put EventのAPI
Event
- 通知の実体
- イベントパターン で定義された構造のJSON形式の情報
Event Bus
- 発行されたイベントを受信するリソース
- 別のAWSアカウントのEventSourceからの受信も可能。（リソースポリシーにより、アクセス元を制御）
- Event SourceがAWSサービスのイベントは、 ”Default” のEvent Busに通知される
Rule
- 受信したEventの条件フィルタリングを行い、Targetのアクションを実行するリソース
- Eventのメタ情報に対して、フィルタリング条件(Event Pattern)を作成
- 1つのルールに対して複数の Target が設定可能(ルールあたり最大5つまで)
- ルールごとにEnable/Disableの設定が可能
Target
Cloud Formation 対応
EventBus と Rule がCloud Formation に対応しています。
調査のために下記のような構成を作成して、独自アプリケーションのイベントを通知してみました。
参考までに作成したCloud Formationのテンプレートも掲載しておきます。
AWSTemplateFormatVersion: "2010-09-09"
Description: Event Bridge Template
Parameters:
CanonicalName:
Type: String
Default: my-canonical-name
AllowedPattern: "[-a-zA-Z0-9]*"
ConstraintDescription: ""
ActionLambdaFunctionName:
Type: String
Default: my-lambda-function
Resources:
EventBus:
Type: AWS::Events::EventBus
Properties:
Name: !Sub "${CanonicalName}-event-bus"
EventRule:
Type: AWS::Events::Rule
Properties:
Description: "EventRule"
EventPattern:
source:
- "net.my-super-company"
detail-type:
- "my-super-detail-type"
account:
- !Ref "AWS::AccountId"
detail:
key1:
- "value1"
State: "ENABLED"
Targets:
-
Arn: !Sub "arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${ActionLambdaFunctionName}"
Id: "TargetFunctionV1"
PermissionForEventsToInvokeLambda:
Type: AWS::Lambda::Permission
Properties:
FunctionName: !Sub "arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${ActionLambdaFunctionName}"
Action: "lambda:InvokeFunction"
Principal: "events.amazonaws.com"
SourceArn: !GetAtt EventBus.Arn
Outputs:
EventBus:
Value: !Ref EventBus
EventBusArn:
Value: !GetAtt EventBus.Arn
EventRule:
Value: !Ref EventRule
PermissionForEventsToInvokeLambda:
Value: !Ref PermissionForEventsToInvokeLambda
イベントの実行テスト
リソースの配備が完了したところで、早速イベントを通知してみます。
イベントをCLIで発行して、Lambdaに通知されるeventの詳細を確認してみます。
PutEventのCLIで発行された EventId が Lambdaにも引き継がれるため、アプリケーションでは
EventIdを使って一意性の特定等を行うことができそうです。
2020/2のアップデートで、EventPatternに数字型のクエリー処理や文字列の前方一致などの
機能も追加されたようなのでイベントのフィルタリングの幅が広がりそうです。
## 実行コード
$ aws events put-events --entries file://test-events.json
{
"FailedEntryCount": 0,
"Entries": [
{
"EventId": "05962799-3038-ce67-f891-295a8d3bb704"
}
]
}
## test-events.json
[
{
“Source”: “net.my-super-company.my-app”,
“EventBusName”: “default”,
“Detail”: “{ \”key1\”: \”value1\”, \”key2\”: [\”array-value-21\”, \”array-value-22\”] }”,
“Resources”: [
“resource1”,
“resource2”
],
“DetailType”: “my-super-detail-type”
}
]
## Ruleに設定したEventPattern
{
"account": [
"123456789012"
],
"source": [
{
"prefix": "net.my-super-company"
}
]
}
## Lambdaで受け取ったEvent
{
"version":"0",
"id": "05962799-3038-ce67-f891-295a8d3bb704",
"detail-type": "my-super-detail-type"",
"source": "net.my-super-company.my-app",
"account": "123456789012",
"time": "2019-12-22T07:32:48Z",
"region": "us-west-2",
"resources": [
"resource1",
"resource2"
],
"detail": {
"key1": "value1",
"key2": [
"array-value-21",
"array-value-22"
]
}
}
最後の方はコードだらけになってしまいましたが、Amazon EventBridgeをうまく使って
イベント通知になにかの処理を足すような自動化が捗りそうです。
参照
- Amazon EventBridge
- Amazon EventBridgeに対応したAWSサービス
- Amazon EventBridgeイベントパターンサンプル
- Amazon EventBridgeのTargetとして利用可能なAWSリソース
- Amazon EventBridgeのアクセスRole
- Amazon EventBridgeのCloud Formation対応
変更履歴
- 2020/03/17: Roleの記載誤りを修正