個人的に苦手意識のあるまったくわからないゾーン！やってくよーー！
とりあえずわかるまでやるしかないのじゃ。資格とるには。
Route 53
DNSサービス。可用性高く低レイテンシー。自分でDNSサーバを構築する必要がなくなる。
パブリックホストゾーンとプライベートホストゾーンがある。
パブリックは、インターネット上に公開するDNSドメインのレコードを管理するホストゾーン。
プライベートはVPC内でのDNSドメインのレコードを管理するホストゾーン。
つまり公開する情報か公開しない情報かの違い。ちなみに四つのトップレベルドメインの、異なるロケーションに配置されたDNSサーバで管理されている。
エイリアスレコード
仮想リソースレコード。よくわからんな。
- AWSサービスのエンドポイントをDNSに登録する場合
AWSサービスはエンドポイントのIPが変わり続けるため、Aレコードの設定ができない。Aレコードとは、ホスト名からIPを引き出すやつ。IP変わっちゃうなら登録しても無意味やなそりゃ。
なのでRoute53でエイリアスレコードを作成し、エンドポイントのIPに直接応答するときに使う。
よくあるのは、ロードバランサの名前はLB.comだけど、エンドユーザからは別名(site.com)でアクセスさせたいときなどに使う。
ELBは動的IPなのでAレコードは使えない。よってCNAMEを使うのが一般的だが、同じようにエイリアスレコードを使える。
どちらも別名を登録するという点では同じだが、エイリアスレコードの場合、内部で処理してから返してくれるので早い。そしてS3/CloudFront/ELBへのクエリは無料。
site.com→site.comはLB.comのことだったな…せや！LB.comのIPで応答したろ！みたいな感じ。気が利く。
- Zone Apex
管理しているDNSドメインの頂点となるノードのこと。
例えば、「www.exam.com」の「exam.com」の部分のこと。すでにNSレコードにZone Apexが登録されている場合、CNAMEでの登録はできないため、エイリアスレコードを使う。
基本的にエイリアスレコード使えばいいんじゃないかな(適当)
別名ってことだけ覚えておこう。
ポリシーベースのルーティング
| ポリシー名 | 説明 |
|---|---|
| シンプルルーティング | 従来と同様、事前に設定された値に基づいて応答 |
| 加重ルーティング | 優先度を先に決めておいて、それが高いほうから |
| レイテンシールーティング | 遅延が少ないほうから |
| フェイルオーバールーティング | ヘルスチェックの結果、利用可能なところから。一個も正常なのがない場合、逆にすべて正常とみなす。 |
| 位置情報ルーティング | クライアントの位置情報に基づき応答 |
たとえば接続が不安定な場合、ダウンタイムを最小にしたいならレイテンシールーティングポリシーを設定すれば解決できる。
Direct Connect
オンプレとAWSを専用線でつなぐサービス。インターネットVPNはネット経由なのでそれぞれの特色がある。
| 項目 | インターネットVPN | 専用線 |
|---|---|---|
| コスト | 安価なベストエフォートの回線を選択して利用することも可能 | 高め |
| 利用開始までの期間 | 短い期間で開始可能 | 数週間以上 |
| 帯域 | 暗号化などのオーバーヘッド(負担)による制限あり | 占有型は1,10Gbps。共有型は～10Gbps |
| 品質 | インターネットを利用してるため経路で影響を受ける | キャリアによる高い品質保証 |
| 障害対応 | インターネットを利用しているため自社の範囲外だと困難 | どの経路を使用しているのかはっきりわかるので比較的容易 |
要するに、高くて準備に時間がかかるけど早くて品質よいのが専用線。すぐ使えて安いけど品質とか速度落ちるのがインターネットVPN。よくあるのはプライマリ接続は専用線、バックアップ回線はインターネットVPNにするなど。
Direct Connectの接続構成
-
物理接続
AWS自体はDCの場所を公開していないため、AWSのパートナーの設備に用意された相互接続ポイントを使って接続する。ルータを持ち込めば占有型、持ち込まないでパートナーのを共有して使うなら共有型になる。
ちなみにパートナーのことをAPNパートナーというらしい。 -
論理接続
物理的な接続を論理的に分割し、複数のAWSアカウントで使用できる。要するに物理線一本引いて、その中で分割すれば部署や用途ごとに使える。
プライベート接続とパブリック接続
プライベート接続は、プライベートIPを利用し、VPCのサブネットへアクセスする接続。
パブリック接続は、パブリックIPを利用し、全リージョンのパブリックサービスへ接続。パブリックIPじゃないといけないのでオンプレ側にNAT機器が必要。
Direct Connect Gateway
プライベート接続でVPCに接続するとき、VGW(仮想プライベートゲートウェイ)に接続する。
ほかのリージョンのVPCへ接続する場合はVPC同士がピア接続していないといけないが、ここでDirect Connect Gatewayの出番。友達の友達は友達！！ってタイプのやつ。
しかし、注意としては、オンプレ同士は友達になれない。VPC同士もなれないってかピア接続っていう方式を使え。
課金体系
使用した時間とデータの転送量で課金される。
CloudFront
CDNサービスのこと。こいつがキャッシュを持ってればそこから配信してくれるし、もってなかったらこいつがオリジンサーバ(大本)からコンテンツを取得する。
要するに野球でいうショートやセカンドのカット(中継)みたいな感じ。外野から一本でバックホームすると負担がすごいからこいつらが受け取って代わりに投げてくれる(ちょっと違うか)
どの中継になるかはディストリビュージョンが決める。レフトだったらショートが、ライトだったらセカンドがカットに入るとかそういう決まりをディストリビュージョンっていう。(しつこい)
オリジンサーバの負荷軽減や、クライアントに対してレスポンス向上などのメリットがある。
DNSサーバへドメイン名の問い合わせ→CloudFrontへドメイン名を問い合わせ→最適なエッジサーバを応答→エッジサーバへアクセス→キャッシュから応答もしくはオリジンサーバから取得してきて応答
って流れ。
暗号化通信
言っちゃえばこいつは中継地点なので、クライアントとこいつの間で暗号化できるし、こいつとオリジンサーバ間でも暗号化できる。
-
クライアント-エッジサーバ間の暗号化
デフォルトのドメインである、cloudfront.netドメインのSSL証明書を標準で利用できる。これによってデフォルトのドメイン名で利用する場合はHTTPSでクライアントとエッジサーバとの間で通信できる。
また、独自ドメイン名の場合はX.509PEM形式のSSL証明書を入れれば利用可能。 -
エッジサーバ-オリジンサーバ間の暗号化
オリジンサーバが何かによって、暗号化の種類が変わる。
S3バケット
デフォルトではクライアントからアクセスされたプロトコルで通信される。HTTPSを必須にするなら、CloudFrontにてViewer Protocol PolicyをRedirect HTTP to HTTPS、または、HTTPS Onlyにする必要がある。
S3静的ウェブホスティング
HTTPSを使用できない。S3静的ウェブホスティングのエンドポイントがHTTPS不可のため。
この場合、S3静的ウェブホスティングはカスタムオリジンとして暗号化しなければいけない。
カスタムオリジン
CloudFrontにてViewer Protocol PolicyをRedirect HTTP to HTTPS、または、HTTPS Onlyに設定し、かつ、カスタムオリジンサーバに自分で証明書を入れなければならない。
要するにS3バケットならCloudFrontの設定変えるだけでいいけど、それ以外は設定変えたうえで証明書入れてねってこと。
##署名付きURL
コンテンツへのアクセスを期間限定にしたい場合、署名付きURLにてURLの有効期限を設定できる。
例えば期間限定で音楽配信したりとか。長い期間なら事業計画を投資家に配信したりとか。
##オリジンサーバの保護
オリジンサーバのURLが外部にばれて直接アクセスされることはセキュリティ的に大きな問題となる。(CloudFrontとクライアント間で暗号化とかしてたら、ここすっ飛ばされて暗号化できないため)
これを避けるため、オリジンサーバを保護する機能がある。
S3バケットの場合
Origin Access Identity(OAI)(かっこいい)を使い、S3バケットへのアクセスをCloudFrontからのみに制限できる。
S3静的ウェブホスティング
無力。注意すべし。
カスタムオリジン
オリジンカスタムヘッダーを利用して、CloudFrontで指定された任意のヘッダーをオリジンサーバでチェックすることで、CloudFrontからのアクセスのみ受け付けにできる。
しかし、オリジンサーバへのアクセス自体はパブリックにしておかないといけないためURL流出は注意。
要するにS3バケットの場合制限できる。カスタムの場合は制限しててもパブリックなので危険。静的ウェブホスティングは危険ってこと。まず流出しないよう気を付けよう。
以上。次回DBへ。