AWS

https://gyazo.com/909e6c9c7e5603926488fcbdff9d9d56

AWS 1日目に行う作業

ルートアカウントの利用の停止

MFA をアクセス要件にする

請求レポートを有効にする

基礎

スケーリング

Tips

暗号化

AWS Well Architected

目標

アーキテクチャの評価/改善ができる

設計がビジネスに与える影響を理解できる

目的

アーキテクチャのベストプラクティスに対する認識を向上させる

無視されがちな基礎的分野への対応

一貫性のある原則でアーキテクチャを評価する

どのようなものか

AWS エキスパートによる一連の質問事項

それらの質問事項を設計に投げかけ、評価する

基本的に日本語版は古いので、英語版を参照するのが良い。

TODO

具体的なネットワーク設計例を書く

フェデレーションについてまとめておく

メモ

後ほどまとめる予定のもの

ワークロードを分ける、すなわち、S3 に同じリージョンの別アカウントにすれば同じリージョンの S3 にアクセスさせないようにできる

NAT ゲートウェイの可用性をあげるために、AZ ごとに NAT ゲートウェイを立てると良い

gard duty

トップドメイン？CNAME？エイリアス？DNS...

耐障害性は高可用性のサブセット

耐障害性はエラーを 0 に近づける

高可用性は利用不可時間を (エラーが発生しても) 0 に近づける

Direct Connect の効果妖精は、契約数を増やす

VPN 接続と併用する

複数契約する

別会社で契約する

同じ会社の別の場所で契約する

lambda

Auto Scaling が増減させることができるのは EC2 インスタンスのみ

Docker コンテナ等は lambda から増減させるのが良い？ -> ECS が行なってくれるので別に

Auto Scaling の制約としては、アラームの仕組み内でしか動作しない。複雑なメトリクスの変化に合わせてスケーリングするには、lambda が選択肢に入ってくる

lambda 自体はスケーリングするので、置き換えるのもあり

Lambda とスケーリング

インフラストラクチャを疎結合にすると、

スケーリングしやすくなる

耐障害性が上がる

結合点には、高い可用性/拡張性が必要となる。そのため、そういった場所には AWS のマネージド型のサービスを利用する。

例えば、多数の EC2 インスタンスが各々みつ結合しているのはアンチパターン。ELB を介して各々アクセスするようにできると良い。このとき、ELB が落ちると全てダメになるが、ELB は高い可用性がある

SQS について

cloudWatch で SQS の中身を監視して、それにトリガーして Auto Scaling する。Auto Sclaing は ELB が必須というわけではない

分散キューの苦しみを知っておく必要がある。

ポーリングが基本

Amazon SNS

SQS と同様に、メッセージングのサービス

メッセージをトピックに対して発行し、クライアントはそれを Subscribe する

Sbscribe/Publisher モデル

メッセージを Sbuscriber に push できる

ActiveMQ

EC2 にインストールして利用できるが、マネージド型の方が良い

これが Amazon MQ

標準的なメッセージングプロトコルを活用できるのが特徴。

SQS や SNS ではこれができない

ステートをどこに保存しておくか？

Neptune

EMR

質問

Blue/Green Deployment を CloudFormation や CodeDeploy 等を組み合わせて行いたい場合、Code Pipeline 等を利用するのが良いのか？

AMI から EC2 インスタンスを立ち上げ、デプロイを行い、CNAME を切り替えたい場合、どうやって実現するのが良い？

CodeDeploy は ELB がないと Blue/Green Deployment ができない

例えば、例に出ていた CloudFormation を利用した手順は、どのように自動化すべき？

バケットポリシー等と IAM ロールの使い分け

利用される側とする側のどちらに設定するか、という違いのみ？

インスタンス/RDS 間の暗号化は、 VPC 内部のみでのやりとりの場合はやらなくてもよい？

EC2 インスタンス/ELB 間の暗号化もいらない？

assume role api は、role の arn が分かっていれば、誰でも叩けてしまう？