Ⅰ 如何在aws服务器上设置ip黑白名单
在网站安全狗IP黑白名单内将本机IP设置为黑名单，通过测试发现在本地访问网站就提示错误信息
IP白名单设置可以通过设置一些值得信赖IP地址为白名单地址，从而使它们能够顺利的访问网站，用户可以点击“启用”选项开启白名单功能，不要忘了设置好后需要保存
规则列表，可以新增、修改、删除禁止访问IP段及对应的网站规则
具体设置和设置后
可以点击“修改”和“删除”对规则进行修改
将一些常见的网络爬虫设置成白名单，这样就不会再拦截爬虫了
在默认设置中已经有添加了一些爬虫白名单，用户同时可以在“新增”和“删除”选项中添加一些自己需要的爬虫和删除一些没用的爬虫。
IP黑名单是相对白名单进行设置的，目的是为了通过设置一些不良IP地址为黑名单地址，从而限制它们访问网站。需要先开启防护功能列表中的监控设置才能正常启动，同时点击“启用”后要记得保存修改
同样IP黑名单也是采用由指定IP和子网掩码来划分IP地址，设置方法和IP白名单的设置是一样的，用户可以通过“新增”，“修改”，“删除”修改规则列表
当被禁止IP访问用户的网站时，服务器就会返回信息，这个信息可以根据自己的情况进行设置
Ⅱ AWS - ECS + Application Load Balancer的思考
我们有一个前端应用项目，这个前端应用用来替换老的Web站点的部分页面，其结构如下：
用户的请求首先会到Nginx，由Nginx做反向代理，根据请求路径转发到New Web App或者Legacy Website。
在部署这个应用的时候使用到了AWS ECS。下图为最开始时的部署结构：
从图中可以看到，应用的DNS（Route53）指向了一个外部可访问到的负载均衡器（External Classic Load Balancer）。负载均衡器暴露了80端口(用于Http请求)和443端口(用于Https请求)。负载均衡器将80端口和443端口都映射到了AWS EC2 Instance上的80端口。
而由ECS管理的Nginx容器，它将宿主机（EC2 Instance）的80端口映射到了容器的80端口。这样从External Classic Load Balancer来的请求都会转发到Nginx容器。
那么，当用户请求到达Nginx容器后，由Nginx做反向代理，根据请求路径将请求转发到New Web App或者Legacy Website（Legacy Website并不属于部署结构中，所以并没有在部署结构图中画出）。
假设，这个请求需要转发到New Web App中，那么应该怎么做呢？
由于AWS ECS并没有服务自动发现机制，所以我们需要给New Web App Container Cluster添加一个内部可访问到的负载均衡器（Internal Classic Load Balancer）。这个负载均衡器将80端口映射到了AWS EC2 Instance上的3000端口，而在创建Nginx Container的时候会将这个内部负载均衡器关联起来。所以在请求需要转发到New Web App中时，直接转发到这个内部负载均衡器即可。
到此为止，这个方案看似还不错，但是如果你细心研究，你就会发现它存在一些问题。
有没有发现，我们将ELB端口映射到了Instance上，而这个映射是固定的。一个Instance上的某个端口一旦被占用，就无法被其它进程绑定。这就意味着一个EC2 Instance上只能启动一个Nginx容器、一个New Web App容器，因为它们都需要绑定到特定的EC2 Instance端口号。
那么，如果说EC2 Instance上有足够的资源能够再启动一个New Web App容器或者Nginx容器，但是由于端口已经被占用所以这些资源只能被浪费掉。我们必须再启动一台EC2 Instance给ECS使用，ECS发现这个新的EC2 Instance上没有绑定过3000或者80端口，并且有足够的资源（CPU, Memory）启动New Web App或者Nginx容器，那么New Web App或者Nginx容器就会在新的EC2 Instance上启动。
由此，我们可以看到这种部署方式，给我们带来了这样的问题，即： 某种类型的容器只能在一个EC2 Instance上启动一个 。这对于我们来说是一个极大的限制，为了解决这个问题，我们找到了AWS Application Load Balancer（ALB）。
首先，我们将Classic Load Balancer换成了Application Load Balancer，如下图：
从图中看，好像并没有什么改变。是的，如果还是使用固定端口的话对我们并没有什么帮助。但是，ALB有一个特性它可以实现 动态端口绑定 ，这个特性正式我们想要的。
通过，实现动态端口绑定我们的架构变为如下图所示：
如图所示，通过动态端口绑定，我们实现了在 一个EC2 Instance上启动多个同类型的容器 。
Ⅲ 如何管理aws云服务器
管理可以由两个方面构成
第一个是通过AWS控制台的配置，来设置服务器的伸缩，监控等等。
EC2的使用
第二个是使用PuTTY直接连接EC2，进行管理。
教程：
使用PuTTY连接EC2
希望可以帮到你。
Ⅳ 亚马逊AWS的云计算服务有哪些优势
亚马逊AWS作为云计算服务的领军者， AWS对SaaS解决方案的设计提供了一些云计算服务最佳实践。
一、将平台化的功能隔离出来，SaaS产品的更新速度是非常快的，但是我们仍然能够总结出一些核心的功能是基本不变或者能够在很多其他新的产品模块中重用的。我们要将这部分功能分离出来进行平台化改造以服务于更多的其它功能，将这些功能平台化以后也会降低整个系统的耦合性从而支撑更多的SaaS应用的功能。对通用功能的平台服务隔离可以更好的调优和独立扩展，同时重用核心服务并结合应用框架的使用会极大提升应用开发的效率。
二、优化成本和性能，在传统的技术架构下这两者之间往往需要进行一定的平衡，而在AWS云的架构下的SaaS服务云模式下往往可以实现鱼与熊掌兼得。在每个架构层次实现弹性的横向扩展可以让我们实现按使用量付费的模式，而不需要为了获得强大的性能而提前付出大量的资源成本，同时我们在SaaS的AWS架构下可以使用更小的、平行的资源单位进行扩展，从而更为贴近SaaS环境下的实际资源需求，在合适的场景下尽可能的采用完全由AWS托管的服务(比如Amazon DynamoDB等)来降低SaaS合作伙伴的运维成本并提升效率。
三、针对SaaS解决方案设计的。云计算服务，首先对于多租户的设计要针对SaaS应用自身的特点来进行规划，总体的设计原则是系统会有多个帐号，而一个帐号会对应多个用户，一个用户又会对应多个角色;其次是对于系统处理各种请求时要按照优先级进行分级管理，在通过使用AWS各种服务如SQS、SWF等对系统进行解偶后，对AWS资源集约使用的前提下，对请求分优先级处理会极大提升SaaS架构的处理能力和稳定性;接下来要对监控加大投入力度，借助AWS CloudWatch等监控服务，通过粒度更细的监控来控制分布式资源更为有效的弹性伸缩;最后合作伙伴还需要非常了解SaaS应用架构中所有数据的生命周期以及在在各个周期内数据的特点，依据这些特点为数据在AWS的服务中选择正确恰当的存储方式以优化技术架构及降低成本。
四、收集一切可以收集的数据并从这些数据中挖掘出价值。AWS基础架构自身通过CloudWatch服务就可以收集粒度非常细的指标，同时SaaS应用自身也会产生大量日志及指标数据，这些数据和指标不但要密切监控同时也要全量的妥善保存起来，以便后续的大数据挖掘工作。云计算服务,不要担心在传统模式下数据存储的高昂成本，在AWS云的架构模式下有大量诸如Amazon S3、Glacier等成本极低的存储方式。通过分析这些大量的数据来了解你SaaS服务的客户，能够为业务带来巨大的价值，例如实时自动调整用户体验及与之相关的基础架构，通过使用量的分析改进业务模型等等。
Ⅳ AWS 考试认证心得(SAA)（下）
接上 AWS 考试认证心得(SAA)（上）
这章主要就是AWS-SAA相关知识点的干货啦，不过这不一定适用于每个人，最好的办法还是自己按照自己的熟悉薄弱的地方去归纳总结AWS-SAA的考点知识：
个人总结AWS-SAA的考试有八大考点方向，分别是：
先按照大纲弄清每个服务是做什么的，然后再深入去了解，再对比相似的服务，比如对于存储这一块儿就会考S3，EBS，EFS的区别，格子在什么情况下用，再比如题目会问在某情况下怎么cost最经济高效？Spot，Reserved，还是On-demand。建议在这个过程中建议观看英文文档，因为有很多专业的词汇还是要用英文才能描述的更准确。
AWS的考试是十分有技巧的，相信各位同学经历了中国大大小小的考试，见过大风大浪，这个考试也应该不在话下，哈哈。总的来说就是做英文阅读！没错，就是做阅读。学会抓关键字法，排除法灵活运用。比如这一道题目：
这是道是非常经典的AWS的题目类型，虽然题目很长，但是按照找关键字法的话就很快能做出来。快速浏览题目找到关键词 highly available ，既然题目要求是HA的，那答案就是D。因为只有D有对应关键字的答案---- Multi-AZ 即：多个可用区。（看到HA那么90%以上选Multi-AZ，因为要保证高可用，必须要在多个可用区部署，反之如果只是单个可用区，那么服务挂了就不能保证高可用)。所以有很多考题就要学会抓关键字去做，这样就能事半功倍。
1.SMB + on- premises 找 AWS Storage GateWay File gateway (注意是 file )
3.对象存储： S3 ，S3也可以放static web，常与cloudfront搭配分发
4.“multi-instance，HFC，并行” = EFS
5.I/O较低，偶尔会有小峰值：EBS通用SSD(gp2) General Purpose
7.吞吐量经过优化的HDD（st1）卷提供了低成本的磁存储，该磁存储根据吞吐量而不是IOPS定义了性能。此卷类型非常适合大型连续工作负载，例如Amazon EMR，ETL，数据仓库和日志处理。
8.冷HDD（sc1）卷提供了低成本的磁存储，该磁存储通过吞吐量而不是IOPS来定义性能。 sc1具有比st1低的吞吐量限制，非常适合大型连续的冷数据工作负载
4 iGB = 200 IOPS
Volume(iGB) : IOPS = 1：50，
EBS 4 IOPS = 1024 kb I/O
I/O : IOPS = 256 : 1
21.Amazon EBS 可看成外接移动硬盘
23.NLB 用于 layer 4
24.ALB 用于layer 7
总之要善于总结这些知识点，之后要做的事就是Mapping，找到关键字及匹配答案就能快速完成答题，不然130分钟65道题时间还是有点紧张。
最后祝大家考试顺利，早日通过认证考试！
Ⅵ 如何在AWS上部署千万用户级别服务
基础架构
AWS分布在全球12个区域里
每个区域对应着一个地理位置，里面含有多个Availability
Zones(可用区)。这些区域设置在北美，南美，欧洲，中东，非洲，亚太区。
每个AZ实质上是单个数据中心，尽管它们可由多个数据中心构建。
每个AZ有着独立的供电系统和互联网连接。
不同AZ之间以低延迟网络进行连接，这种快速网络可消除物理位置带来的速度影响。
每个区域含有至少两个AZ，共计32个AZs。
借助AZ可创建高可用性的程序架构。
AWS在全球还分布有53个偏远区域(Edge locations)
偏远区域的使用对象是CloudFront，这是Amazon的内容分发网络(CDN)和DNS服务器。
偏远区域的存在使得全球用户都可以享用低延迟网络而不论他们身在何处。建立区块服务(Block Services)
Amazon透过AWS创建了大量高可用和高容错的服务，具体的服务清单可点击这里查看。
缴纳一定的费用，你就可以在个人的应用中使用这些服务而不必为高可用性而忧心。
部分服务位于一个AZ中：CloudFront, Route 53, S3, DynamoDB, Elastic Load
Balancing, EFS, Lambda, SQS, SNS, SES, SWF。
即使是使用单个AZ的服务，其高可用架构也是足够强大的。
1个用户
在这个时候，开发者=用户。你的架构看起来是这样的：
运行单个实例，如t2.micro。你可以为你的服务器选择不同的CPU，内存，存储设备和网络环境。
该服务器承载了全部web任务，如：web应用，数据库，管理器等。
使用AmazonRoute 53进行DNS管理。
为该实例附加一个Elastic IP地址。
那么随着用户数的增加，我们需要如何进行升级改造，直至能为千万用户提供优质的服务呢？强调文字
优化策略
采用多主机模式
尝试使用Amazon数据库服务，如Amazon RDS(关系数据库)，Amazon DynamoDB(NoSQL数据库)，Amazon Redshift。
逐步从SQL数据库转为NoSQL数据库，特别是数据量超过5TB，你的应用对低延迟敏感的时候。
使用Elastic Load Balancer(弹性负载均衡器)，它可以对主机进行健康检测以确保网络的通畅，同时可以帮助实现网络的扩展。
垂直升级
需要更强的实例类型，例如c4.8xlarge或者m3.2xlarge。
停止使用当前的服务器，换用功能更强大的机器，如：244GB RAM，40核CPU。
某些Amazon服务提供了Provisined IOPS选项以便用户自行配置变更，这样一来用户可以使用类似DynamoDB的扩展服务。
类似上面的做法就叫做垂直升级。但其有个缺点，就是一旦机器出错，你的网站也会停止运作了。所以要尽量避免单个实例的做法。
自动扩展
如果你一直在为峰值负载而努力，如黑色星期五，那么其实是在浪费金钱。更好的解决方案
列表内容
是按需分配，这就是Auto Scaling(自动扩展)，在计算机群组中实现自动化的大小变更。
你可以为你的容量池定义最大值和最小值。
CloudWatch是一个管理服务，已内置到所有的Amazon应用中。
CloudWatch事件会触发扩展。
触发事件可以是CPU占用率，时间延迟，网速等等。
你也可以向CloudWatch导入自定义基线，按照你的意愿来触发扩展。
架构分解
使用SOA/微服务，使你的服务层组件化。
这样做的好处是单独的服务可以独立地进行扩展，从而大大增加了灵活性和可用性。
SOA是Amazon提供的重要架构组件。
避免重复劳动
把精力投入到能使你的业务与众不同的事情上。
Amazon提供了很多高容错的服务。例如，排队(SQS服务)，邮件，转码，搜索，数据库，监控等等。所以类似的服务都不必再次编写了。
用户数>千万+
当用户达到千万级别的时候，你考虑的策略应该是这样的：
多AZs模式
在不同层之间执行ELB(弹性负载平衡)。除了web层，在应用层，数据层等层里也需要进行ELB。
能够自动扩展
使用面向服务的架构
缓存架构内和外的数据
使用Amazon S3和CloudFront。S3用于存储静态数据，如js，CSS，图像等，具有足够的扩展性。CloudFront可对数据进行缓存。
使用Amazon SES来进行邮件发送。
使用CloudWatch进行监控。
对数据写入执行如下的策略：
联结 – 根据功能划分不同的数据库。
分表 – 把一个数据集分解到多个主机上。
把部分功能放到其他类型的数据库上（NoSQL,graph等）。
不断优化你的应用和整个架构堆栈，针对瓶颈进行分析并找出解决方法。
Ⅶ 在AWS上部署TE Agent并进行测试
ThousandEyes 是一个网络性能监控的SAAS云服务，结合了各种主动和被动的监控技术，让您深入了解您提供的以及您消费的应用和服务的用户体验。ThousandEyes使用的监控技术包括网络的可达性探测、时延、丢包、抖动、可视化的逐跳路径分析、可视化的BGP路由分析、DNS监控、HTTP服务监控等。ThousandEyes平台对这些监控收集而来的数据进行分析、交叉关联，将涉及用户体验的方方面面，包括网络和应用的状况统一的呈现在同一个界面之下，让您能够轻松的隔离问题，采取行动，从而快速的解决问题。
ThousandEyes提供了三种Agent进行网络和应用的探测，分别是Cloud Agent、Enterprise Agent和Endpoint Agent。Cloud Agent 由ThousandEyes在全球部署和维护，当前，ThousandEyes在全球200多个城市共部署了400多个 Cloud Agent ，可供全球用户使用。Enterprise Agent由用户自己部署，可以部署为虚拟机或者容器，可以安装在物理硬件，如Intel NCU或者树莓派中，支持Windows、Linux系统，还可以部署在思科或Juniper的网络设备中，也能通过CloudFormation在AWS云中自动部署。Endpoint Agent是浏览器插件，用户在访问网站时，可以自助的使用Endpoint Agent进行测试，由ThousandEyes进行数据分析，从而帮助用户快速了解其数字体验，以及快速定位问题所在。用户可以根据自己的需要来选择一种或多种Agent进行探测，ThousandEyes平台会自动完成分析和展现，提供网络和应用状况的洞见分析。
在正式部署之前，快速阅读了一下 AWS Deployment Guide ，部署过程是通过AWS的CloudFormation创建一个Stack，整个过程全部自动化。
部署的前提是需要设置好SSH Key-pair，VPC网络、公共子网、以及使用CloudFormation部署EC2的权限。
部署的内容包括：启动基于Ubuntu的EC2实例，并自动安装TE Agent，创建Security Group，并基于最小权限配置Inbound Rules。
首先，在MAC电脑中，执行以下命令，用于创建一个RSA的秘钥对，并将公钥拷贝至桌面。
登录AWS的Console管理界面后，选择Region，比如us-east-1，定位到EC2—Network Security—Key Pair，在界面右上侧的Actions下拉框中，选择Import key pair，将aws_kp.pub上传。
在其他的Region，重复上述动作，将key pair上传，这样在多个Region创建的EC2可以使用同一个私钥进行登录。
部署TE Agent的操作路径为：在ThousandEyes的界面中，选择Cloud & Enterprise Agents，再选择Agent Settings，进一步选择Enterprise Agents，点击Add New Enterprise Agent。在右侧出现的界面中，选择IaaS Marketplaces，在该界面中点击Launch in AWS，跳转到AWS的登录界面，并自动进入CloudFormation的界面，该界面已将Stack模板选择好了。
Stack模板的链接：
https://s3-us-west-1.amazonaws.com/oneclick-ea.aws.thousandeyes/aws-ea-oneclick.yaml
该模板包含两个组件：EC2 Instance 和 Security Group。
按照上文的部署指南填写表单，并点击下一步，直至完成部署。
在完成安装后，可以使用私钥登录到虚机，注意：用户名为 ubuntu，不是ec2-user 或 root。
在两个不同的Region，us-east-1 和 ap-southeast-1 分别部署一个TE Agent。
大约5分钟后，即可在app.thousandeyes.com的界面中看到两个TE Agent上线。
分别执行两种测试，一个是通过公网IP进行双向测试，一个是创建VPC Peering后，使用私有地址进行测试，比较两者之间的差异。
在ThousandEyes的Agent Settings界面中，点击Agent，在右侧的网页中，选择Advanced Settings，将地址设置为Agent的公网IP地址。
在Test Settings中，选择Add New Test，Layer选择Network，Test Type选择Agent to Agent。
选择一个Agent作为Target，另一个Agent作为源，测试方向选择双向。
经过一段时间后，ThousandEyes上即可呈现测试结果。
测试持续了一个小时左右，测试结果如下：
AWS us-east-1 to ap-southeast-1 Using Public IP
在可视化的路径分析图中，观察到如下信息：
本次测试的方法同上，只是需要将Agent的IP地址修改为使用私有IP地址，两个Region的VPC之间建立VPC Peering。
测试结果如下：
AWS us-east-1 to ap-southeast-1 Using Private IP
在可视化的路径分析图中，观察到如下信息：
做完两次测试，第二天检查了一下AWS的账单，预计花费了0.29美金。
https://zwskwtsea.share.thousandeyes.com/
https://aieajezsh.share.thousandeyes.com/
Ⅷ aws 入门：建立含有两个子网的网站
接触aws一个月时间，网上看了很多材料，自己做了一个包含两个公有字网的网站，记录下大概过程以备忘
1. 在VPC中创建一个vpc
2.在建立好的VPC中，创建两个公有字网，为什么要两个公有字网，因为之后启用https的话，需要启用负载均衡，自己只试了alb，alb要求两个位于不同可用区中的公有字网
3.