AWS： VPC以及其他

VPC的4种场景 

个人认为NAT和VPN还是比较常用的。

ELB

create ELB(选择VPC）

…….

添加SG 安全组

健康检查

添加EC2 instance.

autoscaling 

创建组

选择对应的AMI（IAM ROLE，比如是web role)

选择SG

配置 key pair

设置group的VPC/Subnet（可能涉及到ELB）

（有个多的选项是，保持现状还是自动扩展流量）

然后看EC2多了2个Instance

然后ELB下2/4 in service.

可以尝试停掉2个，然后看ELB, 自动扩展的可用了。

NAT上网

1. 2个ec2 instances,不同子网。
2. 创建SG，选择VPC。源10.0.3.0/24,dest 是80、443，outbound any
3. 选择ami-vpc-nat来创建NATBOX（就是一个iptables规则），VPC是。。。子网是10.0.2.0，选择刚才的SG，
4. 然后给一个EIP，关联到NATBOX否则没办法NAT。disable source/dest check,因为是NAT。
5. route tables. 选中内网的那个，Route talbe ID 编辑routes.
6. 找到刚才的nat ID。 0.0.0.0/0 走NAT
7. subnet Associations ,就是把刚才设置的路由规则的ID和子网关联，此时应该是10.0.3.0/24

故障处理，需要看NAT SG，是否允许80/443, 还有route tables.

NAT 10.0.2.0 

路由表local ,0.0.0.0/0 走NAT自身

其他：l0.0.3.0

路由表Local. 

# 一些问题
1. ELB分Internal和external(好比Database前边的LB无需给公网访问就能设为internal), external的话需要公网能访问，所以ELB所在的子网必须有路由表能出去。一般来说，route table 必须在某个VPC里，而且和某些subnet关联起来。

2. AWS的health check 非常的弱，基本上是最简单的那种访问某个页面，默认是80/index.html，而某些页面需要401认证，此时访问肯定是返回403，而AWS默认健康值应该是200之类的。所以一直Out of service.

原文:

The destination for the HTTP or HTTPS request.

An HTTP or HTTPS GET request is issued to the instance on the ping port and the ping path. If the load balancer receives any response other than "200 OK" within the response timeout period, the instance is considered unhealthy. If the response includes a body, your application must either set the Content-Length header to a value greater than or equal to zero, or specify Transfer-Encoding with a value set to 'chunked'.

不得不说做的太次了。而且连个日志都没有，查起来非常的麻烦。

3. 注意平时习惯了去ping，但不通可能非常正常，以为security group可能没打开这个，定势思维会干扰你。