AWS Availability Zones（AZ）和Regions简化了冗余能力的设计，类似的服务还有Azure Locally Redundant Storage（LRS）、Zone-redundant Storage（ZRS）、Geo-redundant Storage（GRS）和Read-access geo-redundant storage（RA-GRS）。与传统手段相比，构建弹性云的基础设施更为简单，代价更低。在数据库存储设计时，应保证至少一个区域或可用区（Availability Zone）可容错。应用可通过使用灾难恢复模式的最佳实践变得更为高可用。这些最佳实践包括指示灯（Pilot Light）、暖待机（Warm Site）和热待机（Hot Site）部署模型等。可在AWS白皮书《使用AWS进行灾难恢复》（“Using Amazon Web Services for Disaster Recovery”）中看到更多的详细信息。
重启和重加载的弹性。在应用设计中，应对重启和重加载具有弹性。在组件重启或重加载时，系统必须保持正常可用。不要假定任何组件会是健康的、可用的或是固定位置的。使用动态配置引导实例。在启动实例时，应该质疑一下“我是谁，我的角色/目的是什么？”此外，对启动配置内容进行精简，以使新的基础设施可以快速地适用于工作。
在每一层上应用安全。在构建安全性时，应根据云中无任何天生安全的事情这一假设，为每一层加入安全性。云中的环境安全是工作于一种供应商和消费者间的共同职责模式下。云提供商确保底层基础设施的安全，而消费者负责自身工作负载的安全。消费者应该在数据传输和驻留时应用适当层级的加密。应始终强制执行最小权限原则，不要赋予用户（或其它系统！）其所不需要的权限。利用云提供商所提供的安全特性。
受控密钥服务AWS Key Management Service（KMS）和Azure Key Vault简化了对数据加密所用密钥的创建和控制。此外，还可使用Hardware Security Modules（HSM）保护密钥的安全性。KMS和Key Vault可与各种云服务集成，随时可用。让用户自己去设置这样的HSM基础设施，这无疑是复杂的，并需要特殊的技能。尽可能地利用可用的原生服务，这样也易于实现与其它应用的集成。安全是云采纳与集成中所面临的最大挑战之一。为了克服这一挑战，采用安全密钥服务对实现的每一层做加密，使用云提供的身份验证和授权服务（AWS IAM和Azure Directory Services）来控制和保护云资源。不要将其用于应用程序内的身份验证或授权，这是一个反模式（anti-pattern）。因为一个应用可能会有成百上千的用户，为所有的用户管理云资源将会是一个繁琐的任务，我们并不需要这样做。如果应用是一个内网应用，推荐使用Active Directory认证。对于关键云资源的保护，强烈建议使用多重身份验证（Multi-Factor Authentication）。一个应用的主要安全风险，就是在源代码中对密码或其它安全凭证（例如AWS中的Access Key Id和Secret Access Key）做硬编码。这不仅会使密码和安全密钥轮转（Rotation）复杂化，而且一旦代码提交到源代码仓储后，会将秘密暴露给无关人员。 从应用访问云资源时，始终使用由AWS Security Token Service（STS）等服务所生成的临时凭据。
确定基础设施的规模。在云中，由于云提供了内置的扩展功能，确定基础设施的最初规模不再是最重要的，但依然很重要。如果一个企业能确定自身的需要，例如需要100或1000台的服务器，这将有助于企业选择备用容量来降低成本，因为企业无需为最低工作负载支付更高的价格。最低工作负载即对于三层架构的应用，至少需要四台服务器（即两台数据库服务器，一台应用服务器和一台Web服务器）。在这种情况下，你可以长期租用四台服务器。小规模负载可以节省支出。也就是说，云费用将会继续下滑，因此我们要限制具有未来扩容需要的长期合约。一年时间的长期租赁通常足以获得定价上的优势。云允许我们超越基础设施的限制。按需付费适于通过横向和纵向扩展云基础设施支持可变的需求。
边缘站点（Edge Location）的缓存。缓存是一种传统的技术，针对重复请求改进应用性能。 AWS边缘站点（Edge Location）或Azure PoP（Point of Presence）将缓存提升到了一个新的级别，并降低了延迟。尽可能地使用支持经由边缘站点进行内容传送的云原生服务（例如，AWS Cloudfront或Azure CDN）。采用AWS API Gateway或Azure API应用，将自身的REST API服务公开给外部的和内部的消费者。这免除了所有的操作负担，通过点击几下鼠标，就可提供安全、缓存、管理等特性。