AWS構築のハマりポイントを詳しく解説 / Cloud on the BEACH 2016

Cloud on the BEACH 2016 ษڧձͷ෦ʢܦݧऀ޲͚τϥοΫʣ AWS構築のハマりポイントを詳しく解説！栄野川直⽃斗(@enkw_̲)
2016.04.29

⾃自⼰己紹介 ☁ 栄野川直⽃斗（えのかわなおと） ☁ サポートエンジニア ☁
新卒⼆二年年⽬目 ☁ クラウドゆとり世代 ☁ ⼀一応JAWS-‐‑‒UG沖縄コアメンバー

ɹɹɹɹɹɹʹ͍ͭͯ

AWSを活⽤用しながらビジネスに集中できるコンシェルジュサービス

24時間365⽇日定額課⾦金金/ 請求書払い PCI DSS、ISMS、Pマーク取得済みの運⽤用体制監視運⽤用保守企業 AWS

(1,500⽇日間) ※ 2010年年5⽉月cloudpackサービススタート 36,000時間連続稼働 (※)

4 社社超プロジェクト超 500 600 5年年間 5年年間AWSのみで運⽤用保守

アジア地域4社世界28社最上位パートナープレミアコンサルティングパートナー

企業規模別 cloudpack利利⽤用⽐比率率率 36% 27 37 % % 中⼩小企業中堅企業⼤大企業

Web系 91 ％うち33%がソーシャルゲームやメディアサイト cloudpackͷओͳར༻状況

ࠓ೔͓࿩͢͠Δ͜ͱ

Α͘ݟΔ͋ͷߏ੒

͜ΕΛ

Πν͔Βߏங͢Δ࣌ͷ ྲྀΕͱ͔ϋϚΓϙΠϯτΛ σϞ΋ަ͑ͳ͕Βղઆ͠·͢ʂ

Ͱ͸ͬͦ͘͞

1. ্ݶਃ੥

1. 上限申請 ☁ ⼀一番最初に上限申請をしましょう • スケールすることを想定 • けっこう忘れがち
☁ 想定より多めで申請した⽅方がいいかも • EC2インスタンス数 • EIP数 • メール上限 / 逆引き

1. 上限申請（ハマりポイント） ☁ 上限申請をし忘れる • 急なスケールアウトに対応できない • EIP
を Allocate できない • Email の送信制限にかかる • ドメインがメールのブラックリストに登録される

2. VPC

2. VPC ☁ CIDRは余裕をもって • スケールすることを想定 • サービスが開始した後に変更更するのは難しい
☁ 注意点 • オンプレミスや他クラウドとのVPN接続がある場合 • ネットワークアドレスが被らないように

2. VPC（ハマりポイント） ☁ CIDRの範囲が狭すぎた • 任意のサブネットにインスタンスがローンチできない • VPC/EC2の再構築が必要
☁ オンプレミスとネットワークアドレスが被った • VPN接続ができない • VPCの再構築が必要

3. IAM

3. IAM ☁ IAM Role を作成しましょう • IAM Role
is EC2 に紐紐付ける認証情報 ☁ 各 Role（役割）ごとに Role を作成しましょう • web / app / db / cache • AWS の API を利利⽤用する予定がなくても作成 • 権限を渡さない設定も可能

3. IAM（ハマりポイント） ☁ IAM Role を作成していなかった • EC2 に
IAM Role を設定しなかった • IAM Role は後からEC2に追加することができない • EC2 で AWS の API を使⽤用するのにアクセスキー/ シークレットアクセスキーの発⾏行行が必要 • キーを流流出するリスクが発⽣生

4. Security Group security group

4. Security Group ☁ EC2 を作成する前に作成しましょう • 複数の SG
をアタッチすることがあるため ☁ SSHのポートは必ず接続元IP制限を⾏行行いましょう • 第三者にアクセスされる可能性があるため ☁ 共通⽤用と役割ごとの SG を作成する • 次のページでオレオレルールを晒します

4. Security Group ☁ 共通⽤用の SG は EC2 全台に設定
• SSHポートなどを解放 ☁ それ以外は役割ごとの SG を各リソースに設定 • elb は 80 / 443 • web は elb からの 80 のみ • db は web からの 3306 のみなどなど..

4. Security Group（ハマりポイント） ☁ 適切切な SG を設定しない • ELB
や RDS に 22番ポートを解放してしまう • 美しくない • SG のルールが煩雑になる • ルール変更更の際に事故が起きる可能性がある

5. EC2

5. EC2 ☁ 作成した VPC/Subnet に配置しましょう • 指差し確認ホント⼤大事
☁ IAM Role の設定を忘れないように • 役割に応じた IAM Role を設定 ☁ Private IP は指定しておきましょう • 指定しないと AWS から⾃自動的に割り振られる

5. EC2 ☁ EBS の Delete on Termination は無効化した⽅方が無難
• インスタンスを削除した際に EBS も消えちゃう ☁ Security Group は適切切に設定しましょう • 各ロールの SG をアタッチする

5. EC2（ハマりポイント） ☁ ローンチする VPC/Subnet を間違える • スケールできない
• インスタンスの再ローンチ ☁ IAM Role を設定し忘れる • AWS の API を使⽤用できない • インスタンスの再ローンチ

6. ELB

6. ELB ☁ 作成した VPC/Subnet に配置しましょう ☁ Load Balancer
name はドメイン名で • enokawa-‐‑‒co-‐‑‒jp とか ☁ SSL 証明書は ELB に設定しましょう • Apache/Nginx などに設定するのはリスク • OpenSSLの脆弱性とか

6. ELB（ハマりポイント） ☁ Load Balancer name に適当な名前をつける • 何⽤用の
ELB か分からなくなる ☁ ローンチする VPC/Subnet を間違える • 適切切な EC2 を紐紐づけられない

7. RDS

7. RDS ☁ Parameter Groups はデフォルトを使わない • Parameter Groups
is MySQLの my.cnf みたいなもの • インスタンス作成後に変更更ができない（要再起動） • デフォルトの Parameter Group は編集ができない ☁ RDS は基本的に Private Subnet に配置すること • インターネットからアクセスできないようにするのがベター

7. RDS ☁ Backup Window と Maintenance Window •
タイムゾーンが UTC になっているので注意 ☁ Auto Minor Version Upgrade は No で • AWS のタイミングで⾃自動的にマイナーアップグレードが⾛走る

7. RDS（ハマりポイント） ☁ インスタンス削除の際に Final Snapshot を取得しない • ⽇日次バックアップの
Snapshot は削除される ☁ デフォルトの Parameter Group を使⽤用する • コネクション数の上限が変更更できない • Parameter Group 変更更を⾏行行う際にダウンタイムが⽣生じる

8. Route53

8. Route53 ☁ ELB や S3、CloudFront を指定する際は ALIAS レコードを使⽤用しましょう
• 名前解決のプロセスが⼀一つ減る ☁ ネイキッドドメインを利利⽤用したい場合は Route53 を使⽤用しましょう • 外部 DNS で ELB や S3 を指定する場合、ネイキッドドメインが利利⽤用できない

8. Route53（ハマりポイント） ☁ ALIAS レコードを使⽤用しない • 名前解決のプロセスが増えて若若⼲干レスポンスが落落ちる •
ネイキッドドメインが利利⽤用できない

⼿手順のおさらい 1. 上限申請 2. VPC 3. IAM
4. Security Group 5. EC2 6. ELB 7. RDS 8. Route53

まとめ ☁ 常にサービスがスケールすることを想定 ☁ デフォルトの設定のままで構築するのはリスク ☁ インスタンスのローンチ前に指差し確認をしましょう

AWS構築のハマりポイントを詳しく解説 / Cloud on the BEACH 2016

AWS構築のハマりポイントを詳しく解説 / Cloud on the BEACH 2016

More Decks by Naoto Enokawa

Featured

Transcript