[レポート]ネットワーク Deep Dive #AWSSummit

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Summit Tokyo 2015TA-08: Tech Deep Dive by Amazon:「ネットワーク Deep Dive」のレポートです。

スピーカーはAmazon Data Services Japanの吉田英世氏です。

IMG_1897

レポート

AWSにおけるNetwork→Core Services

VPC Direct Connect Route53

VPCベストプラクティス

AWS Marketplaceの活用

1900の製品が登録、236のネットワーク製品が利用可能 ファイアアウォール ロードバランサ WAF ルータ ネットワーク高速化 費用は従量課金 Marketplaceの利用→EC2 Launch画面でMarketplaceを選択するだけ

VPC Peering

VPC同士をつなぐサービス Peering Connectionを作成しVPC同士で設定するだけ 企業間コラボレーションの例 AWS同士のシステムであればVPCを使わなくてもVPC Peeringだけで相互に接続可能 セキュリティ機能の共有 セキュリティ系アプリケーションを独立したVPCに固めて、各システムVPCから接続 セキュリティを共通サービスとして提供する

VPCのルーティング

全てルートテーブルに基づく IPレベルでの接続性を確保 どのオブジェクトにトラフィックを転送すれば良いのかを設定する IGW、VGW、VPC Peeringなどのオブジェクト 主なルーティングのエントリ VPCのCIDR→local デフォルトルート(0.0.0.0/0)→IGWやNATインスタンスなど オンプレミスへのルーティング→VGW 他のVPCへの通信→VPC Peering

VPCのセキュリティ

ネットワークACL→ブラックリスト型、ステートレス →ネットワーク構築時に不要な通信を禁止 セキュリティグループ→ホワイトリスト側、ステートフル →システムで使う通信を許可 ルーティングとセキュリティ ルーティングテーブルで疎通性を確保 全体で不要な通信をネットワークACLで禁止 個別に必要な通信をセキュリティグループで許可 それぞれのコンポーネントの特徴に合わせて適用を

VPCエンドポイント

従来はNATインスタンスが無いとプライベートサブネットからS3にアクセス出来なかった プライベートサブネットから直接S3にアクセス可能になった VPCエンドポイントへのルーティングを作成する 今後S3以外のサービスでもエンドポイントが作成される予定 エンドポイントポリシー エンドポイントを経由した通信にポリシーを適用 特定のバケットのみ通信可能とする、など 移行 VPCエンドポイントへのルーティングを追加する ロンゲストマッチでDestの狭いルーティングが優先的に適用される 注意事項 リージョンをまたいだ通信はできない そのエンドポイントがあるリージョンからしか使えない VPN先など外部のネットワークからVPCエンドポイントを使うことは出来ない

Direct Connectベストプラクティス

AWSのBGPの動作

ルートにBGP属性値は付与しない、ルータのBGP属性値を評価する ロードシェアリング可能、マルチパスが有効 プライベート接続ではVPCのCIDRを広告する パブリック接続ではリージョン内のAWSクラウドのプレフィックスを広告する

回線のフェイルオーバーを高速化する

デフォルトではフェイルオーバーまで90秒から180秒 リンクダウンではなく途中経路の切断の場合 →ルータで検知が出来ないため、タイムアウトまで待つ BFD(Bidirectional Forwarding Detection) ミリsec単位でBFDパケットを送受信 対向からBFDパケットが到達しなければ障害と判断 高速なフェイルオーバーが可能 DirectConnectのオフィシャルドキュメントでBFDを推奨 ルータがBFDを利用できる必要がある BFDが使えない場合→keeplaliveとholdtime BGPの機能の一部 holdtime時間内にkeepaliveパケットが受信出来なければ障害とはなん holdtime値を調整してフェイルオーバーを高速化する 対向同士でholdtimeを比較、低い方を使う →カスタマルータで低くすれば、DX側ルータも低い値を採用する

DirectConnectのトラフィック設定

2本以上の複数経路がある場合のトラフィックの流し方 Active/Standby構成 DXとVPN、あるいは複数のDXを作成し、Active/Standbyとする オンプレミスの受信はAS Path Prependのパス長が短い方を優先 オンプレミスからの送信はLocal Preferenceが高い方が優先 Active/Standbyの注意点 どの回線がActiveなのかを常に管理する 細い回線がActiveにならないように 上りと下りのトラフィックを意識 BGPの設定値によって非対称ルートになりえる Active/Activeの構成(ロードシェアリング) 複数の回線を束ねて高速化かつ冗長化 マルチパスにより送信トラフィックをロードバランス オンプレミスルータで設定することで、AWS向け通信がロードバランスされる AWSからオンプレミスへはデフォルトでマルチパスが有効になっている 広告経路が等価であればセッションベースでロードバランスする Active/Activeの注意点 回線切断時は生きている回線に通信が集中する 帯域あふれに注意 トラフィックの偏りに注意

占有型と共有型

物理線を占有するもの、物理線を他の顧客と共有するもの 占有型は物理接続単位、共有型は論理接続単位で管理 共有型は1つのVPCとしか接続できない 占有型はリードタイムが遅く高価 共有型はリードタイムが早く安価 キャリア閉域網の共有型を使われる場合が多い

ネットワークのコード化

コード化について

手順書や手動オペレーションによって構築するのではなく、 コードを作成し、実行し、インフラの構成をコードで管理する、という考え方 →オペレーションミスが防止できる →コード自体がインフラの状態を表す、構成管理できる

コード化するツール

CloudFormation JSONテンプレートでAWSのインフラ構築を自動化 複製、アップデート、バージョン管理が容易 AWS CLI、PowerShell、SDK AWSの操作をコマンドラインで行うツール CloudFormationのワークフロー JSONファイルを編集→CloudFormationにアップロード→構築 CloudFormer→既存構成を読み込んでJSONテンプレートを作成 AWS CLI 変数を使った動的な処理も可能 AWS CLIを使ったタグによる動的NAT制御の例 NATインタンス起動時にタグ情報を見て、自動的にルーティングテーブルに自分を登録する

さいごに

BGPについてなど、がっつりネットワークレイヤーから見たAWSの話が聞けて、すごく楽しかったです!