AWS ServiceCatalogまとめ

# この記事の目的
- ServiceCatalogでの環境構築を組織内に展開するためにやったことの個人的な整理
- ServiceCatalogの情報が圧倒的に少ないので
- ServiceCatalogを利用するにあたってのつまづきどころなど、わかったことを記載

# はじめに
- ServiceCatalog自体の細かい説明は割愛
    - [オンラインドキュメント](http://docs.aws.amazon.com/ja_jp/servicecatalog/latest/adminguide/getstarted.html)

- 2017/03時点の情報
- 筆者が使い始めたのが2016/12ぐらいからなので、それ以降のお話
- アップデートはこまめにあるようなので、今後は解消されている可能性は高い

# ServiceCatalogの概要
- 「管理者」と「ユーザー」に別れる
- 「ユーザー」は管理者が用意した「ポーフォトリオ」にある「製品」を通じてAWSリソースの作成が可能
    - 製品(Product)：CloudFormationテンプレートに対応
    - ポートフォリオ(Portfolio)：製品の集合
- 課金は”ポートフォリオにユーザーを割り当てたタイミングで1ヶ月分発生”
    - ポートフォリオにはIAMユーザー、IAMロールを割り当てられる
    - ロールにだけ割り当てて、Switchロールで使うと課金されないみたい
- リソース作成を「製品の起動(Launch Product)」と呼び、パラメータ変更は「製品の更新(Update Product)」、リソース削除は「製品の終了(Terminate Product)」

## ServiceCatalogのいいところ
- [オンラインドキュメントの説明](http://docs.aws.amazon.com/ja_jp/servicecatalog/latest/adminguide/introduction.html)
    - エンタープライズな組織内での利用において「標準化」は1つのポイント
- ユーザーに直接EC2作成(RunInstance)権限を与えずに、インスタンス作成をさせることができる
    - リソースタグ付けを強制させることができるのでその後の操作はタグを条件にIAMポリシーで制御できる
    - リソース作成時にどのIAMロールで行うかを管理者が指定できる（起動制約）
- EC2インスタンスタイプの変更もServiceCatalog経由で行うことで不用意に巨大なインスタンスを作成してしまうこともない
    - ユーザーごと（正確にはポートフォリオごとに、製品ごと）にパラメータ値を制限できる（テンプレート制約）
    - 製品ではすべてのインスタンスタイプを指定できるようにしてあるが、ユーザーAにはlargeまで、ユーザーBには4xlargeまで、といった具合

などなど。

## 使ってみた”つかいどころ”
- EC2にCloudWatchAlermのAutoRecoveryを必ずセットで作成
- EBSボリュームは1つだけ必ず付けて、KMSキーで暗号化
- RDSも暗号化強制
- RDSにはセキュリティグループを必ず付けて、セットで作ったEC2からのみ通信許可
- 管理者が割り当てたSubnet内にのみリソース作成可能に
- RDSのライセンスタイプにBYODは使わせない（ライセンス違反があると危ない）

などなど。

## ServiceCatalogの最近のアップデート
- [製品に使用できるCloudFromationテンプレートにYAML形式が利用可能に](https://aws.amazon.com/jp/about-aws/whats-new/2017/02/aws-service-catalog-introduces-support-for-yaml-formatted-aws-cloudformation-templates/)
    - それまではJSONのみ
    - CloudFormationでは以前からYAMLに対応していたが、それに追いついた形
- AWS CLIに管理者の機能が追加
    - ManagementConsoleのUIからできないこともできるように（後述）

# ServiceCatalogの困ったところ
## 製品(Product)のCloudFormationテンプレート
- CloudFormationで使えてもServiceCatalog製品としては使えないことがある
    - YAML対応したものの、CloudFormationのYAML短縮形(!Ifとか)は使えない。無視されるので構文エラーになる。。
    - そして製品起動後にエラー。（通常の文法エラーであれば、製品登録時にエラーになる）
- ManagementCosoleから製品の古いバージョンを削除する方法がない
    - CLIや各種SDKならば可能( [CLI Command Reference: delete-provisioning-artifact](http://docs.aws.amazon.com/cli/latest/reference/servicecatalog/delete-provisioning-artifact.html) )
    - ということがオンラインドキュメントの方には解説がない。
- ParameterのDescriptionに&lt;br&gt;,&lt;h1&gt;,&lt;strong&gt;,&lt;font&gt;タグが使える
    - &lt;script&gt;タグなどはさすがにサニタイジングされる
    - CloudFormationでは単にすべてテキストとして解釈される
    - 今後も使えるかというと、使えなくなるのではないかと思われる

## 製品(Product)起動時の挙動
- CloudFormationと違って、AllowedPatternでの精査は製品起動後に行われる
    - これにより失敗した製品は削除するしかない
    - が、何故か製品の更新(Update Provisioned Product)ができてしまい、かつ即時成功となりAvailableとなってなんだかわからなくなる
- テンプレート制約で、Stringパラメータの未入力チェックが設定できるが、これも起動後にチェックされる
    - 未入力でなく、入力値の組み合わせなどの制約は起動前にチェックされるのに。。
- テンプレート制約条件の属性値として、VPCやSubnet、SecurityGroupのタグ値を使える、と[されている](http://docs.aws.amazon.com/ja_jp/servicecatalog/latest/adminguide/intrinsic-function-reference-rules.html#rules-parameter-attributes)が、動かない
    - 具体的には、ManagementConsoleでは製品起動時のパラメータ入力画面で項目が表示されない、次に遷移もしない
    - CLIから製品起動するとできるらしい

# まとめ的な所感
- 製品テンプレートのメンテナンスをやり続けられるのかという課題は別途あり
    - ServiceCatalogおじさんができあがるかもしれない
- AWS環境を自治できる組織には個別のアカウントを作成して、[Organizations](https://aws.amazon.com/jp/organizations/)で大枠制御しつつ、標準化されたCloudFormationテンプレートを提供するというガバナンスの方がフィットしそう