12. 新システム構成(図)
Tokyo, Japan
AWS上にあるSystemに世界中の各拠点ネットワークから専用線またはVPNでPrivate接続
ADFS
12
Mumbai, India
San Francisco, US
corporate data center
ロードバランサ:ELB
WEBサーバ:EC2 x 3台以上 (Scaling
で任意に台数変更)
DBサーバ:RDS (Master:1台+
Slave:1台+リードレプリカ:MAX(5台)
(負荷次第で台数変更)
Storage (NFS):EBSをNFS化、MAX
回数(5回)のSnapShot
BackupStorage:SnapshotをGlacier
に暗号化して保存
認証:自社ADFSで認証
★スパイク対応:APIで任意スケール
VPC, サーバにはは踏み台サーバから
のみアクセス可能でアクセス履歴を証
跡化
(図ではMumbaiからメンテンナス)
コンソールやAPIの操作をCloudTrail
で証跡化
★BCPを考慮してマルチRegion
13. Network & Security
Tokyo, Japan
利用したいサービスは、VPC、EC2、RDS、CloudTrail および IAM、Security Group となります。
13
Mumbai, India
San Francisco, US
• Private接続として接続
VPN ( またはDirect Connect)
• Privateなネットワーク定義
• Security Groupでアクセス制御
VPC
• Security Groupでアクセス制御
• IAMによる管理者のみ操作
• http/https以外は直接アクセス不可
(踏み台サーバのみターミナル接続許可)
EC2 (Webサーバ、踏み台サーバ)
• Security Groupにてアクセス制御
RDS
• AWSへのAPI操作を証跡化
• EC2へのアクセス証跡は踏み台サーバでも取得
CloudTrail
security group
security group
security group
14. Balancing
Tokyo, Japan
利用したいサービスは、VPC、EC2、ELB および、AMI、SDK となります。
14
Mumbai, India
San Francisco, US
•ロードバランシング
•負荷に応じてスケールしたWebサーバをバラン
シング
ELB
•通常3台 (冗長化MIN構成)
•★スパイク時にスケールするようにスケジュー
リング:予想時刻までに自動でN台のサーバを
AMIからコピーし、ELBにてバランシング開始、
不要になったらインスタンスは破棄、通常はス
ケジューリング、※スパイクタイミングは明確な
のでオートスケールは利用しない
EC2 (Webサーバ)
•操作端末からのAPI操作によって臨時スケール
可能
API (SDK)
18. ADFS
Tokyo, Japan
利用したいサービス は ありません。
ADFS
18
Mumbai, India
San Francisco, US
corporate data center
•既存ADFS認証をそのまま利用
•ADFSの認証情報があればよいのでAWS
独自の構成を考慮する必要なし
•将来的にAWSコンソールもADFS連携する
ADFS