目次
- 書籍レベル完全学習ガイド
- 試験概要
- ドメイン1: ネットワーク設計(30%)
- ドメイン2: ネットワーク実装(26%)
- ドメイン3: ネットワーク管理・運用(20%)
- ドメイン4: ネットワークセキュリティ(24%)
- 試験重要数値チートシート
- 12週間学習プラン
- 頻出問題パターンと解法
- アーキテクチャ図
- 本試験形式 模擬問題(詳細解説付き)
- ANS-C01 追加詳解セクション
- ANS-C01 模擬問題
- ANS-C01 試験直前チェックリスト
- 付録: ANS-C01 頻出サービス一覧
- Domain 1: ネットワーク設計(詳細補足)
- Domain 2: ハイブリッドネットワーク接続
- Domain 3: エッジネットワークとコンテンツデリバリー
- Domain 4: ネットワークセキュリティ
- Domain 5: ネットワーク管理と運用
- 模擬試験 第1回 (65問)
- 付録: ANS-C01 重要ポイント総まとめ
- 第7章: ネットワーク自動化・CloudFormation
- 第8章: SD-WAN・ハイブリッドネットワーク最適化
- 模擬試験 セット2(15問)
- ANS試験 最終チェックリスト(補足)
AWS Certified Advanced Networking - Specialty (ANS-C01)
書籍レベル完全学習ガイド
試験概要
| 項目 | 詳細 |
|---|---|
| 試験コード | ANS-C01 |
| レベル | Specialty |
| 試験時間 | 170分 |
| 問題数 | 65問(採点対象)+ 15問(採点外) |
| 合格スコア | 750/1000 |
| 受験料 | $300 USD |
| 前提推奨 | AWS経験5年以上 + ネットワーク実務経験 |
ドメイン別出題割合
┌──────────────────────────────────────────────────────────────────┐
│ ドメイン1: ネットワーク設計 30% ██████████████ │
│ ドメイン2: ネットワーク実装 26% ████████████ │
│ ドメイン3: ネットワーク管理・運用 20% ████████ │
│ ドメイン4: ネットワークセキュリティ・コンプライアンス・ガバナンス │
│ 24% ██████████ │
└──────────────────────────────────────────────────────────────────┘
ドメイン1: ネットワーク設計(30%)
1.1 VPC 設計の原則
CIDRブロック設計
VPC CIDR設計の原則:
- 十分なIPアドレス空間(将来の拡張を考慮)
- RFC 1918 プライベートアドレス推奨
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
- オンプレミスや他のVPCと重複しない
サブネット設計:
VPC: 10.0.0.0/16 (65,536 IP)
├── Public Subnet AZ-A: 10.0.0.0/24 (256 IP)
├── Public Subnet AZ-B: 10.0.1.0/24 (256 IP)
├── Public Subnet AZ-C: 10.0.2.0/24 (256 IP)
├── Private Subnet AZ-A: 10.0.10.0/23 (512 IP)
├── Private Subnet AZ-B: 10.0.12.0/23 (512 IP)
├── Private Subnet AZ-C: 10.0.14.0/23 (512 IP)
├── Data Subnet AZ-A: 10.0.20.0/24 (256 IP)
├── Data Subnet AZ-B: 10.0.21.0/24 (256 IP)
└── Data Subnet AZ-C: 10.0.22.0/24 (256 IP)
注: AWSは各サブネットで最初の4つと最後の1つ(計5つ)のIPを予約
例: 10.0.0.0/24 の場合
10.0.0.0 ネットワークアドレス
10.0.0.1 VPCルーター
10.0.0.2 DNS(VPC+2)
10.0.0.3 将来の予約
10.0.0.255 ブロードキャスト
→ 実際に使えるのは 251 IP
VPC Secondary CIDR
import boto3
ec2 = boto3.client('ec2')
# セカンダリCIDR追加(IPアドレス不足時)
ec2.associate_vpc_cidr_block(
VpcId='vpc-xxxxxxxx',
CidrBlock='100.64.0.0/16' # CG-NAT範囲も使用可能
)
# 制限事項:
# - 既存のピアリングと重複不可
# - RFC 1918以外のアドレスも使用可能(100.64.0.0/10等)
# - 最大5つのCIDRブロックを関連付け可能
1.2 ルーティング設計
ルートテーブルの詳細
ルート優先度(最長プレフィックスマッチ):
より具体的なルート(プレフィックス長が長い)が優先
例: 宛先 10.0.0.5 へのパケット
10.0.0.0/16 via TGW ← 選択されない
10.0.0.0/24 via NATGW ← こちらが選択される(より具体的)
同じプレフィックス長の場合の優先度:
1. Local(VPC内) ← 最高優先
2. Static route(手動)
3. Propagated route(BGP/VGW)
# ルートテーブル設定例
ec2 = boto3.client('ec2')
# パブリックサブネット用ルートテーブル
ec2.create_route(
RouteTableId='rtb-public-xxxx',
DestinationCidrBlock='0.0.0.0/0',
GatewayId='igw-xxxxxxxxxx' # Internet Gateway
)
# プライベートサブネット用ルートテーブル(NAT Gateway経由)
ec2.create_route(
RouteTableId='rtb-private-xxxx',
DestinationCidrBlock='0.0.0.0/0',
NatGatewayId='nat-xxxxxxxxxx' # NAT Gateway
)
# オンプレミス向けルート
ec2.create_route(
RouteTableId='rtb-private-xxxx',
DestinationCidrBlock='192.168.0.0/16',
TransitGatewayId='tgw-xxxxxxxxxx' # Transit Gateway
)
# ミドルボックス(Network Firewall/GWLB)への強制ルーティング
ec2.create_route(
RouteTableId='rtb-ingress',
DestinationCidrBlock='10.0.1.0/24', # Webサーバーサブネット
VpcEndpointId='vpce-xxxxxxxxxx' # GWLB Endpoint(Inspection VPC)
)
1.3 Transit Gateway 完全ガイド
TGW アーキテクチャ
Transit Gateway
│
┌────────────┬────────┴────────┬────────────┐
│ │ │ │
VPC A VPC B VPC C オンプレミス
(本番) (開発) (共有) (Direct Connect/VPN)
TGW ルートテーブルで分離:
├── Production RT
│ 10.0.0.0/16 → VPC-A
│ 192.168.0.0/16 → オンプレミス(Direct Connect)
│
└── Development RT
10.1.0.0/16 → VPC-B
192.168.0.0/16 → オンプレミス(VPN)
(本番VPC-Aへのルートなし → 本番/開発分離)
import boto3
ec2 = boto3.client('ec2')
# Transit Gateway作成
tgw = ec2.create_transit_gateway(
Description='Production Transit Gateway',
Options={
'AmazonSideAsn': 64512, # BGP ASN
'AutoAcceptSharedAttachments': 'disable', # 明示的承認必要
'DefaultRouteTableAssociation': 'disable', # カスタムRTを使用
'DefaultRouteTablePropagation': 'disable',
'DnsSupport': 'enable',
'VpnEcmpSupport': 'enable', # ECMPでVPN帯域最大化
'MulticastSupport': 'disable'
}
)
tgw_id = tgw['TransitGateway']['TransitGatewayId']
# VPCアタッチメント
attachment = ec2.create_transit_gateway_vpc_attachment(
TransitGatewayId=tgw_id,
VpcId='vpc-production',
SubnetIds=['subnet-az-a', 'subnet-az-b', 'subnet-az-c'], # 各AZのサブネット
Options={
'DnsSupport': 'enable',
'Ipv6Support': 'disable',
'ApplianceModeSupport': 'enable' # Network Firewallなどのアプライアンス向け
}
)
# カスタムルートテーブル
prod_rt = ec2.create_transit_gateway_route_table(
TransitGatewayId=tgw_id,
TagSpecifications=[{'ResourceType': 'transit-gateway-route-table',
'Tags': [{'Key': 'Name', 'Value': 'production-rt'}]}]
)
# ルート追加
ec2.create_transit_gateway_route(
TransitGatewayRouteTableId=prod_rt['TransitGatewayRouteTable']['TransitGatewayRouteTableId'],
DestinationCidrBlock='10.0.0.0/16',
TransitGatewayAttachmentId='tgw-attach-vpc-production'
)
# アタッチメントをルートテーブルに関連付け
ec2.associate_transit_gateway_route_table(
TransitGatewayRouteTableId=prod_rt['TransitGatewayRouteTable']['TransitGatewayRouteTableId'],
TransitGatewayAttachmentId='tgw-attach-vpc-production'
)
TGW マルチリージョン(Inter-Region Peering)
# リージョン間TGWピアリング
ec2_tokyo = boto3.client('ec2', region_name='ap-northeast-1')
ec2_virginia = boto3.client('ec2', region_name='us-east-1')
# Tokyoから Virginia TGWへのピアリングリクエスト
peering = ec2_tokyo.create_transit_gateway_peering_attachment(
TransitGatewayId='tgw-tokyo',
PeerTransitGatewayId='tgw-virginia',
PeerAccountId='123456789012',
PeerRegion='us-east-1'
)
# Virginia側で承認
ec2_virginia.accept_transit_gateway_peering_attachment(
TransitGatewayAttachmentId=peering['TransitGatewayPeeringAttachment']['TransitGatewayAttachmentId']
)
# 静的ルート追加(ピアリング接続ではBGP経路交換なし)
ec2_tokyo.create_transit_gateway_route(
TransitGatewayRouteTableId='rtb-tokyo',
DestinationCidrBlock='172.16.0.0/16', # Virginia VPC CIDR
TransitGatewayAttachmentId=peering_attachment_id
)
1.4 AWS Direct Connect 完全ガイド
Direct Connect 接続種類
| 種類 | 速度 | 特徴 |
|---|---|---|
| Dedicated Connection | 1/10/100 Gbps | 専用ポート、DX Location |
| Hosted Connection | 50Mbps〜10Gbps | AWSパートナー経由、共有ポート |
Virtual Interface (VIF) 種類
| VIF種類 | 接続先 | 用途 |
|---|---|---|
| Public VIF | AWS パブリックエンドポイント | S3/DynamoDB等への直接接続 |
| Private VIF | VPC(VGW経由) | VPC内リソースへのアクセス |
| Transit VIF | Transit Gateway | 複数VPC/オンプレミスをTGW経由で集約 |
Direct Connect 接続フロー:
オンプレミス ──→ DX Location ──→ DX Connection ──→ VIF ──→ AWS
Private VIF:
オンプレミス → DX → Private VIF → VGW → VPC
Transit VIF(推奨: 複数VPC接続時):
オンプレミス → DX → Transit VIF → TGW → 複数VPC
Direct Connect 高可用性設計
冗長性レベル1: 単一接続(開発用のみ)
オンプレミス ━━→ DX Location A ━━→ AWS
冗長性レベル2: 別ロケーション(同一リージョン)
オンプレミス ━━→ DX Location A ━━→ AWS
オンプレミス ━━→ DX Location B ━━→ AWS
冗長性レベル3: 最高(ロケーション + デバイス冗長)
オンプレミス ─→ Router1 ─→ DX Location A ─→ AWS
オンプレミス ─→ Router1 ─→ DX Location B ─→ AWS
オンプレミス ─→ Router2 ─→ DX Location A ─→ AWS
オンプレミス ─→ Router2 ─→ DX Location B ─→ AWS
DX + VPN バックアップ(コスト最適化):
通常: DX(高帯域・低レイテンシ)
障害時: Site-to-Site VPN(自動フェイルオーバー)
→ BGP コミュニティで優先度制御
BGP(Border Gateway Protocol)基礎
BGP基本概念:
- AS(Autonomous System): BGPルーティングドメイン単位
- ASN(AS番号): ASの識別子(AWS: 7224, 64512-65534はプライベートASN)
- eBGP(External BGP): 異なるAS間
- iBGP(Internal BGP): 同一AS内
DirectConnect BGP設定:
- お客様のルーター eBGP → AWS
- BGPピア: お客様割り当てIPとAWS割り当てIPでセッション確立
- 経路広報: オンプレミスの経路をAWSに広報、AWSのVPC CIDRをオンプレミスに広報
BGPコミュニティによる経路制御:
7224:7300 → ローカル優先(DX経由ルートを優先)
7224:7100 → 低優先(バックアップ経路)
例: DX優先、VPNバックアップ
DXからの経路: local-preference 200 (BGPコミュニティで設定)
VPNからの経路: local-preference 100 (デフォルト)
→ DX正常時はDX経由、障害時はVPN経由
# Direct Connect設定確認
import boto3
dx = boto3.client('directconnect')
# 接続一覧
connections = dx.describe_connections()
# VIF設定
vifs = dx.describe_virtual_interfaces()
for vif in vifs['virtualInterfaces']:
print(f"VIF: {vif['virtualInterfaceName']}")
print(f"Type: {vif['virtualInterfaceType']}")
print(f"VLAN: {vif['vlan']}")
print(f"BGP ASN: {vif['asn']}")
print(f"State: {vif['virtualInterfaceState']}")
# Direct Connect Gateway(リージョン間VPC接続)
dxgw = dx.create_direct_connect_gateway(
directConnectGatewayName='global-dxgw',
amazonSideAsn=64512
)
# DX GatewayにVGW関連付け
dx.create_direct_connect_gateway_association(
directConnectGatewayId=dxgw['directConnectGateway']['directConnectGatewayId'],
gatewayId='vgw-xxxxxxxx',
addAllowedPrefixesToDirectConnectGateway=[
{'cidr': '10.0.0.0/16'}
]
)
1.5 VPN 設計
Site-to-Site VPN
# Site-to-Site VPN 設定
ec2 = boto3.client('ec2')
# Customer Gateway(オンプレミスルーター)
cgw = ec2.create_customer_gateway(
BgpAsn=65000,
PublicIp='203.0.113.1', # オンプレミスのパブリックIP
Type='ipsec.1',
DeviceName='Cisco-ASR-1001'
)
# Virtual Private Gateway
vgw = ec2.create_vpn_gateway(
AmazonSideAsn=64512,
Type='ipsec.1'
)
# VGWをVPCに接続
ec2.attach_vpn_gateway(
VpcId='vpc-xxxxxxxx',
VpnGatewayId=vgw['VpnGateway']['VpnGatewayId']
)
# VPN接続作成(BGP動的ルーティング)
vpn = ec2.create_vpn_connection(
CustomerGatewayId=cgw['CustomerGateway']['CustomerGatewayId'],
VpnGatewayId=vgw['VpnGateway']['VpnGatewayId'],
Type='ipsec.1',
Options={
'StaticRoutesOnly': False, # BGP使用
'TunnelOptions': [
{
'TunnelInsideCidr': '169.254.10.0/30', # Tunnel1
'PreSharedKey': 'MyPreSharedKey1'
},
{
'TunnelInsideCidr': '169.254.10.4/30', # Tunnel2
'PreSharedKey': 'MyPreSharedKey2'
}
]
}
)
# VPNは2つのトンネルを作成(冗長性)
# 両方のトンネルをオンプレミスで設定・BGPセッション確立を推奨
VPN ECMP(Equal Cost Multi-Path)
VPN ECMP を使った帯域集約:
TGW は ECMP をサポート(VGWは非対応)
TGW ←── VPN Tunnel 1 (1.25 Gbps)
TGW ←── VPN Tunnel 2 (1.25 Gbps)
TGW ←── VPN Tunnel 3 (1.25 Gbps)
TGW ←── VPN Tunnel 4 (1.25 Gbps)
合計: 最大 5 Gbps(理論値)
実装: TGW の VpnEcmpSupport を enable に設定
ドメイン2: ネットワーク実装(26%)
2.1 Elastic Load Balancing 詳細
ロードバランサー種類比較
| 項目 | ALB | NLB | GWLB | CLB |
|---|---|---|---|---|
| プロトコル | HTTP/HTTPS/gRPC | TCP/UDP/TLS | Layer3+4 | HTTP/HTTPS/TCP |
| Layer | 7 | 4 | 3 | 4/7 |
| スティッキー | Cookie | Source IP | - | Cookie |
| パスルーティング | ○ | ✗ | ✗ | ✗ |
| WebSocket | ○ | ○ | - | ✗ |
| 固定IP | ✗(DNS) | ○(Elastic IP) | - | ✗ |
| PrivateLink | ✗ | ○ | ✗ | ✗ |
| 静的IPでの接続 | ✗ | ○ | - | ✗ |
| レイテンシ | ms | μs(超低レイテンシ) | - | ms |
import boto3
elbv2 = boto3.client('elbv2')
# ALB作成
alb = elbv2.create_load_balancer(
Name='production-alb',
Subnets=['subnet-public-az-a', 'subnet-public-az-b', 'subnet-public-az-c'],
SecurityGroups=['sg-alb-xxxxxxxx'],
Scheme='internet-facing',
Type='application',
IpAddressType='dualstack' # IPv4 + IPv6
)
alb_arn = alb['LoadBalancers'][0]['LoadBalancerArn']
# リスナー作成(HTTPS)
listener = elbv2.create_listener(
LoadBalancerArn=alb_arn,
Protocol='HTTPS',
Port=443,
SslPolicy='ELBSecurityPolicy-TLS13-1-2-2021-06', # TLS 1.3推奨
Certificates=[{'CertificateArn': 'arn:aws:acm:...'}],
DefaultActions=[
{
'Type': 'forward',
'TargetGroupArn': 'arn:aws:elasticloadbalancing:...'
}
]
)
# パスベースルーティング
elbv2.create_rule(
ListenerArn=listener['Listeners'][0]['ListenerArn'],
Priority=10,
Conditions=[
{
'Field': 'path-pattern',
'Values': ['/api/*']
}
],
Actions=[
{
'Type': 'forward',
'TargetGroupArn': 'arn:aws:elasticloadbalancing:...api-tg...'
}
]
)
NLB + PrivateLink
# NLBをPrivateLinkサービスとして公開
ec2 = boto3.client('ec2')
# VPCエンドポイントサービス作成(NLBをPrivateLink化)
endpoint_service = ec2.create_vpc_endpoint_service_configuration(
NetworkLoadBalancerArns=['arn:aws:elasticloadbalancing:...nlb...'],
AcceptanceRequired=True # 接続リクエストを手動承認
)
# 他アカウントのVPCからエンドポイント作成
endpoint = ec2.create_vpc_endpoint(
VpcId='vpc-consumer',
ServiceName='com.amazonaws.vpce.us-east-1.vpce-svc-xxxxxxxxxx',
VpcEndpointType='Interface',
SubnetIds=['subnet-consumer-az-a', 'subnet-consumer-az-b'],
SecurityGroupIds=['sg-consumer-endpoint'],
PrivateDnsEnabled=True
)
2.2 Route 53 高度な設定
ルーティングポリシー詳細
| ポリシー | 機能 | ユースケース |
|---|---|---|
| Simple | 1レコード、複数値はランダム返却 | 単一リソース |
| Weighted | 重み比率でトラフィック分散 | A/Bテスト・カナリア |
| Latency | レイテンシ最小のリージョンへ | マルチリージョンユーザー最適化 |
| Geolocation | ユーザーの地理的位置 | 地域コンテンツ・法規制対応 |
| Geoproximity | 地理的位置+バイアス値 | 詳細なトラフィック調整 |
| Failover | Active-Passive フェイルオーバー | DR切り替え |
| Multivalue Answer | 最大8レコード返却+ヘルスチェック | クライアントサイドLB |
| IP-based | クライアントIPでルーティング | ISP毎のコンテンツ最適化 |
import boto3
route53 = boto3.client('route53')
# ヘルスチェック作成
health_check = route53.create_health_check(
CallerReference='unique-ref-001',
HealthCheckConfig={
'IPAddress': '10.0.0.100',
'Port': 443,
'Type': 'HTTPS',
'ResourcePath': '/health',
'FullyQualifiedDomainName': 'app.example.com',
'RequestInterval': 30, # 30秒間隔
'FailureThreshold': 3, # 3回連続失敗でUnhealthy
'Regions': ['us-east-1', 'eu-west-1', 'ap-northeast-1'], # 複数リージョンから確認
'EnableSNI': True
}
)
health_check_id = health_check['HealthCheck']['Id']
# Active-Passive フェイルオーバー
# Primary(Active)レコード
route53.change_resource_record_sets(
HostedZoneId='Z1234567890ABC',
ChangeBatch={
'Changes': [
{
'Action': 'CREATE',
'ResourceRecordSet': {
'Name': 'app.example.com',
'Type': 'A',
'SetIdentifier': 'Primary',
'Failover': 'PRIMARY',
'HealthCheckId': health_check_id,
'AliasTarget': {
'HostedZoneId': 'Z35SXDOTRQ7X7K',
'DNSName': 'prod-alb-xxxxxx.us-east-1.elb.amazonaws.com',
'EvaluateTargetHealth': True
}
}
},
{
'Action': 'CREATE',
'ResourceRecordSet': {
'Name': 'app.example.com',
'Type': 'A',
'SetIdentifier': 'Secondary',
'Failover': 'SECONDARY',
'AliasTarget': {
'HostedZoneId': 'Z35SXDOTRQ7X7K',
'DNSName': 'dr-alb-xxxxxx.us-west-2.elb.amazonaws.com',
'EvaluateTargetHealth': True
}
}
}
]
}
)
Route 53 Resolver(DNS プロキシ)
# Route 53 Resolver: オンプレミス ↔ VPC間のDNS解決
# オンプレミス → VPC内のプライベートDNSを解決
# Inbound Endpointを作成(VPC内のIPを持つDNSエンドポイント)
route53resolver = boto3.client('route53resolver')
inbound_endpoint = route53resolver.create_resolver_endpoint(
CreatorRequestId='inbound-001',
Name='OnPrem-to-VPC-DNS',
SecurityGroupIds=['sg-resolver-xxxxxxxx'],
Direction='INBOUND',
IpAddresses=[
{'SubnetId': 'subnet-az-a', 'Ip': '10.0.10.10'},
{'SubnetId': 'subnet-az-b', 'Ip': '10.0.12.10'}
]
)
# オンプレミスのDNSサーバーがこのIPに転送ルールを設定
# VPC → オンプレミスのDNSを解決
# Outbound Endpointを作成
outbound_endpoint = route53resolver.create_resolver_endpoint(
CreatorRequestId='outbound-001',
Name='VPC-to-OnPrem-DNS',
SecurityGroupIds=['sg-resolver-xxxxxxxx'],
Direction='OUTBOUND',
IpAddresses=[
{'SubnetId': 'subnet-az-a'},
{'SubnetId': 'subnet-az-b'}
]
)
# 転送ルール(.corp.example.com → オンプレミスDNSサーバーに転送)
resolver_rule = route53resolver.create_resolver_rule(
CreatorRequestId='rule-001',
Name='ForwardCorpDNS',
RuleType='FORWARD',
DomainName='corp.example.com.',
TargetIps=[
{'Ip': '192.168.1.10', 'Port': 53},
{'Ip': '192.168.1.11', 'Port': 53}
],
ResolverEndpointId=outbound_endpoint['ResolverEndpoint']['Id']
)
# VPCに転送ルールを関連付け
route53resolver.associate_resolver_rule(
ResolverRuleId=resolver_rule['ResolverRule']['Id'],
VPCId='vpc-xxxxxxxx'
)
2.3 CloudFront 高度な設定
CloudFront 配信パターン
パターン1: 静的コンテンツ配信
User → CloudFront (Edge) → S3 (Origin)
パターン2: 動的コンテンツ加速
User → CloudFront → ALB → EC2/ECS
(TCP接続最適化・HTTP/2・キャッシュ不使用)
パターン3: ハイブリッド配信
/static/* → CloudFront → S3 (キャッシュ)
/api/* → CloudFront → ALB (キャッシュなし)
パターン4: グローバル加速
User → CloudFront PoP → AWS Backbone → オリジン
(BGP Anycastによる最適なEdge選択)
import boto3
cloudfront = boto3.client('cloudfront')
# Distribution作成
distribution = cloudfront.create_distribution(
DistributionConfig={
'CallerReference': 'my-distribution-001',
'Origins': {
'Quantity': 2,
'Items': [
{
'Id': 's3-origin',
'DomainName': 'my-bucket.s3.amazonaws.com',
'S3OriginConfig': {
'OriginAccessIdentity': '' # OAC使用のためOAIは空
}
},
{
'Id': 'alb-origin',
'DomainName': 'my-alb.us-east-1.elb.amazonaws.com',
'CustomOriginConfig': {
'HTTPSPort': 443,
'OriginProtocolPolicy': 'https-only',
'OriginSSLProtocols': {
'Quantity': 1,
'Items': ['TLSv1.2']
}
}
}
]
},
'DefaultCacheBehavior': {
'TargetOriginId': 's3-origin',
'ViewerProtocolPolicy': 'redirect-to-https',
'AllowedMethods': {
'Quantity': 2,
'Items': ['GET', 'HEAD'],
'CachedMethods': {'Quantity': 2, 'Items': ['GET', 'HEAD']}
},
'CachePolicyId': '658327ea-f89d-4fab-a63d-7e88639e58f6', # CachingOptimized
'OriginRequestPolicyId': '88a5eaf4-2fd4-4709-b370-b4c650ea3fcf',
'Compress': True,
'FunctionAssociations': {
'Quantity': 1,
'Items': [{
'FunctionARN': 'arn:aws:cloudfront::123456789012:function/url-rewrite',
'EventType': 'viewer-request'
}]
}
},
'CacheBehaviors': {
'Quantity': 1,
'Items': [{
'PathPattern': '/api/*',
'TargetOriginId': 'alb-origin',
'ViewerProtocolPolicy': 'https-only',
'AllowedMethods': {
'Quantity': 7,
'Items': ['GET', 'HEAD', 'OPTIONS', 'PUT', 'POST', 'PATCH', 'DELETE'],
'CachedMethods': {'Quantity': 2, 'Items': ['GET', 'HEAD']}
},
'CachePolicyId': '4135ea2d-6df8-44a3-9df3-4b5a84be39ad', # CachingDisabled
'OriginRequestPolicyId': 'b689b0a8-53d0-40ab-baf2-68738e2966ac', # AllViewer
}]
},
'PriceClass': 'PriceClass_All', # 全EdgeロケーションPriceClass_100, PriceClass_200も可
'WebACLId': 'arn:aws:wafv2:us-east-1:123456789012:global/webacl/...',
'Enabled': True,
'Comment': 'Production Distribution',
'Aliases': {
'Quantity': 1,
'Items': ['www.example.com']
},
'ViewerCertificate': {
'ACMCertificateArn': 'arn:aws:acm:us-east-1:...',
'SSLSupportMethod': 'sni-only',
'MinimumProtocolVersion': 'TLSv1.2_2021'
}
}
)
CloudFront Functions vs Lambda@Edge
| 項目 | CloudFront Functions | Lambda@Edge |
|---|---|---|
| 実行場所 | 200+ Edge PoP | リージョンEdge(~13箇所) |
| レイテンシ | 超低(< 1ms) | 低(数ms) |
| タイムアウト | 1ms | 5秒(viewer)/ 30秒(origin) |
| メモリ | 2MB | 128MB〜10GB |
| ランタイム | JavaScript (ES5.1) | Node.js / Python |
| イベント | viewer-request/response | viewer/origin request/response |
| ユースケース | URL書き換え、ヘッダー操作 | 認証、画像変換、A/Bテスト |
// CloudFront Function: URLリライト
function handler(event) {
var request = event.request;
var uri = request.uri;
// /blog/post-name → /blog/index.html に書き換え
if (uri.startsWith('/blog/') && !uri.endsWith('/') && !uri.includes('.')) {
request.uri = '/blog/index.html';
}
return request;
}
2.4 Global Accelerator
# Global Accelerator: 静的Anycast IPでグローバル最適化
import boto3
globalaccelerator = boto3.client('globalaccelerator', region_name='us-east-1')
# アクセラレーター作成(静的IP 2つ)
accelerator = globalaccelerator.create_accelerator(
Name='production-accelerator',
IpAddressType='IPV4',
Enabled=True
)
# リスナー作成
listener = globalaccelerator.create_listener(
AcceleratorArn=accelerator['Accelerator']['AcceleratorArn'],
Protocol='TCP',
PortRanges=[
{'FromPort': 80, 'ToPort': 80},
{'FromPort': 443, 'ToPort': 443}
]
)
# エンドポイントグループ(リージョン毎)
# 東京リージョン
globalaccelerator.create_endpoint_group(
ListenerArn=listener['Listener']['ListenerArn'],
EndpointGroupRegion='ap-northeast-1',
TrafficDialPercentage=100, # 通常時100%
HealthCheckPath='/health',
HealthCheckPort=443,
HealthCheckProtocol='HTTPS',
EndpointConfigurations=[
{
'EndpointId': 'arn:aws:elasticloadbalancing:ap-northeast-1:...',
'Weight': 100,
'ClientIPPreservationEnabled': True # 元のクライアントIP保持
}
]
)
ドメイン3: ネットワーク管理・運用(20%)
3.1 VPC Flow Logs 詳細分析
- Flow Log フィールド(v2デフォルト):
- version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
- v3以降で追加可能なフィールド:
- vpc-id subnet-id instance-id tcp-flags type pkt-srcaddr pkt-dstaddr region az-id sublocation-type sublocation-id pkt-src-aws-service pkt-dst-aws-service flow-direction traffic-path
import boto3
ec2 = boto3.client('ec2')
# Flow Log有効化(ENI/サブネット/VPC レベル)
ec2.create_flow_logs(
ResourceIds=['vpc-xxxxxxxx'],
ResourceType='VPC',
TrafficType='ALL', # ACCEPT / REJECT / ALL
LogDestinationType='s3',
LogDestination='arn:aws:s3:::flow-logs-bucket/vpc-logs/',
LogFormat='${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status} ${vpc-id} ${subnet-id} ${instance-id} ${tcp-flags} ${type} ${pkt-srcaddr} ${pkt-dstaddr}',
MaxAggregationInterval=60 # 集約間隔: 60秒 or 600秒
)
-- Athena でFlow Logs分析
-- 不審な外部通信を検出
SELECT
srcaddr,
dstaddr,
dstport,
protocol,
SUM(bytes) as total_bytes,
COUNT(*) as flow_count
FROM vpc_flow_logs
WHERE action = 'ACCEPT'
AND date_partition = '2026/01/15'
AND srcaddr LIKE '10.%' -- 内部IPから
AND dstaddr NOT LIKE '10.%' -- 外部IPへ
AND dstaddr NOT LIKE '172.16.%'
AND dstaddr NOT LIKE '192.168.%'
GROUP BY srcaddr, dstaddr, dstport, protocol
HAVING SUM(bytes) > 10485760 -- 10MB超
ORDER BY total_bytes DESC
LIMIT 50;
-- TCP Flagsでポートスキャン検出
-- tcp-flags: 2=SYN, 18=SYN-ACK, 4=RST
SELECT srcaddr, COUNT(DISTINCT dstport) as unique_ports
FROM vpc_flow_logs
WHERE protocol = '6' -- TCP
AND tcp-flags = '2' -- SYNのみ(接続試みのみ)
AND action = 'REJECT'
AND date_partition = '2026/01/15'
GROUP BY srcaddr
HAVING COUNT(DISTINCT dstport) > 50
ORDER BY unique_ports DESC;
3.2 Network Performance モニタリング
# VPC Reachability Analyzer(到達性テスト)
ec2 = boto3.client('ec2')
# 到達性分析パスを作成
path = ec2.create_network_insights_path(
Source='i-xxxxxxxxxx', # 送信元インスタンス
Destination='i-yyyyyyyyyy', # 宛先インスタンス
Protocol='tcp',
DestinationPort=443
)
# 分析実行
analysis = ec2.start_network_insights_analysis(
NetworkInsightsPathId=path['NetworkInsightsPath']['NetworkInsightsPathId']
)
# 結果確認(インターネット経路がブロックされている場合の診断)
result = ec2.describe_network_insights_analyses(
NetworkInsightsAnalysisIds=[analysis['NetworkInsightsAnalysis']['NetworkInsightsAnalysisId']]
)
analysis_result = result['NetworkInsightsAnalyses'][0]
if analysis_result['NetworkPathFound']:
print("到達可能: パスが見つかりました")
else:
print("到達不可")
for explanation in analysis_result.get('Explanations', []):
print(f" 原因: {explanation['ExplanationCode']}")
print(f" 詳細: {explanation.get('Component', {})}")
3.3 AWS Network Manager
Network Manager: グローバルネットワーク全体の可視化・管理
機能:
- グローバルネットワークトポロジーの可視化
- TGW、[Direct Connect](/services/aws-direct-connect/)、VPN、SD-WAN の一元管理
- ルート分析(エンドツーエンドのパス確認)
- [CloudWatch](/services/cloudwatch/) メトリクス統合
- イベント(リンク障害等)の通知
ユースケース:
- 大規模マルチリージョンネットワークの運用管理
- ハイブリッドクラウドネットワークの可視化
ドメイン4: ネットワークセキュリティ(24%)
4.1 VPC Endpoint(Private Link)設計
VPC Endpoint 種類
| 種類 | 対象 | 特徴 |
|---|---|---|
| Gateway Endpoint | S3, DynamoDB | ルートテーブルへのルート追加・無料 |
| Interface Endpoint | 大半のAWSサービス | ENI作成・時間課金+データ料金 |
| Gateway Load Balancer Endpoint | アプライアンスサービス | サードパーティ製品 |
# Gateway Endpoint(S3向け・無料)
ec2.create_vpc_endpoint(
VpcId='vpc-xxxxxxxx',
ServiceName='com.amazonaws.us-east-1.s3',
VpcEndpointType='Gateway',
RouteTableIds=['rtb-private-xxxx'] # プライベートサブネットのRTに追加
)
# Interface Endpoint(プライベートDNSあり)
ec2.create_vpc_endpoint(
VpcId='vpc-xxxxxxxx',
ServiceName='com.amazonaws.us-east-1.ssm',
VpcEndpointType='Interface',
SubnetIds=['subnet-private-az-a', 'subnet-private-az-b'],
SecurityGroupIds=['sg-endpoint-xxxxxxxx'],
PrivateDnsEnabled=True # ssm.us-east-1.amazonaws.com → VPC内IPに解決
)
# Endpoint Policy(アクセス制限)
endpoint_policy = {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": [
"arn:aws:s3:::production-bucket",
"arn:aws:s3:::production-bucket/*"
],
"Condition": {
"StringEquals": {
"aws:sourceVpc": "vpc-xxxxxxxx" # 特定VPCからのみ
}
}
}
]
}
4.2 Network Firewall 詳細設計
[Network Firewall](/services/network-firewall/) 配置パターン:
パターン1: Centralized Inspection(推奨)
各VPC → TGW → Inspection [VPC](/services/vpc/) ([Network Firewall](/services/network-firewall/)) → TGW → Internet
パターン2: Distributed
各VPC内にNetwork Firewall(コスト高・管理複雑)
パターン3: East-West (VPC間) 検査
[VPC](/services/vpc/)-A → TGW → Inspection [VPC](/services/vpc/) (NF) → TGW → [VPC](/services/vpc/)-B
# Gateway Load Balancer(サードパーティアプライアンス統合)
# GWLB は GENEVE プロトコルでパケットを透過的に転送
elbv2 = boto3.client('elbv2')
# GWLB作成
gwlb = elbv2.create_load_balancer(
Name='security-gwlb',
Subnets=['subnet-security-az-a', 'subnet-security-az-b'],
Type='gateway',
IpAddressType='ipv4'
)
# ターゲットグループ(ファイアウォールアプライアンスEC2)
tg = elbv2.create_target_group(
Name='firewall-appliances',
Protocol='GENEVE',
Port=6081,
VpcId='vpc-security',
TargetType='instance',
HealthCheckProtocol='HTTP',
HealthCheckPath='/health'
)
# GWLBエンドポイントサービスとして公開
ec2.create_vpc_endpoint_service_configuration(
GatewayLoadBalancerArns=[gwlb['LoadBalancers'][0]['LoadBalancerArn']],
AcceptanceRequired=False # 同一組織内は自動承認
)
4.3 ネットワークセキュリティ多層防御
AWSネットワーク セキュリティ全体像:
Layer 1(グローバルエッジ):
[CloudFront](/services/cloudfront/) + Shield Standard/Advanced → DDoS/大規模攻撃
Layer 2(エッジ検査):
[WAF](/services/aws-waf/) (CloudFront/ALBにアタッチ) → OWASP Top10 / SQLi / XSS
Layer 3(ネットワーク境界):
[Network Firewall](/services/network-firewall/) → ステートフルパケット検査・IPS
Layer 4(サブネット境界):
Network ACL → ステートレスIPフィルタリング
Layer 5(インスタンス境界):
Security Group → アプリケーションポートのみ許可
Layer 6(監視・検出):
[VPC](/services/vpc/) Flow Logs + [GuardDuty](/services/guardduty/) → 異常検出・インシデント対応
Layer 7(データ保護):
KMS/ACM + [VPC](/services/vpc/) Endpoint → 通信の暗号化・プライベートルーティング
試験重要数値チートシート
| 項目 | 値 |
|---|---|
| VPC最大CIDRブロック | /16(65,536 IP) |
| VPC最小CIDRブロック | /28(16 IP) |
| サブネット予約IP | 5個(.0/.1/.2/.3/.255) |
| VPC Peering最大数 | 125(デフォルト) |
| TGW Attachment最大数 | 5,000 |
| Site-to-Site VPN スループット | 最大 1.25 Gbps/トンネル |
| Direct Connect 帯域 | 1/10/100 Gbps(Dedicated) |
| CloudFront TTLデフォルト | 86,400秒(24時間) |
| CloudFront TTL最小 | 0秒 |
| Global Accelerator 静的IP | 2個(Anycast) |
| Route 53 TTL最小 | 0秒 |
| NLB AZあたりのENI | 1個固定 |
| ALBノード最小 | 2(2AZ以上推奨) |
| NAT Gateway最大スループット | 45 Gbps |
| NAT Gateway課金 | 時間+データ処理量 |
| EIP最大数(デフォルト) | 5個/リージョン |
12週間学習プラン
Week 1-2: VPCとルーティング基礎
- [ ] VPC CIDR設計(サブネット分割演習)
- [ ] ルートテーブル・プレフィックスマッチ理解
- [ ] セキュリティグループ vs Network ACL
- [ ] NAT Gateway vs NAT Instance
- [ ] VPC Peering(制限・推移的ルーティング不可)
Week 3-4: 高度なVPCと接続
- [ ] Transit Gateway 詳細設計
- [ ] VPC Endpoint(Gateway/Interface/GWLB)
- [ ] PrivateLinkサービス公開
- [ ] VPN設定(BGP設定を含む)
Week 5-6: Direct Connect
- [ ] DX接続種類(Dedicated/Hosted)
- [ ] VIF設計(Public/Private/Transit)
- [ ] DX高可用性設計(冗長化パターン)
- [ ] BGP基礎(AS・経路広報・コミュニティ)
- [ ] DX Gateway設計
Week 7-8: DNS・CDN
- [ ] Route 53 全ルーティングポリシー
- [ ] Route 53 Resolver(Inbound/Outbound Endpoint)
- [ ] CloudFront 高度な設定
- [ ] Global Accelerator vs Route 53 vs CloudFront 使い分け
Week 9-10: ロードバランサー・セキュリティ
- [ ] ALB/NLB/GWLB 深掘り
- [ ] WAF ルール設計
- [ ] Network Firewall Suricataルール
- [ ] Shield Advanced 設定
Week 11: 監視・トラブルシューティング
- [ ] VPC Flow Logs + Athena分析
- [ ] VPC Reachability Analyzer
- [ ] Network Manager
- [ ] CloudWatch Network Insights
Week 12: 試験対策
- [ ] AWS公式模擬試験(全問解説)
- [ ] Tutorialsdojo/Whizlabs模擬試験 × 3回
- [ ] BGP/CIDR計算演習
- [ ] AWS Well-Architected Framework(信頼性の柱)精読
頻出問題パターンと解法
Q1: VPC Peering vs Transit Gateway の選択
問題: 10個のVPCを全対全で接続したい場合の最適な方法?
解答: Transit Gateway。VPC Peeringは推移的ルーティングが不可能なため、n個のVPCを全対全で接続するにはn(n-1)/2個のPeering接続が必要(10VPCなら45本)。TGWはスター型で全VPCを接続でき、ルートテーブルで通信制御も可能。
Q2: Direct Connect 帯域不足
問題: 10Gbps DX接続で帯域が不足してきた。コスト効率よく帯域を増やす方法?
解答: LAG(Link Aggregation Group)で複数DX接続を束ねる。2本の10Gbps → 20Gbps論理チャネル。または100Gbps Dedicated Connectionに移行。VPN ECMPは最大5Gbps程度なので補助的用途。
Q3: グローバルユーザーへの低レイテンシ配信
問題: 静的コンテンツはCloudFrontで最適化できているが、動的APIのレイテンシを世界中で均一に低くしたい。
解答: Global Accelerator。静的IPを使用し、AWSのグローバルバックボーン上で最適な経路を選択。CloudFrontは静的コンテンツのキャッシュに最適だが動的コンテンツは基本オリジンまで往復する。Global AcceleratorはTCP接続をエッジで終端してAWSバックボーン経由でオリジンに接続。
Q4: ハイブリッドDNS解決
問題: オンプレミスのホスト名(.corp.local)をVPC内のEC2から解決したい。
解答: Route 53 Resolver Outbound Endpointを作成し、.corp.localへの転送ルールでオンプレミスDNSサーバーのIPを指定。VPCにルールを関連付ける。逆方向(オンプレミス→VPC内プライベートDNS)はInbound Endpointを作成。
Q5: マルチリージョン障害対応
問題: ap-northeast-1とus-east-1でアクティブ/アクティブ構成。障害時に自動フェイルオーバーする方法?
解答: Route 53のレイテンシーベースルーティング + ヘルスチェック。各リージョンのALBに対してヘルスチェックを設定。障害検知時(FailureThreshold=3、30秒間隔なら最大1.5分)に該当リージョンのレコードをDNS解決から除外。Global Acceleratorはより高速(30秒以下)なフェイルオーバーが必要な場合に使用。
アーキテクチャ図
Transit Gateway ハブ&スポーク設計
flowchart TB
subgraph OnPrem["オンプレミス"]
DC["データセンター\n192.168.0.0/16"]
end
subgraph DX["接続層"]
DXCONN["[Direct Connect](/services/aws-direct-connect/)\n(10Gbps Dedicated)"]
VPN["Site-to-Site VPN\n(バックアップ)"]
end
subgraph TGW["Transit Gateway (ap-northeast-1)"]
PROD_RT["本番ルートテーブル\n(Dev VPCへのルートなし)"]
DEV_RT["開発ルートテーブル\n(Prod VPCへのルートなし)"]
ONPREM_RT["オンプレルートテーブル\n(全VPCへのルートあり)"]
end
subgraph VPCs["VPCs"]
VPC_P["本番VPC\n10.0.0.0/16"]
VPC_D["開発VPC\n10.1.0.0/16"]
VPC_S["共有VPC\n10.2.0.0/16\n(DNS/NTP/AD)"]
VPC_I["検査VPC\n10.3.0.0/16\n([Network Firewall](/services/network-firewall/))"]
end
DC --> DXCONN --> ONPREM_RT
DC --> VPN --> ONPREM_RT
PROD_RT <--> VPC_P & VPC_S
DEV_RT <--> VPC_D & VPC_S
ONPREM_RT <--> VPC_P & VPC_D & VPC_S
VPC_P & VPC_D -->|"インターネット\nアクセス"| VPC_I
style VPC_P fill:#fee2e2
style VPC_D fill:#dbeafe
style VPC_S fill:#dcfce7
style VPC_I fill:#fef3c7
Route 53 フェイルオーバー設計
flowchart TB
User["🌐 ユーザー\napp.example.com を解決"]
subgraph R53["[Route 53](/services/route-53/)"]
HC1["Health Check\n東京 [ALB](/services/alb/)\n30秒間隔・3回失敗でUnhealthy"]
HC2["Health Check\nバージニア [ALB](/services/alb/)"]
Primary["PRIMARY レコード\n東京ALB\n(HealthCheck紐付け)"]
Secondary["SECONDARY レコード\nバージニアALB\n(フェイルオーバー先)"]
end
subgraph Tokyo["ap-northeast-1 (東京)"]
ALB_T["[ALB](/services/alb/) (東京)"]
App_T["アプリケーション"]
end
subgraph Virginia["us-east-1 (バージニア)"]
ALB_V["[ALB](/services/alb/) (バージニア)"]
App_V["アプリケーション\n(DR環境)"]
end
User --> R53
HC1 -->|"ヘルスチェック"| ALB_T
HC2 -->|"ヘルスチェック"| ALB_V
Primary -->|"正常時"| ALB_T --> App_T
Secondary -->|"東京障害時\n自動フェイルオーバー"| ALB_V --> App_V
本試験形式 模擬問題(詳細解説付き)
問題 1
あなたの会社は 10 個の VPC を管理しています。各 VPC 間のすべての通信と、オンプレミスデータセンターへの接続が必要です。VPC Peering を使った場合に必要な接続数と、Transit Gateway を使った場合の接続数の差はいくつですか?
- A. Peering: 45本、TGW: 11本(差: 34本)
- B. Peering: 90本、TGW: 10本(差: 80本)
- C. Peering: 45本、TGW: 10本(差: 35本)
- D. Peering: 55本、TGW: 11本(差: 44本)
正解と解説
正解: A
解説: VPC Peering の場合:
- n個のVPCを全対全で接続する場合、必要な接続数 = n(n-1)/2
- 10個のVPC = 10×9/2 = 45本の Peering 接続
- さらにオンプレミスとの接続(VGW経由)は各VPCに1本ずつ必要 = +10本
- ただし「VPCペアリングは10本」という問題の読み方もある(オンプレ除く45本)
Transit Gateway の場合:
- TGW 自体は1つ
- 各VPCのアタッチメント = 10本
- オンプレミス = Direct Connect Transit VIF(または VPN)= 1本
- 合計 11本のアタッチメント
差 = 45 - 11 = 34本
VPC Peeringの重要な制限(試験頻出):
問題 2
オンプレミスデータセンターから AWS の プライベートサブネット内の EC2 インスタンスに接続するために Direct Connect を設定しています。オンプレミスから EC2 の プライベートIPアドレス(10.0.1.100)に到達するために使用すべき VIF(Virtual Interface)はどれですか?
- A. Public VIF
- B. Private VIF
- C. Transit VIF(Transit Gateway経由)
- D. Hosted VIF
正解と解説
正解: B または C(構成による)
解説: この問題は構成によって正解が変わります。試験では「1つのVPCへの接続」か「複数VPCへの接続」かで判断します。
B(Private VIF)が正解の場合:
- 単一のVPC(Virtual Private Gateway = VGW)に直接接続する場合
- VGW ↔ Private VIF ↔ DX ↔ オンプレミス
C(Transit VIF)が正解の場合:
- Transit Gatewayを経由して複数VPCに接続する場合(推奨・モダン構成)
- TGW ↔ Transit VIF ↔ DX ↔ オンプレミス
A(Public VIF)が不正解の理由:
DX VIF 選択基準(試験頻出):
| VIF種類 | 接続先 | 使用ケース |
|---|---|---|
| Public VIF | AWSパブリックIP | S3, ECR等のパブリックエンドポイント |
| Private VIF | VGW(単一VPC) | 単一VPCへのプライベートアクセス |
| Transit VIF | TGW | 複数VPC・ハブスポーク構成 |
問題 3
グローバルWebアプリケーションで、ユーザーが世界中のどこからアクセスしても常に最も近いAWSリージョンに接続させたい場合、最も適切なサービスはどれですか?
- A. Route 53 レイテンシーベースルーティング
- B. Global Accelerator
- C. CloudFront
- D. Route 53 地理ロケーションルーティング
正解と解説
正解: A または B(要件による)
解説: この問題はキーワードによって正解が変わります:
A(Route 53 レイテンシーベース):
- 各リージョンのエンドポイントへのDNS解決を最もレイテンシが低いリージョンに向ける
- DNSベースのルーティング(グローバルロードバランシング)
- ヘルスチェックと組み合わせてフェイルオーバー可能
- 静的な Anycast IPアドレス(2個)を使用
- エッジロケーションで TCP/UDP 接続を終端し、AWS バックボーン経由でオリジンに接続
- DNSキャッシュに影響されない(IPベース)
- フェイルオーバーが30秒以下(Route 53より高速)
試験での使い分け:
-
「固定IP(Anycast IP)が必要」→ Global Accelerator
-
「フェイルオーバー < 60秒」→ Global Accelerator
-
「DNSベースで十分」→ Route 53 レイテンシーベース
-
「静的コンテンツのキャッシュが主目的」→ CloudFront
-
D(地理ロケーション): ユーザーの国/大陸でルーティング。最も近いリージョンではなく「地域」でルーティングします。
問題 4
VPCのプライベートサブネットにある EC2 インスタンスから Amazon S3 にアクセスする際に、インターネットゲートウェイや NAT ゲートウェイを経由させたくない場合、最も適切な方法はどれですか?
- A. VPC Peering で S3 専用の VPC を作成する
- B. S3 用の VPC Gateway Endpoint を作成する
- C. S3 用の VPC Interface Endpoint を作成する
- D. Direct Connect Public VIF を使用する
正解と解説
正解: B
解説:
- B(Gateway Endpoint)が正解: S3 と DynamoDB には Gateway Endpoint が利用でき、追加費用なしでプライベートサブネットから直接アクセスできます。ルートテーブルにエントリが追加され、S3向けのトラフィックがゲートウェイ経由でルーティングされます。
Gateway Endpoint の特徴:
-
費用: 無料(Gateway型はデータ処理料金なし)
-
実装: ルートテーブルへのルートエントリ追加
-
プライベート DNS: 不要(amazonaws.com のエンドポイントURLそのまま使用)
-
C(Interface Endpoint): S3にも Interface Endpoint は存在しますが、料金がかかります(時間課金 + データ処理料金)。VPC内の DNS 解決が必要な場合や、オンプレミスからアクセスする場合に使います。
-
D(Direct Connect Public VIF): オンプレミスからAWSのパブリックエンドポイントへのアクセスに使用。VPC内からの接続には不要。
覚え方(試験頻出):
“S3とDynamoDBだけGateway Endpoint(無料)、その他はInterface Endpoint(有料)”
問題 5
ネットワーク管理者が VPC内の EC2 インスタンス(IP: 10.0.1.100)から別の EC2 インスタンス(IP: 10.0.2.200)への通信が失敗していることを調査しています。ネットワーク層での到達性を確認するための最も効率的な方法はどれですか?
- A. 両インスタンスにSSHして ping を実行する
- B. VPC Flow Logs を有効化して Athena でクエリする
- C. VPC Reachability Analyzer でソース・デスティネーションを指定して分析する
- D. CloudTrail でネットワーク接続ログを確認する
正解と解説
正解: C
解説:
- C(Reachability Analyzer)が正解: VPC Reachability Analyzer は、AWS ネットワーク構成(セキュリティグループ・NACL・ルートテーブル・IGW等)を分析して、指定した送受信者間の到達性を確認します。実際のパケットは送信せず、構成を論理的に分析します。接続できない場合は原因(どのセキュリティグループのどのルールがブロックしているか)まで特定できます。
Reachability Analyzerが便利な理由:
-
SSHアクセスが不要
-
リアルタイム分析(分析完了まで数分)
-
ブロック原因まで特定可能(SG・NACL・ルートテーブル等)
-
A(SSH + ping): SSHアクセスが必要。セキュリティグループでSSHが閉じている可能性。OSレベルのファイアウォールの影響を受けます。
-
B(Flow Logs + Athena): 「実際に発生した」トラフィックの記録。到達性「確認」には有効ですが、原因特定には時間がかかります。
-
D(CloudTrail): APIコールの監査ログ。ネットワーク通信の到達性確認には使いません。
問題 6
Direct Connect 接続が障害になった場合の自動フェイルオーバーとして Site-to-Site VPN をバックアップとして設定しています。BGP で Direct Connect を優先させ、障害時のみ VPN を使用させる設定として正しいものはどれですか?
- A. VPN に higher MED(Metric、AS Path)を設定する
- B. Direct Connect からの経路に BGP コミュニティ
7224:7300を設定してローカル優先度を上げる - C. VPN ルートテーブルに higher metric を設定する
- D. Direct Connect のアタッチメントに weight を追加する
正解と解説
正解: B
解説:
- B(BGP コミュニティ)が正解: AWS Direct Connect では BGP コミュニティタグを使って経路の優先度を制御できます。
AWS Direct Connect BGP コミュニティ(試験頻出):
| コミュニティ値 | Local Preference | 意味 |
|---|---|---|
7224:7100 |
100 | 低優先(バックアップ) |
7224:7200 |
200 | 中優先 |
7224:7300 |
300 | 高優先(DXを優先させる場合) |
設定の論理:
-
DX から受け取る経路に
7224:7300が付いていれば Local Preference = 300 -
VPN から受け取る経路は Local Preference = 100(デフォルト)
-
BGP では Local Preference が高い経路が優先される
-
→ DX が正常な間は DX 経由、DX 障害時は VPN 経由(自動フェイルオーバー)
-
A(VPN に高い MED): MED は AS 外への通知用。同じ宛先への複数経路がある場合の選択には Local Preference の方が影響が大きい。
-
C・D: ルートテーブルの metric や weight はBGPの経路選択に直接影響しません。
問題 7
ある企業が新たに VPC(CIDR: 10.100.0.0/16)を既存の Transit Gateway に接続しようとしています。接続後、TGW ルートテーブルに新しい VPC への経路が自動的に追加されません。原因として最も可能性が高いのはどれですか?
- A. TGW が利用できるルートの上限に達している
- B. TGW の
DefaultRouteTableAssociationがdisableに設定されており、手動でルートテーブルへの関連付けが必要 - C. 新しい VPC の CIDR が既存の VPC と重複している
- D. TGW は同一アカウントの VPC しか接続できない
正解と解説
正解: B
解説:
- B が正解: TGW の
DefaultRouteTableAssociationオプションがdisableの場合(セキュリティのためのカスタム設定でよく使われる)、新しいアタッチメントはデフォルトルートテーブルに自動関連付けされません。手動で関連付け(Association)とルート伝播(Propagation)を設定する必要があります。
# 手動で関連付けとルート伝播を設定
ec2.associate_transit_gateway_route_table(
TransitGatewayRouteTableId='tgw-rtb-xxxxxxxx',
TransitGatewayAttachmentId='tgw-attach-yyyyyyyy' # 新VPCのアタッチメント
)
# 経路の自動伝播(BGPからの自動ルート追加)
ec2.enable_transit_gateway_route_table_propagation(
TransitGatewayRouteTableId='tgw-rtb-xxxxxxxx',
TransitGatewayAttachmentId='tgw-attach-yyyyyyyy'
)
- A(上限): TGW のルート数上限(デフォルト10,000ルート)に達した場合は
RouteTableLimitExceededエラーが発生しますが、まず B を疑います。 - C(CIDR重複): CIDR重複がある場合、アタッチメント自体は作成できますが、ルーティングが不定になります。これは別の問題です。
- D(同一アカウント制限): TGW は Resource Access Manager(RAM)を通じてクロスアカウント共有が可能です。
ANS-C01 追加詳解セクション
ネットワークトポロジー設計の高度な知識
BGP ルーティング詳細(試験最頻出)
BGP(Border Gateway Protocol)基礎:
→ インターネットのルーティングプロトコル
→ AWS Direct Connect / Transit Gateway で使用
→ AS番号(Autonomous System Number)でネットワークを識別
BGP属性によるルート選択:
1. Weight(Cisco独自、ローカル): 高いほど優先
2. Local Preference: AS内での優先度
3. AS Path: 短いほど優先(AS数が少ない経路)
4. MED(Multi-Exit Discriminator): 他ASへの「推奨ルート」ヒント
AWS Direct Connectでのルート制御:
→ AS-PATH Prepending: AS番号を繰り返してパスを長くする(優先度を下げる)
→ Local Preference: VGW/TGWでの優先ルート設定
→ MED: オンプレミス側からAWSへの複数接続の優先制御
AWS Direct Connect 高度な設計
Direct Connect 接続の種類:
専用接続(Dedicated):
→ 1Gbps, 10Gbps, 100Gbps
→ Directコロケーション施設でのポート占有
ホスト接続(Hosted):
→ AWSパートナーが提供
→ 50Mbps〜10Gbps
→ 設定が容易・低速での開始が可能
仮想インターフェイス(VIF):
プライベートVIF(Private VIF):
→ VPCへの接続
→ VGW(Virtual Private Gateway)またはTGWに接続
パブリックVIF(Public VIF):
→ S3/DynamoDB等のAWSパブリックサービスへの接続
→ インターネット経由なしでAWSパブリックエンドポイントにアクセス
トランジットVIF(Transit VIF):
→ Transit Gatewayへの接続
→ 複数VPCへの接続が1つのDXで可能
冗長設計(HA):
→ 2つのDX接続(異なるDXロケーション)+ VPN フォールバック
→ SLA: 99.99%(2つのDXロケーション)
→ SLA: 99.9%(1つのDXロケーション + VPN)
AWS Global Accelerator
概念:
→ AWSのグローバルネットワーク(バックボーン)を使ってトラフィックをルーティング
→ Anycast IPでユーザーを最寄りのエッジロケーションに誘導
→ エッジからAWSバックボーン経由でエンドポイントへ
CloudFront vs Global Accelerator:
CloudFront: コンテンツキャッシュ(CDN)→静的コンテンツ・画像・動画
Global Accelerator: トラフィックの最適ルーティング → API・ゲーム・IoT
メリット:
→ 一般インターネットより低レイテンシ・安定した接続
→ 固定の2つのAnycast IPアドレス(ホワイトリストに追加可能)
→ 自動フェイルオーバー(60秒以内)
ユースケース:
「複数リージョンのAPIに固定IPでアクセスしたい」
「非HTTPSトラフィック(TCP/UDP)を最適化したい」
「IoT デバイスが固定IPで接続したい」
ANS-C01 模擬問題
問題 ANS-01
「オンプレミスから東京と大阪の2つのDirect Connect接続を使い、東京を優先ルートにしたい」場合のBGP設定はどれですか?
- A. 東京VIFのLocal Preferenceを高くする
- B. 大阪VIFのAS-PATH Prependingで大阪経由のパスを長くする
- C. 東京VIFのMEDを低くする
- D. 全て同じ設定にしてECMP(等コストマルチパス)で負荷分散する
正解と解説
正解: B
AS-PATH Prependingで大阪経由のAS番号を繰り返すと、BGPルート選択でAS Pathが短い(東京)が優先される。オンプレミス側からAWS方向のルーティング制御はAS-PATH Prependingで行う。
問題 ANS-02
Direct ConnectのVIFタイプで「VGWではなくTransit Gatewayに直接接続してTGW配下の複数VPCへのアクセスを実現したい」場合に使うVIFはどれですか?
- A. プライベートVIF
- B. パブリックVIF
- C. トランジットVIF
- D. トランクVIF
正解と解説
正解: C
Transit VIF(トランジット仮想インターフェイス)はTransit Gatewayに接続するために使用する。1つのDirect Connect接続でTGW配下の全VPCにアクセスできる。
問題 ANS-03
「複数のAWSリージョンのAPIに対して固定IPアドレスで低レイテンシアクセスを提供したい。コンテンツキャッシュは不要」最も適切なサービスはどれですか?
- A. Amazon CloudFront
- B. AWS Global Accelerator
- C. Amazon Route 53
- D. AWS Transit Gateway
正解と解説
正解: B
Global Acceleratorは非HTTPSトラフィック(TCP/UDP)の最適ルーティング・固定IP・低レイテンシに対応。CloudFrontはHTTP/HTTPS のコンテンツキャッシュCDN。
ANS-C01 試験直前チェックリスト
- [ ] BGPの属性とルート選択の優先順位(Weight/Local Preference/AS Path/MED)
- [ ] AS-PATH Prependingによるルート制御
- [ ] Direct Connect VIFの3種類(Private/Public/Transit)
- [ ] Direct Connect 冗長設計(99.99% vs 99.9% SLA)
- [ ] Global Accelerator vs CloudFrontの使い分け
- [ ] Transit Gateway vs VPCピアリングの使い分け
- [ ] PrivateLink(インターフェイスエンドポイント)の設計
付録: ANS-C01 頻出サービス一覧
| サービス | ANS試験での重点 |
|---|---|
| AWS Direct Connect | 接続タイプ・VIF・BGP・冗長設計 |
| AWS Transit Gateway | Hub-and-Spoke・ルートテーブル・TGW Connect |
| AWS Global Accelerator | Anycast IP・低レイテンシルーティング |
| Amazon VPC | サブネット設計・ルーティング・セキュリティ |
| AWS Site-to-Site VPN | IPsec・BGP・HA設計 |
| Amazon Route 53 | DNS・プライベートホストゾーン・Resolver |
| AWS PrivateLink | エンドポイントサービス・クロスアカウント |
| Amazon CloudFront | CDN・エッジ最適化 |
| Elastic Load Balancing | ALB/NLB・クロスゾーン負荷分散 |
| Amazon VPC Flow Logs | ネットワークトラフィック監視 |
Domain 1: ネットワーク設計(詳細補足)
1-1. AWS Transit Gateway 高度な設計
Transit Gateway マルチアカウント設計:
Account A (Prod) Account B (Dev) Account C (Shared Services)
VPC-A ──────────┐ VPC-B ──────────┐ VPC-C (DNS, AD) ──┐
↓ ↓ ↓
┌─────────────────────────────────────────────────────┐
│ Transit Gateway │
│ │
│ Route Table: Prod Route Table: Dev │
│ - VPC-A - VPC-B │
│ - VPC-C (Shared) - VPC-C (Shared) │
│ ✗ VPC-B (隔離) ✗ VPC-A (隔離) │
└─────────────────────────────────────────────────────┘
↓
Direct Connect / VPN
↓
オンプレミス
TGW の主要設定:
- ASN: デフォルト64512 (BGP AS番号)
- ECMP: 複数VPN/DirectConnect経路の負荷分散
- Multicast: マルチキャストドメインのサポート
- Appliance Mode: サードパーティ NVA (Network Virtual Appliance) の配置
- TGW Connect: GRE over TGWで高スループット (最大20Gbps)
import boto3
import json
ec2 = boto3.client('ec2', region_name='us-east-1')
ram = boto3.client('ram', region_name='us-east-1')
# Transit Gateway の作成
def create_transit_gateway(
name: str,
asn: int = 64512,
auto_accept: bool = False
) -> dict:
response = ec2.create_transit_gateway(
Description=f'Transit Gateway: {name}',
Options={
'AmazonSideAsn': asn,
'AutoAcceptSharedAttachments': 'enable' if auto_accept else 'disable',
'DefaultRouteTableAssociation': 'disable', # 手動でルートテーブル管理
'DefaultRouteTablePropagation': 'disable',
'VpnEcmpSupport': 'enable', # ECMP有効
'DnsSupport': 'enable',
'MulticastSupport': 'disable'
},
TagSpecifications=[{
'ResourceType': 'transit-gateway',
'Tags': [{'Key': 'Name', 'Value': name}]
}]
)
return response['TransitGateway']
# TGW ルートテーブルの作成
def create_tgw_route_table(tgw_id: str, name: str) -> str:
response = ec2.create_transit_gateway_route_table(
TransitGatewayId=tgw_id,
TagSpecifications=[{
'ResourceType': 'transit-gateway-route-table',
'Tags': [{'Key': 'Name', 'Value': name}]
}]
)
return response['TransitGatewayRouteTable']['TransitGatewayRouteTableId']
# VPC アタッチメント
def attach_vpc_to_tgw(
tgw_id: str,
vpc_id: str,
subnet_ids: list,
name: str
) -> str:
response = ec2.create_transit_gateway_vpc_attachment(
TransitGatewayId=tgw_id,
VpcId=vpc_id,
SubnetIds=subnet_ids,
Options={
'DnsSupport': 'enable',
'ApplianceModeSupport': 'disable'
},
TagSpecifications=[{
'ResourceType': 'transit-gateway-attachment',
'Tags': [{'Key': 'Name', 'Value': name}]
}]
)
return response['TransitGatewayVpcAttachment']['TransitGatewayAttachmentId']
# TGW をRAM経由でクロスアカウント共有
def share_tgw_cross_account(
tgw_arn: str,
target_account_ids: list
) -> dict:
return ram.create_resource_share(
name='TransitGatewayShare',
resourceArns=[tgw_arn],
principals=target_account_ids,
allowExternalPrincipals=False # AWS組織内のみ
)
1-2. AWS Direct Connect 設計パターン
Direct Connect 冗長設計:
【最高可用性 (Maximum Resilience)】
DCX Location 1 DCX Location 2
DX Router ──→ Customer Router 1 DX Router ──→ Customer Router 2
DX Router ──→ Customer Router 2 DX Router ──→ Customer Router 1
Physical Connection: 4本 (2 Location × 2 Connection)
BGP Failover: 自動
【高可用性 (High Resilience)】
DCX Location 1 DCX Location 2
DX Router ──→ Customer Router DX Router ──→ Customer Router
Physical Connection: 2本 (2 Location × 1 Connection)
【開発/テスト (Development)】
DCX Location 1
DX Router ──→ Customer Router
+ Site-to-Site VPN (バックアップ)
Virtual Interface (VIF) 種類:
Private VIF: VPC内リソースへのプライベートアクセス (VGW/TGWに接続)
Public VIF: AWS Public API endpoint へのアクセス (S3, DynamoDB等)
Transit VIF: TGW に接続してマルチVPCアクセス
Hosted VIF: パートナー経由の1Gbps以下接続
# Direct Connect の BGP 設定と監視
def monitor_direct_connect_connections() -> list:
dx = boto3.client('directconnect', region_name='us-east-1')
cw = boto3.client('cloudwatch', region_name='us-east-1')
connections = dx.describe_connections()['connections']
status_report = []
for conn in connections:
conn_id = conn['connectionId']
# 帯域幅使用率の取得
metrics = cw.get_metric_statistics(
Namespace='AWS/DX',
MetricName='ConnectionBpsIngress',
Dimensions=[{'Name': 'ConnectionId', 'Value': conn_id}],
StartTime='2024-01-01T00:00:00Z',
EndTime='2024-01-02T00:00:00Z',
Period=3600,
Statistics=['Average', 'Maximum']
)
status_report.append({
'connection_id': conn_id,
'name': conn.get('connectionName'),
'bandwidth': conn.get('bandwidth'),
'state': conn.get('connectionState'),
'location': conn.get('location'),
'region': conn.get('region')
})
return status_report
# BGP Route フィルタリング (ルートポリシー)
BGP_ROUTE_POLICY = """
route-map AWS-IN permit 10
match community 7224:8100 ! US East
set local-preference 200
route-map AWS-IN permit 20
match community 7224:8200 ! EU West
set local-preference 100
route-map AWS-OUT permit 10
match ip address prefix-list CORP-NETWORKS
set community 7224:9300 ! AS Path prepend for standby
"""
1-3. VPC 高度な設計パターン
VPC CIDR 設計原則:
【推奨CIDRレンジ】
- 10.0.0.0/8 (RFC1918): 最大 16,777,214 アドレス
- 172.16.0.0/12 (RFC1918)
- 192.168.0.0/16 (RFC1918)
【サブネット設計例 (3-AZ 構成)】
VPC: 10.1.0.0/16 (65,534 アドレス)
Public Subnets (Internet-facing):
10.1.1.0/24 - AZ-a (NAT GW, Load Balancer)
10.1.2.0/24 - AZ-b
10.1.3.0/24 - AZ-c
Private Subnets (Application):
10.1.11.0/24 - AZ-a (EC2, ECS)
10.1.12.0/24 - AZ-b
10.1.13.0/24 - AZ-c
Private Subnets (Database):
10.1.21.0/24 - AZ-a (RDS, ElastiCache)
10.1.22.0/24 - AZ-b
10.1.23.0/24 - AZ-c
Isolated Subnets (VPC Endpoints):
10.1.31.0/24 - AZ-a
10.1.32.0/24 - AZ-b
10.1.33.0/24 - AZ-c
AWS が予約するアドレス (各サブネットで5個):
x.x.x.0 ネットワークアドレス
x.x.x.1 VPCルーター
x.x.x.2 DNSリゾルバー
x.x.x.3 将来のAWS使用
x.x.x.255 ブロードキャスト
import boto3
ec2 = boto3.client('ec2', region_name='us-east-1')
# VPC Flow Logs の設定
def enable_vpc_flow_logs(
vpc_id: str,
log_group_name: str,
iam_role_arn: str,
traffic_type: str = 'ALL'
) -> dict:
return ec2.create_flow_logs(
ResourceIds=[vpc_id],
ResourceType='VPC',
TrafficType=traffic_type, # ACCEPT, REJECT, ALL
LogDestinationType='cloud-watch-logs',
LogGroupName=log_group_name,
DeliverLogsPermissionArn=iam_role_arn,
LogFormat=' '.join([
'${version}', '${account-id}', '${interface-id}',
'${srcaddr}', '${dstaddr}', '${srcport}', '${dstport}',
'${protocol}', '${packets}', '${bytes}',
'${start}', '${end}', '${action}', '${log-status}',
# 拡張フィールド
'${vpc-id}', '${subnet-id}', '${instance-id}',
'${tcp-flags}', '${type}', '${pkt-srcaddr}', '${pkt-dstaddr}'
]),
MaxAggregationInterval=60 # 60秒または600秒
)
# Flow Logs の分析 (CloudWatch Logs Insights)
FLOW_LOG_QUERIES = {
'top_talkers': """
fields srcAddr, dstAddr, bytes
| stats sum(bytes) as totalBytes by srcAddr, dstAddr
| sort totalBytes desc
| limit 20
""",
'rejected_traffic': """
fields srcAddr, dstAddr, srcPort, dstPort, action
| filter action = "REJECT"
| stats count() as rejectCount by srcAddr, dstAddr, dstPort
| sort rejectCount desc
| limit 20
""",
'security_group_analysis': """
fields interfaceId, srcAddr, dstAddr, dstPort, protocol, action
| filter action = "REJECT" and protocol = "6"
| stats count() by dstPort
| sort count desc
| limit 10
"""
}
# Network Access Analyzer でのセキュリティ分析
def create_network_access_scope(vpc_id: str) -> str:
"""不必要なネットワークアクセスパスを検出"""
response = ec2.create_network_insights_access_scope(
MatchPaths=[
{
'Source': {
'ResourceStatement': {
'Resources': [f'arn:aws:ec2:us-east-1:123456789:vpc/{vpc_id}']
}
},
'Destination': {
'ResourceStatement': {
'ResourceTypes': ['AWS::EC2::InternetGateway']
}
}
}
],
ExcludePaths=[
{
'Source': {
'ResourceStatement': {
'ResourceTypes': ['AWS::EC2::InternetGateway']
}
}
}
],
TagSpecifications=[{
'ResourceType': 'network-insights-access-scope',
'Tags': [{'Key': 'Purpose', 'Value': 'SecurityAudit'}]
}]
)
return response['NetworkInsightsAccessScope']['NetworkInsightsAccessScopeId']
Domain 2: ハイブリッドネットワーク接続
2-1. AWS Site-to-Site VPN 詳細
Site-to-Site VPN アーキテクチャ:
オンプレミス AWS
Customer Gateway (CGW) Virtual Private Gateway (VGW)
IP: 203.0.113.1 または
Transit Gateway
IPsec Tunnel 1 ──────────────────→ VPN Endpoint 1 (AZ-a)
IPsec Tunnel 2 ──────────────────→ VPN Endpoint 2 (AZ-b)
VPN 設定:
- 暗号化: AES-256
- 認証: SHA-256 / SHA-384 / SHA-512
- DH グループ: 14, 19, 20, 21 (推奨)
- IKE バージョン: IKEv1 または IKEv2
- Dead Peer Detection (DPD): 有効
BGP vs Static Routing:
BGP: 動的ルーティング、フェイルオーバー自動、ECMP対応
Static: シンプルだがフェイルオーバーは手動
import boto3
ec2 = boto3.client('ec2', region_name='us-east-1')
# Site-to-Site VPN の作成
def create_site_to_site_vpn(
customer_gateway_id: str,
tgw_id: str = None,
vgw_id: str = None,
bgp_asn: int = 65000
) -> dict:
options = {
'StaticRoutesOnly': False, # BGP使用
'TunnelInsideIpVersion': 'ipv4',
'TunnelOptions': [
{
'TunnelInsideCidr': '169.254.100.0/30',
'PreSharedKey': 'your-pre-shared-key-1',
'Phase1LifetimeSeconds': 28800,
'Phase2LifetimeSeconds': 3600,
'Phase1DHGroupNumbers': [{'Value': 14}],
'Phase2DHGroupNumbers': [{'Value': 14}],
'Phase1EncryptionAlgorithms': [{'Value': 'AES256'}],
'Phase2EncryptionAlgorithms': [{'Value': 'AES256'}],
'Phase1IntegrityAlgorithms': [{'Value': 'SHA2-256'}],
'Phase2IntegrityAlgorithms': [{'Value': 'SHA2-256'}],
'StartupAction': 'start', # or 'add'
'DPDTimeoutAction': 'restart',
'DPDTimeoutSeconds': 30
},
{
'TunnelInsideCidr': '169.254.101.0/30',
'PreSharedKey': 'your-pre-shared-key-2',
# ... same settings
}
]
}
if tgw_id:
response = ec2.create_vpn_connection(
Type='ipsec.1',
CustomerGatewayId=customer_gateway_id,
TransitGatewayId=tgw_id,
Options=options
)
elif vgw_id:
response = ec2.create_vpn_connection(
Type='ipsec.1',
CustomerGatewayId=customer_gateway_id,
VpnGatewayId=vgw_id,
Options=options
)
return response['VpnConnection']
# VPN 状態監視
def monitor_vpn_tunnels(vpn_connection_id: str) -> dict:
cw = boto3.client('cloudwatch')
metrics = {}
for tunnel_index in [0, 1]:
# TunnelState: 0 = Down, 1 = Up
response = cw.get_metric_statistics(
Namespace='AWS/VPN',
MetricName='TunnelState',
Dimensions=[
{'Name': 'VpnId', 'Value': vpn_connection_id},
{'Name': 'TunnelIpAddress', 'Value': f'tunnel-{tunnel_index+1}'}
],
StartTime='2024-01-01T00:00:00Z',
EndTime='2024-01-01T01:00:00Z',
Period=300,
Statistics=['Average']
)
metrics[f'tunnel_{tunnel_index+1}'] = response['Datapoints']
return metrics
2-2. AWS PrivateLink の設計
PrivateLink アーキテクチャ:
Consumer VPC Provider VPC (サービス提供者)
┌─────────────────┐ ┌──────────────────────────────┐
│ EC2 Instance │ │ NLB → Service (EC2/ECS/etc) │
│ ↓ │ │ │
│ Interface │ │ Endpoint Service │
│ Endpoint (ENI) │ │ (Acceptance Required: Yes) │
│ ↓ │ └──────────────────────────────┘
│ Private DNS │ ↑
│ (Automatic) │ ←── PrivateLink ──────┘
└─────────────────┘
メリット:
- データがインターネットを経由しない
- VPCピアリング不要(アドレス重複OK)
- 一方向通信(Consumerからのみ)
- AWS サービスエンドポイントにも使用(S3, EC2等)
VPC エンドポイント種類:
Gateway Endpoint: S3, DynamoDB (無料, ルートテーブル経由)
Interface Endpoint: 他のAWSサービス + PrivateLink (ENI作成, 時間課金)
Gateway Load Balancer Endpoint: 3rd partyセキュリティアプライアンス
# PrivateLink エンドポイントサービスの設定
def create_endpoint_service(
nlb_arns: list,
acceptance_required: bool = True
) -> dict:
response = ec2.create_vpc_endpoint_service_configuration(
NetworkLoadBalancerArns=nlb_arns,
AcceptanceRequired=acceptance_required,
PrivateDnsName='api.example.com', # プライベートDNS名
TagSpecifications=[{
'ResourceType': 'vpc-endpoint-service',
'Tags': [{'Key': 'Name', 'Value': 'MyAPIService'}]
}]
)
return response['ServiceConfiguration']
def accept_endpoint_connection(
service_id: str,
connection_id: str
) -> None:
ec2.accept_vpc_endpoint_connections(
ServiceId=service_id,
VpcEndpointIds=[connection_id]
)
# Interface Endpoint の作成 (Consumer側)
def create_interface_endpoint(
vpc_id: str,
service_name: str,
subnet_ids: list,
sg_ids: list
) -> dict:
return ec2.create_vpc_endpoint(
VpcEndpointType='Interface',
VpcId=vpc_id,
ServiceName=service_name,
SubnetIds=subnet_ids,
SecurityGroupIds=sg_ids,
PrivateDnsEnabled=True # プライベートDNS自動設定
)
Domain 3: エッジネットワークとコンテンツデリバリー
3-1. Amazon CloudFront 高度な設定
CloudFront アーキテクチャ:
User → Edge Location (POP) → Regional Edge Cache → Origin
(またはOriginShield)
キャッシュ戦略:
TTL設定:
min-TTL: 0秒 (動的コンテンツ)
max-TTL: 31536000秒 (1年, 静的コンテンツ)
default-TTL: 86400秒 (1日, デフォルト)
キャッシュキー:
- URL Path (必須)
- Query String (選択可)
- Headers (選択可, 原則最小限)
- Cookies (選択可, 原則最小限)
セキュリティ:
- WAF (Web Application Firewall) 統合
- AWS Shield Standard (デフォルト無料)
- AWS Shield Advanced (追加費用)
- HTTPS強制 (Viewer Protocol Policy)
- Field Level Encryption (特定フィールドの暗号化)
- Origin Access Control (OAC): S3へのアクセスをCFDのみに制限
import boto3
import json
cf = boto3.client('cloudfront', region_name='us-east-1')
# CloudFront Distribution の作成
def create_cloudfront_distribution(
s3_bucket: str,
domain_names: list,
acm_cert_arn: str,
waf_acl_id: str = None
) -> dict:
config = {
'CallerReference': str(int(time.time())),
'Aliases': {
'Quantity': len(domain_names),
'Items': domain_names
},
'DefaultRootObject': 'index.html',
'Origins': {
'Quantity': 1,
'Items': [
{
'Id': 's3-origin',
'DomainName': f'{s3_bucket}.s3.amazonaws.com',
'S3OriginConfig': {
'OriginAccessIdentity': '' # OACを使用
},
'OriginAccessControlId': 'OAC_ID' # Origin Access Control
}
]
},
'DefaultCacheBehavior': {
'TargetOriginId': 's3-origin',
'ViewerProtocolPolicy': 'redirect-to-https',
'CachePolicyId': '658327ea-f89d-4fab-a63d-7e88639e58f6', # CachingOptimized
'AllowedMethods': {
'Quantity': 2,
'Items': ['GET', 'HEAD'],
'CachedMethods': {
'Quantity': 2,
'Items': ['GET', 'HEAD']
}
},
'Compress': True,
'FunctionAssociations': {
'Quantity': 0,
'Items': []
}
},
'CacheBehaviors': {
'Quantity': 1,
'Items': [
{
'PathPattern': '/api/*',
'TargetOriginId': 's3-origin',
'ViewerProtocolPolicy': 'https-only',
'CachePolicyId': '4135ea2d-6df8-44a3-9df3-4b5a84be39ad', # CachingDisabled
'OriginRequestPolicyId': '88a5eaf4-2fd4-4709-b370-b4c650ea3fcf' # CORS-S3Origin
}
]
},
'CustomErrorResponses': {
'Quantity': 2,
'Items': [
{
'ErrorCode': 403,
'ResponsePagePath': '/index.html',
'ResponseCode': '200',
'ErrorCachingMinTTL': 300
},
{
'ErrorCode': 404,
'ResponsePagePath': '/404.html',
'ResponseCode': '404',
'ErrorCachingMinTTL': 30
}
]
},
'PriceClass': 'PriceClass_All', # PriceClass_100, PriceClass_200, PriceClass_All
'Enabled': True,
'HttpVersion': 'http2and3',
'IsIPV6Enabled': True,
'ViewerCertificate': {
'ACMCertificateArn': acm_cert_arn,
'SSLSupportMethod': 'sni-only',
'MinimumProtocolVersion': 'TLSv1.2_2021'
}
}
if waf_acl_id:
config['WebACLId'] = waf_acl_id
return cf.create_distribution(DistributionConfig=config)
# CloudFront Functions (エッジでの軽量処理)
CLOUDFRONT_FUNCTION = """
function handler(event) {
var request = event.request;
var uri = request.uri;
// URLリダイレクト
if (uri.endsWith('/')) {
request.uri = uri + 'index.html';
} else if (!uri.includes('.')) {
request.uri = uri + '/index.html';
}
// セキュリティヘッダーの追加 (Viewer Response)
// var response = event.response;
// response.headers['strict-transport-security'] = {value: 'max-age=63072000'};
return request;
}
"""
3-2. AWS Global Accelerator
Global Accelerator vs CloudFront:
┌──────────────────────────────────────────────────────────────┐
│ Global Accelerator vs CloudFront │
├──────────────────┬───────────────────┬───────────────────────┤
│ 項目 │ Global Accelerator│ CloudFront │
├──────────────────┼───────────────────┼───────────────────────┤
│ 主な用途 │ TCP/UDP最適化 │ HTTPSコンテンツ配信 │
│ キャッシュ │ なし │ あり │
│ エンドポイント種類 │ ELB, EC2, EIP │ S3, HTTP Origin │
│ プロトコル │ TCP, UDP │ HTTP/S │
│ 固定IP │ あり (Anycast) │ なし (DNS) │
│ ヘルスチェック │ 詳細設定可能 │ あり │
│ トラフィック制御 │ 重み付けルーティング│ Cache Behavior │
│ 使用例 │ ゲーム, IoT, VoIP │ Webサイト, API │
└──────────────────┴───────────────────┴───────────────────────┘
Global Accelerator の動作:
User → Nearest PoP (Anycast IP) → AWS Backbone → Endpoint
通常: User → Internet → AWS Region
AWSバックボーン経由でパケット損失が少なく低レイテンシ実現
import boto3
ga = boto3.client('globalaccelerator', region_name='us-east-1')
# Global Accelerator の作成
def create_global_accelerator(
name: str,
endpoint_groups: list
) -> dict:
# Accelerator作成
accel_response = ga.create_accelerator(
Name=name,
IpAddressType='IPV4',
Enabled=True,
Tags=[{'Key': 'Name', 'Value': name}]
)
accelerator_arn = accel_response['Accelerator']['AcceleratorArn']
# リスナー作成
listener_response = ga.create_listener(
AcceleratorArn=accelerator_arn,
Protocol='TCP',
PortRanges=[
{'FromPort': 443, 'ToPort': 443},
{'FromPort': 80, 'ToPort': 80}
],
ClientAffinity='SOURCE_IP' # セッション持続性
)
listener_arn = listener_response['Listener']['ListenerArn']
# エンドポイントグループ作成 (リージョンごと)
for endpoint_group in endpoint_groups:
ga.create_endpoint_group(
ListenerArn=listener_arn,
EndpointGroupRegion=endpoint_group['region'],
EndpointConfigurations=[
{
'EndpointId': endpoint_group['alb_arn'],
'Weight': endpoint_group.get('weight', 100),
'ClientIPPreservationEnabled': True
}
],
TrafficDialPercentage=endpoint_group.get('traffic_dial', 100.0),
HealthCheckPort=443,
HealthCheckProtocol='HTTPS',
HealthCheckPath='/health',
HealthCheckIntervalSeconds=30,
ThresholdCount=3
)
return {
'accelerator_arn': accelerator_arn,
'dns_name': accel_response['Accelerator']['DnsName'],
'ip_sets': accel_response['Accelerator']['IpSets']
}
Domain 4: ネットワークセキュリティ
4-1. AWS Network Firewall
Network Firewall アーキテクチャ:
Internet Gateway
↓
Firewall Subnet (Network Firewall)
↓ (Stateful/Stateless ルール検査)
Application Subnet (EC2/ECS)
Firewall ルール種類:
1. Stateless Rules: 単純なパケットフィルタリング (IP/Port/Protocol)
2. Stateful Rules (Suricata): 深いパケット検査
- Standard: プロトコル認識
- Domain List: ドメインフィルタ
- Suricata IPS: カスタムIDS/IPSルール
3. TLS Inspection: SSL/TLSインスペクション
import boto3
import json
nfw = boto3.client('network-firewall', region_name='us-east-1')
# Firewall ポリシーの作成
def create_firewall_policy(name: str) -> dict:
# ルールグループ: ドメインブロックリスト
domain_block_rg = nfw.create_rule_group(
RuleGroupName=f'{name}-domain-blocklist',
Type='STATEFUL',
Capacity=100,
RuleGroup={
'RulesSource': {
'RulesSourceList': {
'Targets': [
'.malware.example.com',
'.phishing.example.com'
],
'TargetTypes': ['TLS_SNI', 'HTTP_HOST'],
'GeneratedRulesType': 'DENYLIST'
}
}
},
Tags=[{'Key': 'Name', 'Value': f'{name}-domain-blocklist'}]
)
# ルールグループ: カスタム Suricata ルール
custom_rg = nfw.create_rule_group(
RuleGroupName=f'{name}-custom-rules',
Type='STATEFUL',
Capacity=200,
RuleGroup={
'RulesSource': {
'RulesString': '\n'.join([
# SQL インジェクション検出
'alert http any any -> any any (msg:"SQL Injection Attempt"; content:"UNION SELECT"; nocase; sid:1000001;)',
# ポートスキャン検出
'alert tcp any any -> $HOME_NET 22 (msg:"SSH Brute Force Attempt"; flow:to_server; threshold:type both,track by_src,count 5,seconds 60; sid:1000002;)',
# データ漏洩防止
'alert http $HOME_NET any -> any any (msg:"Potential Data Exfiltration"; content:"credit card"; nocase; sid:1000003;)'
])
}
}
)
# Firewall ポリシーの作成
policy_response = nfw.create_firewall_policy(
FirewallPolicyName=name,
FirewallPolicy={
'StatelessDefaultActions': ['aws:forward_to_sfe'], # Statefulに転送
'StatelessFragmentDefaultActions': ['aws:drop'],
'StatelessRuleGroupReferences': [],
'StatefulDefaultActions': ['aws:drop_strict'], # デフォルトDROP
'StatefulEngineOptions': {
'RuleOrder': 'STRICT_ORDER'
},
'StatefulRuleGroupReferences': [
{
'ResourceArn': domain_block_rg['RuleGroupResponse']['RuleGroupArn'],
'Priority': 1
},
{
'ResourceArn': custom_rg['RuleGroupResponse']['RuleGroupArn'],
'Priority': 2
},
{
'ResourceArn': 'arn:aws:network-firewall:us-east-1:aws-managed:stateful-rulegroup/ThreatSignaturesMalwareWeb',
'Priority': 100
}
]
}
)
return policy_response
# Network Firewall のデプロイ
def deploy_firewall(
vpc_id: str,
subnet_mappings: list,
policy_arn: str,
name: str
) -> dict:
return nfw.create_firewall(
FirewallName=name,
FirewallPolicyArn=policy_arn,
VpcId=vpc_id,
SubnetMappings=subnet_mappings,
DeleteProtection=True,
FirewallPolicyChangeProtection=True,
Tags=[{'Key': 'Name', 'Value': name}]
)
4-2. Security Groups と NACLs の比較
Security Groups vs NACLs:
┌─────────────────────────────────────────────────────────────┐
│ Security Groups │ NACLs │
├────────────────────────────────────┼─────────────────────────┤
│ インスタンスレベル │ サブネットレベル │
│ ステートフル (応答自動許可) │ ステートレス │
│ 許可ルールのみ │ 許可/拒否ルール両方 │
│ 全ルールを評価 │ 番号順に評価(最初にマッチ)│
│ 1〜1000ルール │ 1〜32766ルール │
└────────────────────────────────────┴─────────────────────────┘
推奨パターン:
- NACLs: 広いIP範囲のブロック (DDoS対策, 国別ブロック)
- SG: アプリレベルの細かいアクセス制御
セキュリティグループの参照:
# 同じSGのインスタンス間通信 (例: ECS タスク間)
aws ec2 authorize-security-group-ingress \
--group-id sg-app \
--protocol tcp \
--port 8080 \
--source-group sg-app # 自己参照
Domain 5: ネットワーク管理と運用
5-1. Amazon Route 53 高度な設定
import boto3
r53 = boto3.client('route53', region_name='us-east-1')
# フェイルオーバーポリシーの設定
def configure_route53_failover(
hosted_zone_id: str,
domain: str,
primary_alb_dns: str,
secondary_alb_dns: str
) -> None:
# ヘルスチェックの作成
primary_hc = r53.create_health_check(
CallerReference=f'primary-{int(time.time())}',
HealthCheckConfig={
'Type': 'HTTPS',
'FullyQualifiedDomainName': primary_alb_dns,
'Port': 443,
'ResourcePath': '/health',
'FailureThreshold': 3,
'RequestInterval': 30,
'EnableSNI': True
}
)
# Failover: PRIMARY レコード
r53.change_resource_record_sets(
HostedZoneId=hosted_zone_id,
ChangeBatch={
'Changes': [
{
'Action': 'CREATE',
'ResourceRecordSet': {
'Name': domain,
'Type': 'CNAME',
'SetIdentifier': 'primary',
'Failover': 'PRIMARY',
'TTL': 30,
'ResourceRecords': [{'Value': primary_alb_dns}],
'HealthCheckId': primary_hc['HealthCheck']['Id']
}
},
{
'Action': 'CREATE',
'ResourceRecordSet': {
'Name': domain,
'Type': 'CNAME',
'SetIdentifier': 'secondary',
'Failover': 'SECONDARY',
'TTL': 30,
'ResourceRecords': [{'Value': secondary_alb_dns}]
}
}
]
}
)
# Geolocation ルーティング
def configure_geolocation_routing(
hosted_zone_id: str,
domain: str,
regions: dict # {'JP': 'jp-alb.example.com', 'US': 'us-alb.example.com', 'DEFAULT': 'default-alb.example.com'}
) -> None:
changes = []
for geo_code, endpoint in regions.items():
geo_location = {}
if geo_code == 'DEFAULT':
geo_location = {'CountryCode': '*'}
elif len(geo_code) == 2:
geo_location = {'CountryCode': geo_code}
else:
geo_location = {'ContinentCode': geo_code}
changes.append({
'Action': 'CREATE',
'ResourceRecordSet': {
'Name': domain,
'Type': 'CNAME',
'SetIdentifier': f'geo-{geo_code}',
'GeoLocation': geo_location,
'TTL': 60,
'ResourceRecords': [{'Value': endpoint}]
}
})
r53.change_resource_record_sets(
HostedZoneId=hosted_zone_id,
ChangeBatch={'Changes': changes}
)
# Route 53 Resolver DNS Firewall
def create_dns_firewall(
vpc_id: str,
blocked_domains: list
) -> dict:
r53resolver = boto3.client('route53resolver', region_name='us-east-1')
# ドメインリストの作成
domain_list = r53resolver.create_firewall_domain_list(
Name='BlockedDomains',
)
r53resolver.import_firewall_domains(
FirewallDomainListId=domain_list['FirewallDomainList']['Id'],
Operation='REPLACE',
Domains=blocked_domains
)
# ルールグループ作成
rule_group = r53resolver.create_firewall_rule_group(
Name='DNSFirewallRuleGroup'
)
# ルール追加 (ブロック)
r53resolver.create_firewall_rule(
FirewallRuleGroupId=rule_group['FirewallRuleGroup']['Id'],
FirewallDomainListId=domain_list['FirewallDomainList']['Id'],
Priority=1,
Action='BLOCK',
BlockResponse='NXDOMAIN'
)
# VPCへのアタッチ
r53resolver.associate_firewall_rule_group(
FirewallRuleGroupId=rule_group['FirewallRuleGroup']['Id'],
VpcId=vpc_id,
Priority=100,
Name='DNS-Firewall-Association'
)
return rule_group
5-2. ネットワーク監視とトラブルシューティング
# VPC Reachability Analyzer でのパス分析
def analyze_network_path(
source_id: str,
destination_id: str,
protocol: str = 'tcp',
port: int = 443
) -> dict:
# ネットワークインサイトパスの作成
path_response = ec2.create_network_insights_path(
Source=source_id, # ENI, Instance, VPC Endpoint 等
Destination=destination_id,
Protocol=protocol,
DestinationPort=port,
TagSpecifications=[{
'ResourceType': 'network-insights-path',
'Tags': [{'Key': 'Purpose', 'Value': 'Troubleshooting'}]
}]
)
path_id = path_response['NetworkInsightsPath']['NetworkInsightsPathId']
# 分析の実行
analysis_response = ec2.start_network_insights_analysis(
NetworkInsightsPathId=path_id
)
analysis_id = analysis_response['NetworkInsightsAnalysis']['NetworkInsightsAnalysisId']
# 結果待機
import time
while True:
result = ec2.describe_network_insights_analyses(
NetworkInsightsAnalysisIds=[analysis_id]
)
analysis = result['NetworkInsightsAnalyses'][0]
status = analysis['Status']
if status == 'succeeded':
return {
'reachable': analysis.get('NetworkPathFound', False),
'explanations': analysis.get('Explanations', []),
'forward_path': analysis.get('ForwardPathComponents', [])
}
elif status == 'failed':
raise Exception(f"Analysis failed: {analysis.get('StatusMessage')}")
time.sleep(5)
# CloudWatch Logs Insights でのフローログ分析
USEFUL_FLOW_LOG_QUERIES = {
'rejected_by_nacl': """
fields srcAddr, dstAddr, dstPort, action
| filter action = "REJECT"
| filter logStatus = "OK"
| stats count() as rejectCount by srcAddr, dstPort
| sort rejectCount desc
| limit 20
""",
'bandwidth_by_instance': """
fields interfaceId, bytes
| stats sum(bytes) as totalBytes by interfaceId
| sort totalBytes desc
| limit 20
""",
'unusual_ports': """
fields dstPort, protocol
| filter dstPort not in [80, 443, 22, 3306, 5432]
| filter action = "ACCEPT"
| stats count() by dstPort, protocol
| sort count desc
| limit 20
"""
}
模擬試験 第1回 (65問)
Part 1: VPC とネットワーク基礎 (問1-20)
問1: VPC のCIDRブロックを後から追加できるか?
A) 不可能 B) VPCに最大5個のIPv4 CIDRブロックを追加できる (セカンダリCIDR) C) 作成後は変更不可 D) IPv6のみ追加可能
正解: B 解説: VPCはプライマリCIDRに加え、最大4個のセカンダリIPv4 CIDRブロックを追加できる(合計5個)。ただし既存のCIDRとの重複は不可。IPv6はIPv6 CIDRブロックとして別途追加。
問2: VPCピアリング接続でのルーティング制限は?
A) 全トラフィックが自動的にルーティングされる B) エッジツーエッジルーティング(ピアリング経由でのVPN/DirectConnect/インターネットアクセス)は不可能 C) 同一リージョンのみ対応 D) IPv4のみ対応
正解: B 解説: VPCピアリングはP2P接続で推移的ルーティングはサポートしない。VPC-A←→VPC-B←→VPC-Cの構成でVPC-AからVPC-CへはVPC-B経由では通信できない。また、VPC-B経由でのインターネットやDXへのアクセスも不可。
問3: AWS Transit Gateway と VPCピアリングの使い分けは?
A) 機能は同じ B) 接続するVPCが3個以上の場合はTGW(Hub-and-Spoke), 2VPCの場合はピアリングがシンプル C) TGWは常にピアリングより高速 D) ピアリングはマルチリージョン不可
正解: B 解説: VPCピアリングはN²(二乗)のメッシュ接続が必要でスケールしない。TGWはHub-and-Spoke構成でO(N)の接続数に抑えられる。また、TGWはオンプレミスへのVPN/DX接続もサポートし、一元管理が可能。
問4: NATゲートウェイの可用性を確保するための設計は?
A) 1つのNATゲートウェイで全AZをカバー B) 各AZのPublic SubnetにNATゲートウェイを1つずつ配置し、各Private SubnetのルートテーブルをAZ内のNATに向ける C) NATゲートウェイは自動的にマルチAZで動作 D) NATゲートウェイは高可用性のため1リージョンに1つのみ
正解: B 解説: AZ-aのNATがダウンした場合に他AZのPrivate SubnetからのNATトラフィックが影響を受けないよう、各AZに1つのNATゲートウェイを配置し、AZ内のルートテーブルをAZ内のNATに向けるのが推奨設計。
問5: AWS PrivateLinkのエンドポイントサービスを公開する際に必要なロードバランサーの種類は?
A) Application Load Balancer B) Network Load Balancer C) Classic Load Balancer D) Gateway Load Balancer
正解: B 解説: PrivateLinkのエンドポイントサービスはNetwork Load Balancer(NLB)またはGateway Load Balancer(GWLB)をサポートする。ALBは直接サポートしない(NLBをALBの前に配置するパターンで対応可能)。
問6: VPC Flow LogsでICMPトラフィックのprotocol番号は?
A) 6 (TCP) B) 17 (UDP) C) 1 (ICMP) D) 0 (ALL)
正解: C
解説: プロトコル番号: 1=ICMP, 6=TCP, 17=UDP, 50=ESP(IPsec), 51=AH(IPsec)。Flow Logsのフィルター: filter protocol = 1でICMPのみ抽出できる。
問7: Direct Connect のVirtual Interface (VIF) でPublic VIFを使用する場合に接続できるのは?
A) VPC内のプライベートIPアドレス B) AWSのパブリックエンドポイント (S3, DynamoDB, EC2 APIなど) C) オンプレミスのリソース D) インターネット全般
正解: B 解説: Public VIFはAWS パブリックIPアドレス空間(S3, DynamoDB, API Gateway等のAWSマネージドサービス)へのプライベートネットワーク経由アクセスに使用。Private VIFはVPC内のプライベートIPアドレスへのアクセス。
問8: Elastic Load Balancing でTCP/UDPの低レイテンシ負荷分散が必要な場合のELBタイプは?
A) Application Load Balancer (ALB) B) Network Load Balancer (NLB) C) Classic Load Balancer D) Gateway Load Balancer
正解: B 解説: NLBはレイヤー4(TCP/UDP/TLS)で動作し、超低レイテンシ(マイクロ秒単位)と高スループット(数百万req/sec)を提供。ゲームサーバー、IoTデバイス、リアルタイムアプリに最適。ALBはHTTP/HTTPSのみ。
問9: ALBで同一ドメインへのリクエストをパスベースでルーティングする設定は?
A) Route 53の加重ルーティング B) ALBのリスナーにパスベースのルーティングルールを追加 C) CloudFrontのCache Behavior D) NLBのポートベースルーティング
正解: B
解説: ALBはリスナールールで/api/*→ターゲットグループA、/static/*→ターゲットグループBのようなパスベースルーティングをサポート。ヘッダー、クエリ文字列、ホスト名、送信元IPによるルーティングも可能。
問10: VPCエンドポイントポリシーの役割は?
A) VPC内のインスタンスのIAM権限を制御 B) エンドポイントを通じたAWSサービスへのアクセスをIPアドレスや操作単位で制限 C) エンドポイントの料金を管理 D) エンドポイントのパフォーマンスを設定
正解: B 解説: エンドポイントポリシーはリソースベースポリシーで、S3バケットへの特定操作(GetObject/PutObjectのみ許可)や特定S3バケットのみアクセス許可などの細粒度制御が可能。IAMポリシーと組み合わせて使用。
問11: Route 53 でヘルスチェックを使用した自動フェイルオーバーの設定方法は?
A) ヘルスチェックは自動的にフェイルオーバーを設定する B) ヘルスチェックを作成し、FailoverルーティングポリシーのレコードにヘルスチェックIDを関連付ける C) Route 53はフェイルオーバーをサポートしない D) ヘルスチェックはALBのみに使用可能
正解: B 解説: フェイルオーバー設定: (1)ヘルスチェック作成 (2)PRIMARY/SECONDARYポリシーのDNSレコード作成 (3)PRIMARYレコードにヘルスチェックを関連付け。ヘルスチェック失敗時にSECONDARYに自動切替。
問12: AWS Network Firewall を配置する最適な場所は?
A) Internet Gatewayと同じサブネット B) 専用のFirewall Subnetに配置し、ルートテーブルでトラフィックをFirewallエンドポイント経由に設定 C) アプリケーションと同じサブネット D) VGW の後段
正解: B 解説: Firewall Subnetは各AZに専用サブネットを作成し、IGW Route Table: Inbound→Firewall Endpoint, Firewall Route Table: Firewall→App Subnet, App Route Table: Outbound→Firewallというルーティング設計が必要。
問13: CloudFront Origin Shield を使用する主な目的は?
A) HTTPS強制 B) オリジンへのリクエスト数を削減し、キャッシュヒット率を向上させるための追加キャッシュレイヤー C) コンテンツの暗号化 D) DDoS対策
正解: B 解説: Origin Shieldは地域的なエッジキャッシュとオリジンの間に追加のキャッシュレイヤーを提供し、オリジンに届くリクエスト数を最大で数倍削減できる。地理的に分散したユーザーへのサービスで効果的。
問14: VPNとDirect Connectの両方を同じTGWに接続した場合、デフォルトではどちらのルートが優先されるか?
A) VPN B) Direct Connect (BGP AS_PATH が短く、より具体的なルートを使用) C) 同じ重みで自動ECMP D) 管理者が設定した順序
正解: B 解説: BGPルートの優先順位(高い順): 1.Static Route, 2.Direct Connect BGP, 3.VPN BGP。同じAWS経路でも、DXのほうが一般的に高い優先度を持つ。VPNをバックアップにするにはAS_PATHプリペンドで調整する。
問15: AWS Transit Gateway Connect を使用する場面は?
A) VPCのアタッチメント標準方法 B) SD-WANアプライアンス等のサードパーティNVAからTGWへのGREトンネルで高スループット(最大20Gbps)接続 C) Direct Connectの接続方法 D) VPN接続の暗号化強化
正解: B 解説: TGW ConnectはGRE(Generic Routing Encapsulation)トンネルを使用して、TGWアタッチメント(VPC or DX)の上にオーバーレイするGREトンネルを確立し、BGPで動的ルーティングを実現。最大20Gbpsの帯域をサポート。
問16: AWS Global Accelerator の「Traffic Dial」設定の目的は?
A) トラフィックの優先順位付け B) エンドポイントグループへのトラフィック割合(0-100%)を設定し、段階的なカナリアデプロイやフェイルオーバーテストに使用 C) レイテンシの調整 D) コストの最適化
正解: B 解説: Traffic Dialはエンドポイントグループ単位でトラフィック割合を0-100%で設定。Blue/Greenデプロイ時に新リージョンへのトラフィックを0%→10%→50%→100%と段階的に増やすカナリアデプロイが可能。
問17: Route 53 の Resolver Endpoints の役割は?
A) パブリックDNSの解決 B) Inbound: オンプレからVPCのDNSへのフォワード, Outbound: VPCからオンプレDNSへのフォワード C) CloudFrontとの統合 D) 自動ヘルスチェック
正解: B 解説: Resolver Inbound Endpointはオンプレミスからプライベートホストゾーンの名前解決を可能にする。Outbound EndpointはVPCのResolver Rulesに基づいてオンプレミスのDNSサーバーにクエリを転送する。
問18: Network Load Balancer でClient IPを保持する設定は?
A) デフォルトで保持 B) NLBのTarget TypeがIPの場合はProxyProtocol v2, Instanceの場合はClientIPPreservation設定 C) ALBのみClientIP保持可能 D) ClientIP保持は不可
正解: B 解説: NLBのTarget typeがInstanceの場合、デフォルトでClientIPが保持。Target typeがIPの場合はProxy Protocol v2を有効にし、アプリがプロキシプロトコルヘッダーを解析する必要がある。
問19: VPC の DNS設定で enableDnsHostnames を有効にする必要がある場面は?
A) すべてのVPCで必須 B) EC2インスタンスにPublicDNSホスト名を割り当てたい場合、またはPrivate HostedZoneのDNS解決に使用 C) プライベートIPのみ使用する場合 D) ENI作成時のみ必要
正解: B 解説: enableDnsHostnames=trueにするとEC2インスタンスにパブリックDNSホスト名(ip-10-0-1-1.ec2.internal等)が付与される。Route 53のプライベートホストゾーンでDNS解決するにはenableDnsSupport=trueとenableDnsHostnames=trueの両方が必要。
問20: GWLB (Gateway Load Balancer) の主な用途は?
A) HTTPアプリケーションの負荷分散 B) サードパーティのネットワークアプライアンス(FW, IDS/IPS, DPI)をスケーラブルに挿入 C) RDSへの接続プール管理 D) CDNコンテンツのキャッシュ
正解: B 解説: GWLBはGENEVEプロトコル(UDP 6081)でパケットをトランスペアレントにサードパーティNVAに転送し、検査後に返却する。NVAのスケーリング・フェイルオーバーを自動化し、トラフィックの透過的な挿入を実現。
Part 2: ハイブリッド・エッジ (問21-45)
問21: Direct Connect の最小帯域幅と最大帯域幅は?
A) 10Mbps - 10Gbps B) 50Mbps - 100Gbps (HostedConnectionは50Mbps/100Mbps/200Mbps/300Mbps/400Mbps/500Mbps/1Gbps/2Gbps/5Gbps/10Gbps, 専用接続は1Gbps/10Gbps/100Gbps) C) 1Gbps - 10Gbps D) 100Mbps - 40Gbps
正解: B 解説: Dedicated Connection: 1Gbps, 10Gbps, 100Gbps。Hosted Connection: パートナー経由で50Mbpsから最大10Gbps。LAG(Link Aggregation Group)で複数接続を束ねて最大400Gbpsまで対応可能。
問22: Site-to-Site VPN の最大スループットは?
A) 100Mbps B) 1.25Gbps (per tunnel) C) 10Gbps D) 制限なし
正解: B 解説: Site-to-Site VPNの1トンネルあたりの最大スループットは約1.25Gbps。TGWにECMP対応VPN接続を複数作成することで等コストマルチパスにより実効スループットを増やすことができる(最大50Gbps程度)。
問23: Direct Connect と VPN を組み合わせたハイブリッド設計で、DXをプライマリ・VPNをバックアップにする方法は?
A) VPNにより高い優先度を設定 B) DXのBGPルートにLocal Preferenceを高く設定し、VPNはAS_PATHプリペンドで優先度を下げる C) ランダムに選択される D) DXは常に自動的に優先される
正解: B 解説: BGP設定: DXのBGP Local-Preferenceを200に設定→DXダウン時にVPN(Local-Preference 100)に自動フェイルオーバー。オンプレ側: VPNルートにAS_PATHプリペンドでDXを優先させる。
問24: CloudFront でオリジンとしてALBを使用する場合のセキュリティ強化方法は?
A) オリジンをパブリックに公開 B) CloudFrontのマネージドプレフィックスリストをALBのSGで許可し、オリジンへの直接アクセスを防ぐ C) HTTPSは使用できない D) CloudFrontのみからのアクセスはデフォルトで制限できない
正解: B
解説: com.amazonaws.global.cloudfront.origin-facingというマネージドプレフィックスリストをALBのセキュリティグループのインバウンドルールに追加し、CloudFrontのIPからのみアクセスを許可する。
問25: Route 53 Latency Based RoutingとGeolocation Routingの違いは?
A) 機能は同じ B) Latencyは実測レイテンシを基に最適なリージョンにルーティング、Geolocationはユーザーの地理的場所に基づいてルーティング C) Geolocationはレイテンシを考慮する D) Latencyは地理情報のみ使用
正解: B 解説: Latency Based Routing: DNSクエリ発信元から各リージョンへの測定済みレイテンシに基づいて最小レイテンシのリージョンに誘導。Geolocation: ユーザーの物理的な国/大陸に基づいてルーティング(コンプライアンスや言語対応に使用)。
問26: VPC エンドポイント経由でS3にアクセスする際、エンドポイントポリシーとS3バケットポリシーの両方が必要か?
A) エンドポイントポリシーのみで十分 B) 両方を設定する必要がある (どちらもDENYなし・ALLOWが必要) C) バケットポリシーのみで十分 D) IAMポリシーのみで十分
正解: B 解説: アクセス評価順: (1)IAMポリシー (2)エンドポイントポリシー (3)S3バケットポリシー。3つ全てで許可されている場合のみアクセス可能。どれか1つでDENYがあればアクセス拒否。
問27: AWS CloudWAN の主な用途は?
A) CloudFront のWAN最適化 B) グローバルなWAN/SD-WANをAWSコンソールから管理し、TGW+Direct Connect+VPNを統合管理 C) VPC間通信の暗号化 D) ゲートウェイの自動スケーリング
正解: B 解説: Cloud WANはグローバルネットワーク管理サービスで、複数リージョンのTGWを接続するTGW Peering、Direct Connect、VPN接続をポリシードリブンで一元管理。SD-WANとAWSネットワークをポリシーで管理。
問28: ENI (Elastic Network Interface) の主な活用パターンは?
A) ENIは単純に1 VM = 1 ENI B) 複数ENI: デュアルホーム構成, セカンダリENIによる高速フェイルオーバー, EIP/MAC分離 C) ENIはIPアドレス管理のみ D) ENIはECSのみ使用
正解: B 解説: ENI活用パターン: (1)NVAのデュアルホーム(パブリック/プライベート) (2)プライマリENI障害時にセカンダリENIを別インスタンスにアタッチして即時フェイルオーバー (3)Licensing bindingのためMACアドレス固定 (4)複数IPアドレスの割り当て。
問29: EgressOnly Internet Gateway の目的は?
A) アウトバウンド専用のIPv4インターネット接続 B) IPv6インスタンスにアウトバウンド専用のインターネット接続を提供(インバウンドをブロック) C) NATゲートウェイの代替 D) IPv6のDNS解決
正解: B 解説: Egress-Only IGWはIPv6専用のNATゲートウェイのような機能で、プライベートサブネットのIPv6インスタンスからのアウトバウンド通信を許可しつつ、インターネットからのインバウンドをブロックする。
問30: AWS VPN CloudHub の用途は?
A) 複数のVPCを接続するハブ B) 複数のオンプレミスサイトをVGW経由でスポーク型に接続し、サイト間通信も可能にする C) クラウドへのVPN接続を最適化 D) マルチリージョンVPN
正解: B 解説: VPN CloudHubは1つのVGWに複数のCustomer GatewayのVPNを接続することで、オンプレ支店間の通信をAWS VGWを中継点(Hub)として実現するハブ&スポーク VPN構成。各サイト間の通信もVGW経由で可能。
問31: Direct Connect Gateway (DXGW) の主な利点は?
A) DX接続の速度向上 B) 1つのDirect Connect接続から複数リージョンのVPC/TGWに接続可能 C) 接続コストの削減 D) 自動フェイルオーバー
正解: B 解説: DXGW(グローバルリソース)は1つのPrivate VIFから最大10個のVGW/TGWに接続し、複数リージョンのVPCへのアクセスを単一DX接続から実現する。リージョンをまたいだDXアクセスに必須。
問32: VPC Sharing (Resource Access Manager) の利点は?
A) 無料でVPCを共有できる B) 複数アカウントが同一VPCのサブネットを共有してENI作成が可能、VPC数削減とIP効率化 C) VPCの暗号化 D) アカウント間のルーティング自動設定
正解: B 解説: VPC Sharingは1アカウントが所有するVPCのサブネットを他アカウントにRAM共有。共有先アカウントはそのサブネットにEC2/ECS/RDS等のリソースを作成できる。VPC数を削減しIPアドレス管理を集中化できる。
問33: AWS Transit Gateway Connect Peer の設定に必要なのは?
A) BGPのみ B) TGW ConnectアタッチメントのGREトンネル上にBGPピアを設定 C) Static Routingのみ D) TGW Connectは設定不要
正解: B 解説: TGW Connectは(1)既存TGWアタッチメント(VPCまたはDX)をTransport Attachmentとして選択 (2)Connect Attachmentを作成 (3)Connect PeerでGRE Tunnel IP+BGP ASN+BGP Peer IPを設定 の3ステップで設定。
問34: CloudFront でカスタムエラーレスポンスを設定する用途は?
A) デバッグ情報の表示 B) オリジンエラー(503等)をユーザーフレンドリーなカスタムページに変換し、キャッシュ時間も設定 C) セキュリティの強化 D) レイテンシの削減
正解: B 解説: CloudFrontのCustom Error Responseは特定のHTTPエラーコード(403, 404, 500等)を検出した際にカスタムページのパス(/error.html等)にリダイレクトし、ErrorCachingMinTTLでエラーのキャッシュ時間を制御できる。
問35: Security Group で同じSGのインスタンス間の通信を許可する設定は?
A) すべての内部通信は自動許可 B) Ingress ルールのSourceに同一SGのIDを指定(Self-Referencing) C) NACL のみで制御 D) VPC内は全通信許可
正解: B 解説: SG Self-ReferencingはSource/Destinationに同一のSG IDを指定することで、そのSGが付いたインスタンス同士の通信を許可。ECSタスク間通信、RDSクラスターのノード間通信等に使用。
問36: Direct Connect でBGP MD5認証を設定する理由は?
A) 帯域幅の向上 B) BGPピアが正当なルーターからの接続であることを認証し、BGPハイジャックを防止 C) レイテンシの削減 D) 自動フェイルオーバーの有効化
正解: B 解説: BGP MD5認証はBGPセッション確立時にMD5ハッシュを使用して相手を認証し、不正なBGPピアからの接続やルートインジェクション攻撃を防ぐ。DX接続ではAWSとCGWの両側で同一のMD5 keyを設定する。
問37: ALB で WebSocket をサポートするための設定は?
A) 特別な設定が必要 B) ALBはデフォルトでWebSocketをサポート (HTTP Upgradeヘッダーを自動処理) C) NLBのみWebSocketをサポート D) CloudFrontとの組み合わせが必須
正解: B 解説: ALBはHTTP/1.1のUpgradeリクエストとWebSocketプロトコルをネイティブサポートし、特別な設定なしにWebSocketアプリケーションをターゲットグループにルーティングできる。ただし、Idle Timeoutの調整(600秒等)が推奨。
問38: VPC IPAM (IP Address Manager) の主な用途は?
A) IPアドレスの自動割り当て B) 組織全体のVPC/サブネットのIPアドレス空間を一元管理・計画・監視 C) IPアドレスの暗号化 D) DHCPサービスの管理
正解: B 解説: VPC IPAMはOrganizations全体のIPアドレス空間をプールで階層管理し、VPC CIDR割り当ての重複防止、使用率の可視化、自動割り当てを提供。マルチアカウント環境のIPアドレス管理に必須ツール。
問39: Route 53 でプライベートホストゾーンを複数VPCに関連付ける場合の手順は?
A) ゾーンは1つのVPCにのみ関連付け可能 B) Route 53コンソールまたはAPIで複数のVPCをプライベートホストゾーンに関連付け C) 各VPCに別々のホストゾーンが必要 D) TGWを経由すれば自動的に共有される
正解: B 解説: プライベートホストゾーンは複数のVPCに関連付けることができ、異なるアカウントのVPCとも関連付け可能(Cross-account)。TGWでVPCを接続しただけではDNS解決は共有されないため、ホストゾーンへのVPCの関連付けが必要。
問40: AWS Network Manager を使用する主な目的は?
A) EC2インスタンスの管理 B) グローバルネットワーク(TGW, SD-WAN)の可視化・監視・トポロジー管理 C) VPNの設定自動化 D) コストの最適化
正解: B 解説: Network Managerはグローバルネットワークのトポロジーをビジュアル化し、TGW Route Analyzer、Network Insight、Transit Gateway Network Managerでネットワーク全体の可視性と問題診断を提供する。
問41: ELB の Cross-Zone Load Balancing を有効にする主な理由は?
A) セキュリティの強化 B) 各AZのターゲット数に関係なくトラフィックを均等分散し、AZ間の不均衡を防ぐ C) レイテンシの削減 D) コストの削減
正解: B 解説: Cross-Zone LBを有効にすると、AZ-aに2インスタンス・AZ-bに8インスタンスの場合でも全インスタンスに均等にトラフィックを分散できる。ALBはデフォルト有効、NLBはデフォルト無効(クロスゾーン通信コストが発生)。
問42: VPC でInternet Gatewayと同じサブネット(Public Subnet)の定義は?
A) インターネットGWを持つVPCのすべてのサブネット B) ルートテーブルにInternet Gatewayへのデフォルトルート(0.0.0.0/0 → IGW)が設定されているサブネット C) インターネットから直接アクセス可能なサブネット D) パブリックIPが割り当てられているサブネット
正解: B 解説: パブリックサブネットの条件: (1)VPCにIGWがアタッチされている (2)サブネットのルートテーブルに0.0.0.0/0→IGWのルートが存在 (3)インスタンスにパブリックIPまたはEIPが割り当てられている。3つ全て必要。
問43: Direct Connect のLAG (Link Aggregation Group) を使用する目的は?
A) コストの削減 B) 複数のDX接続を論理的に束ねて帯域幅を増やし(最大4本)、単一障害点を排除 C) 接続の暗号化 D) レイテンシの監視
正解: B 解説: LAGは最大4本のDX接続を束ねて論理的な高帯域幅接続を実現。1Gbps × 4 = 4Gbps LAG等。最小アクティブ接続数を設定して一部障害時の自動切断も制御できる。同じDCX Location/速度が必要。
問44: AWS VPN の加速接続 (Accelerated VPN) とは何か?
A) VPNの暗号化を高速化する機能 B) AWS Global AcceleratorのインフラをVPNに使用し、AWSバックボーン経由でオンプレとの通信を最適化 C) VPNハードウェアアプライアンスの高速版 D) Direct Connectの代替
正解: B 解説: Accelerated Site-to-Site VPNはGlobal Acceleratorのエニーキャストインフラを使用して、ユーザーの最寄りのAWS PoP経由でVPNトラフィックをAWSバックボーンに誘導し、インターネット経由より低レイテンシを実現。
問45: CloudFront のField-Level Encryption (FLE) の用途は?
A) HTTPS通信の強化 B) 特定のフォームフィールド(クレジットカード番号等)をエッジで暗号化し、オリジンではなくアプリのみが復号できるようにする C) S3オブジェクトの暗号化 D) WAFルールの強化
正解: B 解説: FLEは公開鍵でエッジでの追加暗号化を実施し、オリジンサーバーやバックエンドではデータが暗号化されたまま処理される。復号は対応する秘密鍵を持つアプリのみが可能で、機密データの保護を強化する。
Part 3: セキュリティ・設計 (問46-65)
問46: AWS WAF でSQLインジェクションをブロックする最も簡単な方法は?
A) カスタムルールを手動作成 B) AWSマネージドルール(AWS-AWSManagedRulesSQLiRuleSet)を適用 C) ALBのセキュリティグループで対応 D) Lambda関数でリクエストを検査
正解: B 解説: AWS WAFにはSQLi、XSS、Log4J、CRS(Core Rule Set)などのAWS/AWSベンダー提供のマネージドルールグループが用意されており、ワンクリックでWAF WebACLに追加できる。カスタムルールも組み合わせ可能。
問47: AWS Shield Advanced のDDoS保護の主な追加機能は?
A) 追加費用なし B) DDoS Response Team (DRT) サポート、コストプロテクション、高度なネットワーク監視、AWS WAF無償利用 C) Shield StandardとAdvancedは同じ保護レベル D) EC2のみ保護対象
正解: B 解説: Shield Advanced: 24/7 DRTによる攻撃緩和支援、DDoS起因のEC2/ELBコスト増分のクレジット、Advanced Diagnostics、AWS WAFのウェブACL無償利用($3,000/month+)。Shield Standardは無料で基本的なL3/L4攻撃を自動緩和。
問48: VPC の Suricata ベースのNetwork Firewallで IPS (侵入防止) を有効にするには?
A) Stateless RulesでドロップルールのみでOK
B) Stateful RulesでSuricata互換ルールをdropまたはrejectアクションで作成し、RuleOrderをSTRICT_ORDERに設定
C) IPS機能は別サービス
D) Suricataルールはサポートされていない
正解: B
解説: Network FirewallのStatefulエンジンはSuricata互換。drop tcp any any -> $HOME_NET 22 (threshold:type both,track by_src,count 10,seconds 60;)のようなルールで不審なトラフィックをドロップするIPS機能を提供。
問49: Route 53 Resolver DNS Firewall でEgressトラフィックの制御ができるのはどのような場合か?
A) インバウンドDNSのフィルタリングのみ B) VPC内のEC2インスタンス等からのDNSクエリに対してドメインリストでAllow/Block/Alert C) HTTPトラフィックの制御 D) 特定のIPアドレスのブロックのみ
正解: B 解説: DNS Firewallはドメインリスト(許可/拒否)を定義し、VPC内からのDNSクエリをフィルタリング。C2(C&C)サーバーへの通信ブロック、マルウェアドメインのブロック、DNSトンネリングの検出に有効。
問50: AWS PrivateLink を使用して企業内のSaaSサービスをセキュアに公開するための設計で、Consumer側に必要な設定は?
A) VPCピアリングのみ B) Interface Endpoint作成+Security Group(エンドポイントからのトラフィック許可)+プライベートDNS C) Public IPへのアクセス D) PrivateLinkは自動設定される
正解: B 解説: Consumer側の設定: (1)VPCにInterface Endpoint作成 (2)Endpointに適切なSGを設定(サービスポートを許可) (3)Private DNS Enabledでアプリが通常のDNS名を使用可能 (4)必要に応じてRoute 53プライベートホストゾーンのエイリアスレコード作成。
問51: マルチアカウントのネットワーク設計でHub VPCに共有サービス(DNS, NTP, パッチリポジトリ)を配置する構成の名称は?
A) Data Mesh B) Centralized Services VPC (Shared Services VPC) C) Transit VPC D) Management VPC
正解: B 解説: Centralized Services VPC(共有サービスVPC)はDNS、Active Directory、セキュリティツール、Artifactory等の共通インフラを集中管理するVPC。TGWを通じて全スポークVPCからアクセス可能で、各アカウントでの重複構築を避けられる。
問52: ALB の Sticky Session (スティッキーセッション) が必要なケースと注意点は?
A) 常に有効にすべき B) セッションデータをサーバーローカルに保持するアプリに必要だが、負荷不均衡とスケールダウン時のセッション喪失のリスクがある C) HTTPSのみ使用可能 D) NLBのみスティッキーセッションをサポート
正解: B 解説: Sticky Sessionは特定クライアントを同じターゲットに固定するが、ターゲット追加・削除時やAZバランスの変化で不均衡が生じる。推奨設計: セッションデータをElastiCache等の外部ストアに保存してStatelessに設計し、スティッキーセッション不要にする。
問53: VPC Endpoint をプライベートサブネットから使用する際に必要なルーティング設定は?
A) 通常のルートテーブルのみ B) Gateway Endpoint (S3/DynamoDB): プレフィックスリストをルートテーブルに追加, Interface Endpoint: ENI経由で自動解決 C) インターネット経由のルートが必要 D) TGWを経由する必要がある
正解: B 解説: Gateway Endpoint (S3, DynamoDB): ルートテーブルにpl-xxxxxx → vpce-xxxx(プレフィックスリスト)の形式でルートが自動追加される。Interface Endpoint: ENIが作成されプライベートDNS解決により自動的に使用。追加のルート設定は不要。
問54: AWS Network Firewall でのTLS Inspectionを設定する際の考慮事項は?
A) TLS Inspectionは透過的で設定不要 B) SSL証明書の設置(ACM)、クライアントへのCA証明書配布、プライバシーポリシー対応が必要 C) HTTP のみ対応 D) TLS Inspectionはサポートされていない
正解: B 解説: TLS Inspectionは中間者(MITM)として機能するため: (1)ACMで自己署名CA証明書を管理 (2)クライアントのトラストストアにCA証明書を追加 (3)プライバシーポリシーの更新 (4)健康/金融系の機密通信は除外リストで対応 が必要。
問55: Direct Connect でのJumbo Frame(ジャンボフレーム)の設定について正しいのは?
A) DCXは常にジャンボフレーム対応 B) MTU 9001バイトのジャンボフレームをDCXでサポート(Private VIF経由のトラフィックのみ) C) ジャンボフレームは使用不可 D) Public VIFのみジャンボフレーム対応
正解: B 解説: DX Private VIF はMTU 9001バイトのジャンボフレームをサポート。VGWまたはTGW経由でVPC内のEC2インスタンスにも適用。ジャンボフレームにより大きなデータ転送時のオーバーヘッドを削減しスループットを向上。
問56: 会社のオンプレミスのDNSサーバーとRoute 53プライベートホストゾーンを統合する方法は?
A) オンプレのDNSをRoute 53に移行 B) Route 53 Resolver Inbound Endpoint (オンプレ→R53) + Outbound Endpoint + Forwarding Rules (R53→オンプレ) C) 相互参照は不可能 D) Direct ConnectのみDNS統合が可能
正解: B 解説: ハイブリッドDNS統合: Inbound Endpointはオンプレのフォワードルールの転送先IP(ENI)を提供。Outbound EndpointはResolver Rulesに基づいてオンプレDNSサーバーにクエリを転送。オンプレとAWSの相互DNS解決を実現。
問57: VPC で IPv4 NAT がないプライベートサブネットからS3に安全にアクセスする最もコスト効率的な方法は?
A) NATゲートウェイ経由 B) S3 Gateway VPC Endpoint (無料, ルートテーブルのみ変更) C) Transit Gateway経由 D) Direct Connect経由
正解: B 解説: S3とDynamoDBはGateway VPC Endpointを無料で提供。インターネット通過なしでプライベートサブネットから直接アクセス可能。NATゲートウェイはS3アクセスのためには不要でコスト削減できる。
問58: マルチリージョンのネットワーク設計でTGW Inter-Region Peeringを使用する際の注意点は?
A) 帯域幅は無制限 B) TGW Peeringは暗号化なし・帯域幅制限あり・レイテンシはリージョン間の物理距離に依存 C) 自動フェイルオーバーは標準サポート D) 追加コストはない
正解: B 解説: TGW Inter-Region Peeringの注意点: (1)AWSバックボーン使用だがデータ転送コストが発生 (2)暗号化なし(必要ならDX/VPN over TGW Peering) (3)最大帯域幅はリージョン間経路による (4)ルート伝播は手動設定が必要。
問59: CloudFront でオリジンとのHTTPS通信でACM証明書が必要か?
A) CloudFrontはHTTPのみ対応 B) オリジンがAWSサービス(ALB, API GW)ならACM, カスタムオリジンなら任意の証明書(自己署名も可, ただし信頼できるCAが推奨) C) すべてのケースでACMが必須 D) オリジンとの通信は暗号化不要
正解: B 解説: ViewerとCFの間のHTTPS: CloudFront証明書(ACMで発行, us-east-1リージョン必須)。CFとOriginの間のHTTPS: ALBならACM証明書, API GWは自動, カスタムオリジンは信頼できるCA証明書(自己署名はmatch-viewer以外の場合に問題)。
問60: AWS Verified Access の主な用途は?
A) HTTPS証明書の検証 B) VPNなしで企業アプリへのゼロトラストアクセスを提供(IAM Identity Center/OIDC認証+デバイス姿勢確認) C) インターネットアクセスのフィルタリング D) APIゲートウェイの認証
正解: B 解説: Verified Accessはゼロトラストネットワークアクセス(ZTNA)サービスで、VPN不要でAWS上のアプリへのアクセスをIAM Identity Center(SSO)またはOIDC、デバイス管理(CrowdStrike等)のポスチャーに基づいて制御する。
問61: VPC でHigh Networkパフォーマンスが必要なEC2インスタンス間通信で「クラスタープレイスメントグループ」を使用する利点は?
A) 自動HA/フェイルオーバー B) 同一AZの物理的に近い場所に配置し、低レイテンシ(10μs以下)と高帯域幅(最大100Gbps)を実現 C) ストレージの高速化 D) コストの最適化
正解: B 解説: Cluster Placement Groupは同一AZの単一ラック内または隣接ラックにインスタンスを集中配置し、拡張ネットワーキング(ENA/EFA)と組み合わせることで最高のネットワークパフォーマンスを発揮。HPC、機械学習クラスターに最適。
問62: EFA (Elastic Fabric Adapter) の主な用途は?
A) 一般的なネットワーク通信 B) HPCクラスタリングやML分散学習でのMPI/NCCL通信でOS-bypassにより超低レイテンシを実現 C) インターネット接続の高速化 D) ストレージへの高速アクセス
正解: B 解説: EFAはOSカーネルをバイパスしてNICに直接アクセスするため、MPI(Message Passing Interface)やNCCL(NCCL for GPU)の通信レイテンシを大幅削減。分散機械学習の勾配同期やHPCのノード間通信に使用。
問63: Network Load Balancer でTLSターミネーションを設定する際の特徴は?
A) NLBはTLSターミネーションをサポートしない B) TLSリスナーを設定してNLBでTLS終端し、バックエンドへの通信をTCPにすることで証明書管理を集中化 C) ACM証明書は使用不可 D) TLSターミネーション後の再暗号化は不可能
正解: B 解説: NLBのTLSリスナー(ポート443等)にACM証明書を設定することで、クライアントとのTLSをNLBで終端し、バックエンドにはTCP/TCPで転送できる。SNIを使用して複数ドメインの証明書を1つのリスナーで処理も可能。
問64: VPC でNATゲートウェイのコスト削減策は?
A) NAT GWを削除してインターネット接続を停止 B) VPCエンドポイント(S3, DynamoDB等)への切り替え、AZ内NAT GW数の最適化、処理データ量の削減 C) NAT GWを常に使用する必要がある D) EC2ベースのNATインスタンスに変更
正解: B 解説: NAT GWコスト削減: (1)S3/DynamoDB→Gateway Endpoint(無料) (2)CloudWatch等→Interface Endpoint(NAT不要) (3)各AZに1つ(AZ内の転送は無料) (4)ECRイメージをAZキャッシュ (5)NATの処理データ量をVPC Flow Logsで分析して削減。
問65: AWSネットワーク設計の「Least Privilege Connectivity」原則の実装は?
A) 全リソースへのフルアクセスを許可 B) SGでポート/プロトコルを最小限に制限、PrivateLinkで必要なサービスのみ公開、VPCエンドポイントポリシーで操作を制限 C) NACLのみで制御 D) パブリックサブネットを最大限活用
正解: B 解説: Least Privilege Connectivity: (1)SGで必要なポートのみ許可(デフォルト全拒否) (2)PrivateLinkで特定サービスのみ公開(IPアドレス重複許可) (3)Endpoint Policyで特定S3バケット/操作のみ許可 (4)NACLで広範なCIDRブロック (5)Network Firewallで詳細検査。
付録: ANS-C01 重要ポイント総まとめ
【ANS-C01 必須暗記事項】
■ Direct Connect
VIF種類: Private(VPC), Public(AWSサービス), Transit(TGW), Hosted
接続種類: Dedicated(1/10/100Gbps), Hosted(50Mbps-10Gbps)
冗長性: Maximum→4接続/2Location, High→2接続/2Location
Direct Connect Gateway: マルチリージョン対応グローバルリソース
BGP優先度: Static > DX BGP > VPN BGP
■ Transit Gateway
Max接続数: 5000 VPC + 20 VPN + 4 DX GW アタッチメント
最大帯域: 50Gbps (per attachment)
TGW Connect: GREトンネル経由で最大20Gbps
Multicast: マルチキャストドメインサポート
Inter-Region Peering: 暗号化なし、手動ルート設定
■ VPN
最大スループット: 1.25Gbps/トンネル
ECMP: TGWで複数VPN接続を束ねてスループット増加
Accelerated VPN: Global Accelerator経由で低レイテンシ
■ CloudFront
Origin Shield: 追加キャッシュレイヤー
FLE: 特定フィールドのエッジ暗号化
OAC: S3へのアクセスをCFのみに制限
Functions vs Lambda@Edge: Functions=軽量JS, Lambda@Edge=Node.js/Python/重い処理
■ Route 53
ルーティングポリシー: Simple/Weighted/Latency/Failover/Geolocation/Geoproximity/Multivalue
Resolver: Inbound/OutboundEndpoint でハイブリッドDNS統合
DNS Firewall: VPC発のDNSクエリをドメインリストでフィルタ
■ セキュリティ
Network Firewall: Stateless(パケットフィルタ)/Stateful(Suricata)
WAF: マネージドルール + カスタムルール + Rate-based
Shield: Standard(無料)/Advanced(DRT+コストプロテクション)
Verified Access: ゼロトラスト, VPN不要
■ VPC 設計
サブネット予約: 5 IP/サブネット
セカンダリCIDR: 最大4個追加
IPAM: 組織全体のIPアドレス管理
VPC Sharing: RAM経由でサブネット共有
PrivateLink: P2Pプライベート接続, アドレス重複OK
【試験戦略】
1. ハイブリッド問題: DX vs VPN の使い分け (帯域/コスト/レイテンシ)
2. ルーティング問題: BGP優先度とAS_PATH prepend
3. セキュリティ問題: Defense in depth (IGW→NFW→NACL→SG→アプリ)
4. コスト問題: Gateway Endpoint(無料)の積極活用
5. 可用性問題: 各AZに冗長化(NAT GW, NLB, DX接続)
ANS-C01 (AWS Certified Advanced Networking Specialty) 試験対策ガイド完成 作成日: 2026-04
第7章: ネットワーク自動化・CloudFormation
7.1 ネットワークインフラのIaC
import boto3
import json
# CloudFormation でVPC・TGW設定を管理
VPC_NETWORK_TEMPLATE = {
'AWSTemplateFormatVersion': '2010-09-09',
'Description': 'Enterprise Network Infrastructure',
'Parameters': {
'Environment': {
'Type': 'String',
'AllowedValues': ['development', 'staging', 'production']
},
'VpcCidr': {
'Type': 'String',
'Default': '10.0.0.0/16'
}
},
'Resources': {
'VPC': {
'Type': 'AWS::EC2::VPC',
'Properties': {
'CidrBlock': {'Ref': 'VpcCidr'},
'EnableDnsHostnames': True,
'EnableDnsSupport': True,
'Tags': [
{'Key': 'Name', 'Value': {'Fn::Sub': '${Environment}-vpc'}},
{'Key': 'Environment', 'Value': {'Ref': 'Environment'}}
]
}
},
'PublicSubnet1': {
'Type': 'AWS::EC2::Subnet',
'Properties': {
'VpcId': {'Ref': 'VPC'},
'CidrBlock': '10.0.1.0/24',
'AvailabilityZone': {'Fn::Select': [0, {'Fn::GetAZs': ''}]},
'MapPublicIpOnLaunch': True
}
},
'InternetGateway': {
'Type': 'AWS::EC2::InternetGateway'
},
'IGWAttachment': {
'Type': 'AWS::EC2::VPCGatewayAttachment',
'Properties': {
'VpcId': {'Ref': 'VPC'},
'InternetGatewayId': {'Ref': 'InternetGateway'}
}
},
'TransitGateway': {
'Type': 'AWS::EC2::TransitGateway',
'Properties': {
'AmazonSideAsn': 64512,
'AutoAcceptSharedAttachments': 'disable',
'DefaultRouteTableAssociation': 'disable',
'DefaultRouteTablePropagation': 'disable',
'DnsSupport': 'enable',
'VpnEcmpSupport': 'enable',
'Tags': [{'Key': 'Name', 'Value': {'Fn::Sub': '${Environment}-tgw'}}]
}
}
},
'Outputs': {
'VpcId': {
'Value': {'Ref': 'VPC'},
'Export': {'Name': {'Fn::Sub': '${Environment}-VpcId'}}
},
'TransitGatewayId': {
'Value': {'Ref': 'TransitGateway'},
'Export': {'Name': {'Fn::Sub': '${Environment}-TGWId'}}
}
}
}
# Network Automationの実装
class NetworkAutomation:
def __init__(self):
self.ec2_client = boto3.client('ec2', region_name='ap-northeast-1')
self.cfn_client = boto3.client('cloudformation', region_name='ap-northeast-1')
def detect_security_group_violations(self):
"""SGの違反(0.0.0.0/0 inbound)を自動検出"""
violations = []
paginator = self.ec2_client.get_paginator('describe_security_groups')
for page in paginator.paginate():
for sg in page['SecurityGroups']:
for rule in sg['IpPermissions']:
for ip_range in rule.get('IpRanges', []):
if ip_range['CidrIp'] == '0.0.0.0/0':
if rule.get('FromPort') not in [80, 443]:
violations.append({
'sg_id': sg['GroupId'],
'sg_name': sg['GroupName'],
'port': rule.get('FromPort', 'All'),
'protocol': rule.get('IpProtocol', 'All'),
'vpc_id': sg.get('VpcId', 'N/A')
})
return violations
def auto_remediate_sg_violation(self, sg_id, from_port, to_port, protocol):
"""セキュリティグループ違反の自動修復"""
self.ec2_client.revoke_security_group_ingress(
GroupId=sg_id,
IpPermissions=[{
'IpProtocol': protocol,
'FromPort': from_port,
'ToPort': to_port,
'IpRanges': [{'CidrIp': '0.0.0.0/0'}]
}]
)
print(f'Remediated SG {sg_id}: Removed 0.0.0.0/0 rule for port {from_port}')
def analyze_vpc_flow_logs(self, log_group, start_time, end_time):
"""VPCフローログのCloudWatch Logs分析"""
logs_client = boto3.client('logs', region_name='ap-northeast-1')
# 拒否されたトラフィックの分析
query = """
fields @timestamp, srcAddr, dstAddr, dstPort, protocol, action
| filter action = "REJECT"
| stats count(*) as attempts,
count_distinct(srcAddr) as unique_sources
by dstPort, protocol
| sort attempts desc
| limit 20
"""
start_query = logs_client.start_query(
logGroupName=log_group,
startTime=start_time,
endTime=end_time,
queryString=query
)
return start_query['queryId']
7.2 AWS Transit Gateway Network Manager
import boto3
tgw_nm_client = boto3.client('networkmanager', region_name='us-west-2') # Global
# Global Network 作成
def create_global_network():
response = tgw_nm_client.create_global_network(
Description='Enterprise Global Network',
Tags=[{'Key': 'Name', 'Value': 'enterprise-global-network'}]
)
return response['GlobalNetwork']['GlobalNetworkId']
# TGWをGlobal Networkに登録
def register_tgw(global_network_id, tgw_arn):
response = tgw_nm_client.register_transit_gateway(
GlobalNetworkId=global_network_id,
TransitGatewayArn=tgw_arn
)
return response['TransitGatewayRegistration']
# ネットワークトポロジー可視化(ルート解析)
def analyze_network_route(global_network_id, source_arn, destination_arn):
response = tgw_nm_client.get_network_routes(
GlobalNetworkId=global_network_id,
RouteTableIdentifier={
'TransitGatewayRouteTableArn': 'arn:aws:ec2:ap-northeast-1:123456789012:transit-gateway-route-table/tgw-rtb-xxx'
},
DestinationFilters={
'ATTACHMENT_ID': [destination_arn]
}
)
return response['NetworkRoutes']
7.3 AWS Network Firewall 高度な設定
import boto3
nfw_client = boto3.client('network-firewall', region_name='ap-northeast-1')
# Network Firewall ポリシー作成
def create_firewall_policy(policy_name):
# ルールグループ: Suricata ルール
ids_rule_group = nfw_client.create_rule_group(
RuleGroupName='ids-rules',
Type='STATEFUL',
Capacity=1000,
RuleGroup={
'RulesSource': {
'RulesString': """
# SQL Injection の検出
alert http any any -> any any (
msg: "SQL Injection Attempt";
flow: established, to_server;
content: "UNION";
content: "SELECT";
classtype: web-application-attack;
sid: 1000001;
rev: 1;
)
# 悪意あるUser-Agentの検出
alert http any any -> any any (
msg: "Malicious Scanner Detected";
flow: established, to_server;
http.user_agent;
content: "sqlmap";
nocase;
classtype: attempted-recon;
sid: 1000002;
rev: 1;
)
# 暗号化通貨マイニングの検出
alert dns any any -> any any (
msg: "Crypto Mining Pool DNS Query";
dns.query;
content: "pool.";
content: "mining";
nocase;
classtype: policy-violation;
sid: 1000003;
rev: 1;
)
"""
},
'StatefulRuleOptions': {
'RuleOrder': 'STRICT_ORDER'
}
},
Tags=[{'Key': 'Name', 'Value': 'IDS Rules'}]
)
ids_rule_group_arn = ids_rule_group['RuleGroupResponse']['RuleGroupArn']
# ドメインリストによる L7 フィルタリング
domain_rule_group = nfw_client.create_rule_group(
RuleGroupName='domain-filter',
Type='STATEFUL',
Capacity=1000,
RuleGroup={
'RulesSource': {
'RulesSourceList': {
'Targets': [
'.malware.example.com',
'.ransomware.example.com',
'badsite.com'
],
'TargetTypes': ['TLS_SNI', 'HTTP_HOST'],
'GeneratedRulesType': 'DENYLIST'
}
}
}
)
domain_rule_group_arn = domain_rule_group['RuleGroupResponse']['RuleGroupArn']
# TLS インスペクション設定
tls_config_arn = create_tls_inspection_config()
# ファイアウォールポリシー作成
policy = nfw_client.create_firewall_policy(
FirewallPolicyName=policy_name,
FirewallPolicy={
'StatelessDefaultActions': ['aws:forward_to_sfe'],
'StatelessFragmentDefaultActions': ['aws:forward_to_sfe'],
'StatefulDefaultActions': ['aws:drop_strict'],
'StatefulEngineOptions': {
'RuleOrder': 'STRICT_ORDER',
'StreamExceptionPolicy': 'DROP'
},
'StatefulRuleGroupReferences': [
{
'ResourceArn': ids_rule_group_arn,
'Priority': 100
},
{
'ResourceArn': domain_rule_group_arn,
'Priority': 200
}
],
'TLSInspectionConfigurationArn': tls_config_arn,
'PolicyVariables': {
'RuleVariables': {
'HOME_NET': {
'Definition': ['10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16']
}
}
}
}
)
return policy['FirewallPolicyResponse']['FirewallPolicyArn']
def create_tls_inspection_config():
"""TLSインスペクション設定(アウトバウンド/インバウンドHTTPS解析)"""
response = nfw_client.create_tls_inspection_configuration(
TLSInspectionConfigurationName='enterprise-tls-inspection',
TLSInspectionConfiguration={
'ServerCertificateConfigurations': [
{
'ServerCertificates': [
{
'ResourceArn': 'arn:aws:acm:ap-northeast-1:123456789012:certificate/cert-id'
}
],
'Scopes': [
{
'Sources': [
{'AddressDefinition': '10.0.0.0/8'}
],
'Destinations': [
{'AddressDefinition': '0.0.0.0/0'}
],
'SourcePorts': [
{'FromPort': 1024, 'ToPort': 65535}
],
'DestinationPorts': [
{'FromPort': 443, 'ToPort': 443}
],
'Protocols': [6] # TCP
}
],
'CertificateAuthorityArn': 'arn:aws:acm-pca:ap-northeast-1:123456789012:certificate-authority/ca-id',
'CheckCertificateRevocationStatus': {
'RevokedStatusAction': 'DROP',
'UnknownStatusAction': 'PASS'
}
}
]
}
)
return response['TLSInspectionConfigurationResponse']['TLSInspectionConfigurationArn']
第8章: SD-WAN・ハイブリッドネットワーク最適化
8.1 AWS Cloud WAN
import boto3
cloudwan_client = boto3.client('networkmanager', region_name='us-west-2')
# Cloud WAN グローバルネットワーク作成
def create_cloud_wan(network_name):
# グローバルネットワーク作成
global_network = cloudwan_client.create_global_network(
Description=f'{network_name} Global Network',
Tags=[{'Key': 'Name', 'Value': network_name}]
)
global_network_id = global_network['GlobalNetwork']['GlobalNetworkId']
# コアネットワーク作成(SD-WAN機能)
core_network_policy = {
'version': '2021.12',
'core-network-configuration': {
'vpn-ecmp-support': True,
'asn-ranges': ['64512-65534'],
'inside-cidr-blocks': ['10.0.0.0/8'],
'edge-locations': [
{'location': 'ap-northeast-1', 'inside-cidr-blocks': ['10.0.1.0/24']},
{'location': 'us-east-1', 'inside-cidr-blocks': ['10.0.2.0/24']},
{'location': 'eu-west-1', 'inside-cidr-blocks': ['10.0.3.0/24']}
]
},
'segments': [
{
'name': 'production',
'description': 'Production workloads',
'require-attachment-acceptance': True
},
{
'name': 'development',
'description': 'Development workloads',
'require-attachment-acceptance': False,
'isolate-attachments': True # 本番との通信分離
},
{
'name': 'shared-services',
'description': 'Shared services (DNS, AD)',
'require-attachment-acceptance': False
}
],
'segment-actions': [
{
'action': 'share',
'mode': 'attachment-route',
'segment': 'shared-services',
'share-with': ['production', 'development']
}
],
'attachment-policies': [
{
'rule-number': 100,
'condition-logic': 'and',
'conditions': [
{
'type': 'tag-value',
'operator': 'equals',
'key': 'Environment',
'value': 'production'
}
],
'action': {
'association-method': 'constant',
'segment': 'production'
}
}
]
}
core_network = cloudwan_client.create_core_network(
GlobalNetworkId=global_network_id,
PolicyDocument=json.dumps(core_network_policy),
Tags=[{'Key': 'Name', 'Value': f'{network_name}-core'}]
)
return global_network_id, core_network['CoreNetwork']['CoreNetworkId']
8.2 Route 53 高度な設計
import boto3
r53_client = boto3.client('route53')
# Route 53 Resolver DNS Firewall
def create_dns_firewall(vpc_id):
resolver_client = boto3.client('route53resolver', region_name='ap-northeast-1')
# ドメインリスト(悪意あるドメインブロック)
block_list = resolver_client.create_firewall_domain_list(
Name='MaliciousDomainBlockList',
Tags=[{'Key': 'Name', 'Value': 'MaliciousDomains'}]
)
block_list_id = block_list['FirewallDomainList']['Id']
# ドメインをリストに追加
resolver_client.update_firewall_domains(
FirewallDomainListId=block_list_id,
Operation='ADD',
Domains=[
'malware.example.com',
'*.cryptomining.bad',
'phishing-site.net'
]
)
# ルールグループ作成
rule_group = resolver_client.create_firewall_rule_group(
Name='SecurityRuleGroup',
Tags=[{'Key': 'Name', 'Value': 'SecurityRules'}]
)
rule_group_id = rule_group['FirewallRuleGroup']['Id']
# ブロックルール追加
resolver_client.create_firewall_rule(
FirewallRuleGroupId=rule_group_id,
FirewallDomainListId=block_list_id,
Priority=100,
Action='BLOCK',
BlockResponse='NXDOMAIN',
Name='BlockMaliciousDomains'
)
# Managed Domain Lists(AWSのマネージドリストを使用)
# Route53Resolver:AmazonRoute53ResolverManagedThreatList
# VPCにルールグループを関連付け
resolver_client.associate_firewall_rule_group(
FirewallRuleGroupId=rule_group_id,
VpcId=vpc_id,
Priority=100,
Name='VPCDNSProtection',
MutationProtection='DISABLED'
)
return rule_group_id
# プライベートホストゾーンのハイブリッドDNS設定
def setup_hybrid_dns(vpc_id, onprem_dns_ip, onprem_domain):
resolver_client = boto3.client('route53resolver', region_name='ap-northeast-1')
# インバウンドエンドポイント(オンプレ→AWSのDNS解決)
inbound_endpoint = resolver_client.create_resolver_endpoint(
CreatorRequestId='inbound-001',
Name='InboundDNSEndpoint',
SecurityGroupIds=['sg-12345678'],
Direction='INBOUND',
IpAddresses=[
{'SubnetId': 'subnet-12345678'},
{'SubnetId': 'subnet-87654321'}
]
)
# アウトバウンドエンドポイント(AWS→オンプレのDNS解決)
outbound_endpoint = resolver_client.create_resolver_endpoint(
CreatorRequestId='outbound-001',
Name='OutboundDNSEndpoint',
SecurityGroupIds=['sg-12345678'],
Direction='OUTBOUND',
IpAddresses=[
{'SubnetId': 'subnet-12345678'},
{'SubnetId': 'subnet-87654321'}
]
)
outbound_endpoint_id = outbound_endpoint['ResolverEndpoint']['Id']
# フォワーディングルール(オンプレドメインをオンプレDNSへ転送)
forwarding_rule = resolver_client.create_resolver_rule(
CreatorRequestId='fwd-rule-001',
Name=f'ForwardTo-{onprem_domain}',
RuleType='FORWARD',
DomainName=onprem_domain,
TargetIps=[
{'Ip': onprem_dns_ip, 'Port': 53}
],
ResolverEndpointId=outbound_endpoint_id
)
# VPCにルールを関連付け
resolver_client.associate_resolver_rule(
ResolverRuleId=forwarding_rule['ResolverRule']['Id'],
VPCId=vpc_id,
Name=f'{onprem_domain}-rule'
)
return inbound_endpoint, outbound_endpoint, forwarding_rule
# マルチリージョンRoute 53 トラフィックポリシー
def create_traffic_policy(domain_name):
"""複雑なルーティングロジックをトラフィックポリシーで定義"""
traffic_policy_document = {
'AWSPolicyFormatVersion': '2015-10-01',
'RecordType': 'A',
'StartRule': 'geolocation-rule',
'Endpoints': {
'tokyo-alb': {
'Type': 'elastic-load-balancer',
'Value': 'tokyo-alb.ap-northeast-1.elb.amazonaws.com'
},
'singapore-alb': {
'Type': 'elastic-load-balancer',
'Value': 'singapore-alb.ap-southeast-1.elb.amazonaws.com'
},
'us-alb': {
'Type': 'elastic-load-balancer',
'Value': 'us-alb.us-east-1.elb.amazonaws.com'
}
},
'Rules': {
'geolocation-rule': {
'RuleType': 'geo',
'GeolocationGroups': [
{
'EndpointId': 'tokyo-alb',
'Locations': [{'CountryCode': 'JP'}, {'CountryCode': 'KR'}]
},
{
'EndpointId': 'singapore-alb',
'Locations': [{'CountryCode': 'SG'}, {'CountryCode': 'TH'}, {'CountryCode': 'MY'}]
}
],
'DefaultRule': 'latency-rule' # その他→レイテンシーベース
},
'latency-rule': {
'RuleType': 'latency',
'Regions': {
'ap-northeast-1': {'EndpointId': 'tokyo-alb'},
'us-east-1': {'EndpointId': 'us-alb'}
}
}
}
}
response = r53_client.create_traffic_policy(
Name='enterprise-traffic-policy',
Document=json.dumps(traffic_policy_document),
Comment='Geo + Latency based routing'
)
return response['TrafficPolicy']['Id']
模擬試験 セット2(15問)
問題1 AWS Network Firewallのステートフル検査とステートレス検査の違いは?
A) 違いはない B) ステートレス: パケット単位で評価(送信元/宛先IP・ポート)、高速。ステートフル: コネクション状態を追跡(TCP SYNトラッキング、Suricataルール)、より高度な脅威検知 C) ステートレス検査はTCPのみ対応 D) ステートフル検査はアウトバウンドのみ
正解: B 解説: Network Firewallの2段階検査: ①ステートレスエンジン(最初に評価): 5タプル(送信元IP、送信先IP、送信元ポート、宛先ポート、プロトコル)ベースのルール。Forward to SFE、Pass、Drop、Custom Actionのいずれかを実行。②ステートフルエンジン(Suricataベース): コネクション状態追跡、アプリケーション層(HTTP/TLS/DNS等)の詳細検査、IDS/IPSルール、ドメインリストフィルタリング。
問題2 Amazon CloudFront のOrigin Shield の目的は?
A) オリジンサーバーのバックアップ B) CloudFrontエッジロケーションとオリジンの間に追加のキャッシュ層を設け、オリジンへのリクエスト数を削減してコストとレイテンシーを最適化 C) CloudFrontのDDoS保護 D) 複数のオリジンを負荷分散する
正解: B 解説: CloudFront Origin Shield: 特定のAWSリージョン(ap-northeast-1等)を中間キャッシュ層として指定。エッジロケーションがキャッシュミスした場合、直接オリジンに行く前にOrigin Shieldを経由。利点: ①オリジンへのリクエスト数を大幅削減(コスト削減)②キャッシュヒット率向上③オリジンの保護(レート制限対策)。オリジンが単一リージョンにある場合に特に有効。
問題3 Direct Connectの「MACsec(Media Access Control Security)」の用途は?
A) Direct Connect接続のIPsec暗号化 B) DX物理接続のレイヤー2(データリンク層)での暗号化(128-bit/256-bit AES)。IPsecより低オーバーヘッドでライン速度の暗号化 C) DX接続のBGP認証 D) DX LAGのリンク冗長化
正解: B 解説: MACsec(802.1AE): Direct Connectのレイヤー2暗号化。DXロケーションからAWSリージョンまでの区間を暗号化。特徴: ①ライン速度で動作(IPsecより低オーバーヘッド)②XGCMによるAES-128/256暗号化と認証③専用接続(10Gbps/100Gbps)のみサポート(ホスト型接続は非対応)。コンプライアンス要件(PCI DSS、HIPAA等)でのデータ転送保護に利用。
問題4 VPCのNetwork Access Analyzerで「意図しないネットワーク露出」を検出する主なユースケースは?
A) VPCフローログのリアルタイム分析 B) プライベートサブネットのEC2がインターネットゲートウェイから直接到達可能であることを検出(意図しないルーティング設定) C) DDoS攻撃の検出 D) EC2インスタンスのセキュリティ脆弱性スキャン
正解: B 解説: Network Access Analyzer: 「セキュリティ要件(スコープ)」を定義して実際のネットワーク経路を分析。例: 「インターネットゲートウェイ→プライベートサブネットのEC2への到達性なし」が要件なのに、誤ったルートテーブル設定により到達可能な経路が存在→Finding。VPC Reachability Analyzerは特定2点間のデバッグ。Network Access Analyzerは組織全体の意図しないパス発見。
問題5 Transit Gateway Connect(GRE)の主な用途は?
A) TGWとオンプレの接続をIPsecで暗号化する B) SD-WANアプライアンス(仮想)とTGWをGREトンネル経由で接続してより高いスループット(50Gbps)を実現 C) TGW間のピアリングを高速化する D) VPCとTGWの接続を暗号化する
正解: B 解説: TGW Connect: GREプロトコルを使用してVPC内のSD-WAN仮想アプライアンス(Cisco、Palo Alto等)とTGWを接続。利点: ①通常のVPN接続(1.25Gbps上限)と比較して最大50Gbpsのスループット②BGPで動的ルーティング③VPC Attachmentが基盤(GREはVPC内アプライアンスへのトンネル)。オンプレとのSD-WAN統合に使用。
問題6 AWS Site-to-Site VPNのデュアルトンネル設計の必要性は?
A) 冗長性なし B) AWSはVPN接続で2つのVPNエンドポイント(異なるAZ)を提供。両方のトンネルをアクティブにしてECMP(Equal Cost Multi-Path)ルーティングで帯域幅増加と高可用性を実現 C) デュアルトンネルはAWS Site-to-Site VPNでは設定不可 D) デュアルトンネルはDirect Connect専用機能
正解: B 解説: AWS Site-to-Site VPN アーキテクチャ: 各VPN接続はAWSのVGW/TGW側に2つのVPNエンドポイント(異なるAZ/異なるパブリックIP)を持つ。オンプレ側のルーターでBGP ECMPを設定することで両トンネルをActive-Activeに→帯域幅2倍+冗長性。トンネル1本の最大スループットは1.25Gbps。複数VPN接続のTGWへのECMP設定で最大50Gbpsまでスケール可能(Equal Cost Multi-Path)。
問題7 Amazon CloudFrontのField-Level Encryption(FLE)の目的は?
A) CloudFrontとオリジン間の全通信を暗号化する B) 特定のフォームフィールド(クレジットカード番号等)をエッジで公開鍵暗号化し、指定のオリジンのみが秘密鍵で復号できる仕組み C) CloudFrontのキャッシュコンテンツを暗号化する D) CloudFront Functionsでのデータ暗号化
正解: B 解説: CloudFront FLE(Field-Level Encryption): ユーザーがHTTPSフォームで送信するデータの特定フィールドをエッジロケーションで公開鍵(最大10フィールド)で暗号化。ネットワーク経由では暗号化済みのまま流れ、秘密鍵を持つオリジンのみが復号。PCI DSS等のコンプライアンス要件でクレジットカードデータ等の保護に使用。CloudFront OACと組み合わせてエンドツーエンドのセキュリティを実現。
問題8 Global Acceleratorのエニーキャスト(Anycast)IPアドレスの特徴は?
A) 各リージョンに異なるIPアドレスが割り当てられる B) 世界中のすべてのエッジロケーションで同一のIPアドレスを使用。ユーザーからの接続は自動的に最寄りのAWSエッジに誘導される C) Anycast IPはHTTPSのみサポートする D) エニーキャストIPはDNSキャッシュに影響される
正解: B 解説: Global Accelerator Anycast: 2つのグローバル静的Anycast IPアドレスを提供。BGPアニュアンスにより世界中のAWSエッジロケーションから同じIPを広告。ユーザーのトラフィックはBGP経由で最近接エッジに誘導(DNSなし→TTL問題なし)。エッジからAWSバックボーンネットワーク(プライベート高速回線)経由でリージョンエンドポイントに接続。Route 53 Latency routingより即時フェイルオーバーが可能(60秒以内)。
問題9 VPC Lattice の主な機能は?
A) VPC間のVPNトンネル B) マイクロサービス間の通信を一元管理するサービスメッシュ(認証認可、トラフィック管理、オブザーバビリティをインフラから分離) C) VPCフローログの可視化 D) セキュリティグループのバージョン管理
正解: B 解説: Amazon VPC Lattice: サービスメッシュのマネージドサービス。機能: ①Service Network(VPC間の通信ネットワーク)②認証認可(IAM認証、Lambda認証者)③トラフィック管理(重み付けルーティング、ヘッダーベースルーティング)④観測可能性(アクセスログ、CloudWatchメトリクス)。EC2、ECS、EKS、Lambda対応。Envoy/Istioのマネージド代替。
問題10 AWS PrivateLinkとVPCピアリングの主な違いは?
A) PrivateLinkは高コスト B) PrivateLink: サービスプロバイダーがNLBを経由してサービスをエンドポイントサービスとして公開(単方向、非推移的)。VPCピアリング: 2つのVPC間の双方向通信(推移的ルーティング不可) C) VPCピアリングはクロスリージョン非対応 D) PrivateLinkは同一アカウントのみ
正解: B 解説: 使い分け: VPCピアリング: 双方向全通信(全ポート・プロトコル)、CIDRオーバーラップ不可、推移的ルーティング不可。PrivateLink: 単方向(コンシューマー→プロバイダー)、特定サービスのみ公開(NLBバックエンド)、異なるCIDRも可、横断的通信に安全。B2Bサービス提供はPrivateLink、内部VPC統合はピアリング(またはTGW)。
問題11 Route 53のTTL(Time To Live)を短縮するデメリットは?
A) フェイルオーバーが遅くなる B) TTL短縮でフェイルオーバーは速くなるが、DNS解決のリクエスト数が増加→Route 53のクエリコスト増加とDNSリゾルバーの負荷増加 C) TTL短縮はRoute 53でサポートされない D) TTL短縮でキャッシュが永続化する
正解: B 解説: TTL(DNS Cache Duration): 短いTTL(例: 30秒)→フェイルオーバー応答が速い→DNSクエリ頻度増加→Route 53課金増加($0.40/100万クエリ)→大規模トラフィックでコスト問題。長いTTL(例: 5分)→キャッシュ効率良い→フェイルオーバー遅延。推奨: 通常は300秒、メンテナンス前日に60秒に短縮→メンテ後に元に戻す。
問題12 CloudFront Behaviors(ビヘイビア)のPath Patternの評価順序は?
A) 設定した順序(1, 2, 3…)で評価される B) パスパターンの特異性(具体性)の高い順に評価され、デフォルトビヘイビア(*)が最後に評価される C) ランダムに評価される D) 英数字順に評価される
正解: B
解説: CloudFront Behaviors評価: より具体的なパスパターンが優先。例: /api/v2/users/*(最も具体的)→/api/*→/static/*→*(デフォルト、最後)。ビヘイビアの「優先度」番号(0が最高)で制御。同じ特異性の場合は優先度番号で決定。コンソール上でドラッグ&ドロップで順序変更可能。デフォルトビヘイビアは削除不可。
問題13 Amazon VPCのIPv6サポートの主な特徴は?
A) IPv6はVPCでサポートされない B) IPv6はVPCに/56、サブネットに/64のCIDRを割り当て可能。すべてのIPv6アドレスはパブリックアドレスで、Egress-Only Internet Gatewayでアウトバウンドのみ制御 C) IPv6とIPv4は同時使用不可 D) IPv6はRoute 53でサポートされない
正解: B 解説: AWS IPv6: VPCに/56(Amazonから割り当て)またはBYOIPv6、サブネットに/64を割り当て。全IPv6アドレスはグローバルユニキャスト(パブリック)→プライベートIPv6なし。送信専用: Egress-Only Internet Gateway(インバウンドをブロック)。デュアルスタック: IPv4とIPv6を同時にEC2インスタンスに設定可能。NACLとセキュリティグループでIPv6ルールを別途設定必要。
問題14 AWS Verified Accessを使用したゼロトラストネットワークの主な特徴は?
A) VPNの代替として使用するが同じ機能 B) VPN不要でアプリケーションレベルのアクセス制御を実現。Cedar Policy言語でユーザー属性・デバイス状態・コンテキスト(時間、場所等)に基づいたきめ細かいポリシーを定義 C) Verified AccessはEC2インスタンスのみ対応 D) Verified Accessは外部IdPとの統合不可
正解: B 解説: AWS Verified Access: VPN不要のゼロトラストアクセス。動作: ユーザー→Verified Access エンドポイント→IdP認証(IAM Identity Center、Okta等)→デバイス信頼確認(Jamf、CrowdStrike等)→Cedarポリシー評価→許可/拒否。対応アプリ: HTTP/HTTPS(ALBベース)。アクセスログのS3/CloudWatch送信。既存のプライベートALBを公開せずにセキュアアクセスを実現。
問題15 AWS App Mesh(サービスメッシュ)の主要コンポーネントは?
A) Load Balancer、Target Group、Security Group B) Mesh(名前空間)、Virtual Service(論理サービス名)、Virtual Router(ルーティングルール)、Virtual Node(実際のサービスエンドポイント) C) VPC、Subnet、Route Table D) API Gateway、Lambda、SQS
正解: B 解説: AWS App Mesh(Envoyベース): Mesh: サービスメッシュの名前空間。Virtual Service: クライアントが使用するサービス名(DNS名)。Virtual Router: トラフィックルール(重み付け、ヘッダーベースルーティング)。Virtual Node: 実サービスのDNS名+バックエンド/リスナー設定。Envoy Proxy: サイドカーコンテナとして各タスク/Podに注入。App Meshは現在VPC Latticeへの移行が推奨されている。
ANS試験 最終チェックリスト(補足)
重要な比較
- [ ] Transit Gateway vs VPC Peering vs PrivateLink(用途別選択)
- [ ] Network Firewall vs Security Group vs NACL(防御層の設計)
- [ ] Global Accelerator vs CloudFront(静的コンテンツ vs 動的コンテンツ)
- [ ] Direct Connect vs Site-to-Site VPN(コスト・帯域・信頼性)
- [ ] Route 53 健全性チェック(ヘルスチェックタイプ)
- [ ] Egress-Only Internet Gateway vs NAT Gateway(IPv6 vs IPv4)
- [ ] VPC Lattice vs App Mesh(マイクロサービスメッシュ)
試験頻出数値
| 項目 | 値 |
|---|---|
| VPC最大CIDR | /16(最大65,536IP) |
| サブネット予約IP数 | 5個(最初4個+最後1個) |
| セキュリティグループ最大ルール | 60インバウンド+60アウトバウンド |
| TGW最大VPCアタッチメント | 5000 |
| DX専用接続帯域 | 1/10/100 Gbps |
| Site-to-Site VPN 最大スループット | 1.25 Gbps/トンネル |
| Network Firewall ステートフル処理 | Suricata 3.0 |
| CloudFront POP数 | 600以上 |
| Route 53 TTL 最小値 | 0秒(推奨は60秒以上) |