参考
https://www.google.com/amp/s/knowledge.sakura.ad.jp/7734/%3famp=1
転送最適化を実現
ストリーム
一コネで複数リクエスト、レスポンス
優先処理
サーバプッシュ
バイナリ転送
参考
https://www.google.com/amp/s/knowledge.sakura.ad.jp/7734/%3famp=1
転送最適化を実現
ストリーム
一コネで複数リクエスト、レスポンス
優先処理
サーバプッシュ
バイナリ転送
エイリアスレコードと非エイリアスレコードの選択 - Amazon Route 53
・CNAMEレコードと異なる
・Route 53 固有の拡張機能
・選択した AWS リソースにトラフィックをルーティングする。またはホストゾーン内の別のレコードにトラフィックをルーティングする。
・DNS 名前空間の最上位ノード (Zone Apex とも呼ばれる) にエイリアスレコードを作成できる。
例)example.com という DNS 名を登録する場合、Zone Apex は example.com。
example.com に対して CNAME レコードは作成できないが、 www.example.com にトラフィックをルーティングするエイリアスレコードを作成できる。
・Route 53 はリソースの変更を自動的に認識
例)エイリアスレコード example.com が 、lb1-1234.us-east-2.elb.amazonaws.com (ELB)を指し示してる場合、ELBの IP アドレスが変更されても新 IPが DNS クエリに応答される。
・エイリアスレコード自体にTTLは設定できない。ルーティング先のAWSリソース・別のレコードのTTLが利用される。★要確認★
DNSレコードタイプがAWS独自の場合、AWS以外からは使えないんじゃない?
→DNSレコードタイプはAWS独自でない。ルーティング先毎にタイプは定義されてるが、基本Aレコード。
加重エイリアスレコードに固有の値 - Amazon Route 53
Route 53 テンプレートスニペット - AWS CloudFormation
RecordSetGroup を使用したエイリアスリソースレコードセットの設定
★Route53のプライベートドメインを使うケースで確認したこと★
EC2は、デフォルトでip-X-X-X-X.ap-northeast-1.compute.internalでVPC内のDNSサーバに自動登録される。(正引き・逆引き両方とも)
VPCのDHCPオプションでドメイン定義できるが、このドメインのEC2のFQDNは、VPC内のDNSサーバには自動登録されない。EC2のOS設定には反映される。
Route53でプライベートドメインを定義し、全VPCのDNSサーバで公開できる。→定義したドメインで、EC2やLB等をDNS登録できる。
VPCでのドメイン利用は、
①DHCPオプションのドメインを設定する
②Route53で①をプライベートドメインで定義
③EC2等のVPCリソース間の名前での通信は、プライベートドメインのFQDNでする
上記かと、勝手に思っていた。
ただ、VPCリソースがプライベートドメインだと自動では登録されない。
VPCリソース間の名前での通信は、デフォルトでDNS登録されるドメインap-northeast-1.compute.internal等で行い、プライベートドメインの利用は最小限にするのが良いのかも。
DNS attributes for your VPC - Amazon Virtual Private Cloud
上記URLより引用
VPCのDHCPオプションでexample.comをドメインに設定
Route53で定義したプライベートゾーンとしてexample.comを定義
全VPCに定義したプライベートゾーンを割当
作成したEC2を、example.comドメインでプライベートゾーンへAレコードで登録
VPC内のEC2から、以下クエリを実行
dig google.com
dig ip-X-X-X-X.example.com
dig ip-X-X-X-X.ap-northeast-1.compute.internal
No | enableDnsSupport | enableDNSHostnames | google.com | ip-X-X-X-X.example.com | ip-X-X-X-X.ap-northeast-1.compute.internal |
---|---|---|---|---|---|
1 | True | True | OK | OK | OK |
2 | True | False | OK | NG NXDOMAINでns.icann.orgにQuery |
NG NXDOMAINでa.root-servers.netにクエリ |
3 | False | True | NG Timeout |
NG Timeout |
NG Timeout |
4 | False | False | NG Timeout |
NG Timeout |
NG Timeout |
※enableDnsSupportをFalseにするとVPC内のDNSサーバが使えない。
※enableDNSHostnamesをFlaseにするとプライベートドメインがVPCでDNS公開されない。
大きな設定項目は以下
①ホストゾーン
ゾーンの定義。レコード定義もできるが、ルーティングを細かく定義するには、トラフィック管理でレコード定義をする。
②トラフィック管理
トラフィックポリシー→DNSレコードの値側(右)をルーティング条件で定義するもの。キー側(左)は定義しない。
ポリシーレコード→キー側(左)とトラフィックポリシーを紐づける。
→上記2つあわせて、DNSレコードが定義される。
③可用性のモニタリング
ルーティング条件になるヘルスチェックの定義
Route53がエンドポイントをモニタリングする方式は、エンドポイントがグローバル公開されてる必要あり。
モニタリングはインターネット経由で行う為、プライベートサブネットのエンドポイントは監視できない。
Amazon Route 53 でヘルスチェックの正常性を判断する方法 - Amazon Route 53
上記URLより引用
設定画面でも、ローカルNGの旨、記載あり。
AWS Transit Gatewayを導入するメリットとは?構造や構築例を詳しく紹介 | TOKAIコミュニケーションズ AWSソリューション
上記URLより引用
Transit Gatewayのルーティング仕様を分かりやすく解説してみる - サーバーワークスエンジニアブログ
上記URLより引用
伝播(Propagation)は、BGP広報経路を受け取り、ルートテーブルに反映させること
※BGP経路を送信してるのは、アタッチメントだろう。
Transit Gatewayのデフォルト設定だと
「デフォルトルートテーブルの関連付け」
「デフォルトルートテーブルの伝播」
が有効。
これは以下動作となる。
これだと、アタッチメントが付与されたVPN間は全て通信可能になる。
例)
・VPC-A、VPC-B、VPC-Cがある。
・VPC-Cは共通サービス用
・VPC-A⇔VPC-C、VPC-B⇔VPC-Cのみ許可したい。
以下を設定する。
・ルートテーブルAを作成し、VPC-A、VPC-Bをアソシエーション(関連付け)
・ルートテーブルAでVPC-Cからのルートをプロパゲーション(BGP広報受け取りルートテーブルAに反映)
・ルートテーブルBを作成し、VPC-Cをアソシエ―ション。
・ルートテーブルBでVPC-A、VPC-Bからのルートをプロパゲーション
短く済むため
短縮系だとデータ構造が直感的に分からない為
例) Fn::Notの場合
Fn::Not: [condition]
→こっちで書く
!Not [condition]
Ref - AWS CloudFormation
2種類あり。
TypeがAWS::EC2::VPCの場合はVPCID
AWS::EC2::VPC - AWS CloudFormation
AWSTemplateFormatVersion: 2010-09-09 Description: AWS CloudFormation Sample Template Parameters: VpcName: Type: String Resources: Vpc: Type: AWS::EC2::VPC Properties: CidrBlock: 10.0.0.0/16 EnableDnsHostnames: True EnableDnsSupport: True InstanceTenancy: default Tags: - Key: Name Value: !Ref VpcName Outputs: VpcName: Value: !Ref VpcName Vpc: Value: !Ref Vpc
vgwはトランジット?
dxgwもトランジット?
dcgw有無でのbgp経路、動作を調べる
tracerouteなど
bgpメモ見て納得できふこと。
tgw利用時のeniの動きなど
ルートテーブルなど
tgwからdxgwへ伝播できるルートの数は20個までを確認する。
route53のエイリアスレコード
awsサービスを名前解決先にする場合に使える。cnameと似てるが、レスポンス性能よいみたい。
route53のビジュアルエディタを動かす
awsのfaqみる。
nist csfのaws資料よむ
arnの意味
サービス毎の識別子ではない。サービスが利用するリソースまで含む。例)S3であればバケット名まで
ロールのプリンシパルの制御もそう。
サービスレベルでプリンシバル定義したら、たとえばec2なら、どのインスタンスでとヘルメットかぶれる。そうならないよう、インスタンスレベルで制限してふはず。arnはインスタンス単位で定義できるため。
https://ja.javascript.info/cookie
これと
https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/aws-managed-rule-groups-baseline.html
これと
https://qiita.com/comware_hirousi/items/68daf3bbab2d29ce990e
これがインプット
CrossSiteScripting_COOKIE
これの説明文の今がわからない?
cokieのバターンで分かる?