birdpixyさんの投稿一覧

ちょっとご質問と外れてるかもしれませんが

２．元々プライマリだったDBインスタンスがスタンバイに変更

障害の発生したDBインスタンスがスタンバイに変更されるでしょうか？
障害が発生したら利用不能になるので、スタンバイにはならないのではないのかなと思いました。
元のプライマリDBインスタンスがどのような挙動をしているかの資料が見つからなかったのですが、どこかに載っていましたか？

CloudFormationとElastic BeanstalkはどちらもAWS環境を自動的に構築できるサービスですが、それぞれ下記のような特徴があります。

CloudFormation
・インフラ環境をコード化して各AWSリソースを構築する
・コードの書き換えによって、細かいカスタマイズが可能
・複数の環境をまとめて管理できる

Elastic Beanstalk
・基本的にAWSが用意したインフラ環境の中から選択する
・CloudFormationよりも容易に構築が可能な分、柔軟なカスタマイズはできない
・インフラの専門的知識を持たない人でも、AWS環境の構築が可能

設問の「この環境は企業の部署ごとに個別に用意する必要がある」ことから、WordPress環境を部署ごとにカスタマイズする要件があることが分かります。
Elastic Beanstalkは前述のとおり、AWSが容易したインフラ環境の中から選択するので、部署ごとの細かいカスタマイズしたい要件には適していません。
一方、CloudFormationでは部署全体の共通コードを作成し、部署ごとに異なる部分のみコードを書き換えるだけで対応できます。

各サービスの作成画面だけでも触ってみると理解が深まると思います。
最後のデプロイさえしなければ料金もかからないので。

このサイトの構成図が分かりやすかったです。
https://dev.classmethod.jp/articles/trasfer-for-sftp-endpoint-types-202004/#toc-10

①VPCエンドポイントとは、インターネットに晒されることなく、S3のようなVPC外のサービスとVPC内とを繋ぐサービスではなかったでしたっけ。
(VPC外の)Transfer FamilyとVPC内とを繋ぐなら理解できますが、AWSの外にいるユーザーがVPCエンドポイントに接続する、という構成がピンと来ません。
実際にはインターネットゲートウェイも必要なのでしょうか。

インターネットゲートウェイからパブリックサブネットを通って、VPCエンドポイントへ接続しているようです。

②あわせてもう1点確認させてください。
ACLがサブネットに適用されるのに対し、セキュリティグループはEC2インスタンスのような個々のリソースに適用されるのですよね。
この構成では、セキュリティグループをVPCエンドポイントに適用する、ということでしょうか。

セキュリティグループをVPCエンドポイントに適用する、で合っていると思います。