企业官网建设流程全解析

简介：这份PPT课件面向云计算初学者、高校学生及需要系统了解AWS服务体系的IT从业者，以《云计算》第三版配套教学材料的形式，梳理Amazon云计算的核心服务与典型应用场景，帮助读者建立对公有云解决方案的整体认知。资源包内含1个pptx文件，大小约2.85MB，以图文并茂的幻灯片呈现，便于课堂讲解与自学翻阅。内容从基础存储架构Dynamo切入，依次讲解弹性计算云EC2、简单存储服务S3、非关系型数据库SimpleDB与DynamoDB、关系数据库RDS、简单队列服务SQS、内容推送服务CloudFront，并延伸至Elastic Beanstalk、Route 53、VPC、SNS与SES、弹性MapReduce、Redshift、AppStream、Kinesis等多项服务，最后结合AWS应用实例与小结收束。目前已有454人学习浏览，适合作为云计算课程配套资料或AWS入门参考，帮助读者快速把握各服务的特点、功能定位与适用场景。

1. 从一份 PPT 说起：AWS 云计算到底在讲什么

很多人第一次接触 AWS，是从一份《Amazon云计算AWS介绍.pptx》开始的。翻完几十页幻灯片，满眼是 EC2、S3、IAM、VPC，合上电脑却不知道从哪下手。这个标题背后真正的问题不是“AWS 是什么”，而是“我该怎么用 AWS 把一台服务跑起来，并且知道钱花在哪、坑埋在哪”。它适合三类人：准备转云计算运维工程师的初学者、需要把本地服务搬上云的后端开发、以及被要求做技术选型却对云账单心里没底的小团队负责人。这篇笔记不逐页翻译 PPT，而是顺着这份介绍里最该被讲透的主线——计算、存储、网络、权限、计费——把每一步落到能复现的命令和参数上。读完你至少能独立开出一台按量计费的实例、挂上一块对象存储、配好最小权限，并且知道哪些默认设置会让你月底收到一张意外的账单。

2. AWS 全球基础设施与核心服务选型：先搞懂区域、可用区和计费单位

2.1 区域、可用区、边缘站点到底怎么选

AWS 把基础设施分成区域（Region）、可用区（Availability Zone，AZ）和边缘站点。区域是地理上独立的数据中心集群，比如东京、新加坡、法兰克福；每个区域内部由多个物理隔离的可用区组成，AZ 之间用低延迟专线互联。选区域的第一原则不是“离我近”，而是“离我的用户近且合规”。如果你的用户主要在华东，选东京或首尔通常比选美东延迟低得多；如果业务涉及数据驻留要求，就得先确认目标区域是否满足。

可用区的意义在于容错。把同一套服务部署在同一个区域的两个 AZ，一个 AZ 断电时另一个还能扛。但要注意，AZ 之间的内网流量虽然快，跨 AZ 的数据传输是要计费的，很多新手把主从数据库放在不同 AZ，月底发现流量费比实例费还高，这就是没算清计费单位的血泪经验。

边缘站点是 CloudFront 这类 CDN 服务用的，和你在控制台开 EC2 的区域不是一回事。做静态资源加速时，源站放在哪个区域、边缘缓存怎么配，直接决定回源流量成本。

2.2 计算、存储、网络、权限四类核心服务对照

一份合格的 AWS 介绍 PPT 通常会把这四类服务各列一页，但真正落地时你需要知道它们之间的依赖关系。下面这张表是我给团队新人做培训时用的最小对照，只列最常用的入口服务。

选型的顺序建议是：先定区域，再划 VPC 网段，然后在 VPC 里开 EC2 或配 Lambda，最后用 IAM 把权限收紧。反过来先开实例再补网络和权限，很容易出现实例在默认 VPC 里、安全组全开、根账号密钥满天飞的局面。

2.3 用 AWS CLI 完成第一次身份验证与区域配置

在动手开资源之前，先把命令行工具配好。控制台点选虽然直观，但批量操作和复现步骤必须靠 CLI。安装 AWS CLI v2 后，用 IAM 用户的访问密钥做初始化配置。

# 安装 AWS CLI v2（以 Linux x86_64 为例） curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" unzip awscliv2.zip sudo ./aws/install # 配置凭证，区域设为 ap-northeast-1（东京） aws configure # 依次输入 Access Key ID、Secret Access Key、默认区域、输出格式 json # 验证身份和区域 aws sts get-caller-identity aws ec2 describe-regions --query "Regions[?RegionName=='ap-northeast-1']"

aws configure会把凭证写入~/.aws/credentials，区域写入~/.aws/config。sts get-caller-identity返回当前身份，如果报InvalidClientTokenId，说明密钥错了或没启用。describe-regions用来确认目标区域可用。注意不要用根账号的密钥，也不要把密钥提交到 Git 仓库，这是最常见的翻车点。

提示：生产环境建议用 IAM 角色（Role）而不是长期访问密钥，EC2 实例绑定角色后无需在机器上存密钥。

3. 用 EC2 和 S3 搭出最小可用环境：从开实例到传文件

3.1 创建 VPC 与子网：别直接用默认 VPC

默认 VPC 在每个区域自动存在，网段通常是 172.31.0.0/16，所有实例共享。做实验可以，但一旦要接数据库、做网络隔离，就必须自建 VPC。下面用 CLI 建一个 10.0.0.0/16 的 VPC，并在两个 AZ 各开一个子网。

# 创建 VPC VPC_ID=$(aws ec2 create-vpc --cidr-block 10.0.0.0/16 \ --query 'Vpc.VpcId' --output text) aws ec2 create-tags --resources $VPC_ID --tags Key=Name,Value=my-vpc # 在东京区域的两个 AZ 创建子网 SUBNET_A=$(aws ec2 create-subnet --vpc-id $VPC_ID \ --cidr-block 10.0.1.0/24 --availability-zone ap-northeast-1a \ --query 'Subnet.SubnetId' --output text) SUBNET_C=$(aws ec2 create-subnet --vpc-id $VPC_ID \ --cidr-block 10.0.2.0/24 --availability-zone ap-northeast-1c \ --query 'Subnet.SubnetId' --output text) # 创建互联网网关并挂到 VPC IGW_ID=$(aws ec2 create-internet-gateway \ --query 'InternetGateway.InternetGatewayId' --output text) aws ec2 attach-internet-gateway --vpc-id $VPC_ID --internet-gateway-id $IGW_ID # 创建路由表，把 0.0.0.0/0 指向互联网网关 RT_ID=$(aws ec2 create-route-table --vpc-id $VPC_ID \ --query 'RouteTable.RouteTableId' --output text) aws ec2 create-route --route-table-id $RT_ID \ --destination-cidr-block 0.0.0.0/0 --gateway-id $IGW_ID aws ec2 associate-route-table --route-table-id $RT_ID --subnet-id $SUBNET_A

create-vpc的--cidr-block决定整个私有网段，建议用 RFC1918 地址段。两个子网分在不同 AZ 是为了后续做高可用。互联网网关让子网里的实例能出公网，但实例还需要公网 IP 或弹性 IP 才能被访问。路由表关联到子网后，该子网才真正有默认路由。如果漏了associate-route-table，实例有公网 IP 也上不了网，这是排查时第一个要看的地方。

3.2 启动一台按量计费的 EC2 实例

接下来开一台 t3.micro 实例，用 Amazon Linux 2023 镜像，绑定刚才的子网和安全组。安全组先只放行 SSH。

# 创建安全组，只允许你的公网 IP 访问 22 端口 SG_ID=$(aws ec2 create-security-group --group-name my-ssh-sg \ --description "ssh only" --vpc-id $VPC_ID \ --query 'GroupId' --output text) MY_IP=$(curl -s https://checkip.amazonaws.com)/32 aws ec2 authorize-security-group-ingress --group-id $SG_ID \ --protocol tcp --port 22 --cidr $MY_IP # 查询最新的 Amazon Linux 2023 AMI AMI_ID=$(aws ssm get-parameters \ --names /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \ --query 'Parameters[0].Value' --output text) # 启动实例 INSTANCE_ID=$(aws ec2 run-instances \ --image-id $AMI_ID --instance-type t3.micro \ --subnet-id $SUBNET_A --security-group-ids $SG_ID \ --associate-public-ip-address \ --query 'Instances[0].InstanceId' --output text) # 等待运行并获取公网 IP aws ec2 wait instance-running --instance-ids $INSTANCE_ID aws ec2 describe-instances --instance-ids $INSTANCE_ID \ --query 'Reservations[0].Instances[0].PublicIpAddress' --output text

--instance-type t3.micro是突发性能实例，适合测试，CPU 积分耗尽后会限速。--associate-public-ip-address给实例分配临时公网 IP，重启可能变化，生产环境应绑弹性 IP。authorize-security-group-ingress里的$MY_IP只放行你自己的地址，比 0.0.0.0/0 安全得多。ssm get-parameters拿到的 AMI ID 是动态的，不要硬编码某个镜像 ID，否则区域换了就找不到。

注意：t3.micro 在部分区域有免费额度限制，超出后按秒计费。测试完记得aws ec2 terminate-instances，停止（stop）实例仍然会收 EBS 存储费。

3.3 用 S3 存静态文件并设置生命周期

S3 是对象存储，适合放图片、备份、日志。先建桶，再传文件，最后配生命周期规则自动清理。

# 创建全局唯一名称的桶，区域与实例一致 BUCKET="my-demo-bucket-$(date +%s)" aws s3api create-bucket --bucket $BUCKET \ --region ap-northeast-1 \ --create-bucket-configuration LocationConstraint=ap-northeast-1 # 上传一个本地文件 echo "hello aws" > test.txt aws s3 cp test.txt s3://$BUCKET/data/test.txt # 配置生命周期：30 天后转低频存储，90 天后删除 cat > lifecycle.json <<'EOF' { "Rules": [ { "ID": "archive-and-delete", "Status": "Enabled", "Filter": {"Prefix": "data/"}, "Transitions": [ {"Days": 30, "StorageClass": "STANDARD_IA"} ], "Expiration": {"Days": 90} } ] } EOF aws s3api put-bucket-lifecycle-configuration \ --bucket $BUCKET --lifecycle-configuration file://lifecycle.json

create-bucket在非 us-east-1 区域必须带LocationConstraint，否则报错。桶名全局唯一，用时间戳后缀避免冲突。put-bucket-lifecycle-configuration里的STANDARD_IA是低频访问存储，单价低但有最小存储时长和取回费，适合不常读的备份。Expiration到期自动删除，避免长期堆积。如果桶里放的是网站静态资源，还需要开静态网站托管并配桶策略，但注意不要给桶开公共写权限。

4. IAM 权限与账单控制：把最小权限和预算告警配到位

4.1 创建最小权限的 IAM 用户与策略

根账号只用来开账号和付钱，日常操作全部用 IAM 用户或角色。下面建一个只能读写指定 S3 桶前缀的用户。

# 创建用户 aws iam create-user --user-name app-reader # 写一条只允许访问指定桶 data/ 前缀的策略 cat > policy.json <<'EOF' { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject", "s3:ListBucket"], "Resource": [ "arn:aws:s3:::my-demo-bucket-*", "arn:aws:s3:::my-demo-bucket-*/data/*" ] } ] } EOF aws iam create-policy --policy-name app-reader-policy \ --policy-document file://policy.json # 把策略挂到用户 aws iam attach-user-policy --user-name app-reader \ --policy-arn arn:aws:iam::<你的账号ID>:policy/app-reader-policy

Action里s3:ListBucket作用于桶本身，s3:GetObject作用于对象，所以Resource要写两条。arn:aws:s3:::my-demo-bucket-*用了通配符，实际生产建议写死桶名。创建策略后必须attach-user-policy才生效，只建不挂是新手常犯的错。如果需要临时凭证，用aws sts assume-role而不是给用户发长期密钥。

4.2 用预算和告警拦住意外账单

AWS 的计费是后付费，等账单出来已经晚了。Budget 可以在花费接近阈值时发邮件。

# 创建一个每月 10 美元的预算，超过 80% 告警 aws budgets create-budget --account-id <你的账号ID> \ --budget '{ "BudgetName": "monthly-10usd", "BudgetLimit": {"Amount": "10", "Unit": "USD"}, "TimeUnit": "MONTHLY", "BudgetType": "COST" }' \ --notifications-with-subscribers '[{ "Notification": { "NotificationType": "ACTUAL", "ComparisonOperator": "GREATER_THAN", "Threshold": 80, "ThresholdType": "PERCENTAGE" }, "Subscribers": [{"SubscriptionType": "EMAIL", "Address": "you@example.com"}] }]'

BudgetType选COST是按实际花费，选USAGE是按用量。Threshold80 表示达到预算的 80% 就发邮件。这个命令需要账号 ID，可以用aws sts get-caller-identity查。预算告警不是硬性拦截，只是通知，真正要硬停需要配合 Lambda 或 Service Control Policy。另外，NAT 网关、弹性 IP 未绑定、快照堆积是三个最隐蔽的扣费项，建议每周用aws ce get-cost-and-usage拉一次分服务账单。

4.3 用 CloudWatch 看基础指标并设 CPU 告警

实例开起来后，至少要知道它活着没有。CloudWatch 默认收集 CPU、网络、磁盘指标，内存和磁盘使用率需要装 Agent。

# 查看最近 10 分钟 CPU 使用率 aws cloudwatch get-metric-statistics \ --namespace AWS/EC2 --metric-name CPUUtilization \ --dimensions Name=InstanceId,Value=$INSTANCE_ID \ --start-time $(date -u -d '10 minutes ago' +%Y-%m-%dT%H:%M:%SZ) \ --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \ --period 300 --statistics Average # 创建 CPU 持续高于 70% 的告警 aws cloudwatch put-metric-alarm --alarm-name high-cpu \ --metric-name CPUUtilization --namespace AWS/EC2 \ --statistic Average --period 300 --threshold 70 \ --comparison-operator GreaterThanThreshold \ --evaluation-periods 2 \ --dimensions Name=InstanceId,Value=$INSTANCE_ID \ --alarm-actions arn:aws:sns:ap-northeast-1:<账号ID>:my-topic

--period 300是 5 分钟一个数据点，--evaluation-periods 2表示连续两个周期超阈值才触发，避免毛刺误报。--alarm-actions需要提前建好 SNS 主题并订阅邮箱。内存指标默认没有，要装 CloudWatch Agent 并在配置里开启mem_used_percent。如果告警一直处于INSUFFICIENT_DATA，先确认实例是否在运行、指标是否已上报。

5. 避坑与排查：AWS 新手最容易翻车的 5 个场景

5.1 现象：实例有公网 IP 却连不上 SSH

原因通常有三层：安全组没放行你的当前 IP、子网路由表没关联互联网网关、或者实例没有公网 IP。解决顺序是先aws ec2 describe-instances看公网 IP 是否存在，再aws ec2 describe-route-tables确认子网关联的路由有0.0.0.0/0指向 igw，最后检查安全组入站规则里的 CIDR 是不是你现在的公网 IP。家庭宽带 IP 会变，昨天能连今天连不上很常见，重新查checkip.amazonaws.com再改规则。

5.2 现象：S3 桶策略改了却依然 403

原因多半是桶策略和 IAM 策略同时存在时取交集，或者对象所有权设置阻止了访问。先aws s3api get-bucket-policy看桶策略，再确认 IAM 用户有没有s3:GetObject。如果桶开了“阻止公共访问”而你又想公开读，需要在桶级别关闭对应选项。另一个隐蔽点是 KMS 加密的桶，调用方还需要kms:Decrypt权限，否则读对象报AccessDenied。

5.3 现象：月底账单比预期高出一截

先按服务维度拉账单：aws ce get-cost-and-usage --granularity MONTHLY --metrics BlendedCost --group-by Type=DIMENSION,Key=SERVICE。常见元凶是 NAT 网关按小时和流量双计费、未绑定的弹性 IP 按小时收费、EBS 快照越积越多、跨 AZ 流量费。解决方法是给非生产资源打标签，用 Budget 告警，定期清理未挂载的卷和旧快照。免费额度只覆盖部分实例类型和存储量，超出部分照常收费。

5.4 现象：Lambda 函数冷启动慢且超时

原因可能是包体积过大、VPC 配置导致 ENI 创建慢、或者内存设太小。解决方法是精简依赖、把不常变的库放层（Layer）、给函数至少 256MB 内存（CPU 随内存比例分配）、避免把 Lambda 放进需要 NAT 的私有子网除非必要。如果必须访问 VPC 内资源，确认子网有足够空闲 IP，ENI 创建失败会直接导致调用超时。

5.5 现象：IAM 策略明明允许却报权限不足

先看错误信息里的Action和Resource是否和策略完全匹配，注意大小写和通配符位置。如果用了条件键（Condition），比如aws:SourceIp或aws:RequestedRegion，实际请求不满足条件也会拒绝。还有一种情况是服务控制策略（SCP）在组织层面做了限制，IAM 策略再宽也没用。排查时用 IAM Policy Simulator 模拟请求，比反复改策略快得多。

6. 把成本算清楚：用 Cost Explorer 和标签做一次真实复盘

6.1 给资源打标签并按标签看账单

标签是成本归集的基础。开实例和桶的时候就该打上Project、Env、Owner三个标签。

# 给实例打标签 aws ec2 create-tags --resources $INSTANCE_ID \ --tags Key=Project,Value=demo Key=Env,Value=test Key=Owner,Value=me # 激活成本分配标签（在账单控制台或 CLI） aws ce update-cost-allocation-tags-status \ --cost-allocation-tags-status '[{"TagKey":"Project","Status":"Active"}]' # 按 Project 标签拉本月成本 aws ce get-cost-and-usage \ --time-period Start=$(date -u +%Y-%m-01),End=$(date -u +%Y-%m-%d) \ --granularity MONTHLY --metrics UnblendedCost \ --group-by Type=TAG,Key=Project

update-cost-allocation-tags-status激活后，标签才会出现在 Cost Explorer 里，激活前产生的费用不会追溯。UnblendedCost是未混合成本，反映实际单价。按标签分组能直接看出哪个项目在烧钱。如果返回空，先确认标签键拼写和激活状态。

6.2 用 Cost Explorer 找出增长最快的服务

Cost Explorer 控制台可以按服务、区域、标签多维下钻，CLI 也能拉。下面这条命令按服务看最近 6 个月趋势，适合每月复盘。

aws ce get-cost-and-usage \ --time-period Start=$(date -u -d '6 months ago' +%Y-%m-01),End=$(date -u +%Y-%m-%d) \ --granularity MONTHLY --metrics UnblendedCost \ --group-by Type=DIMENSION,Key=SERVICE

输出里如果 EC2 或 S3 突然跳升，结合标签定位到具体资源。常见增长源是测试实例忘了关、日志桶没设生命周期、快照自动备份策略太激进。我自己的习惯是每月 1 号花十分钟跑一次这条命令，比等账单邮件再手忙脚乱强得多。

6.3 一个具体技巧：用实例调度和 S3 智能分层压成本

非生产实例不需要 7×24 运行。用 Instance Scheduler 或简单的 Lambda 定时启停，能省下一大半计算费。S3 这边，访问模式不固定的数据用 INTELLIGENT_TIERING，让 AWS 自动在访问层之间移动，不用自己猜什么时候转低频。

# 把桶的默认存储类设为智能分层 aws s3api put-bucket-lifecycle-configuration --bucket $BUCKET \ --lifecycle-configuration '{ "Rules": [{ "ID": "intelligent-tiering", "Status": "Enabled", "Filter": {"Prefix": ""}, "Transitions": [{ "Days": 0, "StorageClass": "INTELLIGENT_TIERING" }] }] }'

Days: 0表示上传后立即进入智能分层，AWS 根据访问频率自动调整。智能分层有监控和自动化费用，数据量很小的时候不一定划算，一般超过 128KB 的对象才建议用。实例定时启停可以用 EventBridge 加 Lambda，工作日 9 点到 19 点运行，其余时间停止，停止期间只收 EBS 费用。

这套东西我踩过最深的坑是：以为“停止”实例就不花钱，结果 EBS 卷和弹性 IP 一直在计费。后来养成习惯，实验做完直接terminate，需要保留的卷单独打标签并记进台账。云上的成本控制没有后悔药，只有提前配好的预算告警和每月复盘。希望帮到你。

本文还有配套的精品资源，点击获取