AWS Service Catalogを理解する

初めに

Control Towerの設定を行う時や資格勉強している時にちょくちょくService Catalogが登場してきたのですが、いまいち理解しきれていない気がするので、実際に触りながら理解してみようと思います。

AWS Service Catalogとは

AWSのドキュメントでは以下のように記載されています。

Service Catalogを使用すると、組織は承認された IT サービスのカタログを作成および管理できます。
組織は一般的に導入されているITサービスを一元管理でき、組織が一貫したガバナンスを実現し、コンプライアンス要件を満たすのに役立ちます。エンドユーザーは、組織によって設定された制約に従って、必要な承認済みの IT サービスのみをすばやくデプロイできます。

OrganizationsでAWSアカウントを管理している時に、メンバーアカウントにデプロイさせたいものをカタログとして登録して管理アカウントから作成できるようにするサービス、みたいなイメージになるでしょうか。

実機を見てみる

とりあえずService Catalogを開きます。

このアカウントではControl Towerを設定していたため、Service Catalog側にControl Towerの設定がありました。Control Towerで行われる設定はここでされていたのですね。

「製品」の項目ではテンプレートでリソースの情報が記載されています。
「ポートフォリオ」の項目では製品の登録とユーザーやロールにアクセス権限する設定の設定がされています。
「製品」でデプロイしたいリソースを登録し、「ポートフォリオ」で製品とアクセス権限を関連付けてデプロイするのが基本的な使い方だと理解しました。

実際に触ってみる

基本的な流れ

まずは製品を作ってみます。
以前AWS Configのルールをいくつか作成するCloudFormationのテンプレートを作成したのでそれを使って製品を作成しました。

参考までにテンプレートは以下です。

Resources:
    S3BucketLevelPublicAccessProhibited:
        Properties:
            ConfigRuleName: s3-bucket-level-public-access-prohibited
            Source:
                Owner: AWS
                SourceIdentifier: S3_BUCKET_LEVEL_PUBLIC_ACCESS_PROHIBITED
        Type: AWS::Config::ConfigRule    
    S3BucketPublicReadProhibited:
        Properties:
            ConfigRuleName: s3-bucket-public-read-prohibited
            Source:
                Owner: AWS
                SourceIdentifier: S3_BUCKET_PUBLIC_READ_PROHIBITED
        Type: AWS::Config::ConfigRule    
    S3BucketPublicWriteProhibited:
        Properties:
            ConfigRuleName: s3-bucket-public-write-prohibited
            Source:
                Owner: AWS
                SourceIdentifier: S3_BUCKET_PUBLIC_WRITE_PROHIBITED
        Type: AWS::Config::ConfigRule
    EbsSnapshotPublicRestorableCheck:
        Properties:
            ConfigRuleName: ebs-snapshot-public-restorable-check
            Source:
                Owner: AWS
                SourceIdentifier: EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK
        Type: AWS::Config::ConfigRule
    Ec2InstanceNoPublicIp:
        Properties:
            ConfigRuleName: ec2-instance-no-public-ip
            Source:
                Owner: AWS
                SourceIdentifier: EC2_INSTANCE_NO_PUBLIC_IP
        Type: AWS::Config::ConfigRule
    RestrictedIncomingTraffic:
        Properties:
            ConfigRuleName: restricted-common-ports
            InputParameters:
                blockedPort1: '20'
                blockedPort2: '21'
                blockedPort3: '3389'
                blockedPort4: '3306'
                blockedPort5: '4333'
            Source:
                 Owner: AWS
                 SourceIdentifier: RESTRICTED_INCOMING_TRAFFIC
        Type: AWS::Config::ConfigRule
    RestrictedSsh:
        Properties:
            ConfigRuleName: restricted-ssh
            Source:
                Owner: AWS
                SourceIdentifier: INCOMING_SSH_DISABLED
        Type: AWS::Config::ConfigRule
    RdsInstancePublicAccessCheck:
        Properties:
            ConfigRuleName: rds-instance-public-access-check
            Source:
                Owner: AWS
                SourceIdentifier: RDS_INSTANCE_PUBLIC_ACCESS_CHECK
        Type: AWS::Config::ConfigRule
    RdsSnapshotsPublicProhibited:
        Properties:
            ConfigRuleName: rds-snapshots-public-prohibited
            Source:
                Owner: AWS
                SourceIdentifier: RDS_SNAPSHOTS_PUBLIC_PROHIBITED
        Type: AWS::Config::ConfigRule

次に作成した製品へのアクセス権限を付与するポートフォリオを作成します。
ポートフォリオを作成し、作成した製品と使用しているIAMユーザーにアクセス権を付与しました。

とりあえず製品を作成したアカウントで起動してみます。
「プロビジョニング」⇒「製品」から作成した製品を選び「製品を起動」を選択します。

テンプレートで定義したConfigルールが作成されました。

「プロビジョニングされた製品」からプロビジョニングした製品を終了してみます。

作成されたConfigルールが削除されはじめ、無事なくなりました。

別アカウントに共有する

一連の使い方はわかりましたが、Organizationsのメンバーアカウントで使うみたいなことができてないので今度はそれをやってみます。

ポートフォリオから「共有」を選択し、共有したいAWSアカウントに対して共有することができました。
Organizationsを作成していればその配下のアカウントはすぐ選べるようになっています。

共有先のアカウントにポートフォリオが表示されるようになりました。
同じように共有先のユーザーにアクセス権を付与することで起動ができるようになりました。

起動すると同じようにConfigのルールが作成されました。

まとめ

AWS Service Catalogでリソースのデプロイをしてみました。
OrganizationsでAWSアカウントを管理している場合はすぐにOrganizations組織内のアカウントに共有してデプロイできるようになるので、Organizations組織内で共通のリソース作成を行う場合などあればとても便利だと思います。
やっぱり実機を触ってみるのが一番理解につながりますね。
参考になる部分があれば幸いです。