2020年2月に転職してから使い始めたAWSサービス #AWS

外出自粛が本格化する前の2020年2月、弊社に転職しました。

2016年からAWS関連の仕事を続けていますが、やはり現在の職場で使い始めたAWSサービスも色々ありました。2020年になって自分が初めて使い始めたAWSサービスの振り返りです。（AWSサービス以外も色々ありますが省略）

AWS Organizations

複数アカウントに同じポリシーや設定を適用したい場合、まずはこの機能を検討しました。

既存設定があるケースでも、原則としてOrganizations統合で再設定することで設定ミスや余分なコストは無くなるはずです。いまAWSのドキュメント履歴を見ると2020年の年間更新件数はリリース(2017年)以後で最多になっているので、マルチアカウント対応の要求は高まっていたようです。

CloudFormation StackSets

Organizationsに統合されていないAWSサービスを共通化したい場合、このサービスを使っていました。

一つのCloudFormationテンプレートをマルチアカウント/マルチリージョンに展開できるため、Condition句を使えば特定のアカウント/リージョンだけに適用することも可能です。

Condition例（抜粋）

Conditions:
  OnlyUSE1: !Equals [ !Ref "AWS::Region", "us-east-1" ]  # バージニア北部リージョンのみ
  OnlyAPNE1: !Equals [ !Ref "AWS::Region", "ap-northeast-1" ]  # 東京リージョンのみ
  ControlAccount: !Equals [ !Ref "AWS::AccountId", !Ref "GovernAccount" ]  # 管理アカウントのみ(GovernAccountはパラメータ)
  MemberAccount: !Not
    - Condition: ControlAccount  # 管理アカウント以外
  OnlyMemberAccountAndUSE1: !And
    - Condition: OnlyUSE1
    - Condition: MemberAccount  # 管理アカウント以外のバージニア北部のみ

ただ、現時点の仕様としてStackSetsを使う上で注意点もあります（2020年7月頃、AWSサポートにも確認済み）

組織に対するStackSetsデプロイを実行しても、マスタアカウントには適用されない
- マスタアカウント単体にStackSetsを実行して対処しました（CFnテンプレートは同一でOK）
複数のStackSetsを同じ組織またはOUに対する自動デプロイしたい場合、実行順序を制御できない
- 暫定対処として「組織に対するデプロイ」と「指定OUに対するデプロイ」の2段階に分けて運用してます
- 組織に対するStackSetsは、Organizationsに新しいアカウントを作成した直後に自動実行されます
  - IAMロール等のグローバルなAWSリソースを作成する
- 指定OUに対するStackSetsは、新アカウントを指定OUに手動で移動した後に自動実行されます
  - リージョン個別のAWSリソースを作成する

AWS Backup

特定のリソースタグを参照するバックアッププランをStackSetsで作成しました。

バックアップ/リストアはシステムごとに方針が変わるため、何パターンのバックアッププランが必要かを社内でヒアリングしましたが、バックアッププランの適用までは強制しませんでした。

バックアップ有無まで強制したい場合はOrganizations統合のBackup policiesがユースケースになりそうです。

AWS Chatbot

現在はSlackを通知先として、AWS Configによる変更通知とAWS Healthによるイベント通知のために使用しています。
これもStackSetsで作成しました。

Chatbotは複数アカウントに作成せず管理アカウントのみに作成したかったため、次の方法をとりました。

AWS Configのアグリゲータ機能で管理アカウントに集約する
AWS Healthのイベントは全てAmazon EventBridgeのevent busを使って管理アカウントに集約する

Amazon EventBridge

event busのソースアカウントとターゲットアカウントの両方で設定は必要で、これもStackSetsで作成しました。

Condition句を使うことでテンプレートは1つで済んでいますが、イベントを集約するターゲットアカウントの方でイベント受信のパーミッション設定は手動対応しました。

ターゲットアカウントにおけるイベント受信のパーミッション設定（例）

$ aws events put-permission --action events:PutEvents --statement-id OrgEventBridge \
--principal \* --condition '{"Type" : "StringEquals", "Key": "aws:PrincipalOrgID", "Value": "o-で始まる組織ID"}'

$ aws2 events describe-event-bus
{
    "Name": "default",
    "Arn": "arn:aws:events:ap-northeast-1:{管理アカウントID}:event-bus/default",
    "Policy": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"---ランダム文字列---\",\"Effect\":\"Allow\",\"Principal\":\"*\",\"Action\":\"events:PutEvents\",\"Resource\":\"arn:aws:events:ap-northeast-1:{管理アカウントID}:event-bus/default\",\"Condition\":{\"StringEquals\":{\"aws:PrincipalOrgID\":\"o-で始まる組織ID\"}}}]}"
}

最後に

「今年初めて使い始めたAWSサービス」を列挙しましたが、やはり複数アカウント統制まわりの機能が多かったです。AWSのマネージドサービスを前提としても、複数アカウントを同様の方針で運用したい場合はユーザ側が使いこなす必要があります。

アプリ開発ではサーバレス構成/サーバフル構成のどちらも使う機会はありますが、（AWSサービス観点では）個人的には新機能に触れる機会は少なめでした。今後はもっと開発寄りの新機能も積極的に使っていく予定です。運用ツールとしてだけでも、AWS Perspectiveやanaynayak / aws-security-vizのようなグラフは欲しい。。

2020年2月に転職してから使い始めたAWSサービス

目次

AWS Organizations

CloudFormation StackSets

AWS Backup

AWS Chatbot

Amazon EventBridge

最後に