AWS共有云架构介绍

合集下载

亚马逊AWS云计算平台的介绍

亚马逊AWS云计算平台的介绍

亚马逊AWS云计算平台的介绍云计算是一种新的计算模式,其核心思想是将计算设备、数据和应用程序都存储在互联网上,使得用户可以在任何时间、任何地点通过网络访问这些服务。

目前,亚马逊AWS云计算平台已经成为了全球领先的云计算服务提供商之一。

本文就对亚马逊AWS 云计算平台做一个简单的介绍。

一、亚马逊AWS云计算平台的历史和发展亚马逊AWS云计算平台是由亚马逊公司于2006年推出的,它最初是为了满足亚马逊自身的业务需求而开发的。

1998年,亚马逊公司的规模开始急剧扩张,当时传统的客户端服务器架构已经无法满足公司的业务需求。

于是,亚马逊公司开始探索新的计算模式,最终决定采用云计算模式,即将计算设备、数据和应用程序都存储在互联网上,以便随时随地访问。

随着亚马逊AWS云计算平台的不断发展和壮大,越来越多的企业和机构开始意识到云计算的重要性,并开始采用亚马逊AWS 云计算平台来提供各种IT服务。

目前,亚马逊AWS云计算平台已经成为全球领先的云计算服务提供商之一,其用户包括了众多知名企业和机构,如NASA、Netflix、Airbnb、Dropbox、Spotify 等。

二、亚马逊AWS云计算平台的服务和应用亚马逊AWS云计算平台提供了包括计算、存储、数据库、安全、开发工具、人工智能、物联网等在内的各种服务和应用程序。

以下是亚马逊AWS云计算平台的一些主要服务和应用的介绍:1.计算服务计算服务是亚马逊AWS云计算平台的核心服务之一。

它包括了EC2、Lambda、Batch等多个服务。

其中,EC2是一种弹性计算服务,它可以让用户在亚马逊的基础设施上租用虚拟计算机实例,并以每小时收费的方式,按需使用计算资源。

Lambda是一种无服务器计算服务,它可以让用户编写和运行代码,而无需担心基础设施的管理和维护。

Batch是一种批处理服务,它可以让用户轻松地在亚马逊的基础设施上运行批处理作业。

2.存储服务存储服务是亚马逊AWS云计算平台中另一个核心服务。

AWS 云采用框架(CAF) 概述

AWS 云采用框架(CAF) 概述

创新与转型
通过以下方式提高云的价值:采用不断改进的开发运行方式;审查应用程序并制定战略来实现应用程序产品 组合的创新和转型;制定敏捷应用程序开发的云优先战略、实现速错并提高应用程序为企业带来的价值
版权归 © 2016 Amazon Web Services, Inc. 及其附属公司所有。保留所有权利。
版权归 © 2016 Amazon Web Services, Inc. 及其附属公司所有。保留所有权利。
20
应用程序发现与产品组合评估
版权归 © 2016 Amazon Web Services, Inc. 及其附属公司所有。保留所有权利。
21
概览
确定来源战略与模式
用于决定如何确定每个工作负载业务和技术运营来源的决策流程 决策流程、应迁移到 AWS 的工作负载的细分和优先级划分
?业务的所有人必须定义rto和rpo?将关键数据与可抛弃数据隔离开来?rto关注您的整个业务和所涉及的系统而rpo仅关注数据及企业对数据丢失的整体恢复能力?基于rpo设计您的业务连续性bcdr解决方案构建能实现目标rpo的解决方案并对其进行评估?在rto和rpo之间实现适当的平衡?两个目标都与成本成反比65我是否需要多区域部署较为适合多区域部署的使用案例?动态内容延迟存在cdn限制问题?灾难恢复dr大型企业通常需要将数据存储在另一个区域用于dr或实现业务连续性数据丢失不可能完全避免?降低发生数据丢失的几率?注重小型事务采用分布式数据存储可以降低数据大规模丢失的可能性?反面模式一个真正的数据库会造成致命后果?多个数据库服务器可降低灾难性数据丢失发生的可能性在地域分离的情况下可更好地实现最终一致性需要设计应用程序来处理该问题66模式在您的主区域实施高可用性架构将您的数据复制到第二区域或写入两个区域以进行灾难恢复需要为rto确定适用的dr模式67灾难恢复如果主区域服务出现故障可写入基于事件的服务以使用第二区域?sqssnsswfcloudwatchkinesisstreams等?可使用故障模式上的镜像或重定向具体取决于应用程序性能降低要好于完全故障68示例架构精选顶级示例69议程将展示4个架构?账单?付款处理?大型企业资源规划?商业智能寻找模式最后我们将设计一个架构70账单系统账单系统包括事务性数据存储常用业务规则应用程序和关系数据库71账单架构示例amazon区域1amazon区域2vpcvpc应用程序应用程序amazonamazonsesseselasticloadelasticloadbalancingbalancing多可用区rdsrdsrds多可用区rdssnapshotsnapshot取决于bcp计划72付款处理付款处理系统是有状态的工作流系统具有信用卡处理程序接口73付款处理架构示例amazon区域1amazon区域2vpcvpc工作流应amazon用程序amazonswf工作流应swf用程序多可用区rdsrdsrds多可用区rdssnapshotsnapshot取决于bcp计划74大型企业资源规划大型企业资源规划erp系统是连接一系列数据库供应链管理产品管理规划排程销售等的多个接口通常有多个架构或数据库也包括工作流表面看来与crm相似实际上也可以涵盖crm供应商架构可能会有明显区别75erp架构示例am

2024AWS的入门与使用课件PPT模板

2024AWS的入门与使用课件PPT模板

目录•引言•AWS核心服务介绍•AWS安全实践指南•AWS部署与优化技巧•AWS案例分析与实战演练•总结与展望引言01AWS(Amazon Web Services)是亚马逊公司提供的云计算服务平台,提供全球范围内的计算、存储、数据库等服务02AWS成立于2006年,现已成为全球最大的云计算服务提供商之一03AWS致力于为企业提供灵活、可扩展、安全且成本效益高的云计算解决方案AWS概述与背景01云计算是一种基于互联网的计算方式,通过共享软硬件资源和信息,能按需提供给计算机和其他设备02云计算具有弹性可扩展、按需付费、资源池化等特点云计算服务通常包括基础设施即服务(IaaS )、平台即服务(PaaS )和软件即服务(SaaS )云计算基本概念02AWS在全球云计算市场占据领先地位,拥有丰富的产品线和服务AWS提供高度可靠、可扩展的云计算基础设施,支持各种应用场景AWS具有强大的技术创新能力和完善的安全体系,保障用户数据安全AWS拥有广泛的合作伙伴生态系统和丰富的开发者资源,提供全方位的支持AWS市场地位及优势课程安排介绍AWS基本概念和核心服务;深入讲解AWS的计算、存储、数据库等服务;探讨AWS的安全、管理和监控等话题;进行实践操作和案例分析学习目标掌握AWS基本概念、核心服务和应用场景;了解AWS 安全、管理和监控等方面的知识;具备基本的AWS实践能力和问题解决能力学习目标与课程安排AWS核心服务介绍计算服务:EC2与LambdaEC2(Elastic Compute Cloud)提供可扩展、按需付费的计算容量,允许用户启动虚拟服务器并配置安全、网络和存储等。

Lambda无服务器计算服务,允许用户运行代码而无需管理服务器,自动扩展并按实际使用的计算时间付费。

存储服务:S3、EBS和EFSS3(Simple Storage Service)对象存储服务,提供高度可扩展、可靠和安全的存储,适用于各种使用案例,如数据备份、归档和大数据分析等。

云计算第三版Amazon云计算AWS

云计算第三版Amazon云计算AWS

3.1 基础存储架构Dynamo
《云计算》第三版配套PPT课件
成员资格及错误检测
为了避免新加入的节点之间不能及时发现其他节点的存在,Dynamo中设置了一些 种子节点(Seed Node)。种子节点和所有的节点都有联系。当新节点加入时, 它扮演一个中介的角色,使新加入节点之间互相感知。
新节点 1
新节点 2
直到N个节点全部传遍
结论:
Dynamo中的节点数不能太多 Amazon采用了分层Dynamo结构 来解决该问题
25 of 52
容错机制 《云计算》第三版配套PPT课件
由于成本方面的原因,Dynamo中很多服务器采用的是普通 PC主机; 其硬盘性能和专业服务器硬盘相差很远,出错很难避免; Dynamo中容错机制非常重要
11 of 52
《云计算》第三版配套PPT课件
数据均衡《云分计算布》第的三版问配套P题PT课件
➢一致性哈希算法
平衡性 单调性 分散性 负载
两步进行:
求出设备节点的哈希值,并
配置到环上的一个点;接着
计算数据的哈希值,按顺时
针方向将其存放到环上第一
个大于或等于数据哈希值的
节点上; 添加新节点时,按
照上述规则,调整相关数据
问题 数据均衡分布
数据备份 数据冲突处理 成员资格及错误检测 临时故障处理 永久故障处理
采取的相关技术 改进的一致性哈希算法 参数可调的弱quorum机制 向量时钟(Vector Clock) 基于Gossip协议的成员资格和错误检测 Hinted handoff(数据回传机制),
Merkle哈希树
种子节点
A B
C
24 of 52
3.1 基础存储架构Dynamo

云计算第三章

云计算第三章

3.1 亚马逊云计算AWS
消息
消息
1.消息的格式
(1)消息ID(Message ID) (2)接收句柄(Receipt Handle) (3)消息体(Body) (4)消息体MD5摘要(MD5 of Body)
2.消息取样
队列中的消息冗余存储,目 的是为了保证系统的高可用性 基于加权随机分布(Based on a Weighted Random Distribution)的消息取样
一:Amazon平台基础存储架构:Dynamo Amazon平台的架构是完 全的分布式、去中心化 需求——Amazon平台中 有很多服务对存储的需求 只是读取、写入,(满足 简单的键/值式存储) 例如:常用的购物车、信 息会话管理和推荐商品列 表等。
面向服务的Amazon平台架构
3.1 亚马逊云计算AWS
弹性MapReduce的运行过程非常简单,用户根本不需要考虑计算中涉及的服务器部 署、维护及软件环境的配置
S3安全措施
2.访问控制列表
S3提供的可供用户自行定义的访问控制策略列表 S3中有三大类型的授权用户
1)所有者 2)个人授权用户 3)组授权用户
权 限 READ WRITE 允许操作目标 桶 对象 桶 桶 对象 桶 对象 桶
对象
具体权限内容 列出已有桶 读取数据及元数据 创建、覆写、删除桶中对象 读取桶的ACL 读取对象中的ACL 覆写桶的ACP 覆写对象的ACP 允许进行以上所有操作,是S3提供的最高权限
3.1 亚马逊云计算AWS
出现这些现象是因为S3为 了保证用户数据的一致性 而采取的一种折中手段, 即在数据被充分传播到所 有的存放节点之前返回给 用户的仍是原数据
3.1 亚马逊云计算AWS

Amazon云计算AWS介绍

Amazon云计算AWS介绍

《云计算》第三版配套PPT课件
虚拟私有云 VPC
算服务 虚拟私有云VPC
《云计算》第三版配套PPT课件
Amazon虚拟私有云(VPC)是一个安全的、可靠的、可以无缝连接企业现有的 基础设施和Amazon云平台的技术。 VPC将企业现有网络和AWS计算资源连接成一个虚拟专用网络资源,提供强大的 网络功能。通过Amazon VPC,企业可以很容易地获得需要的基础资源,有效地 控制成本、节省时间和管理成本。
Amazon提供的两种服务 快速应用部署Elastic Beanstalk
《云计算》第三版配套PPT课件
服务模板CloudFormation
AWS Elastic Beanstalk是一种简化在AWS上部署和管理应用程序的服务
需求分配
负载均衡
自动缩放
监督检测
目前AWS Elastic Beanstalk仅针对Java开发者提供支持。
3.8.7 Amazon执行网络服务
3.8.8 土耳其机器人 3 . 8 . 9 数 据 仓 库 服 务 Re d s h i f t 3 . 8 . 1 0 应 用 流 服 务 A p p St re m和数据流分析服务Kinesis ofa40
3.8 其他 Amazon 云计算服务 DNS服务Router 53
《云计算》第三版配套PPT课件
云计算
CLOUD COMPUTING
第3章
Amazon 云计算 AWS介绍
of 40
《云计算》第三版配套PPT课件
目 录
3.1 基础存储架构Dynamo 3.2 弹性计算云EC2 3.3 简单存储服务S3 3 . 4 非关系型数据库服务SimpleDB和DynamoDB 3.5 关系数据库服务RDS 3.6 简单队列服务SQS 3.7 内容推送服务CloudFront 3.8 其他Amazon云计算服务

AWS系列之一亚马逊云服务概述

AWS系列之一亚马逊云服务概述

AWS系列之⼀亚马逊云服务概述云计算经过这⼏年的发展,已经不再是是⼀个⾼⼤上的名词,⽽是已经应⽤到寻常百姓家的技术。

每天如果你和互联⽹打交道,那么或多或少都会和云扯上关系。

gmail、github、各种⽹盘、GAE、heroku等各种服务都属于云服务的范畴。

那么云计算的定义到底是什么?这⾥有摘⾃wiki的定义。

Cloud computing in general can be defined as a computer network which includes, computing hardware machine orgroup of computing hardware machines commonly referred as a server or servers connected through acommunication network such as the Internet, an intranet, a local area network(LAN) or wide area network(WAN).从上⾯的定义可以看出,云计算可以看做⼀个计算⽹络,其由⼀组硬件主机作为服务器,然后通过通讯⽹络连接,从⽽给其他⽤户提供各种各样的服务。

以下是云计算的⼀个概念图。

从该图中可以看出,云计算提供的服务可以分为三层,第⼀层是基础设施(Infrastructure),第⼆层是平台(Platform),第三层是应⽤软件(Application)。

基础设置的服务包括虚拟或实体计算机、块级存储、⽹络设施(如负载均衡,内容交付⽹络,DNS解析)等,平台的服务包括对象存储、认证服务和访问服务、各种程序的运⾏时、队列服务、数据库服务等,⽽应⽤软件的服务则包括的多了,⽐如邮件服务、代码托管服务等等。

⽤户可以通过台式电脑、⼿提电脑、⼿机、平板等各种互联⽹终端设备访问和使⽤这些服务。

其实这三层就是我们常说的IaaS(Infrastructure as a Service)、PaaS(Platform as a Service)、SaaS(Software as a Service)。

亚马逊AWS的服务器架构及优化方案

亚马逊AWS的服务器架构及优化方案

亚马逊AWS的服务器架构及优化方案亚马逊AWS(Amazon Web Services)是全球最大的云计算服务提供商之一。

AWS提供各种云计算相关的服务,包括计算、存储、数据库、分析、机器学习、人工智能等。

其中,AWS的服务器架构是其成功的关键之一。

在本文中,我们将探讨AWS的服务器架构及如何优化。

1. 服务器架构AWS的服务器架构采用多层次的系统架构,包括数据中心、区域、可用区、实例和存储。

下面我们逐个介绍。

数据中心是AWS云计算服务的核心基础设施,其提供了可靠的电力、网络、空调和物理安全。

AWS目前在全球70个区域(包括已经启动的和尚未启动的区域)拥有100多个数据中心。

每个AWS区域都由一个或多个数据中心组成。

例如,北美区域包括美国西部、美国东部、加拿大中部等多个数据中心。

数据中心下面的是区域,AWS的区域是由一些相邻的地理位置组成的。

现在,AWS区域的数量已经达到了全球22个。

AWS 的区域与数据中心的联系非常紧密,基本上每个数据中心都在一个区域内。

区域下一层是可用区,AWS的可用区是指在同一AWS区域中独立运营的一个或多个数据中心。

每个可用区都是独立的,可以实现高可用性和灾备恢复。

例如,美国东部(弗吉尼亚)AWS区域包括6个可用区。

实例是AWS云计算服务提供的虚拟服务器,提供各种计算能力和服务,支持多种操作系统和应用程序。

AWS的实例是根据业务需求进行规划和分配的,可以根据需要动态增加或减少。

AWS 的实例规划非常灵活,有多种规格可供选择,可以根据需要选择适当的规格。

存储是AWS提供的云存储服务,支持不同的存储类型,包括对象存储,文件存储和块存储。

AWS的存储也非常灵活,可以根据业务需要进行灵活选取。

2. 优化方案在使用AWS的服务时,有一些优化技巧可以提高系统的性能和可用性。

下面我们将从以下几个方面进行介绍。

2.1 规划优化在使用AWS的服务时,最重要的事情是规划。

规划是根据业务需求和服务特性进行部署和调整的过程。

AWS产品介绍及BPM解决方案

AWS产品介绍及BPM解决方案

AWS产品介绍及BPM解决方案AWS(Amazon Web Services)是亚马逊公司提供的一系列云计算服务。

AWS提供了各种基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS)解决方案,帮助企业实现更高效、安全、灵活和可扩展的云端运算。

以下是AWS的一些主要产品和服务介绍:1.EC2(云计算服务-虚拟服务器):提供可定制的虚拟机实例,可根据需求进行弹性伸缩,支持各种操作系统。

2.S3(云存储服务):提供安全、持久且高可扩展的对象存储,可用于存储和检索任意数量的数据。

3. RDS(关系型数据库服务):提供托管的关系数据库服务,支持多种数据库引擎,包括MySQL、PostgreSQL、Oracle等。

4. Lambda(无服务器计算):无需管理服务器,直接运行代码,根据触发器自动处理请求。

5. DynamoDB(NoSQL数据库服务):快速、灵活且完全托管的NoSQL数据库服务。

6.VPC(虚拟私有云):创建和管控虚拟网络环境,可以与数据中心或其他云服务进行安全通信。

7.IAM(身份和访问管理):帮助控制对AWS资源的访问权限,并管理多个用户和组。

8. CloudFront(内容分发网络):分发静态和动态网络内容,提高用户的访问速度。

9. Route 53(域名系统服务):提供可扩展的域名注册、解析和管理的服务。

10.SNS(简单通知服务):提供可靠的消息传递机制,用于构建分布式应用。

针对BPM(Business Process Management)的解决方案,AWS提供了以下服务:1. Step Functions:提供了一种可视化和弹性的方式来协调和管理应用程序中的多个任务和工作流程。

用户可以通过创建状态机来定义和执行复杂的业务流程。

2. Simple Queue Service(SQS):提供了一种简单的消息队列服务,用于在分布式系统之间传递消息。

可以用于实现异步通信、削峰填谷、解耦等场景。

Amazon AWS 搭建及部署手册

Amazon AWS 搭建及部署手册

Amazon AWS 搭建及部署手册现阶段,不断涌现的云服务厂商给这样的实战带来了福音——价格低廉甚至免费的云服务器正在向你招手。

如果你不想用国内厂商的云服务——或者就是单纯的嫌贵,那么免费12个月的亚马逊AWS就是你最合适的选择。

亚马逊AWS 介绍简单来说,AWS (Amazon Web Service) 提供了一整套基础设施和服务,使“建站”这件事变得轻松愉快。

你可以利用AWS构建博客主机,云存储(比如DropBox),手游数据中心,公司门户等等几乎所有你能想到的需要网络服务的场景。

作为一个入门介绍,我们从Wordpress 开始,因为Wordpress 几乎包含了入门级站点的全部需求元素:服务器主机,PHP运行环境,数据库,前端页面等等。

不得不多说一句,对于个人博客来说,如果经济性是首要考量因素,AWS 并非首选,大量专业博客虚拟主机以非常低廉的价格提供给低访问量的博客站长。

AWS的入门套餐价格也远比入门级博客主机价格高许多,当然,性能和容量也大许多。

在决定是否选用AWS提供服务前,有必要对自己的业务量有个初步估算。

好在AWS 对于初次注册的用户提供了为期一年的免费套餐,足以应对一个中等大小的博客站点(甚至多个)持续运行一年时间。

我们就从这个免费套餐开始入门的学习。

免费套餐的详细说明请参见官方介绍。

另外,AWS 有遍布全球的数据中心,而且,即使你的主机设置在美洲,也可以用CloudFront 服务来进行全球加速。

不过CloudFront 服务似乎并未包含在免费套餐中。

建议在创建主机时,选择日本节点,从大陆访问的速度还算不错。

有消息称亚马逊正在计划在中国大陆部署数据中心,并有望在2013年年底前正式上线。

非常令人期待啊。

第一步:注册账号在开始前,请先准备一张双币信用卡。

AWS 账号就是你的Amazon 账号(注意,不是 而是)。

若之前没有amazon 账号,请直接去 注册。

如果不想用AWS服务,这个账号还可以用来在美国亚马逊海涛心仪的商品。

AWS、Vmvare和Openstack三种云架构对比,如何选择?

AWS、Vmvare和Openstack三种云架构对比,如何选择?

AWS、Vmvare和Openstack三种云架构对比,如何选择?展开全文云计算服务既然是一种通过网络提供的自动化服务,其架构就和传统IT有很大的区别。

下面我们来讨论云计算的架构,从中我们可以看到为什么云计算架构是支持互联网+转型的唯一IT架构选择。

什么是架构?要了解云计算架构,首先我们要对架构有个清晰准确的理解。

架构有两个层面的涵义。

一个是静态层面的,主要是勾画系统边界、结构、组成的组件以及组件之间的关联关系;另一个是动态层面,主要是规范组件的行为以及组件之间的交互协议。

根据一个IT系统的架构,可以界定该系统的功能特性和一些非功能特性。

例如:一个邮箱系统,它的功能可以是收、发邮件;非功能特性则包括安全措施(认证、加密等)以及响应时间、吞吐率等。

架构设计要考虑不断变化和恒久不变的两方面。

一个有长久生命力的系统都有一个设计高明的架构,其精髓在于架构能支持系统功能的变化、发展、演化,允许系统功能的不断变化,也就是架构必须提供灵活性;而系统对易用性、安全性、稳定性和性能却应该是恒久不变,因此IT架构的设计必须强调非功能特性,其中开放性、可扩展性、可移植性、可维护性、灵活性、安全性、性能(响应时间、吞吐率、并发数等)最为重要。

云计算架构尤其强调灵活性、扩展性和易用性。

云计算架构的特点要了解云计算架构,最直接的方法是了解目前流行的主要云计算提供商的平台架构。

下面我们通过了解公云提供商的典型代表—亚马逊AWS的架构,以及在企业私云占垄断地位的VMWware,还有在互联网企业主流使用的OpenStack架构来深入了解云计算的架构。

公云–亚马逊AWS 架构在2000年前后,以IBM、微软、HP为首的企业IT龙头提出了面向服务的架构(SOA)的理念。

SOA架构核心是松耦合,系统由服务组件组成,每个服务组件提供一个专门的服务功能,各服务的功能通过标准服务接口向外提供。

SOA架构和传统应用架构有很大区别。

传统应用架构组件之间耦合度高,组件之间没有标准的接口,使得应用的扩展、维护非常不方便,不能支持业务的发展。

云计算的几大形式

云计算的几大形式

云计算的几大形式云计算(Cloud computing)是指通过互联网将数据存储、处理和管理的模式。

它已经成为现代社会科技发展的重要组成部分,为个人和企业提供了许多便利和创新的机会。

随着科技的不断发展,云计算也在不断演变和改进中,现在存在着几种不同形式的云计算,本文将重点介绍云计算的几大形式。

一、公有云(Public Cloud)公有云是一种由第三方服务提供商所拥有和管理的云计算基础设施。

这种形式的云计算提供商将硬件、软件和其他基础设施作为服务(IaaS)通过互联网对外提供,用户可以根据自己的需求租用这些服务。

公有云通常具有强大的可扩展性和灵活性,能够为用户提供高性能的计算和存储资源。

例如,亚马逊云服务(AWS)和微软Azure就是公有云的典型代表。

二、私有云(Private Cloud)私有云是一种由单一实体或组织拥有和管理的云计算基础设施。

与公有云不同,私有云的硬件、软件和其他资源完全由该实体或组织独立运营和控制。

私有云通常用于满足特定组织的安全和合规性需求,因为它能够提供更高的数据保密性和可控性。

由于私有云的部署和维护成本较高,并且需要专业的人员来管理,因此它通常被大型企业或政府机构采用。

三、混合云(Hybrid Cloud)混合云是一种结合了公有云和私有云的云计算形式。

在混合云中,企业可以同时利用公有云和私有云的优势,满足不同层次的需求。

例如,企业可以将敏感数据存储在私有云中以确保安全性,而将其他非敏感数据存储在公有云中以降低成本。

混合云的优势在于灵活性和可扩展性,它可以根据实际需求进行快速调整和部署。

四、社区云(Community Cloud)社区云是由多个组织或实体共同拥有和管理的云计算基础设施。

这些组织或实体通常属于相同的行业、领域或利益集团,共享资源和服务。

社区云可以通过共享资源和成本来提高效率和降低成本,同时满足特定社区的需求。

社区云通常由专门的云服务提供商或行业组织来管理,以确保数据和服务的安全和可靠性。

亚马逊AWS技术白皮书:AWS 云采用框架 – 平台视角

亚马逊AWS技术白皮书:AWS 云采用框架 – 平台视角

AWS Cloud Adoption FrameworkPlatform PerspectiveNovember 2015© 2015, Amazon Web Services, Inc. or its affiliates. All rights reserved.NoticesThis document is provided for informational purposes only. It represents AWS’scurrent product offerings and practices as of the date of issue of this document,which are subject to change without notice. Customers are responsible formaking their own independent assessment of the information in this documentand any use of AWS’s products or services, each of which is provided “as is”without warranty of any kind, whether express or implied. This document doesnot create any warranties, representations, contractual commitments, conditionsor assurances from AWS, its affiliates, suppliers or licensors. The responsibilitiesand liabilities of AWS to its customers are controlled by AWS agreements, andthis document is not part of, nor does it modify, any agreement between AWSand its customers.Page 2 of 19ContentsAbstract 4Introduction 4Design Architecture 7Conceptual Architecture Activity 7Logical Architecture Activity 8Considerations 10Implementation Architecture 11Considerations 13Architecture Optimization 14Cloud Design Principles and Patterns Activity 14Application Migration Patterns Activity 15Considerations 17CAF Taxonomy and Terms 18Conclusion 19Notes 19 Page 3 of 19AbstractThe Amazon Web Services (AWS) Cloud Adoption Framework (CAF)1 provides best practices and prescriptive guidance to accelerate an organization's move to cloud computing. The CAF guidance is broken into a number of areas of focus that are relevant to implementing cloud-based IT systems. These focus areas are called perspectives. Each perspective is covered in a separate whitepaper. This whitepaper covers the Platform Perspective, which focuses on designing, implementing, and optimizing the architecture of the AWS technology that you use in your cloud adoption initiative.IntroductionYour organization can use the AWSCloud Adoption Framework (CAF)guidance to explore how differentdepartments can work together onone or more cloud adoption initiative.Guidance is separated into thefollowing focus areas, calledperspectives: Business Perspective,Platform Perspective, MaturityPerspective, People Perspective,Process Perspective, OperationsPerspective, and Security Perspective.The Platform Perspective componentsdescribe the structure and design of acloud-based IT system, or a hybrid ITsystem that spans both cloud andnon-cloud environments.The rest of this whitepaper describeshow the perspectives translate into activities that your organization can perform. This whitepaper covers design architecture and implementation architecture. You can also benefit from principles and patterns for rapidly implementing orFigure 1 Components of the PlatformPerspectiveexperimenting with new solutions on the cloud, or migrating existing non-cloud solutions to the cloud, which will be covered as part of optimization.Embracing AgilityMany organizations already use agile development to increase the velocity of their anticipated business outcomes. However, some businesses experience difficulty in achieving agility all the way through to deployment and operations. Consider embracing agility if you want to increase the velocity of achieving your anticipated business outcomes. For example, you could form a team to initiate a project and, with limited analysis, use AWS services to create a proof of concept (POC). If the POC is successful, you continue. If not, you select a different approach. The AWS platform creates a low barrier for experimentation, and allows you to rapidly deploy servers. When you complete your POC experiment you can shut down the AWS services environment, and no longer pay for resources. When your solution is ready for end users (the minimally viable product), you can gather the users’ feedback and use it to inform priorities for future feature releases. By documenting the different phases of your cloud journey as it progresses, you can create a complete picture of the IT environment. Consider storing the artifacts that you create using incremental experimentation in the source code management system that you use today for storing and revising your application code.You can complete the process of describing a business need and transitioning it into an IT solution using an iterative approach. In addition, you can use an iterative process to provide delivery teams enough detail so that what they build provides the intended outcome. Figure 2 illustrates how an IT capability maps to the services that deliver the capability.Figure 2: Example of Architectural Mapping from Capability to ServiceWhen you use an iterative architectural approach, you can focus more time on business needs and goals. As business needs change and more information is surfaced, the technical architecture you use to deliver the business capability to the customer can shift to match the business need. You can also iterate faster, trying out new things to see if they work with minimal barrier to entry, due to utility pricing. The iterative approach makes it easier to roll back changes or stand up a parallel environment to test new features.You can use a combination of AWS services to create IT capability, and use the AWS Service Catalog to centrally manage commonly deployed IT services. You can also use AWS services that provide a specific IT capability, such as Amazon Glacier for data archiving.There are several components to consider from the Platform Perspective:The Design Architecture component: Look at the common design patterns used in your implementations and identify common needs and redundancies.The Implementation Architecture component: Look at the security, data handling and retention, log aggregation, monitoring needs, and common operational patterns.The Architecture Optimization component: Identify your optimization strategies,what tools and processes need to be changed, and what automation can be used.Design ArchitectureThe Design Architecture component of the Platform perspective promotes the engagement of stakeholders from many parts of the organization. In your cloud adoption scenario, you need to provide different views on your architecture to each stakeholder. For example, as you work with business sponsors to design a solution you can contextualize the architecture to describe how IT can be used to achieve the expected business outcome, and what the costs, returns, and risks might be.Prior to an AWS adoption journey, your organization should consider modifying its governance and architectural principles to include AWS architectural principles. If you have not done so, then try using the iterative method described earlier to establish these principles. You can build methodologies and processes using sprints, just as you build applications. As you build, you can validate the design of your conceptual architectures against your governance and architectural principles.Conceptual Architecture ActivityConceptual views are technically abstract, but they should be described in a context that is familiar to business users. Use the conceptual architecture to define the business context of an IT system with business models. This is where you balance short-, medium-, and long-term business goals and concerns for IT initiatives.Three key components of a conceptual architecture are business vision, goals, and objectives. Use the conceptual architecture to understand which capabilities will be needed as part of the logical or functional architecture that will describe the solution. Figure 3 illustrates an example conceptual architecture that describes where AWS services are applicable.Figure 3 Example of a Conceptual ArchitectureUsing AWS, the creation of a conceptual architecture can become more iterative. You can use AWS services as part of the development effort by using experimentation to validate and evolve the approach. As business capability concepts are proven, development teams can start work on delivering functions and features into production. With quicker delivery, end-user feedback can be used to verify whether business objectives and compliance requirements are being met with the current technical approach.Implement automated testing to test your rapidly iterating conceptual architecture. This not only minimizes the introduction of bugs into your application, but also includes continuous compliance as part of continuous delivery, helping to ensure that changes to your application do not affect your organization’s security posture.Logical Architecture ActivityLogical (or functional) architectural views describe the building blocks of the IT system and their relationships without getting into the technical details of how the functionality is implemented. The logical architecture contains the data flow and capability models that relate to the business models that meet the businessoutcomes.Quality attributes, dependency mapping, and plans for obsolescence can be identified, documented, and addressed as part of designing the logical architecture. A logical architecture (Figure 4) that uses AWS can make use of geographical duplication as well as the elastic nature of AWS services. Using design principles that take advantage of these characteristics will allow system capacities to expand and shrink as loads expand and contract.Figure 4 Example of a Logical Architecture DiagramYou can use different approaches based on the type of project your organization is designing. Projects with a long duration typically are used in predictable, repeatable environments or environments where refinement of approach is not possible or recommended after decisions are made. These types of initiatives are driven with top-down control over outcome. An example of such an initiative is shutting down a corporate data center after a decision to move to the cloud.Initiatives with a short duration are driven with bottom-up freedom over outcome. Change in direction is expected and may be encouraged for better alignment with shifting business needs.There are also hybrid approaches to initiatives where the goal is to migrate and decompose a monolithic mission-critical solution or environment. These initiatives will combine the best aspects of heavy up-front planning with the freedom to innovate as needed to deliver optimized customer outcomes.Considerations∙Do use feedback from delivered features to review and revise the conceptual architecture with the business team.∙Do minimize the number of architectural principles to allow the greatest flexibility in solution development.∙Do stay focused on customer outcomes and business objectives rather than technical solutions.∙Do experiment with AWS services to experience, learn, and prove that your logical architecture will achieve the desired business outcome.∙Do focus on short duration project scoping and iterative processes for systems of interaction where outcomes are more fluid.∙Do consider the practice of creating logical architecture as a dynamic process. ∙Do limit the amount of redundant tech nologies to prevent “technology sprawl” and allow for focus and specialization.∙Do not make functional and implementation architectures dependent on a complete conceptual architecture. Consider identifying a key objective and starting design and delivery of that functionality. Use the feedback fromadoption of the features as input in the evolution of the conceptualarchitecture.∙Do not attempt to create the perfect architecture up front. Consider starting with the highest risk/reward scenario and use experimentation to prove your approach.Implementation ArchitectureThe Implementation Architecture component of the AWS CAF Platform Perspective describes the detailed designs within the IT system and the specific implementation components and their relationships. This architecture also defines the implementation of the system’s building blocks by soft ware or hardware elements.The implementation architecture for an AWS environment describes the design of the technical environment. The description is broken into layers, with each layer providing information for a specific team in the organization. AWS reference architectures are available at /architecture. Figure 5 illustrates a high-level implementation architecture. This artifact works best online, where you can enable clicking on each item for more information, and you can plan for automatic updates.Figure 5 Example of an Implementation ArchitectureDescribing the AWS environment and providing guidance on usage will be a critical portion of the implementation architecture development. Describing how resources, accounts, and tagging work, and the how the Amazon Virtual Private Cloud (VPC) environment is configured provides information that will help the organization determine which resources are consumed by various systems, applications, and initiatives.The Information Architecture should set strategies for deployment, monitoring, auditing, and logging that will give you exposure to near real-time data. Setsecurity, data retention, gateway, and routing strategies and policies so your delivery teams have the information they need to enable control over the AWS environment as it grows.Include taxonomy and naming conventions as part of the metrics, monitoring, and chargeback implementation. The actual running environment will change continuously and will be best viewed through dashboards with near real-time information.Dashboard information can be represented graphically or by using lists. If you use a graphical dashboard, users could click the graphic to show additional detail. If you use a list in your dashboard, users familiar with spreadsheets can find information in well-defined columns. Figure 6 shows a graphical dashboard that can provide near real-time information.Figure 6 Example of a Graphic-based Near Real-time Dashboard Consider prescribing a taxonomy and naming convention in the implementation architecture. Then you can implement this taxonomy as a tagging standard on AWS resources. To increase confidence and reduce risk, you can leverage the AWS environment during implementation architecture creation. When you use AWS, the environment can be created and tested for verification or certification earlier in the release cycle. Additionally, tools are available through AWS and theAWS Marketplace that can automate processes and shorten the time needed to deliver, test, and operate AWS-based environments.Defining an operational playbook for how you are going to deploy and operate your systems will help ensure consistency and repeatability of success. This playbook should also be iterative in nature, with the constructive feedback implemented in systems that did not have this capacity at the time of creation. Considerations∙Do identify a network connectivity strategy for AWS services.∙Do outline AWS components to be used (services/features).∙Do define security controls (native vs. third-party tools). Greater details are available in the AWS CAF Security Perspective whitepaper.∙Do define data security and retention policies (encryption, backups, snapshots, third-party tools).∙Do create and work toward an automated deployment process to reduce the impact of human error and introduce portability.∙Do create an operational playbook. More information on this topic is available in the AWS CAF Operations Perspective whitepaper.∙Do outline a monitoring strategy.∙Do outline a logging strategy that validates that your logging system can manage the amount of information you decide to collect.∙Do create a strategy for resource tracking as part of your implementation architecture, ensuring that resources are appropriately tagged at the time of deployment. This can also be extended into cost allocation tagging.∙Do not let application environments form in an ad hoc fashion. Choose a strategy to organize your application environments.Architecture OptimizationThe Architecture Optimization component of the AWS CAF Platform perspective promotes the adaptability of an architecture that uses AWS—as business needs change and as new and better technical solutions become available, your architectural decisions can be modified and adjusted. Since physical computers are not purchased, the long lead-time for procurement, staging, burn-in, and configuration is no longer necessary. Because you can continue to optimize your architecture during the design phase, this process can completed with less up-front information; your decisions can change and be implemented as needed.As you adopt AWS services, a key focus should be on building tacit knowledge in the organization. Creating a centralized repository with principles, patterns, best practices, a glossary, and reference architectures will help ensure the rapid growth of AWS skills in the organization. As you start an automated and agile deployment process, the centralized information repository allows systems and people who deploy applications to access the governing principles as well as the pieces and parts that they own.Cloud Design Principles and Patterns ActivityAdherence to the software design principles and patterns that you document will improve quality and productivity and reduce risk during solution development. All delivery teams can follow these principles when designing and building solutions. A pattern is a proven approach to achieving a result. You can automate patterns that you use frequently to improve efficiency, consistency, reliability, and supportability. Consider following these best practices:∙Provide guidance that captures reusable approaches, leverages an infrastructure as code approach, and treats that code like application code (source control, code reviews, etc.).∙Create a baseline of language and understanding across the technical organization to ease communications. This might include creating a taxonomy and a dictionary or a glossary describing how things will be named andorganized.∙Educate everyone to a foundational level to provide common language and understanding. Building fluency in the language of AWS cloud adoption and explaining the taxonomy and naming conventions will help acceleratefamiliarity with and ability to use cloud-based technologies and approaches across the organization.∙Use fast track or factory principles to create common approaches with reliable results. Provide documentation that describes diagrams, naming conventions, code review guidance, and so on to provide a common language, approach, and expectations. Using wiki-based tools for documentation will allow teams to update documentation and keep it current, and will provide a single authoritative source for guidance.∙Create a governance process and/or team that ensures and/or audits the outcome of patterns and intended results.∙Provide an “Andon cord” for the deployment team to use if they see something that doesn’t fit in with their understanding of patterns. Application Migration Patterns ActivityProven approaches for migrating IT systems to the cloud are available as migration patterns.Consider organizing applications in a way that helps identify and introduce patterns that you can use with predictable results. Two of the more commonly used pivots are business criticality and data classification. Understanding which categories of data are associated with which applications will provide valuable insight. Another useful pivot is level of mission criticality. Depending on your needs, you could also consider organizing by systems of record versus systems of interaction, monolithic applications versus highly decomposed applications, or new applications versus applications near the end of life.One approach that you can take is to organize your applications into five groups based on the action you want to plan for each application. The different actions include retiring, retaining, replacing, re-hosting, refactoring, and rewriting. Figure 7 illustrates this five-group application migration pattern.Figure 7 Graphic Representation of an Application Migration PatternYou can also use an inventory of current data center applications and their dependencies to determine which applications to migrate and when. This could potentially allow you to avoid a costly equipment refresh, pushing away from capital expenditure (CapEx), and taking advantage of AWS utility pricing.For making decisions about which patterns to leverage, consider creating a Center of Excellence (CoE) team to select patterns that enable the shortest time to value. Another approach is to organize and prioritize by ease of effort to migrate. For example, you could decide to migrate development and test applications first, followed by self-contained applications, customer training sites, pre-sale demo portals, and trial applications. During the migration, consider prioritizing a Tier 1 application to gain visibility and endorsement from executive sponsors.Consider developing new applications or refactoring existing applications in the AWS environment. For existing applications, you could migrate applications to the AWS cloud environment and prioritize rework or optimization initiatives. The refactoring can be enabled by the agility of deployment on AWS.Considerations∙Do consider new applications for migration first.∙Do start development of new capabilities or rewrites of existing capabilities in the AWS environment.∙Do take advantage of capacity concerns as a reason to prioritize development in the cloud.∙Do consider using code review (both for application and infrastructure code) to provide a feedback loop that improves process and reduces technical debt. ∙Do consider using wikis to provide access to guidance that can be updated and maintained over time.∙Do leverage AWS cloud adoption as a way to fast track maturity of combined roles and skills thinking. This would manifest as adeveloper/security/operations mindset and coding architectural models to validate approach.∙Do use AWS cloud adoption to institutionalize a scalable, service-oriented architecture (SOA) approach to separate concerns and to enable integration of reusable services and limit the amount of code maintained.∙Do create patterns that assume failure by building in recovery code with features such as circuit breaker patterns, caching, and queuing, andexponential back-off.∙Do write code with an eye towards reuse through exposed API endpoints for easy discovery, integration, and reuse.∙Do introduce your deployment team to your development team. Empower both teams to fully appreciate the benefits of scalable infrastructure andutility pricing.∙Do not optimize a solution before it is well architected.∙Do not start migrations without operational processes defined. Consider defining backup and recovery guidance as an initial step in a migration effort. ∙Do not manually migrate all applications. Consider using automation to scale and accelerate migration of applications (migration factory).∙Do not wait to automate something. If you’re deploying the same thing twice manually, invest the time in automation.CAF Taxonomy and TermsAWS created the Cloud Adoption Framework (CAF) to capture guidance and best practices from previous customer engagements. An AWS CAF perspective represents an area of focus relevant to implementing cloud-based IT systems in organizations. For example, when a cloud solution is to be implemented, the Platform perspective provides guidance on designing, implementing, and optimizing the architecture of the AWS technology that you plan to use in your cloud adoption initiative.Each CAF perspective is made up of components and activities. A component is a sub-area of a perspective that represents a specific aspect that needs attention. This whitepaper explores the components of the Platform perspective. Within each component, an activity provides prescriptive guidance for creating actionable plans an organization can use to move to the cloud and to operate cloud-based solutions.For example, Design Architecture is one component of the Platform Perspective, and creating logical architectural views that describe the building blocks of the IT system and their relationships may be an activity within that component.When combined, the AWS Cloud Adoption Framework (CAF) and the Cloud Adoption Methodology (CAM) can be used as guidance during your journey to the AWS cloud.ConclusionTranslating business outcomes into technical solutions is still a necessary step in the IT lifecycle. By adopting AWS services, you have the flexibility to change an architectural decision after more information is gathered and as assumptions are tested and technology advances. The Platform Perspective provides an approach to separating a complex set of ideas and decisions into manageable components.Use the design component to facilitate discussions with business stakeholders and provide an abstract level of detail to describe how business outcomes will be accomplished.Use the implementation component to facilitate discussions with technical teams who are responsible for creating, delivering, and maintaining solutions at a level agreed upon with the business stakeholders.Use the architecture optimization component for approaches and patterns that provide predictable and repeatable results. For example, when you use an application migration pattern you can organize and categorize groups of applications and follow a common approach to migrating to an AWS environment. You can also create a small set of principles that all technical team members can use to help with key decisions. This ensures that a common approach to making decisions is used across the organization.Notes1 https:///whitepapers/aws_cloud_adoption_framework.pdf。

AWS安全基础架构02

AWS安全基础架构02

AWS安全基础架构02AWS安全基础架构02AWS(Amazon Web Services)是由亚马逊公司提供的一套云计算服务,包括计算、存储和数据库等各种功能。

在使用AWS的过程中,安全是一个重要的考虑因素。

AWS提供了一系列的安全服务和功能,用于保护用户的数据和应用程序。

本文将介绍AWS的安全基础架构。

首先,AWS采用了多层次的安全措施来保护用户的数据和应用程序。

在物理层面上,AWS的数据中心采用了严格的物理安全措施,包括视频监控、门禁系统、生物识别等。

此外,AWS还使用了防火墙、入侵检测系统(IDS)和入侵防御系统(IPS)等网络安全设备来保护网络交通。

其次,AWS提供了Identity and Access Management(IAM)服务,用于管理用户的身份和访问权限。

IAM允许用户创建和管理用户、组和角色,并控制每个用户对AWS资源的访问权限。

通过使用IAM,用户可以实现最小权限原则,即每个用户只被授予他们所需的最低权限,从而减少了潜在的安全风险。

此外,AWS还提供了Virtual Private Cloud(VPC)服务,用于创建和管理用户的私有虚拟网络。

通过使用VPC,用户可以在AWS云中创建一个与传统数据中心相似的网络环境,包括子网、路由表和安全组等。

用户可以使用网络ACL(Access Control List)和安全组来控制网络流量,从而增强网络的安全性。

AWS还提供了密钥管理服务(AWS Key Management Service,KMS),用于管理和保护加密密钥。

用户可以使用KMS来生成和导入密钥,并使用它们来加密和解密敏感数据。

此外,AWS还提供了多种加密选项,包括在传输过程中使用SSL(Secure Sockets Layer)和在存储过程中使用SSE (Server-Side Encryption)等。

AWS还为用户提供了监控和日志服务,用于监测和记录系统的安全事件。

Amazon Web Services (AWS)亚马逊云服务简介

Amazon Web Services (AWS)亚马逊云服务简介

Amazon Web Services (AWS)亚马逊云服务简介Amazon Web Services (AWS) 在云中提供高度可靠、可扩展、低成本的基础设施平台,为全球190 个国家/地区超过百万的家企业、政府以及创业公司和组织提供支持。

Amazon Web Services 于2006 年推出,并正式开始以Amazon 自己的后端技术平台为基础向开发人员客户提供Web 服务访问,即目前广为人知的云计算。

技术创新始终是公司文化的核心,它推动了 的增长。

在构建和运营了十多年的高可扩展性Web 应用程序后, 公司意识到它已经成功开发出了一个具有核心竞争力的、支持大规模运行的技术基础设施和数据中心,于是决定开始扩大它的使用范围,通过Web 服务平台为新的客户群体(即开发人员和企业)提供服务。

今天,AWS 平台包括40 多种不同的服务,包括Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Simple Storage Service (Amazon S3) 和Amazon Relational Database Service (Amazon RDS)。

AWS 客户范围从创业公司,例如Pinterest、Dropbox、Airbnb、Supercell 和Spotify 等一些最成功的创业公司,到遍布全球的大型企业,十分广泛。

在石油与天然气行业有Shell、BP 和Hess,在金融服务领域有Finra、Intuit、Suncorp 和澳大利亚联邦银行。

在医疗卫生领域有J&J、Pfizor、Bristol Myers Squib 和Merk。

在通信领域有Votifone、Comcast 和NTT Docomo。

在技术领域有Netflix、Samsung 和Adobe。

在媒体领域有Conde Nast、Newscorp、Dow Jones、New York Times 和The Weather Channel。

何为AWS云计算

何为AWS云计算

何为AWS云计算?“AWS云计算”根据定义是指通过互联网以按使用量定价方式付费的IT 资源和应用程序的按需交付。

AWS云计算基础知识无论您是在运行拥有数百万移动用户的照片共享应用程序,还是要为您的业务的关键运营提供支持,“云”都让您可以快速访问灵活且成本低廉的IT 资源。

透过云计算,您无需先期巨资投入硬件,再花大量时间来维护和管理这些硬件。

与此相反,您可以精准配置所需的适当类型和规模的计算资源,为您的新点子提供助力,或者帮助运作您的IT 部门。

您可以根据需要访问任意多的资源,基本是实时访问,而且只需按实际用量付费。

AWS云计算如何工作?AWS云计算以一种简单的方式通过互联网访问服务器、存储空间、数据库和各种应用程序服务。

像Amazon Web Services 这样的云计算提供商,他们拥有和维护此类应用程序服务所需的联网硬件,而您只需要通过Web 应用程序就可以配置和使用需要的资源了。

AWS云计算的六大优势和益处将资本投入变成可变投入与其不明就里地投资重金构建数据中心和服务器,不如使用云服务,这样您只需在使用计算资源时付费,只需按您的使用量付费。

大范围规模经济的优势使用AWS云计算,您可以获得更低的可变成本,比自己去做强得多。

因为云会汇集成千上万的客户,因此像Amazon Web Services 这样的提供商可以利用规模经济的优势,将这一特点转化成更低的按使用量付费的价格。

不必再猜测容量不必再猜测基础设施容量需求。

如果您在部署应用程序前确定了容量,则一般可以避免出现昂贵的闲置资源,或者不必为有限的容量而发愁。

而利用AWS云计算,这些问题都不会出现。

您可以访问任意规模的资源,可多可少,并根据需要扩展或缩减,一切只要分分钟就能完成。

增加速度和灵活性在AWS云计算环境中,新的IT 资源只要点点鼠标就能配置到位,这能显著节省时间,将开发人员调配资源耗费的时间从数周缩短到几分钟。

这让组织的灵活性能够大大增加,因为用于试验和开发的成本和时间明显减少了。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
r总数:4M+
22
23
24
Per Mega DC • Server总带宽14318T • 2Tbps/TOR,总共7168 TOR • 按40 server/rack,则总server 数为:286720 • 带宽比例 • Metro/Server=13.7% • LH/Metro=4.4% • LH/Server=0.6%
5
最可信的云平台,适用于全球化的合规性要求
SOC 1 / ISAE 3402 SOC 2 SOC 3 HIPAA CJIS DoD SRG Levels 2 & 4 ISO 27001 ISO 9001 ISO 27018 GxP ITAR FERPA FedRAMP ISO 27017 PCI DSS Level 1 FIPS 140-2 G-Cloud IT-Grundschutz
Rosco
Each room or each building might compose a power availability zone
26
ASIA PAC (Sydney)
US-WEST (N. California) ASIA PAC (Mumbai)
ASIA PAC (Singapore) SOUTH AMERICA (Sao Paulo)
全球13个 Regions 区域 (低延时,高覆盖,多运营商接入) 全球2016~2017计划新增区域:中国宁夏, 加拿大蒙特利尔,英国,俄亥俄
MLPS Level 3
MTCS Tier 3 IRAP
Section 508 / VPAT
NIST FISMA, RMF, and DIACAP
MPAA
Cloud Security Alliance Cyber Essentials Plus
6
高可用的基础设施
Availability Zones 可用区: 多数据中心组成的同城灾备
Building
Building
Building
Building
Rosco Inter-city / Long haul:
9.6T + / Fiber Coherent 100G 80km - 3500km
MDF
MDF
Nexus 9K Rosco ( for challenging
links)
Building Building Building Building
25
80+ acres 100+ MW
Intra-Complex :
TOR to tier 1, Tier 1 to Tier 2 and Tier 2 to Tier 3 interconnects. Upto 2Km reach
Room
Building Building Building Building
生产
• 把应用发布到 生产环境
4
EU-WEST (Ireland) US-WEST (Oregon) GOV CLOUD EU (Frankfurt)
Montreal
ASIA PAC (Beijing)
Ohio
UK NX
ASIA PAC (Seoul) ASIA PAC (Tokyo)
US-EAST (Virginia)
7
8
9
10
VPC:IPSEC/Direct Connect
VPC Peering
11
12
13
14
US East
LH DWDM
15
Metro DWDM
16
Source:/awschina/article/details/46125963
17
18
MDF
MDF
Nexus 9K
Advanced Metro:
Building
Building
Building
Building
Simple Metro:
Fiber rich inter complex links 4T / fiber Upto 80Km
Fiber scarce inter complex links 24T / fiber Coherent 200G/250G 80Km reach
AWS 共有云架构介绍
1
你眼中的亚马逊集团
2003: $5B
2004: $7B 2015: $107B
2
亚马逊开发流程的演进
3
源码
• 写入源代码, • 例如.java文件。• • 新代码的结对 • 检查。 • •
编译
编译代码 单元测试 风格检查 代码检测 创建容器镜像
测试
• 和其他的系统 做兼容性测试 • 压力测试 • 用户界面测试 • 攻击测试
相关文档
最新文档