difficult points that make static website, using Route53, CloudFront, ACM and S3 via https

i think, there are some difficult points make https static website using Route53, CloudFront, ACM and S3.

so i searched and writing knowlege in this blog.

Route53

can’t select CloudFront distributions at CNAME Alias, after setting CloudFront.

please set Alias ” No “, and set CloudFront Domain Name in Value.


ACM

please set region US East (N. Virginia) when you get certificate.

if you other region you set, you can’t  select certificate in CloudFront AWS conslole.


CloudFront

can’t set certificate, after you get certificate at US East (N. Virginia) region.

answer 1:

please wait few days.

if you get certificate at Certification Manager, you can’t select in CloudFront immediately.

i waited few days and i could selected it.

 

ansewer 2:

you upload certificate by aws acli.

maybe you can select certificate at CloudFront AWS console immediately.

but i don’t try this method.

https://aws.amazon.com/premiumsupport/knowledge-center/custom-ssl-certificate-cloudfront/

displayed file list of XML, via CloudFront

please set ” Default Root Object ” at CloudFront AWS console.

example, ” index.html “.

Access Deny occur, when you access your domain.

please set ” Alternate Domain Names (CNAMEs) ” your domain at CloudFront AWS console.

Access Deny occur via CloudFront

please public access setting, at S3 object and bucket at S3 BucketPolicy.

i setting every thing, but i can’t access.

there is possibility used cache at CloudFront.

so remove cache at Invalidation tab of CloudFront console. and input ” /* “.


S3

you can access “static website hosting” url. but can’t via CloudFront.

there is possibility, you did’t setting public access policy at S3 object and S3 bucket.

so you setting public access setting at it.

if you have too many object.

using aws cli command is very useful.

aws s3 sync . s3://my-bucket/path –acl public-read

error occur when public access setting at S3 bucket.

please select ” false ” at Piblic access settings of Permissions.

this function is add AWS console, at November 18th, 2018.

Route53 + CloudFront + ACM + S3 で https する際にハマったこと

ネットの記事をみながら構成していくなかで、ハマったこと

Route53

CloudFront の設定が終わって、Route53 で、登録したドメインの CNAME に、CloudFront のドメイン名を登録するときAlias を選択しても、Target の候補に CroudFront が出てこない。

Alias No を選択して、Value CloudFront のドメイン名を入力しよう。


ACM

証明書をとるときは、リージョンを「バージニア北部」にしよう。

そうしないと、CloudFront の画面で取得した証明書を選択できない。


CloudFront

バージニア北部」で証明書を取得しても CloudFront の画面で設定できない。

解決方法1:

待つ。

ACM で証明書を取得しても、すぐには CloudFront の画面で選択ができない。

私は 1,2 日待ったら選択できるようになりました。

 

解決方法2:

手動でアップロードする。

私は試してないですが、手動でアップロードすることですぐに反映されるみたいです。

Amazon CloudFrontの独自ドメインSSL証明書をAWS CLIでアップロードする

CloudFront 経由で S3 にアクセスしたら、ファイル一覧の XML が表示される。

解決方法:

CloudFront の設定画面で、「Default Root Object」を設定しましょう。

例えば、index.html など。

取得したドメインで、CloudFront 経由でアクセスすると AccessDeny になる。

CloudFront Alternate Domain Names (CNAMEs)」に、

アクセスしたいドメインの値を設定しましょう。

CloudFront 経由で AccessDeny になる。

S3 バケットポリシーで、オブジェクトとバケット全体を、パブリック公開設定にしましょう。

もろもろ設定したけど、やっぱりダメだ。

CloudFront でキャッシュが残っている可能性があります。

CloudFront Invalidations “/*” を設定して、全てのキャッシュを削除してみましょう。


S3

static website hosting url にはアクセスできるが、CloudFront 経由でアクセスできない。

バケットと、オブジェクトがパブリック公開になっていない可能性があります。

バケットポリシーを公開設定にして、各オブジェクトを公開設定にしましょう。

オブジェクトが大量にある場合は、 aws cli を用いてコマンドでサイドアップロードするのが手っ取り早いです。

aws s3 sync . s3://my-bucket/path –acl public-read

バケットポリシーを公開設定にしようとするが、エラーになる。

「アクセス権限」の「パブリックアクセス設定」を全て false にしましょう。

この機能は、201811/18から AWS に追加されました。

[AWS] IAMユーザで請求情報を確認する

AWSの請求画面を表示するには、デフォルトの設定だと

root でログインしなければ見ることができません。

今回は IAM ユーザでログインして請求画面を表示させる方法を書きます。

公式ドキュメント

https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/grantaccess.html

 

IAM ユーザで請求画面を表示させるには、次の 2 つの設定が必要になります。

  • root でログインし、請求画面を IAM ユーザにも表示させるように設定
  • IAM ユーザに、請求画面を表示させるポリシーをアタッチ

 

root でログインし、請求画面を IAM ユーザにも表示させる設定

root でログインし、右上のバーからアカウントを開きます。

画面をスクロールし、「IAM ユーザ/ロールによる請求情報へのアクセス」を開き

「IAM アクセスのアクティブ化」にチェックを入れ「更新」します。

IAM ユーザに、請求画面を表示させるポリシーをアタッチ

請求画面を表示させたい IAM を選択し、

「Billing」のポリシーをアタッチします。

これで請求情報の全て(請求書 や 予算 など)が表示できるようになります。

個別に許可したい場合は、下記のドキュメントを参考に個別にポリシーを付与しましょう。

https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/billing-permissions-ref.html

IAM ユーザでログインしなおし、請求画面を開くと問題なく表示ができました。

 

AWS 認定試験準備ワークショップを受けました

AWS 認定試験準備ワークショップ

https://pages.awscloud.com/event_JAPAN_certified-sa-associate.html

を受けたので、そのときのレポート

 

このセミナーでは、問題の解き方が主になります。
個々のサービスの詳細な説明はしません。

まず初めに、この資格は、AWSを使って設計ができることの証明です。

メリットとしては、客観的な評価が得られること
AWS認定の期限は2
更新するためには、繰り返し受験する必要がある。

ソリューションアーキテクトに関する具体的な内容
 → 要件に対して、AWSアーキテクチャのベストプラクティスを用いてソリューションを定義できること

現在、試験は旧バージョンと新バージョンがある。
合格した結果得られる資格は一緒。
新バージョンと旧バージョンの違いは、出題されるサービスの内容が新しいか古いかの違い

出題内容は4つの分野に分けられる。

  • 分野1:可溶性、コスト効率、スケーラブルなシステムの設計
    出題率:60%
  • 分野2:実装・デプロイ
    出題率:10%
  • 分野3:データセキュリティ
    出題率:20%
  • 分野4:トラブルシューティング
    出題率:10%

分野1がもっとも多く出題される。

問題となっているユースケースをサービスを使って解決するための問題が出る

設問は選択式の問題

今日の講義では、問題の狙いを見極めるポイントや答えのポイントを説明する。



分野1:可溶性、コスト効率、スケーラブルなシステムの設計

可用性、コスト効率、耐障害性に優れたスケーラブルなシステムの設計

最も出題数が多い分野

試験において重要なのが、これらの4つ(可用性、コスト効率、耐障害性、スケーラブル)を満たすために

どのようなサービスを組み合わせるのか知っていること。

可用性とは
→ システムが停止してしまったときに、復旧までの時間が短いこと
例えば、ec21台で動いているのであれば、停止したときのために Load Balancing を使う、など。

耐障害性とは
障害が起きてもサービスが動き続けられるかということ。

スケーラブルとは
システムの性能が足りなくなったときに、Auto Scaling する仕組みのこと
例えば SQS など

原則の1つ目

「疎結合で柔軟に」

システムが疎であるほど、スケーラビリティがあがる。

ポイントとしては、個々の固有の情報に依存しないこと

例えば、 IP アドレスを固定にせずに、 DNS とエンドポイント名を使うなど。

リソース固有の情報に依存しないサービス

  • ELB
  • RDS
  • Route 53
  • EIP(再マッピングが可能)

他のコンポーネントの健全性を前提にしない

  • ELB
  • SQS
  • SNS

 

練習問題

疎結合アーキテクチャの実装を用意にするものはどれですか?

選択肢

1:Cloud Formation

2:SQS

3:Croud Trail

4:ELB

5:Elastic Mapreduce

 

解答

2, 4

 

解説

1: 違う。コンポーネントのスタックを起動するサービス。

3: 違う。これは。ロギングサービス
 awsapiを全てロギングするサービス
なので障害が起こったときに、原因追求になる。

5: 違う。これはマネージド hadoop のサービス

 

実際に問題を解く際には、消去方が良い。

 

原則2つ目

「障害に備えた設計にすれば問題は起きない。」

各コンポーネントに障害が生じたらどうなるか?という観点が大事。

高可用性と耐障害性の考え方の違い

 

例えば、前提として、

SLAを満たすには4つのEC2インスタンスが必要という状況だった場合に、

AZ で障害が起きた場合を考える。

 

耐障害性のない例だと

AZ2つに、ec22台ずつ置いている場合。

耐障害性のある例だと

AZ2つに、4台ずつ置いている場合。

一般的に耐障害性が上がるとコストが上がるということがある。

もう1つの例だと、

AZ3つに、2台ずつ置く例。

これはコストを抑えられている。ただ、複雑さはある。

 

可用性の実現

  • 複数のAZおよびリージョンを使用する
  • 可用性の高いサービスを使う。
  • Multi-AZ Amazon RDS : 2つの AZ でレプリケーション
  • S3 : 異なる AZ に複数のコピーを保存
  • ELB : LB クラスターを提供
  • SQS : メッセージングクラスター
  • Dynamo DB :
    同じリージョンの複数の AZ 感でデータを自動的に同期してレプリケートする。
    施設規模で障害が発生してもデータを保護することができる。
  • Route 53 :DNSクエリに対する応答に失敗したことがない。

耐障害性の実現

  • Dynamo DB : 同上
  • Route 53 : 同上

 

練習問題

現在使用しているWebサービスのパフォーマンス SLA は、1秒未満でリクエストに応答するというもおです。
通常の運用でも高負荷な運用でも、4つのインスタンスにリクエストを分散することでこの SLA を達成しています。
1つの AZ が利用不可能になった場合、サービスの高可用性と耐障害性を確保できるのは次のどのアーキテクチャですか?

 

選択肢

1: 1つの AZ 4つのサーバーにサービスをデプロイする。

2: 1つの AZ 6つのサーバーにサービスをデプロイする。

3: 2つの AZ にまたがる4つのサーバーにサービスをデプロイする。

4: 2つの AZ にまたがる8つのサーバーにサービスをデプロイする。

 

解答
4

 

解説

1: 単一のAZなので違う

2: 単一のAZなので違う

3: 1つの AZ に対してインスタンスが2つだけでは SLA を満たさないので違う。

原則3つ目

「融通の聞く実装」

クラウドのメリットとしては、必要な時に生成して、不必要な時に削除するということ

固定IPアドレスが必要な構成にしないこと。(アンチパターン)

固定的なIPアドレスが必要な場合には付け替え可能なEIPを用いよう。

 

ELBを配置することで

背景にあるシステムに融通が聞く。

auto scalingを設定する。

これにより、適切なec2インスタンスの数を保持することができる。

 

自在に再起動できる設計を使用する

  • ステートフルではなく、ステートレスに。
    セッションデータを DynamoDBに保存するなど
  • ELB と Cloud Watach を使用して、インスタンスの健全性を調べる。
  • ブートストラップ
    ユーザデータやアプリケーションを、マシン起動時にインストールするようにするとよい。
    可能であれば、構成やカスタマイズ設定をインスタンス外に保存
  • S3にアプリケーションを置いて起き、ユーザデータ処理で配置など
    セッションデータなどを別レイヤ(RDS)などに保存するようにすれば、
    EC2が増えたとしても同じ値が取得できる。

 

練習問題

ある携帯電話会社が、動的コンテンツを使ってコンテストのテレビコマーシャルを放送しています。
この会社は、コマーシャルが放送された後のウェブサイトのトラフィックの急増に対応したいと考えています。
ウェブサイトは対話型で、訪問者の所在地、購入履歴、現在放送中のコマーシャルに応じてカスタマイズされたコンテンツが表示されます。
Auto Scaling を設定して需要の急増に応じてスケールアウトし、同時に需要の少ない時間のコストを最小化できる
アーキテクチャはどれですか?

 

選択肢

1: スケールアウトしなくても高いトラフィックボリュームに対応できるような最小サイズを持つ、
Auto Scaling グループを設定する。

2: トラフィック負荷のピークに対応できる大規模な Auto Scaling Group を作成し、
一部のインスタンスを停止する。停止したインスタンスを使用してトラフィックが増加したときに
スケールアウトするように Auto Scaling Group を設定し、新しいキャパシティーがすぐにオンラインになるようにする。

3: Cloud Front S3 を使用して静的コンテンツを保存する。トラフィックの増加に合わせて
スケールアウトするように Auto Scaling を設定する。事前設定された AMI から新しいインスタンスを起動し、
起動時にユーザデータを渡すようにし、起動設定を行う。

4: Auto Scaling グループをオリジンとして設定し、Cloud Front S3 を使用して変化するコンテンツをキャッシュする。
Auto Scaling を設定して、最初に Cloud Front ElastiCache にキャッシュを追加するのに
必要な数のインスタンスを起動し、キャッシュが完全に追加されたらスケールインする。

 

解答
3

 

解説

1: 常にトラフィックのピークに合わせてプロビジョニングするため、コストがかかりすぎる。

2: Auto Scalingの仕組みは、あらかじめ停止したインスタンスを用意するというものではなく

新しい EC2 インスタンスを生成したり削除したりするということ

4 : 動的コンテンツの配信に対応していないので違う

 

練習問題

3つの AZ (us-east-1 a, us-east-1 b, us-east-1 c) us-east-1で稼働しているアプリケーションがあります。
このアプリケーションは、通常9つの EC2インスタンス を実行する必要がありますが、
AZ が利用できなくなった場合に、 Auto Scaling が代替インスタンスを残りの AZ で起動しているあいだは
65% 以上のキャパシティーで実行できます。
このアプリケーションに最も高い可用性を実現できるインスタンスのデプロイ方法はどれですか?

 

選択肢

1: アプリケーションを us-east-1 a 4つのサーバー、 us-east-1 b5つのサーバーにデプロイし、

予備として us-east-1 a に停止したインスタンスを5つ用意する。

2: アプリケーションを us-east-1 a, us-east-1 b, us-east-1 c それぞれ3つのサーバーにデプロイする。

3: アプリケーションを us-east-1 b 6つのサーバー、 us-east-1 c 3つのサーバーにデプロイする。

4: アプリケーションを us-east-1 b 9つのサーバーにデプロイし、予備として us-east-1 aに停止した
サーバーを9つ用意する。

 

解答
2

 

解説

1: Auto Scaling は停止したインスタンスを起動しない

3: 2bが利用できなくなった場合、停止率が66%となる。

4 bで停止した場合に、100%停止してしまうのでだめ。



分野2:実装/デプロイ

10%の出題

全員が開発者である必要はない。

コードで自動化ができる

 

分野1(可溶性、コスト効率、スケーラブルなシステムの設計)では、何を使用するか(what)に焦点をあてた

分野2(実装:デプロイ)では、どう使用するか(How)に焦点をあてる

howに焦点を当てているので、より実践的な内容が出題される。

 

細かい機能を把握するには、実際に触ってみるのをおすすめする。

 

現在 100 ほどのサービスがあるが、

全部を学ぶのは現実てきでなないので重点的に勉強しよう。

重点的とは?

  • コンピューティングとネットワーク
    EC2, VPC
  • ストレージ
    S3, Amazon Glacier
  • DB
    RDS

上記3つはほぼ多くのビジネスパターンで必要になってくるため重要

  • デプロイメント
    CloudFormation, Cloud Watch, IAM

これは運用していくなかで必要

  • アプリケーションサービス
    SQS, SNS

これは疎結合な運用をするために必要

「コンピューティングとネットワーキング」

EC2のオンデマンド、リザーブドインスタンス、スポットインスタンスの違い、HW専有インスタンスとは何か?を理解しよう。

EBSルートとインスタンスストアルートの比較

メタデータとユーザデータを使用したブーとストラップ

ユーザデータとは、起動時に与えられるデータ。
これをつかってブートストラップする内容も押さえておこう

EC2に連携するサービス

  • ELB
    AZはまたげるが、リージョンはまたげない。など抑えておこう
  • Aout Scaling
  • EBS
    スナップショットやEBS最適化されたEC2の利用など
  • VPC
    IPアドレッシング。セキュリティグループ関連など。

 

問題の中で、IPレンジはCIDR表記で使用するため、読めるようになっておこう。

設計上の推奨としては、2つのAZにそれぞれpublicprivateのサブネットを作成する。

同じVPC内のEC2はプライベートIPを使ってアクセスできる

IPアドレスを関連ずける方法は、生成時に紐づける方法と、起動後に紐づける方法がある。

 

練習問題

EC2 インスタンスが起動され、EIP がそのインスタンスに関連づけられています。
そのEC2インスタンスで実行されているアプリケーションは、どのようにインスタンスの
新しい Public DNS 名を判断できますか?

 

選択肢

1: OSレベルの hostname コマンドを使用する。

2: EC2インスタンスのメタデータをクエリする。

3: 該当する Cloud Watch のメトリックスをクエリする。

4: EC2インスタンスのユーザデータをクエリする。

 

解答
2

 

解説

1: public nat の名前を引くことができない。

3: ホスト名はメトリックスではない。メトリックスとは常に変化するメトリックスなどを記録するもの。

4: ユーザデータはブートストラップ時の情報など。

「ストレージとコンテンツ配信」

S3 Clacier の違いを把握しておかなければならない。

S3

  • 結果を確認する整合性モデルであるということ
  • ストレージにクラスがあるということ

Clacier

  • S3は必要なときにすぐにデータを取り出せるのに対しGlacier は時間がかかる。
    これはオプションによって異なる。
  • S3での暗号化はサーバサイド暗号化のオプションが設定できる
    Gracierは全てのデータが暗号化される。

RDS

重要なポイント

フェイルオーバー時は IP アドレスが変わるので、DNS名を使用しよう

ユーザが指定した時間にバックアップが行われているよ

また、そのときにスナップショットを取っていて、それをもとに復元されるよ

復元の際は、上書きされるのではなく、新しいインスタンスが生成されるよ。

 

練習問題

プライマリの DB インスタンスで障害が発生した場合、RDS Multi-AZ 配置はどうなりますか?
3つ選択してください)

1: オリジナルのプライマリ DB インスタンスが再起動し、新しいスタンバイレプリカになる。

2: オリジナルのプライマリ DB インスタンスは削除され、新しいスタンバイレプリカが作成される。

3: DB インスタンスの DNS レコードが変更されて、新しいプライマリを指定する。

4: スタンバイの DB インスタンスがオリジナルのプライマリ IP アドレスを引き継ぐ。

5: 別の AZ のスタンバイのレプリカが新しいプライマリに「昇格」する。

6: 直近のバックアップから新しいプライマリ DB インスタンスが作成される。

 

解答
2,3,5

 

解説

この問題はフェイルオーバー時の問題。

1: オリジナルのプライマリは削除される。RDSでは、障害の要因に関わらず、すぐにセカンダリが昇格する。

4: RDS IP アドレスではなく、 DNS 名を使用する。
ほとんどのAWSサービスでは、ベストプラクティスを採用しており、DNSを利用することを覚えておこう

6: Multi-AZ RDS はレプリケーションとフェイルオーバーを使用する。

 

ここで問題を解くときに注意することが、フェイルオーバー時の処理が

選択肢の順番になっているとは限らないということ

 

順番にならべると

5 -> 3 -> 2の順番で処理が行われる。

デプロイメントとマネジメント

  • Cloud Formation
    EC2のブートストラップなども実行ができる。
  • Cloud Watch
    クラウドリソースとアプリケーションを監視

組み込みメトリックスとカスタムメトリックスの違いを把握しておこう

アラームと Auto Scaling

IAM

IAMロールなどを把握しておこう

 

アプリケーションサービス

  • SQS
    テキストのみのメッセージをやりとりできるポーリングモデルと、名前つきキュー

非同期ワークキュー

  • SNS
    Pub-Sub(プッシュ)モデル、名前付きトピック
    送信メカニズム:HTTP/HTTPSSQSSMS、メール

SNS Cloud Watch アラームと連携

この2つはメッセージングサービスである。

メッセージングサービスは、疎結合を実現するのに役立つ。

まとめ

  • 重要で、よく利用されているサービスに焦点を当てる。
  • 各サービスについて以下を実施する。
    → 基本的なユースケースとパターンを把握
    → サービスの仕組みと使用方法を把握
    → 実践での経験を積む
  • 暗記しない:試験に求められるのは機械的な暗記力ではなく、応用力です。


分野3:データセキュリティ

重要なことは、レイヤーごとにセキュリティを設定するということ

各レイヤーでどのようにセキュリティを設定するのかを把握しよう。

 

4つのレイヤー

  • インフラストラクチャーレイヤー
  • コンピューティング/ネットワークアーキテクチャレイヤー
  • データレイヤー
  • アプリケーションレイヤー

 

「インフラストラクチャー」で重要なこと

責任共有モデル

→お客さんとAWSで担保しなければならない責任範囲が別れているということ

→試験でも、どのように責任範囲が別れているのかが出題される。

 

AWS リソースの保護

最小権限の原則

アイデンティティ

各ユーザまたはプロセスの権限は、実行する必要があるアクティビティに限られる。

  • ユーザまたはプロセスの権限はアイデンティティで示される。
  • AWS API にアクセスできるアイデンティティは3種類
    → 「マスターアカウント」
    最初のメールアドレスによって設定されるアカウント
    乗っ取られたら被害がすごいので多要素認証を設定しよう。
    そのアカウント全体に対する完全な権限を持っている。
    制限できない。

MFAの追加をしよう。

ベストプラクティスは、このアカウントをアイデンティティに使わないことです。

  •  IAMユーザ
    グループやポリシーによる詳細なアクセスコントロール
  • AWSコンソール / CLI / API アクセスをコントロール
    → Security Token Service(STS)/フェデレーション

STS / フェデレーション」

おそらく理解するのがもっとも難しい仕組みが STS です。

STSを使用すると、

一時的な権限を付与することができる。

フェデレーションとは
→ AWS とか別の、例えば社内で許可を得た人だけがアクセスできるような仕組みのこと

 

練習問題

会社の AWS アカウント管理者が今日退職しました。
この管理者は、マスターアカウントとパーソナル IAM 管理者アカウントに対するアクセス権を持っていました。
これらのアカウントを使って、この管理者は別の IAM アカウントとキーを生成しました。
会社の AWS インフラストラクチャを保護するために今すぐに実行する必要があることは、
次のうちどれでしょうか?(3つ選択してください。)

 

選択肢

1: パスワードを変更し、マスターアカウントに MFA を追加する。

2: マスターアカウントによるログインに IP 制限をかける

3: キーを交換して、 IAM アカウントのパスワードを変更する。

4: IAM アカウントを全て削除する。

5: 管理者の IAM アカウントを削除する。

6: 全ての EC2 インスタンスを新しいロールで再起動する。

 

解答
1,3,5

 

解説

2: マスターアカウントは一切制限をすることはできません

4: デメリットが大きすぎるので、そこまでの必要はない。

6: ロールはSTSに基づいているため、元社員が認証情報を引き続き持っているわけではない。

「コンピューティング/ネットワークアーキテクチャの保護」

サブネットの役割は

vpcをさらに細かい IP アドレスの範囲に区切るということ。

SGNACLの比較

この2つの違いを把握しよう

ほとんどの場合はSGで対応できるが、許可の仕方だけが違う。

NACLでは、ホワイトリスト方式なので、

特定の CIDR 範囲からのアクセスを拒否することができる。

「インターネットゲートウェイ、仮想プライベートゲートウェイ、Direct Connect

VPC にトラフィックを出し入れするサービス

それぞれのユースケースを把握

  • IGW: インターネットに接続
  • VGW: VPNに接続
  • Direct Connnect: インターネットを使わずに、AWSとオンプレミスの環境を繋ぐ専用線接続
  • VPC ピアリング: 他のVPCに接続

「ルートテーブル」

通信の経路を設定するために使われる。

サブネットと関連づけられる。

IP範囲の宛先を定義

  • ローカルルールはデフォルトで定義
  • インターネット(パブリックサブネット)にアクセスするための IGW へのルート
  • オンプレミスネットワークにアクセスするための仮想プライベートGWへのルート
  • ピアリングされた VPC にアクセスするためのピアリング接続へのルート

ルートテーブルの際に意識しないといけないのが

VPC の外と中で通信をしたいときの設定。

 

練習問題

あなたは VPC 内のサブネットにインスタンスをデプロイしました。
S3 へのアクセスを許可する手順で、正しいのは次のどれでしょうか?

1: 仮想プライベートゲートウェイを追加する。仮想プライベートゲートウェイへのルートを 0.0.0.0/0 と指定する。
ACL のアウトバウンドルールでポート443 を開放をする。インスタンスに EIP を追加する。

2: IGW を追加する。IGW へのルートを 0.0.0.0/0 と指定する。SGのアウトバウンドルールで443 を開放する。インスタンスに EIP を追加する。

3: 仮想プライベートゲートウェイを追加する。仮想プライベートゲートウェイへのルートを 0.0.0.0/0 と指定する。
SGのアウトバウンドルールでポート443 を開放する。VPC から割り当てられる内部 IP アドレスを使用する。

4: 仮想プライベートゲートウェイを追加する。仮想プライベートゲートウェイへのルートを 0.0.0.0/0 と指定する。
SGのアウトバウンドルールでポート 443 を開放する。VPC から割り当てられる内部 IP アドレスを使用する。

5: IGW を追加する。IGW へのルートを 0.0.0.0/0 と指定する。ACL のアウトバウンドルールでポート443 を開放をする。インスタンスに EIP を追加する。

6: IGW を追加する。IGW へのルートを 0.0.0.0/0 と指定する。SGのアウトバウンドルールでポート 443 を開放する。VPC から割り当てられる内部 IP アドレスを使用する。

 

解答
2

 

解説
S3への経路で、仮想プライベートゲートウェイを使うことはありません。
そのため、1,3,4が除外できる。
ACLでは除外するためのアクセスのみ設定できるので、
アウトバウンドとインバウンドが設定できなければいけない。
そのため、5が除外できる。
IP アドレスは、EIPを使うので、 6が除外できる。

「データレイヤー」

データを保護する方法としては4つある

  • 転送中のデータ
    • AWS の入口と出口
    • AWS の内部
  • 保管時のデータ
    • S3
    • EBS

主要なストレージサービスである、EBS S3 を見ていこう

転送中のデータ

AWS インフラストラクチャへのデータ送信と、AWS インフラストラクチャからのデータ送信

  • ウェブ経由のSSL
  • IPSec VPN
  • 直接接続
  • インポート/エクスポート

AWS API に送信されるデータ

  • AWS API 呼び出しはすべて、HTTPS REST 呼び出しです。

S3 に保管中のデータ

アクセス

  • IAM ポリシー
  • バケットポリシー
  • アクセスコントロールリスト
  • 一時認証情報
    • 署名つき URL に使用

暗号化

  • サーバ側(AWS が管理するキー)
  • サーバ側(お客様が管理するキー)
  • クライアント側
  • クライアントコードの暗号化 / 復号化
  • キーは S3 から独立した形でお客様が管理する。

EBS に保管中のデータ」

  • 暗号化された EBS ボリューム(AWS が管理するキー)
  • EBS ボリューム上の暗号化されたファイルシステム

(お客様が管理するキー)

  • アプリケーションレベルで暗号化されたデータ
    • クライアント側にあるアプリケーションの暗号化 / 復号化データ
    • お客様が管理するキー
    • サードパーティの支援
      (例えば、一部のDBテクノロジーで使われてる Transparent Data EncryptionTDE))

EBS はインターネットにアクセスしないので、

インターネットに対するアクセスはアプリケーションの話になります。

 

練習問題

あなたの会社には機密情報があり、セキュリティポリシーにしたがってこの情報を暗号化形式で
保存しなければなりません。暗号化機能を提供するサービスは、次のどれですか?
3つ選択してください)

1: EBSボリューム

2: S3

3: EC2 インスタンスストレージボリューム

4: RedShift

5: DynamoDB

6: ElastiCache

 

解答
1,2,4

 

解説
3,5,6には暗号化機能がない。

ただし、この問題では補足が必要
5は、2018年に暗号化機能が追加された。

アプリケーションレイヤー

責任共有モデルでは、お客様が責任をおうことになっている。

「それぞれのアイデンティティによって、何を保護しているのかを把握しよう。」

  • IAM
  • OS/AD/LDAPアカウント
  • アプリケーションアカウント
  • アプリケーションの保護(オンプレミスと同様)
    安全なパスワードストレージとパスワードポリシーを使用する。

OSip tableなどで保護したり、ソフトウェアをアップデートしたりする

堅牢なロールベースアクセスコントロール(RBAC)を使用する。

 

練習問題

IAMポリシーでコントロールできるアクションは、次のうちどれですか?
3つ選択してください)

1: RDS データベーステーブルを作成する。

2: VPC SG を構成する。

3: .NET アプリケーションにログインする。

4: RDS データベースを作成する。

5: S3 バケットを作成する。

 

解答
2,4,5

 

解説
1: DB管理者の管理になる。IAMで制御できるのは RDS の作成。

3: アプリケーションのセキュリティになる。

4: 正解。1との違いは、RDSインスタンスを操作するので正解。1は、DBエンジン内の操作になるので違う。

 

練習問題

ウェブ層のインスタンス(ウェブ層の SG を共有する別のサブネットのインスタンスグループ)
からのみ HTTP トラフィックを受け入れるアプリケーション層サブネットに、
EC2 インスタンスのグループを作成しようとしています。
これを実現する方法として正しいのは次のどれですか?

 

選択肢

1: アプリケーション層インスタンスの手前の SG LB に追加する。

2: アプリケーション層の各インスタンスを、ウェブ層 SG からのインバウンド
HTTP トラフィックを許可する SG と関連づける。

3: ウェブ層サブネット IP 範囲からのインバウンド HTTP トラフィックを許可するアプリケーション層サブネットに、ACL を許可する。

4: IPアドレスに基づくアプリケーション層インスタンスにトラフィックを送信するために、
ウェブ層サブネットのルーティングテーブルを変更する。

 

解答
2

 

解説

1: ロードバランサーでは、レイヤー感でのトラフィックをコントロールできない。

3: 注目すべき点は、ACLはステートレスな操作になるので、アウトバウンドも設定しないといけない。

4: ルートテーブルはトラフィックを送信するが、ブロックはしない。

 

練習問題

公開ウェブアプリケーションがあり、ユーザが自分で登録してアカウント作成することになっています。
このアカウントは、アプリケーションの認証ユーザと静的オブジェクトを共有します。
そこで、このコンテンツを S3 に保存して、適切に権限を付与されたユーザだけがウェブ経由で
利用できるようにしたいと思います。これを実現する方法として、最もコスト効率が良く、パフォーマンス
に優れているのは次のどれですか?

 

選択肢

1: バケットポリシーでバケットにアクセス権を付与する。

2: ウェブサーバから、オブジェクトへの一時アクセス権付きの署名済み URL を返す。

3: IAM ポリシーでオブジェクトへのアクセス権を付与する。

4: ユーザのブラウザーに配信するために S3 からオブジェクトを読み出すウェブサーバコードを作成する

 

解答
2

 

解説

1: 公開ユーザは IAM ユーザを持っていない。IAM AWS インフラストラクチャを保護するが、アプリケーショは保護しない。

3: アプリケーションユーザは AWS アカウントを持っていない。

4: ウェブサーバーコードというのは、起動したウェブサーバー経友でアクセスするということ。これでも実現できないことはないが、
EC2インスタンス経友で起動するというステップが増えている。またEC2は帯域幅が小さいので遅くなる。またEC2も起動しているので、コストもかかる。



分野4:一般的なトラブルシューティングの情報および質問に関する問題

  • EC2インスタンスの接続
    • ec2にsshできないなどの問題
    • ec2が起動しないなどの問題
  • EC2 インスタンス、EBS ボリューム回復
  • AWS サービス制限の問題

「接続のトラブルシューティング」

ゲートウェイがアタッチされているか。

IGW VGW など、ゲートウェイの種類を把握しよう。

ルートテーブルをきちんと設定しないといけない

ポートに設定できるか問題:これはSGなどの設定などを把握しよう。

 

接続できないのにはいくつかの原因が考えられる。

VPC の外部から VPC 内のインスタンスまで:

  • アタッチされた GW IGW または VGW
  • 企業ネットワークから VPC までのルーティングルール
  • VPC またはサブネットのルートテーブル
  • インスタンスの EIP または パブリックIP
  • NACL
  • SG
  • OS レベルのファイアウォール

問題になるのは、あるケースで EC2 に接続できないという状況です

4つのポイントがあります。

  1.  IGW
  2. SG, NACL
  3. EIPが関連づけられているか
  4. ネットワーク経路の話
    → public サブネットのルートテーブルに、IGWが設定されていることが必要。

「インスタンス/EBS ボリューム回復のトラブルシューティング」

  • EC2 インスタンスが応答しなくなることがある
    ex. 例えば、Linux のカーネルパラメータに変な値を設定してしまったとか
    アタッチしているEBSボリュームはデタッチできる
    → 必要なら強制的にでタッチ
  • EBS ボリュームを正常なインスタンスに再アタッチする。
  • 以下のプロセスを実行して非稼動ブートボリュームを回復する。
    • ボリュームをでタッチ
    • データボリュームとしてアタッチ
    • ファイル内の問題を解決
    • 元のインスタンスに再アタッチして、再起動

「制限問題のトラブルシューティング」

AWS には様々なソフトリミットがあある。

また、いくつかのハードリミットもある

制限は相互に影響を及ぼすことがある

  • EBS の制限に達したために、 EC2 インスタンスを起動できないことがある。
  • Trusted Adviser が役立つ

一般的な制限は次の通り(基本的には全てリージョンごと)

  • アカウントごとのインスタンス数は 20 まで
    (インスタンスタイプによってはさらに少ない場合がある)
  • リージョンごとの EIP 5 まで
  • VPC ごとの SG の数は 500 まで
  • LB 20 まで
  • Auto Scaling グループは 20 まで
  • EBS: 5,000 ボリューム、10,000 スナップショット、40,000 IOSP20 TBのストレージ
  • S3 のバケット数は 100 まで。
  • ネットワークの帯域幅
  • etc…

 

問題を解く際に、制限のないようを記憶する必要はない。

  • 制限があることと、その制限によって生じる問題について注意が必要
  • 制限の引き上げを要求する方法について把握する。
    → ソフトリミットは、設定により変更できることがある。

 

練習問題

EBS-Backed EC2 インスタンスに障害が発生し、応答しなくなりました。
ルートボリュームに重要情報が入っているために復旧する必要がありますが、
あらゆる手段を試みてもインスタンスにログインできません。
元の AMI にはアクセスできますが、ルートボリュームの最新のバックアップが利用できません。
どうすればボリューム内の情報を復旧できますか?

 

解答
4

 

解説

1: デフォルトの設定では、インスタンスの削除と同時に、ルートボリュームも削除されてしまう。

設定でそうならないこともできるが、この問題ではそれが書いていないので、消えてしまう。

2: スナップショットからインスタンスは起動できない。起動は AMI からのみ可能。

3: 元の AMI には障害が発生したデータと同じデータは存在せず、同一データではないため間違い。

 

練習問題

VPC パブリックサブネットにアプリケーションをデプロイしました。
複数の同じ EC2 アプリケーションインスタンスが正常に稼動し、
インターネット経由でアクセスできます。
ここで、同じ AMI および SG を使用して、同じサブネットに新たな EC2 インスタンスを起動し、
アプリケーションをスケールすることにしました。
ところが、新しいインスタンスにはインターネットからアクセスできないことが分かりました。
どこに変更すれば、新しいインスタンスにインターネットからアクセスできるようになりますか?

 

選択肢

1: パブリックサブネット内にNATインスタンスをデプロイする。

2: 新しいインスタンスのゲスト OS に、パブリックIPアドレスを設定する。

3: EIP を新しいインスタンスに割り当てる。

4: サブネットのルートテーブルを、新しいインスタンスへのアクセスを許可するように変更する。

 

解答
3

 

解説

1: パブリックサブネット内のインスタンスが NAT インスタンスを使う必要はない。
windowファイアウォールがRDPをブロックすることはあるが、この場合、AMI から作られれているので、許可されているはず。
パブリックサブネット内のインスタンスは、EIPによって接続ができる。

2: ルーティングルールによって、ポートのトラフィックまでは制限できない。
ホスト OS が知っているのはプライベートIPのみ。パブリックIPOSが知らない情報。

4: ルートテーブルはサブネット全体に適用され、サブネット内の他のインスタンスは正常。
また、デフォルトでは全て許可されている。
ルートテーブルの問題ではないことが、問題文からわかる。

この問題のポイントは
SGは、デフォルトでは、全てのインバウンドは許可されていないということ
なので、つなげたかったら許可しないといけないということ。



まとめと今後について

実際に触って実務経験があることが重要。

試験の準備

詳細

https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/

トレーニング

  • セルフペースラボ
    https://aws.amazon.com/jp/training/self-paced-labs/

コース
https://aws.amazon.com/jp/training/course-descriptions/

参考資料

  • ホワイトペーパー
    https://aws.amazon.com/jp/whitepapers/
  • アーキテクチャセンター
    https://aws.amazon.com/jp/architecture/
  • ドキュメント
    https://aws.amazon.com/jp/documentation/

試験ガイド
https://d1.awsstatic.com/training-and-certification/docs-sa-assoc/AWS%20Certified%20Solutions%20Architect%20-%20Associate_Exam%20Guide_v1.5_FINALJP.pdf

サンプル試験
https://d1.awsstatic.com/training-and-certification/docs-sa-assoc/AWS%20Certified%20Solutions%20Architect%20-%20Associate_Exam%20Sample_v1.5_FINALJP.pdf

模擬試験
https://aws.amazon.com/jp/training/

個々のサービスを詳しく学びたい場合

  • AWSクラウドサービス活用資料集
    https://aws.amazon.com/jp/aws-jp-introduction/

試験の登録
https://aws.amazon.com/jp/training/

認定FAQ
https://aws.amazon.com/jp/certification/faqs/

「AKIBA.AWS #6 ネットワーク x 基礎編 – VPNとDirectConnect -」に行ってきました

AKIBA.AWS #6 ネットワーク x 基礎編 – VPNDirectConnect –

https://classmethod.connpass.com/event/84401/

に行ってきたので、そのときのレポート

1. 日本でAWS Direct Connectを利用する話

資料

 

以下、講演を聞きながらのメモ

想定する聴講者

ネットワークはあまり詳しくないけど、AWSを使ってみたいIT技術者

ネットワークセキュリティとその設計

Direct Connectはオンプレとクラウドを繋げるサービス

 

インターネットは怖いのでセキュリティをしなければいけない。

コンピュータセキュリティは大きく分けて2種類ある

エンドポイントセキュリティ

 → ウィルス対策ソフトを入れたり

ゾーンセキュリティ

 → 企業などが、自分の管理下のネットワークを置いて、そこで管理すること。
プライベートなネットワークのこと。

 → 組織内の人のみアクセスできるプライベートネットワーク。専用の箱を作って管理。

 → 誰でもアクセスできるパブリックネットワークとの境界を
しっかり分けて管理しましょうということ。

 → 会社の場合だと、ルータがその境界になっていたりする。

家庭のネットワークと企業のネットワークの違い

会社のネットワークは、システムの用途などでプライベートネットワークが別れている。

オフィスのLANとデータセンターで別ネットワーク。

それぞれのプライベートネットワークをどう繋ごうかと考えたりする。

拠点間プライベートネットワーク

方法としては大きく2種類ある

インターネットVPN

安価でベストエフォート

パブリックなインターネットを経由して行うが、組織内の通信を暗号化することにより実現。

インターネットを経由して行なっているので、使い勝手も特に差異はない。

IP-VPN

高価・高セキュリティで帯域保証つき

インターネットベンダーの設備を経由して、閉じた通信網のなかで行う通信。

 → 昔は、ビルとビルの間に線をつないで、、、とかやってる時代もあった。

 → いまは、ネットワークベンダーの設備を使ってやったりしている。

 

Ethernetであれば、ネットワーク通信自体の要件に違いはない。

セキュリティレベルや品質で選択する。

クラウドのネットワーク設計

いわゆる、VPCの話。AWSVPCはどういうつくりなのか?

VPCとは

AWSで使えるネットワーク機能

ざっくりいうと、AWSで使えるネットワーク機能が詰まったもの。

 

VPCの便利なところというのが、

パブリッククライドとしては、東京リージョンということで共通で使うのだが、

ユーザごとにネットワークを切って使うことができる。

 

それぞれのVPCは独立していて、閉じた仮装プライベートネットワーク。

やろうと思えば、VPC同士の接続(ピア接続)もできる。

 

本番と開発のネットワークを分けたいというような形で使われることが多い。

本番のネットワークのセキュリティレベルはあげたいが、

開発用はポコポコサーバーを建てたい、など。

 

VPCとプライベートネットワーク(社内の環境)との相互接続を実現するために

AWSが提供しているDirect Connectというのがある。

 

VPCとプライベートネットワークを繋げる手段は3

  • VPCのインターネットVPN機能
  • EC2でインターネットVPNソフトウェアを実行
  • AWS Direct Connect (今回のメイン

Direct Connectの特徴

  • 高品質
  • 高セキュリティ

サービスとしてのSLAは未定義なため、

現状は、月のアクセスがどのくらいまで保証、というのが明示されていない。

AWSによるサービスのメンテ頻度など実績で比較する。

Direct Connectはメンテ頻度が少ないので、安定しているなど。

対して、インターネットVPNというのが、構築も簡単で手軽である。

AWS Direct Connect

日本で使えるところ。

  1. エクイニックス ty2(東京 東品川)
  2. アット東京 cc1(東京 新豊洲)
  3. エクイニックス os1(大阪 四つ橋)

AWSのリージョン(東京・大阪)とは別

コラム

Direct Connectがある場所に、日本のAZがあるの?という質問がよくある。

真実はわからないが、違うというアナウンスがされている。

Direct Connectの使い方

Direct Connectが提供してくれるのは全てではなく、

VPCから、先ほどの3箇所(エクイニックスty2、アット東京cc1、エクイニックスos1

までの通信が用意される。

 

その3箇所のところにLANの差込口があるので、そこまでは繋ぐよ。

そこから自社のネットワークまでは、自分で用意してね。っていうようになっている。

自社のネットワークまでの繋ぎ方は2種類ある

占有プラン

3つのいずれかのデータセンターと通信を自前で行なって

IP-VPN接続などをする。

自社内のプライベートネットワークの中に

3つのうちのデータセンターへの口を用意する。

メリット

ユーザが自分でいろいろ設定するので、制約は少ないというメリットがある。

 → たとえば、複数のネットワークベンダーからデータセンターに繋ぐということもできるし、

   いくつものVPCを繋げるということもできる。

デメリット

価格が高いこと

共用プラン

ネットワーク事業者が、3つのうちのデータセンターとクラウドとの接続をやっているので、

自社内からそのクラウドに対して、IP-VPN接続を行う。

メリット

占有プランと比べて、データセンターとのやりとりコストや予算などが抑えられること。

デメリット

制約が多いことと、接続できるVPC数が1つだけであること。

まとめると

  • 共用プラン:比較的手軽
  • 占有プラン:本格利用

とっかかりはどうするか?

Direct Connnectを使いたいとなったら、既存のネットワーク事業者の営業さんに相談をする。

 → 中には、Direct Connectの経験があるネットワークベンダーもある。

 → AというネットワークはIP-VPN接続でやって、
   Bというネットワークはネットワークベンダーにお願いして、というようなやりかたもある。

技術的な不明点があれば、質問したり、AWS専用線アクセス体験ラボの活用がおすすめ

おまけ

  • Direct Connect応用機能
    → 占有プランでないと使えなかったりする。
  • パブリック接続
  • Direct Connect Gateway
  • Lag

まとめ

  • Direct connectはプライベトネットワークとVPCを高品質セキュアにつなぐサービス
  • 占有プランと共有プランがある
  • 質問があればネットワークベンダーに質問してみよう。

Q & A

Q1.

メンテナンスの頻度はよくある?

A1.

Direct Connectの推奨としては、冗長構成となっているので

片方がメンテナンスになってしまっても、

もう片方が残っていればいいというような状況にしておくのがよい。



2. AWS 専用線アクセス体験ラボトレーニング参加レポート

登壇者の方(濱田さん)から。

今回の講演で、面白かったポイントを伝えたりしようと思う。

また、これを聞いた人が参加したいなと思ってもらえたらよいかなと思う。

資料

 

以下、講演を聞きながらのメモ

イントロ

濱田さんが日頃の業務をしているときに

AWSとオンプレとの接続はマスト要件」という案件がある。

そういう場合は、

Configファイルを渡して、つながったら、よしやった!と思う。

ただ、当時のイメージとしては、

お客さん側の得体のしれない機材や得体の知らないネットワークが

どのように稼働しているのかイメージがつかなかったため、

体験ラボハンズオンに参加した。

 

結論からいうと、バックエンドやVPNとかよくわからないという方にとっては

とても学びがあって楽しい。

体験ラボとは?

学べる。

ルータを使った接続の体験とかができる。

会社でネットワークの運用とかをやっている人におすすめ。

 

トレーニングは2種類あって、

ハンズオントレーニングの方をやってきた。

(もう片方は座学なのかもしれない、、、たぶん。)

 

料金が無料!!!!!!!!

 

ハンズオン会場は、AWSのビルの素敵なところで行なう。

注意:ボルダリングするところがあるが、そこの写真とると怒られる。

 

行くときは、PCAWSアカウントを用意しておく。

 

講師は、AWSの菊池さんという人。ガチガチのスペシャリストの人。

とても丁寧に教えてもらえる。

 

ハンズオン形式でテキストを進めて行く形。

 

講演の中で説明されるが、

あるWEBサイトにAWSアカウトを登録すると

自分のAWSアカウントのDirect Connect のところに

Virtual Interfaceが自動で作られる。すごい。

 

ハンズオンの中では、VGWの作成などが

こうやればできますよってテキストに書いてあって、それをやる。

 

ある程度最初に、どんなことをやるのかイメージして

ハンズオンで進めていくことで理解が深まるのでよい。

よかったこと

  • Direct Connectの設定の流れを一気通貫で学ぶことができる。
  • ルーターコマンドを体験できる。
  • 講師にマニアックな質問ができる。
    → 参加人数がそれほど多くないので、
    ネットワークスペシャリストにVPNや専用線の質問ができる!
  • テストラボトレーニングの資料がもらえる。

まとめ

これまで霧のようなイメージだったお客さん側の環境が理解できるようになった!

また、無料だし3時間くらいだし、失うものは何もないので参加すると良い!

AWS 専用線体験」で検索!

Q & A

Q1.

無料ということだったが

ハンズオン内で行うAWS料金も無料?

A1.

そこはさすがに自分持ちです。

ただ、ハンズオン内でかかる費用は50円くらい。

しかも、ハンズオンの資料がもらえるので、それを見ながら1週間くらい遊んだりはできる。

1週間くらいはハンズオン用のデモの環境を残しておいてくれるので)



3. VPN接続とルーティングの基礎

まず始めに、登壇者の菊池さんから

今回はだいぶテクニカルな内容になります。と説明があった。

菊池さんは、AWS認定を8冠しているすごい方。

資料

 

以下、講演を聞きながらのメモ

1. AWSVPN接続

いわゆる、インターネットVPN

 → インターネット上の通信でパケットをカプセル化することで仮想敵なトンネルを形成

 

実現方法によって2つの分類がある。

  • ハードウェアVPN
  • ソフトウェアVPN

ハードウェアVPN

接続に必要な部分が、AWSのサービスとして提供されている。

ソフトウェアVPN

EC2の中にソフトウェアをインストールして、そこを通してVPN接続すること。

 

この2つを比べて一番違う部分が、

ソフトウェアVPNの場合は、

VPN接続の部分を、ユーザが自分たちで保守・運用しないといけない
例えばEC2インスタンス建てたりソフトウェアをインストールしたりとかということ

今回のテーマはハードウェアVPN

ハードウェアVPN = マネージドVPN

拠点間を繋ぐIPSecVPN

2. ハードウェアVPN

出てくるコンポーネントは3

  • customer gateway
    → オンプレ側に設置するルータ
    public ipを必要とする。
  • virtual private gateway
    VPCにアタッチするゲートウェイ
  • VPNトンネル
    → CGWとVPGを繋ぐ

 

AWS上での設定はとても楽。3ステップ。

 

設定ファイルが最後にDLできる

 

設定ファイルには、

  • IPSecVPNの設定情報
    → IKE/Ipsec/TUNNEL
  • BGPルーティングの設定(動的ルーティングの場合)

が書かれており、

IKEの事前共有鍵、AWS側の接続先IPなどが書かれている。

 

AWS側では、2箇所でルートが設定されている。

  • VGW
  • VPCのルートテーブル

3. BGPによる経路交換

AWSを使うと、IPSecまでの設計はほとんどいらない。DLするConfigに書かれている。

ネットワークの経験がない人がBGPをやろうとすると、一気にハードルが高くなる。

 

BGPとは?

Border Gateway Protocol

のこと。

動的ルーティングプロトコルの1

 

AS(Autonomous System:自律システム)間で経路情報を交換する。

ASナンバーというのは、大きなネットワークキャリアとかが、他と通信するための番号。

 

TCPで接続したルータ間で経路をアドバタイズ(広報)する

 → パスアトリビュート属性を付加することで経路を制御

  → ISPとかが複数の経路を提示してくれるが、
この属性によって最短の経路が何かを示してくれる。

 

VGWVPNトンネルの間にルータが2つある。

  • CGWで設定したCIDRCGWから受け取るルータ
  • VPNCIDRCGWに送信するルータ

 

BGPでは、パスアトリビュートのパラメータが10以上ある。

AWSでよく使われているのは

  • Local_Prefence
  • AS_PATH
  • Med

ここら辺の話はとてもディープな話になるので、

また次回の勉強会でやろうかな菊池さんがおっしゃってました。

4. 設定時の注意

CGWには実績のある機器を設定しよう

 → 不具合の回避

 → 実績のない機器を検討する場合は事前検証を。

 

AWSが公式に検証をサポートしている機器もある。

そういうものを使えば、まぁ、間違いないでしょう。

その機器の中に、 Cisco とか Juniper とかある。

コラム

ネットワーク屋さんからすると、CGWVGWは同じ機種を使うのがセオリーなので

AWSで使われている、謎の機器を使うときは、サポートされているものを使いましょう。

サンプルコンフィグの注意点

CGWNAT環境にある場合。

クライアントのFireWallの奥にCGWがある場合。

その時は、インターネットからFireWallを超えてCGWにアクセスできるように設定しよう。

サンプルコンフィグを使うと、NATGWIPが記載されているので、そこの書き換えが必要。

繋がらないときのトラブルシューティング

  • Ipsecがダウンしていないか
  • BGPがダウンしていないか
  • ルートテーブルが反映されているか

まとめ

  • ハードウェアVPNはマネージドなIpsecVPN
  • BGPまたはstaticルーティング経路を設定
  • AWSが、設定は簡単

Q & A

Q1

今回話したような内容は、ネットワークベンダーさんがやってくれる?

A1

基本的にやってくれる。

Q2.

経路交換しているときに、

VPC側の経路情報が流れてしまうという話があったがルーティングの設定をすればよいのか?

A2.

そうですね。オンプレの設定だけルーティングするような設定をしないといけない。

Q3.

Direct ConnnectSLAの設定がないという話で、冗長構成が推奨ということだったが、

どういう内容があるか?

A3.

データセンサーから線を2本引くなど。どこまでお金かけるかとか、考え方とかによることになる。

Q4.

AWS側でVPN接続する際にルータが2

CGWCIDRを受け取るものと、VPCCIDRを送るもの)出てくるが、

それが別れているのはなぜか?

A4.

AWS側が冗長化のためにやっている。

メンテナンスの際は、片方がとまるが、片方は生き残ったままというような形になる。