Consolidated Billing作为AWS Organization的一大好处被频繁提及。
我的简单理解就是一堆人花钱，然后让一个人买单。
可这对“组织”又有什么好处呢？我一直有这样的疑问。
首先，只拿到一张账单，对于整个”组织“来说是非常方便的 – 总比拿着几百张员工账单来得轻巧。
这一张账单并不只有一个数字的，而是有各个账户的分别数字的，类似于：
一目了然，是不是？
第三个好处，我认为是Consolidated billing最大的好处：资源共享或者资源累积。
AWS的很多东西，是你用得越多越便宜的。
存储、reque[……]
回答这个问题之前，要考虑清楚：为什么数据要在各种存储之间迁移？
第一个原因，换组件。比如以前用一个数据库，现在想换一个数据库用用。
另一个原因我更喜欢：因为要拿数据去实现价值啊！
数据存进来仅仅是第一步。数据的价值在于分析，提取有效的内容，生成报告啦、图标啦，等等。
在《数据库，何时用Redshift，何时用Aurora？Fast local read是什么？》这篇中，我们提及了为什么要用Redshift，因为Redshift是列数据库，擅长分析。
当然擅长分析的（不一定是数据库）还有EMR，大数据平台嘛。
题目中提到的场景，只能作为简单的数据迁移来[……]
简单来说，4xx的错误叫Client Error，可以理解为客户端到API-Gateway之间的错误；5xx的错误叫Server Error，可以理解为API-Gateway“背后”出现了问题。
换句话说，如果看到4xx的错误，查API-Gateway。看到5xx错误，把目光放到它的后面，比如Lambda。
4xx常见的有：
400 – Bad Request
403 – Access Denied。查查是不是被WAF给墙了。
429 – Quota exceeded。查查是不是被Throttle了。比如API Gateway设了Quota。
5xx常见的有[……]
恩，这个问题，其实要Database的种类讲起。
首先大家知道的DB，一般是MySQL、PostgreSQL、SQL Server等。
这类的数据库成为“关系型数据库”，也就是OLTP。它每一行是一条记录。具体的意思大家自己查查吧。
关系型数据库的优点是可以非常快地找到“这个人”的“所有信息”，因为就一行。
但要是想开始查，有“多少人”，“怎么样”的时候，就会很慢。
一般这个时候，大家会用一个东西，叫index。将记录里的一项，做索引，加速查询。
其实你没意识到，当你加了一个索引的时候，其实你存的数据，是一列。
于是列数据库就不难理解了。这样的数据库是[……]
AWS S3 Glacier有Vault吗？有啊。S3 Glacier本身就是用Vault来做的，而Vault本身，也是个Container而已。
“Amazon S3 Glacier uses “vaults” as containers to store archives. ”
我知道有上面这个问题的原因，是因为我们以为S3 Glacier和S3一样，用Bucket。
所以不要把S3 Glacier和S3混在一起，当他们是两个产品即可。
至于Vault Lock，理解了Vault，那lock就是为了“锁Vault”的嘛。
Vault lock其实又是一个Pol[……]
在《Lambda如何接入私有网络》篇中，我稍微介绍了一点Lambda创建的过程。
简单来说，当你有个任务需要Lambda去运行的时候，AWS在它自己的平台上，分出来一个Container给你，来运行你的程序。
你可以用这个Container跑一个任务，也可以跑多个任务。记得有一些限制，比如内存128M-10240M（10G内存支持于2020年12月1日），CPU不受你控制，但会跟内存分配的增加而增加。1000个软concurrency限制，/tmp目录512MB，以及一个任务最多运行15分钟。
但是这个Container从无到有，是需要一些时间的。这个“从无到有”时间，就是所[……]
这个问题涉及到了AWS的防御模块们。请出AWS Shield和AWS WAF（Web Application Firewall）。
我的理解，shield主要针对的是DDoS。针对网络层，DNS也包含在内。
WAF，从名字就能知道是针对Web的，所以HTTP的防护，比如限制从哪来的（Original IP或者Country），Header里带了什么不好的东西，SQL注入（因为SQL注入的方法主要是在query中实现），还有Cross-site 攻击等。
因此我的简单理解就是：
可以说，这个问题在考试中和实际情况中很常见。比如：如何给那些缴费的会员显示相应的资源？或者如何给登陆用户展示相应的内容？
这里用到的一个核心技术，是CloudFront signed-URL和signed-cookie。
简单来说，我们假设需要访问的资源在S3上，也就是所谓的CloudFront Origin is S3。那么在启用配置Origin的时候，务必要限制S3 bucket的访问。从此以后，只能是CloudFront能够访问到S3的这个bucket，其他地方都不行。这个，就是所谓的OAI（Origin Access Identity）。
配置好后，那只有访问Clou[……]
是的。RDS可有On-Demand，也可以Reserved。
和EC2一样，在Reserved时，可以选1年或者3年合约，有很大的折扣。
当然，RDS没有spot类型，更没有saving plan或者dedicated Instance/Host。[……]
这个话题明显是个IT部门的话题。
设想你管理着公司所有的办公机，一般你会接到两种普遍的需求：装软件和打Patch。
我不做IT，因此我可能说的不对。我记得这两种需求一般流程都会是：IT部分发个信，通知某个时间做这些操作，然后到时间，通过Windows的域管理（？）实现所有办公机一起升级。
在AWS里，这样的需求也是类似的，对象就是EC2。
但是，管理的“品种”可能要覆盖Windows、Linux和Mac。
AWS推出的组件，叫System Manager。名字简单粗暴。
怎么做？这个图画的同样简单粗暴：
用Cache的好处这里就不赘述了，如果你不懂，请自己查一查。
我一直很好奇，AWS里究竟哪些地方给你选项，可以用Cache。
首先一个组件，CloudFront，为Cache而生。
CloudFront关注的是将返回的结果快速地分发到客户端，可以简单理解为HTTP Content Cache。
多说一句，配置CloudFront Cache的时候，记得static和dynamic分别处理。static可以cache，dynamic request嘛，只能尽力了。
另外对于Header的匹配也要注意，包括cookie，容易变的，就不要当做匹配条件。比如传说中的Dat[……]
首先要明白一点，Redshift就是列数据库，跟clickhouse是一样的。
列数据库的优势在于分析，所以Redshift是OLAP，不是OLTP。
再一点，Cross-region Replica这个东西仅用于S3，和RDS或者Redshift毫无关联。
好，现在开始说多AZ部署和灾难恢复。
先前说了，Redshift是分析型数据库，所以也就不像RDS那样分什么Read-Replica之类的。
Redshift就是列数据库的Cluster，所以基本来说，备份全靠Snapshot。
Redshift的snapshot分为自动和手动两种，自动的每8小时，或者[……]
首次听到VPC sharing的时候，我以为它和VPC peering是一个意思。
但这里的sharing，是和同一个AWS Organization 下其他Account分享VPC的意思。
【特别注意】VPC Sharing中Sharing的是Subnet，不是VPC（因为就变成一个VPC了）。
理解了这个，就知道它和VPC peering完全不一样。
VPC peering，简单理解就是搭建了路由，让两个VPC可以互通。
而且还是最初级的那种两个网段的单跳路由。高级一点的现在都用Transit Gateway。
而VPC Endpoint[……]
