1. Athena 查询长时间无反应，也不扫描数据

Athena是serverless服务，因此会使用公用的资源池，提供不同的使用者所提交的各个查询一同使用资源。当一个查询被提交时，Athena系统会估算该查询需要用到的资源数量，并向资源池申请资源，成功获得资源后，会将相关的Stage与Task派发在这些资源的Presto worker上运行。在这一系列的工作流程中，若资源池的资源较为稀缺时，则从申请资源到成功获得资源所耗费的时间就会比较长。
通常资源相关的问题，可以借由重试（将完全相同的查询命令重跑一次）来解决。因为Athena会自动弹性维护资源池，重试操作会发出新的查询，重新发出申请资源的请求，提高申请到底层资源的机率。在大多数情况下，资源相关的问题都能够借由重试来解决。
为什么我的 Amazon Athena 查询运行时间很长

2.elasticache 创建后连接不上

外网是要开传输加密后才能连的，先看内网连接。
创建时不选传输加密内网时可以直接连的，不需要特殊设置。
不能连的话，先检查集群的安全组有没有对内网测试的ec2放开6379的权限，
telnet 测试下主终端节点通不通。
通的话说明网络正常，看下开了传输加密没有，开的话要加 --tls 参数才能连。
连接到集群节点

3. vpc 内无法解析内网域名地址

看下你的vpc属性那里，开了 dns 解析没有，开了当前 vpc 内的地址肯定是可以解析的。
还有种情况是跨 vpc的，开了vpc peering的，一个vpc内的机器没法解析另一端的vpc的内网域名地址，
这个需要特殊设置dns的域名解析，具体参考下面的文档
实现对对等连接的 DNS 解析

4. rds mysql 中的 rdsadmin

在 rds mysql 中查 user 表，能发现一个用户叫 rdsadmin，这个是 aws 自己建的，用于管理集群升级备份等操作的。不要去删除，修改这个用户和它的权限，会导致集群出错的。

18f1e835934892f1f74b8dcb11d5590.png

5. GA 详细日志和监控分析

如果想要查 ga 的日志和监控信息，比如网络波动或者用户连接情况，只能用 aws cli 开 ga 的 flow log 。 之后用 athena 去查。查询 AWS Global Accelerator 流日志 。

6. glue 表版本的配额限制

glue 中的表在没修改一次表设置（表结构，名称，路径等）都会生成一个历史记录，每个历史记录都有一个版本号，是从0开始的自增序列。默认的上限是10万。虽然看着很多，但是如果你的代码里有经常修改表设置的，还是有可能刷满配额的，这个时候就不能再修改了。你可以开 case 提升这个配额，不过有上限总会打满的，可以使用 aws 的接口批量删除旧的版本。

7. lambda vpc 内访问其他账号的 S3

有些服务在 vpc 私有子网，为了访问这些服务，lamda 也要搭在 vpc 内，这时 lambda 需要 nat 才能访问到公网的资源，但是如果访问的是 aws 的服务的话，可以创建对应服务的终端节点，让 lambda 直接在内网访问到这些服务。因此也可以通过终端节点访问 s3，不过终端节点是建在 vpc 上的，你的 vpc 和你的 s3 桶必须在同一 region，否则 lambda 会直接报 time out。
同一 region 下的 s3 其实都是在同一个地方，即使账号不同。所以建了终端节点后，内网访问其他账号的 s3 桶也是可以的。

8. EMR 中 yarn 可调度的内存很少

启动了2台 m5.xlarge 的 emr 集群，总的内存 32GB，但是在 yarn 的 web 页面看到总内存才12GB。这应该是个bug，根据文档，单台 m5.xlarge 的 yarn 可用内存应该是 12GB 多点。试了其他机型，都是和文档相符的。不过这个参数也可以在控制台修改，调整到文档给出的值就好。
yarn.nodemanager.resource.memory-mb
yarn.scheduler.maximum-allocation-mb
任务配置 - Amazon EMR

9. 报权限错误时带了一串编码的字符串

有时遇到一些权限上的错误，控制台上或者 cli 会报出如下的错误，后面还跟了很长的编码后的字符串，这个的意思是权限错误的具体信息被加密了，想要得到原信息必须用报出这个错的账号去执行 decode-authorization-message 这个命令去解密。注意：执行这个命令也需要单独的权限，请先确保你有sts服务下的这个权限，再去执行解密命令。
Service role test-emr-role has insufficient EC2 permissions. EC2 Message: AmazonEC2Exception: You are not authorized to perform this operation. Encoded authorization failure message
Amazon EC2 中 RunInstances 的编码授权失败

10. EMR 扩充 core 节点的磁盘空间

emr 中 yarn 的日志默认是保存在 hdfs 上的，保存期限是2天，物理位置是在 core 节点上。100G的节点实际只有30G左右可以用来存日志，3台 master 的话就是100G。如果你的日志刷的过快，把hdfs写满了，程序就会报错，这时要么调节日志保留期，要么扩core节点的存储空间。
扩充存储空间需要在ec2页面操作，EMR是没有直接修改磁盘的设置的，就把core节点当作一个普通的ec2实例，找到对应的ebs磁盘，然后调整大小，再到实例里面扩容就好了。
需要注意的是，core有两个硬盘设备