AWS 勉強メモ
クラウドコンピューティングとは
オンデマンドでインターネット経由かつ従量制の料金で提供されるサービス
クラウドになり、ハードウェアをソフトウェアに置き換える事ができる様になった
これにより柔軟な対応が可能になった。
一時的なものや、検証などをすることが必要なくなった
IaaSとPaaSの違い
OSとミドルウェアを指定できるかできないか
-
IaaS
EC2など
乗っけるOSは選択出来るAmazon Linux, Debian
そこから自分でDBなどのミドルウェアを導入していくことができる。 -
PasS
RDS, S3, Herokuなど
OS、ミドルウェアなどは既に決まっている状態
AWSの課金の3要素
- コンピューティング
- ストレージ
- データ転送
AWSに保存される受信データ転送は無料
同リージョン内のサービス間のデータ転送も無料
※例外あり
総所有コスト - Total Cost Ownership
TCOはクラウドをオンプレミスに置き換えたときの全体のコストの予算を出す、財務予測
AWSサポート
AWS Trusted Advisor
自動的に月々の費用の削減やリソース確保などが可能かどうか診断してくれる
aws
ケースと応答時間
プランに応じて緊急事態があった場合、サポートの対応が~時間までと決まっている
AWS Organizations
- 複数のAWSアカウントのアクセスポリシーの一元管理
- AWSのサービスへのアクセス制御
- AWSアカウントの作成と管理を自動化
- 複数のAWSアカウント間での一括請求を有効にする
IAMとの違いは、IAMはより特定のサービスへの権限の設定ができること
ex) s3:CreateBucketへのAPIを制限する
Organizationsはサービスコントロールポリシー(SCP)を使用して、特定のAWSサービスへのアクセスの許可/拒否を設定出来る。
IAMとOrganizationの違い
IAMポリシーはあくまで、AWSのサービスのみに適用し、AWSアカウントにまでは適用できない
OrganizationによるSCPは、有効範囲がAWSアカウントにまで及ぶ。ルートユーザーもこれの対象外ではない。
また一括請求なども管理できることにより、組織上のAWSアカウントに対しての一元管理をすることが可能。
SCPとIAMアクセス許可ポリシーは類似する構文が使用されるが、SCPによりアクセス許可が付与されず、最大アクセス許可が指定される。
最大アクセス許可???
つまりこういうこと
「ざっくりとした」制限をSCPで実施し、細かい制御をIAMで実施する、というアプローチが適切かと思います。
AWS Cost Explorer
時間経過に伴うAWSのコストと使用状況を可視化して、過去三ヶ月〜翌月の予測数値を表示することが出来る。
AWS Budgets Cost Explorerによるコストの可視化を使用して、予算の状態を表示し、コスト予測を可能にする。
予算を設定してアラートやメールを通して通知することが可能
AWSリージョンの選択
-
データとガバナンス
情報は地理的境界で保存するように法律で定められている場合があります。
たとえば、EUのデータ保護規則(GDPR)など -
レイテンシーの低減
ユーザーやシステムになるべく近い場所の方がレイテンシーは上がる
CloudPingでレイテンシーのテストをすることが出来る。 -
運用コスト
微妙に値段が違ったりする。
アベイラビリティゾーン
各AWSリージョンにはアベイラビリティゾーンと呼ばれる、複数の独立したロケーションが存在する。
アベイラビリティゾーンはそれぞれに電源があり、物理的に分離されています。
距離は100km以内です。
すべてのアベイラビリティゾーンは冗長化された専用回線を介して、アベイラビリティゾーン間に高スループットを提供します。
ネットワークはアベイラビリティゾーン間で、同期レプリケーションを実行します。
そのためAZは高可用性のアプリケーションに構築に役立ちます。
※高可用性
システムやサービスなどが故障、停止することが少ないこと。
Amazon CloudFront, Route 53はレイテンシーを低減するために、自動的に最寄りのエッジロケーションにルーティングされる。
POP(Point Of Presence)は世界30か国の主要都市に設置されている。
POPとはパフォーマンスなどを継続的に測定して、低レイテンシーを期待する。
CloudFront Route 53 AWS Shield WAFなどのサービスで使用される。
リージョン別エッジキャッシュはCloudFrontでデフォルトで使用されて、アクセス頻度が高くなく、エッジロケーションに置く必要がないコンテンツにたいして、オリジンサーバーの代わりにそこから取得出来るようにする
AWS責任共有モデル
責任範囲をカスタマーとAWS側で分ける。
AWS側の責任
データセンターの物理的なセキュリティ
ストレージの廃棄やOSでのアクセスログの記録/監査
ネットワークにおける侵入検知
仮想化における、各インスタンスの分離
カスタマーの責任
- EC2内のOSのメンテナンス
- アプリケーション
- セキュリティグループ
- OSとホストベースのファイアウォール
- ネットワーク設定
- アカウント管理
IAM
ベストプラクティス
最小権限の原則に従う
ポリシーはJSONで管理を行う
-
アイデンティティベースのポリシー
IAMユーザー、グループ、ロールに付与できるポリシー -
リソースベース
S3バケットなど
明示的な拒否は許可よりも優先される
- 優先順位
明示的な拒否→明示的な許可→暗黙的な拒否
なにも明示的な許可が存在しない場合においては、拒否が優先される
AWSルートユーザー
必要な場合以外ルートユーザーを使用するのは極力やめる。
ルートユーザー上でIAMユーザーを作成して、ルートユーザーのアクセスキーなどは削除して、ルートユーザーの認証情報などは安全な場所に保存しておく
AWS CloudTrail
CloudTrailはアカウントのユーザーアクティビティを追跡する事ができる。
監査のドキュメント作成などにも役に立つ
AWS KMS
暗号化キーの作成/管理が可能
Amazon Cognito
ウェブ or モバイルアプリケーションにサインアップ、サインイン、アクセスコントロールを追加する。
AWS Shield
DDoSから保護するマネージド型サービス
AWS Shield Standardは追加料金なしで使用可能
データの保護
AWS KMSのシークレットキーで暗号化が可能
コンプライアンス
AWS Config
コンプライアンスの監査とセキュリティ分析を簡素化する
AWS Artifact
レポートをオンデマンドでDLすることが可能