Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
[AWSあるある] 複数拠点との接続パターン
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
AWS_Aruaru
September 01, 2021
Technology
1.1k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
[AWSあるある] 複数拠点との接続パターン
複数拠点との接続パターンを紹介していきます
AWS_Aruaru
September 01, 2021
More Decks by AWS_Aruaru
See All by AWS_Aruaru
[AWSあるある] Microsoftライセンス②
aws_aruaru
0
46
[AWSあるある] Microsoftライセンス①
aws_aruaru
0
120
[AWSあるある] コスト削減パターン①
aws_aruaru
0
85
[AWSあるある] 外部公開用FTPサーバ構築パターン
aws_aruaru
1
4.1k
Other Decks in Technology
See All in Technology
攻撃者視点で考えるDetection Engineering
cryptopeg
2
1.2k
就職⽀援サービスにおけるキャリアアドバイザーのシフトスケジューリング
recruitengineers
PRO
1
140
NAB Show 2026 動画技術関連レポート / NAB Show 2026 Report
cyberagentdevelopers
PRO
0
170
Disciplined Vibes: Scaling AI-Assisted Engineering
sheharyar
0
130
「エンジニア進化論」2028年の開発完全自動化、エンジニアはどう進化するか
cyberagentdevelopers
PRO
6
4.6k
日本 Fintech 未来予測レポート 2027〜2028年(オリジナル版)
8maki
0
1.9k
白金鉱業Meetup_Vol.24_「AIエージェントは分けるほど良い」は本当か? / Is it true that “the more you divide AI agents, the better”?
brainpadpr
1
310
AI-DLCを活用した高品質・安全なAI駆動開発実践 / AI Driven Development with AI-DLC
yoshidashingo
0
170
タクシーアプリ『GO』の実践的データ活用
mot_techtalk
3
190
Chainlitで作るお手軽チャットUI
ynt0485
0
200
2026TECHFRESH畢業分享會 - Lightning Talk - 資料也要 CI/CD? 用 Airbyte 自動化資料同步
line_developers_tw
PRO
0
830
Agent Skills設計で柔軟性と硬さのバランスが難しい話
nassy20
0
120
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1033
470k
Speed Design
sergeychernyshev
33
1.8k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.5k
Become a Pro
speakerdeck
PRO
31
6k
Art, The Web, and Tiny UX
lynnandtonic
304
22k
Practical Orchestrator
shlominoach
191
11k
The Pragmatic Product Professional
lauravandoore
37
7.3k
Information Architects: The Missing Link in Design Systems
soysaucechin
0
970
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.3k
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.5k
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
410
What the history of the web can teach us about the future of AI
inesmontani
PRO
1
610
Transcript
AWS あるある 複数拠点との接続
前提・要件 拠点A 拠点B 拠点Y 拠点Z ・・・・ AWS • AWS環境と拠点(A~Z)がある •
各拠点がAWS内のサーバにアクセスする必要がある • インターネット経由でのアクセスはNG(VPN経由であればOK) サーバ
代表的な考慮事項 • 現在何らかのVPN(拠点間接続)サービスを利⽤しているか • AWS側のVPC数 • 拠点数 • 拠点のNW構成は変更可能か
構成パターン① 現在何らかのVPN(拠点間接続)サービスを利⽤している場合
拠点A 拠点B 拠点Y 拠点Z ・・・・ キャリアVPNサービス 閉域網サービス 現在、きっとこのような接続になっているはず。
拠点A 拠点B 拠点Y 拠点Z ・・・・ キャリアVPNサービス 閉域網サービス AWSに⾜を⽣やすだけでOK。 キャリア側の設定は、 キャリアに確認を。
AWS側の接続パターンは2つ AWS サーバ
サーバ キャリアVPNサービス 閉域網サービス *表記省略 拠点A~Z VPC Virtual Private Gateway (VGW)
VPCが1つのパターン キャリア側の⾜は VGWに直接紐づく
サーバ キャリアVPNサービス 閉域網サービス *表記省略 拠点A~Z VPC VGW VPCが2つ以上のパターン (図では3つ) キャリア側の⾜は
Direct Connect Gatewayに 紐づく Direct Connect Gatewayに 各VPCが紐づく (1つのDXGWで最⼤10 VPCまで紐付け可能。10 VPC を超える場合は、キャリアの⾜とDXGWを増やす) サーバ VPC サーバ VPC Direct Connect Gateway (DXGW)
構成パターン② • 現在VPN(拠点間接続)サービスを利⽤していないため、 Internet VPNで接続する • 各拠点は各NWアドレスが重複しないように設計済み • もし重複があっても、拠点側の変更を⾏うことができる
拠点A 拠点B 拠点C 「拠点数が 10 以下」 かつ「 VPC が 1
つ」の場合 サーバ VPC Virtual Private Gateway (VGW) + Site-To-Site VPN Site-to-Site VPN接続をVPCに 直接貼る (図の場合は 3本のVPN接続) 1つのVPCに対して、最⼤10本のVPNま で貼れる。超える場合は、次ページのパ ターンを利⽤
拠点A 拠点B 拠点Y 拠点数(VPN数)が 10 を超える場合 VPC数に関係なく(図では 3 つ) Transit
Gateway を利⽤ Transit Gateway ・・・・ 拠点Z サーバ VPC サーバ VPC サーバ VPC
構成パターン③ 各拠点は各NWアドレスが重複しないように設計されてはいない • 重複があっても、拠点側の変更を⾏うことができない • 変更ができない理由例 • そもそも⾃社の拠点ではない(プライベート接続なSaaS提供パターン) • 変更の影響が⼤きすぎる
この構成パターン(拠点のNWが重複)の前提条件 • 拠点 ⇔ AWS の通信は、必ず「拠点 → AWS 」となる •
例) 拠点にクライアントPC、AWS上にWebサーバ(Webサービス) がある構成 • クライアントPCから必ずWebサーバにアクセスする • AWSからクライアントPCへの通信は発⽣しない • 「NWが重複」かつ「AWS → 拠点」 の通信が発⽣する場合は、難易度が ⾼いため、このパターンでは扱いません(別のパターンで紹介する予定)
拠点A 拠点B サーバ VPC 拠点C 10.0.0.0/16 10.0.0.0/16 10.0.0.0/16 10.0.0.0/16 これらをどう接続するか
3つの拠点と1つのVPC 地獄のような状況を作るために、全部 10.0.0.0/16 にしてみました
拠点A 拠点B サーバ VPC 拠点C 10.0.0.0/16 10.0.0.0/16 10.0.0.0/16 10.0.0.0/16 Network
Load Balancer(NLB) の PrivateLink 機能を利⽤ - サービス⽤VPCにNLBを作成 - 各拠点ごとに PrivateLink ⽤ VPCを作成し、各VPC内に VPC endpointを作成 - 各拠点内のクライアントはVPC endpointのIPアドレスにアクセスすることで、 NLBを経由して、サーバに接続できる VPC VPC VPC Site-To-Site VPN or キャリアVPNサービス Site-To-Site VPN or キャリアVPNサービス Site-To-Site VPN or キャリアVPNサービス Network Load Balancer (NLB) 10.0.0.0/16 以外のNW Endpoints Endpoints Endpoints 10.0.0.0/16 以外のNW 10.0.0.0/16 以外のNW サービス用VPC PrivateLink用VPC PrivateLink PrivateLink PrivateLink
拠点A サーバ VPC 10.0.0.0/16 10.0.0.0/16 分かりやすくするために、拠点Aのみ表⽰ - PrivateLink⽤VPCのNWを 192.168.1.0/24 としている
- 払い出されたVPC endpointのIPアドレスを 192.168.1.100 としている VPC Site-To-Site VPN or キャリアVPNサービス Network Load Balancer (NLB) Endpoints 192.168.1.0/24 PrivateLink サービス用VPC 192.168.1.100 PrivateLink用VPC 拠点AとPrivateLink⽤VPCは、プライベートに接続さえされていればいいので、VPNで もキャリアサービスでもなんでもいい。接続要件次第 Client クライアントは、VPC endpoint (192.168.1.100)にアクセス (実際は、直IPじゃなく、DNSレコードを登録しておくはず) VPC endpoint(PrivateLink)を通じて、クライアントからのトラフィックは NLBを経由してサーバに届く。(戻りのトラフィックは逆の順番で戻る)