十年运维开发经验的王义杰在此分享自己的知识和经验

“显式子网关联”是我们主动的设计，而“未显式关联的子网”则是一种默认回退机制，它们会自动归属于主路由表的管辖。虽然关联方式本身不直接决定网络通断，但它决定了子网最终会使用哪一套“交通规则”。

CloudFormation是AWS生态的基石之一。它将基础设施的管理从繁琐的手工操作，转变为严谨、可重复、自动化的代码工程。

理解CloudTrail事件和原生服务事件的区别，是掌握EventBridge精髓的关键一步。为了安全和审计选择CloudTrail事件，为了自动化和编排选择服务原生事件。

通过创建一个简单的“捕获所有”的EventBridge规则，并将事件输出到CloudWatch Logs，我们彻底解决了事件模式“盲猜”的难题。这个方法将EventBridge规则的创建过程，从一个充满不确定性的猜测游戏，变成了一个精确、高效的工程任务。

安全是一场永不停止的攻防博弈。对于金融系统而言，与其等待安全事件发生后亡羊补牢，不如利用AWS提供的强大工具，构建一套主动、实时、自动化的入侵检测系统。

本文探讨了从AWS RDS MySQL迁移到Aurora MySQL实现"无缝迁移"的方案。主要推荐使用Aurora读取副本实现近乎零停机的迁移，需经历创建副本、监控延迟和计划切换三个步骤，会有分钟级短暂写入中断。对于更高要求场景，建议采用数据库代理、AWS DMS或蓝绿部署等复杂方案实现秒级切换。文章强调应根据业务需求选择方案，并做好测试验证和回滚准备。总体来说，通过合理方案可以实现数据零丢失、服务影响极小的平滑迁移。

本文对比AWS两种主流关系型数据库的差异，重点分析高可用架构和关键功能。RDS MySQL采用主备架构，故障切换需60-120秒；Aurora MySQL采用计算存储分离设计，故障切换<30秒，支持15个低延迟只读副本。两者都支持审计日志，但Aurora在性能（吞吐可达5倍）、存储自动扩展（最大128TB）和高级功能（如秒级回滚）方面更具优势。对于需要高可用集群审计日志、高性能和扩展性的场景，Aurora MySQL是更优选择，但需注意成本评估和迁移测试。

“Multi-AZ”的世界比我们想象的要丰富。实例追求的是兼容性和坚如磐石的可靠性，而集群则是在此基础上，为极致读性能和快速恢复开辟了新的道路。它们没有绝对的优劣，只有场景的匹配度。

通过“Cognito 托管 UI + 本地助手工具 + `credential_process`”这套组合拳，我们成功地在受限的单一账户环境中，实现了堪比官方 IAM Identity Center 的 CLI 单点登录体验。

虽然我们无法使用组织级的 IAM Identity Center，但这并不意味着我们必须在安全上妥协。通过组合 Cognito 用户池和身份池，我们成功地为自己构建了一个轻量、安全、且支持 MFA 的 CLI 登录解决方案。

IAM Identity Center 有两种不同“工作模式”，账户预置模式：中央集权的总司令部；应用程序预置模式：各司其职的分支机构

摘要： 本文介绍了如何通过AWS IAM Identity Center实现用户权限管理，取代传统IAM用户模式。核心在于解耦“用户”与“权限”，通过三步完成授权： 创建权限集：定义权限模板（如开发者权限）； 分配访问权限：将用户组与权限集绑定到目标AWS账户； 用户登录：通过访问门户直接使用分配的角色。 该方法简化了多账户权限管理，新增用户只需加入对应组即可自动继承权限，提升安全性与效率。

AWS Cognito与IAM Identity Center的核心区别在于服务对象：Cognito面向外部应用程序用户（B2C/B2B），提供注册、登录和访问控制功能，适合电商App等场景；而IAM Identity Center针对企业内部员工（B2E），集中管理多账户和SaaS应用的SSO访问权限，适合企业IT管理。Cognito作为服务提供商支持社交登录，按活跃用户收费；Identity Center作为身份提供商免费提供企业级权限管理。关键选择标准是区分用户群体——服务客户用Cognito，管理员

AWS Cognito 提供了一套全面且灵活的用户认证和管理解决方案。通过理解用户池和身份池的核心概念，掌握不同的认证流程，并遵循安全最佳实践，开发者可以快速、安全地为应用添加强大的用户认证功能。

临时凭证的可移植性体现了 AWS 身份系统的灵活性。但真正的高手，懂得何时利用这种灵活性，何时坚持 AWS 提供的安全模式（如 IAM Identity Center）。

直接给用户加权限，是一种“所有权”的思维模式——“我拥有这些权限”。而使用角色扮演，是一种“使用权”的思维模式——“我只在需要时，临时获取这些权限的使用权”。

aws sts assume-role 是 AWS 安全体系的基石之一。对于 AWS 运维工程师而言，请务必将“使用 CLI Profile 扮演角色”作为我们的标准操作流程。这不仅是衡量专业性的一个标准，更是保护云上资产安全的最佳实践。

事件驱动架构（EDA）之所以强大，并不仅仅因为它是一种先进的软件设计模式，更因为它促使我们从一种“命令式”的思维（服务A 命令 服务B去做某事）转向一种“声明式”或“广播式”的思维（服务A 声明 发生了某事，任何感兴趣的服务都可以去响应）。

AWS EKS中使用ALB Ingress Controller时，ip目标类型因性能优势备受青睐，但常遇到目标组显示"unhealthy"问题。这是由于安全组配置不当导致ALB节点无法访问Pod IP。核心在于正确配置Pod安全组(SG_POD)的入站规则，源应设置为ALB安全组(SG_ALB)而非具体IP。通过理解流量路径、检查NACLs规则和利用VPC Flow Logs等工具，可以有效排查问题。合理使用Security Groups for Pods和ALB Ingress Co

文章摘要： AWS EKS集群使用ALB Ingress Controller时，Pod更新后Target Group会出现"Unused"状态，导致服务中断。通过排查发现，问题的根源在于子网标签配置错误：一个子网仍标记着旧集群名称（cex），导致当前集群（xxx-test）的Controller忽略该子网。修正方法是为子网更新正确的集群标签（kubernetes.io/cluster/xxx-test: shared）。本文详细记录了从问题定位到解决的完整过程，并强调精确子网标签管理对

CloudWatch Container Insights 的 `pod_cpu_utilization` 指标是 Pod 在一段时间内**平均 CPU 使用率**，以节点总 CPU 为基准。它与 `kubectl top` 的区别在于单位（百分比 vs 毫核）和时间粒度（平均 vs 实时快照）。

最简单且推荐的解决方案是使用以下mysqldump如果仍然遇到问题，可以手动编辑 SQL 文件或使用--force导入，但需谨慎检查结果。