概要

前回の記事の続きです。
AWS Innovate onlineConference内のAWS認定試験-試験対策「ソリューションアーキテクト・アソシエイト」 のメモあくまでメモなので興味のある方は実際に視聴するのをお勧めします。

セキュアなアプリケーションおよびアーキテクチャを規定する

アプリケーション層の保護方法を決定する

• インフラストラクチャ

  • 責任共有モデル
    • AWSが提供するサービスはクラウドのセキュリティに責任を持つ
      • ハード、ネットワーク、施設
    • お客様はクラウドにおけるセキュリティに責任を持つ
      • ファイアーウォールやアカウントなど
  • ユーザ
    • 認証情報を持つ
  • グループ
    • ユーザを束ねる
  • ロール
    • 一時的な権限の委任
  • ポリシー
    • 認証を受けたユーザがアクセスできる範囲を指定する
    • リソースの範囲を定義する

• AWS リソースの保護

  • 最小限の保護
    • ユーザが何をするかを考えて必要なもののみ渡す
  • アイデンティティ
    • IAM
      • アカウント内に作成するユーザ
    • ロール
      • EC2インスタンス、Lambdaおよび外部のユーザが使用する一時的なもの
    • フェデレーション
      • IAMでロールを割り当てられた、ActiveDirectoryアイデンティティまたは会社の他の認証情報を持つユーザ
    • ウェブID フェデレーション
      • Security Token Serviceを使用してロールを割り当てられたAmazon.comやほかのOpenIDプロバイダーのウェブIDを持つユーザ

• IAMユーザを使いまわすのはアンチパターン

• VPC

  • セキュリティの設定はお客様の責任範囲内

  • サブネットの使用方法

    • 推奨事項 インターネットのアクセス可否を定義するためにサブネットを定義する
    • パブリックサブネット
      • パブリックインターネットへのアクセスを可能にするにはルーティングテーブルへインターネットゲートウェイへのエントリを含める
    • プライベートサブネット
      • ルーティングテーブルにインターネットゲートウェイへのエントリがない
      • パブリックインターネットから直接アクセスできない
      • ジャンプボックス(NAT,プロキシ、踏み台ホスト)を使用して制限付くでアウトバウンド専用のパブリックインターネットアクセスを可能にする
    • セキュリティグループ
      • ファイヤーウォールとして機能
      • 許可のみ
      • ステートフル
        • アウトバウンドは無条件で通過
      • ENI 仮想的なNICに適用
    • ネットワークアクセスコントロールリスト(ACL)
      • 許可、拒否両方
      • ステートレス
        • 受信、送信両方とも適用される
      • サブネットに適用
    • ルール、ステート、適用対象は特に重要

  • セキュリティグループ

  • VPC接続

    • インターネットゲートウェイ : インターネットに接続
    • 仮想プライベートゲートウェイ : VPNに接続 オンプレミスとつなぐときに使う
    • AWS DirectConnect : 専用パイプ 専用線を使いたいとき
    • VPCピア接続 : ほかのVPCに接続
    • VPCエンドポイント : VPC外のサービスに接続 VPCのなかのインスタンスとS3などをつなぐときに使う
    • NATゲートウェイ : プライベートサブネットからインターネットトラフィックを許可 パッチを当てたいときや外部のAPIと連携するときなど 可用性や拡張性はお客様が実施

データの保護方法を決定する

• AWS 外部の通信

  • インターネットからのウェブ経由のSSL
  • オンプレミスとのVPN接続IPsec
  • 大容量のデータ snowball

• 保管中のデータ

  • アクセスコントロール デフォルトではプライベートになるため認証が必要
    • S3はアクセスログの機能がある
  • データの暗号化
    • サーバサイド
      • 保存するときに自動的に暗号化
    • クライアントサイド
      • 暗号化キーを使って暗号化
      • ある種のコンプライアンスや規約がある場合に利用
  • 暗号化キーの管理
    • お客様が管理
      • AWS KMS
        • キーの作成や管理を容易にできる
        • クラウド上のマルチテナント型
      • AWS CloudHSM
        • お客様専用の暗号化キーの管理サービス

原則

• ルートユーザをロックダウンする
  • 通常の運用では使わない
  • IAMユーザを作成する

• セキュリティグループは許可のみ行う

• ネットワークACLは許可と拒否を行う

• アクセスキーよりIAMロールが望ましい

コスト最適化アーキテクチャを設計する

コストを最適化したストレージの設計方法を決定する

コストを最適化したコンピューティングの設計方法を決定する

• データ転送

  • リージョンの外への送信で料金がかかる

• EC2の料金の検討事項

  • サーバの実働時間
  • マシン構成
  • マシン購入タイプ
  • インスタンス数
  • ロードバランシング
    • ELBを使う
  • 詳細モニタリング
    • デフォルトは５分 １分間隔にもできるが料金はかかる
  • AutoScaling
    • これで起動したインスタンスに対して料金がかかる
  • Elastic IP アドレス
    • IPを確保して使っていないと課金される
    • アタッチしていてインスタンスを起動させていればかからない
    • 2つ以上アタッチしていると２つ目以降に料金がかかる
  • オペレーティングシステムとソフトウェアパッケージ

• ワークロードを考えてインスタンスを選択する

  • 固定かバーストできるかなどを考える

• インスタンスにはインスタンスストレージがついてきて無料で使える

コスト削減方法

• 最適なインスタンスファミリーを使う
• 使っていないいインスタンスは停止または終了する
• 最適な料金オプションを選択する
  • 従量課金のオンデマンド以外に予約を行うリザーブド、必要な時に確保するスポットを考えてみる
    • リザーブドは1年、３年契約最大75%割引 スケジュールRIは特定の時間決まっている場合に有効
    • スポットは空きがなくなると強制中断される可能性もある
• ストレージ
  • S3
    • ストレージクラス 取り出すときにお金がかかる
      • 標準
      • 標準低頻度アクセス
    • ストレージサイズ
    • リクエスト
    • データ転送
  • EBS
    • ボリュームサイズ
    • ボリュームタイプ
      • SSDタイプ IOPSが高い
      • HDDタイプ IOPSは低いがシーケンシャルな処理のスループットが高い 値段は安い
    • 1秒あたりの入力/出力オペレーション回数(IOPS)
    • スナップショット どれくらい保持するか
    • データ転送 リージョンをまたいだデータ転送
• AmazonCloudFront
  • CDN(コンテンツデリバリーネットワーク)を実現できる
  • キャッシュをさせることで料金を安くできる
  • コンテンツ-静的及び動的コンテンツ
  • コスト見積りにおける検討事項
    • データ転送(受信)
    • リクエスト
    • トラフィックディストリビューション

原則

• 使用する予定であれば予約する
• 使用していないCPU時間はコストの無駄
  • 使っていない期間が長いならオンデマンドにして都度止めるなど
• 最もコスト効率の良いデータストレージサービスとクラスを使用する
• 各ワークロードに対して最もコスト効率のよいEC2の料金モデルとインスタンスタイプを検討する

運用上の優劣性(オペレーションエクセレンス)を備えたアーキテクチャを定義する+クロージング

• 運用上の優秀性

  • 準備
    • 運用上の優秀性を実現するためには包括的な準備が必要
  • 運用
    • 技術的なメトリックスに終始せずにビジネス、お客様の成果の達成度で運用を評価する
  • 進化
    • 運用を進化し続けましょう

• 運用上の優秀性:設計原則

  • コードを使用して運用する
    • コードとして実行しヒューマンエラーを抑える
  • ドキュメントに注釈をつける
    • ドキュメントが自動化のために用意したスクリプトなどになります
      • スクリプトに適切なコメントをつけることで何が起こるかを人が判断できる
  • 定期的に、小規模な、元に戻すことができる変更を適用する
    • コンポーネントを失敗ても戻せるようにする
  • 運用手順を定期的に改良する
    • 運用手順を実行するときに改善の機会を探すワークロードを進化させるときに合わせて改善する
  • 障害を予想する
    • 障害シナリオをテストしその障害への理解を確認する定期的なゲームデイを予定しワークロードとシミュレートされたイベントに対するチームの応答を確認する
  • 運用上のすべての障害から学ぶ
    • 運用上のすべてのイベントと障害からチーム間で教訓を共有する

原則

• IAMロールはキーやパスワードよりも簡単で安全である
• システム全体のメトリクスをモニタリングする
• 必要に応じてメトリクスへの応答を自動化する
• 異常な状態を検知してアラートを送信する