はじめに
ソリューションアーキテクトの問題集を解いたときのメモ其の１。
書きっぷりはAWSの公式から、画像は問題集のスクショ。
特に目新しいことは書いていませんのでご了承ください！
VPC
VPCピアリングの注意点
ピアリングしたVPCを経由したり跨ったりする通信を、AWSはサポートしていない。できません。
例えば以下の環境だと。
社内オンプレミスNWとVPC-AがDirectConnectで接続されている。
VPC-AとVPC-Bはピアリングで接続されている。
この場合、社内オンプレミスからVPC-Bへのアクセスはできない。
VPC-Bから社内オンプレミスへのアクセスもできない。
→VPCはエッジ間ルーティングをサポートしていないので、このようなアクセスが不可能
なので、フォールトトレランス(壊れても大丈夫なように対策を図る考え方)を向上させるのであれば以下の対応となる。
┗ 社内オンプレミスとVPC-Aを別のDirect Connectおよび仮想インタフェースで接続する
┗ ハードウェアVPN(オンプレ側に置くVPNルータなど)を社内オンプレミスとVPC-Aに接続する
AWSでのルートテーブルとは
VPC(の各サブネット)に暗黙的に存在するルーターの経路設定。
EC2インスタンスから見るとデフォルトゲートウェイに該当する。
セキュリティグループはサーバー単位で適用、ネットワークACLsはVPC/サブネット単位で適用する。違いは認識通りでおk
ネットワークACLの評価順序
ルールナンバーの「低い順から高い順」に評価され、一致する評価があると許可・拒否ルールを即時反映する。
なのでリストの降順ってこと。CloudFlareとかのFWルールと同じ考え方でおk
ENI(Elastic Network Interface)のアタッチあれこれ
・まずENIとは？
仮想ネットワークカードを表すVPCの論理ネットワークコンポーネント。
以下の方法でEC2インスタンスにネットワークインターフェースをアタッチできる。
なのでDRに使える。
実行中のアタッチ(ホットアタッチ)
停止中のアタッチ(ウォームアタッチ)
インスタンスが起動中のアタッチ(コールドアタッチ)
ただしアタッチは同じAZのインスタンスに限る。
VPCにおけるDNSの使用
VPC内で起動したインスタンスがパブリックIPアドレスに対応するパブリックDNSホスト名を受け取るための設定が必要。
以下のパラメータが両方ともtrueの場合、DNSを受け取る。
・enableDnsHostnames
VPCがパブリックIPを持つインスタンスへのパブリックDNSホスト名の割り当てをサポートするかを決定する。
この属性がtrueの場合、VPC内のインスタンスはパブリックDNS名を受け取る。
デフォルトでfalseだが、デフォルトVPCとVPCコンソールウィザードを使って作成したVPCを除く。
・enableDnsSupport
VPCがAmazon提供のDNSサーバーを介したDNS解決策をサポートするかを決定する。
この属性がtrueの場合、Amazonが提供したDNSサーバーへのクエリは成功する。
VPCの作成方法を問わずデフォルトはtrueである。
VPCフローログと拡張VPCルーティングの違い
・VPCフローログ
VPCに出入りするログ。それを監視する。
・拡張VPCルーティング
トラフィックがVPCを通るように強制する。
それによってVPCフローログで監視ができるようになる。
VPCのCIDRブロックについて
サブネットを切る時の話。
・許容ブロックサイズは/28〜/16のサブネットマスクまで
・CIDRブロックは、VPCに関連づけられてる既存のCIDRブロックと重複してはいけない
ELB
ALBの特徴
レイヤー7に対応し、HTTP/HTTPSリスナー対応
WebsocketとHTTP/2のリクエストを受付
1インスタンスに複数ポートを登録可能
ターゲットグループでのヘルスチェックが可能
★リクエスト内容を確認して分散先を振り分ける、コンテントベースルーティングが可能
ちなみにWebsocketプロトコルとは、WebサーバとWebブラウザの間で双方向通信ができるようにするプロトコルのこと。
ALBが対応している。
パスルーティングについて
URLパスに基づいてリクエストを転送するルールを持つリスナーを作成できる。
これをパスルーティングという。
パスルーティングを使用して、1つのALBで複数のバックエンドサービスにトラフィックをルーティングすることができる。
よってパスベースルーティングによってトラフィックの制御が可能。
ELBのクロスゾーン負荷分散
有効な全てのAZの登録済みターゲットにトラフィックを分散する。
なので複数のAZにわたって全インスタンスに着信要求を均等に分散することが可能になる。
ちなみにリクエストルーティングを用いて任意のルールによって分散処理を実現することが可能。
ただし着信要求を均等に分散するためにはクロスゾーン負荷分散の方が適している。
ELBのロードバランシング機能あれこれ
ヘルスチェック
EC2インスタンスの正常/異常を確認し、利用するEC2の振り分けを行う
クロスゾーン負荷分散
配下のEC2の負荷に応じて、複数のAZに跨るEC2インスタンスに均等に負荷分散を行う
暗号化通信
SSL/TLS証明書をELBに設定することでHTTPSまたはTLS通信を実施することができる
スティッキーセッション
セッション中に同じユーザから来たリクエストを継続して同じEC2に送信する
Connection Draining
インスタンスが登録解除されるか異常が発生した場合に、そのバックエンドインスタンスへの新規リクエスト送信を中止する
ログ取得
ELBのログ取得を有効化するとS3バケットにログを収集する
API GateWay
API GateWayの権限について
IAMで権限管理ができる。IAMポリシーを使用して、開発者/管理者/ユーザーとか分けたりできる。
APIゲートウェイのスロットリングの制限機能
・サーバー側のスロットリング制限
全てのクライアントに対するリクエストを制限する。
全体のリクエストが多すぎるためにバックエンドサービスが処理しきれなくなることを防げる。
・クライアントあたりのスロットリング制限
クライアントごとに「使用量プラン」に応じて制限を行う。
特定のユーザーからのリクエストが多い場合に有効。
IAM
IAMポリシーの種類。知らなかった…！！
まず、2つに分かれる。
・管理ポリシー
・インラインポリシー
管理ポリシーがさらに2つに分かれる。
・管理ポリシー
・AWS管理ポリシー
・カスタマー管理ポリシー
・インラインポリシー
AWS管理ポリシーはReadOnlyAccessみたいないつもデフォルトで使ってるリソースのこと。
カスタマー管理ポリシーは自分でジェネレータとか使って作るいつものやつ。
この2つは複数のプリンシパルエンティティ(IAMユーザー、グループ、ロール)にアタッチできる。
管理ポリシーはポリシーのアタッチ/デタッチが自由にできる。
インラインポリシーはプリンシパルエンティティと1:1の関係であるため、複数のアタッチはできない。
いっつも忘れるけどプリンシパルは主な、とかそういう意味。
IAMデータベース認証とは
EC2インスタンスからRDSにセキュアに接続したい時とかに使う。
この認証方式ではID/Passwordではなく一時的な認証トークンを使用する。
IAMユーザーまたはロール、それに認証トークンを加えてRDSへ接続を行う。
おわりに
単純に知らなかったり、GUIで見ているはずなのに見逃してたりすることが結構多いですね。
次回に続きます！