はじめに

AWSのベストプラクティスを読んだり読まなかったり。

IAM でのセキュリティのベストプラクティス抜粋

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html

インラインポリシーではなくカスタマー管理ポリシーを使用する

インラインポリシー : IAM アイデンティティ (ユーザー、グループ、またはロール) に埋め込まれたポリシー
カスタマー管理ポリシー : スタンドアロンポリシー、arn:aws:iam::〜の形でpolicyを利用できる

推奨理由

再利用可能性
- 1つの管理ポリシーを複数のプリンシパルエンティティ (ユーザー、グループ、ロール) にアタッチすることができます。
一元化された変更管理
- 管理ポリシーを変更すると、変更はポリシーがアタッチされているすべてのプリンシパルエンティティに適用されます。

カスタマー管理ポリシーの方が管理が楽ってことのようです。
厳密に細かくポリシーを記載したい場合は、インラインポリシーの使用が便利とのこと。

個人的には、管理ポリシーの方が記述量が減ってわかりやすくなるので、よく再利用するポリシーについてはこちらを利用し、少し変わったポリシーをアタッチしたい場合はインラインポリシーを使うようなイメージですかね🤔

S3のベストプラクティス抜粋

頻繁にアクセスされるコンテンツにキャッシュを使用する

キャッシュ導入が成功すると、レイテンシーが低くなり、データ転送速度が速くなります。また、アプリケーションでキャッシュを使用すると Amazon S3 にリクエストを直接送信する回数も減るため、リクエストにかかる費用を削減できます。

キャッシュの導入

Amazon CloudFront(CDN)
- オブジェクトにアクセスするユーザーの近くにデータをキャッシュできます。
Amazon ElastiCache
- マネージド型のインメモリキャッシュ
- これにより、GET レイテンシーが数桁減少し、ダウンロードスループットが大幅に向上します。
- ElastiCache を使用するには、アプリケーションのロジックを変更して、アクセス数の多いオブジェクトをキャッシュに保存し、Amazon S3 にそのオブジェクトをリクエストする前にキャッシュを確認するようにします。
AWS Elemental MediaStore
- Amazon S3 の動画ワークフローとメディア配信のために特別に作成されたキャッシュおよびコンテンツ配信システムです。

DynamoDBのベストプラクティス抜粋

EKSのベストプラクティス抜粋

EKSクラスターエンドポイントをプライベートにする

EKSクラスターエンドポイントとは、すなわちKubernete APIサーバーへアクセスする際のエンドポイントを意味します。
デフォルトでは、エンドポイントは「パブリック」の設定になっており、エンドポイントはインターネットに向けて開かれます。
インターネットに向けられていますが、IAMによる認証とKubenetes RBACによる認可が行われるため、直ちにセキュリティの問題になることはありません。

クラスターへのアクセスを定期的に監査する

クラスターへのアクセスを必要とするユーザーは、時間の経過に従って変化します。
どのユーザーにアクセスが許可されているか、どの権限が割り当てられているかを確認するために、「aws-auth」コンフィグマップの定期的な監査を計画してください。

サービスアカウントトークンの自動マウントを無効にする

ポッドを作成する際にサービスアカウントを明示的に指定しなかった場合、自動的に「default」サービスアカウントが割り当てられます。

特に権限を利用する必要がなければ、下のような設定を追加します。

ポッドを作成する際、spec:にautomountServiceAccountToken: false

アプリケーション毎に専用のサービスアカウントを使用する

用途やアクセスすべきリソースが異なるアプリケーションでは、単一のサービスアカウントを使い回すのではなく、専用のサービスアカウントを使用するようにします。

非rootユーザーとしてアプリケーションを実行する

コンテナーは、デフォルトではrootユーザーとして実行されますが、これはベストプラクティスとは考えられていません。

spec.securityContext.runAsUser を追加しましょう。

ElasticCacheのベストプラクティス

Redis

https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/red-ug/BestPractices.html

Memcached

https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/mem-ug/BestPractices.html

Cluster Auto Scaler

https://aws.github.io/aws-eks-best-practices/cluster-autoscaling/cluster-autoscaling/

podを立てるために必要なnodeが枯渇した際に、自動で新しいnodeを生成し、podを構築します。

正しい設定をすることで、可用性の向上とコストの削減が見込めます
EC2 Auto Scaling Group
事前確認
- インスタンスタイプは、同じCPU・GPUの形である必要がある
1,000ノードくらいイケる
垂直方向のオートスケーリング
- より大きなnodeへpodを遷移させる
- 単純に、要求リソースを増やす
ノードグループを最小限に抑えることは、大規模クラスターでの動作不安を抑制することにつながる
監視間隔時間（デフォルト：１０秒）を短くすれば、オートスケーリングが迅速に行えるが、APIのリクエストに引っかかるかもしれない。
- 実際のところ、ノードの構築には2分とか時間がかかるので、監視間隔を多少伸ばしても大丈夫だと思います
- 1分とか
スポットインスタンスを使うことで、オンデマンドと比べてコストを大幅に減らすことができます
ノードの優先度を設定することも可能
オーバープロビジョニングという選択肢
- 余分にノードを構築して可用性を高める
podの追い出しが悪影響になる場合は、それをガードしよう（データ分析とか）