给你两点建议：1、在本机测试无需安装IIS，下载一个AWS软件可以替代IIS，使用很简单，很方便。2、根据你说的情况：一、本身的模板就存在问题，有些在网上下载的模板后台本身就有问题，比方说：后台有些功能附加了一些图片，所以就不能修改。再就是数据库的链接存在问题，代码与代码的连接存在问题。二、就使是能修改里面的数据也有一定问题的存在，比方说：修改之后不能生成页面等。
建议你使用新云或者动易的模板，这些模板功能还是比较全面的。推荐你先看一看这个模板：,这个就是新云的模板，还是可以的。
希望对你有所帮助。
本回答由网友推荐
AWS分布在全球12个区域里
每个区域对应着一个地理位置，里面含有多个Availability
Zones(可用区)。这些区域设置在北美，南美，欧洲，中东，非洲，亚太区。
每个AZ实质上是单个数据中心，尽管它们可由多个数据中心构建。
每个AZ有着独立的供电系统和互联网连接。
不同AZ之间以低延迟网络进行连接，这种快速网络可消除物理位置带来的速度影响。
每个区域含有至少两个AZ，共计32个AZs。
借助AZ可创建高可用性的程序架构。
AWS在全球还分布有53个偏远区域(Edgelocations)
偏远区域的使用对象是CloudFront，这是Amazon的内容分发网络(CDN)和DNS服务器。
偏远区域的存在使得全球用户都可以享用低延迟网络而不论他们身在何处。建立区块服务(BlockServices)
Amazon透过AWS创建了大量高可用和高容错的服务，具体的服务清单可点击这里查看。
缴纳一定的费用，你就可以在个人的应用中使用这些服务而不必为高可用性而忧心。
部分服务位于一个AZ中：CloudFront,Route53,S3,DynamoDB,ElasticLoad
Balancing,EFS,Lambda,SQS,SNS,SES,SWF。
即使是使用单个AZ的服务，其高可用架构也是足够强大的。
在这个时候，开发者=用户。你的架构看起来是这样的：
运行单个实例，如t2.micro。你可以为你的服务器选择不同的CPU，内存，存储设备和网络环境。
该服务器承载了全部web任务，如：web应用，数据库，管理器等。
使用AmazonRoute53进行DNS管理。
为该实例附加一个ElasticIP地址。
那么随着用户数的增加，我们需要如何进行升级改造，直至能为千万用户提供优质的服务呢？强调文字
采用多主机模式
尝试使用Amazon数据库服务，如AmazonRDS(关系数据库)，AmazonDynamoDB(NoSQL数据库)，AmazonRedshift。
逐步从SQL数据库转为NoSQL数据库，特别是数据量超过5TB，你的应用对低延迟敏感的时候。
使用ElasticLoadBalancer(弹性负载均衡器)，它可以对主机进行健康检测以确保网络的通畅，同时可以帮助实现网络的扩展。
需要更强的实例类型，例如c4.8xlarge或者m3.2xlarge。
停止使用当前的服务器，换用功能更强大的机器，如：244GBRAM，40核CPU。
某些Amazon服务提供了ProvisinedIOPS选项以便用户自行配置变更，这样一来用户可以使用类似DynamoDB的扩展服务。
类似上面的做法就叫做垂直升级。但其有个缺点，就是一旦机器出错，你的网站也会停止运作了。所以要尽量避免单个实例的做法。
如果你一直在为峰值负载而努力，如黑色星期五，那么其实是在浪费金钱。更好的解决方案
是按需分配，这就是AutoScaling(自动扩展)，在计算机群组中实现自动化的大小变更。
你可以为你的容量池定义最大值和最小值。
CloudWatch是一个管理服务，已内置到所有的Amazon应用中。
CloudWatch事件会触发扩展。
触发事件可以是CPU占用率，时间延迟，网速等等。
你也可以向CloudWatch导入自定义基线，按照你的意愿来触发扩展。
使用SOA/微服务，使你的服务层组件化。
这样做的好处是单独的服务可以独立地进行扩展，从而大大增加了灵活性和可用性。
SOA是Amazon提供的重要架构组件。
避免重复劳动
把精力投入到能使你的业务与众不同的事情上。
Amazon提供了很多高容错的服务。例如，排队(SQS服务)，邮件，转码，搜索，数据库，监控等等。所以类似的服务都不必再次编写了。
用户数>千万+
当用户达到千万级别的时候，你考虑的策略应该是这样的：
多AZs模式
在不同层之间执行ELB(弹性负载平衡)。除了web层，在应用层，数据层等层里也需要进行ELB。
能够自动扩展
使用面向服务的架构
缓存架构内和外的数据
使用AmazonS3和CloudFront。S3用于存储静态数据，如js，CSS，图像等，具有足够的扩展性。CloudFront可对数据进行缓存。
使用AmazonSES来进行邮件发送。
使用CloudWatch进行监控。
对数据写入执行如下的策略：
联结–根据功能划分不同的数据库。
分表–把一个数据集分解到多个主机上。
把部分功能放到其他类型的数据库上（NoSQL,graph等）。
不断优化你的应用和整个架构堆栈，针对瓶颈进行分析并找出解决方法。
模板建站和智能建站有啥区别？反正不是用技术原生建站就是了 这样的产品可定制性太低 原生建站就是任你行
建站策划：传统建站前期都是需要根据客户自己的需求来设计网站的，好的沟通能减少大量的时间成本，甚至有些客户都不知道从哪里入手，甚至要求开发人员帮客户制定行业需求而开发人员对客户所在行业又不甚了解，所以需求描述肯定会有部分瑕疵，这样会增加后期需求改动成本。
2
建站时间：传统建站一般需要半个月甚至一个月以上，对于想快速建站，肯定是等不起的，这么长时间的建站时间，时效性已经不再。模板建站一般是需要2到3天就可以完成，即使需要微调版面和改版设计也是很短时间完成，因为大致的框架早就设计完成。
3
网站后期维护和升级传统建站在后期维护方面比较麻烦，因为大多数建站公司的后台都是使用用他们自己公司的后台，而不是我们常见的织梦和帝国，这样需要升级和维护需要联系他们，这样也需要交纳一定费用。模板建站都是使用的是开源的网站管理系统后台：比如：“海站堂”的织梦模板和帝国模板，这样自己看看相关教程就可以完成对网站升级和维护，简单方便而且还免费。
4
建站费用：传统建站由于需要很多步骤，建站时间又长，所以价格也不菲，一般会是上千元以上，稍微增加一点功能的网站甚至价格在几千上万元。这是一般的中小站长不能承受的。模板建站几百元就可以完成，在较短时间内使用符合优化的模板这样节约建站时间让客户利益最大化。
第二部分介绍如何建模、构建和组织您的基础设施即代码 AWS CDK 项目。在 AWS 云中从头开始构建直到 CI/CD 管道组合、所有云组件资源和服务。
欢迎回来！这是两部分文章系列的第二部分。在本文中，我的目标是构建一个蓝图，展示如何使用 AWS-CDK 框架对我们的基础设施即代码项目进行建模、组织和构建。点击此处访问本文的第一部分。
现在，正如所承诺的，在第二部分中，有趣的部分来了，我们开始动手。让我们运行我们的 AWS CDK IaC 项目，部署所有服务和资源，然后查看 AngularJS 应用程序启动并运行。让我们开始吧。
开始之前 - 之前的步骤我们的 AWS CDK 项目使用 Python 语言，因此在开始之前，我们需要执行一些前面的步骤，例如创建和激活 Python 虚拟环境、下载项目的 AWS-CDK 库依赖项，并确保您已经安装AWS CDK 工具包。AWS CDK Toolkit 是使用节点包管理器 (npm) 安装的，有关更多信息，请查看此处。
这是他们：
在（并且如果您）运行 ./scripts/run-checks.sh 之后，您会看到以下错误：
壳
error: Library stubs not installed for "yaml" (or incompatible with Python 3.8) [import]
要解决此问题，请运行以下命令：
python -m pip install types-PyYAML
现在，在继续之前，在同一个终端会话中，不要忘记为您要部署解决方案的 AWS 账户打开一个有效的 AWS CLI 会话。
AWS CDK 项目附带了一个 Makefile，其中包含一些规则，这些规则试图帮助一些可重复的任务/脚本，主要是那些我们通常会忘记的，在该项目一段时间不活动之后。要检查所有这些，只需运行不带参数的 make。请记住，其中一些规则/脚本可能需要设置环境变量，例如 AWS 账户和区域（检查 ./scripts/set-env-template.sh）。稍后，我们将使用这些 Makefile 规则中的一些来使我们的生活更轻松。
让我们尝试一下，在这个 CDK 应用程序中显示所有 Stacks 的列表，并选择一个（或全部）进行合成（AWS CloudFormation 模板翻译），执行以下命令：
make synth
Bootstrapping在使用 AWS CDK 部署任何东西之前，我们需要准备环境（AWS 账户和区域的组合）。为此，我们必须提供 AWS CDK 执行部署所需的资源。诸如用于存储文件的 Amazon S3 Bucket 以及授予执行部署权限的 IAM 角色之类的东西。供应这些初始资源的过程称为引导。
使用命令make check-bootstrap我们可以检查我们所有环境的引导状态，无论它们是否已经引导。
有关此的更多信息，请查看此处。
部署现在，让我们部署解决方案。请记住，我们在本文第一部分中看到的配置 YAML 文件具有将用于部署每个不同阶段的 AWS 账户和 AWS 区域。
在app.py中，我们deployment.py两次实例化 IaC 建模应用程序（定义在 我们将两者都添加到cdk.AppAWS CDK 应用程序的根构造中。
当然，我们可以单独和隔离地部署每个阶段。例如，仅部署 Dev 阶段（AwsSkillsMapping-DEV/Stateful 和 AwsSkillsMapping-DEV/Stateless）。在执行特定 Stacks 部署的情况下，请记住本文第一部分中提到的依赖关系。出于同样的原因，要部署所有解决方案（所有堆栈，包括管道），让我们使用名为deploy-all的 Makefile 规则/脚本。它将以正确的顺序部署它们，首先是 Dev/* 和 Preprod/*，然后是 Pipeline。下面是开始前的顺序：
make deploy-all
现在是喝咖啡的好时机……
一段时间后，在 Pipeline 部署的中间，配置的电子邮件./configuration/pipeline.yml（用于 sre-team 和 application-team）将收到一条通知，要求他们确认订阅，如下所示：
我们等到...
检查结果部署完成后，我们将找到一个名为 deploy-outputs-dev-preprod.json 的文件，我们可以在该文件中的 AwsSkillsMapping-DEV-Stateful 和 AwsSkillsMapping-PREPROD-Stateful 部分中找到 S3 网站 URL。但在我们的导航器中打开它们之前，我们必须至少运行一次管道（在 S3 存储桶中部署 AngularJS）。
注意！Pipeline 应用程序仍在由 AWS CDK 部署期间，在一切完成之前，将触发 CodePipeline 发布，这可能会失败，并显示类似以下内容：“未授权执行：codebuild:StartBuild on resource ”。发生这种情况是因为管道部署仍在进行中。在 Pipeline 部署真正完成后，您可以在 CodePipeline 中点击 Build-DEV 阶段失败的“重试”按钮，或者只是启动一个新的 CodePipeline Release。
如果我们确认之前提到的订阅，我们将收到一封通知电子邮件，说 de CodePipeline 需要我们的批准。此时，我们的 AngularJS 应用程序的 Dev 阶段已经部署，并且 CodePipeline 停止等待 Approvals 继续进行 Pre prod 部署。
你在这！CodePipeline 发布成功完成后，我们可以打开两个 S3 网站 URL。为了在视觉上轻松地区分 Dev 和 Pre 产品，AngularJS 应用程序为它们中的每一种都提供了不同的工具栏颜色。不要忘记（为了节省一些钱），记得清理所有资源，你可以使用命令make destroy-all。
下一步是什么？作为“进化”的下一步，我们可以提取我们在这个 AWS CDK 项目中使用的一些逻辑单元（例如 API），并将它们转换为其他项目的可重用组件，即创建我们自己的“通用”可重用构造。然后，我们可以编写自己的 AWS CDK 云组件库（已经嵌入了一些技术或业务语义），使我们自己的通用构建块对所有其他 IaC AWS CDK 项目有用。这样，例如，一个团队可以创建一个 DynamoDB 表组件，该组件封装了公司的最佳实践和策略，已经嵌入（例如备份、监控、扩展等）。对于 Python，使用 Python 包安装程序（pip、PyPI）处理这些库。
但这将是未来另一篇文章的故事。:-)
结论（第 2/2 部分）在这篇由两部分组成的文章的第二部分中，我们完成了部署 IaC AWS CDK 应用程序的所有步骤，以及使用 CodePipeline 的 AngularJS 应用程序示例。我们测试了实施的设计模型、结构和组织是否满足我们的需求（目前），并帮助我们实现使用 AWS CDK 框架构建 IaC 项目的目标。大多数情况下，这个项目旨在成为一个沙盒，一个“活”的蓝图模型，我们不断分析、检查、思考和修改，寻求改进，让我们做得更好。
此 IaC AWS CDK 项目的源代码以及此蓝图解决方案中使用的所有工件都可以在下面提供的两个 Github 存储库中找到：
AWS 技能映射 IaC
