![[登壇レポート] 「AWS re:Invent 2025 新機能「やってみた」報告会 ~ネットワーク・運用編~」にて「LT中にAWS Interconnect – multicloudでAWSとGoogle Cloudを繋げる」という内容でRTAに失敗しました](https://devio2024-media.developers.io/image/upload/f_auto,q_auto,w_3840/v1775229860/user-gen-eyecatch/e3lw4fv9iqoblcjorawa.webp)
[登壇レポート] 「AWS re:Invent 2025 新機能「やってみた」報告会 ~ネットワーク・運用編~」にて「LT中にAWS Interconnect – multicloudでAWSとGoogle Cloudを繋げる」という内容でRTAに失敗しました
はじめに
皆様こんにちは、あかいけです。
2026/03/24に開催された「AWS re:Invent 2025 新機能「やってみた」報告会 ~ネットワーク・運用編~」にて登壇させていただきました。
内容としてはタイトル通り「LT中にAWS Interconnect – multicloudでAWSとGoogle Cloudを繋げる」というLT中にRTAする登壇だったのですが、結論から言うとRTAは失敗しました。
ただ失敗して終わりでは悔しすぎるので、本記事では登壇内容の振り返りとRTAが失敗した原因の説明、そして後日行ったRTA再走の様子をお届けします。
登壇資料
なぜRTAは失敗してしまったのか
さて、なぜ私はRTAに失敗したのでしょうか。
登壇中、AWS Interconnect – multicloudの構築手順をライブで実行していたのですが、Google Cloud側のTransportリソースを作成するタイミングでエラーが発生しました。
エラー発生時に実行したコマンドは以下です。
$ gcloud beta network-connectivity transports create interconnect-transport \
--region=us-east4 \
--network=interconnect-multicloud-vpc \
--advertised-routes="10.1.0.0/16" \
--activation-key="$ACTIVATION_KEY"
そして発生したエラーは以下です。
(プロジェクトIDなどはマスキングしてます)
ERROR: (gcloud.beta.network-connectivity.transports.create) HttpError accessing <https://networkconnectivity.googleapis.com/v1beta/projects/XXX-XXX/locations/us-east4/transports?alt=json&transportId=interconnect-transport>: response: <{'vary': 'Origin, X-Origin, Referer', 'content-type': 'application/json; charset=UTF-8', 'content-encoding': 'gzip', 'date': 'Tue, 24 Mar 2026 10:43:49 GMT', 'server': 'ESF', 'x-xss-protection': '0', 'x-frame-options': 'SAMEORIGIN', 'x-content-type-options': 'nosniff', 'transfer-encoding': 'chunked', 'status': 429}>, content <{
"error": {
"code": 429,
"message": "Quota limit 'RegionalPerProjectTransports' has been exceeded. Limit: 1 in region us-east4.",
"status": "RESOURCE_EXHAUSTED",
"details": [
{
"@type": "type.googleapis.com/google.rpc.QuotaFailure",
"violations": [
{
"subject": "project:XXXXXXXXXXXX",
"description": "Quota 'RegionalPerProjectTransports' exhausted. Limit 1 in region us-east4"
}
]
}
]
}
}
はい、お察しの良い方はもうお気づきでしょう。
RegionalPerProjectTransportsのクォータに引っかかって、リソースの作成ができずエラーになっています。
そしてこのクォータを使い切っていた原因は、登壇前に試走した際のリソースの消し忘れです。
まとめると、「Google CloudのTransportリソースはリージョンあたり1プロジェクトにつき1つしか作成できないが、試走時のリソースが残っている状態で新しく作成しようとしてエラーになった」、というわけです。
再走してみた
悔しいので再走します。
使うのは登壇で使用したものと同じ以下のリポジトリです。
今回はもちろん事前に既存リソースをすべて削除した上で臨んでいます。同じミスは二度としません。
それでは再走結果です。
| ステップ | 構築手段 | 内容 | LAP | ラップタイム | 合計 |
|---|---|---|---|---|---|
| 事前リソース作成 | Terraform | terraform applyでAWS/GCP基盤リソースを一括作成 |
#1 | 08:39 | 08:39 |
| Interconnect作成 | GUI | AWSコンソールからMulticloud Interconnectを作成し、Activation Keyを取得 | #2 | 00:54 | 09:34 |
| Transport作成 | CLI | GCP CloudShellでActivation Keyを使ってTransportリソースを作成 | #3 | 07:13 | 16:48 |
| VPC Peering設定 | CLI | TransportのpeeringNetworkを使ってGCP側のVPC Peeringを作成 |
#4 | 00:47 | 17:35 |
| 疎通確認(EC2 -> GCE) | CLI | SSM Session ManagerでEC2に接続し、GCEへping/curl | #5 | 01:56 | 19:31 |
| 疎通確認(GCE -> EC2) | CLI | IAP tunnel経由でGCEにSSH接続し、EC2へping/curl | #6 | 01:07 | 20:39 |
| 合計 | - | Terraform構築から双方向疎通確認まで | - | - | 20:40 |
証拠とするにはあまりにも弱々しいですが、以下は再走時にとった記録です。
(ストップウォッチは適当にClaudeに作ってもらいました)

いかがでしょうか。
Terraform ApplyからAWSとGoogle Cloudの双方向疎通確認まで、たったこれだけの時間で完了しています。
マルチクラウドのプライベート接続がこの速度で構築できるのは驚きです。
また、Terraform Applyはあくまで事前の基盤構築なので、AWS Interconnect - multicloud関連リソースのみに絞ると実質約12分で完了しています。
さらに言うと、再走においても各所でモタモタしていた部分もあり(AWS CLIやGoogle Cloud CLIの事前ログインをしていなかったなど)、
事前準備をしっかりしてタイムを詰めれば10分切りも狙えるかもしれません。
さいごに
以上、「AWS re:Invent 2025 新機能「やってみた」報告会 ~ネットワーク・運用編~」の登壇レポートと、RTA失敗の原因、そして再走の様子でした。
LT時にRTAに失敗したのはかなり悔しかったですが、再走で無事に完走できたのでひとまず満足しました。ありがとうございました。
なお失敗の原因は「試走時のリソース消し忘れ」というかなりシンプルなものだったので、次回以降のRTAではこの反省を活かしていきたいと思います。
AWS Interconnect - multicloudはまだプレビュー段階のサービスですが、AWSとGoogle Cloudをプライベート接続できるというのはマルチクラウド構成を検討している方にとってかなり魅力的な選択肢かと思います。
サンプルリポジトリも公開しているので、興味がある方はぜひRTAしてみてください。
この記事が誰かのお役に立てば幸いです。









