(レポート) DVO303: Amazon Service Catalog、AWS Config、およびAWS CloudTrailを使用したインフラストラクチャスケーリング操作 #reinvent
ウィスキー、シガー、パイプをこよなく愛する大栗です。 re:Invent 2015でAmazon Service Catalog、AWS Config、AWS CloudTrailについてのセッションに参加したのでレポートします。
レポート
このセッションへの期待
- 標準化するスケールするインフラストラクチャの監視
- コンプライアンス推進のためのビジネス方針の体系化
- 開発者の生産性を犠牲にしないでセキュリティ、オペレーションの姿勢を改善
- タイムリーなトラブルシューティング
成長は良い
- 実験段階:2人の開発者、2〜3台のインスタンス、1つのアプリ、数百のAPIアクション
- 製品ローンチ:3人の開発者、数十台のインスタンス、2〜3のサービス、数百のAPIアクション
- 6ヶ月:数十人の開発者、幾つかのアプリとサービス、数千のAPIアクション、数十の顧客
- 12ヶ月:幾つかの開発チーム、数十のアプリ/サービス、10万のAPIアクション、数百の顧客
成長は良い。。。
、、、しかし、上手くスケールするためには早期に良い投資が必要です
- 実験やミスのために新規ユーザを増やす
- 様々なデバイスがアクセスしクラウドを使用する
- セルフサービスでインスラにアクセスする ^ グローバルな労働力
成長は挑戦
- 様々な新しい開発者(AWSにも新しい開発者)
- 間違いが非常に効果になる
- 開発者の生産性維持が難しくなる
- 数多くの運用とトラブルシューティング
- 騒がしい#slackチャネル
伝統出来な選択肢
- 分散化と希望
- ロックダウンと承認
またはスケールに対して自身で提供し自身で管理する
- ゴール
- 素早さ
- 確信
- コンプライアンス
- リスク緩和
- コスト管理
- 文化
- DevOps文化
- 継続てきデプロイ
- 自動化
- 計測
- 共有
- ツール化
- Infrastructure-as-code
- セルフサービス
- 監査
- 変更追跡
AWSのマネージドサービスを使う
AWS Service Catalogとは?
AWS Service CatalogはITサービスの構築と管理を組織に許可します。セルフサービスで必要なITサービスを素早くデプロイ出来るようになります。
Service Catalogのフロー
セルフサービスのプロビジョニングと標準化
- セルフサービスのプロビジョニングで素早くなる
- 標準化とコンプライアンつを推進
- コスト追跡と配賦のためのタグリソース
AWS CloudTrail
CloudTrailが有効なユースケース
- セキュリティ分析
- AWSリソースへのAPIコールの追跡
- 運用のトラブルシューティング
- コンプライアンスの実証
APIコールの検索
ユーザ、リソースタイプ、API.リソース名で検索します
ユーザの行動とAPI使用を追跡
- API活動の完全なログ
- だれが、何を、いつ、どこでを素早く回答
- 問題解決をより速く可能
- APIのアラートを設定
AWS Config
- AWSリソースのインベントリを取得
- 記録された設定をチェックするルールを作成
- 設定履歴を監査
- 設定変更を通知
設定アイテム
コンポーネント | 説明 | 含まれるもの |
---|---|---|
メタデータ | 設定アイテムの情報 | バージョンID、設定アイテムID、設定した時刻、りそーすの設定順序を表すステートID、MDハッシュ、等 |
共通属性 | リソース奥製 | リソースID、リソースタイプ、ARN、AZ,等 |
リレーション | アカウントのリソースが他のリソースとどのように関連しているか | EBSボリューム vol-1234567がEC2 i-a1b2c3d4にアタッチされている |
現在の設定 | リソースのDescribeやLIST APIで得られる情報 | EBSボリュームの場合、DeleteOnTerminationフラグの状態、ボリュームタイプ。例えばgp2、io1、standard |
関連イベント | リソースに芸剤の設定に関連したAWS CloudTrailイベント | AWS CloudTrailのイベントID |
Config Rule
記録された構成について妥当性をチェックするツール
- AWS Managed Config Rule AWSが定義してみつ用最低限の設定を有効にしています。ルールはAWSに管理されます
- Costomer Managed Config Rule 赤田のアカウントで作成するルールでオーラリングを必要とするか。AWS Lambdaを再利用します。あなたのアカウントでルールを実行します
なぜConfigを使用して変更イベントを追跡するか?
- セキュエイティ分析;自分は安全?
- コンプライアンス監査:証跡は何処にある?
- 変更管理:この変更はどんな影響がある?
- トラブルシューティング:何が変わったか?
- 検出;どんなリソースが存在するか?
セキュリティパートナー
リソースのインベントリと変更を追跡
AWS Config
- Config Ruleで継続的に順守できる
- 理想的な構成のためにConfig Rulを設定する
- 構成変更の記録
- ストリームの変更通知
AWSマネージドサービスの使用
AWSマネージドサービスを試して下さい
- AWS Service Catalog セルフサービス、標準化、管理
- AWS CloudTrail 活動の追跡。APIコールのログ監査、トラブルシューティング
- AWS Config Config Rule、変更記録、ストリーム通知、サインアップ <https://aws.amazon.com/config/preview>
さいごに
今までのAWS Configでは変更の履歴を取ることまでしかできませんでしたが、今回Config Ruleが発表されたことでルールに則らない変更についてLambdaを使って操作することが出来るようになりました。これからは標準化も自動化出来るようになり、ますます変更管理が楽になると思います。