AWS 面试核心知识点 & 常见问题 (答案增强版)
这份指南旨在帮助您准备 AWS 云计算相关的技术面试。它涵盖了从基础核心服务到高级架构设计的关键知识点，并附带了高频面试问题及参考答案。面试不仅仅是考察您对 "是什么" 的记忆，更重要的是考察您对 "为什么" 和 "怎么做" 的理解。请重点关注服务之间的对比、场景应用和最佳实践。
一、 计算服务 (Compute)
EC2 (Elastic Compute Cloud) - 虚拟服务器
AWS 的基础，提供可调整大小的计算能力。核心概念包括：实例类型、AMI (亚马逊系统镜像)、安全组 (Security Groups)、EBS (弹性块存储)、Spot/On-Demand/Reserved 实例。
常见问题：
- 什么是 EC2？你用它做过什么？
答：Amazon EC2 是一种 Web 服务，可在云中提供安全并且可调整大小的计算容量，就像一个虚拟服务器。在过往的项目中，我主要用 EC2 来：
1. 部署 Web 应用：将后端 API 服务打包成 Docker 镜像，部署在由 Auto Scaling Group 管理的 EC2 集群上，并通过 Application Load Balancer 对外提供服务。
2. 运行批处理任务：对于一些需要较长运行时间的周期性数据处理任务，我们会启动 EC2 实例来执行，任务结束后再关闭实例以节省成本。
- 什么是 AMI？如何创建自定义 AMI？
答：AMI (Amazon Machine Image) 是一个**模板**，它包含了启动一个 EC2 实例所需的所有信息，主要包括操作系统、应用程序服务器和应用程序。您可以把 AMI 理解为一个虚拟机镜像文件。
创建自定义 AMI 的步骤：
1. 启动一个标准的 EC2 实例。
2. 登录实例，安装您需要的软件、更新补丁、配置环境和部署代码。
3. 在 AWS 控制台中选中这个配置好的实例，选择“操作” -> “映像和模板” -> “创建映像”。
4. 为新 AMI 命名并创建。创建完成后，您就可以用这个自定义 AMI 快速启动多个配置完全相同的实例。
- 安全组 (Security Group) 和网络 ACL (NACL) 有什么区别？
答：安全组是有状态的，作用于实例级别（实例的虚拟防火墙），默认拒绝所有入站，允许所有出站。NACL 是无状态的，作用于子网级别，需要明确设置出站和入站规则。安全组是首选的安全控制方式。
- EC2 的实例购买选项有哪些？(On-Demand, Reserved, Spot)。分别适用于什么场景？
答：按需 (On-Demand) 灵活，用于短期或不可预测负载。预留 (Reserved) 长期承诺换折扣，用于稳定负载。竞价 (Spot) 成本最低，但可能被中断，用于容错和批处理任务。
- EBS 和实例存储 (Instance Store) 的区别是什么？
答：EBS 是持久化的网络附加存储，随实例停止/终止而保留。实例存储是临时的物理附加存储，速度快但随实例停止/终止而丢失数据。
Lambda - 无服务器计算
事件驱动的计算服务，无需管理服务器即可运行代码。核心概念：事件源、触发器、冷启动 (Cold Start)、并发限制、无状态。
常见问题：
- 什么是 Serverless（无服务器）？Lambda 的工作原理是什么？
答：Serverless 是一种云原生开发模型，它允许开发者构建和运行应用程序，而无需管理服务器。开发者只需关注代码逻辑，云服务商会负责底层的服务器、操作系统、扩缩容和维护工作。
Lambda 的工作原理是事件驱动的：
1. 上传代码：您将代码（如 Python, Node.js）打包成部署包上传到 Lambda。
2. 配置触发器：将 Lambda 函数与一个事件源（如 API Gateway 的 HTTP 请求、S3 的文件上传事件、SQS 消息等）关联。
3. 事件触发：当事件发生时，AWS 会自动寻找或创建一个临时的、隔离的微容器环境。
4. 执行代码：AWS 在该环境中运行您的函数代码，处理事件。
5. 完成与关闭：代码执行完毕后，容器会被冻结或销毁。您只需按实际调用次数和代码运行毫秒数付费。
- EC2 和 Lambda 的区别是什么？什么场景下你会选择 Lambda 而不是 EC2？
答：Lambda 用于事件驱动的、短时运行的任务（如 API 后端、数据处理触发器），按调用次数和时长付费。EC2 用于需要持续运行、长时间计算或需要完整操作系统控制的应用。
- 什么是 Lambda 的“冷启动”？如何缓解它？
答：冷启动指首次调用或长时间未调用后，AWS 需要分配资源、下载代码、启动运行时的延迟。缓解方法：预置并发 (Provisioned Concurrency)、选择解释性语言 (Python/Node.js)、保持函数轻量。
二、 存储服务 (Storage)
S3 (Simple Storage Service) - 对象存储
互联网的可扩展存储。几乎无限容量，用于存储和检索任意数据。核心概念：存储桶 (Bucket)、对象 (Object)、存储类别 (Storage Classes)、生命周期策略、版本控制、预签名 URL。
常见问题：
- 解释一下 S3 的不同存储类别 (Standard, IA, Glacier, etc.) 及其适用场景。
答：标准 (Standard) 用于频繁访问；智能分层 (Intelligent-Tiering) 自动优化成本；不频繁访问 (IA) 用于长期但需快速访问的数据；归档 (Glacier) 用于极低成本的长期备份和归档，检索慢。
- 如何实现 S3 的静态网站托管？
答：启用存储桶的静态网站托管功能，上传 HTML/CSS/JS 文件，并设置公共访问权限。为提高性能和安全性，通常会配合 CloudFront 使用。
- 什么是 S3 的生命周期策略？
答：根据规则自动将对象转换到更便宜的存储类别或在指定时间后删除。例如，30天后将文件从 Standard 移到 IA，180天后移到 Glacier。
- 如何安全地让另一个用户临时访问我 S3 中的私有文件？
答：使用预签名 URL (Pre-signed URL)，它是一个带有时效性和特定权限的临时链接。
EBS (Elastic Block Store) & EFS (Elastic File System)
EBS 是 EC2 的块级存储卷（像硬盘）。EFS 是一个网络文件系统，可以被多个 EC2 实例同时挂载和访问（像网络共享文件夹）。
常见问题：
- EBS 和 EFS 的核心区别是什么？什么场景下分别使用它们？
答：EBS 只能挂载到单个可用区内的单个 EC2 实例。EFS 可以被多个可用区内的多个 EC2 实例同时挂载，适用于内容管理、Web 服务等需要共享文件的场景。
三、 网络与内容分发
VPC (Virtual Private Cloud) - 虚拟私有云
在 AWS 云中逻辑隔离出来的私有网络空间。核心概念：CIDR、子网 (Subnet)、路由表 (Route Table)、互联网网关 (IGW)、NAT 网关。
常见问题：
- 请描述一下 VPC 的基本组成部分。
答：一个典型的 VPC 由以下核心部分构成：
• CIDR 地址块：定义 VPC 的私有 IP 地址范围，例如 `10.0.0.0/16`。
• 子网 (Subnets)：将 VPC 的 IP 地址范围划分为更小的段，用于隔离资源。分为公有子网和私有子网。
• 路由表 (Route Tables)：定义网络流量的走向规则，每个子网都关联一个路由表。
• 互联网网关 (Internet Gateway)：允许 VPC 内的资源（如公有子网中的 EC2）与互联网通信。
• NAT 网关 (NAT Gateway)：放置在公有子网中，允许私有子网中的实例单向访问互联网，但互联网无法主动访问这些实例。
• 安全组和网络 ACL：用于控制进出实例和子网的流量的防火墙。
- 公有子网 (Public Subnet) 和私有子网 (Private Subnet) 的区别是什么？
答：公有子网的路由表包含一个指向互联网网关 (IGW) 的路由，子网内的实例可以直接与互联网通信。私有子网没有直接到 IGW 的路由，实例需要通过 NAT 网关才能访问互联网，但互联网无法直接访问它。
- NAT 网关的作用是什么？为什么需要它？
答：它允许位于私有子网中的实例发起出站流量到互联网（如更新补丁、调用外部 API），同时阻止互联网发起的入站连接，从而保护数据库等核心服务。
Route 53 - DNS 服务
高可用、可扩展的域名系统 (DNS) Web 服务。核心概念：托管区 (Hosted Zone)、记录集 (Record Set)、路由策略 (Routing Policies)。
常见问题：
- Route 53 有哪些路由策略？请举例说明其应用场景。
答：简单路由 (Simple)；故障转移 (Failover) 用于主备切换；地理位置 (Geolocation) 根据用户地理位置返回不同 IP（如版权限制）；延迟 (Latency-based) 将用户路由到延迟最低的区域；加权 (Weighted) 用于按比例分配流量（如 A/B 测试）。
CloudFront - 内容分发网络 (CDN)
全球 CDN 服务，加速静态和动态内容的全球分发。核心概念：分发 (Distribution)、源 (Origin)、边缘站点 (Edge Location)。
常见问题：
- CloudFront 如何帮助提升网站性能和降低成本？
答：通过将内容缓存到全球各地的边缘站点，用户可以从最近的节点获取数据，大大降低延迟。同时，用户的请求由 CloudFront 处理，减少了回源到 S3 或 EC2 的请求，节省了数据传输成本和源站负载。
四、 数据库服务
RDS (Relational Database Service) - 关系型数据库
托管的关系型数据库服务，支持 MySQL, PostgreSQL, Oracle 等。核心概念：多可用区部署 (Multi-AZ)、只读副本 (Read Replica)。
常见问题：
- RDS 的多可用区 (Multi-AZ) 和只读副本 (Read Replica) 有什么区别？
答：这是一个极其重要的问题。Multi-AZ 是为了高可用性 (High Availability)，它在不同可用区同步复制一个备用数据库，当主库故障时自动切换，用于容灾。只读副本是为了性能扩展 (Scalability)，它异步复制数据，用于分担主库的读请求压力，不能用于自动故障转移。
DynamoDB - NoSQL 数据库
完全托管的 NoSQL 键值和文档数据库，提供个位数毫秒级的性能。核心概念：表 (Table)、项目 (Item)、分区键 (Partition Key)、排序键 (Sort Key)、DAX (DynamoDB Accelerator)。
常见问题：
- 什么场景下你会选择 DynamoDB 而不是 RDS？
答：当应用需要极低的延迟、巨大的规模、灵活的 schema（非结构化数据），且查询模式相对简单固定时（如用户配置文件、游戏状态、物联网数据）。RDS 适用于需要复杂查询、事务和强一致性的关系型数据。
五、 安全、身份与合规
IAM (Identity and Access Management) - 身份与访问管理
安全地管理对 AWS 服务和资源的访问。核心概念：用户 (User)、组 (Group)、角色 (Role)、策略 (Policy)。
常见问题：
- 什么是 IAM？它的主要组成部分是什么？
答：IAM 是 AWS 的身份和访问管理服务，它让你能够安全地控制对 AWS 资源的访问。它遵循最小权限原则。
主要组成部分包括：
• 用户 (Users)：与个人或应用程序关联的实体，拥有永久的凭证。
• 组 (Groups)：用户的集合，可以统一为组附加权限策略，便于管理。
• 角色 (Roles)：一种可以被 AWS 资源（如 EC2）或其他用户代入的身份，提供临时的安全凭证，是 AWS 安全的最佳实践。
• 策略 (Policies)：一个定义权限的 JSON 文档，明确规定了允许或拒绝哪些操作（`Action`）、作用于哪些资源（`Resource`）。
- IAM 用户 (User) 和角色 (Role) 之间有什么关键区别？
答：用户 (User) 关联一个永久的个人或应用程序，拥有固定的长期凭证。角色 (Role) 是临时性的，不与特定个人绑定，任何受信实体（如 EC2 实例、Lambda 函数、其他 AWS 账户的用户）都可以代入 (Assume) 它以获取临时安全凭证。最佳实践是优先使用角色。
- 如何安全地让一个 EC2 实例访问 S3 存储桶？
答：错误答案是把 Access Key 硬编码在代码里。正确答案是创建一个具有 S3 访问权限的 IAM 角色，然后将该角色附加到 EC2 实例上。这样实例就可以通过实例元数据自动获取临时凭证，无需管理密钥。
六、 监控与管理
CloudWatch & CloudTrail
CloudWatch 是监控服务，用于监控资源和应用的性能指标（如 CPU、内存）、收集和监控日志文件、设置警报。CloudTrail 是审计服务，记录 AWS 账户中所有 API 调用操作日志（谁、在何时、从哪里、做了什么）。
常见问题：
- CloudWatch 和 CloudTrail 的区别是什么？
答：CloudWatch 关注“资源性能和状态”（Performance & Health），用于运维监控。CloudTrail 关注“账户活动和 API 调用”（Who did what?），用于安全审计和合规。
- 如何实现：当一个 EC2 实例的 CPU 使用率连续 5 分钟超过 80% 时，收到一封邮件通知？
答：使用 CloudWatch。创建一个 CloudWatch 警报 (Alarm)，监控该 EC2 实例的 `CPUUtilization` 指标，设置阈值为 80%，周期为 5 分钟。将警报的操作 (Action) 配置为发送通知到一个 SNS 主题 (Topic)，并订阅该主题即可。
七、 架构设计与情景题
这类问题没有标准答案，旨在考察你的综合能力、权衡取舍和沟通能力。
常见问题：
- 请你设计一个高可用、可扩展的 Web 应用架构。
答： 这是一个经典的架构设计题，我会从用户请求的流向来阐述：
1. DNS & CDN：用户通过 Route 53 将域名解析到我们的服务，并使用 CloudFront 作为 CDN，缓存静态资源（如图片、JS、CSS）到全球边缘节点，加速访问并降低源站负载。
2. 负载均衡：请求到达 Application Load Balancer (ALB)，它将流量分发到后端的计算资源，并且它本身就是跨可用区高可用的。
3. 计算层：我们使用一个 Auto Scaling Group 来管理一组 EC2 实例。这些实例分布在至少两个不同的可用区（AZ）中。当流量增加时，Auto Scaling Group 会自动增加实例数量；当某个 AZ 发生故障时，ALB 会自动将流量路由到健康的 AZ，从而实现高可用和弹性伸缩。
4. 数据库层：使用 RDS 数据库，并开启 Multi-AZ 部署。这会在另一个 AZ 创建一个同步的备用数据库。当主库故障时，RDS 会在1分钟内自动切换到备用库，保证数据服务的连续性。同时，为了分担读压力，我们还会创建一到多个 Read Replicas （只读副本）。
5. 状态与存储：用户会话等临时状态信息存储在 ElastiCache (Redis) 中，实现无状态计算层。用户上传的文件等对象数据则存储在 S3 中。
- 如何为你的 AWS 环境做成本优化？
答：成本优化是一个持续的过程，我会从以下几个方面入手：
• 正确选择购买选项：对于稳定的工作负载，使用 Savings Plans 或 Reserved Instances 代替昂贵的 On-Demand 实例，最高可节省70%以上成本。对于可中断的批处理任务，使用 Spot Instances。
• 资源合理配置 (Right Sizing)：使用 CloudWatch 和 Trusted Advisor 监控资源使用率，对 CPU、内存、磁盘使用率过低的 EC2 和 RDS 实例进行降级。
• 清理未使用资源：定期检查并删除未使用的资源，如分离的 EBS 卷、未关联的弹性 IP、闲置的负载均衡器等。
• 利用存储分层：为 S3 设置生命周期策略，自动将老旧、不常访问的数据迁移到更便宜的存储类别，如 `S3 IA` 或 `Glacier`。
• 拥抱 Serverless：对于事件驱动或流量波动大的应用，优先考虑使用 Lambda、API Gateway 等，因为它们按实际用量付费，没有闲置成本。
• 设置预算和告警：使用 AWS Budgets 设置预算告警，当成本超过阈值时及时收到通知。
- 我们的应用是单体的，部署在 EC2 上。你有什么建议来对它进行现代化改造？
答：我会建议采用逐步演进的策略，比如使用“绞杀者无花果模式 (Strangler Fig Pattern)”进行现代化改造，避免一次性重构带来的高风险。
1. 第一步：解耦前端和后端：引入 API Gateway 作为所有请求的统一入口。这样，我们可以逐个将后端的服务替换掉，而前端的调用方式保持不变。
2. 第二步：识别并拆分微服务：分析单体应用，识别出业务边界清晰、可以独立部署的模块（如用户服务、订单服务）。将第一个模块拆分出来，开发成一个独立的微服务。
3. 第三步：容器化部署：将新的微服务打包成 Docker 容器，并使用 Amazon ECS 或 EKS 进行部署和管理。容器化可以提供更好的隔离性、一致的环境和更快的部署速度。
4. 第四步：数据库解耦：为每个微服务提供独立的数据库。例如，订单服务使用关系型数据库 RDS，而用户配置服务可能更适合使用 NoSQL 数据库 DynamoDB。
5. 第五步：逐步迭代：重复第2到4步，逐个将单体应用中的功能模块拆分为微服务，直到最终完全“绞杀”掉旧的单体应用。对于一些简单的、事件驱动的逻辑，也可以直接重构为 Lambda 函数。
- 请设计一个秒杀系统架构。
答：秒杀系统的核心挑战是应对瞬时的高并发流量，保护后端数据库不被压垮。我的设计思路是“层层过滤，尽量减少对数据库的直接冲击”。
1. 前端优化与 CDN：将秒杀页面尽可能静态化，商品信息、图片、JS/CSS 等全部放在 S3 上，并通过 CloudFront 进行全球分发。这样可以扛住海量的页面刷新请求。
2. 库存预热与内存缓存：在秒杀开始前，将商品的库存数量预加载到 ElastiCache for Redis 中。所有的库存扣减操作首先在 Redis 中原子性地进行（例如使用 `DECR` 命令）。只有在 Redis 中成功扣减库存的请求，才有资格进入下一步。
3. 请求削峰与队列：在应用层，当用户点击“秒杀”按钮，请求经过 API Gateway（可以做初步限流）。通过了 Redis 库存检查的请求，并不会立即去创建订单，而是被快速地放入一个 SQS 消息队列中。然后立刻给用户返回一个“排队中，请稍后”的友好提示。
4. 异步订单处理：后端有一组由 Auto Scaling Group 管理的 EC2 实例（或 Lambda 函数），它们以自己能承受的稳定速率，从 SQS 队列中拉取消息，并进行后续的订单创建、支付链接生成等操作，最后将订单信息写入 RDS 数据库。
这个架构通过 Redis 挡住了 99% 的无效请求，又通过 SQS 将瞬时的高并发流量“削平”成后端系统可以平稳处理的流量，从而有效地保护了最脆弱的数据库层。
面试技巧小贴士
- STAR 法则：在回答情景题或项目经验时，使用 Situation (情景), Task (任务), Action (行动), Result (结果) 的结构来清晰地阐述。
- 动手实践：理论知识很重要，但实际操作经验更能打动面试官。一定要在 AWS 控制台或通过 IaC (如 CloudFormation, Terraform) 亲手搭建和部署。
- 了解 Well-Architected Framework：熟悉 AWS 的五个支柱（卓越运营、安全性、可靠性、性能效率、成本优化），并尝试将你的设计思想与之对齐。
- 保持好奇心：展现你对新技术的热情和持续学习的能力。
祝你面试顺利！