AWSSAA~最重要サービス~
はじめに
インフラエンジニア初学者のぽれいんと申します。
※このブログでは自分が後々、見返すことができるようにまとめることを目的としていますが、もし需要があるようでしたら是非ともご覧ください。
<前回の記事>
<参考>
AWS IAM（ユーザーアクセスと暗号化キーの管理）| AWS
今回のやりたいこと
AWSソリューションアーキテクトアソシエイトの学習のためにAWSのサービスで最重要なサービスを簡単にまとめたいと思います。需要があればご覧ください。
IAM
AWS Identify and Access Management(IAM)では、AWSのサービスやリソースへのアクセスを安全に管理できる。IAMを使用すると、AWSのユーザとグループを作成および管理し、アクセス権を使用してAWSリソースへのアクセスを許可および拒否できる。
ポイント
- 利用者ごとのIAMユーザ作成
- 最小権限の原則
- AWSリソースからのアクセスにはIAMロールを使う
利用者ごとのIAMユーザの作成
AWSにはアカウント作成時に作られたAWSルートアカウントがある。AWSルートアカウントは、利用者の追跡やアクセス制限が難しいため、原則として通常の運用には使わない。ユーザごとにIAMユーザを発行し、パスワードポリシーや多要素認証（MFA）を設定する。ユーザ本人しか利用できないようにすることで誰がリソースを操作したか追跡できるようになる。（操作の追跡にはCloudTrailを利用し、設定履歴の確認にはAWS Configを利用。）
最小権限の原則
IAMユーザやIAMロールは必要な操作権限を最小限に付与することが重要。たとえば、通常の開発者にはネットワークの操作権限は不要で、運用者にはインスタンスの起動停止のみで十分な場合が多い。業務で必要な権限以外を与えないことで、万が一アクセス権を奪われても被害を最小限に抑えることができる。
AWSリソースからのアクセスにはIAMロールを使う
IAMロールは、AWSリソースなどサービスに対して付与できる。たとえば、EC2インスタンスにロールを付与することでインスタンスのプログラムからAWSを操作できるようになる。プログラムにIAMユーザのアクセスキー・シークレットキーを付与すると、キー流出の危険性は高くなる。できる限りロールを使用する。
VPC
Amazon virtyual Private Cloud(VPC)は利用者ごとのプライベートなネットワークをAWS内に作成する。VPCはインターネットゲートウェイと呼ばれるインターネット側への出口を付けることで直接インターネットに出ていくことが可能。また、オンプレミスの各拠点へ繋げるために仮想プライベートゲートウェイを出口として、専用線のサービスであるDirect ConnectやVPN経由で直接的にインターネットに出ることなく各拠点と接続することも可能。（VPC内に配置できないサービスとしてS3やCloudWatch、DynamoDBなどがある。）
EC2（＋EBS）
Amazon Elastic Conpute Cloud（EC2）は仮想サーバを提供するコンピューティングサービス。インスタンスという単位でサーバが管理され簡単にサーバを構築することが可能。そのため、オンプレミス環境に比べてサーバ調達のリードタイムを非常に短くできる。また、インスタンス性能を決めるほかの重要な要因として、ディスク機能であるElastic Block Store（EBS）がある。EC2では通常の通信で使用するネットワーク帯域とEBSで使用する帯域を共有している。そのため、ディスクI/O、外部とのリクエストともに多く発生する場合、帯域が足りなくなることがある。このようなときに利用できるのがEBS最適化インスタンス。
EBSのボリュームタイプ
EBSのボリュームタイプはSSDが2種類、HDDが2種類の4種類ある。
※旧世代のマグネティックと呼ばれるHDDのストレージタイプもあるが、新規で作成する際は現行のボリュームタイプから最適なものを選ぶ。また、各タイプの性能を最大限活かすにはEBSへのアクセスを最適化したEC2インスタンスの利用がおすすめ。
汎用SSD
「汎用」という名前が示すとおり、EBSの中で最も一般的な、SSDをベースとしたボリュームタイプ。EC2インスタンスを作成する際のデフォルトのボリュームタイプとしても利用される。性能の指標としてIOPSを用いて31IOPS/GBから最大16,000IOPS/ボリュームまで容量に応じたベースライン性能がある。1TB未満のボリュームには、一時的なIOPSの上昇に対応できるようにバースト機能が用意されており、容量に応じて一定期間3,000IOPSまで性能を向上させることができる。このベースライン性能やバースト機能を用いても必要なIOPSを満たすことができない場合は次のプロビジョンドIOPSの利用を検討する。
プロビジョンドIOPS SSD
プロビジョンドIOPSはEBSの中で最も高性能な、SSDをベースとしたボリュームタイプ。RDSやEC2インスタンスでデータベースサーバを構成する際など、高いIOPS性能が求められる際に利用する。IOPSの高いユースケースと高いスループットが必要なユースケースの両方に適したストレージタイプ。
スループット最適化 HDD
スループット最適化HDDはHDDをべーすとしたスループット重視のボリュームタイプ。ログデータに対する処理やバッチ処理のインプット用ファイルなど大容量ファイルを高速に読み取るようなユースケースに適している。スループットを性能指標として用いており、1TBあたり40MB/秒、最大で500MB/秒のベースライン性能がある。
Cold HDD
Cold HDDは4つのストレージタイプの中でストレージとしての性能はそれほど高くないが最も低コストなボリュームタイプ。利用頻度が少なく、アクセス時の性能もそれほど求められないデータをシーケンシャルにアクセスするようなユースケースやアーカイブ領域の用途に適している。1TBあたり12MB/秒、ボリュームあたり最大250MB/秒のベースライン性能がある。
ELB（＋Auto Scaling）
Elasstic Load Balancing（ELB）は3タイプのロードバランサーがある。
- Classic Load Balancer(CLB)
- Application Load Balancer(ALB)
- Network Load Balancer(NLB)
ELBの特徴
マネージドサービスであるELBを用いるメリットとして、ELB自体のスケーリングが挙げられる。EC2インスタンス上にロードバランサーを導入する場合は、そのインスタンスがボトルネックにならないように設計する必要がある。それに対してELBを用いた場合、負荷に応じて自動的にスケールする設定になっている。だが、スケーリングは瞬時に完了するわけではないことに注意が必要。急激な負担増（スパイク）が予想できる場合は、事前にELBプレウォーミングの申請が必要。もう一つELBの大きな利点としてヘルスチェック機能がある。ヘルスチェックは、設定された間隔で配下にあるEC2にリクエストを送り、各インスタンスが正常に動作しているかを確認する機能。もし、異常なインスタンスが見つかったときは自動的に切り離し、その後正常になったタイミングで改めてインスタンスをELBに紐付ける。ヘルスチェックには下記の設定値がある。
Auto Scaling
Auto Scalingはシステムの利用状況に応じて自動的にELBに紐づくインスタンスの台数を増減させる機能。インフラリソースを簡単に調達でき、不要になれば、使い捨てできるクラウドならではの機能。Auto Scalingには下記の設定項目がある。
RDS(Aurora)
Relational Database Service(RDS)はAWSが提供するマネージドRDBサービス。MySQL,MariaDB,PostgreSQL,Oracle,Mycrosoft SQL Serverなどのオンプレミスでも使い慣れたデータベースエンジンから好きなものを選択できる。さらにAmazon Auroraという、AWSが独自に開発したクラウドのメリットを最大限活かした新しいアーキテクチャのRDSも提供されている。バックアップやハードウェアメンテナンスなどの運用作業、障害時の復旧作業はAWSが提供するマネージドサービスを利用することで複雑になりがちなデータベースの運用を、シンプルかつ低コストに実現できる。
マルチAZ構成
マルチAZ構成とは、1つのリージョン内の2つのAZにDBインスタンスをそれぞれ配置し、障害発生時やメンテナンス時のダウンタイムを短くすることで高可用性を実現するサービス。以下の2点は利用時に注意
- 書き込み速度が遅くなる
- フェイルオーバに60~120秒かかる
リードレプリカ
リードレプリカとは、通常のRDSとは別に、参照専用のDBインスタンスを作成することができるサービス。2021年現在、すべてのデータベースエンジンでリードレプリカを利用可能。読み込みが多いアプリケーションにおいてDBリソースのスケールアウトを容易に実現することが可能。
Aurora
AuroraではDBインスタンスを作成するとともにDBクラスタが作成される。DBクラスタは1つ以上のDBインスタンスと、各DBインスタンスから参照するデータストレージで構成される。データストレージは、SSDをベースとしたクラスタボリューム。各ストレージ間のデータは自動的に同期され、また、クラスタボリューム作成時に容量を指定する必要がなく、Aurora内に保存されるデータ量に応じて最大64TBまで自動的拡張される。Auroraは他のRDSと異なりマルチAZ構成オプションはない。しかし、Auroraクラスタ内に参照専用のレプリカインスタンスを作成することができる。Auroraは他のRDSのリードレプリカとの違いAuroraのプライマリインスタンスに障害が発生した場合にレプリカインスタンスがプライマリインスタンスに昇格することでフェイルオーバーが実現する。
S3+S3 Glacier
Amazon S3は非常に優れた耐久性を持つ、容量無制限のオブジェクトストレージサービス。ファイルストレージとの違いとしては、ディレクトリ構造を持たないフラットな構成であることや、ユーザが独自にデータに対して情報を付与できることが挙げられる。
S3 の各オブジェクトには、RESTやSOAPといったHTTPをベースとしたWeb APIを使ってアクセスする。利用者がデータを保存するために利用するだけでなく、EBSのスナップショットの保存場所として使われるなどAWSのバックエンドサービスにも使われる。
ストレージクラス
- S3標準
- S3標準-低頻度アクセス
- S3 1ゾーン-IA
- S3 Intelligent - Tiering
- S3 Glacier
- S3 Glacier Deep Archive
ライフサイクル管理
S3に保存されたオブジェクトはその利用頻度に応じてライフサイクルを定義することができる。以下の二つのアクションを選択できる。
- 移行アクション
- 有効期限アクション
バージョニング機能
バージョニング機能を有効にすると、1つのオブジェクトに対して複数のバージョンを管理することができる。バージョニングはバケット単位で有効/無効を指定できる。バー叙任うされたオブジェクトは差分管理されるのではなく、新・旧の両方が保存されバージョンIDで区別されるため、両バージョン分の保存容量が必要。
Webサイトホスティング機能
S3では静的なコンテンツに限って、Webサイトとしてホスティングする環境を作成できる。静的コンテンツのリソースは通常のS3の利用と同様に、S3バケットへ保存することで行える。
S3のアクセス管理
S3のアクセス管理にはバケットポリシー、ACL、IAMが使える。バケットポリシーはバケット単位でアクセスを制御する。そのバケットに保存されるオブジェクト全てに適用されるので、バケットの用途に応じた全体的なアクセス制御をするのに有効。ACLはオブジェクト単位で公開/非公開を制御する場合に使用。IAMでの制御はユーザ単位でS3のリソースを制御する場合に使用。
以上！！！！！！！！！！！！
