セキュアで信頼性の高いAWSクラウドアーキテクチャを実際に構築する方法

イントロダクション

AWSのクラウドアーキテクチャをゼロから設計しようとしたことがある人なら、すでにご存知だろう。何かを構築する方法は千差万別で、それを台無しにする方法も同じくらいある。

AWSのドキュメントを少し見ただけでは、「クールだ。しかし、実際の国際的な環境では、一流のプラクティスは、実際の企業のニーズ、価格帯の制限、またはヒューマンエラーに最初に触れることはあまりありません。そのため、perfsysのようなプロフェッショナルと早い段階から一緒に仕事をすることで、後々保護ホールやスケーリングの問題でモグラたたきのようなギャンブルに巻き込まれることを防ぐことができる。

ゴールは単に動くものを手に入れることではありません。トラフィックが急増したり、地域が瞬きしたりしても倒れないシステムを構築することだ。

当たり前のことから始めよう：AWSは野獣だ

AWSを使えば実質的に何でも構築できる。EC2、Lambda、RDS、S3、IAM、VPCなどなど。問題は？選択肢が多ければ多いほど、混乱が生じやすくなる。

AWSの設計が悪いわけではない。ただ、適切に設計しなければならないということだ。そうでなければ、あるチームが「クラウドスパゲッティ」と呼ぶような、相互依存のサービス、ハードコードされた秘密、タグ付けもロギングもなく、何がどれだけのコストをかけているのかまったくわからないという状態になってしまう。

信頼性とセキュリティは "欲しいもの "ではない

セキュリティと信頼性を将来の問題として扱いたい誘惑に駆られる。「本番稼動後にセキュリティーを強化しよう」。「次のスプリントで監視を追加しよう。しかし、データ流出や数時間に及ぶ停電に対処したことのある人に尋ねてみてほしい。これらのステップをスキップすることは、徹夜をすることにつながるのだ。

信頼性の本当の意味

これはスライドデッキ上の稼働時間保証の話ではありません。失敗を想定したエンジニアリングのことだ。サービスがダウンする。ディスクは故障する。APIはタイムアウトする。重要なのは、障害が発生してもシステムが機能し続けるかどうかだ。

アベイラビリティ・ゾーン全体で冗長性があるか？データベース・ノードが故障しても、データが失われたりエラーが発生したりすることなく、システムが耐えられますか？デプロイしやすかったから」という理由で、クリティカルなワークロードを単一のリージョンで実行していないか？これらは、稼働中のシステムと回復力のあるシステムを分ける質問です。

セキュリティは？IAMだけじゃない

アイデンティティとアクセス管理（IAM）は最初の壁だ。しかし、セキュリティはそれだけにとどまらない。一般にアクセス可能なS3バケット。過剰に許可されたロール。Lambda関数にハードコードされた秘密。"コスト削減のため "のログオフ。これらはすべて時限爆弾だ。

aws well architectedフレームワークを使えば、これらの問題が爆発する前に特定することができる。このフレームワークは、アーキテクチャをセキュリティ、信頼性、オペレーショナル・エクセレンス、パフォーマンス効率、コスト最適化の5つの主要分野に分類し、各分野を正直に評価することをチームに強制する。これは銀の弾丸ではないが、難しい質問をするよう促してくれる。

実際に重要なビルディングブロック

さて、本題に入ろう。AWS上でセキュアで信頼性の高いアーキテクチャを構築する際に重要なこと、そしてチームが最もよく間違えることを説明しよう。

IAMロールの正しい使い方（本当にそうだ）

IAMロールは強力だ。強力すぎることもある。何かがうまくいっていないからといって、"AdministratorAccess "をつけるのは簡単すぎる。

早めにロックする必要がある。最小特権の原則は単なるベストプラクティスではなく、唯一まともな運用方法なのです。ということだ：

• サービスごとのロールのスコープ

• 権限におけるワイルドカードの回避

• 短期間の認証情報

• 人間のユーザーにはMFAを義務付ける

面倒だと思いますか？そうだ。しかし、設定ミスのLambdaから顧客データが流出した理由を上司に説明するのも面倒だ。

ネットワークの分離

これも近道が裏目に出る分野だ。超複雑なネットワーク・セットアップは必要ないが、いくつかの基本的なことは長い道のりだ：

• パブリック・サブネットは、インターネットに面する必要があるもの（ALBなど）のみに使用する。

• それ以外はプライベート・サブネット

• アウトバウンドアクセスを制御するためのNATゲートウェイ

• パブリックインターネットにアクセスしないAWSサービストラフィックのためのVPCエンドポイント

すべてが同じサブネット上にあるフラットなVPCは簡単に感じるかもしれない。すべてが同じサブネット上にあるフラットなVPCは簡単に感じるかもしれない。

ロギングとモニタリング：見えないものは直せない

これはもう議論の対象にすらならないだろう。ロギングはオプションではありません。CloudTrail、CloudWatchメトリクス、VPCフローログを取得していないなら、あなたは盲目になっている。

しかし、ここからが問題だ-ロギングだけでは十分ではない。実際にログを見る必要がある。重要なものについてはアラートを作成する。ノイズをフィルタリングする。そして、アカウントやリージョンを超えてログが一元管理されていることを確認する。断片的な可視化では可視化にはなりません。

すべてを暗号化する（例外なし）

静止状態のデータにはKMSを使用する。転送中のデータにはTLSを使用する。鍵をローテーションする。アクセスを監視する。これは、今怠慢になると後で非常に高くつく分野の一つだ。

RDSの暗号化、EBSのボリューム設定、API GatewayのTLSエンフォースメントなども忘れてはならない。このような些細なことが積み重なっていくのだ。

インフラストラクチャー・アズ・コード・オア・バスト

まだAWSコンソールをクリックしてデプロイしているのか？デベロッパーにとっては問題ないが、プロダクションにとっては危険だ。

Terraform、CloudFormation、CDKを使おう。あなたのチームが好むものを選んで、それを使い続けましょう。テンプレートをバージョン管理する。CI/CDを使ってデプロイする。ロールバックを自動化する。手作業でのデプロイはミスを招きやすい。

また、すべてにタグをつけましょう。タグのないリソースは、ラベルのないケーブルのようなものだ。

沈まないスケーリング

AWSはオーバープロビジョニングが大好きだ。あなたは "パフォーマンス "を得ることができ、AWSはあなたのお金を得ることができる。効率的なスケーリングとは、自分のパターンを知ること、そしてそれを計画することだ。

自動スケーリンググループ、スポットインスタンス（注意深く）、キャッシュレイヤーを利用しよう。しかしもっと重要なのは、負荷をかけてテストすることだ。一番避けたいことは、立ち上げから2日後にRDSインスタンスが実際のトラフィックで溶けているのを発見することだ。

また、意味がある場合はキャパシティをリザーブしておくこと。コストを節約し、突然のプロビジョニングの失敗を防ぐことができます。

ディザスタリカバリプランはオプションではない

リージョンがダウンしたら？プライマリデータベースが破損したら？もし答えが「うーん...困ったことになる」なら、DR戦略を練り直す時だ。

これは、別のリージョンにインフラの同一コピーを構築するという意味ではありません。知っておくということだ：

• リストアする内容

• どのくらいの時間がかかるか

• 失われるデータ（もしあれば）

• フェイルオーバー時に誰が何に責任を持つか

そして、リカバリ計画をテストすることだ。そうでなければ、それは単なるフィクションだ。

避けるべき一般的なアンチパターン

あまりに頻繁に見られる、いくつかのダメなパターンを挙げてみよう：

• 1つの大きなアカウントですべてを管理する：AWS Organizationsを使う。prod、dev、stagingなどを分ける。

• デフォルトのVPCとセキュリティグループをそのままにしておく：ロックする。

• t2.microインスタンスを "テスト用 "に頼りすぎる。

• CloudWatchのコストを予算化していない。ログを取らないのはもっとコストがかかる。

• とにかく早く直せ」とアクセスを与える：代わりにプロセスを直せ。

最後の言葉柔軟性を保ち、正気を保つ

クラウドアーキテクチャとは、完璧なセットアップを見つけることではない。柔軟性があり、堅牢で、書いた本人以外も理解できるものを構築することだ。

本当に「完成」することはない。重要なのは、意図的であることだ。早めに難しい質問をすること。頻繁に監査すること。重要なところは自動化する。そして、いつ助けを呼ぶべきかを知ることだ。

正直なところ、AWSはパワフルだが、迷いやすいものでもある。クラウドアーキテクチャに精通したベテランエンジニアと仕事をすることで、"大体うまくいく "か "夜も眠れる "かを分けることができる。

そのために構築する価値がある。