はじめに

昨日やれなかったことをやります。
https://qiita.com/fjisdahgaiuerua/items/9ac461a8f76c8ce94fb0

学習

AWS Config

構成管理・変更管理ツールのこと。以下を参考にしています。
https://dev.classmethod.jp/articles/cm-advent-calendar-2015-aws-re-entering-aws-config/

サポートしているのは以下のAWSリソース

EBS
EC2
VPC
Trail

できること

AWSリソースの構成情報の検索、閲覧
- AWSリソースにどのような設定がされているのかを可視化
AWSリソースの変更履歴の検索、閲覧
- いつ、どの値が、どのように変更されたか
AWSリソースが作成、変更、削除された際の通知
- 変更がなされたタイミングでSNS経由で通知を行うことが出来ます。 SNSなので、メール送信することも可能ですし、SQSに投げて処理を行うことも可能
AWSリソース間の関係性の確認
- 各AWSリソースがどのような関係性にあるのかを確認
  - セキュリティグループを割り当てているインスタンス
  - インスタンスに紐付けられているEBSボリューム
  - VPC内に構築されているインスタンス

AWS Configの構成要素

Configuration Items
- とある時点の各設定値のこと。
  メタデータ、属性値、関係性などAWS Configの最小構成要素。
Configuration Snapshot
- Configuration Itemsの集合。
  定期的、もしくは変更のタイミングで取得されてS3に保管される。
Configuration Stream
- Configuration Itemsのリスト。
  リソースが作成、変更、削除される際にConfiguration Itemsが作成され、それをConfiguration Streamに追加する。
  追加されたConfiguration ItemsはSNSでの通知に使用
Configuration History
- 任意の期間のConfiguration Itemsの集合で、設定の履歴。
  Configuration HistoryはS3に保管される。

Config Rules

AWS Configで取得した設定値を監査して、あるルールに則っているかを自動で確認してくれるサービス

マネージドルールとカスタムルール

マネージド
- たくさんあります
カスタム
- Lambdaで実装する

ルールによる検査の時期

AWSリソースが作成・変更された際に検査を実行する変更時検査
- スコープを設定することができ、特定のAWSリソースタイプ、特定のAWSリソースID、特定のタグがついたAWSリソースだけを検査の対象とすることが出来ます。
- 基本チョイス
設定のスナップショットがS3に保管されるタイミングで検査する定期変更
- 定期検査では、スコープを設定することは出来ず、スナップショット全体の検査となります。
  こちらはアカウント全体でどうか、という検査をするときに使用

サービス利用のユースケース

AWSリソース構成管理
- 自分の所有するAWSアカウント上にどんなAWSリソースが存在していて、どんな設定がなされているのかを確認し、無駄なリソースや、設定値の間違いを発見することが出来ます。
  構成が変更された時に通知を送ることもできるので、すぐに検知することが出来ます。
監査、コンプライアンス
- 構成の変更が全て記録されるので、いつ、どのように変更がなされたかがひと目で分かります。社内ポリシーとして証跡を取得しないといけない場合にはもってこいのサービス
- CloudTrailでも出来るじゃんと思われるかと思いますが、あちらは呼び出されたAPIを全て記録していますので、量がハンパない
- AWS Configでひとまず確認し、詳細はCloudTrailという併用がベスト
変更管理、トラブルシューティング
- SG設定いじった時などに元の設定がわかるので助かる

AWS VPCVPN

ここを参照しながら
https://aws.amazon.com/jp/vpn/

Site to Site VPN

AWS Virtual Private Network (AWS VPN) では、ネットワークあるいはデバイスから AWS グローバルネットワークへの安全でプライベートな暗号化トンネルを確立できます。AWS VPN は、AWS サイト間 VPN と AWS Client VPN で構成

AWS サイト間 VPN
- オンプレミスネットワークあるいは支店サイトから Amazon Virtual Private Cloud (Amazon VPC) への安全な接続が可能
- AWS サイト間 VPN は、複数のアベイラビリティーゾーンに 2 つのトンネルを提供し、クラウドリソースへの中断のないアクセスを実現します。最初のトンネルは主要トラフィックの通信に、2 つ目のトンネルは予備として使用できます。そのため、1 つのトンネルが使用不能になっても、トラフィックは Amazon VPC に伝達
- 接続ではインターネットプロトコルセキュリティ (IPsec) 通信を使用して 2 点間に暗号化された VPN トンネルを作成
- AWS サイト間 VPN では、Amazon CloudWatch 指標を組み込むことで、ローカルネットワークとリモートのネットワークの健全性を把握し、VPN 接続の信頼性とパフォーマンスを監視できます。サイト間 VPN は AWS Transit Gateway ネットワークマネージャーとも統合し、SD-WAN、AWS Transit Gateway、AWS Direct Connect サービスなどのオンプレミスネットワークと AWS ネットワークの状態を国際的に把握できます。
- Accelerated サイト間 VPN は、AWS Global Accelerator と結合することでお使いの VPN 接続のパフォーマンスを向上させます。Accelerated サイト間 VPN はサイト間 VPN のオプションとして、混雑とは無縁の AWS グローバルネットワークを広範囲に活用し、最寄りの AWS エッジロケーションを通じて暗号化トラフィックを転送します。

用語検索

VPN
- 離れた場所の間を仮想的な専用線でつないで安全なデータ通信を実現する仕組みで、仮想プライベート・ネットワークとも言います。
インターネットVPNとIP-VPNの違い
- インターネットVPNとは、インターネット回線を利用して離れた拠点同士のLANをつなぐ仮想技術
- IP-VPNは、通信事業者が提供する閉域網を利用して離れた拠点のLANをつなぎます
閉域網と専用線の違い
- 閉域網
  - インターネットのように誰もが利用できるオープンなネットワークに対し、通信事業者が自社のサービスとして構築した“閉じた”ネットワークを閉域網と呼びます。閉域網の“閉じた”とは、「インターネットから直接アクセスを受けない」ことを意味します。つまり、閉域網とはインターネットから分離されたネットワーク
  - 閉域網のセキュリティは通信事業者が確保
  - 閉域網内のバックボーンネットワークは他のユーザーと共有

Site to Site VPNの基本構成

VPCに対してSite to Site VPNを接続するには二通ある

Virtual Private Gateway（VGW）をVPCにアタッチして接続
Transit Gateway（TGW）を経由する

1つのCustomer Gateway（オンプレミス拠点側のルータ）に対して、1つのVPN接続を作成することで、2つのIPSec VPNトンネルが作成

AWS Client VPN

こういうアーキテクチャ図を作れるようになりたいですね
http://blog.serverworks.co.jp/tech/2019/06/10/awsclientvpn/

AWS Client VPN
- AWS Client VPN は AWS やオンプレミスネットワークへの安全な接続を可能
- VPC上に Client VPN Endpoint を作成することで、クライアント（普通のPCなど）とVPCの間でVPNを張ることができる
- OpenVPN （オープンソースのVPNソフトウェア）を利用
- 認証には “Active Directoryによるアカウント管理“, “サーバ証明書・クライアント証明書による相互認証“, “その両方” を利用できる
- Active Directory認証では AWS Directory Serviceを利用。オンプレのADと連携したい場合は AD Connectorを噛ませることで可能
  - なおClient VPN経由でVPC内のリソースにアクセスするとき、接続元IPはClient VPN EndpointのENIのものになります。つまりクライアントからの通信は Client VPN Endpoint でいったんNATされているということ。SG設計にてポイントになります。

AWS VPN CloudHub

複数の AWS Site-to-Site VPN 接続がある場合は、AWS VPN CloudHub を使用して、安全なサイト間通信を提供することができます。これで、リモートサイトを有効にして、VPC のみとではなく、相互に通信します。VPN CloudHub は、VPC の有無にかかわらず使用できるシンプルなハブアンドスポークモデルで動作

transitと何が違うのか...

	Transit Gateway	CloudHub	Transit VPC※1	Direct Connect Gateway
VPC 間の通信	yes	no	yes (VPN 接続を使用)	No
オンプレミス間の通信	yes	yes	yes	yes
VPC とオンプレミスの通信	yes	yes	yes
複数の VPC の割り当て	yes	no	yes

※1 複数AWSアカウントからVPCを経由してオンプレやその他のクラウドに接続する方法

Transit Gateway とは何か

これまで、複数の VPC の間で接続性を確保したい場合は VPC ピア接続を行うのが一般的でした。一方、VPC ピア接続は直接接続された VPC の間の接続性を提供するものであり、ある VPC を経由して他の VPC に到達するようなことができません。このため、VPC が 3 つ以上ある場合はメッシュ状に VPC ピア接続を行うことで接続性を確保していました。また、同様にある VPC をハブに見立てて VPN 接続を行ったオンプレミスからピア接続先の別の VPC に到達することもできないため、オンプレミスからそれぞれの VPC に VPN 接続を行ったり Transit VPC を用意したりしていました。

Transit Gateway はハブ＋スポーク型のトポロジーを実現

複数の VPC にオンプレミスから接続したい場合、それぞれの VPC に VPN 接続を行う必要はありません。Transit Gateway への VPN 接続を行うだけで、関連付けられたすべての VPC のリソースにアクセス

Direct Connect Gatewayとは

Direct Connectの構成のうち、仮想インターフェース(以下VIF)とVPCの仮想プライベートゲートウェイ(以下VGW)の間に追加する新たなコンポーネント

メリット

これまでVIFと接続するVPCは最大で1つだったため、複数のVPCでDirect Connectを利用するためには複数のVIFを用意する必要がありました。Direct Connect Gatewayに複数のVGWを接続することで、1つのVIFで複数のVPCと通信することが可能です。

注意

Direct Connect Gatewayを介したVPC(VGW)同士の通信は不可
Direct Connect Gatewayを介したVIF同士の通信は不可
異なるAWSアカウントのVIFおよびVGWの接続は不可

移行の際は

では、既に構築済みのDirect Connect接続でDirect Connect Gatewayを利用するためには、どうすれば良いでしょうか。作成済みVIFにあとからDirect Connect Gatewayを追加することはできないため、VIFを再作成する必要があります。また、従来東京リージョンでは10124で固定だったAmazon側のASN *3が、Direct Connect GatewayではPrivate ASNの範囲で自由に指定する形になったため、指定したASNに合わせてカスタマールーターのBGPのコンフィグを調整する必要があります。BGPのピアIPとパスフレーズはVIF再作成時に任意に指定できるため、移行前と同じ設定にしても問題ない

AWS SSM

EC2インスタンスまたはオンプレミスのサーバに導入されたSSM Agentを介して、AWS Systems Managerに情報を集約管理
結果を確認・監視しつつ、自動または手動で対象リソースを管理・操作

注意事項

インターネットへのアウトバウンドアクセス
- インバウンドは不用
- パブリックサブネットやＮＡＴを使用
VPCエンドポイントへのアクセス
- インタフェースエンドポイントを使用
SSM AagentがAMI内にプレインストールされているOSとそうでないものがある

AWS Systems Managerを構成する機能と要素

共有リソース
- SSM Documents
  - SSM Documentsは、管理対象のインスタンスに対して実行するアクションを定義したもので、AWS Systems Managerを構成する様々なサービスのバックエンドでも活用されている、AWS Systems Managerの核となる共有リソースです。先にご紹介した記事にあったWindowsのAD参加から始まり、現在では多数のドキュメントが利用できるようになっており、正直すべてのドキュメントについて把握するのは難しいです。何度も利用するようなものを定型化して再実行可能としてくれるので、同じようなアクションを繰り返し実行することが可能
- Parameter Store
  - 設定データ管理と機密管理のための安全な階層型ストレージが提供されています。パスワード、データベース文字列、ライセンスコードなどのデータをパラメータ値として保存
グループ化
- OpsCenter
  - OpsCenterは「OpsItems（運用対象）」を集中的に管理して、リソースの状況変化を表示・調査・解決する場所である、そして OpsItemsの関連付けやSSM Automation documents の実行、データ検索、要約レポートを提供するサービス
  - クローズ処理をしなければいけないのが新鮮
- Resource Groups
  - https://dev.classmethod.jp/articles/resurce-group/
  - 恥ずかしながらタグで検索していちいちマネコンからオペレーションしていたので、関係ないリソースまで表示されてました...
- Maintenance Windows
  - Systems Manager の Maintenance Windows から Automaiton を呼び出してEC2インスタンスを定期的に再起動
  - Maintenance Windowsは、OSパッチ適用、ドライバー更新、SWパッチのインストールなど、管理対象インスタンスに対しての変更アクション(Run Command、Automaction、Lambda、Step Functionを起動)をスケジュール定義する機能です。事前に決まられた時間にアクションを行いたい場合に利用
オペレーション
- Run Command
  - Run Commandは、事前に定義したSSM DocumentをSSM Agent導入済みの管理対象インスタンスに対して実行する機能
  - 事前に定義したSSM Documentと書きましたが、実際には、"AWS-RunShellScript"や"AWS-RunPowerShellScript"という任意のコマンドを引数から渡すことができるDocumentがありますので、任意のコマンドを管理者権限で実行することが可能
- Automation
  - Automationは、自動化ワークフローを構築して、インスタンスおよびAWSリソースを管理する機能です。AWSが定義済のワークフローだけでなく、独自のカスタムワークフローを作成することも可能です。定義したワークフローの進捗は、CloudWatch Events経由の通知やAWS Systems Managerコンソールから確認することが可能です。
  - これは今度記事にする
- Distributer
  - Distributerを利用すれば、独自のソフトウェアをパッケージ化したり、AmazonCloudWatchAgentなどのAWS提供のエージェントソフトウェアパッケージを見つけて、管理対象インスタンスにインストール(Run Commandで1回のみ/State Managerでスケジュール)することが可能
  - SSMがRZで縛られているので配布パッケージが他RZにある場合はダメ
- Session Manager
  - EC2インスタンスにSSH・RDPで接続せずにブラウザ上からCLI操作ができる機能
  - 鍵の受け渡しが不要
構成情報の集約・監査
- State Manager
  - SSMドキュメントを参照してEC2が自分でメンテしてくれる
- Inventory
  - Inventoryにより、管理対象上のアプリケーション一覧など構成情報を記録することができます。AWS Configに構成情報を送信して、Config Rulesと組み合わせて管理を行ったり、S3に保存した構成情報をAthena & QuickSightで可視化して分析することも可能
- Patch Manager
  - OSパッチを管理するもの
  - State manegerではOSのパッチまで管理しないのだろう

模擬試験

Route53 トラフィックルーティング

HA問題
マルチRZAWS環境を構築してユーザに対して最も応答時間を最小化できるのはレイテンシですね。位置にしちゃいました。そもそも使い方がこのポリシーを利用すると、日本からのアクセスは日本語のコンテンツが配置されたWebサーバへ接するといった制御を行うためのもの。

シンプルルーティング
- 定義されたレコードの値を返す
加重ルーティング
- ELBに割り当てられたエンドポイントごとに重みづけを設定し、それに応じてエンドポイントの値を返す
レイテンシールーティング
- 複数のAWSリージョンにリソースが配置されていた場合、DNSクライアントとAWSリージョン間のレイテンシを53が確認し、レイテンシが短いリソースを返答する
フェイルオーバルーティング
- 53がリソースの正常性を定期的に監視し、リソースが正常な場合値を返す
位置情報ルーティング
- DNSクライアントのリクエスト発信元の位置情報から、地理的に最も近いリソースを判断し値を返す。

m4.4largeを40台起動するにはどうしたらよい？

カタログとアドバイザーを忘れていたので
AWSサポートに制限解除願いだします。

AWS Service Catalog

IT管理部門向けには、CloudFormationのテンプレートとして管理されるAWSリソース定義や、これらの利用権限をカタログとして一元管理する機能を提供
ユーザ部門ではIT管理部門が作成したカタログより、求める機能に応じたAWS環境を必要に応じて起動する事が可能

メリット

CloudFormationのテンプレートの管理が可能
環境を構築する権限がなくてもプロダクトを起動できる
- 好きなものが作れないけどカタログになっているものだったら許可されている

まとめ

CloudFormationで構築できるサービスであればService Catalogで管理ができるようになります。AWS管理者がCloudFormationを準備すれば、管理者が環境構築をせずにエンドユーザに任す運用も可能になると思います。ユーザ部門がオンデマンドで環境を用意できるので、よりアジリティがある運用が可能
超安全なCfnというイメージ

Trusted Advisor

利用者のAWS環境をAWSが自動で精査し、推奨設定のお知らせをしてくれる機能

コスト最適化
フォールトトレランス
パフォーマンス
サービス制限(有料)
セキュリティ

Storage Gateway

これもふわっと覚えていたので復習
標準的なストレージプロトコルを用いてAWSストレージへのアクセスを可能にするハイブリッドソリューション。
仮想アプライアンスマシンとしてEC2に起動＆経由でISCSI接続したオンプレのEFSがS3にデータ転送ができるようになる

ファイルゲートウェイ
- s3をバックエンドにして非同期でデータ転送。その際にはライフサイクルポリシーやクロスリージョンレプリケーションが利用できる
- SMB,NFSインタフェースを提供
- S3ストレージクラス初期設定
  - Amazon S3 標準
  - S3 標準 – 低頻度アクセス (S3 標準 – IA)、および S3 1 ゾーン
  - ライフサイクル
    - S3 Glacier
ボリュームゲートウェイ
- CashedVolumes
  - 堅牢制の高い大容量ストレージ、アクセス頻度の高いデータはキャッシュとしてローカルに保持。プライマリはS3上に保持
  - ゲートウェイキャッシュ型には、ストレージが2つ以上必要
  - m4.xlarge以上が推奨スペック
  - スナップショット
- Stored Volumes
  - オンプレ環境のディスクデータをストゲ経由でスナップショットとしてS3に保存しAWS環境でのDRを実現。
  - プライマリデータはローカルキャッシュに存在する。
テープゲートウェイ
- 物理テープライブラリの代わりにストゲを仮想テープライブラリとして利用。
- Amazon S3 Glacier や Amazon S3 Glacier Deep Archive にアーカイブ可能

まとめ

ストゲのホワイトペーパー探検をしていたら力尽きましたのでまた明日。