💭
現場にAWSエンジニアとして入場した時に最初に確認するポイント

2024/11/09に公開
 初めにいくつもの現場を経験したクラウドエンジニア兼SREエンジニアが思う「これは最初に確認しておくべきAWS設定のポイント」をまとめます。

 背景現在、フリーランスのSREエンジニアとして活動している
業務委託としていくつかの現場を経験してきた中で、稼働しているサービス基盤の設定が基本的なベストプラクティスに沿っていないケースが多い
SREエンジニアとして参画したものの、まずは目の前の課題を片付けないとそのままではSRE導入ができない
しかもそういった現場では、ベストプラクティスに沿っていないだけではなく、事故につながるようなクリティカルな設定が抜けているケースが多い
SRE導入を進めるため、まずはベストプラクティスに沿うことを始めることが多い
毎回現場ごとにポイントを整理しているが、基本的に「サービスのアップデートに左右されない見るべきポイント」は大きく変わらない
とはいえベストプラクティスはAWS Well-Architectedフレームワークのドキュメントにすべて書いてあるがドキュメントの内容も長く、読み解くのが難しい
そのすべてを網羅することは難しいが、端的に分かりやすくポイントをまとめたい

 前提AWS Well-Architectedフレームワークの柱（※「持続可能性」を除く）を中心に箇条書きで記載する
AWSに関わるポイントのみを記載する
細かいサービスの仕様や条件などは記載しない
あくまで「ビジネスで一般的に使われやすいAWSサービスを中心に最初に見るべきポイントを端的に表現した」ものとして見てほしい

 ポイント一覧
 セキュリティいつ誰が何を変更したかわかるようにAWS Configで変更履歴を取得できているか
脅威検知のためGuardDutyを有効化し、通知の仕組みを実装しているか
組織全体の権限のガイドを提供するAWS IAM Access Analyzerを有効化し、通知の仕組みを実装しているか
どの通信が発生したかを確認するためのネットワークログ（VPCフローログ）を取得できているか
デフォルトのVPCおよびセキュリティグループを使っていないか
不必要に緩いインバウンドルールのセキュリティグループを使っていないか
外部公開する必要のないリソースがパブリックサブネットに存在していないか
アプリケーションログなどに記録すべきではない個人情報を含んでいないか
払い出したIAMアクセスキーが90日以内にローテーションされているか、またローテーションの仕組みがあるか
機密情報をSecrets Managerに保管し、AWSリソースがその機密情報を使う時はSecrets Managerから変数として取得するようになっているか
不必要にパブリック公開されているS3バケットがないか
S3のブロックパブリックアクセスが有効化されているか
脆弱性を溜め込まないようにOSやDockerイメージの更新運用ができているか
稼働しているサービスにAWS WAFなどのFirewall機能を導入できているか
AWSルートアカウントに多要素認証が設定され、適切な方法で保管されているか
開発者がIAMユーザを共有で使っていないか
開発者に不必要な強い権限のIAMを渡していないか
組織から離れた開発者のIAMユーザが残っていないか
アプリケーションがAWSリソースにアクセスする際にアクセスキーを使わずIAMロールを使っているか
サポートが切れているまたはバージョンの低いDBを使っていないか
DBのマスターユーザーをそのまま使っていないか
DBの監査ログを取得できているか
Lambdaがパブリックアクセス可能になっていないか
Lambdaが廃止されたランタイムを使っていないか
リソースの削除保護が有効になっているか

 信頼性サービスを構成する基盤が冗長構成になっているか
RDSでいうとレプリカを含むマルチAZになっているか、ECSでいうと複数AZにタスクが分散されるようになっているか

アプリケーションのデプロイがBlue/Greenデプロイなど無停止のデプロイを採用できているか
本番相当の開発（またはステージング）環境が用意されているか
監視に必要なメトリクスが収集できておりそれを監視できているか
障害を想定したバックアップの取得ができており、リストアがテストできているか

 コスト最適化必要のないリソースが残ったままになっていないか
開発環境のリソースが起動したままになっていないか
CostExplorerなどを用いてコストの状況がいつでも参照できるようになっているか
CloudwatchLogsやS3などに不要なログを溜め込んでいないか
（もしNAT Gatewayの料金が高い場合）VPC内のリソースが過剰に外部への通信を行っていないか
ECRへから大容量のイメージをNAT Gatewayを経由していて料金が高くなったケースがあった

コストの超過を検知するための必要なコストアラートが実装されているか
費用対効果の高いリザーブドインスタンスやSaving Plansなどを活用できているか
反対に不要なリザーブドインスタンスを購入してしまったりしていないか

AWSアカウントに設定しているクレジットカードの上限が設定されていないか
過去金額の上限に引っかかってサービスが止まったケースがある


 運用上の優秀性terraformやCloudformationなどを用いてインフラ環境をコード管理できており、環境構築のフローが整っているか
AWS Health Dashborad通知を有効化し運用に必要な情報を収集できているか
ビジネスに必要なログが収集できており、ElaticsearchやSIEM製品を用いてログを分析できる基盤があるか
監査対応に必要なログが収集できており、組織のポリシーにしたがって適切に保管できているか
RDSであればAuditログ、S3であればアクセスログ、総去履歴であればCloudtrailログなどをS3に保管するなど


 パフォーマンス効率サービスを構成する基盤のパフォーマンスを可視化できているか
サービスを構成する基盤が負荷に対してスケーリングできるようになっているか
RDSやElasticacheなどでサーバーレスアーキテクチャを活用できているか
Cloudfrontのキャッシュを活用できているか
コスト観点でもオリジンにアクセスをさせないでキャッシュを使う方がいい

パフォーマンステストを実行できる環境があるか

 その他サービスの制限（Service Quotas）に到達しそうな設定はないか
Service Quotasの上限に到達すると止まってしまうものもあるので注意

上記の課題がAWS Trusted Advisorで解決できているか

 まとめ若干それぞれの柱とズレる項目もありますが、現場入場時に最初に見るべきポイントはざっくりこのような感じだと思っております。
他は現場で使っているサービスを把握して公式ドキュメントを読んだりして、ベストな設計を考えています。
さて、ここまで書いたものの基本的にはTrusted Advisorコンソールを確認することでAWS Well-Architectedフレームワークに沿った推奨設定は概ね確認できます。(書いている途中で思いました。)
しかし
Trusted Advisorにてすべての項目を取得するにはビジネスサポートプランが必要であること
確認すべき項目の中でとくにセキュリティではビジネスインシデントになり得るようなポイントが多くあること
Trusted Advisorには書かれていないが確認すべきポイントがある
などから「最初に見るべきポイント」を端的にまとめることとしました。
誰かの何かの参考になればと嬉しいです。
初めに

背景

前提

ポイント一覧

セキュリティ

信頼性

コスト最適化

運用上の優秀性

パフォーマンス効率

その他

まとめ

Discussion
