LoginSignup
0
1

AWS ANS 参考リンク集

Posted at

参考になりそうなリンク集。
順次追加予定。

■Transit Gateway Connect

□SD-WAN ブランチ接続を簡素化する AWS Transit Gateway Connect の紹介
	https://aws.amazon.com/jp/about-aws/whats-new/2020/12/introducing-aws-transit-gateway-connect-to-simplify-sd-wan-branch-connectivity/

	AWS Transit Gateway Connect は、SD-WAN アプライアンスを AWS Transit Gateway と統合するためのネイティブな方法を提供します。お客様は、Generic Routing Encapsulation (GRE) や Border Gateway Protocol (BGP) などの標準プロトコルを使用して、パートナーオーケストレーションプラットフォームを介して数回クリックするだけで、SD-WAN エッジを AWS にシームレスに拡張できるようになりました。Transit Gateway Connect は、帯域幅の改善などのさらなる利点を顧客に提供し、ルート制限を増やした動的ルーティングをサポートするため、SD-WAN アプライアンスと Transit Gateway の間に複数の IPsec VPN を設定する必要がなくなります。これにより、ネットワーク設計全体が簡素化され、関連する運用コストが削減されます。さらに、Transit Gateway Connect は AWS Transit Gateway Network Manager と完全に統合されており、グローバルネットワークトポロジ、アタッチメントレベルのパフォーマンスメトリック、およびテレメトリデータを通じて高度な可視性を顧客に提供します。 

□AWS Direct Connect + AWS Transit Gateway
	https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect-aws-transit-gateway.html
	
	AWS Direct Connect + AWS Transit Gateway は、Direct Connect ゲートウェイへのトランジット VIF アタッチメントを使用しプライベート専用接続を介して最大 3 つのリージョン集中型ルーターにネットワークを接続できます。

	各 AWS Transit Gateway は、同じリージョン内の VPC を相互接続するネットワークトランジットハブであり、Amazon VPC ルーティング設定を 1 か所に統合
	

□AWS Transit Gateway Network Manager の Route Analyzer を発表
	https://aws.amazon.com/jp/about-aws/whats-new/2020/05/announcing-route-analyzer-in-aws-transit-gateway-network-manager/

	グローバルネットワーク内のTransit Gatewayでルート分析を実行できるようにする
	Route Analyzer を使用すると、指定した送信元と送信先の間のトランジットゲートウェイでネットワーク接続分析を実行するだけで、グローバルネットワーク上の Transit Gateway のルーティング設定を簡単に確認できます。
	グローバルネットワークでトラフィックの中断を引き起こしているルート関連の問題を診断する前に、トランジットゲートウェイルートテーブルの設定が期待どおりに機能することを確認できます。

□[アップデート] AWS Transit Gatewayのリージョン内ピアリングがサポートされました #reinvent
	https://dev.classmethod.jp/articles/intra-regional-peering-is-now-supported-for-aws-transit-gateway/	

	Transit Gatewayをリージョン内に複数作成し、Transit Gateway間を接続するときにTransit VPCを作成する必要がなくなりました
	

□AWS Transit Gatewayの新機能– Network Managerを使用してグローバルネットワークを構築し、モニタリングを集中化
	https://aws.amazon.com/jp/blogs/news/new-for-aws-transit-gateway-build-global-networks-and-centralize-monitoring-using-network-manager/
	
	・トランジットゲートウェイのリージョン間ピアリング
	・高速化されたサイト間VPN
	・AWS Transit Gatewayネットワークマネージャー

□Transit Gateway でのマルチキャスト
	https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-multicast-overview.html
	
	マルチキャストは、単一のデータストリームを複数の受信コンピュータに同時に配信するために使用される通信プロトコル
	ransit Gateway は、接続された VPC のサブネット間のマルチキャストトラフィックのルーティングをサポートし、複数の受信インスタンス宛てのトラフィックを送信するインスタンスのマルチキャストルーターとして機能します。
	
	マルチキャストの概念
		マルチキャストドメイン
			異なるドメインへのマルチキャストネットワークのセグメント化が可能になり、Transit Gateway が複数のマルチキャストルーターとして機能するようになります
		
		マルチキャストグループ
			同じマルチキャストトラフィックを送受信するホストセットを識別します。マルチキャストグループは、グループ IP アドレスによって識別されます
			
		インターネットグループ管理プロトコル (IGMP)
			ホストとルーターがマルチキャストグループメンバーシップを動的に管理できるようにするインターネットプロトコル
			
		マルチキャスト送信元 
			マルチキャストトラフィックを送信するよう静的に設定された、サポートされている EC2 インスタンスに関連付けられた elastic network interface。マルチキャスト送信元は、静的な送信元の設定のみに適用されます。
			
		マルチキャストグループメンバー
			マルチキャストトラフィックを受信する、サポートされている EC2 インスタンスに関連付けられた elastic network interface。
			
		考慮事項
			マルチキャストをサポートするには、新しいTransit Gateway を作成する必要
			マルチキャストのルーティングは、AWS Direct Connect、Site-to-Site VPN、ピアリングアタッチメント、または Transit Gateway Connect アタッチメントではサポートされていません。

□IGMPGMP マルチキャストドメインを作成する
	https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/manage-domain.html#create-tgw-igmp-domain
	
	


□マルチキャストのルーティング
	https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/how-multicast-works.html
	
	ネットワーク ACL
		最小インバウンドルール
			UDP/リモートホストの IP アドレス
		最小アウトバウンドルール
			UDP/マルチキャストグループの IP アドレス
			
	セキュリティグループ
		インバウンドマルチキャストトラフィックとアウトバウンドマルチキャストトラフィックの両方に適用できます
		
		最小インバウンドルール
			2/0.0.0.0/32
			UDP/リモートホストの IP アドレス
			
		最小アウトバウンドルール
			2/マルチキャス
			
□Transit Gatewayを利用してVPC間で通信してみた
	https://dev.classmethod.jp/articles/transit-gateway-vpc/#toc-7

□例: ピア接続 Transit Gateway
	https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/transit-gateway-peering-scenario.html
	
	異なるリージョンで Transit Gateway 間に Transit Gateway ピアリング接続を作成できます。その後、各 Transit Gateway のアタッチメント間でトラフィックをルーティングできます。
	

□トランジットゲートウェイの関連付け
	https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/direct-connect-transit-gateways.html
	
	


□AWS トランジット ゲートウェイ + SD-WAN ソリューション
	https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-vpc-connectivity-options/aws-transit-gateway-sd-wan.html
	
	Software Defined Wide Area Network (SD-WAN) は、さまざまなトランジット ネットワーク (公共のインターネット、MPLS ネットワーク、AWS Direct Connect を使用した AWS バックボーンなど) を介してデータセンター、オフィス、またはコロケーション環境を接続し、トラフィックを管理するために使用されます。
	

□Direct Connect GatewayとTransit Gatewayの併用構成への移行手順をまとめてみた
	https://dev.classmethod.jp/articles/how-to-migrate-from-private-vif-to-transit-vif/

□AWS Resource Access Managerを使用して、複数アカウントでAWS Transit Gatewayを共有して通信する方法
	https://blog.serverworks.co.jp/ram-transit-gateway-routing
	
	①(アカウントA)RAMでTGWをアカウントBに共有
	②(アカウントB)TGWの共有を承諾
	③(アカウントB)TGWアタッチメントの作成
	④(アカウントA)TGWアタッチメントの承諾
	⑤(アカウントA)TGWルートテーブルの設定
	⑥(アカウントA、B)VPCのルートテーブルの設定
	
	□[新機能] オンプレミスネットワーク間を接続するAWS Direct Connect SiteLinkがリリースされました #reinvent
		https://dev.classmethod.jp/articles/introducing-aws-direct-connect-sitelink/#toc-2			
		オフィスやデータセンターなどオンプレミス環境の各ネットワークをAWSのDirect Connect Locationに接続することで、オンプレミス間でプライベートネットワークを簡単に作成できる機能です。
	
	□新機能 — オンプレミスネットワーク間を接続する AWS Direct Connect SiteLink
		https://aws.amazon.com/jp/blogs/news/new-site-to-site-connectivity-with-aws-direct-connect-sitelink/
		AWS Direct Connect の新機能で、AWS グローバルネットワークバックボーンを介してオンプレミスネットワーク間の接続を作成するのに使用する、AWS Direct Connect SiteLink をリリースします
		
	
	□Direct Connect 接続の BFD を有効にするにはどうすればよいですか?
		https://repost.aws/ja/knowledge-center/enable-bfd-direct-connect
		双方向転送検出 (BFD) 
		インターフェイス名、仮想 LAN (VLAN) 番号、AS 番号 (ASN)、および Direct Connect ピアの IP アドレスについては、プレースホルダーをご自身の値に置き換えてください。
		
		
	
	
	□Transit Gateway を別のアカウントと、あるいは AWS Organization 内で、共有するにはどうすればいいですか?
		https://repost.aws/ja/knowledge-center/transit-gateway-sharing
		Transit Gateway を AWS RAM と共有する
		AWS RAM で Transit Gateway のリソース共有を承認する
		共有しているアカウント内に Transit Gateway アタッチメントを作成する
		Transit Gateway の所有者アカウント内でアタッチメントを承諾する
		
		オプション) 共有アタッチメントを自動的に承諾する
			手動の操作を行わずに共有アタッチメントをに承諾するには、Transit Gateway 所有者アカウントで自動承諾を有効化します。

			Amazon VPC コンソールを開きます。
			ナビゲーションペインで、[Transit Gateways] を選択します。
			変更する Transit Gateways を選択します。
			[Actions] (アクション) を選択します。 次に、[Modify transit gateway] (Transit Gateway を変更) を選択します。
			[Configure cross-account sharing options] (クロスアカウント共有オプションの設定) で、[Auto accept shared attachments] (共有アタッチメントを自動承諾) を選択します。

■VPC

□VPC フローログを使用した IP トラフィックのログ記録
	https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/flow-logs.html

	VPC フローログは、VPC のネットワークインターフェイスとの間で行き来する IP トラフィックに関する情報をキャプチャできるようにする機能
	フローログデータは、Amazon CloudWatch Logs、Amazon S3、または Amazon Kinesis Data Firehose に発行できます。フローログを作成したら、設定したロググループ、バケット、または配信ストリームのフローログレコードを取得して表示できます。
	
	フローログは、以下のような多くのタスクに役立ちます。

	・制限の過度に厳しいセキュリティグループルールを診断する
	・インスタンスに到達するトラフィックを監視する
	・ネットワークインターフェイスに出入りするトラフィックの方向を決定する

	フローログデータはネットワークトラフィックのパスの外で収集されるため、ネットワークのスループットやレイテンシーには影響しません。ネットワークパフォーマンスに影響を与えるリスクなしに、フローログを作成または削除できます。
		
	集約間隔は、特定のフローがキャプチャされ、フローログレコードに集約される期間です。デフォルトでは、最大の集約間隔が 10 分に設定されています。フローログを作成する場合、オプションで最大集約間隔を 1 分に指定できます
	
	集約間隔内にデータが取得された後、データの処理および CloudWatch Logs または Amazon S3 へのパブリッシュにさらに時間がかかります。フローログサービスは、通常、約 5 分で CloudWatch Logs に、約 10 分で Amazon S3 にログを配信します。
	
	
	カスタム形式
		・pkt-srcaddr
			トラフィックのパケットレベルの (元の) 送信元 IP アドレス。
		・pkt-dstaddr
			トラフィックのパケットレベルの (元の) 送信先 IP アドレス。
			
□VPC Reachability Analyzer
	https://aws.amazon.com/jp/blogs/news/new-vpc-insights-analyzes-reachability-and-visibility-in-vpcs/
	https://blog.serverworks.co.jp/network-analyzes-route-analyzer-and-reachability-analyzer#VPC-Reachability-Analyzer-%E3%81%A8%E3%81%AF
	
	VPC 内の 2 つのエンドポイント間、または複数の VPC  間で、通信の到達性に関する問題を解決できます。
	
	ネットワークが目的どおりに設定されているかを確認
		Reachability Analyzer のユーザーは、仮想ネットワーク環境を全体的に制御できます。独自の IP アドレス範囲の選択、サブネットの作成、またルートテーブルやネットワークゲートウェイの設定が可能です
		VPC Reachability Analyzer では、VPC 内のすべてのリソースの設定が確認され、自動化された推論を使用して、実現可能なネットワークフローが特定されます。
	
	VPC Reachability Analyzer はAWSが提供しているネットワーク診断ツールでVPC 内の 2 つのエンドポイント間、または複数の VPC 間で、通信の到達性に関する問題を解決することが可能です。送信元(Source)と送信先(destination)に設定可能なコンポーネントは以下の通りです。
		Instances
		Internet gateways
		Network interfaces
		Transit gateways
		VPC endpoints
		VPC peering connections
		VPN gateways

	VPC Reachability Analyzer の利用前提
		・送信元・送信先のコンポーネントはそれぞれ同一アカウント内に存在すること
		・送信元・送信先のコンポーネントはそれぞれ同一リージョン内に存在すること
		・送信元・送信先のコンポーネントはそれぞれ同一VPC内に存在すること(VPCピアリングで接続されている場合はこの限りではない)


□フローログレコードの例
	https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/flow-logs-records-examples.html
	
	ACLのアウトバウンドに気をつけよ

□NAT ゲートウェイ
	https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-gateway.html
	
	NAT ゲートウェイは、ネットワークアドレス変換 (NAT) サービス
	NAT ゲートウェイを作成するときは、次のいずれかの接続タイプを指定
	
	Public 
		(デフォルト) プライベートサブネットのインスタンスは、パブリック NAT ゲートウェイを介してインターネットに接続できますが、インターネットから未承諾のインバウンド接続を受信することはできません。パブリックサブネット内にパブリック NAT ゲートウェイを作成し、作成時に Elastic IP アドレスを NAT ゲートウェイに関連付ける必要があります。NAT ゲートウェイへのトラフィックは、VPC のインターネットゲートウェイにルーティングします。パブリック NAT ゲートウェイを使用して、他の VPC やオンプレミスのネットワークに接続することもできます。
		
	Private
		プライベートサブネットのインスタンスは、プライベート NAT ゲートウェイを介して他の VPC またはオンプレミスのネットワークに接続できます。この場合、NAT ゲートウェイからのトラフィックを Transit Gateway または仮想プライベートゲートウェイ経由でルーティングできます。elastic IP アドレスをプライベート NAT ゲートウェイに関連付けることはできません。プライベート NAT ゲートウェイを使用して VPC にインターネットゲートウェイをアタッチできますが、プライベート NAT ゲートウェイからインターネットゲートウェイにトラフィックをルーティングすると、インターネットゲートウェイによってトラフィックがドロップされます。
		
	NAT ゲートウェイに割り当てるプライベート IPv4 アドレスを選択するか、サブネットの IPv4 アドレス範囲からプライベート IPv4 アドレスを自動的に割り当てることができます。割り当てられたプライベート IPv4 アドレスは、プライベート NAT ゲートウェイを削除するまで維持されます。プライベート IPv4 アドレスをデタッチすることはできず、追加のプライベート IPv4 アドレスをアタッチすることもできません。

□VPC トラフィックミラーリングの使用
	https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/financial-services-industry-lens/use-vpc-traffic-mirroring.html
	
	VPC トラフィックミラーリングを使用して、Amazon EC2 インスタンスの Elastic Network Interface からネットワークトラフィックをコピーし、コンテンツ検査、脅威モニタリング、トラブルシューティングなどのユースケースのために、そのトラフィックをセキュリティおよびモニタリングのアプライアンスに転送します
	監視したいトラフィックを抽出


□Amazon Virtual Private Cloud (VPC) は AWS での IP アドレス管理を簡素化する IP Address Manager (IPAM) を発表
	https://aws.amazon.com/jp/about-aws/whats-new/2021/12/amazon-virtual-private-cloud-vpc-announces-ip-address-manager-ipam/
	
	Amazon VPC IP Address Manager (IPAM) は AWS ワークロードの IP アドレスの計画、追跡、モニタリングを簡単にする新しい機能です
	
	


□Amazon CloudWatch で IPAM をモニタリングする
	https://docs.aws.amazon.com/ja_jp/vpc/latest/ipam/cloudwatch-ipam.html
	
	IPAM では、IP アドレス使用とリソース使用率に関連するメトリクス (IPAM プールで使用可能な IP アドレス空間や、割り当てルールに準拠しているリソース CIDR の数など) が IPAM のホームリージョン内の AWS/IPAM Amazon CloudWatch 名前空間に自動的に保存されます。

□Egress-Only インターネットゲートウェイの基本
	https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/egress-only-internet-gateway.html#egress-only-internet-gateway-basics
	IPv6 アドレスはグローバルに一意であるため、デフォルトではパブリックアドレスになっています。インスタンスにインターネットにアクセスさせる場合で、インターネット上のリソースにインスタンスとの通信を開始させないようにする場合は、Egress-Only インターネットゲートウェイを使用できます
	Egress-Only インターネットゲートウェイを VPC で作成し、次にすべての IPv6 トラフィック (::/0) または特定の IPv6 アドレスの範囲をポイントするルートテーブルに、Egress-Only インターネットゲートウェイへのルートを追加します。ルートテーブルに関連付けられるサブネットの IPv6 トラフィックは、Egress-Only インターネットゲートウェイにルーティングされます。
	
□ステートフルアプライアンスおよびアプライアンスモード
	https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/transit-gateway-appliance-scenario.html#transit-gateway-appliance-support

	アプライアンスモードが有効な場合、トランジットゲートウェイは、フローハッシュアルゴリズムを使用して、アプライアンス VPC 内の 1 つのネットワークインターフェイスを選択し、フローの有効期間中トラフィックを送信します。
	トランジットゲートウェイは、リターントラフィックに同じネットワークインターフェイスを使用します。
	双方向トラフィックは対称的にルーティングされます。
	
	アプライアンスモードが有効でない場合の動作
		トランジットゲートウェイは、送信元のアベイラビリティーゾーン内の VPC アタッチメント間でルーティングされたトラフィックが送信先に到達するまで維持しようとします。トラフィックは、アベイラビリティーゾーンに障害が発生した場合、またはそのアベイラビリティーゾーン内で VPC アタッチメントに関連付けられたサブネットがない場合にのみ、アタッチメント間でアベイラビリティーゾーンを通過します。


□Transit Gatewayでインスペクション用VPCに通信を集約する場合はTransit Gatewayのアプライアンスモードを有効にしよう
	https://dev.classmethod.jp/articles/enable-appliance-mode-when-using-transit-gatewayto-aggregate-communication-to-vpc-for-inspection/
	
	アプライアンスモードを有効にしていない場合、VPC AのEC2インスタンスから、VPC BのEC2インスタンスに通信ができません。

	Transit Gatewayのアプライアンスモードは一言で言うと、「ルーティングが対照的になるようにする機能」
	
	アプライアンスモードを有効にすることで、以下のように、通信先が異なるAZであっても、戻りの通信は行きの通信と同じ経路を辿るようになります。

□Amazon VPC 内の NAT ゲートウェイを経由するトラフィックを最も増加させている要因を調べるにはどうすればよいですか?
	https://repost.aws/ja/knowledge-center/vpc-find-traffic-sources-nat-gateway
	
	以下の手順を実行すれば、 Amazon VPC 内の NAT ゲートウェイを経由するトラフィックを最も増加させた要因が何なのかを調べることができます。

	Amazon CloudWatch メトリクスを使用し、トラフィックが急増した時間を特定します。
	CloudWatch Logs を使用して、トラフィック急増の原因となっているインスタンスを特定します。
	Amazon Simple Storage Service (Amazon S3) または Amazon Athena を使用して、トラフィック急増の原因となっているインスタンスを特定します。

□

■Route 53

□Amazon Route 53 Resolver の概要
	https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resolver.html

	Amazon Route 53 Resolver は、パブリックレコード、Amazon VPC 固有の DNS 名、および Amazon Route 53 プライベートホストゾーンに関する AWS リソースからの DNS クエリに再帰的に応答し、デフォルトですべての VPC で利用可能
	
	DNS クエリに自動的に応答
	・EC2 インスタンスのローカル VPC ドメイン名 (例えば、ec2-192-0-2-44.compute-1.amazonaws.com)
	・プライベートホストゾーンのレコード (例えば、acme.example.com)。
	・パブリックドメイン名については、Route 53 Resolver では、インターネット上の公開ネームサーバーに対して再帰的検索が実行されます。
	

	VPC とオンプレミスリソースの両方を利用するワークロードがある場合は、オンプレミスでホストされている DNS レコードを解決する必要あり。
	これらのオンプレミスリソースは、AWS で ホストされている名前を解決する必要がある場合があります。
		→Resolver エンドポイント+条件付き転送ルール


□Route 53 Resolver インバウンド/アウトバウンドエンドポイントとは
	https://qiita.com/mksamba/items/b16e99170e666b68f194
	
	・Resolver(インバウンドエンドポイント)は、AWS VPCの外部(ダイレクトコネクトやVPNで接続されているオンプレミスやGCPなど)から、VPC内のRoute 53 Resolverを使用して、VPC内の名前解決を可能にするためのエンドポイント。
	・Resolver(アウトバウンドエンドポイント)は、AWS VPCの内部から、Route 53 Resolverを経由して、インターネット以外の外部(オンプレミスやGCPなど)の名前解決を可能にするためのエンドポイント。


□Route 53 Resolver RuleとResource Access Manager
	https://dev.classmethod.jp/articles/explain-route53-resolver-ram/#toc-5
	
	「Resouce Access Manager」で共有するとルールの一元管理で便利になる

	


□Amazon CloudWatch を使用したホストゾーンのモニタリング
	https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/monitoring-hosted-zones-with-cloudwatch.html#cloudwatch-metrics-route-53-hosted-zones

	Amazon CloudWatch を使用して生データを収集し、ほぼリアルタイムで読み取り可能なメトリクスに加工することで、パブリックホストゾーンをモニタリングできます
	
	DNSQueries
		ホストゾーンについて、指定された期間に Route 53 が応答している DNS クエリの数。
		
	DNSSECInternalFailure
		ホストゾーン内に INTERNAL_FAILURE 状態のオブジェクトが存在する場合は、値が 1 になります。それ以外の場合は値は 0 です。

	DNSSECKeySigningKeysNeedingAction
		(KMS の障害により) ACTION_NEED の状態になっているキー署名キー (KSK) の数。
		
	DNSSECKeySigningKeyMaxNeedingActionAge
		キー署名キー (KSK) が ACTION_NEED 状態に設定されてからの経過時間。
		
	DNSSECKeySigningKeyAge
		キー署名キー (KSK) が作成されてからの経過時間 (有効になってからではありません)。
		
	
□ネットワークへのアウトバウンド DNS クエリの転送
	https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/resolver-forwarding-outbound-queries.html
	
	複数の VPC にある Amazon EC2 インスタンスから発信された DNS クエリを、自分のネットワークに転送するには、アウトバウンドエンドポイントと 1 つ以上のルールを作成します。

□Route 53 Resolver Rule を Resource Access Manager で共有してみた
	https://dev.classmethod.jp/articles/share-route-53-resolver-rule-by-ram/
	
	Resource Access Manager を使用して Route 53 Resolver Rule のアカウント間共有
	

□プライベートホストゾーンの使用
	https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/hosted-zones-private.html

	プライベートホストゾーンは、Amazon VPC サービスで作成する 1 つ以上の VPC 内のドメインとそのサブドメインへの DNS クエリに対し、Amazon Route 53 がどのように応答するかに関する情報を保持するコンテナ
	
	

□Amazon Route 53 での DNSSEC 署名の設定
	https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/dns-configuring-dnssec.html
	
	DNSSECInternalFailure または DNSSECKeySigningKeysNeedingAction エラーが検出されるたびにアラートを受け取ることができる、CloudWatch アラームをセットアップしておくことを強くお勧めします。
	
	DNSSEC には、キー署名キー (KSK) とゾーン署名キー (ZSK) の 2 種類のキーがあります。Route 53 の DNSSEC 署名での各 KSK は、お客様が所有する AWS KMS 内の非対称カスタマーマネージドキーに基づいています。必要に応じて行うローテーションを初めとして、KSK管理の責任はお客様が持ちます。ZSK 管理は Route 53 によって実行されます。
	
□キー署名キー (KSK) の使用
	https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/dns-configuring-dnssec-ksk.html
	
	DNSSEC 署名を有効にすると、Route 53 によってキー署名キー (KSK) が作成されます。

	
□パブリック DNS クエリのログ記録
	https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/query-logs.html
	
	
	
□

■ELB

□ロードバランサーの種類
	https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/load-balancer-types.html
	
	

□NLB でスティッキーセッションが使えるようになりました!
	https://dev.classmethod.jp/articles/nlb-support-sicky-session/
	
	ALB/CLB ではスティッキーセッションが利用できましたが、NLB ではサポートされていませんでした。今回のアップデートによって、NLB でもスティッキーセッションが使えるようになったということですね。


□Gateway Load Balancer
	クロスゾーンロードバランサー
	https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/gateway/gateway-load-balancers.html#cross-zone-load-balancing
	
	デフォルトでは、各ロードバランサーノードは、アベイラビリティーゾーン内の登録済みターゲット間でのみトラフィックを分散します。クロスゾーン負荷分散を有効にすると、各 Gateway Load Balancer ノードは、有効なすべてのアベイラビリティーゾーンの登録済みターゲットにトラフィックを分散します

□Gateway Load Balancer の使用開始方法
	https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/gateway/getting-started.html
	
	


□Amazon EKS の NGINX Ingress コントローラーでネットワークロードバランサーを使用する
	https://aws.amazon.com/jp/blogs/opensource/network-load-balancer-nginx-ingress-controller-eks/
	
	

□新規 – AWS Application Load Balancer に対するホストベースのルーティングのサポート
	https://aws.amazon.com/jp/blogs/news/new-host-based-routing-support-for-aws-application-load-balancers/
	。Host ヘッダーに指定したドメイン名に基づいて受信トラフィックをルーティングする Application Load Balancer ルールを作成できるようになりました
	
	


□Network Load Balancer の TLS リスナー
	https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/create-tls-listener.html
	LS リスナーを使用するには、ロードバランサーにサーバー証明書を少なくとも 1 つデプロイする必要があります。
	


□


□

■VPN

□AWS クライアント VPN を使用したピア接続 VPC へのアクセス
	https://docs.aws.amazon.com/ja_jp/vpn/latest/clientvpn-admin/scenario-peered.html
	
	

□Site-to-Site VPN のルーティングオプション
	https://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/VPNRoutingTypes.html
	
	Site-to-Site VPN 接続を作成する場合、以下を実行する必要があります。
		使用予定のルーティングのタイプ (静的または動的) を指定する
		サブネットのルートテーブルを更新する

□トンネル B よりもトンネル A を優先するように、Site-to-Site VPN 接続を設定するにはどうすればよいですか?
	https://repost.aws/ja/knowledge-center/vpn-configure-tunnel-preference
	
	AWS Site-to-Site VPN 接続は、2 つの仮想プライベートネットワーク (VPN) トンネルで構成
	AWS からオンプレミスのネットワークにトラフィックを送信するときに、トンネル A がトンネル B よりも優先されるようにするにはどうすればよいですか?
	
		AWS VPN 接続 (静的ルーティングタイプ) にアクティブ/アクティブ設定 (両方のトンネルが UP) の場合、トラフィックを送信するために特定のトンネルを優先するように AWS を設定することはできません。例えば、トンネル A は、AWS からオンプレミスネットワークにトラフィックを送信するための優先 VPN トンネルとして AWS によってランダムに選択されました。トンネル A がダウンすると、AWS からのトラフィックは自動的にトンネル B にフェイルオーバーします。
		AWS VPN 接続 (静的ルーティングタイプ) にアクティブ/パッシブ設定 (トンネル A は UP だが、トンネル B が DOWN) の場合、トンネル A がアップ状態であるため、AWS からオンプレミスネットワークへのトラフィックはトンネル A を通過します。
		
		
		AWS からオンプレミスネットワークへのトラフィックは、AWS VPN 接続が次の場合に優先トンネル (AWS によってランダムに選択されます) を介して送信されます。
			アクティブ/アクティブ設定 (両方のトンネルがUP) の場合、および
			同じ ボーダーゲートウェイプロトコル (BGP) 属性を使用して、仮想プライベートゲートウェイまたはトランジットゲートウェイに同じプレフィックスをアドバタイズしている場合
			注: アクティブ/アクティブ設定では、カスタマーゲートウェイで仮想トンネルインターフェイスで非対称ルーティングをアクティブ化する必要があります。
		
		動的な AWS VPN 接続の場合
			優先順位の基準を利用して、カスタマーゲートウェイデバイスがある VPN トンネルを他方よりも優先するように設定します。
			
				具体的なプレフィックスをアドバタイズ
				各 VPN 接続が BGP を使用するプレフィックスの照合のために、AS PATH が比較され、AS PATH が最短のプレフィックスが優先されます。
				AS PATH の長さが同じで、AS_SEQUENCE の最初の AS が複数のパス間で同じである場合、Multi-Exit-Discriminator (MED) が比較されます。MED 値が最も小さいパスが優先


□AWS クライアント VPN エンドポイントの分割トンネル
	https://docs.aws.amazon.com/ja_jp/vpn/latest/clientvpn-admin/split-tunnel-vpn.html
	
	

□Elastic Fabric Adapter
	https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/efa.html


□カスタマーゲートウェイデバイス
	https://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/your-cgw.html
	カスタマーゲートウェイデバイスは、オンプレミスネットワーク (Site-to-Site VPN 接続のユーザー側) で所有または管理している物理アプライアンスまたはソフトウェアアプライアンス
	
□Site-to-Site VPN 接続の高速化
	https://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/accelerated-vpn.html
	
	高速 Site-to-Site VPN 接続 (高速 VPN 接続) は、AWS Global Accelerator を使用してオンプレミスネットワークからカスタマーゲートウェイデバイスに最も近い AWS エッジロケーションにトラフィックをルーティングします。AWS Global Accelerator は、輻輳のない AWS グローバルネットワークを使用して、最適なアプリケーションパフォーマンスを提供するエンドポイントにトラフィックをルーティングし、ネットワークパスを最適化します 


□


□

■Direct Connect

□ルーティングポリシーと BGP コミュニティ
	https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/routing-and-bgp.html
	
	AWS Direct Connect は、パブリック AWS 接続の (オンプレミスのデータセンターからの) インバウンドルーティングポリシーおよび (AWS Direct Connect リージョンからの) アウトバウンドルーティングポリシーを適用します。また、Amazon がアドバタイズするルートのボーダーゲートウェイプロトコル (BGP) コミュニティタグを使用して、ユーザーが Amazon にアドバタイズするルートに BGP コミュニティタグを適用できます。
	
	パブリック仮想インターフェイスのルーティングポリシー
		アウトバウンドルーティングポリシーが適用
			AS-PATH と最長のプレフィックス一致を使用してルーティングパスが決定されます。 ‭AWS は同じプレフィックスがインターネットとパブリック仮想インターフェイスの両方にアドバタイズされる場合は、AWS Direct Connect を使用してより具体的なルートをアドバタイズすることを推奨します。
			すべてのローカルおよびリモート AWS リージョンプレフィックス (それらが利用可能な場合) をアドバタイズし、CloudFront や Route 53 などの、リージョンではない AWS PoP (Points of Presence) からのオンネットプレフィックス (それらが利用可能な場合) を含めます。
			
			AWS リージョンコミュニティ
				インバウンドルーティングポリシーの場合
					7224:9100 — ローカル AWS リージョン
					7224:9200 — 1 つの大陸にあるすべての AWS リージョン:
								北米全域
								アジアパシフィック
								欧州、中東、アフリカ

					7224:9300 – グローバル (すべてのパブリック AWS リージョン)
	
	プライベート仮想インターフェイスおよびトランジット仮想インターフェイスの BGP コミュニティ
		ローカル優先設定 BGP コミュニティタグをサポートし、プライベート仮想インターフェイスおよびトランジット仮想インターフェイス上のトラフィックのルートの優先順位を制御するのに役立ちます。
		
	BGP コミュニティのローカル優先設定
		ネットワークの着信トラフィックでロードバランシングやルート設定を実現できます。BGP セッション経由でアドバタイズするプレフィックスごとに、コミュニティタグを適用して、返されるトラフィックの関連付け済みパスの優先度を示すことができます
		
		7224:7100 - 優先設定: 低

		7224:7200 - 優先設定: 中

		7224:7300 - 優先設定: 高
		
		同一または異なる AWS リージョンをホームとする複数の AWS Direct Connect 接続(アクティブ/アクティブ)間でトラフィックを負荷分散するには、接続のプレフィックス間で同じコミュニティタグ、例えば 7224:7200 (中程度の優先設定)を適用します。
		接続の 1 つに障害が発生すると、ホームリージョンの関連付けや発信元のリージョンとの相対距離に関係なく、残りのアクティブな接続間でトラフィックが等価コストマルチパス (ECMP) を使用して負荷分散されます。
		
		
		複数の AWS Direct Connect 接続 (アクティブ/パッシブ) でフェイルオーバーをサポートするには、プライマリまたはアクティブな仮想インターフェイスのプレフィックスに、優先設定が高いコミュニティタグを適用し、バックアップまたはパッシブな仮想インターフェイスのプレフィックスに低い優先設定を適用します。
		ローカル設定 BGP コミュニティタグは AS_PATH 属性の前に評価され、最も低い設定から最も高い設定の順に評価されます (最も高い設定が優先されます)。
		
□AWS Direct Connect でのアクティブ/パッシブ BGP 接続の構築
	https://aws.amazon.com/jp/blogs/news/creating-active-passive-bgp-connections-over-aws-direct-connect/#:~:text=AS_Path%20%E2%80%93%20%E3%81%93%E3%81%AE%E3%83%91%E3%82%B9%E5%B1%9E%E6%80%A7%E3%81%AF%E3%80%81%E7%B5%8C%E8%B7%AF%E5%BA%83%E5%91%8A%E3%81%8C%E9%80%9A%E9%81%8E%E3%81%97%E3%81%9F%E5%85%A8%E3%81%A6%E3%81%AE%20AS%20%E3%81%AE%20AS%20%E7%95%AA%E5%8F%B7%E3%82%92%E7%B5%90%E5%90%88%E3%81%97%E3%81%9F%E3%82%82%E3%81%AE%E3%81%A7%E3%81%99%E3%80%82%E3%83%91%E3%82%B9%E3%81%AE%E3%83%AB%E3%83%BC%E3%83%97%E3%81%AE%E9%98%B2%E6%AD%A2%E3%81%A8%E3%80%81%E8%B7%9D%E9%9B%A2%E3%81%AE%E7%9B%AE%E5%AE%89%E3%81%A8%E3%81%97%E3%81%A6%E5%88%A9%E7%94%A8%E3%81%95%E3%82%8C%E3%81%BE%E3%81%99%E3%80%82%E3%82%A4%E3%83%B3%E3%83%90%E3%82%A6%E3%83%B3%E3%83%89%E3%81%A8%E3%82%A2%E3%82%A6%E3%83%88%E3%83%90%E3%82%A6%E3%83%B3%E3%83%89%E3%81%AE%E5%88%B6%E5%BE%A1%E3%81%AE%E4%B8%A1%E6%96%B9%E3%81%A7%E4%BD%BF%E7%94%A8%E3%81%95%E3%82%8C%E3%80%81AS_Path%20%E3%81%8C%E7%9F%AD%E3%81%84%E3%81%BB%E3%81%A9%E5%84%AA%E5%85%88%E3%81%95%E3%82%8C%E3%81%BE%E3%81%99%E3%80%82
	
	Local Pref
		このパス属性はベストパスアルゴリズムの一番はじめに検討されるので、ルーティング制御に最適なパラメータと言えます。インバウンドとアウトバンドの両方で使用され、高い値が優先されます。
		
	AS_Path 
		このパス属性は、経路広告が通過した全ての AS の AS 番号を結合したものです。パスのループの防止と、距離の目安として利用されます。インバウンドとアウトバウンドの制御の両方で使用され、AS_Path が短いほど優先されます。
	
	MED
		数値で表現します。MED は一般的に、ピアリングされた外部 AS に対して、特定の経路の着信先を指定する時に使用します。インバウンド制御で使用され、低い値が優先されます。


□AWS Direct Connect 接続に MACsec セキュリティを追加する
	https://aws.amazon.com/jp/blogs/news/adding-macsec-security-to-aws-direct-connect-connections/#:~:text=AWS%20Direct%20Connect%20%E3%81%AE%20MACsec%20%E8%A8%AD%E5%AE%9A
	
	Secure Connectivity Association Key (CAK):CAK は、各 MACsec 対応インターフェースに関連付けられた静的な鍵です。AWS の実装では、そして実際ほとんどの実装では事前共有鍵が使用され、最初はオフラインで交換されます。
	Connectivity association Key Name (CKN):どの CAK が使用されているかを識別するために、各 MKA メッセージに文字列の形で含まれる名前
	
	AWS Direct Connect 用の MACsec の設定
		MACsec をサポートする新しい接続を作成する
		CKN/CAK を接続に関連付ける
		接続ステータスを確認する
		必要に応じて、トラフィックを新しい接続に移行する
		
		should_encrypt:接続は MKA を試み、成功した場合、接続は暗号化されたトラフィックのみを送受信する。MKA がタイムアウトまたは失敗した場合、接続は非暗号化トラフィックを許可する。
		must_encrypt:接続は MKA を試み、成功した場合、接続は暗号化されたフレームのみを送受信する。MKA がタイムアウトまたは失敗した場合、接続は暗号化された状態でダウンする。認証はしばらくしてから再試行される。
		no_encrypt:接続は MKA を実行しない。受信した MKAフレームはすべて無視される。接続は暗号化されていないフレームのみ送受信する。

□Link Aggregation Group (LAG)
	https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/lags.html
	
	1 つの AWS Direct Connect エンドポイントに複数の接続を集約し、それらを 1 つのマネージド型接続として扱うことを可能にする論理インターフェイスです

□AWS Direct Connect 仮想インターフェイス
	https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/WorkingWithVirtualInterfaces.html

	AWS Direct Connect 接続の使用を開始するには、次のいずれかの仮想インターフェイスを作成する必要があります
	
	プライベート仮想インターフェイス: プライベート IP アドレスを使って Amazon VPC にアクセスするには、プライベート仮想インターフェイスを使用する必要があります。

	パブリック仮想インターフェイス: パブリック仮想インターフェイスは、パブリック IP アドレスを使用してすべての AWS のパブリックサービスにアクセスできます。

	トランジット仮想インターフェイス: Direct Connect ゲートウェイに関連付けられた 1 つまたは複数の Amazon VPC Transit Gateway にアクセスするには、トランジット仮想インターフェイスを使用する必要があります。任意の速度の AWS Direct Connect 専用接続またはホスト接続で、トランジット仮想インターフェイスを使用できます。Direct Connect ゲートウェイの設定については、「Direct Connect ゲートウェイ」を参照してください。
	
□AWS Direct Connect を使用して高い復元力を実現
	https://aws.amazon.com/jp/directconnect/resiliency-recommendation/
	
	リモート接続を設計する際は、冗長ハードウェアおよび通信プロバイダーの使用をご検討ください。さらに、冗長ネットワーク接続全体で自動ロードバランシングおよび自動フェイルオーバーを行うために動的にルーティングされたアクティブ/アクティブ接続を使用することがベストプラクティスです。十分なネットワーク容量をプロビジョニングし、1 つのネットワーク接続に障害が起きても冗長接続がひっ迫・低下しないようにする必要があります。 
	
	


□


□


□

■Global Accelerator

□Global Accelerator
	https://dev.classmethod.jp/articles/re-introduction-2022-globalaccelerator/

	通信レイテンシーの改善
	静的 IP によるアプリケーションへの単一エントリの提供
	アプリケーションの保護

	エンドポイント/エンドポイントグループ
		エンドポイント は Global Accelerator が最終的にリクエストをルーティングするターゲットで、Global Accelerator では NLB/ALB/EC2/EIP が指定可能となっています。また、エンドポイントグループ は 1つ以上のエンドポイントが含まれるエンドポイントの集合体を指します。

□AWS Global Accelerator の使用開始
	https://docs.aws.amazon.com/ja_jp/global-accelerator/latest/dg/getting-started.html


□


□


□

■EC2

□Amazon EC2 で自分の IP アドレスを使用する (BYOIP)
	https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-byoip.html
	
	


□EC2 インスタンスのネットワークの最大送信単位 (MTU)
	https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/network_mtu.html#jumbo_frame_instances
	
	ジャンボフレーム (9001 MTU)
		ジャンボフレームでは、パケットあたりのペイロードサイズを拡張し、パケットオーバーヘッド以外のパケットの割合を高めることによって、1500 バイトを超えるデータを送信できます。同じ量の使用可能なデータを少ないパケットで送信することができます。ただし次の場合には、トラフィックの MTU は最大 1500 に制限されます。
		次の場合には、トラフィックの MTU は最大 1500 に制限されます。
			インターネットゲートウェイ経由のトラフィック
			リージョン間 VPC ピアリング接続経由のトラフィック
			VPN 接続経由のトラフィック
			EC2-Classic 用の特定の AWSリージョン外部にあるトラフィック
	


□


□


□


□


□


□


□

■AWS Config

□AWS Config ルールによる非準拠リソースの修復
	https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/remediation.html
	
	AWS Config では、AWS Config ルール で評価されている非準拠のリソースを修復できます

□AWS Systems Managerオートメーションランブックを利用して非準拠ステータスのAWS Configルールを修復する
	https://aws.amazon.com/jp/blogs/news/remediate-noncompliant-aws-config-rules-with-aws-systems-manager-automation-runbooks/
	
	Systems Managerオートメーションランブックを使用して、非準拠になっているAWS Configルールを修復する

□AWS Config と AWS CloudFormation StackSets を使用した AWS Organizations アカウントの管理
	https://aws.amazon.com/jp/blogs/mt/managing-aws-organizations-accounts-using-aws-config-and-aws-cloudformation-stacksets/
	
	Organizations を AWS Config 機能およびAWS CloudFormation StackSets と組み合わせることで、数百または数千のメンバーアカウントを効率的に管理できます
	
	
□AWS CloudFormation StackSets と AWS Organizations
	https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/services-that-can-integrate-cloudformation.html
	
	

□


□


□


□


□HTTP 502 ステータスコード (Bad Gateway)
	https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/http-502-bad-gateway.html
	
	HTTP 502 ステータスコード (Bad Gateway) は、CloudFront がオリジンサーバーに接続できず、リクエストされたオブジェクトを提供できなかった場合に返されます。
	
	該当するドメイン名を含む新しい SSL/TLS 証明書を取得します。

	AWS Certificate Manager (ACM) を使用する場合は、AWS Certificate Manager ユーザーガイドの「パブリック証明書をリクエストする」を参照して、新しい証明書をリクエストしてください。

	CloudFront で SSL を使用してオリジンに接続しないように、ディストリビューション設定を変更します。
0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1