ToC
Amazon EventBridge とは…
Amazon EventBridge は、イベントバスのサービスでエンドユーザーのアプリケーションやサードパーティサービス、AWSの各サービスから生成されたイベントを取り扱うサービスです。EventBridgeには、アーキテクチャの３つの重要な概念があります。
イベントソース
イベントを送信する元となるアプリケーションサービスのことです。
EventBridgeでは、「エンドユーザーのアプリケーション」やZendeskなどの「サードパーティサービス」、「AWSサービス」がこれらにあたります。イベントバス
イベントソースからイベントを受け取り、ターゲットに送信するためのハブとなる機能です。
EventBridgeでは、AWSが準備する「Default Bus」、ユーザーが独自定義できる「カスタム Bus」、サードパーティによって定義される「パートナーEvent Bus」の3種類があります。ターゲット
イベントの通知先になります。イベントルールにより、イベントバスに通知されたイベントをフィルタリングして、条件に合致したイベントをターゲットに送信します。 EventBridgeでは、AWSの各種サービスが設定可能です。
今回は、2021年4月に機能拡張された別のAWSアカウントや別リージョンのイベントバスへの通知について検証してみました。
検証を実施した環境
別のAWSアカウントや別リージョンのイベントバスの検証のバリエーションを確保するためにOrganization設定した2つのAWSアカウントを利用しました。 最終的な通知先のイベントバスが存在するAWSアカウント（Destinationアカウント）と送信元となるイベントバスが存在するAWSアカウント（Sourceアカウント）として、3つのイベントバスを設定しています。
- (1) 最終ターゲット１:
us-west-2リージョンのCustom Event Bus - (2) 同一AWSアカウントのイベントソース２: Destinationアカウントの
ap-northeastリージョンのDefault Event Bus - (3) 別AWSアカウントのイベントソース３: Sourceアカウントの
ap-northeastリージョンのCustom Event Bus
2021年8月時点では、ターゲットのEvent Busとして設定可能なリージョンは、us-east-1 us-west-2 eu-west-1 に限定されていました。
イベントの通知
結論から言うと、それぞれ(1)〜(3)のEvent Busにイベントを発生させたところ、最終ターゲットのEvent Busにイベントが通知されました。
最終ターゲットに通知されるイベントの内容も確認してみましたが、イベント転送元のイベントソースで取得できるイベントとデータ内容は同じようです。
{
'version': '0',
'id': '12345678-1234-5678-9012-abcdefghijkl',
'detail-type': 'cross-account-cross-region-type',
'source': 'net.example.cross-account',
'account': '123456789012',
'time': '2021-08-28T01:23:45Z',
'region': 'ap-northeast-1',
'resources': [],
'detail': {
'key1': 'value1',
'key2': 'value2'
}
}
メタ情報のaccountやregionの情報、sourceやdetailもそのまま保持されています。
ただし、idについては、イベントソースのイベントとターゲットのイベントで別のidとなっていました。
厳密にイベントを突き合わせる必要がある場合には、データのdetailにキーとなる情報を埋め込むなど検討が必要になるかと思います。
また、通知されるイベントには、イベントソースのEvent Busの名前など情報等も特に付与されていないので、
ターゲットのEvent Busでイベントの制御が混沌としないようにイベント転送元とイベント送信先での適切なインターフェイスを検討することが活用のポイントになりそうです。
ただ、これは同一アカウント、同一リージョンのEvent Busのイベント転送でも同じことが言えるので、sourceやdetail-typeをうまく活用することで制御できそうですね。
ターゲットEvent Busに設定するリソースポリシー
ターゲットEvent Busにリソースポリシーを設定することが、この機能を利用する上での最も重要なポイントになります。
下記は、同一Organizationからのイベント通知(PutEvents)を許可する際のEvent Busのリソースポリシーの設定例になります。
Organization設定していない場合には、Principalの設定でイベント転送を許可するAWSアカウントを個別に設定することも可能です。
詳細は、AWSのドキュメントイベントバスのアクセス許可に記載されています。
DestinationEventBus:
Type: AWS::Events::EventBus
Properties:
Name: 'destination-account-custom-event-bus'
DestinationEventBusPolicy:
Type: AWS::Events::EventBusPolicy
Properties:
StatementId: "CrossAccountStatement"
EventBusName: !Ref DestinationEventBus
Statement:
Effect: "Allow"
Principal:
AWS: '*'
Action: events:PutEvents
Resource: !GetAtt DestinationEventBus.Arn
Condition:
StringEquals:
"aws:PrincipalOrgID": !Ref <OrganizationId>
イベントソースのRuleに適用するRole設定
最後にRoleの設定ですが、こちらは難しいことはありません。Event bridgeサービスがAssumeして、通知先のアカウントのEvent BusへのPutEventsを許可します。
SourceEventRuleRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
Service:
- events.amazonaws.com
Action:
- sts:AssumeRole
Policies:
- PolicyName: PutEventsPolicy
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Action:
- events:PutEvents
Resource: !Sub "arn:aws:events:us-west-2:111122223333:event-bus/destination-account-custom-event-bus"
クロスアカウントやクロスリージョンでのシステム連携機能がEventBridgeに機能追加されたことで イベントソースとターゲット間で 個別に設定が必要だったものが局所化できるようになり、アプリもインフラ設定もシンプルになりそうです。