上級 40分
Lesson 24
ハイブリッド接続 — Direct Connect・VPN・Client VPN
Direct Connect MACsec、Site-to-Site VPN、Client VPN認証、Transit Gatewayセグメンテーションを徹底解説
AWS Direct Connect VPN SCS-C03 ハイブリッド Security
読み込み中...
1. ハイブリッド接続のセキュリティ階層
ハイブリッド接続は、オンプレミスと AWS を接続するための複数のオプションを提供します。SCS-C03 では、暗号化、認証、冗長性に関する深い理解が要求されます。
Direct Connect vs VPN トポロジ比較
Loading diagram...
Transit Gateway ハブ・スポークアーキテクチャ
Loading diagram...
2. AWS Direct Connect（DX）の深掘り
2.1 DXの基本原則
最重要：DX自体はデフォルト暗号化なし
Direct Connect は AWS とオンプレミスを物理的に接続するサービスですが、デフォルトではレイヤー2トラフィックは暗号化されていません。これは、スループット最適化と低遅延を優先した設計です。
2.2 MACsec（Layer 2 暗号化）
MACsecとは
MACsec（Media Access Control Security、IEEE 802.1AE）は、DX接続のレイヤー2フレームを暗号化する標準です。IPsecとは異なり、ネットワークレイヤーではなくMACレイヤーで動作します。
MACsecの特性:
暗号化位置: Layer 2（MAC フレーム）
オーバーヘッド: 16-32 バイト/フレーム
パフォーマンス: ハードウェアオフロード対応
相互認証: 事前共有鍵（PreSharedKey）
鍵交換: CAK（Connectivity Association Key）
ICV（Integrity Check Value）
更新: 自動キーローテーション可能MACsec設定フロー
1. DXロケーションでMACsec対応を確認
└─ ListConnections → macsecCapable: true
2. カスタマーゲートウェイでMACsec設定
└─ CAKを生成（32文字の16進数）
└─ ICV検証キーを設定
3. AWS側でDXに対してMACsecを有効化
└─ CreateMacSecKey API
└─ CAKを登録（クライアント側と一致させる）
4. BGP接続の確認
└─ MACsecハンドシェイク完了後、BGPが確立MACsec対応ロケーション（2026年4月時点）
日本:
├─ 東京: ap-northeast-1
│ ├─ 東京 1A, 1B, 1D (MACsec対応)
│ └─ 東京 1C, 1E (要確認)
└─ 大阪: ap-northeast-2
└─ 大阪 1 (MACsec対応)
グローバル:
├─ N. Virginia, N. California, Oregon
├─ Frankfurt, London, Paris
├─ Singapore, Sydney, Tokyo
└─ その他 (マトリックスで確認)
注: 対応ロケーションは定期的に拡大中
AWSドキュメントで最新を確認すること試験で狙われるポイント：MACsec
- MACsecはDX専用 — VPN経由では利用不可
- 鍵管理の責任 — AWS側で鍵を保存・ローテーション
- レイヤー2の暗号化 — レイヤー3（IPsec）とは異なる
- 完全性チェック — MACフレームの改ざん検出
- パフォーマンス — ハードウェアオフロード対応で帯域幅損失最小
2.3 DXの3つのVIF（Virtual Interface）
パブリックVIF（Public VIF）
用途:
- AWS パブリックエンドポイント（S3, DynamoDB, etc.）へのアクセス
- 公開APIの呼び出し
セキュリティ特性:
- BGPでAWSのパブリックプレフィックスを受信
- インターネット経由ではなくDX経由で到達
- ただしトラフィック自体は暗号化されない（MACsecで対応）
BGP設定例:
customer side BGP ASN: 65001
AWS side BGP ASN: 14169
BGP通知内容:
├─ S3のプレフィックス (52.92.0.0/16, etc.)
├─ DynamoDBのプレフィックス
└─ Route53, CloudFrontのプレフィックスプライベートVIF（Private VIF）
用途:
- VPC内のプライベートIPへのアクセス
- EC2, RDS, ElastiCacheなど
セキュリティ特性:
- BGPでVPCのプライベートプレフィックスを受信
- DX Gateway経由でマルチVPC接続可能
- NSG（ネットワークセキュリティグループ）は不適用
→ ルートテーブルで制御
BGP設定例:
customer side BGP ASN: 65001
AWS side BGP ASN: 64512 (Private ASN Range)
BGP通知内容:
├─ VPC 10.0.0.0/16
├─ VPC 10.1.0.0/16
└─ VPC 10.2.0.0/16 (複数VPC)トランジットVIF（Transit VIF）
用途:
- Transit Gateway経由での複数VPC接続
- DX GatewayとTGWの統合
セキュリティ特性:
- ルートテーブル + TGW attachment policies で制御
- VPC単位ではなく、TGWレベルでのセグメンテーション
- より柔軟なルーティング制御
ネットワーク図:
┌──────────────┐
│ Customer GW │
└────────┬─────┘
│ (BGP ASN: 65001)
│
┌────▼──────────┐
│ DX Transit │
│ VIF │
└────┬──────────┘
│
┌────▼──────────────────┐
│ DX Gateway │
└────┬──────────────────┘
│
┌────▼──────────────────┐
│ Transit Gateway │
│ ┌──────────┐ │
│ │ Route TB │ │
│ ├──────────┤ │
│ │ VPC Att. │ │
│ └──────────┘ │
└───────────────────────┘
│ │ │
VPC1 VPC2 VPC3VIF比較表
┌──────────────┬──────────────┬──────────────┬──────────────┐
│ 項目 │ パブリック │ プライベート │ トランジット │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ 接続先 │ AWS public │ VPC private │ Transit GW │
│ │ endpoints │ │ │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ 必要な認証 │ 公開BGP ASN │ プライベート │ プライベート │
│ │ (14169など) │ ASN range │ ASN range │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ VPC数 │ N/A │ 複数可能 │ 複数（多数） │
│ │ │ (DX GW経由) │ │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ セキュリティ │ 暗号化推奨 │ MACsec推奨 │ MACsec推奨 │
│ (DX側) │ (MACsec) │ │ │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ 遅延 │ 低 │ 低 │ 低 │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ コスト │ DX費用 + ポート│ DX費用 + ポート│ DX費用 + TGW │
└──────────────┴──────────────┴──────────────┴──────────────┘2.4 DXの複数接続パターン
暗号化オプション1: MACsec（推奨）
セットアップ:
1. DXロケーションでMACsec対応を確認
2. CreateMacSecKey で CAK/ICV キーを生成
3. カスタマーゲートウェイで MACsec を設定
4. BGP セッション確立後、トラフィック開始
メリット:
- DX帯域幅を最大限活用
- ハードウェアオフロード可能
- パフォーマンスロス最小
デメリット:
- MACsec対応ロケーション限定
- 鍵管理の複雑性
- カスタマーゲートウェイの対応必須暗号化オプション2: Site-to-Site VPN over DX
アーキテクチャ:
┌──────────────┐
│ Customer GW │
│ (IPsec) │
└────────┬─────┘
│ IPsec over DX
│
┌────▼──────────────┐
│ DX (物理接続) │
└────┬──────────────┘
│
┌────▼──────────────┐
│ VGW (IPsec終端) │
└────┬──────────────┘
│
┌────▼──────────────┐
│ VPC │
└──────────────────┘
メリット:
- 標準的なIPsecプロトコル
- すべてのロケーションで利用可能
- VPN冗長性構築容易
デメリット:
- 2重の遅延（DX + IPsec処理）
- オーバーヘッド増加
- 帯域幅損失（IPsecヘッダ）
使用場面:
- MACsec非対応ロケーション
- 多層的なセキュリティが必要
- 既存IPsec環境との統合暗号化オプション3: パブリックVIF経由VPN
アーキテクチャ:
オンプレミス
┌──────────────┐
│ Customer GW │
│ (IPsec) │
└────────┬─────┘
│ IPsec
│ (インターネット経由)
│
┌────▼──────────────┐
│ Internet Gateway │
└────┬──────────────┘
│
┌────▼──────────────┐
│ VPC (Public Subnet)│
└──────────────────┘
セキュリティ考慮:
- インターネット経由なので外部露出
- DDoS対策必須（WAF, Shield)
- BGP Hijacking リスク
- パブリックIPで受信するため、
顧客ファイアウォールで許可が必要2.5 Link Aggregation Group（LAG）
LAGは複数のDX接続を束ねて、単一の論理接続として機能させます。
構成:
DX接続1 (1Gbps) ─┐
DX接続2 (1Gbps) ─┼─ LAG (2Gbps)
DX接続3 (1Gbps) ─┘
ルール:
- すべての接続が同じロケーション内
- すべての接続が同じBGP設定
- 同じVIF タイプ（すべてPrivateなど）
セキュリティ:
- MACsec対応の場合、すべての接続で有効化
- LAG内で均等に負荷分散
- 1つの接続が失われても他は継続
監視:
- CloudWatch メトリクス
├─ ConnectionState
├─ ConnectionBpsEgress / Ingress
└─ LagState
設定例:
aws ec2 create-lag \
--location "Tokyo" \
--number-of-connections 3 \
--connections-bandwidth "1Gbps"2.6 Direct Connect Gateway（DX Gateway）
DX Gateway は複数の DX VIF を集約し、複数の VPC に接続するためのゲートウェイです。
ネットワーク図:
オンプレミス
│
└─ DX Connection (東京)
│
┌────▼─────────────┐
│ DX Gateway │
│ (Virtual GW) │
└────┬─────────────┘
│
┌────┼──────────────────────┐
│ │ │
VPC A VPC B VPC C VPC D (最大3リージョン)
利点:
- 単一のDX接続で複数VPCを管理
- クロスリージョン接続対応
- BGP同期を簡素化
セキュリティ:
- DX Gateway レベルでBGP フィルタリング
- VPC ごとの allow/deny ルール
- 不要なルートをフィルタリングDX Gateway のセキュリティ設定
# BGPプレフィックスフィルタリング
import boto3
ec2 = boto3.client('ec2', region_name='ap-northeast-1')
# DX Gateway への接続にフィルタを適用
response = ec2.update_dx_gateway_association(
AssociationId='dcgw-assoc-12345678',
AddAllowedPrefixesToDirectConnectGateway=[
{
'cidr': '10.0.0.0/16' # VPC-A のみ許可
}
]
)
# ブラックホールルートの設定（不要なルートを廃棄）
# BGP AS-PATH プレペンド で優先度制御2.7 BGPセキュリティ
BGP AS-PATH フィルタリング
シナリオ:
悪意のあるオンプレミスネットワークが
他のVPCのプレフィックスを広告しようとする
対策:
BGP ルータ設定例 (Cisco):
router bgp 65001
neighbor 169.254.10.1 remote-as 64512
address-family ipv4
neighbor 169.254.10.1 prefix-list OUT allow-out-prefixes out
neighbor 169.254.10.1 prefix-list IN allow-in-prefixes in
ip prefix-list allow-out-prefixes seq 10 permit 192.168.0.0/16
ip prefix-list allow-out-prefixes seq 20 deny 0.0.0.0/0
ip prefix-list allow-in-prefixes seq 10 permit 10.0.0.0/16
ip prefix-list allow-in-prefixes seq 20 permit 10.1.0.0/16
ip prefix-list allow-in-prefixes seq 30 deny 0.0.0.0/0プレフィックス長制限（RPKI）
Resource Public Key Infrastructure (RPKI):
- BGP Origin Validation
- 正当なIPアドレス帯域の所有者を検証
AWS対応:
- Route Origin Authorizations (ROAs) を発行
- BGPルータで RPKI validation 有効化
設定:
route bgp 64512
bgp bestpath as-path multipath-relax
bgp send-community both
address-family ipv4
bgp suppress-inactive-routes
# RPKI validation 有効化
bgp rpki server 203.0.113.1 vrf MGMT
bgp rpki server 203.0.113.2 vrf MGMT prefer
# ROA validation 結果で決定
route-policy RPKI-VALIDATION
if validation-state is valid then
pass
elif validation-state is invalid then
drop
else # notfound
pass
endif
end-policyRoute Leakage 防止
シナリオ:
DXから受け取ったVPCプレフィックスが
インターネット経由で外部に漏洩
対策:
1. BGP ルータで Inbound フィルタ
2. Route Targets (VRF) で分離
3. ファイアウォール ACL で確認
設定例 (Juniper):
import replace vrf CORPORATE-VPC {
from bgp {
prefix-list only-aws-prefixes;
neighbor 169.254.10.1;
}
then accept;
}
# インターネット向けは独立したVRF
export replace vrf INTERNET {
from bgp {
prefix-list internet-only-prefixes;
}
then accept;
}2.8 高可用性設計パターン
パターン1: 複数DX接続（Active-Active）
┌─────────────────────────────────────────────────────┐
│ オンプレミス │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Router A │ │ Router B │ │
│ │ (Active) │ │ (Active) │ │
│ └──────┬───────┘ └───────┬──────┘ │
└───────────┼────────────────────┼──────────────────┘
│ │
┌────▼──────┐ ┌────▼──────┐
│ DX Connect│ │ DX Connect│
│ (東京) │ │ (大阪) │
└────┬──────┘ └────┬──────┘
│ │
┌────▼────────────────────▼──────┐
│ DX Gateway │
│ (BGP ASN: 64512) │
└────┬───────────────────────────┘
│
┌────▼──────────────────┐
│ VPC │
│ ┌─────────────────┐ │
│ │ Subnet │ │
│ │ 10.0.0.0/24 │ │
│ └─────────────────┘ │
└───────────────────────┘
トラフィックフロー:
- DX (東京) を Primary
- DX (大阪) を Secondary
- BGP Local Preference で制御
BGP設定:
route-map PRIMARY seq 10
set local-preference 200
route-map SECONDARY seq 10
set local-preference 100
neighbor 169.254.10.1 route-map PRIMARY in
neighbor 169.254.11.1 route-map SECONDARY inパターン2: DX + VPN（Backup）
オンプレミス
│
├─ DX Connection (Primary, 帯域幅大)
│
└─ VPN Connection (Backup, 1.25Gbps制限)
ルーティング:
- BGP で DX のプレフィックスに高優先度
- VPN は DX 障害時のフェイルオーバー
フェイルオーバー:
DX 接続喪失
↓
BGP Withdraw (数秒)
↓
VPN ルート有効化（BGP lower preference）
↓
トラフィック VPN 経由
↓
DX 復旧後、自動的に DX 優先に戻るパターン3: ホットスタンバイVGW
VPC側で複数VGWを設定:
VPC
├─ VGW-A (Primary DX)
│ └─ DX Connection (東京)
│
└─ VGW-B (Backup VPN or DX大阪)
└─ VPN or DX Connection
ルートテーブル:
Destination Next Hop Priority
────────────────────────────────────────
192.168.0.0/16 vgw-A 100
192.168.0.0/16 vgw-B 101
VGW-A 障害時:
AWS は自動的にルートを vgw-B にフェイルオーバー
RTO: 数秒 ~ 数十秒3. Site-to-Site VPN（サイト間VPN）
3.1 IPsecハンドシェイク
Phase 1 (IKE SA Establishment):
┌────────────────┐ ┌──────────────┐
│ Customer GW │ │ VGW (AWS) │
└────────┬───────┘ └──────┬───────┘
│ │
│ 1. IKE_SA_INIT │
│─────────────────────────▶
│ │
│ 2. IKE_SA_INIT Response │
│◀─────────────────────────│
│ │
│ 3. IKE_AUTH │
│─────────────────────────▶
│ │
│ 4. IKE_AUTH Response │
│◀─────────────────────────│
│ │
[IKE SA Established]
Phase 2 (IPsec SA Establishment):
│ 5. CREATE_CHILD_SA │
│─────────────────────────▶
│ │
│ 6. CREATE_CHILD_SA Resp │
│◀─────────────────────────│
│ │
[IPsec SA Ready]
[Encrypted Traffic Flows]3.2 暗号化アルゴリズムの選択
Phase 1 Encryption Options:
┌────────────┬─────────────┬─────────────┬──────────┐
│ Algorithm │ Key Size │ Performance │ Security │
├────────────┼─────────────┼─────────────┼──────────┤
│ AES-GCM-16 │ 128/256 bit │ High │ Very High│
│ ChaCha20 │ 256 bit │ Very High │ Very High│
│ AES-CBC │ 128/256 bit │ Medium │ High │
└────────────┴─────────────┴─────────────┴──────────┘
Phase 2 (IPsec) Encryption:
┌────────────┬─────────────┬──────────────────┐
│ Algorithm │ Key Size │ AWS Recommended │
├────────────┼─────────────┼──────────────────┤
│ AES-GCM-16 │ 128/256 bit │ Yes (Preferred) │
│ AES-CBC │ 128/256 bit │ Yes (Legacy OK) │
└────────────┴─────────────┴──────────────────┘
Integrity Algorithms (Phase 1 & 2):
SHA-256, SHA-384, SHA-512 (推奨)
SHA-1 (廃止予定)
MD5 (廃止)3.3 VPNカスタマーゲートウェイ設定
import boto3
ec2 = boto3.client('ec2', region_name='ap-northeast-1')
# 1. カスタマーゲートウェイ作成
cgw_response = ec2.create_customer_gateway(
Type='ipsec.1',
PublicIp='203.0.113.10', # オンプレミス外部IP
BgpAsn=65001, # BGP ASN
TagSpecifications=[
{
'ResourceType': 'customer-gateway',
'Tags': [
{'Key': 'Name', 'Value': 'Tokyo-Branch-GW'}
]
}
]
)
cgw_id = cgw_response['CustomerGateway']['CustomerGatewayId']
# 2. Virtual Private Gateway (VPW) 作成
vgw_response = ec2.create_vpn_gateway(
Type='ipsec.1',
AmazonSideAsn=64512,
TagSpecifications=[
{
'ResourceType': 'vpn-gateway',
'Tags': [
{'Key': 'Name', 'Value': 'Tokyo-VGW'}
]
}
]
)
vgw_id = vgw_response['VpnGateway']['VpnGatewayId']
# 3. VGW を VPC にアタッチ
ec2.attach_vpn_gateway(
VpnGatewayId=vgw_id,
VpcId='vpc-12345678'
)
# 4. VPN 接続作成（IKEv2推奨）
vpn_response = ec2.create_vpn_connection(
Type='ipsec.1',
CustomerGatewayId=cgw_id,
VpnGatewayId=vgw_id,
VpnConnectionOptions={
'StaticRoutesOnly': False, # 動的ルーティング (BGP)
'TunnelOptions': [
{
'TunnelInsideCidr': '169.254.10.0/30',
'PreSharedKey': 'your-preshared-key-12345'
},
{
'TunnelInsideCidr': '169.254.11.0/30',
'PreSharedKey': 'your-preshared-key-67890'
}
],
'IKEVersion': 2 # IKEv2 (IKEv1 より安全)
}
)
print(f"VPN Connection: {vpn_response['VpnConnection']['VpnConnectionId']}")3.4 VPN CloudHub
複数のオンプレミスサイトを VPN で接続し、サイト間通信を可能にします。
オンプレミス AWS オンプレミス
サイトA VPC(東京) サイトB
│ │ │
├──VPN─────────────┤ │
│ [VGW] │
│ [VPC RT]───BGP────────┐ │
│ │ │
└────────────────────────────────────┼──┘
│
BGP で相互に
ルート交換CloudHub 設定:
# VGW でBGP有効化（すべてのVPN接続で同じBGP ASN）
response = ec2.create_vpn_connection(
Type='ipsec.1',
CustomerGatewayId=cgw_id_tokyo,
VpnGatewayId=vgw_id,
VpnConnectionOptions={
'StaticRoutesOnly': False, # BGP必須
'TunnelOptions': [
{
'TunnelInsideCidr': '169.254.10.0/30'
}
]
},
Tags=[{'Key': 'Name', 'Value': 'Tokyo-Branch'}]
)
response = ec2.create_vpn_connection(
Type='ipsec.1',
CustomerGatewayId=cgw_id_osaka,
VpnGatewayId=vgw_id, # 同じ VGW
VpnConnectionOptions={
'StaticRoutesOnly': False,
'TunnelOptions': [
{
'TunnelInsideCidr': '169.254.12.0/30'
}
]
},
Tags=[{'Key': 'Name', 'Value': 'Osaka-Branch'}]
)
# 各ブランチのBGAデバイスが VPCプレフィックスを学習
# → サイト間通信が可能に（ただしVPC経由）セキュリティ注意点
CloudHub のリスク:
1. すべてのサイト間トラフィックが VPC 経由
→ VPC Route Table で制御 (ファイアウォールなし)
2. BGP ハイジャック
→ プレフィックスフィルタリング必須
対策:
- VPC内に中央ファイアウォール(Network Firewall)配置
- BGP プレフィックスフィルタ設定
- サイト間アクセス制御を明示的に許可3.5 Accelerated VPN
Global Accelerator を使用して VPN 遅延を削減します。
標準 VPN:
Customer → インターネット → VGW
遅延: 50-100ms, ルート: 可変
Accelerated VPN:
Customer → Global Accelerator (エッジロケーション)
→ AWS バックボーン → VGW
遅延: 10-50ms, ルート: 固定 (最適化)
設定:
1. Global Accelerator で VGW をターゲット登録
2. Global Accelerator IP でVPN接続初期化
3. VPN トラフィックが自動的にGA経由3.6 VPN パフォーマンス限界
Site-to-Site VPN の制限:
- 単一トンネル帯域幅: 1.25 Gbps
- 複数接続で並列化可能 (3倍まで = 3.75 Gbps)
- IPsec 処理オーバーヘッド: 5-10%
改善策:
1. 複数VPN接続 (異なるCGW)
2. VPN over DX (遅延削減)
3. Accelerated VPN (Global Accelerator)
4. Direct Connect 検討4. Transit Gateway（TGW）セキュリティ
4.1 ルートテーブルと隔離
Transit Gateway Route Table (TGWRT) は、接続ごとの ネットワークトラフィック フローを制御します。
ネットワーク図:
┌──────────────────────────────────┐
│ Transit Gateway │
│ │
│ ┌──────────────────────────┐ │
│ │ TGWRT-PROD │ │
│ │ ┌──────────┐ │ │
│ │ │ Routes │ │ │
│ │ │ 10.1./16 → VPC-Prod │ │
│ │ │ 10.2./16 → Denied │ │
│ │ └──────────┘ │ │
│ │ Propagation: │ │
│ │ ├─ VPC-Prod │ │
│ │ └─ VPC-Dev (NOT) │ │
│ └──────────────────────────┘ │
│ │
│ ┌──────────────────────────┐ │
│ │ TGWRT-DEV │ │
│ │ ┌──────────┐ │ │
│ │ │ Routes │ │ │
│ │ │ 10.2./16 → VPC-Dev │ │
│ │ │ 10.1./16 → Denied │ │
│ │ └──────────┘ │ │
│ │ Propagation: │ │
│ │ ├─ VPC-Dev │ │
│ │ └─ VPC-Prod (NOT) │ │
│ └──────────────────────────┘ │
└──────────────────────────────────┘
効果:
- VPC-Prod と VPC-Dev は完全に隔離
- 同じTGW内でも相互通信不可
- ルートテーブルだけで実装可能4.2 ブラックホールルート
意図しないトラフィックを破棄します。
import boto3
ec2 = boto3.client('ec2', region_name='ap-northeast-1')
# Transit Gateway Route Table 取得
response = ec2.describe_transit_gateway_route_tables()
tgwrt_id = response['TransitGatewayRouteTables'][0]['TransitGatewayRouteTableId']
# ブラックホールルート作成
ec2.create_transit_gateway_route(
TransitGatewayRouteTableId=tgwrt_id,
DestinationCidrBlock='0.0.0.0/0', # すべてのトラフィック
Blackhole=True # 破棄
)
# より細かく制御
ec2.create_transit_gateway_route(
TransitGatewayRouteTableId=tgwrt_id,
DestinationCidrBlock='169.254.0.0/16', # リンクローカルアドレス
Blackhole=True
)
# VPC接続をリッスン
ec2.search_transit_gateway_routes(
TransitGatewayRouteTableId=tgwrt_id,
Filters=[
{
'Name': 'state',
'Values': ['blackhole']
}
]
)4.3 Inter-Region Peering の暗号化
複数リージョンのTGWを接続します。
東京 (ap-northeast-1) 大阪 (ap-northeast-2)
┌──────────────┐ ┌──────────────┐
│ TGW-Tokyo │ │ TGW-Osaka │
│ │ │ │
│ VPC 10.0./16 │ │ VPC 10.1./16 │
└──────┬───────┘ └──────┬───────┘
│ Peering (IPsec) │
│◀──────────────────────▶│
│ (自動暗号化) │
│ │
特性:
- リージョン間をIPsecで暗号化
- AWS バックボーン経由（インターネット不要）
- BGP で ルート自動同期
- DX不要（リージョン間接続）設定:
# TGW Peering Attachment 作成
ec2_tokyo = boto3.client('ec2', region_name='ap-northeast-1')
ec2_osaka = boto3.client('ec2', region_name='ap-northeast-2')
# 東京でピアリング申請
response = ec2_tokyo.create_transit_gateway_peering_attachment(
TransitGatewayId='tgw-tokyo-12345',
PeerTransitGatewayId='tgw-osaka-67890',
PeerAccountId='123456789012',
PeerRegion='ap-northeast-2'
)
attachment_id = response['TransitGatewayPeeringAttachment']['TransitGatewayAttachmentId']
# 大阪で承認
ec2_osaka.accept_transit_gateway_peering_attachment(
TransitGatewayAttachmentId=attachment_id
)
# ルートテーブルに伝播ルール設定
ec2_tokyo.enable_transit_gateway_route_table_propagation(
TransitGatewayRouteTableId='tgwrt-tokyo-12345',
TransitGatewayAttachmentId=attachment_id
)4.4 Transit Gateway Network Manager
ネットワークを可視化・監視します。
機能:
- トポロジー表示 (グラフ)
- リアルタイム監視
- BGP ルート検証
- ネットワーク異常検知
- CloudWatch Logs統合
構成:
Network Manager
└─ Global Network
├─ Sites (物理ロケーション)
│ ├─ Tokyo HQ
│ └─ Osaka Branch
├─ Transit Gateways (集約ポイント)
│ └─ TGW-Tokyo
└─ Links (DX / VPN)
├─ DX Tokyo
└─ VPN Osaka設定:
ec2 = boto3.client('ec2', region_name='ap-northeast-1')
# Global Network 作成
response = ec2.create_global_network(
Description='Company-wide Hybrid Network',
Tags=[
{
'Key': 'Environment',
'Value': 'Production'
}
]
)
global_network_id = response['GlobalNetwork']['GlobalNetworkId']
# Site 登録
site_response = ec2.create_site(
GlobalNetworkId=global_network_id,
Description='Tokyo Head Office',
Location={
'Address': 'Tokyo, Japan',
'Latitude': '35.6762',
'Longitude': '139.6503'
}
)
# Link 登録 (DX)
link_response = ec2.create_link(
GlobalNetworkId=global_network_id,
SiteId=site_response['Site']['SiteId'],
Bandwidth={
'DownloadSpeed': 10000, # 10 Gbps
'UploadSpeed': 10000
},
LinkProvider='AWS Direct Connect',
Type='DX',
Tags=[{'Key': 'Name', 'Value': 'DX-Tokyo'}]
)4.5 Multicast（マルチキャスト）
用途:
- 金融市場データフィード
- ビデオ配信
- IoT デバイス管理
セキュリティ考慮:
- マルチキャストグループのメンバーシップ管理
- ソース検証（IGMP Snooping）
- レート制限（DSCP）
設定:
1. TGW でマルチキャスト有効化
2. 送信元VPC / 受信元VPCを登録
3. EC2インスタンスで IGMP Join
4. ファイアウォールで許可（Multicast MAC）5. AWS Client VPN
Client VPN は個々のユーザー（またはデバイス）を AWS に接続するためのサービスです。
5.1 認証アーキテクチャ
┌─────────────┐
│ Client │ (Windows / macOS / Linux / iOS / Android)
└──────┬──────┘
│ OpenVPN Protocol (UDP 443)
│
┌──────▼──────────────────────────────┐
│ Client VPN Endpoint │
│ │
│ Authentication Layer │
│ ├─ Certificate (Mutual) │
│ ├─ Active Directory │
│ ├─ SAML (ID Provider) │
│ └─ Single Sign-On │
└──────┬──────────────────────────────┘
│
┌──────▼──────────────────────────────┐
│ Authorization Layer │
│ │
│ ├─ Target Network Access (VPC) │
│ ├─ Route-Based ACL │
│ └─ User Group Policies │
└──────┬──────────────────────────────┘
│
┌──────▼──────────────────────────────┐
│ AWS VPC / On-Premises Network │
│ │
│ ├─ EC2, RDS, DynamoDB │
│ ├─ On-Premises (VPN / DX) │
│ └─ Private Endpoints │
└─────────────────────────────────────┘5.2 認証方式の比較
A. 相互認証（証明書ベース）
最も安全（相互検証）
クライアント側:
- CA証明書 (server.crt)
- クライアント証明書 (client.crt)
- クライアント秘密鍵 (client.key)
サーバー側 (AWS):
- CA証明書 (server.crt)
- サーバー証明書 (server.crt)
- サーバー秘密鍵 (server.key)
検証フロー:
Client → "この秘密鍵で署名" → Server
Server → CA証明書で署名検証 → OK
Server → サーバー証明書提示 → Client
Client → CA証明書で署名検証 → OKセットアップ:
# クライアント証明書生成（OpenSSL / cfssl）
openssl genrsa -out client.key 2048
openssl req -new -key client.key -out client.csr
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -out client.crt
# AWS Client VPN で設定
aws ec2 import-client-vpn-client-certificate-revocation-list \
--certificate-authority-certificate arn:aws:acm:...
# クライアント設定ファイル
cat > client.ovpn << EOF
remote vpn-endpoint.amazonaws.com 443
ca server.crt
cert client.crt
key client.key
cipher AES-256-GCM
EOFB. Active Directory（AD）認証
エンタープライズ環境向け
ユーザー:
user@company.local (ドメインアカウント)
↓
AD サーバーに認証
↓
Kerberos チケット取得
↓
VPN アクセス許可
利点:
- 既存AD基盤の活用
- パスワードポリシー統一
- グループベースの権限制御
設定:
aws ec2 create-client-vpn-endpoint \
--client-cidr-block 10.0.0.0/22 \
--server-certificate-arn arn:aws:acm:... \
--authentication-options Type=directory-service-authentication,\
DirectoryServiceAuthentication=d-1234567890C. SAML/SSO 認証
クラウドネイティブ環境
ユーザー:
user@example.com (Okta, Azure AD, etc.)
↓
SAML IdP に認証
↓
SAML Assertion 取得
↓
VPN アクセス許可
利点:
- MFA対応
- オンボーディング自動化
- 既存SSO体制の活用
設定:
aws ec2 create-client-vpn-endpoint \
--client-cidr-block 10.0.0.0/22 \
--server-certificate-arn arn:aws:acm:... \
--authentication-options Type=federated-authentication,\
FederatedAuthentication=IdpArn=arn:aws:iam::123456789012:saml-provider/Okta,\
SelfServiceSamlProviderArn=arn:aws:iam::123456789012:saml-provider/Okta-self-service5.3 承認ルール（Authorization Rules）
import boto3
ec2 = boto3.client('ec2', region_name='ap-northeast-1')
client_vpn_endpoint = 'cvpn-endpoint-12345678'
# 例1: すべてのユーザーに VPC 10.0.0.0/16 へのアクセスを許可
ec2.authorize_client_vpn_ingress(
ClientVpnEndpointId=client_vpn_endpoint,
TargetNetworkCidr='10.0.0.0/16',
AuthorizeAllGroups=True, # すべてのユーザー
Description='Allow all users to access VPC'
)
# 例2: 特定のADグループにのみアクセス許可
ec2.authorize_client_vpn_ingress(
ClientVpnEndpointId=client_vpn_endpoint,
TargetNetworkCidr='10.0.1.0/24', # Production Subnet
AccessGroupIds=['cn=engineers,ou=groups,dc=company,dc=local'],
Description='Allow engineers to access production'
)
# 例3: 別グループには異なるネットワーク
ec2.authorize_client_vpn_ingress(
ClientVpnEndpointId=client_vpn_endpoint,
TargetNetworkCidr='10.0.100.0/24', # Dev Subnet
AccessGroupIds=['cn=developers,ou=groups,dc=company,dc=local'],
Description='Allow developers to access dev environment'
)
# 例4: 特定のネットワークへのアクセス拒否
ec2.revoke_client_vpn_ingress(
ClientVpnEndpointId=client_vpn_endpoint,
TargetNetworkCidr='172.16.0.0/12', # On-premises networks
AccessGroupIds=['*'] # すべてのユーザー
)
# ルール確認
response = ec2.describe_client_vpn_authorization_rules(
ClientVpnEndpointId=client_vpn_endpoint
)
for rule in response['AuthorizationRules']:
print(f"CIDR: {rule['DestinationCidr']}, "
f"Status: {rule['Status']}, "
f"Access: {rule['AccessAll']}")5.4 スプリットトンネル（Split Tunneling）
スプリットトンネルなし (Full Tunnel):
クライアント上のすべてのトラフィック
└─ VPN 経由
├─ AWS リソース
├─ オンプレミスリソース
└─ インターネット (遅延増加)
セキュリティ: 高 (完全に監視可能)
ユーザー体験: 低 (インターネット遅延)
スプリットトンネル有効 (Split Tunnel):
クライアント上のトラフィック
├─ AWS / オンプレミス関連
│ └─ VPN 経由（ルートテーブルで指定）
└─ インターネット
└─ 直接接続（ISP経由）
セキュリティ: 中 (VPN内のみ監視)
ユーザー体験: 高 (インターネット高速)
設定:
aws ec2 create-client-vpn-endpoint \
--client-cidr-block 10.0.0.0/22 \
--server-certificate-arn arn:aws:acm:... \
--split-tunnel # スプリットトンネル有効
# VPN経由で送信するルートを指定
aws ec2 create-client-vpn-route \
--client-vpn-endpoint-id cvpn-endpoint-... \
--destination-cidr-block 10.0.0.0/16 # VPC
aws ec2 create-client-vpn-route \
--client-vpn-endpoint-id cvpn-endpoint-... \
--destination-cidr-block 192.168.0.0/16 # On-prem5.5 CloudWatch Logs 統合
import boto3
import json
ec2 = boto3.client('ec2', region_name='ap-northeast-1')
logs = boto3.client('logs', region_name='ap-northeast-1')
# 1. CloudWatch Logs グループ作成
log_group_name = '/aws/clientvpn/endpoint1'
logs.create_log_group(logGroupName=log_group_name)
logs.put_retention_policy(
logGroupName=log_group_name,
retentionInDays=30
)
# 2. Client VPN で Logs 有効化
response = ec2.describe_client_vpn_endpoints()
endpoint_id = response['ClientVpnEndpoints'][0]['ClientVpnEndpointId']
ec2.associate_client_vpn_target_network(
ClientVpnEndpointId=endpoint_id,
SubnetId='subnet-12345678'
)
ec2.create_client_vpn_endpoint(
ClientVpnEndpointId=endpoint_id,
ConnectionLogOptions={
'Enabled': True,
'CloudwatchLogGroup': log_group_name,
'CloudwatchLogStream': 'auth-logs' # ログストリーム
}
)
# 3. ログ解析 (CloudWatch Insights)
log_events = logs.start_query(
logGroupName=log_group_name,
startTime=int(time.time()) - 3600, # 過去1時間
endTime=int(time.time()),
queryString="""
fields @timestamp, @message, @logStream
| filter @message like /CONNECTION_ERROR|AUTH_FAILED/
| stats count() by @logStream
"""
)
# 4. アラート設定
cloudwatch = boto3.client('cloudwatch', region_name='ap-northeast-1')
cloudwatch.put_metric_alarm(
AlarmName='ClientVPN-AuthFailures',
ComparisonOperator='GreaterThanThreshold',
EvaluationPeriods=1,
MetricName='AuthFailures',
Namespace='AWS/ClientVPN',
Period=300,
Statistic='Sum',
Threshold=10, # 5分内に10回以上の認証失敗
ActionsEnabled=True,
AlarmActions=['arn:aws:sns:ap-northeast-1:123456789012:security-alerts']
)5.6 Client VPN の制限事項
同時接続数:
AWS アカウント内での合計: 最大 5,000 ユーザー
個別 Endpoint: 制限なし（ただし容量ベース）
帯域幅:
Endpoint あたり: 最大 100 Mbps 推奨
(ユーザー数に応じて自動スケーリング)
トランスポート:
UDP 443 のみ（TCP 443 不可）
→ ファイアウォール設定に注意
プロトコル:
OpenVPN Core のみ
WireGuard 非対応
複雑な認証:
認証とは別に承認ルール必須
→ 両方設定しないと接続不可6. フォレンジック用ネットワーク設計
6.1 隔離VPC設計
セキュリティ侵害やインシデント調査のための専用VPC。
本番 VPC (10.0.0.0/16)
┌────────────────────────────┐
│ ┌─────────────┐ │
│ │ Compromised │ (侵害) │
│ │ EC2 Instance│ │
│ └────────┬────┘ │
│ │ (Traffic Capture)│
│ ▼ │
│ ┌─────────────────────────┐│
│ │ ENI (Mirror Source) ││
│ │ Traffic Mirroring ON ││
│ └─────────────────────────┘│
└────────────┬───────────────┘
│ (Mirrored Traffic)
┌──────▼────────────┐
│ VPC Traffic │
│ Mirroring (Target)│
└──────┬────────────┘
│
Forensics VPC (10.100.0.0/16)
┌────────────────────────────┐
│ ┌─────────────────────────┐│
│ │ Network Packet Sniffer ││
│ │ (tcpdump / Wireshark) ││
│ │ - 物理的に隔離 ││
│ │ - ログ改ざん不可 ││
│ │ - CloudWatch Logs送信 ││
│ └─────────────────────────┘│
│ │
│ ┌─────────────────────────┐│
│ │ SIEM / Log Aggregation ││
│ │ (Splunk / ELK) ││
│ └─────────────────────────┘│
└────────────────────────────┘設定:
import boto3
ec2 = boto3.client('ec2', region_name='ap-northeast-1')
# 1. フォレンジック VPC 作成
forensics_vpc = ec2.create_vpc(CidrBlock='10.100.0.0/16')
forensics_vpc_id = forensics_vpc['Vpc']['VpcId']
# Forensics サブネット
forensics_subnet = ec2.create_subnet(
VpcId=forensics_vpc_id,
CidrBlock='10.100.1.0/24'
)
forensics_subnet_id = forensics_subnet['Subnet']['SubnetId']
# 2. Traffic Mirroring Target 作成
mirror_target = ec2.create_traffic_mirror_target(
NetworkInterfaceId='eni-forensics-sniffer', # フォレンジック EC2
TrafficMirrorFilterInboundHandler='10.100.1.100' # フォレンジック EC2 IP
)
mirror_target_id = mirror_target['TrafficMirrorTarget']['TrafficMirrorTargetId']
# 3. 本番 VPC の疑わしい EC2 を Mirror Source に設定
mirror_filter = ec2.create_traffic_mirror_filter(
Description='Capture all traffic from compromised instance',
IngressFilterRules=[
{
'RuleNumber': 100,
'Protocol': -1, # All protocols
'DestinationCidrBlock': '0.0.0.0/0',
'SourceCidrBlock': '0.0.0.0/0',
'Action': 'accept'
}
],
EgressFilterRules=[
{
'RuleNumber': 100,
'Protocol': -1,
'DestinationCidrBlock': '0.0.0.0/0',
'SourceCidrBlock': '0.0.0.0/0',
'Action': 'accept'
}
]
)
mirror_filter_id = mirror_filter['TrafficMirrorFilter']['TrafficMirrorFilterId']
# 4. ミラーリングセッション開始
mirror_session = ec2.create_traffic_mirror_session(
TrafficMirrorTargetId=mirror_target_id,
TrafficMirrorFilterId=mirror_filter_id,
NetworkInterfaceId='eni-12345678', # Compromised EC2 ENI
SessionNumber=1,
VirtualNetworkId=100 # VLAN ID
)6.2 VPC Traffic Mirroring
機能:
- ENI レベルでトラフィック複製
- オリジナルフローへの影響なし
- 複数ターゲットへの同時ミラーリング可能
ユースケース:
1. フォレンジック調査
2. 侵入検知 (IDS/IPS)
3. パケットキャプチャ
4. コンプライアンス検査
フロー:
EC2 ENI (Source)
↓ (original traffic)
Target Network / Application
│
└─ Mirror (copy)
↓
Forensics VPC
├─ tcpdump
├─ Wireshark
└─ SIEM6.3 パケットキャプチャの実装
#!/bin/bash
# フォレンジック EC2 上で実行
# 1. tcpdump セッション開始（背景）
sudo tcpdump -i eth0 -w /var/log/packets-$(date +%s).pcap &
# 2. CloudWatch Logs にキャプチャ記録
aws logs create-log-group --log-group-name /aws/forensics/packets
aws logs create-log-stream \
--log-group-name /aws/forensics/packets \
--log-stream-name $(hostname)
# 3. 定期的にログを送信
while true; do
stat_output=$(tcpdump -i eth0 -tttt -v 2>&1 | head -20)
aws logs put-log-events \
--log-group-name /aws/forensics/packets \
--log-stream-name $(hostname) \
--log-events "[{\"message\": \"$stat_output\", \"timestamp\": $(date +%s000)}]"
sleep 60
done
# 4. S3 にアーカイブ（改ざん防止）
aws s3 sync /var/log/packets/ \
s3://forensics-bucket/packets/ \
--sse aws:kms \
--sse-kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/12345678-...7. ハイブリッド接続のベストプラクティス
7.1 多層セキュリティ（Defense in Depth）
┌─────────────────────────────────────────────────────┐
│ レイヤー1: 物理/接続セキュリティ │
│ ├─ Direct Connect (MACsec有効) │
│ ├─ 冗長構成 (複数DX / DX+VPN) │
│ └─ BGP認証 (RPKI検証) │
├─────────────────────────────────────────────────────┤
│ レイヤー2: ネットワークセグメンテーション │
│ ├─ Transit Gateway ルートテーブル │
│ ├─ VPC ルートテーブル制御 │
│ ├─ ブラックホールルート │
│ └─ VLAN 分離 (キャリアサイド) │
├─────────────────────────────────────────────────────┤
│ レイヤー3: ファイアウォール │
│ ├─ Network Firewall (VPC内) │
│ ├─ Security Group (EC2単位) │
│ ├─ Network ACL (Subnet単位) │
│ └─ VPC Endpoint ポリシー │
├─────────────────────────────────────────────────────┤
│ レイヤー4: アプリケーション認証 │
│ ├─ TLS/SSL (HTTPS) │
│ ├─ API キー検証 │
│ ├─ IAM ロール検証 │
│ └─ 監査ログ (CloudTrail) │
└─────────────────────────────────────────────────────┘7.2 冗長性設計チェックリスト
チェック項目:
1. 接続冗長性:
□ 複数DX接続（異なるロケーション）
□ VPN バックアップ有効
□ RTO/RPO 目標値の定義
□ フェイルオーバーテスト済み
2. ルーティング冗長性:
□ BGP ECMP（多経路）設定
□ AS-PATH プレペンドで優先度制御
□ BGP Local Preference 設定
□ BGP コミュニティ属性活用
3. 監視・検知:
□ CloudWatch アラーム設定
□ DX接続状態の監視
□ BGP ネイバー状態の監視
□ トラフィック異常検知
4. ドキュメント:
□ ネットワーク図の最新化
□ フェイルオーバープロセス文書化
□ BGP設定書の保管
□ 連絡先リスト更新7.3 パフォーマンス最適化
DX 最適化:
1. MACsec 対応ロケーション確認
2. BGP ECMP で負荷分散
3. ジャンボフレーム (MTU 9000) 設定
4. クラウド側との帯域幅マッチング
VPN 最適化:
1. Accelerated VPN 検討
2. 複数VPN接続で並列化
3. ファイアウォールルール最適化
4. TLS セッション再開設定
アプリケーション側:
1. Connection pooling
2. Keep-alive タイムアウト調整
3. Retry ロジック実装
4. キャッシング戦略試験で狙われるポイント
SCS-C03 のハイブリッド接続問題のパターン
1. 【セキュリティ】MACsec について
Q: DX 接続を暗号化する方法は？
A: MACsec（層2）/ VPN over DX（層3）/ パブリックVIF+VPN
判別ポイント:
- MACsec は DX 専用（VPN不可）
- 対応ロケーション限定
- パフォーマンス最優先の場合 → MACsec
2. 【認証】BGP セキュリティ
Q: BGP ハイジャックを防ぐには？
A: RPKI（ROA）/ AS-PATH フィルタ / プレフィックスリスト
判別ポイント:
- RPKI は IP 帯域の所有を検証
- AS-PATH プレペンドは優先度制御
3. 【アーキテクチャ】Transit Gateway
Q: 複数VPCを安全に接続するには？
A: TGW ルートテーブルで隔離 / 明示的ルート指定
判別ポイント:
- ルートテーブルだけで機能（ファイアウォール別）
- ブラックホールルートで拒否
4. 【認証】Client VPN 認証
Q: エンタープライズ向けの認証は？
A: AD / SAML / 証明書（相互認証）
判別ポイント:
- AD ← 既存ドメイン有効
- SAML ← クラウドネイティブSSO
- 証明書 ← スタンドアロン環境
5. 【パフォーマンス】VPN 帯域幅
Q: VPN の最大帯域幅は？
A: 単一接続 1.25 Gbps / 複数接続で並列化
判別ポイント:
- DX >> VPN（帯域比較）
- Accelerated VPN で遅延削減絶対に落とさない重要知識
-
Direct Connect
- デフォルト暗号化なし ← MACsec有効化必須
- MACsec対応ロケーション限定
- プライベートVIF / 公開VIF / トランジットVIF の違い
-
Site-to-Site VPN
- IPsec（IKEv2推奨）
- 1.25 Gbps 帯域幅制限
- CloudHub（複数サイト）
-
Transit Gateway
- ルートテーブルでセグメンテーション
- ブラックホールルート破棄
- Inter-Region Peering（IPsec自動）
-
Client VPN
- 認証（相互認証 / AD / SAML）
- 承認ルール（ネットワークベース）
- スプリットトンネル設定
-
セキュリティプリミティブ
- BGP RPKI / AS-PATH フィルタ
- VPC Traffic Mirroring
- CloudWatch Logs / CloudTrail
まとめ
AWS ハイブリッド接続は、多段階の選択肢と暗号化オプション を提供する包括的なサービススイートです。
試験に合格するポイント:
- デフォルト暗号化を疑え — DX / VPN の仕様を正確に把握
- ルートテーブルはファイアウォールではない — 別途制御が必要
- 冗長性設計が最優先 — RTO/RPO の定義なしに実装不可
- 認証と承認は別 — Client VPN は両方設定が必須
- BGP セキュリティは要 — RPKI / プレフィックスフィルタ
これらのポイントを押さえて、SCS-C03 の合格ラインを確実にクリアしましょう。