AWS Identity and Access Management

AWS IAM tech black belt aws

# AWS Identity and Access Management

https://d1.awsstatic.com/webinars/jp/pdf/services/20190129_AWS-BlackBelt_IAM_Part1.pdf

https://d1.awsstatic.com/webinars/jp/pdf/services/20190130_AWS-BlackBelt_IAM_Part2.pdf

 

## IAM とは

  • AWS リソースをセキュアに操作するために、認証・認可の仕組みを提供するマネージドサービス

 

## AWS IAM のベストプラクティス

  • ID と認証情報の管理
    • ルートユーザーを極力利用しない
    • 個々のIAMユーザーを作成
    • ユーザーの強力なパスワードポリシーを設定
    • アクセスキーを共有しない
      • コード内にハードコードしてしまったり、ドキュメントに記載するのはNG
    • 特権ユーザーに対してMFAを有効化する
  • アクセス権限の管理
    • AWS管理ポリシーを使用したアクセス許可の使用
    • インラインポリシーではなく、カスタマー管理ポリシーを使用
    • 追加セキュリティに対するポリシー条件を使用
      • Principal 要素（AWSリソースへのアクセスが許可or拒否されるIAMエンティティを指定する）
      • Action 要素
      • Condition 要素
        • リクエストを許容するソースIPアドレスの範囲
        • 日付または時間の範囲
        • MFAデバイスの要求
        • SSL 使用の要求
      • 要素はAND または OR条件
      • アクセス可否のロジック
        • 明示的なDeny > 明示的なAllow > 暗黙的なDeny
    • 最小権限
      • AWS Organization サービスコントロールポリシーとのAND条件で決定
      • AND条件で決定されるかOR条件で決定されるかを確認する
    • グループにIAMユーザーを割り当てる
      • IAM グループにIAMユーザーを集合させて管理する
  • 権限の委任
    • インスタンスプロファイルを利用する
    • IAMロール
      • IAM ユーザやグループには紐づかない
      • ユーザーまたはアプリケーションがロールを一時的に引き受けることで関連づけられたアクセス許可を受けることができる
    • 一時的なセキュリティ認証情報
      • 有効期限つきのアクセスキー・シークレットキー・セキュリティトークン
      • ユーザーのリクエストによってAWS Security Token Service(STS) が動的に作成
        • 発行した認証期限の変更はできない（したい場合は特定時点より前のトークンを全て無効にすることはできる）
        • グローバルサービスとして提供
        • CloudTrail が利用可能
      • STS で利用できるAPI
        • Assume Role
          • 既存のIAMユーザを用いて一時的な認証情報を取得
        • AssumeRoleWithWebIdentity
        • AssumeRoleWithSAML
        • GetSessionToken
        • GetFederationToken
    • ロールを利用したアクセス許可の委任
      • IAMロールによるクロスアカウントアクセス
      • クロスアカウントアクセスによる権限管理を効率化（Switch Role)
      • SAML2.0ベースのIDフェデレーション
        • 組織で生成したSAMLアサーションを認証レスポンスの一部として使用し、一時的セキュリティ認証情報を取得
        • 組織内の全員についてIAMユーザを作成しなくても、ユーザはAWSを利用可能
      • SAML2.0ベースのAWSマネジメントコンソールへのシングルサインオン
        • 既存のユーザ情報をそのまま利用できる
        • アカウント管理が統合され、リスクが低減する
        • 既存の言言ベースでの管理が可能
        • 入隊者など一元的な管理が可能
      • Amazon Cognito を用いたモバイルアプリのWeb IDフェデレーション
        • モバイルアプリから一時的なAWSセキュリティ認証情報を必要に応じて動的にリクエスト
        • OIDCプロバイダ + Cognito で動作
  • IDと権限のライフサイクル管理
    • AWSアカウントのアクティビティの監視
      • CloudTrail による監視
    • アクセスレベルでIAM権限を確認
      • アクセスレベルの分類
        • List
        • Read
        • Write
        • Permissions management
      • Service Last Accessed Data を利用して与えられた権限で利用されていないものを発見
    • 不要な認証情報の削除
      • 不要なIAMユーザー
      • コンソールを利用しないIAMユーザのパスワード
    • 認証情報を定期的にローテーションする
      • 認証情報の利用状況はCredential Report 機能で確認可能
      • IAMユーザのパスワードローテーション
      • アクセスキーのローテーション

 

## 雑感

AWS を利用する上では絶対に機能を知っていないといけないサービスであるIAMの話。

一番気になったのはSAMLを利用したIDフェデレーション。IAMユーザを都度作成するのはすごい手間なのでGoogle の認証情報を利用できるとすごい便利だなと思った。

Switch Role はよく利用している機能でベストプラクティスに則った設計なんだなと改めて感じた。

IAMのベストプラクティスに則ることが大抵の場合良い結果につながると思うので自分の見える範囲で運用を再確認してみようと思う。

AWS Well-Architected Framework

AWS Well-Architected Framework tech aws black belt

# AWS Well-Architected Framework

https://d1.awsstatic.com/webinars/jp/pdf/services/20181211_AWS-BlackBelt-Well-Architected.pdf

## クラウド活用の2つのアプローチ

  • クラウドネイティブなアプリを最初から開発
  • リフト＆シフトで既存アプリをクラウドに対応し、その後最適化する

 

## Well-Architected Frameworkとは

システム設計・運用の大局的な考え方とベストプラクティス集

  • 目的
    • 全ての要素をクリアしないといけないのではなく、ベストプラクティスを理解した上でビジネス的な判断をすることが重要。リスクをあえて受け入れるだったり、改善点を明確にすることが目的。
    • 改善をするにあたって優先順位を作ることができる
  • 構成要素

 

    • AWS ソリューションアーキテクトor W-A認定パートナー
      • 毎週W-A個別技術相談会をしている
      • SAだけではなく認定パートナーもいる（日本にも何社か存在する）
    • AWS Well-Architected Tool
      • AWS Well-Architected Framework のベストプラクティスに則っているかを自身でセルフレビューできるツール
      • 項目に対して回答していくことで、ワークロードの改善点やリスクに気がつくことができる（あえて回答を対象外にすることもできる）
      • レビュー結果として改善プランが表示される。PDF形式でレポート出力も可能
      • 日本語訳（https://d1.awsstatic.com/webinars/jp/pdf/services/images/Well-Architected_2018Nov.487ff97b96b61af87e6eef4acf0622d4a36a6532.xlsx）
      • レビュー実施の方法も書いてある
        • 監査ではなく話し合い
        • 変更不能に陥る前のレビュー
        • 修正はできなくても、問題を認識した上で前に進むことができる
        • 継続的にレビューを行う

 

## コストを意識した設計原則

https://d1.awsstatic.com/webinars/jp/pdf/services/20190312_AWS-BlackBelt_Cost_Optimazed_with_WA.pdf

 

  • 必要な分だけ使用
  • 全体的な効率を測定する
    • コスト削減が本当にビジネス成長につながるのかを考慮する
    • CloudWatch でリソース利用状況を把握する
      • 使用率に応じて適切なキャパシティに変更
    • Trusted Advisor
  • データセンター運用への投資は不要
  • 投資の分析と要因の把握
    • リージョン変更もコストへ影響する要素
  • マネージドサービスの活用
    • 必ず、マネージドサービスが活用できないかは検討する
    • 進化が早いので常に最新情報をキャッチして楽できるようにする

 

## 雑感

AWS Well-Architected Framework はおよそ一年に一回は改定されているようで必要になったときに読んで自分のプロダクトに適用していくのが良いという感じだった。

設計段階から読んでおくことが重要で、ビジネス上あえて問題は認識しているが現時点で解決することはしないという選択をすることができる。V字モデルと同じことが言えると思うが、早い時点で問題が発覚していたり、問題を解決できない状態にしてしまう選択をしないで進められるようにしておくことが重要。

AWS Support のエンタープライズは月額 総利用料の10% or 最低15000$ になっていてもっと利用していかないともったいないなーって思った。

AWS Service Catalog

AWS Service Catalog tech aws black belt AWS CloudFormation

## AWS Service Catalog

https://d1.awsstatic.com/webinars/jp/pdf/services/20180718_AWS_BlackBelt_AWSServiceCatalog_public.pdf

## AWS Service Catalog とは

### 従来のインフラの課題

  • インフラはInfrastructure as Code としてコード化してプロビジョニングするのがベストプラクティス
  • 統制を取りつつ、各チーム/プロジェクトがセルフサービスでプロビジョニングできる仕組み作りが必要
  • 統制のルールと利用者が素早く開発できるバランスが難しい

 

### 用語

  • 製品
    • CloudFormation テンプレートをパッケージ化してユーザ（開発者）へ提供できる社内ポータル
    • バージョン管理が可能
  • ポートフォリオ
    • 製品の集合
    • ポートフォリオ単位でユーザに製品の使用を許可
    • 製品の使用方法の管理も可能
    • 他のAWSアカウントに共有することも可能
  • 制約
    • 製品のデプロイ方法を制御。ポートフォリオごとに各製品の制約を追加
    • テンプレート制約
      • 製品をデプロイする際に指定できるパラメータを制限
    • 起動制限
      • リソースをプロビジョニングするのに必要なロール。最小権限に保つのに役立つ
    • 通知制約
      • Amazon SNS トピックを使用してスタックのイベントに関する通知を受けることが可能になる
  • プロビジョニングされた製品

 

## ビュー

  • 管理者用
    1. ポートフォリオを作成する
    2. 製品を追加する
    3. 制約を追加する
    4. ポートフォリオへのアクセス権限の追加
  • エンドユーザー用
    1. 製品を見て、どの製品を起動するかを決める

 

## 各種機能

  • TagOption ライブラリ
    • ポートフォリオや製品に対してTagOption を指定し、製品起動時に指定したTagOption が引き継がれる仕組み
    • リソースのタグを統一的に付与するのに役立つ
  • アカウント間でのポートフォリオの共有
    • テンプレート制約、起動制約を継承できる
    • 共有されたポートフォリオをコピーして上書きすることも可能
  • エンドユーザに見せるGUIのカスタマイズ
  • 連携機能
    • Marketplace
    • ServiceNow

 

## 料金

 

## アーキテクチャーパターン

  • Hub-Spoke パターン
  • Consumer - Creator - Manager パターン
    • Consumer
      • 製品を閲覧し、利用する
    • Creator
      • リソース/自動化の管理者
      • Service Catalogの管理者権限
      • ログや監視のアラームダッシュボードの作成権限
    • Managers
      • AWS の管理者
  • Agile Governance パターン
    • 製品に対するテンプレート制約を動的に追加するパターン
    • 開発者が製品を追加するが、制約を動的に付与される

 

## 雑感

CloudFormation を社内で管理して、ユーザに利用しやすい形で提供するポータル。

CloudFormation 自体が単機能で完結していて、組み合わせることで実現できる場合や、製品単体で環境が実現できる場合に良さそう。製品が多くなりすぎるとコストがかかってくるため、細かくするときはだいたいの規模感を見積もっておかないとお金がかかりそう。

役割を明確化できて、管理する側と利用する側がはっきりするので統制と、役割に対しての集中ができそう。

AWS OpsWorks

AWS OpsWorks tech black belt aws

# AWS OpsWorks

https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-online-seminar-2017-aws-opsworks

## OpsWorks とは

Chef を使用してアプリケーションを構成および運用するための構成管理サービス

 

  • 種類
    • AWS OpsWorks スタック
    • AWS OpsWorks for Chef Automate
  • 仕組み
    • インストールしたOpsWorks エージェントがOpsWorks エンドポイントに対しアウトバウンド通信を行う（SSMと同じ感じ）
    • OpsWorks によって発行された一連のコマンドを取得
    • エージェントがChef Client のローカルモードでレシピを実行
  • OpsWorks の構成要素
    • スタック
      • OpsWorks のトップエンティティ
      • 属する全インスタンスの構成を管理
      • カスタムレシピを保存する任意のリポジトリを指定可能
      • VPC内部に作成可能
      • スタックごとに構成情報をJSON形式で保持
      • スタックを（リージョン間でも）コピー可能
    • レイヤー
    • インスタンス
      • EC2インスタンスなどのコンピューティングリソース
      • 内部ではOpsWorksエージェントが動作している必要がある
      • OpsWorks エンドポイントに対しアウトバウンド接続ができる必要がある
    • スケーリング(Auto Scaling Group とは違う)
      • 常時稼働
      • 時間ベース
      • 負荷ベース
    • App
      • デプロイするアプリケーション
    • 実行可能なコマンド
      • スタックコマンド
        • スタック全体の構成を変更・管理するためのコマンド
        • AWS マネージメントコンソール、AWS SDK、AWS CLI でリモートから実行可能
      • エージェントコマンド
    • ライフサイクル
      • Setup
      • Configure
      • Deploy
      • Undeploy
      • Shutdown
    • 連携
      • AWS CodePipelineと連携

 

## ベストプラクティス

  • インスタンス間のバージョン整合性の維持
    • 以下の2パターンでデプロイされる
      • インスタンス起動時
      • DeployコマンドまたはUpdate Custom Cookbooks コマンド
    • 問題
      • 意図しないタイミングで最新のコードでデプロイされてしまう
    • 解決方法
      • S3のバージョニングとGitのブランチ戦略によって意図したコードが配信されて適切なバージョンが当たるようにする
  • ローリングでデプロイ
    • 問題
      • 機能としては提供されていないので自身で仕組みを構築しないといけない
  • 開発・ステージング・本番用スタックの使用
  • Blue-Green Deployment の使用
  • Berkshelf を使用してローカルでの複数クックブックの依存関係をパッケージ化
  • Linux セキュリティ更新のインストールの自動化

 

## Chef Automate

  • Chef のcookbookやレシプを使って、インフラ管理を自動化
  • アプリケーションの継続的なインストール、構成、管理、デプロイ、スケールが可能

 

  • 仕組み
    • リソースを中央のChef サーバに接続し、更新がChefサーバーから配信される
  • 機能
    • オペレーション、コンプライアンス、ワークフローのイベントを可視化
    • インフラおよびアプリの継続的なデリバリーパイプラインのワークフローが組める
    • コンプライアンス用に利用できるカスタマイズ可能なレポート

 

## AWS OpsWorks for Chef Automate

  • マネージドChef サーバ
    • 毎日または週一の定期バックアップ
  • スケーリングが簡単
  • AWS OpsWorks for Chef Automate API を利用可能
  • Chef DK
  • ハイブリッド環境を簡単に構築
  • ダッシュボードから確認可能

 

 

  • ノードの追加
    • 手動
    • EC2 Auto Scaling 対応
    • CloudFormation 対応
    • 要IAMの設定
    • Userdateaを利用してノードを追加するイメージ

 

 

## OpsWorksスタックとOpsWorks for Chef Automate の違い

  • Chef サーバ
    • OpsWorks スタックでは不要
    • OpsWorks for Chef Automate では必要（管理はAWS)
  • 互換性
    • OpsWorks スタックでは一部互換性のないものがある
  • 東京リージョンサポート
    • OpsWorks のみ

 

## 雑感

マネージドChef サーバー。近年だとChef はAnsible などに流されているので振るわないイメージがどうしても付いてきてしまう。OpsWorks のリリースが2013年の2月

(アマゾン ウェブ サービス AWS OpsWorksを発表)

 で、Docker のコンテナ技術が出はじめたのが2014年なので少しタイミングが悪かったといえばそうなる感じがする。

使い所は少し違うが、最近だと簡単にアプリをデプロイできるサービス(lightsail 、Beanstalkなど）があるし、サーバレス、ECRも整っている。さらにはサーバの管理というレイヤーだとSSMもあるので役目を終えたようなサービスに見えてしまう。。。

AWS CloudTrail & AWS Config

AWS CloudTrail AWS Config black belt aws tech Audit

# AWS CloudTrail & AWS Config

https://d1.awsstatic.com/webinars/jp/pdf/services/20160831-AWS_BlackBelt-CloudTrail-Config-public.pdf

https://d1.awsstatic.com/webinars/jp/pdf/services/20190618_AWS-Blackbelt_Config.pdf

## CloudTrail とは

  • AWS ユーザーの操作をロギングするサービス(全リージョンで有効にしておくのがベストプラクティス)
    • 対象
      • ルートアカウント
      • IAMユーザー
    • ロギング対象のイベント
      • API call Event
      • Non-API call Event
  • ロギングデータはS3に暗号化されて保存
    • KMSを利用した暗号化にも対応
    • Digest File を利用したログファイル整合性の確認
      • CloudTrail ログファイル、ダイジェストファイルの編集・削除の検知
    • Bucket Policy により、複数アカウントのCloudTrail Log を１つのバケットに集約することも可能
  • CloudTrail 自体の利用料金は無料
  • 活用方法
    • アラート
      • CloudTrail のログをJSON 形式でCloudWatch Logs に転送
      • CloudWatch Logs Metric Filter の利用し特定のAPIコールを検知
      • Amazon SNS を利用して通知
      • これらの設定はCloudFormation を利用して構築可能
    • 文字列検索
      • S3に保存されたデータを利用して、制限はあるが、CloudTrail Lookup Event を活用して、文字列を検索
    • 可視化
      • CloudWatch Logs からElasticsearch Service に連携。そのデータをKibanaを利用して可視化

 

## AWS Config とは

  • AWS リソースを切り口に時系列ベースでロギング
  • AWS リソースのレポジトリ情報からリソースの変更履歴、構成変更を管理するサービス
    • 構成情報は定期的にスナップショットとしてS3に保存(最大7年)
    • 必要に応じSNSを使った通知も可能
  • 構成情報を元に、現在のシステムがあるべき状態になっているかを評価
    • 独自の評価ルール or AWS が適用するルールを利用

 

  • 機能
    • Configuration Stream
      • リソースが作成、変更、または構成項目が削除されるたびに作成され、構成ストリームに追加される
      • SNSトピックに連携可能
    • Configuration History
      • 任意の期間における各リソースタイプの構成要素の集合
      • リソースの設定履歴を指定したS3バケットに保存
    • Configuration Snapshot
      • あるポイントでのコンフィグレーションアイテムの集合
      • 自動で定期的あるいは変更トリガで作成され、S3にエクスポートされる

 

 

  • ディスカバリの仕組み
    • First Discovery
      • サポートされるリソースに対して、ディスカバリが実行され、Configuration Item が作成される
    • Periodically Discovery
      • CIに対して、定期的に構成変更がないかをディスカバリ
    • Configuration History
      • 6時間ごとにディスカバリ結果を出力
    • Configuration Snapshot
      • 定期的にSnapshot を出力

 

  • AWS Config リレーションシップでリソースの連携関係を把握できる

 

  • AWS Config Rules
    • 準拠すべきルールを事前に設定し、その内容に沿った構成変更が行われているかを評価
    • ルールの種類
      • AWS Managed Rules
        • AWS が提供するルール
      • Customer Managed Rules
        • Lambda ベースにルールを作成可能
        • 評価実行のタイミングを指定
        • Awslabs がGitHub でカスタムルールを公開もしている。コミュニティベースでカスタマイズされたルールも公開されている
        • AWS Config Rule Development Kit(RDK) というカスタムルール作成を支援する開発キットがある
    • マネージドルールのカテゴリ
      • コンピューティング
      • データベース
      • マネジメントとガバナンス
      • ネットワークとコンテンツ配信
      • セキュリティ、コンプライアンス
      • ストレージ
    • 評価実行のタイミング
      • Event-Based Evaluations
        • 関連リソースが作成、変更された際にルールの評価が実行される
      • Periodic Evaluations
        • 任意のタイミング
        • AWS Config がコンフィグレーションスナップショットを取得する際にルールの評価が実地される
    • 修復アクション
      • コンプライアンス違反のリソースに対して、ルールに関連付けられた修正アクションを実行

 

## ベストプラクティス

aws.amazon.com

- AMI の種類のチェック

  - 実行中のインスタンスの

- required-tags

  - リソースに指定したタグがあるかどうかを確認

- EBSが暗号化されているかを確認

- Systems Manager の管理下におかれているかを確認

- VPC Flow Logs が有効になっているかを確認

- S3 のバケットの権限の確認

- 有効なアクセスキーが、指定日内にローテーションされているかどうかを確認

 

 

記録対象について

  1. すべてのアカウントとリージョンで有効化する
  2. すべてのリソースタイプについて、設定変更を記録する
  3. グローバルリソースは１リージョンで記録を有効にする（重複して登録されるのを防ぐ）
  4. 権限管理が行われ、特定の人にしかアクセスできないS3バケットにヒストリーとスナップショットを保存する
  5. Data aggregation 機能を利用して、管理アカウントから集中管理する
  6. Organizations ベースのaggregator を利用する（マルチアカウント環境だと統制がとりにくい）

 

全体的なAWS Config 利用の流れとしては

アカウントとリージョンを指定してAWS Config データを取得する。それをアグリゲータを利用して、リージョンとアカウントを一つにまとめる。それを集約ビューでまとめる。

 

## 雑感

CloudTrail はユーザの操作に対してのロギングが行えるサービス。AWS Config はリソースの変更に対してロギングが行えるサービス。

削除されてしまったEC2インスタンスの追跡を行いたい場合はリソースベースのAWS Config が良さそう。それを誰が行なったのかを追跡するのはCloudTrail といった具合なのかなと思った。

AWS Config に関しては、アカウント管理者がユーザに対してルールに準拠しているかを検知したいと行った場合に使えるので中央集権的に管理するのにちょうど良いサービスという印象。CloudTrail は有効にしておくのがベストプラクティスで短期～長期にわたってユーザの操作ログを分析したりするのに向いている。

CloudTrail は有効にしているが、AWS Config は有効に使えていないので業務で使えたらなと思った。

Amazon EC2 Auto Scaling & AWS Auto Scaling

AWS Auto Scaling Amazon EC2 tech black belt aws

# Amazon EC2 Auto Scaling & AWS Auto Scaling

https://d1.awsstatic.com/webinars/jp/pdf/services/20191002_AWS-Blakbelt_Auto_Scaling.pdf

## コンセプト

Auto Scaling サービス群により、実際の需要に合わせたオートスケールが可能

 

## 基礎知識

  • 希望する容量(Desired Capacity)を目標に
    • 手動でDesired Capacity を設定
    • 何かをトリガーに自動でDesired Capacity を調節
  • インスタンスの分散
  • Pet としてではなく、Cattle として扱う

 

  • Auto Scaling の世界
    • AWS Auto Scaling（EC2の予測スケーリングの管理）
      • 様々なリソースのスケーリングプラン（動的スケーリング＋予測スケーリング）
    • EC2 Auto Scaling（EC2の管理）
    • Application Auto Scasling
      • ECSクラスター
      • スポットフリート
      • EMRクラスター
      • AppStream 2.0 フリート
      • DynamoDB テーブル
      • Aurora レプリカ
      • SageMakerエンドポイントバリアント
      • カスタムリソース

 

## スケーリングの主要機能

  • 動的なスケーリング
    • 簡易スケーリング
      • EC2 Auto Scaling のみ
      • 1つのメトリクスに対して1種類だけのスケーリング調整値を指定
      • 現在は非推奨
    • ステップスケーリング
      • EC2 Auto Scaling, Application Auto Scaling
      • 1つのメトリクスに対して複数のスケーリング調整値を指定可能
      • ウォームアップ期間
        • 新しいインスタンスがサービス開始できるようになるまで何秒かかるかを設定する値
    • ターゲット追跡スケーリング
      • EC2 Auto Scaling, Application Auto Scaling
      • １つのメトリクスに対し、単に目標値を指定する
        • CPU使用率を40%に維持してほしい
      • 目標値を満たす様に自動的にリソースが調整される
      • スケールインとスケールアウトのCloudWatch Alarm が作成される
      • 素早くスケールアウト、ゆっくりスケールインと行ったことも可能
  • 予測スケーリング
    • EC2 Auto Scaling のみ
    • 2週間分のメトリクスを分析し、今後2日間の需要を予測
    • 24時間ごとに次の48時間の予測値を作成し、キャパシティの増減をスケジュールする
    • お試しにスケーリングを行わない、「予測のみ」を利用してみる
  • スケジュールスケーリング
    • EC2 Auto Scaling, Application Auto Scaling
    • 一度限り、もしくは定期的なスケジュールを指定可能
    • MinCapacity と MaxCapacity のいずれか、または両方を指定可能

 

  • スケーリングオプションの選択指針
    • EC2
      • 大まかなキャパシティ増減は予測スケーリングに任せて前もってスケールしておく
      • 実際の負荷に対して不足した分をターゲット追跡で補充する

 

 

## Auto Scaling の機能

  • ミックスインスタンスグループ
  • 起動テンプレートを利用する（起動設定の後継）
  • 速やかにオートスケールさせたいとき
    • CloudWatch メトリクスを1分間隔にする（有料）
    • ゴールデンイメージを用意しておく
  • スケールアウトした後、サービス開始前にインスタンスに準備させたい。スケールイン前に処理を行わせたいときにはライフサイクルフックを利用
  • 特定のインスタンスをAuto Scaling グループから外す
    • スタンバイ or デタッチ
  • 特定のインスタンスをスケール院から保護したい
  • 一時的にスケールを停止したい。
    • スケーリングプロセスの中断

 

 

## 雑感

Auto Scaling といったらEC2のオートスケーリンググループの話とばかり思っていたが、他のサービスでも自動的にスケールされていたりするというのを、Auto Scaling の種別（AWS Auto Scaling, EC2 Auto Scaling, Application Auto Scaling ) を確認していく中で知った。

EC2のAuto Scaling ばかり利用しているがEC2の予測スケーリングなどもっと使いこなせる部分は多いなと思った。スパイクがあって、通常リクエスト量が少ないとかだったらサーバーレスな構成にした方がいいとは思うが、EC2を利用しないといけない状況でいいかんじにリソース管理をしてくれるAuto Scaling は使いこなせればかなり無駄が少なくなるのかなと思った。

複数項目をトリガーに一気にスケールアウトし、徐々にスケールインといったことや、事前の予測からスパイクの少し前にスケールアウトしておくといったことができそう。

ただ、そのためにはAPがステートレスになっていないと管理が難しいのでそのためのアプリケーション設計も必要になってくるだろう。

AWS Direct Connect

AWS Direct Connect tech black belt aws Networking

AWS Direct Connect

https://d1.awsstatic.com/webinars/jp/pdf/services/20181114-AWS-Blackbelt-DirectConnect.pdf

AWS Direct Connect とは

データセンターやオフィスを専用線を介してAWSへプライベートに接続するサービス。コスト面とネットワーク品質でのメリットが得られる。

 

基本構成

オンプレミス --専用線-- Direct Connect ロケーション -- AWS リソース

 

物理接続

Direct Connect ロケーション（物理）ではAWSの管理するラックのPatch Panel と パートナー/ユーザのラックのPatch Panel をつないで通信する。Link Aggregation Group を構成し、最大4本を集約し、１つの論理インターフェースとして構築することも可能

 

プライベート接続とパブリック接続

  • 仮想インターフェース(VIF)

    • Connection が物理接続なのに対し、VIFはConnection を通してAWSリソースにアクセスするための論理インターフェース
    • VPCへプライベートアドレスを介した接続を提供するのがPrivate VIF
    • AWSの全リージョンへのパブリックIPを介した接続を提供するのが Public VIF
    • Connction を所有しているAWSアカウントから他のAWSアカウントに対してVIFを提供することが可能
    • Jumbo Frame をサポート
    • 構成
      • DC 1 とVPC n を接続することができる。その際はDirect Connect ロケーションに紐づけられたリージョンのVPCにのみ接続が可能になる
      • オンプレDC --Direct Connect-- VPC(VPC Endpoint--)--AWS サービス
    • 上記はPrivate VIF を利用し、VPC Endpoint を介してAWSのサービスに接続していた（そうしないとインターネットへのアクセスが必要なAWSサービスには接続できない）。それに対しPublic VIF を利用するとインターネットへのアクセスが必要なAWSサービスと接続できる

AWS Direct Connect Gateway

単一のPrivate VIF を用いたプライベート接続で、中国以外の全リージョンの複数のVPCと閉域で通信することができる。ただし、オンプレミスからオンプレミス、VPCからVPCへの折り返し通信はできない。

パートナー経由のDirect Connect

  • 専有型
    • Connectionをユーザが管理
    • 物理帯域を専有
  • 共有型
    • Connection はパートナーが所有
    • 他のユーザーも利用するので帯域が他のユーザの影響を受けることがある。

複数のパートナーを利用して冗長構成をとることもできるが、経路広報タイプが異なると予期しない経路の偏りが生まれてパフォーマンスが出なくなる可能性がある。

モニタリング

  • 基本的に高可用性を担保するために複数のDirect Connectを張る場合は異なるロケーションにする。
  • 冗長構成
    • １つのVirtual Private Gateway に複数のVirtual Interface を終端させることができる。経路制御にはBGPパス属性を用いて制御する。これはAWS上の設定ではなく、ユーザーのルータの設定で行う。
    • 経路制御はActive/Active だったりActive/Standby またはDirect Connect/VPN といった構成が取れる
    • ただし、冗長構成の片方が死んだ時にもう片方で動き続けられる様に帯域を管理する必要はある。
    • 上りはDirect Connect 下りはVPNといったことも可能
    • CloudWatch でDirect Connect のモニタリングをすることが可能

雑感

データセンターやオフィスを専用線を介してAWSへプライベートに接続するサービス。料金はポートの使用量とデータアウト時のデータ転送料なので普段利用しているところからガッとあがるということはなさそう。 興味深かったのはDirect Connect の冗長構成の部分で、二本あればいいという訳ではなく、帯域も見ておかないと輻輳が発生してしまいパフォーマンス問題が出てしまうとあたりの話を聞いた時に設計力が求められるなと思った。 セキュリティに厳しい会社でインターネットに繋ぎたくないが、AWSのPrvate Link とDirect Connect でサービスを利用したいというユースケースはありそうだなと思った。