こんにちは。
AWS認定、Advanced NW Specialtyの試験日が間近に迫ってます。
（明日です）
最後の追い込み、という形で復習をしていたところ、理解が浅いなー、とかいつも詰まるなー、という箇所があったので、復習兼ねてブログ化します。
AWS Advanced NW Specialtyって？
https://aws.amazon.com/jp/certification/certified-advanced-networking-specialty/
AWSと呼ばれる、Amazon社が提供するパブリッククラウドがあります。
それの適切な使い方を知るための資格、AWS認定というものがあり、その一種です。
正直、Advanced Netwrokingのことを書くときにこのことを話し始めるのはどうかと思いますが。笑
というのも、AWS認定にはいくつかレベルがあり、その中でも今回受験するのは専門知識と呼ばれる少々ニッチな部分です。
特に、このNetworkingは本当にニッチ。
hakutatsuは先にAWS Certified Solution Architect Professional（SAP）を獲得しています。
SAPはAWS認定の中でも最高難易度と名高いですが、その次点に来ると言われるのがこのNetworking。
範囲は狭いものの重箱の隅をつつくような細かい問題が多いので、今回始めて知ることも多かったです。
なぜ受けるの？
今の仕事で今まで以上にAWSを活用するので、もうちょっと体系的な知識がほしいな、ということで今年中に専門知識5種を全部取得することにしました。
先日Securityに合格し、その第二弾となります。
ちなみに、今年はじめに専門知識にSAP（上記Professionalとは別です、ややこしい）が追加されたので、現在は全6種です。
ただSAPは全く馴染み無いので、受験するかは今の所微妙…
全冠狙いなら取るかもですが、どうかなあ。
また、Networkingは7月に新試験のリリースが予定されています。
リリースされると、試験の性格上かなり問題が変わりそうなので、先に受けておこうという目論見もあります。
本題、よく間違えるところ
本題です。
個人的によく間違えるところを、メモ書きレベルですがまとめます。
正直勉強も後半になってるので、この試験でしか出ないものの、単なる暗記項目とかは省いてます。
（BGPコミュニティタグとか。）
こういう問題が出るんだな、とか、試験テクニック的な感じで読んでもらえると幸いです。
クライアントからUDPでアクセスする場合
Networkingでは、他の試験以上にクライアントから様々なパターンでアクセスがあります。
特に個人的によくはまる、というか見落としがちな点が、UDPでアクセスが来る場合。
結論を先に。
UDPでアクセスされる場合は、
・NLB
・EC2（Elastic/PublicIP）
・Global Accelerator
の構成でないと受けられません。
CloudFrontではHTTP/HTTPSしか受けられないので注意。
Webキャッシュがメインなのでそりゃそうなんですけど。
なので、グローバルにレイテンシを軽減させたい、という用途でも通信プロトコルによってCloudFront/Global Acceleratorのどちらを使うかは注意が必要。
参考になる記事もありましたので、詳しく知りたい方はこちら。
また、比較的最近のアップデートでNLB→ALBの構成も可能になりました。
なので、理論上は
クライアント-(UDP)→NLB-(TCP/TLS)→ALB
という構成が可能なはず。
アプリケーションには結局TCP（HTTP/S）で届くので、実用性があるかは微妙ですが。
ALBのConnection Draining
ALBがある構成で、クライアントのセッションが中断された場合、被疑箇所として
・Sticky Session
・Connection Draining
がだいたい比較して登場します。
Sticky Sessionは、ターゲットグループにロードバランシングする際、一定のルール（ELBの種類によって異なる）に基づき、同じターゲットにルーティングできるようにする設定。
Connection Drainingは、ターゲットに異常が発生した際に、設定時間分遅延を発生させ、継続中のコネクションが中断されないようにする設定。
（新規コネクションは発生しないようになる）
全然用途が違うので、ちゃんと問題文読みましょう、って感じですね。
例えば、クライアントのセッションが急に切断されることが問題、であればConnection Drainingですし、一定のユーザがアクセス時に正常にルーティングされない、であればSticky Sessionを疑います。
Zone Apexについて
Route53、DNS界隈ではよく初心者がハマる制約の一種だと勝手に思ってますが、案の定たまに間違えるので整理。
たとえば、
example.com
|-www.example.com
|-internal.example.com
というドメイン構成があったとします。
この場合、最上位に位置するexample.comがZone Apexと呼ばれます。
このZone Apexには、CNAMEレコードを作成できない、という制約があります。
正確な理由としては。Zone ApexにはNSレコードが仕様上必要となるため、となります（RFC1912）。
そのため、CNAMEレコードはZone Apexではなく、サブドメインがついている状態である必要があります。
上記の例で行くとwwwやinternal、といったものです。
ではIPアドレス（Aレコード）でしか登録できないのか？
いえ、AWSではその代替としてALIASレコードなるものがあります。
DNS上の扱いはAレコードとして設定しますが、実態はCNAME相当の動きをします。
ややこしいですね。
ただ、あくまで相当、であり、CNAMEとは違うのでそこは注意。
またALIASはAWS内のリソースである必要があり、その中でも無制限に使えるわけではないのでご注意ください。
以下のサイトが詳しかったです。
Split View
上記に続いてDNSの話。
上記はPublicでもPrivateでも共通の話でしたが、それらを混在させることも出来ます。
この構成のことをSplit View、もしくはSplit Horizonと言います。
（相変わらずややこしい）
この際に、Route53 Resolverを使って名前解決することになりますが、評価順序として
・Private Hosted Zoneの名前解決で一致するものがあるか確認
・一致するものがない場合、パブリックDNSに転送
という流れで検索されます。
つまり、先の例でinternalサブドメインを内部公開したい場合は、Hosted Zoneを分割させることによって実現可能です。
example.com(Public)
|-www.example.com
internal.example.com(Private)
DNS名が重複しているものの、先の評価順序からPrivateが先に解決されるため、Resolverを経由した名前解決ではSplit Viewを実現できます。
まとめ
直前勉強でよく詰まった箇所を書き出しました。
書き出してみると、頑張って勉強したDirect Connect周りを全く書かなかったことに気づきました。
こういう勉強法はもっと事前にやっておくべきですね。
反省。
とりあえず明日がんばります。
追記：合格しました
無事一発合格できました。
上記の対策が思ったよりも役立ちました。
想像以上にRoute53周りの設問が多く、スプリットビューの問題もありました。
事前にきちんと整理できておいたので、自身を持って答えることが出来ました。
前日だろうがやれることはやっておくに越したことはないですね。
悩む問題はSAP並に悩むものもありましたが、暗記知識で答えられるものも多かったのでその分難易度は幾分易しめだった印象。
まあ、元がインフラなのでというのも多分にありそうですが。
とにかくこれで一旦落ち着いた。
溜まっている編曲やら勉強やら積ん読やらを片付けて、次はデータベース専門知識を…
