理解下AWS Well-Architected Best Pra
一.缘起：
1.从aws小白到渐渐掌握了一些常用服务的使用，发现SAP考试对服务的考量并不在了解功能和会使用层面，而是有大量的Best Practice问题，这相对于SAA是有很大难度提升的
2.各种的服务之间到底如何协同使用才是Best Practice？--这就得说Well-Architected
二.设计原则（5大支柱）：
0.原始系统架构图
原始系统架构
1.卓越运营
如何运行才是卓越的，对于云计算来说那一定是运营即代码。按照我个人的理解一切的运营都是可以在System Manager和CouldWatch当中来进行的。
卓越运行目标架构
1.1给EC2打标签是为了分类管理，在instance页面中的tag tab可以为实例添加标签，如：{Environment:Production,App:Product-Catalog}
1.2资源组是相同标签资源的集合，使用资源组可以对资源进行批量操作。创建资源组使用Resource Groups & Tag Editor
1.3选择资源组以Tag分类，选择资源类型为EC2，选择标签内容为{Environment:Production,App:Product-Catalog}后，会自动筛选出刚刚设置的两个EC2实例
1.4连接到SSM的EC2要确保安装了SSM代理，创建名为wa-lab-ssm-ec2-role的IAM role，选择两个AWS托管的两个policy：CloudWatchAgentServerPolicy，AmazonSSMManagedInstanceCore。这两个policy能够让SSM连接到EC2并且在其中运行某些命令
1.5将创建的IAM role应用到两个EC2实例上，重启实例使得IAM role生效
1.6在node management>Inventory中可以检查到出现两个EC2实例，代表可以通过SSM链接到实例并且运行命令，如果未出现则需要重启它们
1.7在node management>Run Command中运行AmazonCloudWatchAgent命令，名称选择AmazonCloudWatchAgent，目标选择前步骤创建的资源组
1.8在node management>Run Command中运行AmazonCloudWatch-ManageAgent命令，名称选择AmazonCloudWatch-ManageAgent，配置源选SSM，配置位置选wa-cw-config-file-httpd-mariadb，可选重启选是
1.9将此json文件存放在SSM的Parameter Stored中
{
"agent": {
"metrics_collection_interval": 60,
"run_as_user": "root"
},
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/messages",
"log_group_name": "messages",
"log_stream_name": "{instance_id}"
},
{
"file_path": "/var/log/httpd/access_log",
"log_group_name": "httpd_access_log",
"log_stream_name": "{instance_id}"
},
{
"file_path": "/var/log/mariadb/wa-db-server.log",
"log_group_name": "db_general_query_log",
"log_stream_name": "{instance_id}"
},
{
"file_path": "/var/log/mariadb/mariadb.log",
"log_group_name": "mariadb_log",
"log_stream_name": "{instance_id}"
}
]
}
}
},
"metrics": {
"append_dimensions": {
"AutoScalingGroupName": "${aws:AutoScalingGroupName}",
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}"
},
"metrics_collected": {
"disk": {
"measurement": ["used_percent"],
"metrics_collection_interval": 60,
"resources": ["*"]
},
"mem": {
"measurement": ["mem_used_percent"],
"metrics_collection_interval": 60
},
"statsd": {
"metrics_aggregation_interval": 60,
"metrics_collection_interval": 10,
"service_address": ":8125"
}
}
}
}
1.10在CloudWatch的Metric中可以查看CWAgent选项卡中两个EC2的指标都显示出来了
2.可靠性
提到可靠性，就不得不说高可用，实现高可用就要用到分可用区，ALB，Auto Scaling Group等
可靠性设计目标
2.1将子网添加到第二个可用区
2.2使用多可用区部署RDS
2.3更新SSM parameter
2.4创建ALB和Auto Scaling group的目标组
2.5使用SSM>Run Command进行数据库迁移，将数据库从EC2实例迁移到RDS
2.6为EC2实例创建ASG
3.安全性
安全性是aws中最为看重也是最复杂的一项方面，因为在多个层面实现安全都会使用不同的服务，本次主要使用CloudTrial和AWS Config对系统进行监控和检测提升安全性
安全性目标架构.png
3.1启动CloudTrial创建一个新的trial存储在S3中
3.2启动Config，选择记录此区域所有资源包括全局资源如IAM等，创建新的存储桶，如果使用寄存的存储桶需要另外设置权限允许与Config进行通信
3.3到此我们在CloudTrail中获得了全资源的操作监控清单，在Config中获得了全资源清单，并存放在了不同的S3 bucket中
3.4修改安全组规则，分别修改inbound和outbound rule，配置为仅允许数据库实例的流程与应用程序实例进行流量通信
3.5启动VPC创建ACL编辑出站和入站规则并关联到公有子网
3.6在CoudTrial中选择创建的Trial，打开S3存储桶，可以下载Json文件查看日志
3.7在AWS Config的资源清单中可以查看到新加入的ACL已出现在其中
4.性能效率
主要考虑弹性elastic and auto scaling,以及使用cloudWatch来监控并指定扩展策略
4.1在EC2中选择ASG并创建动态扩展策略为CPU使用率达到阈值的时候自动扩展
4.2在CloudWatch中创建监控数字、图标和警报分别监控EC2实例的CPU利用率
4.3通过监控了解与预期性能的任何偏差并采取自动化操作
4.4验证创建的警报和策略，可以在SSM中使用Run Command的方式来测试警报并在CloudWatch中观察指标变化,Command参数如下
AWS-RunShellScript，
#!/bin/bash
sudo stress --cpu 8 --vm-bytes $(awk '/MemAvailable/{printf "%d\n", $2 * 0.9;}' < /proc/meminfo)k --vm-keep -m 1 --timeout 300s
5.成本优化
成本是需要能在满足业务需求的基础上，不算优化的，比如通常会使用Organization整合账单的功能来共享套餐优惠降低整体成本。本次我们使用Config来建立rule的方式查看资源配置结果，激活合规预防控制达到整体优化成本的目的
成本优化目标架构
5.1启动Config，选择特定的资源类型EC2 instance,赋予Config一个ConfigServiceRole并将其保存在S3存储桶中
5.2添加role以强制执行所需的标签，使用AWS托管的required-tags规则只针对于EC2资源
5.3查看创建好的role，发现其中一个EC2由于缺少标签被标记为了不合规
5.4返回EC2实例，按照config要求打上标签，再次确认role中的不会贵标签变为了合规
5.5当然Config除了进行合规性检查意外更重要的是可以激活合规性的预防控制，使得新建的每个EC2实例都是合规的
以上，做些实验的总结加深对Well-Architected的理解。
