去做一件事有多难？让我足足拖延了500多天，并且浪费了数千大洋？或许主要原因不是难，是心里不平衡吧！ (图源 ：pixabay) 话说长期关注我的朋友，大概知道三年前我在Amazon斥巨资购买了一个Amazon云计算的保留实例(RI)，期望RI既能让我体验到EC2的强大功能，又能让我省一大笔钱。

Learn how to set up Amazon EFS with two EC2 instances for shared file storage. Step-by-step guide for seamless data sharing & scalability.

自从因为RI实例Retired的问题和AWS客服吵翻天，进而被他们在客服系统拉黑之后，我在斥巨资在AWS买的RI上的实例一直处于空闲状态，就这样闲置了一年多。 (图源 ：pixabay) 也曾想把这个RI好好利用起来，毕竟花了我不少钱呢，但是一想到如果再次Retire，那不但会因为数据问题折腾大半天，还会惹一肚子气，算了，就那么着吧。

还记得O哥被Amazon气哭的事情吗？一下子买了三年的云服务（可以粗暴地理解为VPS），Amazon那边三番五次地因为维护停掉我的实例。 (图源 ：pixabay) 每次实例一停掉，我就得耗费很多时间重启实例，已经重建数据等等。之前在上边跑一些对稳定性要求很高的应用，基本就没法跑了。

之前的帖子中曾经说过自己切切实实地被Amazon的服务恶心到了，买了一个EC2 预留实例3年，结果时不时地来个退役(Instance Retirement)，然后需要重新设置实例不说，本地存储上的所有数据都会丢失。 (图源 ：pixabay) 如果这种情况遇到一次便也罢了，结果类似情况接连给我来了三次。俺们中国有句古话咋说的来着：再一再二，不能再三再四。（ "Once, twice, but

大概一个月以前，我发布了一篇帖子，标题为《美帝有无315？大概是毫无希望的维权》，讲述自己在美帝那租房被房东坑惨的经历。看完整个帖子的人都会明白，其实这里的租房，指的是在Amazon AWS租用EC2服务。 (图源 ：pixabay) 现在把租房这个写法换成真实的情况

The Importance of Disaster Recovery In today's digital age, the ability to quickly recover from data loss or IT system failures is crucial for maintaining business continuity, protecting data integrity,

话说O哥花重金美帝租了一个房子，租期三年，中途和房东闹了一些不愉快，现在O哥想投诉房东，要求房东退租，请问去哪里投诉比较好呢？ (图源 ：pixabay) 事情是这样的，在美帝租房有两种方式：一种是按月付房租，然后水电煤气费另算；另一种是长租，租期有一年、两年、三年等，提前付全部房租，但是租金价格会大打折扣，当然了，水电煤气费等还是要交的。

The Importance of Disaster Recovery In today's digital age, the ability to quickly recover from data loss or IT system failures is crucial for maintaining business continuity, protecting data integrity,

之前的帖子说到自己的一台Amazon EC2实例又因为retirement，且又漏看邮件而没能及时处理而导致被停止（stopped）。 (图源 ：pixabay) 除了懊恼于自己又没能及时查看并处理邮件，同时也懊恼于上次出这样的故障恢复过程没能写一个手册，一切又都要重来。 所以这次恢复过程记录一下，万一下次再出这样的问题（呸呸呸），只需依照手册逐步处理就好，不必再费脑了。 登录面板 首先，登录AWS的管理面板：

进入正题之前，先讲个冷笑话： 说，有个人一天出门，没注意到门口的路上多出来一个坑，结果不小心掉到坑里；第二天他再次出门，又没注意到这个坑，又掉进坑里；第三天，他又掉入同样的坑中；第四天..... 话说，我们如何评价这个人？我想一定是被傻冒、缺心眼、不长记性、愚蠢等贬义词来形容吧？ 可是，我没想到的是，我竟然也两次掉入同一个坑中，小丑竟是我自己！呜呜呜，悲伤、愤怒、抓狂、无奈😭 (图源 ：pixabay)

前两天曾发帖说因为我的一台Amazon EC2底层硬件问题，并且自己没有及时看邮件处理，导致Amazon停掉我的EC2实例，存储在本地存储的一些重要数据通通消失啦。 (图源 ：pixabay) 尽管我觉得Amazon应该为此担负一定的责任（毕竟是他们停掉的实例而不是我主动停掉），但是有理未必说得清，只能打落牙齿吞肚子里，忍着呗。

今天偶然访问了一下自己的一个监控站点，竟然惊讶发现我的一个很重要的服务竟然停掉10天之久，从2023-08-23 08:00:02之后就再无数据上传到站点。 (图源 ：pixabay) 呜呜呜，这又是怎么啦？最近怎么全是域名啊、网站啊出问题，这个服务可是放在Amazon EC2上，应该极其稳定才对，怎么就停掉了呢？

之前发帖说过ec2存储卷类型的问题，有朋友微信私聊问我：“O哥O哥，你怎么就弄20G空间呀？干啥都不够啊！”，言外之意说我有些吝啬。 这怎么能叫吝啬呢？这叫抠门好不好？哦，不对，这叫节约好不好？毕竟每G空间都是要交月租的，能省的话，当然要节省一些啦。 (图源 ：pixabay) 说起来你可能不信，20G空间，装完系统，还剩接近19G呢，能干好多事情呢，毕竟这EC2我不是用来存储小电影的。😍😳 关于本地存储

话说，在之前给大家介绍如何一步一步创建AWS EC2实例时，在存储设置中，我特别强调了gp3更加灵活，自己也一直使用gp3。 (图源 ：pixabay) 原文中内容如下： 关于类型，gp2更简单，gp3更灵活（配置和计费也复杂），也有其它一些类型，比如针对IO密集的，我一般都使用gp3。 然而昨天创建完成实例，并且浪费了一整天时间进行初始设置和迁移数据之后，我偶然间发现，我的存储卷，IOPS只有100！

之前一篇文章中介绍了如何一步一步创建一个AWS EC2实例，光说不练不是咱的性格，虽然实例挺耗银子的，不过舍不得孩子套不住狼，撸起袖子就是干！ (图源 ：pixabay) 话说实例创建后，略等一小会就可以在EC2->Instances中看到了，里边同时会显示一个Public IPv4 address，我们就可以用这个地址登录啦。 要完成初始登录，大致需要三个要素： IP地址

最近发现两件让人郁闷的事情，一个是自己忘性越来越大，很多以前做过的操作都忘记该如何去弄；另一个就是感觉好多服务商的系统都弄得越来越复杂，不像以前那样可以轻易上手。 (图源 ：pixabay) 就说这两天吧，因为需要启动一个新的AWS EC2实例，然后进到面板中我不禁发出灵魂拷问：我是谁？我在哪？我在干什么？

Background Someone on the Internet claimed to have achieved 1M+ concurrent connections on a single EC2 instance. While I can not verify this claim, it is true that EC2 does not set a hard limit on the

因为计划调整，需要停止AWS上的一个EC2实例，当然了，其实不关也没有什么毛病，就是会一直哗哗哗地扣费下去，只要你足够有钱，可以任性下去的。我没有钱，没法任性。 (图源 ：pixabay) 无法删除实例 按着步骤去删除实例： 结果却被提示，不让删除，让关闭“disableApiTermination”属性后再试，这是什么鬼？ 看了一眼实例的属性，有如下“Termination protection”信息：

今天有两台Amazon 的云服务器需要扩容磁盘(EBS)空间，在大概两个月之前我曾经为一台云服务器进行过类似操作，当时可是第一次操作，战战兢兢每步都万分小心地完成了工作。 (图源 ：pixabay) 当时还把操作步骤写了一个帖子《Amazon EC2动态扩展挂载磁盘(Volume)空间》，且煞有介事地总结了三大步骤： 面板中调整对应Volume的空间大小 系统中拓展分区大小(growpart)