[レポート] AWSの利用前におさえておきたい 10 のこと #AWSSummit

当エントリでは2018年5月31日に行われた『AWSの利用前におさえておきたい10のこと』に関する内容をレポートしたいと思います。

当セッションの登壇者及び概要は以下の通りです。

セッションレポート

セッションの目的

• AWSを利用する際に、事前におさえておきたい設定を紹介する
  • AWS ベストプラクティスを活用

セッションの流れ

• Well-Architected Framework(W-A)の紹介
  • 全体像を眺める
• 利用時に最低限おさえておきたい項目を紹介
  • セキュリティ
  • コスト最適化
  • 信頼性

Well-Architected Frameworkとは？

• 設計・運用の大局的な考え方とベストプラクティス集
  • SAの数多くの経験をもとにつくられたもの
  • 常にアップデートされている
• 常に必ず従うべきというわけではない
  • 意思決定の助けに
• 構成要素
  • W-Aホワイトペーパー
  • 5つの「柱」(詳細版ホワイトペーパー)
    • セキュリティ
    • 信頼性
    • パフォーマンス効率
    • コスト最適化
    • 運用性
  • チェックリスト
• 設計原則
  • 推測ではなく計測
  • 自動化を取り入れる
  • 構成を発展的に
  • 各柱にも設計原則がある
    • 例 : 信頼性
      • 回復手段のテスト
      • 回復の自動化
      • キャパシティの予測をしない
  • チェックリスト
    • 推奨項目は優先しておこなう
    • 質問から対策を考える
      • 質問を出発点として、起こり得る事態を考える
      • yes/noの2択ではなく、様々な状況に対応できるかを考える
  • 優先度とトレードオフ
    • それぞれの柱はプロジェクトの性質に応じてトレードオフされる
      • ただし、セキュリティと運用はトレードオフには含めない
        • 必ず優先するべき

特に重要な10項目

• 重要、かつ忘れられがちな10項目をピックアップ

セキュリティ

• No.1 ルートアカウントの保護
  • ルートアカウントはMFA設定した上で極力使わない
  • 通常はIAMユーザ/ロールを利用する
  • 意外と忘れがち
• No.2 ユーザの権限は最小限に
  • IAMユーザ, IAMロール
    • 使い回しはしない
    • 共通の権限であれば、IAMグループを設定
• No.3 認証情報をコードに埋め込まない
  • IAMロール
    • AWSサービスに対して、捜査権限を与える仕組み
    • プログラムから使う際は、IAMロールを与える
  • git-secrets
    • gitリポジトリへの認証情報の混入を防止
• No.4 証跡取得(ログ取得)
  • AWS CloudTrailによる操作ログ取得を設定する
    • API操作を記録
    • 内部からの攻撃を特定できる
  • Amazon GuardDuty
    • 機械学習で驚異を検出
    • CloudTrailのログを元に自動検出
• No.5 各レイヤでのセキュリティ対策
  • アクセス設定
    • 不必要なポートや外部アクセスは閉じる
      • セキュリティグループ、ACL
  • ネットワーク境界での防御策
    • AWS WAF
    • AWS Shield

コスト最適化

• No.6 メトリクスに基づいたサイジング
  • リリース後はスペックをそのままにしていることが多い
    • CloudWatchでメトリクスを取得
      • 安定している場合はインスタンスタイプの見直しを
      • 不安定な場合はAuto Scalingを
• No.7 購入オプションの活用
  • オンデマンド
  • リザーブド
    • Cost Explorerから利用率を確認
  • スポット
    • 分散処理用のノード
    • メディアプロセッシング
    • 活用シーンは増えている
      • SpotFleet
      • Docker Container
• No.8 使用料金の把握
  • Cost Explorerから請求情報を取得
  • 請求アラーム
    • メール, API, Slack通知など

信頼性

• No.9 データバックアップ
  • AWSの各サービスが提供するバックアップ手段を活用
    • RDSの自動バックアップなど
  • 普段から復旧手順の確認を
    • 障害発生時に手順に不備が見つかることも...
• No.10 単一障害点の排除
  • Multi-AZ
    • RDS MultiAZオプション
  • マネージドサービスの活用

まとめ

• 大事なのは、「常に」Well-Architectedであること
  • 定期的に見直しを
  • セキュリティだけではなく、コスト効率も高められる可能性がある
  • Trusted Advisorの活用

おわりに

Well-Architected Frameworkの特に重要な部分についての紹介セッションでした。個別の項目自体はよくある話ですが、全体を踏まえた上で理解することで応用の幅が広がりました。