AWS-SysOps試験対策まとめ｜アーキテクトアソシエイト、ディベロッパーアソシエイト、SysOps三冠目指して

アーキテクトアソシエイト、ディベロッパーアソシエイトととった勢いで、SysOpsもとってコンプリートしたい気持ちになり受検を決めました。と早速日程を見に行くと現行の試験は9月23日で終了ですと出てくるではないですか。なんとか23日までに予約して本当はもっと余裕を持って試験を受けたかったのですが２週間程で受けることになりました。

暫定的でも試験範囲のまとめをあげていきます。参考になれば幸いです。

VPC

各サブネットは、一つの AZ にマップします。
デフォルトで、プライベート又はパブリックに関わらず、すべてのサブネット間でルートは可能です。
外部ネットワークとの接続性を提供するコンポーネントは
Internet Gateway (IGW)、Virtual Private Gateway (VGW)の２つです
1.VPC にインターネット・ゲートウェイ (IGW) があること
2.インスタンスには、関連付けられた Elastic IP (EIP)があること
3.適切なセキュリティ・グループ・ルールが設定されていること
★4.ルーティング・テーブルの設定いること
の順で確認すると良いでしょう。
ICMP ping を使用して、アプリケーション・インスタンスのネットワーク 到達可否を確認する必要などで
ICMP ping のみパスするように、インスタンスのセキュリティグループを設定する場合
モニタリング・インスタンスのセキュリティグループは送信 ICMP を許可し、
アプリケーション・インスタンスのセキュリティグループは受信 ICMP を許可する必要があります

・IP アドレスがハードコーディングされているレガシー・アプリケーションを変更なしでフェールオーバーしたい。

1.フェールオーバー・インスタンスに移動可能なセカンダリ ENI を作成します。
2.フェイルオーバー・インスタンスに移動可能なプライマリ ENIO に、
セカンダリ・プライベート IP アドレスを割り当てます。

・指定された IP アドレスブロックからのアクセスを一時的に拒否する方法は?

VPC 内のすべてのパブリックサブネットに関連付けられているネットワーク ACL を変更して、
IP アドレスブロックからのアクセスを拒否します。

ELB

Connection Draining を設定した際、未処理リクエスト・トラフィックを
継続する時間はデフォルトで300秒です
既存の ELB に新しいゾーンを追加するコマンドは
enable-availability-zones-for-load-balancer
逆に削除は
elb disable-availability-zones-for-load-balancer
となっています
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/classic/enable-disable-az.html
・危険と表示されたインスタンスは終了されない
ELB によって危険であると表示されたトライヤルインスタンスを確実に終了し、
交換するにはAuto Scaling グループに Elastic Load Balancing ヘルスチェックを追加する方法があります。

・事前に設定した顧客 IPアドレスからのトラフィックだけ受け入れる
1.ELB の”X-forwarded-for”ヘッダーに基づきトラフィックをフィルタするように Web サーバーを設定します。
2.顧客の IP からのトラフィックを許可し、すべての送信トラフィックを拒否するように ELB セキュリティグル ープを設定する

#Auto Scaling
Auto Scaling launch configurationでインスタンス・タイプを変更できます。
最小負荷を処理するのに必要なサーバは6つのリザーブド・インスタンス(重度使用)。
日次単位の最大台数と最小負荷分の台数の「差分」は 6つのオンデマンドインスタンス、
年間の局所的な増加台数はスポット・インス タンスでカバーします。

EC2

あらかじめ定義された プライベート IP アドレスが割り当てる必要がある場合は
Amazon virtual Private Cloud (VPC) でインスタンスを起動します。
EC2 インスタンスの管理者権限で実行すべきサービスは
Amazon Elastic Map Reduce AWS Elastic Beanstalkであり
EC2 インスタンスでフル管理者権限が必要な場合、これらのサービスを使用します。
・Termination protectionとShutdown behavior
EC2 インスタンスの終了保護を有効にし、インスタンスによって起動されたシャットダウン動作を
設定した場合もユーザーが OS のインスタンスをシャットダウンした場合インスタンスを終了します。

あれっと思いますよね。実はどちらもコンソール上の操作に対する設定だからです。
「終了保護」とはEC2ダッシュボードでのEC2を誤操作による削除（terminate）から守ってくれる機能です。
CloudFormationでDisableApiTerminationプロパティをtrueにしておけば忘れずに済みます。
「インスタンスによって起動されたシャットダウン動作の変更」はシャットダウン時の挙動について、
「停止」か「削除」かを選択できるというものです。デフォルトは「停止」です。

・CloudWatchとの連携
EC2 システムとインスタンス・ステータス・チェックに基いて CloudWatch アラームを設定し、
監視用インスタンスで検知された問題点をアラームで操作チームに通知するように構成すると
EC2 ベースの Multi-tier アプリケーションを構築した際にアプリケーションの問題をメールやSMSて
オペーレーションチームに通知できます。

・S3との連携
m1.small EC2 インスタンスから、同じリージョンにある Amazon S3 にデータをアップロードする時、
ネットワーク・スループットがボトルネックになる場合、より大きなインスタンスへ変更する必要があります。

・NoSQLとの連携
ノードごとに4KBブロックサイトで最大100,000 IOPS のランダム読み取りI/Oディスクパフォーマンスが
必要となっている場合は High I/O Quadruple Extra Large (hi1.4xlarge)インスタンス・ストレージを使用します。

・EC2 コンソールを確認すると、システムステータスチェックは”故障”と示しSSHもwebアクセスもできなくなった
正常ホストシステムにて再配置するように、インスタンスを停止及び開始します。

・内部監査を受け、一つのインスタンスに専有ハードウエアが必要であると判断されたが影響を最小にするには？
インスタンスを停止し、AMI を作成し、tenancy=dedicated で新しいインスタンスを起動し、元のインスタンスを終了します。

＃Elastic Beanstalk
・開発者をログファイルのみにアクセスさせるために、管理者はどうすればよいか
ログファイルを S3 にローテーションするように Elastic Beanstalk を設定します。

EBS

バックアップに基いて可能な限り最短時間で新しい AZ でボリュームを再作成できるようにする
→
EBS ボリュームのスナップショットを定期的に取ります。
EBS スナップショットの作成中(進行中)でもEBS ボリュームは使用可能です。
EC2 EBS-backed (EBS root) インスタンスが停止された場合、
ストア・ボリューム上のデータは削除され、アクセスできません。
違いに注意しましょう。
インスタンスストアボリュームの仮想デバイスは ephemeral[0-23] ] です。
・セキュリティについて
まずアクセス権を制限するためボリュームの読み取りと書き込みアクセス権を制限する
IAM ポリシーを作成します。
EBS ボリュームに保存されているデータはAES-256 アルゴリズムを使用して
データキーでボリュームを暗号化が可能です

・Provisioned IOPS EBSの利用
EBSへ永続的データを保存するデータベースを EC2 インスタンス上で実行した際にディスク・ボリュームて
゙待機時間が多く発生する場合は、以下を検討してみてください。
1.データベースを EBS 最適化インスタンスに移動します。
2.Provisioned IOPS EBS を使用します。

S3

オブジェクトは URL 経由で直接アクセスできます
S3 は事実上無制限数のデータを保存できます
S3 バケットで、パブリックオブジェクトにアクセスする時 IP アドレスブロックが発生しないようにするには
バケットポリシーを作成し、それをバケットに適用する方法がよいでしょう

・S3 バケット ACLの注意点
Canonical user groupは事前定義済みグループを使用して、オブジェクトにACL を付与できません

・S3-Backed AMI によりバックアップされている EC2 インスタンスが終了したとき、
root ボリューム上のデーターはは自動的に削除されます。

#ElastiCache
・セッションやキャッシュを管理した際にEvictions と GetMisses が非常に高くなる。
1.クラスタ内のノード数を増やします
2.クラスタ上内のノードのサイズを大きくします

Route 53

Amazon route 53 のエイリアスレコードを使用します。

SQS

顧客オーダーと同じ順序で処理したいなどの要望にはメッセージのシーケンス情報を使用すれば対応できます。

Cloudwatch

以下のような時系列変化のグラフを表示したい場合はCloudWatch CLI ツールを使用して、
各リージョンのエンドポイントから関連メトリックを取得し、グラフ 表示用に、
CloudWatchでデータ集約及び保存する必要があります。
・すべての EC2 インスタンスの平均 CPU 使用率(Avg CPU Utilization)
・すべての DynamoDB テーブルの調整されたリクエストの数(Number of Throttled Requests)

OpsWorks

BackEndDBサーバーを OpsWorks stack に追加す方法は
・新しいデータベースレイヤーを追加し、レシピをデータベースおよび
App Server レイヤーのデプロイメント アクションに追加します。
・RDS データベース接続情報のホスト、ユーザなどの変数は、deploy JSON の
[:depioy][:app_name][:database] 属性からそれぞれ対応する値を使用して設定します。
・カスタムレシピを使用して app サーバと RDS レイヤ間の接続を設定します。
一般的に構成ファイルを作成す ることにより、レシピは必要に応じてアプリケーションサーバーを設定します。
レシピは、AWS OpsWorks がすべてのインスタンスにインストールしているスタック設定と
デプロイメント JSON の属性セットから、ホスト名 とデータベース名などの接続情報を取得します。

IAM

RDS にアクセスするためのポリシーを作成する場合、
root アカウント所有者は、IAM ユーザー用のポリシーを作成し、
RDS サービスへのアクセス権限を付与します。
・アクションのセットアップとアクセス権限の注意
CloudWatch のアクセス権のみのIAM ユーザーで「CPU 使用率が限界値を下回ったときに
EC2 インスタンスを停止するアラーム」アクションをセットアップをセットアップした場合
ユーザーはアクションをセットアップできますが、ユーザーがEC2権限を持っていないため実行はされません。
IAM ユーザーに S3 バケットのフルアクセス権を付与しそのユーザーでログインした場合、
ACLを使用してIAMユーザーにアクセス権を付与することができません。

・「AWS アカウント ID:xyzxyz、グループ名：service」の時、AWS ログイン URLは？
https:// xyzxyz.signin.aws.amazon.com/console/となります。

・アップロードした人にそのオブジェクトに対するアクセス権限を管理させるのと同時に、
誰でもオブジェクトをアップロードを可能にしたい
誰にでもオブジェクトをアップロードできるようにバケットで ACL を使用する必要があ ります

Webサービスへの課題解決

人気ある記事へのトラフィック増加により、サイトがダウンする
→
・記事の配信用に、CloudFront を活用します。
・RDS への読み取りトラフィック用に、RDS リードレプリカ(英文:read-replicas)を追加します。
・最も頻繁に使用されるデータをキャッシュするために、ElastiCache を活用します。

・インフラストラクチャの大部分はオンプレミスであり AWS上の新しいアプリはLDAP 接続を必要とする
データセンターと AWS 間に VPN 接続を確立し、AWS 上に LDAP レプリカを作成し、
認証用に LDAP レプリカを使用するようにアプリケーションを設定します。

・異なるバージョンのインフラストラクチャをコピーしたり、過去のバージョンに戻したり、
現在どのバージョンが稼働しているかを判断できるようにしたい
AWS CloudFormation と Git のようなバージョン管理システムを使用して、
インフラストラクチャを展開及び 管理することを提案します

・複数リージョンでの画像表示サービスをスピードアップできる方法
ルート 53 のレイテンシーベースのルーティングを使用し、us-east-1 と同じようにus-west-2 でも
画像表示サービスを提供するようにし、 さらにCloudFront を経由して画像をロードします。

AWS

・セキュリティ
root アカウント及び特権 IAM ユーザーに対して MFA を設定します。(これは絶対やりましょう)
必要最小限のアクセス権限を付与するポリシーを、IAM ユーザおよびグループに割り当てます。

・コンプライアンス評価
1.IT オペレーション・コントロールの証拠を収集します。
2.第三者が監査した AWS コンプライアンス・レポート、および認定資格を要求および取得します。
3.ネットワーク・スキャンの実行及び、お使いのシステム・インスタンスとエンドポイントに対して、
侵入テストを実施するように、AWS にリクエストし、承認を得ます。
こちらの公式アナウンスにもあると通りhttps://s3.amazonaws.com/awsmedia/AWS+Auditing+Security+Checklist+Whitepaper_Japanese.pdf
テスト予定日の少なくとも 7 営業日前までにリクエストを提出してください。リクエストが詳細であればあるほど、すぐに承認される可能性が高くなります。
十分な詳細情報が提供されない場合、AWS がリクエストを拒否することもあります。
加えて米国への申請であることも考慮すると安全確実でいうなら10日前ぐらいがいいことになります。
(実際メールで急ぎの旨を書けば３営業日位で対応してくれることもありますが余裕を持って準備しましょう。)
セキュリティに関してもう一つのトピックとしては、
IP スプーフィングまたはパケット・スニフィングから守ることは「AWS」の責任範囲だそうです。

追加できたら追加していきます。

参考：Amazon S3 のバケットのアクションに設定できるアクセス許可のリストです

バケットポリシーは読めるようにしましょう。

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/using-with-s3-actions.htmlからの抜粋ですがIAMのポリシーとごっちゃになりやすい私には重宝します。

以上です。参考になりましたら幸いです。