主に自分用のメモです。情報の共有を目的としていません。
模擬問題の復習をつらつらと書き連ねていく
WebサーバーとDBインスタンスでサブネットが分かれていて、WebサーバーにAutoScailingが設定されている場合、DBインスタンスのインバウンド通信ルールにはIPアドレスではなく、セキュリティグループのIDを指定すると、Webサーバーの増減でIPアドレスが変わっても、変わらずに通信ができる ようになる。
EC2インスタンスにELBやRoute53を構成していると、特定のEC2インスタンスに障害が発生した際に、ダウンタイムを最小にして待機系インスタンスに切り替えることができます。その際にホスト名を待機系のIPアドレスに向け直すと、DNS情報が伝播するまでに一定のダウンタイムが発生する可能性があります。
これを防止するためには、IPフローティングを利用してElastic IPアドレスをフローティングすることで即時に別のEC2インスタンスへとトラフィックを切り替えることができます。 これによって、障害発生時には稼動系からElastic IPアドレスを外し、待機系インスタンスに割り当て直すことで瞬時にトラフィックの向け先を変更できます。
異なるAWSアカウントが有するリソースへのアクセスを委任する方法として、クロスアカウントアクセス許可とIAMロールを設定することが必要です。これによって、特定のアカウントにある特定のリソースを別アカウントのユーザーと共有します。クロスアカウントアクセスを設定することで、利用者はアカウントごとに IAM ユーザーを作成する必要がなくなります。
EC2で本番環境と開発環境で開発者に異なる権限を与えたいとき、例えば開発環境は削除権限を与えるが、本番環境には与えない、といったときにはタグを活用する。
タグによって「本番インスタンス」と「開発インスタンス」を定義するメタデータをインスタンスに追加します。次に、ユーザーに対してIAMポリシーによってアクセス権限を付与する際に、これらのタグに基づいて開発者の利用範囲を分けます。これによって、タグベースで本番用インスタンスを操作するユーザーと、開発用インスタンスを操作するユーザーに権限を分割することが可能となります。
IAMポリシーはサービス単位でアクセス権限を拒否するため、開発者が開発用インスタンスも削除できなくなってしまいます。
ステートフル処理用のインスタンスは、クライアントとWebサーバー間の接続時にはセッションがアクティブである限りデータベースが使用されたままになるため、分散システムに適していません。
暗号化を自動的に実行しているサービス
AWS Storage GatewayとS3(Glacier)
しないサービス
Amazon RDS, Lambda, ECS
Amazon Aurora は、標準的な MySQL データベースと比べて最大で 5 倍、標準的な PostgreSQL データベースと比べて最大で 3 倍高速化することが可能なリレーショナルデータベースです。 したがって、Amazon RDS for MySQLよりも、Amazon Aurora for MySQLの方が高可用性やスケーラビリティを高めることが可能
リザーブド購入オプションは以下のようなものがあります。
・EC2リザーブドインスタンス
・RDSリザーブドインスタンス
・ElastiCacheリザーブドキャッシュノード
・DynamoDBリザーブドキャパシティ
・Redshiftリザーブドノード
VPC間の接続の違いについてはこちら
1.VPC peering
2.AWS Transit Gateway
3.Software Site-to-Site VPN
4.Software VPN-to-AWS Managed VPN
5.AWS Managed VPN
6.AWS PrivateLink
VPCエンドポイントとAWS PrivateLinkの違い
Config Inspector GuardDutyの違い
AWS WAF, AWS Shield, and AWS Firewall Manager の違い