グローバルエンドポイントを使ってみる。

## はじめに

今回はバス関連の機能、グローバルエンドポイントについて調べてみました。

![スクリーンショット 2025-03-25 3.44.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/3f45fd3f-6804-40d0-addb-19f231bb8b99.png)

公式の説明については、下記の通りです。

https://docs.aws.amazon.com/ja_jp/eventbridge/latest/userguide/eb-global-endpoints.html

>Amazon EventBridge グローバルエンドポイントを使用して、アプリケーションの可用性を向上させることができます。グローバルエンドポイントを使用すると、追加コストなしでアプリケーションをリージョンフォールトトレラントにできます。

２つのリージョンに同じイベントバスを作り、プライマリリージョン側に障害が起きると、セカンダリリージョンへフェイルオーバーしたり、常に両方のリージョンにイベントを送ったりする機能です。

## 試してみます！

### グローバルエンドポイントの作成

名前は適当に。

![スクリーンショット 2025-03-25 3.44.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/7f3f6c7c-fbec-47a7-86cc-49b47e69ae88.png)

今回は東京とバージニア北部で作ってみます！

![スクリーンショット 2025-03-25 3.44.37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/a40efd42-d52b-478b-8980-a3c37068eec4.png)

次にプライマリリージョンの正常性を監視するためのヘルスチェックの指定です。

![スクリーンショット 2025-03-25 3.45.05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/d7061e68-feab-4627-b3be-d7292f028936.png)

`新しいヘルスチェック`を選ぶと、CloudFormationで環境を作ってくれます。

![スクリーンショット 2025-03-25 3.45.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/903171b5-41c1-4245-a278-41ea47700de2.png)

作成後リロードすると、指定できるようになってました。
![スクリーンショット 2025-03-25 3.48.12.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/4400f66c-8bec-4cdd-8168-ab5865c87ac8.png)

次にイベントレプリケーションの設定を行います。

コストが上がる旨の記載がありますが、１つのイベントを２つのリージョンに送信することで倍のお金がかかるよ。という意味で、特にイベントレプリケーション自体に料金がかかるわけではありません。

![スクリーンショット 2025-03-25 3.48.29.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/54c9bfb2-fcf4-4231-9556-b53da16abdb3.png)

なお、事前にセカンダリリージョン側にも同じ名前のイベントバスを作ってないとエラーになります。

![スクリーンショット 2025-03-25 3.48.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/d0f06ee0-fa59-450a-807c-a1a8e566a09b.png)

セカンダリリージョンにも同じイベントバスを作ったら無事できました！

![スクリーンショット 2025-03-27 3.56.45.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/59fdbbd8-90cc-43bb-bad0-619138ebcf49.png)

### 試してみる。

CLIを使ってイベントを送ってみます。

グローバルエンドポイントを使う場合、`endpoint-id`及び、`endpoint-url`を追加して送ります。

```console
aws events put-events \
  --entries '[{ "Source": "custom.application", "DetailType": "paid", "Detail": "{\"payment_number\": \"00001\"}", "EventBusName": "arn:aws:events:ap-northeast-1:000011112222:event-bus/Cross-Account-Bus" }]' \
  --endpoint-id 69fcv3qa03.kwg \
  --endpoint-url https://69fcv3qa03.kwg.endpoint.events.amazonaws.com \
```

なお、両リージョンはルールでSNSを通じてメールを送るようにしています。
東京リージョンは入力トランスフォーマを使い、バージニア北部は使っていません。

イベントを送ってみると、メールが２通届いていることを確認できました！

![スクリーンショット 2025-03-27 4.04.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/4ed76511-26d4-4191-98a3-3be0368bfe83.png)

### ヘルスチェックは何してるの？

グローバルエンドポイント作成時に指定するヘルスチェックは何を持って状態監視をしているかを確認してみます。

CloudFormationのスタックの説明を見ると以下のような記載がありました。

> Global endpoints health check that will fail when the average Amazon EventBridge latency is above 30 seconds for a duration of 5 minutes. Note, missing data will cause the health check to fail, so if you only send events intermittently, consider changing the heath check to use a longer evaluation period or instead treat missing data as 'missing' instead of 'breaching'.

> 翻訳：Amazon EventBridgeの平均レイテンシーが5分間にわたって30秒を超えると失敗するグローバルエンドポイントのヘルスチェックです。なお、データが欠損するとヘルスチェックが失敗しますので、イベントを断続的にしか送信しない場合は、より長い評価期間を使用するようにヘルスチェックを変更するか、欠損データを「違反」ではなく「欠損」として扱うことを検討してください。

実際に作成されているリソースを覗いてみると、CloudWatchアラームと、アラーム元にヘルスチェックを行う、Route53ヘルスチェックができてました。

![スクリーンショット 2025-03-29 4.52.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/582fb79c-840e-4124-a6c4-4a7fa9ce1515.png)

アラームの条件は`5 分内の5データポイントのIngestionToInvocationStartLatency > 3000`でした。

![スクリーンショット 2025-03-29 4.53.55.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3894042/df4667fa-7def-4e49-9d6b-84d760189b46.png)

## 最後に

可用性を高める仕組みのグローバルエンドポイントですが、イベントレプリケーションはA/Bテストみたいな検証作業にも使えそうな気がしました。

良い機能です！