AWS在大阪区域的发展历程！
你好，我是后藤。
今年，我很荣幸地被AWS公司选为APN大使，并参与了2021年的”日本APN大使冒险日历”活动。作为大使，我们被赋予了向外界传递信息的重要角色，并且我希望能够为大家提供有价值的信息。
照片看得出来吗？ dé ma?)
是的，我在大阪。
我在这里发布了一张从后面拍摄大阪的象征物——太阳塔的照片。有趣的地方在于它与大家所熟悉的正面形象完全不同。接下来，我要讲述的是今年新开设的“大阪地区”的轨迹。
哎呀，大阪地区是什么意思？
为了那些对大阪地区历史感兴趣的人，我想简单回顾一下大阪地区的历史。
另外，我要提醒大家，以下是我个人的意见和经验分享，与我所属的公司、组织，甚至是代表 APN大使、AWS先生、JAWS-UG等等的身份无关。请多多关照。
■一开始是世界上唯一的本地区域
首先，在2011年3月，AWS的第一个区域诞生在日本。
该名字是“东京区域”。
「云端登陆日本（The Cloud Lands in Japan）」
AWS的全新亚太东京区域已经可供使用！
今天起，对于在日本开展业务的企业和全球企业拥有日本客户的各位，使用东京区域将使您能够在低延迟、本地数据存储的环境中提供和操作应用程序。您将从繁琐的自有基础架构运营和管理等工作中解脱出来。在大部分情况下，日本客户可以以数毫秒的低延迟使用新的东京区域。
经过那段时间，连续七年都是东京独占的时代。然而，在那期间，2018年2月诞生了一个新的地区。
这个名字叫做『大阪本地地区』。
『【AWS新区域】AWS大阪本地区域已于今天开始提供服务』
AWS大阪本地区域是日本的第二个区域，也是AWS首个本地区域，即亚太 (大阪) 本地区域（以下简称AWS大阪本地区域）。在2017年5月31日的AWS Summit Tokyo 2017主题演讲中，我们宣布从2018年起可使用该区域。对于使用AWS东京区域的客户来说，我们收到了很多反馈，称赞我们为了符合监管要求而准备的补充基础设施，并可以使特定应用程序在地理上与可用区相隔离运行。
终于在关西诞生了AWS区域的那一刻！但是它带有“本地”的标签。
包含在单一数据中心的基础设施已经被分离并采用具有容错性的设计，结构上是作为补充现有 AWS 区域的新区域配置。离东京区域 400 公里的大阪本地区域旨在为那些在全国各地具有应用需求的客户提供灾害防备难度较高的支持，因此在东京区域无法满足他们的需求。
大阪ローカルリージョンは、バックアップと災害復旧（DR）を中心に機能するリージョンでした。そのため、メインリージョンとして利用することはできず、多くの制約がありました。東京リージョンが大規模な災害で利用できなくなった場合に、最低限の復旧を見込んだ環境が整っていたわけです。
然而，「本地区」是「世界独一无二」的存在。
『世界独一无二』听起来不酷吗？
■果然还是全区域最好！
在我认为的2020年，新闻突然传来了。
大阪本地区的全区域化适应！
『AWS正在将大阪本地区域扩展为完整区域』
基于对大阪服务的客户强烈需求，大阪本地区将在2021年年初扩展为一个具有三个可用区的完整AWS区域。与其他所有AWS区域一样，每个可用区都拥有独立的电力、冷却系统和物理安全措施。同时，它们被远离彼此以显著降低单个事件对可用性的影响风险，但仍能保持高可用性应用的低延迟。
终于，与”东京区域”并肩的时刻已经到来了。当时，其他云服务商都拥有东西方全区域，而AWS只有这一点被视为弱点。这次全区域化将一举解决这个问题。
有巨大的回响，决定进行银行系统等的迁移！
索尼银行扩大了使用AWS的范围，包括所有的系统，包括账务系统。
为了将AWS引入账务系统，我们需要在日本国内的多个地区进行部署以最小化自然灾害和停电等风险。考虑到2018年大阪地区的开设，我们决定将AWS迁移到银行系统中最重要的系统之一，即财务会计系统（总账）。
在某些场景中，由于”大阪本地区”被升级为完全区域，银行类重要系统的迁移决定也会出现。在云端应用推进的背景下，”大阪本地区”的完全区域提升是不可或缺的。
■ 现在已经开设了全新的富丽地区！
终于在2021年3月，期待已久的全省地位提升实现了。
这是『大阪地区』的诞生。
『AWS亚太地区（大阪）区域随着三个可用区和多种服务的开设』
我很高兴地宣布扩展了大阪本地区，成为一个具有三个可用区的标准AWS区域的大阪区域。作为AWS独有的特点，每个可用区在区域内是独立的，设计用于应对停电、网络中断、洪水和其他自然灾害。
这样就能和东京地区并肩了吗？
有些人可能会想到”并肩前进!”。
不，我們不是并肩而行的！
2021年3月時点では，大阪リージョンにはまだまだ利用できないサービスがたくさんありました。重要な機能もいくつかサポートされていなかったので，最初はまだまだ用途が限定されていました。しかしこれからは怒涛のリリースラッシュが始まります。
我們主要以「Amazon Web Services博客」的文章為基礎，來回顧一下這次的發佈情況。請注意，由於在日期欄中記錄了博客更新日期，因此實際的服務發佈日期可能會有少許誤差，敬請諒解。
For Amazon EC203月24日Amazon Redshift Spectrum03月24日AWS Backup03月30日AWS Security Hub03月31日AWS Gateway Load Balancer04月06日Amazon Macie04月06日Amazon MQ04月09日Amazon GuardDuty04月13日AWS Console Mobile Application04月15日AWS CodeCommit04月23日AWS Resource Access Manager04月23日AWS Service Catalog04月27日AWS TransitGateway04月30日AWS Network Firewall04月30日Amazon RDS for SQL Server
(MultiAZ)05月03日AWS Transit Gateway Network Manager05月11日AWS Certificate Manager
プライベート認証機関05月20日Amazon Route 53 Resolver
Endpoints for Hybrid Cloud05月28日Amazon CloudWatch Synthetics06月02日AWS WAF06月02日AWS Shield Advanced06月12日Network Load Balancer06月24日AWS Outposts06月30日AWS Firewall Manager07月08日AWS Storage Gateway07月09日AWS Application Migration Service07月13日AWS AppSync07月15日AWS Directory Service for
Microsoft Active Directory07月15日AD Connector07月21日AWS CodeBuild07月30日Amazon DynamoDB Global Tables08月06日Amazon FSx08月08日Amazon Athena09月02日Amazon SageMaker09月08日AWS Cloud909月16日AWS Lake Formation09月16日Route 53 Resolver DNS Firewall09月24日Amazon SES11月11日Amazon GameLift
大约在3至7月期间，真的是一连串的忙碌发布。
然后，大约在11月左右，这个发布热潮也渐渐平息下来了。
■目前（2021年12月）服务有何差异？
现在已经到了2021年12月。在东京和大阪两个区域，AWS的可用服务有什么差异呢？您可以通过“AWS按区域分类的服务”来确认每个AWS区域的可用服务。以下是服务数量的比较结果。
只差一半！
还有一半的路要走呢。
在东京地区有的90项服务在大阪地区都没有。
写下来的话确实让人觉得壮观。个人而言，如果能尽快在大阪地区发布“AWS Budgets”、“AWS CloudShell”、“AWS Control Tower”、“AWS Single Sign-On”、“Amazon AppStream 2.0”、“Amazon CodeGuru”、“Amazon Inspector”、“Amazon Kinesis Data Analytics”、“Amazon Kinesis Video Streams”、“Amazon QuickSight”、“Amazon WorkSpaces”等等，那我会非常高兴。
除此之外还有其他的差异吗？
嗯，如果不使用那90个服务，就没有差异了吧……听起来好像会有这样的声音传来。
不，是有差别的!
尽管有许多服务已发布，但实际上，在这些服务的功能方面，东京区域与其他地区存在一些细微差异。在这里，我们将介绍AWS的几个主要服务，并解释这些差异。
EC2: 云计算的弹性计算服务
EBS 可以被中文本地化
就费用而言，它们是平等的。然而，“提供的 IOPS SSD (io2)”尚未在大阪地区发布，只能在东京地区使用。io1和io2之间的区别如下所示。
IO1音量旨在以年故障率（AFR）低于0.2%的情况下，提供99.8%至99.9%的音量耐久性。这意味着每年在一千个运行中的音量中，最多有两个音量发生故障。IO2音量旨在以年故障率低于0.001%的情况下，提供99.999%的音量耐久性。这意味着在十万个运行中的音量中，最多只有一个音量发生故障。
S3
就价格而言，两者相当。然而，「S3 Object Lambda」功能仅在东京地区可用。
通过使用S3对象Lambda，在S3 GET请求中添加自定义代码，可以在将数据返回给应用程序时修改和处理该数据。
Lambda (拉姆达)
只有东京区域能够使用”Arm”架构。
由于Arm的成本效益更高，因此东京地区具有更多的经济利益。
如果使用Arm/Graviton2架构的函数，时间费用将比当前x86架构的费用降低20%。同样的20%折扣也适用于使用预配的并发执行的函数的时间费用。
RDS (云数据库)
东京区域的实例类型更多。虽然在价格上有许多相同费用的数据库服务，但像Oracle这样的明显比大阪区域高的服务也存在。以下是“即时 RDS for Oracle DB 实例（包含许可证）”的费用比较。
其他
顺便提一下，关于这项服务的差异，基本上新的服务通常会先在东京地区发布，这也会产生影响。如果想要尽早使用新的服务，就需要选择东京地区。
此外，还存在一些服务无法与DirectConnect等连接服务连接至大阪区域。需要注意的是，由于大阪区域的周边环境正在积极进行整备工作，因此需要谨慎。
那大阪地区在什么情况下使用呢？
我认为通过之前的解释，您可以理解东京地区和大阪地区之间存在差异。
不仅仅是西日本的用户使用，不仅仅是大阪地区的使用！
确实在延迟方面可能会有优势，但如果无法使用所需功能，则毫无意义。
我们能否使用所需的功能？应该优先考虑什么？
要认真考虑这一点，并且需要灵活选择东京区域。
在考虑使用所需功能时，重要的是要注意以下事项：
并不是所有东京地区的服务都可以使用。
这一点很重要。正如我们所看到的，两者的服务发布数量有90个差异。而且在细节功能上也存在差异。因此，如果您有需要使用的功能，我们建议您首先在大阪区域进行测试，以确保其正常运行。在实际环境中，AWS的操作确认非常容易，所以在您自己的AWS账户上进行实际验证是最可靠的。
亲眼目睹真物，方能理解真实。
我认为这非常重要。
当然国内有东京和大阪两个地区的价值是无法估量的。
大阪地区的诞生给我们带来了许多梦想！
我期待着未来大阪地区的进一步发展。
希望这篇关于大阪地区的总结文章对大家有些许参考价值。
尽管我本来打算就到这儿结束，但是考虑到最开始展示的“太阳塔”只是背面的图像，可能会让某些人感到不舒服，所以最后还是决定放上正面的“太阳塔”来结束吧。这是正面的面孔。前面的面孔代表“现在”，背面的面孔代表“过去”，还有金色的面孔代表“未来”，据说。不管你是对于金色面孔这个问题有疑问还是想，这座“太阳塔”都有深度的一面。
实际上，最近『太阳之塔』的内部也对公众开放了。
里面有一棵『生命之树』。
对于对它感兴趣的人来说，想知道是什么样的树。
那是请务必『亲临现场亲眼目睹』一下。
我认为用自己的眼睛亲眼看到并产生共鸣是很重要的。
去大阪！！
那么，感谢您一起陪伴到最后。
