集中式日志存储架构

Hello大家好，欢迎回来，我们今天的视频课程要讨论的内容是 AWS的集中式日志存储架构，包括集中式日志存储架构需要考虑的事项，以及使用了两个AWS账户对架构的实现做了个快速的演示。

我们开始今天的内容。

集中式日志存储架构

当前，在绝大多数组织中，日志的管理和分析都被列为是非常核心的任务。它使组织能够更加了解业务运营情况、安全性、变更管理、各事件之间的关系等，可帮助持续对整个组织的架构运转情况全面的掌控。

一般来说，当讨论的是AWS时, 需要我们关注的日志服务有像AWS Cloudtrail ,VPC flow 日志，aws config日志，可能还会有来自EC2的日志等等，因此，将所有AWS账户的日志转发到一个作为中央区域的账户的S3存储桶，集中管理和存储是非常有必要的。然后可以在这个中心区域分析整个组织的日志，也可以使用splunk等工具从S3存储桶中获取日志，进行安全、审计、监控、排错等其他的需求分析，通过单一的节点实现所有管理的AWS账户的日志存储、分析、监控需求。

实现集中日志架构注意事项

我们先看下在实现集中式日志架构时，需要考虑的一些注意事项。

首先，尽早定义日志所需保留时间等要求，以及日志生命周期策略，这对于您的组织在遵循某种审计、合规政策时显得更加的重要，对于不同的日志类型对应不同的日志保留要求是非常常见的。我们假设有一个日志需要保留5年，就要确保如果您把日志存储到了一个集中的中央账户的S3存储桶，你要确保日志将在存储桶中保留5年且不会被自动删除。

同样，生命周期策略也是同样重要，尤其是出于成本因素考虑的时候。比如，当组织的某个应用程序产生了重要的日志，并需要集中存储时，数据达到了TB级别，我们可以先分析一下后续对于此日志的需求，评估后续日志的检索次数和对于检索时间的要求，根据这些需求您可能不需要一直将全部TB级别的日志放在S3存储桶，可以将大部分日志转移至glacier满足您的需求并为您节省很多的成本，这一点恰好就是生命周期策略起到重要作用的地方。

第二个是生命周期策略要自动化执行，比如上面提到的程序日志，将产生时间在1个月内的日志保存在S3中，以便在程序出现问题或其他需要的时候快速，高频进行检索；当在S3保留时间超过1个月后，将所有旧的应用程序日志自动转移到glacier以节省大量的成本。这些应该是自动化执行不需要我们人工去干预的。

第三点是我们的系统要能够自动化安装和配置日志传输代理程序。假设你有ec2实例在autoscaling环境，在后半夜一个新的ec2启动了，你需要确保这个新启动的实例的应用程序日志或者服务器日志，也要传输到S3存储桶中。要实现这个需求，就需要确保日志传输代理程序自动安装在了这个新启动的实例上。取决于不同的环境案例，可以将其在UserData实现，或者也可以将它集成在AMI中。

这个很好理解吧？因为如果您使用了autoscaling，非常可能发生的一个情况是一个EC2实例在后半夜因扩展规则自动启动，然后在运行一段时间比如当cpu使用率降低后这个新启动的实例又被终止了，如果您没有自动安装和配置日志传输代理程序，那么这个新启动的实例上的日志将会丢失。

最后一点是确保您实现的解决方案支持混合云架构。当前出于安全考虑企业更愿意将数据存放在本地私有云中，但是同时又希望可以获得公有云的资源，在这种情况下，现在很多组织都在朝着混合云架构方向发展，既拥有私有云，又同时使用多家公有云，如AWS ，阿里云等，所以不管你采用的什么解决方案，确认它支持混合云架构。

这是集中日志架构的一些注意事项。

AWS日志相关服务

因为我们的课程是AWS认证课程，所以我们需要了解如何使用AWS托管服务来构建集中式日志解决方案。
AWS提供了很多服务帮您构建，如AWS ElasticSearch Service、AWS S3、AWS CloudWatch servcie 、Kinesis Firehose等等

需要说明的一点是，在AWS中，在配置集中式日志存储方案时，以上提到的服务的配置方式都是不同的，比如配置CloudTrail服务构建集中式日志解决方案的方式是和VPCflow配置的方式是不同的，需要注意。

集中式日志存储实现快速演示

接下来我们快速演示下集中式日志存储架构。
我们介绍下演示的架构，使用两个AWS账户，在后面的演示中我们统一把把左边的账户成为中央账户或者ACCOUNT A，将右边的账户成为ACCOUNT B。我们将ACCOUNT B的config和CloudTrail日志集中存储至中央账户的S3对应的两个存储桶中。

当然，这个架构是只是使用了2个账户的架构，您的组织中可能还存在着account c,d,e，分别可以配置这些账户将对应的日志转发至中央账户的S3存储桶中集中存储，实现集中式日志存储架构。

登陆ACCOUNT A ，查看日志生成情况

我们现在登陆了中央账户account A，我们使用这个账户负责集中式日志存储。
打开S3控制台，可以看到有两个和本次演示相关的S3存储桶，iloveaws-central-config和iloveaws-central-cloudtrail,负责存储来自不同账户ACCOUNT B对应的aws config和cloudtrail日志。

我们快速打开ioveawscn-central-cloudtrail存储桶，可以看到来自另外一个aws账户ACCOUNT B的CloudTrail日志已经成功转发过来了，在s3存储桶中是按照账户id目录进行存储的，这个2732数字的文件夹就是account b的账户id。

登陆ACCOUNT B

我们切换到账户account b浏览器，我们看下ACCOUNT B账户id,和刚才在中央账户中的cloudtrail存储桶的文件夹的账户id是一样的。也就是说目前中央账户的s3存储桶中已经存储了来自不同AWS账户的ACCOUNTB的cloudtrail日志。

下面我们进入到account b的cloudtrail控制台，进入跟踪，我们看下我们已经创建好的配置。在存储位置部分，可以看到我们已经完成将中央账户的s3存储桶ioveaws-central-cloudtrail配置到了cloudtrail配置的存储位置。

完成这一步后还无法成功转发日志到中央账户的s3，因为S3要开放相应的策略允许它访问。

登陆ACCOUNTA，查看存储桶策略

我们切换到中央账户的这个S3存储桶，我们提前配置好了存储桶策略，策略的作用是允许account B的cloudtrail日志转发写入这个存储桶。这里显示了具体的存储桶策略的内容，我们指定了cloudtrail.amazonaws.com这个aws service允许对这个存储桶GetBucketAcl ，PutObject行为，这个策略内容我之后会附到课程后面，大家直接复制修改后就可使用。

以上是cloudtail对应的配置演示。

我们前面演示了CloudTrail如何配置构建集中式日志存储，参照配置，可以将组织中所有账户的cloudtrail日志转发到中央账户的S3存储桶中集中存储。前面提到过不同的AWS服务（CloudTrail，VPCFlow）构建集中式日志解决方案的配置方式各不相同。同样cloudtrail和aws config的配置方式是不同的，我们下面将快速演示下aws config 日志如何配置构建集中日志存储。

我们回到中央账户的s3控制台，打开用于存储config日志的iloveawscn-central-config存储桶，我们同样可以看到来自于不同账户account b的aws config日志已经成功写入存储桶中

登陆ACCOUNT B

我们切换到account b打开aws config控制台，进入设置，查看s3存储桶配置部分，同样，可以看到我们已经将中央账户的s3负责存储config日志的存储桶名称配置到了这里。

为了将accountb的aws config日志转发到中央账户相应的存储桶中，我们同样要为config日志的存储桶配置存储桶策略，我们切换到中央账户的s3控制台，打开存储桶策略，我们看下我们已经配置策略的内容，基本上和前面cloudtral的策略差不多，Service这里我们改成了config.amazonaws.com。

好的，以上就是我们今天的课程内容，我们下节课将从头开始配置本节课的快速演示内容，配置CloudTrail和aws Config日志实现跨AWS账户日志存储。