Akamai利用側からAWSを考える 株式会社オズビジョン ハピタス事業部SREチーム 横地秀　shigeru yokochi 2018/10/26

1. CDN and WAF
Akamai利用側からAWSを考える
株式会社オズビジョン
ハピタス事業部SREチーム
横地秀 shigeru yokochi
2018/10/26

2. speaker
• 横地 秀 ( shigeru yokochi)
• 株式会社オズビジョン
• ハピタス事業部SREチーム責任者
• 情報セキュリティ責任者
• HomePage：https://yokochi.jp
• Qiita：https://qiita.com/shigeru-yokochi
• GitHub：https://github.com/shigeru-yokochi
• Facebook：https://www.facebook.com/shigeru.yokochi

3. アジェンダ
テーマについて
AkamiとAWSの基本構成
AkamaiのCDNとWAFを導入するまで
効果
AWSのCloudFrontとWAF＆Shieldとの比較
まとめ

4. テーマについて
CDN and WAF
Akamai利用側からAWSを考える
弊社のサービス「ハピタス」のシステム基盤はAWSですが、AkamaiのDNS、
CDN、および、WAFを使用しています。
AWSなのになぜ？
ということも含めて、導入から現在に至るまでをまとめてみました。
※重要：あくまでも本資料は個人の見解であり所属する組織の公式見解ではありません。

5. AkamaiとAWSの基本構成
AkamaiもAWSも構成はほぼ同じ
DNS FastDNS Route53
CDN DSD※ CloudFront
WAF KSD WAF & Shield
※ハピタスの場合

6. AkamaiのCDNとWAFを導入するまで
CDN導入理由
2011年
・サーバ負荷によりサイト
が頻繁にダウンしている状
況を解消したかった。
負荷を下げる対策の一つと
して導入検討
2012年11月
ドル箱→ハピタスへリニュー
アル
Amakaiでの不具合はないため
継続利用
2011年オンプレからAWSへ
移行
・サーバ負荷対策として効
果が高いと判断した画像フ
ァイルに対してCDNを導入
・東京リージョンには
CloudFrontはなかったため
Akamaiを採用

7. AkamaiのCDNとWAFを導入するまで
WAF導入理由
2015年、
・PC/SPサイトをCDN化
・ZoneApex(hapitas.jp)のためAWSのRoute53からAkamaiのFastDNSへ移行※
・WAFルール設定カスタマイズ
（誤検知対策）
2014年、脆弱性診断結果対策
として導入を決めた。
ソフトウェア改修も検討したが進
行している開発への影響が少なく
て実施できることも考慮した
※エッジサーバのFQDNをCNAMEで登録したいがZoneApexは登録できない。RFC1912 https://www.ietf.org/rfc/rfc1912.txt
動的に割り当たるエッジサーバのIPをAレコードエイリアスとしてZoneApexに設定する必要があるのでRoute53ではなくFastDNSへの移行が必要

8. AkamaiのCDNとWAFを導入するまで
Rout53からFastDNSへの移行(ZoneApex(hapitas.jp)に対応するため)
NSレコード切り替え
FastDNS
レジストラ

9. AkamaiのCDNとWAFを導入するまで
PC/SPサイトをCDN+WAF化(DNSレコード変更)
FastDNS
CDN
WAF
hapitas.jp alias ELB
FastDNS
HTTP_X_FORWARDED_FOR
hapitas.jp alias CDN-edge
origin.hapitas.jp cname ELB
アプリ側で使用している、HTTP_X_FORWARDED_FOR の値がCDNエッジサーバ
のIPになってしまうため、エッジサーバが付与するHTTP_TRUE_CLIENT_IPを取得す
るようにアプリ側の改修が必要
HTTP_TRUE_CLIENT_IP
導入前
導入後

10. AkamaiのCDNとWAFを導入するまで
Client IPは優先度を付けてX_FORWORDED_FORでもTRUE_CLIENT_IPでも取得可
能にする。
優先度
①TRUE_CLIENT_IP
②CLIENT_IP
③X_FORWORDED_FOR
④REMOTE_ADDR

11. AkamaiのCDNとWAFを導入
ここで導入は完了。
大変だったことは
・WAF導入時のDNS変更やPC/SPサイトのCDN化をサービス無停止での実施
・TRUE_CLIENT_IPへの変更箇所が多かったため検証に時間がかかったこと
楽だったこと
WAFの設定（特に除外設定）についてはAkamaiのサポートがあったこと

12. AkamaiのCDNとWAFを導入
WAFの除外設定（ルール約250中約10%に除外設定）

13. 効果
CDN
これは画像サーバの例なのでオフロードは100%近くになっています。
PC/SPについては動的な部分が多く現状ではオフロード率10～20％程度です。
WAF導入目的でのCDNなのでOKとしますが、折角CDN化になっているので、オフロード
率を向上することも考えていきたいです

14. 効果
CDNオリジンサーバ負荷（EC2 m1.small 2台）
これは画像サーバ（オフロードは100%近く）です。
エッジサーバからほとんど配信されている場合はここまで負荷は低減できます。
※もしかしたら今では静的なオリジンサーバはS3+CloudFrontのほうがよいかも。

15. 効果
WAF
trigger：(32,840+88,092)/175,172,738 ≒ 0.07%
block：32,840/175,172,738 ≒ 0.02%
最近1か月のPCサイト/モバイルサイトの合計
blockしているのは0.02% 件数だと約8,500件（283件/日,5分で1件）

16. 効果
WAF
Inbound Anomaly

17. 効果
レートコントロール（上：PCサイト 下：モバイルサイト）
同一IPから一定時間内にアクセスされた回数が設定値を超えるとブロックされます

18. AWSのWAF & Shieldとの比較
Akamai AWS
費用 高 低
運用スキル 多少必要 必須
誤検知対策 あり 可能なはずだが。。
SLA(CDN) 100% 99.9% (8.76H/年)
運用 Akamai側 利用者側
セキュリティ 高
(参考サイト) https://stratusly.com/cloudfront-
vs-akamai/
中
管理画面 使いにくい 使いやすい
ログ分析 Akamai側に依頼することが多い 容易(CloudWatch)

19. まとめ
・AWSはマネージドルールや、レートベースルールなどが追加され機能面でAkamaiと同等になりつつあ
る
・予算よりパフォーマンスやセキュリティを重視するのであればAkamaiで間違いない
・素早いデプロイが必要なサービスではエッジサーバの数が多いAkamaiではなくAWSという選択もある
・どちらを導入するかは、サービス戦略や運用に合わせたリスクとコストを試算して導入したい
・セキュリティ知識が乏しいと結局のところ安いほうに行ってしまいそう。弊社はAkamaiとAWSの両方
を扱える状況は幸せ

20. ご清聴ありがとうございました
• Thank you！ 横地 秀