ことの発端は、とあるサイトが提供しているサービスから静的コンテンツ(画像)を無断で大量にダウンロードしていることなのですが、まぁセキュリティ的に甘かったことは否めません。
しかし、クラウドのメリットをど返しして対応するには自分としては勘弁してほしい。 なにか方法はないか模索している。
もしかしたら、解決策があるかもしれない。
これまでAWSのS3から配信していた画像へ加工を加えて配信する 簡単に言うと画像をアクセスしに来た方専用に加工する必要があるのです。
私なりに考えてみました。
現状が
NET━ELB━EC2━RDS
┗━━━S3
という構成ですが、EC2はRDSに保存されているS3の画像パスをHTMLに埋め込みクライアントから直接S3へアクセスさせる。
これを
NET━ELB━EC2━RDS
┗━━S3
としてEC2側でS3からオリジナル画像を取得して加工し、EC2のローカルへディレクトリに保存してローカルパスをHTMLに埋め込む これはEC2の負荷が高くなり加えてS3からの画像取得や加工で時間がかかるだろうなぁ
次に考えたのが
NET━ELB━EC2━RDS
│
┗APIGateWay━Lamdba
│ │
┗S3━━━━━━┛
図をおこせばいいのですが、ブログなので、すいません。簡単にご説明するとEC2で受け取ったリクエストに対してAPIGateWayへ画像取得リクエストを送信するAPIGateWayはLamdbaを動かし画像加工を行いS3へ画像加工後のファイルを格納し画像のパスをEC2へ返す。返ってきたパスをHTMLに埋め込みクライアントへ返す。
私はPGの知識がないので簡単に書いてますけど大丈夫なのか？ これはAWSに詳しい方にお聞きします。
やっぱり安全牌な構成としては
NET━ELB━EC2━RDS
┗ELB━EC2━S3
かなぁ あらかじめS3から画像を取り出しておいて、上段のWebサーバから画像のリクエストがあったら加工を加えてEC2のローカルに保存して画像のパスをWebサーバに返してHTMLに埋め込むクライアント側からはELB経由で画像にアクセスしてもらう。
ん これが安全牌なのか？
ここで想定される懸念としては加工した画像ファイルをいつまでも保存しておけないこと、S3を保管場所としては考えるなら無制限だけど(お金はかかる)それにEC2の場合はディスク容量は限られる。なので、暫くすれば溢れ出す。
定期的に1時間や半日 毎日で加工後の画像ファイルを削除しなければいけない これもディスクのIOに負荷がかかるだろうなぁ〜 いずれにせよ やはりアンチクラウドパターンだから無理が出るよね。
どうしたものか？
誰か助けてください。
