AWS関連メモ
ktAWS クレデンシャルについて：
AWSのAPI操作のために必要なアクセスキーとシークレットキーの情報
全てのAPIリクエストに対してクレデンシャル情報を渡してあげないといけない。
AWS CLIでは、コマンド実行毎にクレデンシャル情報を記載する煩雑さを避けるため、
~/.aws/configに記載されたクレデンシャル情報を使えるようになっている。
ktELBの役割 (おさらい)
複数のサーバーにアクセストラフィックを分散
↓
アクセス集中によるサーバーダウンを防ぐ
↓
処理速度の向上や、高い可用性の維持
ELBの設定で、メンテナンス対象や障害が発生しているサーバーへのリクエストのみを停止できる
サービスの全停止も可能。サーバのモニタリングすることで、ヘルスチェックが可能
↓
異常検知時に、サーバを切り離してトラフィックを他に分散→安定稼働に繋がる
分かりやすかった解説記事：
kt最小構成でLAMP環境を構築
EBS：ブロックストレージボリューム
EC2 にアタッチ可能なブロックレベルのストレージサービス。仮想ディスク。
EC2はサーバーを停止すると自動的に初期化してしまう為、
仮想的に外付けされるHDDのような機能
インスタンスタイプの選定はどうやってやるのか??
↓
グローバルIPアドレスの自動割り当てを設定する。
自動割り当てパブリックIP：無効化にする
有効化にすると動的なグローバルIPアドレスが付与され、ネットからアクセスできる。
ただ、この設定で付与されるグローバルIPアドレスは、EC2インスタンスを再起動するたびに
自動的に変更される。
↓
再起動ごとにDNSを書き換えるはめになる
割り当てず、あとで固定のグローバルIPアドレスを割り当てる別のサービスを利用する
動作停止
シャットダウン停止をすると、停止時にOSイメージが保持される。
再度起動すると同じ状態で起動される。
削除を選ぶと、OSを停止すると同時にEC2インスタンスが削除される。
セキュリティグループ
OSレベルでのネットワーク通信のフィルタリングルールを決めるもので、許可するプロトコルを設定する。
デフォルトではすべての接続元からSSHが許可されているので、送信元をマイIPと設定。
グローバルIPが複数ある場合は、カスタムIPを選んでアドレスのレンジをCIRD表記で記述する。
ElasticIP
EIP ＝ 固定のグローバルIPの事
サービスの設定変更や追加は、Web管理画面「マネジメントコンソール」で行う
FQDN(ホスト名)
Fully Qualified Domain Name
FQDNとは、DNS（Domain Name System）などのホスト名、ドメイン名（サブドメイン名）
などすべてを省略せずに指定した記述形式のこと
EIPで固定グローバルIPを取得
↓
EC2インスタンスにアドレスの関連付けで紐づける
↓
Route53でDNSを定義
↓
- VPCのDNS関連の設定
- ルーティング設定
↓
EC2にLAMP環境のセットアップ
ktマネージドサービスの説明
AWSは、EC2に代表されるIaaS（InfrastructureasaService）を提供するクラウド事業者からスタート。
OSとミドルウエアレイヤーまで管理されている、PaaS（Platform as a Service）的なサービスが
どんどん拡充されている。
↓
マネージドサービスと呼ぶ。
主なマネージドサービスとして、
- AmazonS3：ストレージサービス
- AmazonRDS：データベースサービス
- AmazonRoute53：DNSサービス
- AWSLambda：サーバーレスのコード実行サービスなど
マネージドサービスでは利用者はOSにアクセスできない。AWSがインスタンスを管理する。
＜メリット＞
バージョンアップや冗長化、バックアップなどの作業を、利用者側で実施する必要がない
＜デメリット＞
性能問題が出た際に改善する手段が少なくなる
利用者が変更できる範囲が小さくなることで、動作を変えられる範囲も小さくなる。
利用すると構築、運用がとても楽。各サービスの制約を評価して、
問題がなければマネージドサービスはオススメ。
ktコーポレートサイト 冗長化で可用性を確保
EC2インスタンスを作成してWebサーバーとして構成
CMSをインストール
AMIを利用して、複数の仮想サーバーをまとめてセットアップする
ELBと連帯した冗長構成を設定する
負荷分散
アクセス先をELBにする CNAME(ドメイン先のエイリアス)を指定
→ELBはIPアドレスが固定されず、変わる可能性があるから
Route53を利用して、ELBのCNAMEと独自ドメイン名を関連づける
→エンドユーザーがドメイン名を指定してアクセスするとELBにアクセスするようになる
ELBとWebサーバのEC2インスタンスを関連付ける
ktELB設定の注意点
-
ELB用とWebサーバ用で異なるセキュリティーグループを用意する
- ELBはどこからでもHTTP、HTTPSでアクセスできるように
- WebサーバーはELBからのHTTPリクエストしか受付ないよう、送信元をELBが属するサブネットだけに設定（サブネットとするのは、ELBのIPアドレスが変わる可能性があるからWebサーバに直接アクセスできるとELBで制御できないので、）
-
セッション維持の必要性の有無
-
Webサイトではセッション維持機能を使っている場合があり、その際はセッション情報をWebサーバー間で共有する仕組みを用意していなければ、同一クライアントからのアクセスを常に同じWebサーバーに振り分ける必要がある
HTTPSの処理
- ELBではSSLターミネーションというSSL証明書の確認と暗号化/復号処理の機能を備える
- ELBのリスナー設定でロードバランサーのプロトコルをHTTPS、インスタンスのプロトコルを
HTTPにすると自動適用される - 個々のWebサーバーでSSL証明書を管理する必要がなくなるうえ、SSL復号処理の負荷が
下がってEC2インスタンスのコストを削減できる
ヘルスチェックの設定
- デフォルトでは間隔が30秒、応答タイムアウトが5秒、非正常の閾値が2回。
- 障害が起きると40秒〜70秒で検知し、サーバーを切り離す。短すぎると、サーバーの負荷が
高まってレスポンスが低下している状態を障害と誤検知し、サーバーを切り離してしまう。
- 長すぎると、障害が発生しているWebサーバにリクエストを振り分け続ける。
通常はデフォルトで構わないが、性能試験や運用時に調整する。
レスポンスに応じたタイムアウトの設定
- 一定時間応答がないと、コネクションを切断して、クライアントにHTTP504を返す。
ktRDSとEC2上にRDBを構成する違い
- RDBMSを自由に選べる
- OSとDB環境をユーザーがメンテナンスする必要がある
- RDSはパッチ適用、バックアップが自動化される
- DBの運用に制限がかかる
DBの冗長化はアクティブ-スタンバイ構成
マルチAZを使ってマスターとスレーブに同期レプリケーションする構成
DBサブネットグループを作成→障害が起きても、もう一つのサブネットに配置された
サーバーで業務を継続可能にする
-
スナップショットをとる
-
自動バックアップの場合、1日最大35時間まで。スナップショットの方が恒久的。
-
マイナーバージョンアップに注意
- RDSは数ヶ月に1回バージョンアップで30分ほど停止する- マルチAZの挙動として、スレーブがメンテされた後にフェールオーバーによって新しいマスターとなり、元々のマスターが新しいスレーブになる。
- Webサーバー側で切り替え操作が必要になるので、メンテ時間の調整をしたい。
-
マルチAZを利用するとデータの更新処理にかかる時間が長くなる
-
マスターDBと異なるAZにあるEC2インスタンスからアクセスする際に多少遅延が発生する
kt静的コンテンツ(画像、動画、JS、CSS、HTML)を安価に配信→CloudFlontやS3を利用
CloudFrontはCDNの一種で、コンテンツをキャッシュして配信する。
CloudFrontでコンテンツのキャッシュが済んでない場合は、ELBヘアクセス。2回目以降はCFへ。
さらに静的コンテンツをS3に置くと、Webサーバーの負荷を抑え、低コストで配信できるようになる。
S3にファイルを保存すると、ファイル単位でアクセス用のURLが発行される。
これを静的コンテンツの格納先として利用する。
ktEC2のインスタンス設計
コーポレートサイトは、
1.安定したレスポンス
2.数年単位の長期利用 という要件。
性能の安定については、ストレージのI/O帯域に注意。
- EBS最適化利用
- プロビジョンドIOPS (ピーク時の性能を上げる)
IOPS
1秒あたりのディスクI/O回数。
リザーブドインスタンスを検討→1年または3年といった期間を定めて利用を予約する
60~70%を超えるとリザーブドインスタンスを利用している方が安くなる
RDSのマイナーバージョンアップ対応
フェイルオーバーが発生する → Web サーバー側で切り替え操作が必要になる
メンテナンスの時間
※※
Kubernetesでは1つのバージョンが9ヶ月間しか保守されないため、
かなり早いサイクルでクラスタのアップデートをかけないといけない為、注意が必要。
負荷が変動する環境下でも性能が低下しにくいインフラを設計する
- Auto Scaling
インメモリーのキャッシュと高速RDBを活用
- Amazon Elastic Cache
- Aurora
A.時間を指定して決まった数に変更
B.インスタンス利用状況の監視結果に応じて動的に変更
A.処理量が多くなる日時が予想できる時に利用
B予期しないピークの発生に備える場合、必要なリソースが変動する場合に利用
CloudWatchでモニタリング設定する
A.
スケーリングポリシーの最小サイズと最大サイズのみを設定して、インスタンス数を変動させたいタイミングでコマンドラインツール AWS CLIからインスタンスを起動・停止する
最小サイズと最大サイズを設定するのは、グループサイズの増加、減少によるスケーリング範囲を
制限するため
B.
最小サイズと最大サイズに加えて、グループサイズ(Auto ScalingグループのEC2インスタンス数)の増加、減少ポリシーを設定する
例：70%以上使用率→増加 50%以下→減少
インスタンス起動に数分かかるので、パフォーマンス低下を許容できない場合は監視閾値を低めにする
オンデマンドインスタンス
確実に起動できる通常価格のインスタンス
スポットインスタンス
設定した入札価格が変動する市場価格を上回っている時だけ起動できるインスタンス
スポットインスタンスは不安定だが安価。
1段階目：スポットインスタンス
2段階目：オンデマンドといったやり方で運用もできる。
自動デプロイ
リリース時にAMIを作り直す必要があるので、アプリのリリース頻度が高い場合は自動実行する仕組みがおすすめ
Elastic Cache：MemcachedとRedisをサポートしている
Redisは1台のプライマリーと複数のリードレプリカでクラスターを構成している
リードレプリカ：
データベースの負荷分散のために作成される、参照専用の複製。
あるデータベースの内容を複製したもので、データの追加や更新はできず検索や読み込みのみを行うことができる。
パッチ自動化されてる代償として、メンテナンスウィンドウの時間帯に回避できないダウンタイムが発生する可能性がある
ktAurora詳細
Log-Structured Storage
追記型のストレージシステムを採用している
MySQLでは上書き時に更新行のロックが発生
参照時にも一貫性のある読み取りを保証するためロックが発生
↓
同時並行で多くのトランザクションが発生すると、スループットが頭打ちになる
↓
追記型ではロック競合が発生しにくい
リードレプリカの負荷を小さくできる
DBのスケールアウトも容易
MySQL→バイナリーログが必要
Aurora→不要
Service Level Agreement
この値を下回ったら返金するという約束
AMI
amazon machine image
インスタンスを起動するのに必要なOSやボリュームの情報、アプリケーションなどを含むインスタンスの起動テンプレートのこと
ktRoute53 詳細
新規ドメイン名の登録や、ドメインの DNS レコードの管理が行えるサービス
Route53は権威DNS
権威DNSとは、ドメイン名とIPアドレスの変換情報を保持しているDNS
変換情報を保持していないDNS（キャシュDNS）と区別するときに利用
Route53は権威DNSなので、保持しているドメイン名以外の名前解決をリクエストしても応答なし
キャッシュDNSは、別に用意する必要がある。
Auto Recovery
EC2を自動復旧
別リージョンにバックアップを用意する方法
1.障害発生時に自動切り替えする方式
2.バックアップデータからサーバーを作成する方式
ダウンタイムは長くなるが低コストでの運用
1.EC2からAMIを作成
2.AMIをバックアップサイトにコピー
3.平常時は停止、サイト切り替え時にAMIとスナップショットから作成する
AWSのストレージシステム設計
- S3をコマンドラインで利用する
- EC2とEBSで構築したバックアップ用サーバにデータを同期
- 自動バックアップサービス AWS Storage Gateway を利用する
①S3 APIを使ってバックアップする
S3へのデータ受信は無償、送信(アウト)は有償
②オフラインバックアップとオンラインバックアップ
EBSボリュームを用意し、EC2インスタンスにアタッチする
③AWS storage Gateway
オンプレ環境に格納されたファイルをAWS環境に自動バックアップできる
ktGlacierを使う
Glacier
バックアップおよびアーカイブストレージの事
S3との比較
↓
- 料金が安い
- ファイル取り出しに時間がかかる
- ファイル名設定はできず、ファイルごとにアーカイブIDと呼ばれるIDがつけられて管理される
重要データのバックアップは専用線を使う
↓
Direct Connect
AWS上で構築したシステムのバックアップ
①全てのリソースに対して、初期構築時にバックアップを取得する。
EC2、RDSはマネジメントコンソールでインスタンスのスナップショットを取得
↓
S3バケットに収納
S3→AWS CLIを利用して、コンテンツ格納に使うS3バケットからほかのS3バケットに
バックアップしておく。
②通常の稼働中→DBのデータをバックアップする必要がある
DBのマルチAZを利用して自動的に同期したデータを取得する
サーバの設定を変更した場合→EC2、RDSインスタンスのスナップショットを取得する
↓
オンプレ環境でのシステムバックアップに相当するバックアップとして利用できる
③定期的なバックアップ
運用管理用のEC2インスタンスを用意。
EC2上でAWS CLIコマンドを利用したバックアップスクリプトを定期実行する
↓
バックアップ対象のEC2、RDSインスタンスにタグを設定して、タグを指定してスナップショットを
取得するコマンドをスクリプト化する。
S3バケットにもAWS CLIでアクセスして差分更新を取得する
ktファイルサーバー
①アプリからEFS (Elastic File System)をファイルサーバーとして利用
②Storage Gatewayでストレージを自動階層管理
③WorkDocsでのファイル共有
S3をファイルサーバーとして使う場合の留意点
①REST APIを利用
→HTTP/HTTPSでアクセスするので、一般的なファイルサーバープロトコルのNFSよりレスポンスが遅い
②ファイルを排他制御できない
③S3の上書き処理が結果整合性モデルで動作している
↓
障害時にデータがロストしないように、物理的に複数のコピーを持つ分散型ファイルシステムとなっている
↓
ファイルを更新するとコピーのどれかが更新され、時間が経つとほかのコピーも更新される
↓
意図しない更新結果になる可能性がある
EFSの特徴
保存容量：無制限
耐久性：複数AZに複製して保存される
同時接続数：数千のクライアントから接続可能
読み取り整合性：どのノードから読んでも同じデータが読めることが保証 ファイルをロックできる
マウント方法：DNS名もしくはIPアドレスで表されるマウントターゲットをマウントする
性能特性：レイテンシーはEBSより大きく、S3より小さい
スループットはEBSより大きい
暗号化：通信経路とファイルの暗号化に対応
コスト：保存しているファイルの容量に対して課金され、読み書きには保存されない
Storage Gatewayを使うと保有コストが下がる
①オンプレ環境のストレージサイズを小さくできる
②マスターとなるデータをコストの低いS3に置ける
③S3は外部からのデータ転送(受信)には料金がかからないが、外部への転送(送信)には課金される
Storage GatewayはS3経由なので転送料金が少なく済む
Direct Connect：
AWSの専用線 インターネットを経由しないプライベートの接続を実現できるサービス
AWSが直接専用線を提供するサービスではなく、相互接続ポイントを用意するサービス
WorkDocs：文書共有などに活用できる
データ分析のシステム構成
Redshiftを活用する
Hadoop：はーどぅーぷ
テキスト、画像、ログなどの構造化されていないデータを、高速に処理できるオープンソースの
プラットフォーム。
複数のコンピューターで行う分散処理を可能としている。
ktAWS CodePipeline
CIの利用
→CodePipelineを使ってビルドとテストを自動化する
実行環境のコンテナ化
→ECSをアプリ実行環境としてデプロイする
コンテナ切り替えでの無停止リリース
→ECSを使ってBule-Green Deploymentする仕組みを作る
リザーブドインスタンスの利用
＜スマホアプリの環境整備＞
AWS Mobile SDKを利用する
AWS Device Farmを利用して物理デバイスを保有せずに自動テストを実行する
CloudFormationを使って検証、本番を構築
懸念
・物理デバイスのテストに手間とコストがかかる
スケールの種類
スケールアップ：処理ノードの数を変えずに、CPUやメモリーなどのスペックを上げる事
スケールアウト：ノード数を増やす事で大きく処理能力を向上させる事
ktLambdaを活用
LambdaとAPI gatewayを活用
データを永続化する為にRDSに格納
静的コンテンツはCloudFrontとS3を利用して配信
API呼び出しの流れ
①リソースを表すURLでアクセス
amazonaws.com/prod/bill
②HTTPのGETメソッドでパラメータが渡される
③json形式でパラメータが引数で渡される
④実行結果がHTTPのメッセージボディで渡される
API GatewayとLambdaの料金体系はリクエストの回数や処理時間に依存する。
lambdaは軽い処理を大量に実行することを想定したもので、長時間かかる重い処理には向かない
ステートレスな処理を前提としているので、前後の処理との依存関係が強い場合にも不向き
高いレスポンスが求められる用途にも向かない
ktEKSでコンテナ実行管理
マイクロサービス化の事例
家電量販店でビジネスモデルの見直し
- ECの強化
- 家電以外の販売
既存のシステム
仕入れ、販売管理、業務システムをスクラッチで開発したモノリシック(1枚岩)なものだった
開発サイクルを早める、小さい単位で高頻度リリースのためにマイクロサービス化していく
EKSとAWS Fargateでオーケストレーションとプロビジョニングを実行
データレイクの構築
データカタログの構築
Fargate
コンテナ用インスタンスのプロビジョニングやスケーリング管理をサポート
サーバレスのイメージ
データレイク
構造化、非構造化データを一元的に蓄積する場所
データを生の形で蓄積するストレージ、データ品質を保つためにクレンジング、名寄せといった管理機能、分析機能など
awsではS3をデータレイクとして使うことを推奨
Athena
S3にあるデータファイルに対してクエリを実行することのできるサービス
Glue
データの分類や消去、強化などが行える完全マネージドサービス
ktgoofysについて
AWSでS3をサーバーマウントする技術の事。
s3fsに比べ、パフォーマンスが高い(速い)模様
資料：
ktAmazon SNSについて
Simple Notification Service
アプリケーションからの通知を可能にするサービス。
事例：
- 商品が発送されたタイミングでの発送完了通知
- フリマアプリで出品していた商品が購入されたときのプッシュ通知
特徴
- ユーザーアクションをトリガーにしたメッセージ通知ができる
- モバイルのプッシュ通知にも対応
- HTTPS APIによる通信のセキュアなプッシュ
- 従量課金制で利用分しか払う必要がない
SQS(Simple Queue Service) SES(Simple Email Service)の違い
SNS：
- プッシュ通知が得意でSMS、スマフォへの通知が可能
- 容量制限があるのでEメールの長文コンテンツは不向き
- スケジュール配信ができない
- 開封率やA/Bテストといった解析機能がついていない
SES：
- Eメールが得意。Eメールの通知のみ。
SQS：
- 非同期処理で受け取ったメッセージを処理できる。受信メッセージを処理するサービス
設定手順メモ
s3バケットのオブジェクト作成通知をAWS SNS経由でポータルサイトが受信する為に必要な設定
①manifest設定
②snsサブスクライブ作成
公式説明
AdminAcess可能になるSwitchRoleに切り替え
↓
Amazon SNS→トピック→プロジェクトの既存トピック(なければ新規作成)を検索
↓
サブスクリプションの作成→プロトコル(今回はHTTPS)→対象サービスのURL + /※※(それ用のURL)→rawメッセージ配信の有効化をチェック→サブスクリプションの作成ボタン押下
③対象サービスのPod log確認
kubectl logs pod名 --container ECRリポジトリ名 | grep ※※※※
④subscription urlを確認してコピー
INFO web::routes::※※] ConfirmMessage { msg_type: "SubscriptionConfirmation", message_id: "※※", token: "※※※※",
topic_arn: "arn:aws:sns:※※※※",
message: "You have chosen to subscribe to the topic arn:aws:sns:※※※※
\nTo confirm the subscription, visit the SubscribeURL included in this message.",
// 下記のsubscribe_urlをコピーして打鍵する
subscribe_url: "https://sns.ap-※※※※",
timestamp: "※※※※",
signature_version: "※※",
signature: "※※※※",
signature_cert_url: "※※※※" }
⑤コピーしたsubscribe_urlをブラウザで打鍵
下記の表示が出る白い画面が現れたら成功
This XML file does not appear to have any style information associated with it. The document tree is shown below.
<ConfirmSubscriptionResponse xmlns="http://sns.amazonaws.com/doc/2010-03-31/">
<ConfirmSubscriptionResult>
<SubscriptionArn>arn:aws:sns:ap-northeast-*:*:****</SubscriptionArn>
</ConfirmSubscriptionResult>
<ResponseMetadata>
<RequestId>****</RequestId>
</ResponseMetadata>
</ConfirmSubscriptionResponse>
⑥AWSマネジメントコンソール上で確認する
以下のようなメッセージが緑色の枠で表示されたら成功
*** へのサブスクリプションが正常に作成されました。
サブスクリプションの ARN は arn:aws:sns:**** です
⑦コンソールのトピック→サブスクリプションから確認
ID、エンドポイントが一致しており、ステータスが確認済みであれば正常で登録完了
ktElastic IP
固定IP
VPCから外部へアクセスするためのIPアドレスを固定できる
ktリスナー
接続リクエストをチェックする
ALBがどのような通信を待ち受けるか定義する
ktAmplifyについて
バックエンド構築からフロントエンド開発までカバーする開発フレームワーク
特に認証と認可の提供が魅力的。
- コマンドラインで設問に回答するだけ(対話式のCLI)で構築可能
- DBのレコード単位でのアクセス制御も簡単に実装できる
ktAWS WAF
ウェブ アプリケーション ファイアウォールの事
- SQLインジェクション
- XSS
- DDoS攻撃
などの防御効果がある
CloudFront、ALB、API GatewayなどでWAFを有効に設定するだけで、導入準備が完了する
ktCognito
ユーザーの認証・認可を実装する機能
ユーザープール
ユーザーの情報(ユーザー名、パスワード、メール)を管理する
IDプール
他のAWSサービスへの認証情報を管理する
ktACM AWS Certificate Manager
Certificate：証明書
SSL証明書について
Webサイトの証明、通信における暗号化に利用する証明書
ELB、CloudFrontで証明書をプロビジョニングできる
ktロードバランサーの分かりやすい資料 個人的な要約
ELBを使う理由は、
- 冗長化/可用性
- 負荷分散/スケール
ELB自体も負荷に応じて自動でスケールする
注：
NLB以外がスケールする時はIPアドレスが変化する
ELBにアクセスする時は必ずDNS名を利用する
ALB
Application Load Balancer
- HTTP/HTTPSのみに対応(TCPはしていない)
- L7ロードバランサー
NLB
Network Load Balancer
- TCP/UDPに対応
- L4ロードバランサー
- 高可用、高スループット、低レイテンシ
- Source IP/Portがターゲットまで保持される
- 固定IPを持つ
用語
リスナー
LBがリッスンするプロトコルとポート番号
リッスンの解説
listen リッスン
ソフトウェアが外部からのアクセスに備えて待機すること
TCP/IPでは、複数のプログラムが同時に異なる種類の通信ができるよう、
ポート番号が用意されている。
LBからターゲットへの接続用のプロトコルとポート番号など設定
自分が通信したいポート番号をOSに登録し、ポートに接続要求があると
通知を受けて処理を行う。
解説：https://e-words.jp/w/リッスン.html#:~:text=リッスンとは、「聞く」,をこのように呼ぶ。
ターゲット
LBがトラフィックを転送するEC2インスタンスなどのリソースやエンドポイント
利用
- VPC、AZにELBを設置
- AZごとに1つのサブネットを指定
- 基本的に2つ以上のAZからサブネットを指定する
- ELBに任意のSecurity Groupを指定できる(特定IPのユーザーのみアクセス可能な制御が実現)
- ↑NLBは不可
- EC2インスタンスはELBからのみリクエストを受け付ける設定を推奨
TLSサーバ証明書
AWS Certificate Manager ACMで証明書のリクエスト、管理、更新、プロビジョニングが可能
ALB利用時のクライアントのIPアドレス取得
X-Forwarded-Forヘッダーを使用する
※NLBの場合は設定なしでIPアドレスが取得可能
クラスメソッドの資料
ktCloudWatchについて
概要
AWSで動作している各サービスを監視するサービス
標準で用意されている
- システム異常を検知し、障害の時間を最小化する
- サーバーのリソース利用料をモニタリングし、最適なリソース配分を実現する為の情報を取得する
CloudWatch
リソースの稼働状況を監視する
CloudWatch Dashboard
サービスとアプリログを可視化
カスタマイズ可能
Alarm
監視するメトリクスが特定のしきい値を超えた場合に メールを送信するなどの通知アクションを実行
Logs
エージェントをインストールすることで、必要なメトリクスやログを収集
Events
システムイベントをリアルタイムに取得し、イベントに応じたアクションを自動化したりスケジューリングしたりする
ktECインスタンスのクレジットについて
EC2のインスタンスタイプに応じて、CPUクレジットというものがある
CPU能力のバースト継続可能リソース
T2ファミリーのインスタンスの場合、必要に応じて自動的にCPU処理能力がスケールアップする仕様となっている。スケールアップが継続できる時間をクレジットという単位で管理している。
クレジットを使い尽くすと、最低保証ラインまでCPU処理能力が低下する。
この保証ラインをベースライン性能と呼ぶ。
使い切ってもさらに使用されない限り、1時間毎に規定の割合でCPUクレジットの蓄積が再開される。
公式：
ktAWSリソースタグ
AWSのリソースにmetadataをタグ形式で割り当てる事ができる
タグはユーザー定義のキーと値で構成されるラベル
- 個人情報などの機微情報は取り扱わない
- リソースタイプに一貫して適用する
- リソース整理やコスト配分に活用される
ktAWS RDSのコネクションプーリングについて
コネクションプーリング
データを送受信する際、一度形成したコネクション(接続窓口)を維持し続けて使い回す手法。
DBの内容を読み書きする際、DBMSに依頼するが、その際データ送受信するコネクションを確立する必要がある。接続・切断などに一定の負荷が生じるため、頻繁にアクセス等行われるとオーバーヘッドによる性能劣化の恐れあり。
コネクションプーリングを利用すると、使用後切断されず、コネクションプールと呼ばれる待機場所に移され、再アクセス時に使われる。
資料：
利用例の記事：
RDS Proxyの機能が使われている
ktNATゲートウェイとNATインスタンスを比較
本番ではAWSのマネージドサービスであるNATゲートウェイ、
Dev環境では経費削減の為、NATインスタンスといった使い分けが多い
ktCloudFrontについて
AWSのCDN（コンテンツデリバリネットワーク）サービス
コンテンツファイルをサーバーから直接配信せず、CDNを介してユーザーに配信
キャッシュサーバーやプロキシサーバーに近い
資料：https://tracpath.com/works/cloud/amazon-cloudfront/
そもそもCDNとは
Webコンテンツをスピーディーに配信する為のネットワーク技術
オリジナルコンテンツ→オリジンサーバー
オリジンサーバーから複数のコンテンツをコピー→キャッシュサーバー
キャッシュサーバーは世界中に配置されている
- オリジンサーバーの負荷低減
- ネットワークが近いキャッシュサーバーにアクセスさせて速度UP
DNSのAレコードを設定することでインターネットからアクセスできるようにしている
ktQ.なぜSESはus-EAST-1なのか
A.東京になかったから
2020-07 頃、東京リージョンが利用可能になった模様
資料：https://dev.classmethod.jp/articles/new-available-amazon-ses-tokyo-region/
ktEBS
概要まとめ
- EC2向けの永続的なブロックストレージサービス
- API経由でボリュームを作成、アタッチ、管理
- ネットワーク接続型
- サーバーのローカルストレージではない
- EBSボリュームの可用性
- 単体の物理ディスクドライブではない
- アベイラビリティゾーン内で自動的に複製されており可用性と耐久性が確保されている
- 論理障害に対応するバックアップはユーザーがする必要がある(責任共有モデル)
- ネットワーク接続型でストレージとコンピュートが独立して管理されている
- EC2に依存しないボリュームライフサイクル
- ワークロードに基づいてストレージとコンピューティングを選択
- 同じアベイラビリティーゾーン内のEC2 インスタンス間でデタッチとアタッチが可能
- ネットワーク接続型でストレージとコンピュートが独立して管理されている
- EC2に依存しないボリュームライフサイクル
- ワークロードに基づいてストレージとコンピューティングを選択
- 同じアベイラビリティーゾーン内のEC2 インスタンス間でデタッチとアタッチが可能
- 1つの EC2 インスタンスに複数のボリュームのアタッチが可能
- ブートとデータのボリュームを別々に用意することを推奨
- 管理の観点から、システム領域のブートボリュームとユーザーのデータを格納するデータボリュームは別々にすることを推奨
- データボリュームもデータベースであれば耐障害性の観点からデータファイル、ログファイル、バックアップ領域をそれぞれ構成することを検討
- 現時点では無条件で共有ストレージとして使えるわけではない
資料：https://dev.classmethod.jp/articles/aws-summit-online-2020-aws-20/
ktセキュリティグループについて
ステートフルなファイヤーウォールのこと
インバウンドルール
インスタンスへの受信トラフィックを制御する
アウトバウンドルール
インスタンスからの送信トラフィックをコントロールする
- インスタンスの仮想ファイアウォールとして機能
- インバウンドトラフィックとアウトバウンドトラフィックをコントロール
- インスタンスの起動時に1つ以上のセキュリティグループを指定できる
- セキュリティグループを指定しない場合、Amazon EC2 はデフォルトのセキュリティグループを使用する
- セキュリティグループは、サブネットレベルでなくインスタンスレベルで動作する
ktFargateについて
ECSとEKSで動作する、コンテナ実行環境
ホストマシンを意識せずにコンテナを実行する事ができる
EC2インスタンス(コンテナを実行するためのサーバー環境)やすのスケーリング、インスタンスの集合体であるクラスターを管理する必要がなくなり、管理の効率化が図れる。
コンテナ向けのサーバレスコンピューティング
メリット
- ホストマシンのOSやミドルウェアなどの構築が必要ない
- インスタンスタイプやクラスター管理が不要
- オートスケーリング
デメリット
- パブリックIPの固定割り当てができない
- sshやdocker execが使えない
ktSSMについて
Amazon EC2 Simple Systems Managerの略
マネジメントコンソール上からオンプレミス、およびAWSのリソースを管理することができるサービス
資料：https://blog.serverworks.co.jp/tech/2020/04/16/systems_manager_yattemiyou/
ktElastiCache
Redis、Memcachedに互換性のあるマネージド型のインメモリデータストアの事。
特徴
- 高パフォーマンス
- フルマネージド型
- スケーラブル
ktKMS Key Management Serviceについて
参考：
terraformで構築した箇所
resource "aws_kms_key" "encryption"
resource "aws_ssm_parameter"
エイリアスコード(Route53) Aレコード、CNAMEなど
Aレコード
ドメインに対するIPアドレスを登録するためのレコード "A"ddress
CNAMEレコード
ドメインに対応するFQDNを登録するレコード "C"anonical
エイリアスレコード
Route53のDNS拡張機能
AWSリソースにルーティングする為の別名をつけることができる
メリット
- ELB、S3、API GatewayなどDNS名を持つリソースに対して、直接ドメインを登録することができる
- 外部からのアクセスにAレコードとして振る舞う
例：
CNAMEレコード
mydomain.com → myelb1-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com → IPアドレスの 3ステップで名前解決
エイリアスレコード
mydomain.com → IPアドレスの 2ステップで名前解決
ktEC2の踏み台サーバーのユーザー管理
- modle化したec2ディレクトリのdataリソースにtmplateファイルを設置
- templateファイルはsh.tplから参照
- ヒアドキュメントでaws-ec2-sshをインストール
- iam_authrized_groupを変数から設置
- main.tfにmodule.ec2を用意
- iamに登録された値をハードコーディング
資料：
ktNLBと関連サービス
ktBastionについて
インフラにおいては踏み台サーバーの事
ktSSMのパラメータストアを操作する
要件
パラメータストアのパスワード画面を特定のグループで回覧できるよう、
権限を付与する
やった事
templateファイルにポリシーを書いて、TerraformのIAM(aws_iam_policyリソース)
にアタッチする
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeParameters"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:Get*"
],
"Resource": [
"arn:aws:ssm:*:*:parameter/〜〜"
]
},
{
"Effect": "Allow",
"Action": [
"kms:Decrypt"
],
"Resource": [
"*"
]
}
]
}
ktS3の操作パスに関して
ktバウンス率
Eメールが配信できない時、バウンス(送信したメールが不達で返ってくる)現象が生じる
AWSでは10%を超えた場合、利用アカウントによるEメール送信機能を
一時的に停止する可能性がある為、高くなった場合対策が必要
アカウントのバウンス率が 10% を超えた場合、当社はお客様のアカウントによる E メール送信機能を一時的に停止することがあります。
サプレッションリストについて
suppression list
過去にバウンスや苦情が発生したアドレスが登録されるリストの事
抑制という意味
リストにアドレスを登録すると、メールを送信してもSESでメールは受け付けられるが、
送信はされなくなる
グローバルサプレッションリスト
世界中全てのAmazon SESに対して適用される
アカウントレベル サプレッション
AWSのアカウント単位で適用される
ktS3 Presigned URL
概要
s3のファイルを操作するには、必要なPermissonが付与されたIAM Userアカウントを持っているか、必要なPermissonが付与されたIAM RoliをAssumeRoleできる権限が必要
↓
S3 Presigned URLはこの権限を不要にして一時的にs3 bucketへアクセスできるようにするURLの事
- s3のファイルを一時的に不特定多数に公開したい
- IAM Userアカウントを持っていない人に一時的にファイルのダウンロード/アップロードをさせたい
上記の場合に用いられる手段の事
機能
- 特定のIAM Entityの権限で発行
- Presigned URLによるファイルのダウンロード／アップロード→本URLを発行したIAM Entityの権限で実行される
- 有効期限を持たせられる
- WS Signature V2/V4に基づく署名がQuery stringsパラメータに付与されたURL
ktECRのIAMポリシー
ECRマネージドポリシー
ECR IAMポリシー一覧 (公式英語)
ktOrganizationsについて
組織単位でAWSのアカウント管理を行うことができるサービス
組織内の複数のAWSアカウントを一元管理できる
- 組織のアカウントを自動的に作成
- 既存のAWSアカウントを組織に追加
- 通常のAWS利用料金しかかからない
以下のアクセス方法がある
- マネジメントコンソール
- AWS CLI
- SDKs
- Organizatuins HTTPS クエリAPI
ktControl Towerについて
マルチアカウントでのAWS環境の管理を簡単にできるようにするサービス
サービス(Organizations、Service Control Policy、Config Rules、アグリゲータ、Single Sign-On)を組み合わせることで、複数のアカウントで管理を行う為、Landing Zoneがリリースされた
↓
CloudFormationテンプレートが作成されたが、サービスの統制がとれているかチェックして確認する作業が必要
↓
Control Towerの登場
機能
- ガードレール
セキュリティ、オペレーション、コンプライアンス向けの事前にパッケージされたガバナンスルール。予防的と発見的の2種類がある
- Account Factory
事前に承認されたアカウント設定で新規アカウントのプロビジョニングを標準化する設定可能なアカウントテンプレート
- ダッシュボード
料金
マスターアカウントに5USDほど
ktMFA 強制ポリシーについて
IAMユーザーに対してMFAを有効化しない限り、AWSの操作権限を与えないIAMポリシー
Terraformでの設定例：
①template fileとなるjsonを作成
②iam.tfにて、resource "aws_iam_policy"でリソース作成し、policyにtemplateファイルを読ませる
例：
policy = file("${path.cwd}/templates/mfa.json")
③resource "aws_iam_group_policy_attachment" で適用したいグループにアタッチする
例：
resource "aws_iam_group_policy_attachment" "mfa" {
group = aws_iam_group.test.name
policy_arn = aws_iam_policy.mfa.arn
}
参考資料：
ktIAM JSONポリシーの解説
condition：
policyの実行するタイミングの条件を指定できる
principal：
リソースベースのポリシーに割り当てる時に活用する
何にポリシーを当てはめるのか(user、AWSサービス等)を定義する
資料：https://dev.classmethod.jp/articles/aws-iam-policy/
ktIAMの概要説明
Identity and Access Management
どのサービスに対する
どのような操作を
誰に
許可するか、しないかを定義できる
引用元：https://qiita.com/qiita-kurara/items/b6123be16fbbc82bfee6
polic, user, roleの定義
policy :許可、不許可を定義して、userやroleに紐づける
user：policyを紐付けてユーザーができることを定義
role：policyを紐付けて、対象/AWSのサービス で許可・不許可を定義
※対象はuserに限らず、AWSサービスなども該当する
statementの要素
Effect：Allow、Denyを指定
Action：操作内容を定義
Resource：操作の対象を指定
例：
Actionにs3:Getやs3:List
↓
getやlistで始まるactionが利用可能になる (GetObjectとかListBuckets等)
s3の確認しやすい一覧：
引用元：https://dev.classmethod.jp/articles/iam-role-passrole-assumerole/
ktEC2 worker nodeにあるclam avのCPUコア利用率制限
ウイルスソフトの定期スキャンで生じる問題(実際に起こった問題)
- メモリ使用量が増えてしまう
- スキャンが走った際にCPU占有使用してしまう
メモリ使用量が増える
定期スキャンを行うと、スワップ領域を常時数100MB程度使用することになる
↓
スキャン実行時に読み込むウイルス定義ファイルのサイズが数100MBある為
↓
スキャン実行時に他の処理と被る場合はメモリ不足になる恐れ
CPUを占有使用する問題
実行時は1つのCPUをほぼ占有する
CPUが複数あるサーバーであれば他の処理は空いているCPUを使用できるが、
1つしかないサーバーでは、本来の機能に悪影響が出る恐れがある
↓
Cgroupで管理してCPUを節約する
CGroupはLinuxカーネルの機能で、プロセスへのCPU使用時間、システムメモリー、ネットワーク帯域幅などのリソース割り当てを制御することができる
①CGroupの機能が含まれる、libcgroupおよびlibcgroup-toolsパッケージをインストール
yum install libcgroup libcgroup-tools
②CGroupの設定
/etc/cgconfig.conf で、clamscanコマンドのCPU使用時間を制限するグループを定義
cfs_period_us：単一CPUあたりのCGroupで管理する実行時間（マイクロsec）
700,000マイクロsec = 700msec = 70%(1000ミリsecが100%)
cfs_quota_us：そのうちこのグループに所属しているプロセスがアクセスできる時間（マイクロsec）
例：
# vi /etc/cgconfig.conf
group clamscang {
cpu {
cpu.cfs_quota_us = 700000;
cpu.cfs_period_us = 1000000;
}
cpuacct {
}
}
参考引用情報： 改良して使われているスクリプト： Red hutの公式情報：
ktAWS Well Architectedについて
資料：
ktcloud initでログ情報を確認
ユーザーデータ
view /var/lib/cloud/instance/user-data.txt
デバッグの詳細情報
view /var/log/cloud-init.log
output (shの反映はこちらで確認)
view /var/log/cloud-init-output.log
ktAWS CLIのMFA認証設定
①aws sts get-session-tokenコマンドを使用して、一時的セキュリティ認証情報を取得
aws sts get-session-token --serial-number arn:aws:iam::????????????:mfa/username --token-code 6桁の数字
②jsonで払い出された値を環境変数にエクスポート
export AWS_ACCESS_KEY_ID=??????????
export AWS_SECRET_ACCESS_KEY=?????????
export AWS_SESSION_TOKEN=????????
③適用されているか確認する
aws configure list
Name Value Type Location
---- ----- ---- --------
profile <not set> None None
access_key **************** env
secret_key **************** env
region ap-northeast-1 config-file ~/.aws/config
printenv | grep AWS
AWS_ACCESS_KEY_ID=???????????????
AWS_SECRET_ACCESS_KEY=?????????
AWS_SESSION_TOKEN=???????????
ハマった事
ホームディレクトリにて行ったが、terraformを実行したいディレクトリ下で
backend s3にてterraform initを実行したい時に
認証エラーが出て先に進めなかった。
それぞれのディレクトリごとに設定値が違うので、
対象ディレクトリごとに実施して適応させる必要がある
リセット対応
期限が切れたら、下記の対応で既存の登録情報をリセットする事
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN
参考：
ktAurora MySQLのタイムゾーン設定
デフォルトはUTF-8
time_zone「SYSTEM」
system_time_zone「UTC」
UTCが表示
↓
time_zoneが「Asia/Tokyo」
JCTに変わる
ktCodeGuruについて
自動化されたコードレビューとアプリケーションパフォーマンスの
推奨事項を提供する機械学習サービス
アプリケーションのパフォーマンスを損なう最もコストがかかるコード行を見つけ、
一晩中トラブルシューティングを続けるのに役立つ
コードを修正または改善するための具体的な推奨事項を示してくれる
機械学習モデルを利用して行われる
CodeGuru Reviewer と Codeguru Profilerの2つに分かれる
CodeGuru Reviewer
役割
- 修正方法をレコメンドしてくれる自動コードレビューサービス
- リポジトリ内のソースコードをレビュー
- コード内の問題を検出
Codeguru Profiler
役割
- リポジトリ内のソースコードをレビューする
- コードのパフォーマンスをランタイムで常にレビュー
- 推奨項目(CPUなど、必要以上に処理に時間がかかっている箇所を提供)
ダッシュボード
- CPUのレイテンシや使用率のトラブルシューテング
- インフラストラクチャーコスト削減
- パフォーマンス向上
使い方
対象のリポジトリを関連付けてPR、MRを都度作成する
↓
PR、MRに対して推奨事項をコメントとして残してくれる
↓
コードを修正してコメントへフィードバック
カテゴリの推奨事項
- AWS ベストプラクティス
- 並列処理
- リソースリーク
- 機密データの漏洩
- 一般的なコーディングベストプラクティス
- リファクタリング
- インプットバリデーション
- コード品質
料金
コード100行あたり 0.75USD/月
引用資料：
AWS公式ブログ資料：
よくある質問：
kt現在のアカウント CLI確認
aws sts get-caller-identity
{
"UserId": "〜〜〜",
"Account": "〜〜〜",
"Arn": "arn:aws:iam::〜〜〜:user/〜〜〜"
}
organizations管轄のterraformリソース構築でエラーが生じる
Initializing Terraform configuration...
module..aws_iam_user.terraform: Refreshing state... [id=]
╷
│ Error: Failed getting S3 bucket (): Forbidden: Forbidden
│ status code: 403, request id: , host id:
おそらく現在のアカウントと、organizationsのアカウントが違う為
事例：
ktEC2インスタンスタイプに関する資料
ktIAM roleでpricipalを使って対象を指定
公式：
ktassume_role.shの解説
AWSのassume roleを割り当てたい時に用いる
CI/CDで権限を一時付与して実行させる時などに有効
assume_role.sh
#!/usr/bin/env bash
set -xeuo pipefail
aws_sts_credentials="$(aws sts assume-role \
--role-arn "$AWS_DEPLOY_IAM_ROLE_ARN" \
--role-session-name "$ROLE_SESSION_NAME" \
--external-id "$AWS_DEPLOY_IAM_ROLE_EXTERNAL_ID" \
--duration-seconds 900 \
--query "Credentials" \
--output "json")"
cat <<EOT > "aws-env.sh"
export AWS_ACCESS_KEY_ID="$(echo $aws_sts_credentials | jq -r '.AccessKeyId')"
export AWS_SECRET_ACCESS_KEY="$(echo $aws_sts_credentials | jq -r '.SecretAccessKey')"
export AWS_SESSION_TOKEN="$(echo $aws_sts_credentials | jq -r '.SessionToken')"
EOT
解説：
--role-arn arn:aws:iam::000000000000:role/【ロール名】\
--role-session-name【スイッチロールセッション中の名前】\
--duration-seconds【スイッチロールセッション時間 900秒(15分)～最大はIAMの設定次第】`
引用資料：
ktIAMの種類、使い分けまとめ
アイデンティティベース、リソースベースとは?
アイデンティティベースのポリシーは、IAM ユーザー、グループ、ロールにアタッチされます。
リソースベースのポリシーは、リソースレベルのアクセス許可とは異なっています。リソースベースのポリシーは、このトピックで説明しているように、リソースに直接アタッチできます。
Principal
リソースへのアクセスを許可または拒否するプリンシパルを指定する
Principal エレメントを IAM アイデンティティベースのポリシーで使用することはできません。IAM ロール用の信頼ポリシーおよびリソースベースのポリシーで使用することができます。リソースベースのポリシーは、リソースに直接埋め込むポリシーです。
リソースベースのポリシーでは、Principal エレメントを使用して、リソースへのアクセスが許可されるアカウントまたはユーザーを指定します。
IAM ユーザーおよびグループにアタッチするポリシーで Principal 要素は使用しないでください。同様に、IAM ロールのアクセス許可ポリシー内ではプリンシパルを指定しないでください。
このような場合、プリンシパルは暗黙的にポリシーがアタッチされたユーザーとなるか(IAM ユーザーの場合)、ロールを引き受けるユーザーとなります (ロールアクセスポリシーの場合)。ポリシーが IAM グループにアタッチされている場合、そのグループ内のリクエスト元 IAM ユーザーがプリンシパルです。
プリンシパルの指定
プリンシパルを指定するには、次のセクションに示されているように、Amazon リソースネーム (ARN) またはその他のプリンシパル ID を使用します。IAM グループやインスタンスプロファイルをプリンシパルとして指定することはできません
AWS アカウント ID をポリシーでプリンシパルとして使用する場合、そのアカウントに権限を委任します。そのアカウントの管理者は、そのアカウント内の任意のアイデンティティにアクセス権を付与できます。そのアカウントには、IAM ユーザーおよびロールが含まれます。
個々の IAM ユーザープリンシパル
個別の IAM ユーザー（または一連のユーザー）をプリンシパルとして指定することができます。要素で複数のプリンシパルを指定する場合は、各プリンシパルにアクセス許可を付与します。これは論理 OR であり論理 AND ではありません。一度に 1 つのプリンシパルとして認証されるためです
ロールの信頼ポリシーのPrincipal要素に、特定のIAMユーザーを指し示すARN が含まれている場合、その ARN はポリシーを保存するときにユーザーの一意のプリンシパル ID に変換されます。
ユーザーを削除して再作成することにより、誰かがそのユーザーの特権をエスカレートするリスクを緩和できます。
通常、この ID はコンソールには表示されません。これは信頼ポリシーが表示されるときに、ユーザーのARNへの逆変換が行われるためです。
ただしユーザーを削除すると関係が壊れます。ユーザーを再作成してもポリシーが適用されることはありません。これは新しいユーザーには信頼ポリシーに保存されている ID と一致しない新しいプリンシパル ID が付与されるためです。
この場合、プリンシパル ID はコンソールに表示されます。AWS が有効な ARN に ID をマッピングできなくなるためです。
その結果、信頼ポリシーの Principal エレメントで参照されているユーザーを削除して再作成する場合は、ロールを編集して正しくなくなったプリンシパル ID を正しい ARN に置き換える必要があります。ポリシーを保存するときに、ARN は再びユーザーの新しいプリンシパル ID に変換されます。
引用資料：
Resource
ステートメントで取り扱う一連のオブジェクトを指定しますステートメントには、Resource または NotResource エレメントを含める必要があります。
各サービスには、それぞれ一連のリソースがあります。リソースを特定するためには必ず ARN を使用しますが、それぞれのリソースの ARN の詳細はそのサービスおよびリソースによって異なります。
リソース ARN でのポリシー変数の使用
Resource 要素では、特定のリソースを示す ARN の一部 (つまり、ARN の末尾部分) で JSON ポリシー変数を使用できます。たとえば、リソース ARN の一部としてキー {aws:username} を使用することで、現在のユーザー名をリソースの名前の一部として含める必要があることを示すことができます。
class methodのわかりやすい解説
policy
ポリシーは基本的に、
「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」、といったことをJSON形式で記述
記述したポリシーをユーザー(IAMユーザー、IAMグループ、IAMロール)や、AWSリソースに関連づけることで、アクセス制御を実現
ポリシーの分類
ユーザーベースのポリシー
IAMユーザー、IAMグループ、IAMロールに関連づけるポリシーになります。
ポリシーは「誰が」「どのAWSサービスの」「どのリソースに対して」「どんな操作を」「許可する(許可しない)」を記述する、と述べました。 しかし、このポリシーには
「誰が」(つまり、操作する主体)の部分(ポリシーの記述項目で言うとPrincipal)は記述しません
↓
「誰が」は、記述するまでもなくポリシーを関連づけた先のIAMユーザー、IAMグループ、IAMロールになるから
このポリシーを関連づけたIAMユーザー、IAMグループ、IAMロール(IAMロールをEC2インスタンスにアタッチした場合は、EC2インスタンス)が、「誰が」の部分に該当します。
なので、AmazonS3ReadOnlyAccessポリシーを関連づけたIAMユーザー(やIAMグループ、IAMロール)がS3リソースを参照できる
種類：
- AWS管理ポリシー
- カスタマー管理ポリシー
- インラインポリシー
リソースベースのポリシー
関連づける先がユーザーではなく「AWSサービス」
ポリシーの記述内容レベルでの違いは、操作主体を表すPrincipalの有無
ユーザーベースのポリシーの場合、「人(ユーザー、グループ、ロール)」に関連付けるので、操作主体は「関連づけた先のユーザーやグループ、ロール」と暗黙的に決まりました。
一方、リソースベースのポリシーは「モノ(AWSリソース)」に関連づけるので暗黙的には決まらず、「誰が」の部分にあたるPrincipalの記載が必要になります。
S3のバケットポリシーの例
AWSアカウント：777788889999のIAMユーザー：bob」 が 「example-bucket S3バケット配下」に
「操作：PutObject、PutObjectAcl」を「許可する」事を意味しています。
リソースベースのポリシーはS3等の一部のAWSサービスのみに対応しています。 対応しているAWSサービスは IAM と連携する AWS サービス の表において、「リソースベース」がYesになっている行
IAM ロールの信頼ポリシー
IAMロールの権限移譲操作に特化したポリシー
ポリシーを関連づける先(対象)はIAMロール
当該の信頼ポリシーを関連づけたIAMロールが保有する権限を、信頼ポリシーの操作主体であるPrincipalに移譲(を許可)する
「信頼ポリシーを関連づけたIAMロール」に「Principal(主体者)」が(権限的に)なりすませる
例：
AWSアカウント：999988887777 の kawahara ロールの権限
↓
AWSアカウント：123456789012 の IAMユーザー：bob に謙譲許可する
引用資料：
ktAWS SSOについて
SSOはIAMロール(スイッチロール)を使っている。
Management Accountから、各種アカウントのIAMロールに紐づくイメージ
SSOを有効化すると、Management AccountにSSOインスタンスというものができあがる
(現状1アカウント(というか1Oraganization)に1SSOインスタンスしか作れない)
↓
SSO関連のデータを保存している場所
IDストア = ユーザーやグループの格納場所
IDプロバイダ：
割り当て(Assignment)対象のアカウントにISプロバイダというIAMリソースが作成される
権限セットについて
特定の AWS アカウントにアクセスするための、ユーザーの有効なアクセス許可を決定するため、
AWS Single Sign-On が使用する管理者定義のポリシーの集合
AWSServiceCatalogEndUserAccess：
AWS Service Catalog で承認された製品を起動する権限を付与
AWSPowerUserAccess：
AWS のサービスとリソースへのフルアクセスが付与されますが、ユーザーおよびグループの管理は許可されない
AWSAdministratorAccess：
AWS のサービスとリソースへのフルアクセスを付与
AWSServiceCatalogAdminFullAccess：
AWS Service Catalog 製品とポートフォリオを管理する権限を付与
AWSReadOnlyAccess：
すべての AWS サービスのリソースおよびメタデータを閲覧するためのアクセス許可を付与
AWSOrganizationsFullAccess：
AWS Organizations へのフルアクセスを提供
引用資料：
ktPowerUserAccessについて
解説記事：
ktエフェメラルストレージとは
エフェメラルストレージは、「インスタンスストア」という領域に存在する
「インスタンスストアボリューム」のこと
ktAmazon Linux2でyumがこけた時の対応
原因
VPCエンドポイントの設定がされていなかった為
nslookupの結果、名前解決はできている模様
[root@ip-〜〜〜 ec2-user]# nslookup amazonlinux.ap-northeast-1.amazonaws.com
Server: 10.0.0.2
Address: 10.0.0.2#53
Non-authoritative answer:
amazonlinux.ap-northeast-1.amazonaws.com canonical name = s3.dualstack.ap-northeast-1.amazonaws.com.
Name: s3.dualstack.ap-northeast-1.amazonaws.com
Address: 52.219.8.62
Name: s3.dualstack.ap-northeast-1.amazonaws.com
Address: 2406:daa0:4060:1d1:34db:4a7::
対応
VPCエンドポイントを設定
追加サービス：com.amazonaws.ap-northeast-1.s3
VPC、ルートテーブルをSecretのEC2(踏み台経由のWebサーバ)に設定
ポリシー：フルアクセス
ktEC2 Amazon linux2のpython versionを2→3に変更する
以下の記事通りに実行
sudo yum install python3 -y
python3 -V
Python 3.7.10
python --version
Python 2.7.18
echo 'alias python=python3.7' >> ~/.bashrc
source ~/.bashrc
python --version
Python 3.7.10
Amazon Linux2でpip installをすると警告
解説記事：
ktルートテーブルで外部接続用(Nat Gateway)をターゲットに入れ忘れて接続ができなかった事例
前提
- ALB→Nat Gateway→踏み台(public)→webサーバ(private)という流れ
- EC2に入ってRubyをインストールするためcurlでrbenvを入れようとした
- 以下の形で怒られてタイムアウト
curl: (28) Failed to connect to github.com port 443 after 129585 ms: Connection timed out
原因
プライベートサブネット(Webアプリを載せるEC2)のルートテーブル設定で、
Nat Gatewayのターゲットを入れ忘れていた
復旧
送信先：0.0.0.0/0
ターゲット：作成したngw
curl -fsSL http://github.com/rbenv/rbenv-installer/raw/HEAD/bin/rbenv-installer | bash
中略
Installing ruby-build with git...
All done!
EKS nodegroupを削除しようとしたがエラー
deleteとcreateを試したが、以下の内容で怒られた
eksctl delete nodegroup -f 〜〜〜.yaml --approve
2022-01-07 23:20:37 [ℹ] eksctl version 0.77.0
2022-01-07 23:20:37 [ℹ] using region ap-northeast-1
2022-01-07 23:20:37 [ℹ] comparing 1 nodegroups defined in the given config ("〜〜.yaml") against remote state
2022-01-07 23:20:37 [ℹ] 1 nodegroup (eks-study-ng) was included (based on the include/exclude rules)
2022-01-07 23:20:38 [!] stack's status of nodegroup named 〜〜〜 is DELETE_FAILED
2022-01-07 23:20:38 [!] continuing with deletion, error occurred: error getting instance role ARN for nodegroup "": stack not found for nodegroup ""
2022-01-07 23:20:38 [ℹ] will drain 1 nodegroup(s) in cluster ""
2022-01-07 23:20:38 [!] no nodes found in nodegroup "" (label selector: "alpha.eksctl.io/nodegroup-name=eks-study-ng")
2022-01-07 23:20:38 [ℹ] will delete 1 nodegroups from cluster ""
2022-01-07 23:20:38 [!] stack's status of nodegroup named is DELETE_FAILED
2022-01-07 23:20:38 [ℹ] 1 task: { no tasks }
2022-01-07 23:20:38 [ℹ] will delete 1 nodegroups from auth ConfigMap in cluster ""
2022-01-07 23:20:38 [!] removing nodegroup from auth ConfigMap: instance identity ARN "" not found in auth ConfigMap
2022-01-07 23:20:38 [✔] deleted 1 nodegroup(s) from cluster ""
eksctl create nodegroup -f 〜〜〜.yaml
2022-01-07 23:30:42 [ℹ] eksctl version 0.77.0
2022-01-07 23:30:42 [ℹ] using region ap-northeast-1
2022-01-07 23:30:42 [ℹ] will use version 1.21 for new nodegroup(s) based on control plane version
I0107 23:30:44.378115 21295 request.go:668] Waited for 1.316601317s due to client-side throttling, not priority and fairness, request: GET:https://.gr7.ap-northeast-1.eks.amazonaws.com/apis/coordination.k8s.io/v1beta1?timeout=32s
2022-01-07 23:30:46 [ℹ] nodegroup "" will use "ami-" [AmazonLinux2/1.21]
2022-01-07 23:30:46 [!] stack's status of nodegroup named is DELETE_FAILED
2022-01-07 23:30:46 [ℹ] 1 nodegroup (eks-study-ng) was included (based on the include/exclude rules)
2022-01-07 23:30:46 [ℹ] will create a CloudFormation stack for each of 1 nodegroups in cluster ""
2022-01-07 23:30:46 [ℹ]
2 sequential tasks: { fix cluster compatibility, 1 task: { 1 task: { create nodegroup "" } }
}
2022-01-07 23:30:46 [ℹ] checking cluster stack for missing resources
2022-01-07 23:30:47 [ℹ] cluster stack has all required resources
2022-01-07 23:30:47 [ℹ] building nodegroup stack ""
2022-01-07 23:30:47 [ℹ] 1 error(s) occurred and nodegroups haven't been created properly, you may wish to check CloudFormation console
2022-01-07 23:30:47 [ℹ] to cleanup resources, run 'eksctl delete nodegroup --region=ap-northeast-1 --cluster= --name=<name>' for each of the failed nodegroup
2022-01-07 23:30:47 [✖] creating CloudFormation stack "": AlreadyExistsException: Stack [] already exists
status code: 400, request id:
Error: failed to create nodegroups for cluster ""
解決方法
公式の下記の記事より、マネコン→CloudFormation→スタックから選択して削除を試行
以下の記事のようにエラーが出たが、再試行で削除に成功
ktパラメータストアの回覧権限付与
例：
パスワードの回覧権限を特定のユーザー向けに付与したい時に設定する
iam-policy-develop.json.tplのようなtplファイルに、
以下の記述を追記する
{
"Effect": "Allow",
"Action": [
"ssm:Get*"
],
# 単体の場合
"Resource": "arn:aws:ssm:*:*:parameter/〜〜〜"
},
# 複数ある場合
"Resource": [
"arn:aws:ssm:*:*:parameter/〜〜〜",
"arn:aws:ssm:*:*:parameter/〜〜〜"
]
},
jsonのバリデーションチェックには、
awsのjsonに構文をコピーしてチェックすると有用
ktAmazon EC2のスケジュールイベントの開始時間を変更
参考記事：
ktSid":"AddPermで指定されたプレフィックスにパブリック読み取り権限を付与する
次のバケットポリシーは、特定のプレフィックスの下にあるすべてのオブジェクトに対してパブリック読み取りアクセス権を付与します。このバケットポリシーを使用する前に、ユースケースがプレフィックス内のパブリックに読み取り可能なすべてのオブジェクトをサポートしていることを確認します。
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AddPerm",
"Effect":"Allow",
"Principal": "*",
"Action":["s3:GetObject"],
"Resource":["arn:aws:s3:::DOC-EXAMPLE-BUCKET/publicprefix/*"]
}
]
}
引用公式記事：
ktAWS プリンシパルの設定解説
公式：
ktRoute53 ルーティング設定について
複数値回答ルーティングポリシー
複数値を問い合わせ元に返せる設定
一度に返せるIPは８つまで
登録できるIPは8つ以上も可能
8つ以上登録された場合はヘルスチェックで検証された正常なレコードをランダムに8つ返す
公式より
ヘルスチェックを複数値回答のレコードと関連付けている場合、
Route 53 はヘルスチェックの結果が正常である場合にのみ
DNS クエリに対応する IP アドレスを返します
ヘルスチェックを複数値回答レコードと関連付けない場合、
Route 53 は常にレコードを正常であるとみなす
8 つ以下の正常なレコードがある場合、Route 53 はすべての DNS クエリに
正常なすべてのレコードを返す
すべてのレコードが異常である場合、
Route 53 は DNS クエリに最大 8 つの異常なレコードを返す
加重ルーティングポリシー
複数のリソースを関連付け、加重をつけてルーティングさせる
計算：
レコードの重み / 全てのレコードの重みの合計
サーバーAに10、サーバーBに30と設定した場合
↓
サーバーAには1/4のトラッフィクが行く
引用記事：
公式：
kt加重ポリシーの設定方法について
Amazon Route 53 では加重レコードを設定することができます。
特定の名前やタイプ (例えば、名前が www.example.com で、タイプが A) に対して、
最大 100 の代替応答を設定することができ、それぞれに重みを設定できます。
www.example.comのクエリへ応答する場合、
Route 53 DNS サーバーは重みが設定されたランダム応答を選択
DNS リゾルバーに返します
重みが 2 の加重レコードの値は、
重みが 1 の加重レコードの値よりも平均 2 倍の頻度で返されます
100 を超すエンドポイントにトラフィックを振り分ける場合は、
加重エイリアスレコードと加重レコードのツリーを使用する方法があります。
例えばツリーの最初の「階層」を最大 100 個の加重エイリアスレコードとし、
その各レコードでそれぞれに最大 100 個の加重レコードを指定できます。
Route 53 では、再帰レベルは最大で 3 まで可能であり、
最大 1,000,000 個の一意の加重エンドポイントを管理することができます。
引用資料：
Route53の加重ルーティング機能は、同一レコード名で登録し、
重み (Weight) を各レコードで設定する事で
その重みに応じた割合でリクエストを振り分けることができます
振り分け方法はラウンドロビン方式です。
片方の重みを0にする事で設定したレコードへリクエストが振り分けられなくなり、
もう片方のレコードに全てのリクエストが振り分けられるようになります
レコード名 ルーティングポリシー 重み ルーティング先
hoge.example.com 加重 30 EC2用のALBドメイン
hoge.example.com 加重 70 ECS用のALBドメイン
引用資料：
手順：
レコード名：一緒にする
値：振り分けたいIPをそれぞれ設定
ルーティングポリシー：加重
レコードID：一意の命名をつける
重量：割合で設定 10:90 10%：90%
引用資料：
kts3のパス形式について
パス形式(path-style)： V1
http://s3.amazonaws.com/<bucket-name> （バージニアのみ）
http://s3-ap-northeast-1.amazonaws.com/<bucket-name>
注：
バケット名にピリオドを含むことは可能ですが、
https で利用されている場合、仮想ホスト形式では
SSL ワイルドカード証明書(*.s3.amazonaws.com)に一致しないため、
標準のままでは利用することができません
仮想ホスト形式(virtual hosted–style): V2
http://<bucket-name>.s3.amazonaws.com
http://<bucket-name>.s3-ap-northeast-1.amazonaws.com
引用資料：
公式：
ktAWS 権限系メモ
AWS グローバル条件コンテキストキー
アクセスポリシーを定義する際に、条件(Conditions)という要素を使用して、特定の要求が満たされた場合にのみポリシーが適用されるように設定できる
Key, Operator, Valueの組み合わせて指定する
プリンシパルのプロパティ
条件キーを使用してリ、クエストを行うプリンシパルの詳細をポリシーで指定したプリンシパルのプロパティと指定する
リソースベースのポリシー
リソースベースのポリシーはリソースに直接アタッチする
リソースベースのポリシー：
一部のAWSサービスをサポート
リソースレベルのアクセス許可：
ARN を使用してポリシー内で個別のリソースを指定する機能
PrincipalOrgID
リクエスト元のプリンシパルが属する AWS Organizations の組織の識別子と、ポリシーで指定された識別子を比較する
組織内のすべての AWS アカウントのすべてのアカウント ID を一覧表示する代わりに使用できる
SourceOrgPaths
サービス間リクエストを行っているリソースのAWS Organizationsパスを、ポリシーで指定した組織パスと比較 (AWSサービスプリンシパルによって実行された場合に限定)
キーがリクエストコンテキストに含まれるのは、組織のメンバーであるアカウントが所有するリソースに代わって、AWSサービスプリンシパルが直接リソースを呼び出している場合のみ
※PrincipalがAWSのサービスプリンシパルであるリソースベースのポリシーでのみ使用する
SNSでの使用例
Amazon S3バケットの更新によってAmazon SNSトピックの公開がトリガーされる
↓
Amazon S3サービスはsns:Publish API 操作を呼び出す
↓
sns:Publish操作を許可するトピックポリシーで、条件キーの値をAmazon S3 バケットの組織パスに設定
参考：
ktSNS概要
概要
Pub/Subメッセージングサービス
プッシュ型のメッセージや通知を設定して送信する
機能
<メッセージング>
- Pub/Sub
- メッセージ配信
- メール、SMS、HTTP/HTTPSエンドポイント、Lambda、SQSといったプロトコルとサービス宛にメッセージを配信
- トピック管理
- メッセージングの論理的なアクセスポイントやチャンネルとして、トピック作成して管理する
- ファンアウトパターン
- 単一の送信操作で複数のエンドポイントに対して並列にメッセージを送信可能
ファンアウトは、メッセージが1対多の配置でブロードキャストされるメッセージングパターン
ファンアウトとは、サービスやメッセージルーターが複数のユーザーにメッセージを配信すること
https://medium.com/@pubnub-localized/ファンアウト-ソフトウェアとは-7cd3f02d8afa#:~:text=ファンアウトとは、サービス,数を意味します。
使用例：
- 非同期通信
- ユーザー通知
- モニタリングとアラーム
- ワークフローの自動化と統合
注意点
FIFOを利用して、メッセージの順序性を保ち、メッセージの重複を防止する
↓
FIFOトピックをサブスクライブできるのはSQS FIFOキューのみ
KMSを利用して暗号化することができる
↓
以下暗号化対象外
- トピックのメタデータ
- メッセージのメタデータ
- トピックごとのメトリクス
ベストプラクティス
ユーザー、アプリケーション、またはサービスがそのタスクを遂行するために必要な権限のみを付与する
-
トピックの権限管理 (パブリックアクセス可能でないようにする)
- Principalを""に設定してポリシーを作成しない
- ワイルドカード (*) を使用しない
-
最小特権アクセスの実装
アクセス権限を受け取るユーザー、アクセス許可の対象となるトピック、およびこれらのトピックに対して許可する特定の API アクションを決定する
- Amazon SNS アクセスを必要とするアプリケーションと AWS のサービスには IAM ロールを使用する
IAM ロールを使用して、Amazon SNSにアクセスする必要があるアプリケーションまたはサービスの一時的な認証情報を管理することが推奨
-
保存時の暗号化を使用して、メッセージを保存する場所とは別の場所に保存されているキーを使用してメッセージを暗号化する
-
送信時のデータ暗号化を強制
- HTTPSによる暗号化 (HTTPの通信を禁止)
HTTPS 経由の暗号化された接続のみを実行するには、aws:SecureTransport 条件を、暗号化されていない SNS トピックに添付されている IAM ポリシーに追加する
- VPC エンドポイントを使用して特定の VPC 内のホストのみにトピックアクセスを制限する
- インターネットに絶対に公開してはならないトピックがある場合に設定する
公式： Lambda関数へのファンアウト
class method：