AWS SAA対策メモ（EC2, Lambda & IAM編）

SAA対策の自分用のメモ。
7/13にSAA合格

SOA対策の自分用のメモ。
どんどん更新して加筆修正していく予定。

EC2

インスタンス起動時にパブリックIPアドレスを自動振り分けするか、無効にするのか選べる
パブリックIPアドレスはECインスタンスを再起動すると変わる
EC2の課金はrunningの時のみ

プライマリプライベートIPアドレス
最初に付与するプライベートIPアドレス
指定しなくても自動割り当て
EC2インスタンスを削除しない限りずっと同じ

セカンダリプライベートIPアドレス
ENI(Elastic Network Interface)をEC2にアタッチすることで、を割り当てることができる。
取り外し自由であり、他のEC2インスタンスにも付け替え可能

• オンデマンドインスタンス

デフォルト。初期費用などなし。従量課金。

• リザーブドインスタンス　
  1 or 3年間、最大75%引き、全額／一部前払いか前払いなしで割引率は変わる。

  • スタンダード
    リージョンやAZを指定、その中でなら配置転換可能。他へは手続きが必要。
  • コンバーティブル　インスタンスファミリーの変更が可能。割引率は低い
  • ☆スケジュール

• ☆スポットインスタンス
  最大90%割引、希望額の時のみ起動でき、逆にそうでないときは強制終了となる。処理が中断してもOK、再実行が可能なシステムに使用。

  • スポットブロック　予め決められた時間の起動を保証（最大6時間）、処理の中断を避けられる。
  • スポットフリート
    予め指定した性能キャパシティを満たすように構成してくれる。１つのインスタンスが終了しても、また別の同性能のインスタンスを起動し、維持してくれる。

• ハードウェア占有（Dedicated Instance）
  専用のホストコンピュータであるが、配置するホストコンピュータを指定することはできない
  プライベートアドレスは必ずつく。再起動しても変わらない。

• 専用ホスト（Dedicated Host）
  ホストコンピュータにはIDが付与されており、使用可能な任意のホストコンピュータでEC2起動可。ユーザーがホストコンピュータを選ぶこともできる。
  可視性と制御性をアップ。
  BYOL（Bring Your Own License）が可能。
  企業のコンプライアンスが厳しいとこれを使う。

ユーザーデータ
インスタンス初回起動時に１回だけスクリプトを実行できる
プレイスメントグループ単一AZ内のEC2インスタンスを論理的にグルーピング。高速処理可能。クラスターコンピューティング向き。

インスタンスメタデータ
インスタンス固有のデータ。
curl https://IPアドレス/latest/meta-data/インスタンスIDで確認できる。
また、上記コマンドでシェルスクリプトに入れて何らかの作業の自動化も可能。

クラスタープレイスメントグループ
１つのAZ内のEC2インスタンスグループであり、インスタンス間で低レイテンシー

スプレッドプレイスメントグループ
高い可用性がある

インスタンスタイプはなるべく最新の世代を使う

T2/3はバースト可能パフォーマンスインスタンス。通常は低負荷で、稀に高負荷なアクセスとなるシステムで使用。

ベースラインパフォーマンス
予めインスタンスごとに決められたCPUリソース使用率。これを下回るとCPUクレジットは蓄積され、上回るとクレジットは消費される。この消費部分をバーストという。追加でクレジットを購入し、性能の低下を防ぐためにUnlimitedというオプションがある。

ハイバネーション
インスタンスを休止し、その時のインメモリの内容をディスクに退避、次回起動時にそのメインメモリを展開して休止前と同じ状態で起動（データは消えない）。これにより、EC2の起動が早くなる。

AMIはどちらか選ぶ
EBS-Backed インスタンス→データを永続保存可能（こっちが主流）
Instance store-Backed インスタンス→一時的に保存

セッション情報をEC2保持すると、ステートフルになり、スケールできない。セッションを保存するためにElastiCacheやDynamoDBを使う。これにより、AutoScalingをしてもセッション情報は保持される。

試験ではあまり垂直スケーリングは問われない。CPUアップグレードをしても、コスパや可用性には関係がないから。

Lambda

コードで実行できるサーバーレスコンピューティング
イベントドリブンなので、他のサービスと連携しやすい（S3やCloudWatch Events、API Gatewayなど）
実行するコード ＝ Lambda関数
従量課金（リクエスト量と処理量）
オートスケーリング可能
実行時間の上限は15分間で、大量のデータのバッチ処理には不向き
イベントをトリガーにして、短い時間で処理を行うのに適している。

• Pullモデル
  アプリケーションからストリーム(DynamoDBストリームなど) へイベントを発行し、Lambdaはそのストリームからイベントを取り出し、コードを実行

• pushモデル
  ユーザのアプリケーションからLambdaへ向けてイベントを発行し、コードを実行します。たとえば、S3でバケット通知をLambdaへ向けて設定して、コードを実行。Pushモデルは3回リトライを実行。

レイテンシー対策にSQSを使用
コールドスタートなので、急増したトラフィックに対応できないかも？

IAM

IAMユーザーはIAMグループに入れてからIAMポリシーで権限付与
最小権限の原則、必要最低限の権限のみ付与する
IAMユーザーのデフォルト権限はなし

IAMポリシーの種類

• AWS管理ポリシー
  AWSによって定義されているポリシーのテンプレート
  例 PowerUserAccess IAM以外全てへのアクセス権限を持っている

• カスタマー管理ポリシー
  ユーザーが自身で作成・カスタマイズするポリシー

• インラインポリシー
  IAMユーザーなどに埋め込まれたポリシーに対して、ポリシー設定を個別に反映

☆IAMロール
AWSリソースの操作権限をAWSのサービスやアプリに付与する。
アクセスキーIDやシークレットアクセスキーによる認証より、IAMロールを用いた認証が推奨されている

スイッチロール
あるIAMユーザーが異なるAWSアカウントの管理を行うためにアクセスする。管理される側のAWSアカウントでIAMロールを作成し、それをアタッチする。

AWS organizations

複数のAWSアカウントを一元管理する。
OU（組織単位）で管理
マスターアカウントとメンバーアカウント

Cognito

モバイル／webアプリユーザーのサインアップ／インなどのCognito Identity認証を行う。

ユーザープール
ユーザー名とパスワードで直接サインインする

Identityプール
FBやGoogleなどを介してサインインする

Federated Identity
複数のIDプロバイダー（TwitterやGoogleなど）のアカウント情報をIdentityとして管理する（フェデレーション）

IDプロバイダ
SAMLベース
Facebook, Twitter, Googleなど
OpenID Connectベース
Salesforceなど。Cognito経由でアクセスできる。

SSO(Single Sign-0n)

オンプレのActive DirectoryをSSOに接続し、オンプレと同様にユーザーIDとパスワードを使ってAWSにアクセス。
Security Assertion Markup Language(SAML)2.0もサポートしているので、BoxやOffice365などの連携も簡単