re:Invent 2018で感じたマルチアカウント管理とデータベースのトレンドの変化

この記事は Speee Advent Calendar 2018 の22日目です。

こんにちは。Speee 開発基盤ユニット兼セキュリティ推進室所属のおぎわら (@iogi) です。好きなAWSサービスは AWS CodePipeline です。あと、コストレポートを眺めるのも大好きです。

開発基盤ユニットについては、ちょうどビットジャーニー井原さんとの対談記事が公開されたので読んでもらえるとうれしいです。

今回、初めてAWS re:Inventに参加してきました。 re:Inventのセッションや新機能発表は、AWSのサービスの広がりによって、数も分野も年々多くなりつつあります。自分はその中で、業務で関連するセキュリティやネットワーク、DevOpsといったジャンルを中心に参加してきました。

これらから、全体を通じて感じたこととして、マルチアカウントの管理のトレンドの変化、データベースのサーバレス化について書いていこうと思います。

マルチアカウント環境の統合管理

大昔だと、本番環境とステージングや開発環境はAWSアカウントを分けるべきか? と悩むことがありました。アカウントを分けると、完全に分離され一方が影響を及ぼすことはない一方、共通で参照したいリソースがあってもできない、そして、同じアカウントだと、IAMポリシーでの制限がなかなか骨が折れる作業であった、サービスによっては対応できなかったためです。

2014年にVPC Peeringがリリースされ、同一リージョン内の別アカウントのVPCと通信ができるようになったことや、2015年にAWS Console画面上で複数アカウント間を切り替えられるようになったり、複数アカウントを使いわけることが一般的になってきました。

今年のre:Invent直前にリリースされた*1 AWS Resource Access Manager では、アカウント間でサブネットの共有ができてしまいます。

管理、セキュリティ系サービスのマルチアカウント対応

単一のプロダクトでも複数のAWSアカウントを使うようになり、複数のプロダクトがあると社内に多数のAWSアカウントが存在するようになってくると、AWSアカウントの管理や、IAM権限や、セキュリティ面の管理が煩雑になってきます。

従来、複数アカウントの管理については、一括請求と、RI、クレジットの融通といっただけだったものが、2016年のre:Inventで発表された*2 AWS Organizations となり、配下のアカウントに組織としての制限をかけたりすることができるようになりました。クロスアカウント、クロスリージョンを意識したマネージドのセキュリティや管理サービスは増え、思いつくところでは以下のようなサービスがあります。

AWS CloudTrail: 2013年のリリース当初から指定したアカウントのS3バケットにログを出力できる*3
Amazon GuardDuty: re:Invent 2017で発表。当初から複数アカウントの結果を集約できる*4
AWS Config: AWS Config Ruleへの準拠状況について、2018年4月に複数アカウントの結果を集約できるようになりました。 *5
AWS CloudFormation: 2017年に StackSets がリリース、複数アカウント、リージョンに CloudFormation Stack を適用することができるようになりました。 *6
AWS Firewall Manager: 2018年リリース*7。AWS WAF RuleをOrganization配下のアカウントにデプロイ
AWS Security Hub [NEW]: 複数アカウントの GuardDuty や Inspector の結果を統合管理したり、コンプライアンスチェックを行えるサービス (2018/12現在、プレビュー)

AWSはAPIで操作できるので、自身で結果を集約したり、パートナーソリューションで一括監視することは従来から当然できるのですが、よりまとめてみやすくなるようになってきたという印象です。派手ではないですが地味に便利です。

AWS Landing Zone

AWS Landing Zone は、最近かかれたマルチアカウントをどう管理していくかのリファレンス実装です。

aws.amazon.com

AWS Landing Zone は、AWS ベストプラクティスに基づいて、セキュアでマルチアカウントの AWS 環境を顧客がより迅速に設定できるようにします。多数の設計の選択肢がある場合、マルチアカウント環境を設定することは、長い時間がかかり、複数アカウントとサービスの設定を含み、AWS サービスの深い理解が必要な場合があります。このソリューションは、セキュアでスケーラブルなワークロードで実行される環境のセットアップを自動化する一方で、コアアカウントとリソースの作成を通じて初期セキュリティベースラインを実装します。

re:InventでもAWS Landing Zone関連のセッションやChalk Talk (軽く説明をして、そのあとスピーカーと質疑応答) が多くありました。以下は SEC303: Architecting Security & Governance across your AWS Landing Zone です。

AWS re:Invent 2018: Architecting Security & Governance across your AWS Landing Zone (SEC303-R1)

スライド: Slideshare

かなりアグレッシブにアカウントを分割し、各チームやグループ単位で、各ステージ (Prod, Pre-Prod, Dev)、共有サービスのアカウント、さらに大きい単位での共有サービスや、ログ集約、セキュリティ、さらに各開発者ごとにSandboxアカウントを作るといったものになっています。

f:id:i_ogi:20181222232508p:plain

ここまでやるかは別としても、上で書いた管理系サービスのマルチアカウント対応や、リソース共有やネットワーク機能の強化 (AWS Resource Access Manager、VPC PrivateLinkやTransit Gateway) などで実現ができるようになり、より開発が迅速に行える環境を用意しつつ、セキュリティも担保できるような状況となっているということを改めて感じました。

このあたりの知見を活かしつつ、SpeeeのAWSでの開発効率の向上とセキュリティの向上の双方をよい感じにすすめていきたいと思いました。来年、セキュリティに特化したイベント、re:Inforce が開催されることが会期中にアナウンスされましたが、これもまた象徴的です。

データベースの Pay per request 化

AWSでサーバレスといえば、AWS Lambdaですね。Ruby対応や、カスタムランタイム対応で盛り上がりましたが、別の切り口としてデータベースの価格の話を書きます。

この手のFaaSを利用するとき問題となるのが、ストレージやデータベースです。Lambda自体はステートを保持しないため、呼び出しの都度、データをDynamoDBや、RDSに読み書きすることが必要です。

今回、地味なアップデートではありますが、DynamoDBが従来のProvisioned Capacityのプランに加えて、On-Demandの価格プランが追加され、すでに使えるようになっています。

aws.amazon.com

多少のスパイクであれば、バーストキャパシティでカバーできますが、とても大きいトラフィックが来るような状況にはスケールがバーストでカバーできず、スケールも間に合わず、という状況が発生します。Lambda側の同時並列実行数より先にDynamoDBがネックになってしまうわけです。かといって、余分にWrite/Read Capacityをもたせるとコスト面で割と高く、という状況でした。

価格体系的には、GCPのCloud Firestore、Cloud Datastore に近くなった感じですね。

また、今回データベース系としては、Amazon Quantum Ledger Database (QLDB) (フルマネージド型台帳データベース)、Amazon Timestream (時系列データベース) がプレビューとして発表されました。

これらの価格体系もまた、リクエストやスキャンしたデータ量に応じたものとなっています。

QLDB: 書き込み、読み込みリクエスト、ストレージ、データ転送量
Timestream: 書き込み件数、クエリ時スキャンされたデータ量、ストレージ、データ転送量

予めキャパシティを予約しなくても、使っただけ、またストレージに蓄積したぶんの料金のみが発生し、(当然ながらアプリケーションの設計も重要ではありますが) スケールしていくというサービスはS3やSQSなど多くありますが、データベースに関しては一定のキャパシティをRDSでもDynamoDBでも確保した上でという状況であり、Lambdaの自由度に対しては、少し劣っているという状況だったのが変わりつつあると感じました。