Category: Networking & Content Delivery

本文介绍一个可以建立包含多个（可自定义）子网（包含子网路由）的 VPC 脚本。通过这个脚本创建 VPC 时，不需要指定每个子网的 CIDR， 只需要输入子网支持的 IP 地址个数，子网的路由类型（内部子网，通过 NAT 访问 Internet 或者通过 Internet Gateway 访问 Internet），在VPC内对S3和DynamoDB的访问，该脚本会自动创建 VPC EndPoint 并配置合适的路由。配合文中提到的其他脚本，可以快速创建 Landing Zone（AWS 基本运行环境，包含 VPC, Subnet, 堡垒机，CloudTrail, AWS Config, Log 复制等）

在未来几周，我们将为 Amazon CloudFront 添加增强的域保护功能。简单说明如下：新的措施旨在确保 CloudFront 处理的请求是代表合法的域所有者处理的。

使用 CloudFront 接收您未获授权使用的域流量已经违反了 AWS 服务条款。在注意到此类活动后，我们会通过在后台禁用存在滥用行为的账户予以处理。现在，我们也会将检查直接集成到 CloudFront API 和内容分发服务之中。

本文将探讨 SaaS 组织采用多区域策略的常见原因。以此为背景，我们可以深入了解在构建、部署和管理多区域 SaaS 环境时常用的架构模式和策略。

今天，我很高兴宣布 Amazon 推出新通用顶级域 (gTLD) .BOT。客户可以使用 .BOT 域提供其机器人的身份和门户。健身机器人、Slack 机器人、电子商务机器人等等，都可以受益于方便易用的 .BOT 域。“Bot”是 2016 年 .COM TLD 注册量第四大的域关键词，每月有超过 6000 个域注册。客户使用 .BOT 域可以为其机器人提供确定的 Internet 身份，增强 SEO 性能。

Amazon ECS 新推出的集成式服务发现的新优势全面放送，一起来了解Route 53在新服务发现下的变化。

NAT就在那里 下图 是EC2实例通过IGW(Internet网关) 接入到Internet的示意图。熟悉AWS的读者会知道，这里EC2实例和Internet通信的两个方向上，实际上发生了如下的转换： 从EC2实例发出的前往Internet的IP包，其源地址10.0.0.10在经过IGW时，会被转换为与实例关联的公网地址 54.232.0.1； 从Internet发给54.232.0.1的IP包，经过IGW时其目的地址会转换为ENI对应的内网地址10.0.0.10并被送到 EC2实例； 可以看到，这里Internet网关就是起到实例的内网地址和公网地址一对一的基本 NAT（网络地址转换）的功能。 相比于没有NAT的场景，大部分的应用、软件不需要任何改变就能在基本NAT的场景下继续工作，例如基于HTTP协议的Web应用等；但是对于某些应用，例如FTP、VoIP等，网络地址转换会给应用带来一些意想不到的挑战。今天我们以历史悠久的FTP协议为例，来和大家探讨一下NAT给FTP这样的应用带来什么样的挑战，以及FTP应用和协议又是如何演进去适应它。 被动模式下的FTP 我们重温一下FTP的工作过程。客户端连接服务端TCP 21端口建立命令通道后，输入用户名密码完成登录；随后的每一次数据传输都需要另外建立数据通道进行； 如果数据通道由客户端发起，服务端接受，我们称之为被动模式；反之，如果数据通道由服务端发起，客户端接受，则称之为主动模式。 为简化讨论，我们以被动模式为例。 同一个私网内 我们在EC2实例10.0.0.10上搭建了一台FTP服务器，它监听在21端口。现在我们从同一个VPC里的另外一台EC2上运行FTP客户端；那么整个过程会很顺利。 从Internet访问 现在我们从位于Internet某处的一台PC上运行FTP客户端。 这里连接超时的原因显而易见，FTP服务端发送给客户端的IP地址是服务端的私有地址。位于Internet上的客户端无法建立与位于VPC内部的私有地址10.0.0.10直接通讯。 解决这个问题有多种方法，我们由简单到复杂分别叙述。 增强协议适配NAT FTP协议针对NAT和其他因素，对协议进行了增强，提供了增强版的被动模式EPSV命令[1]。 下面的例子里，服务端不再显式指定IP地址，只提供数据通道的端口号。客户端默认与控制通道相同的IP地址建立数据通道。 可以看到，解决方案很优雅。实际上如果你在阅读本文的时候，绝大部分FTP服务端和客户端都已经实现了EPSV，而且优先使用它，所以FTP应用目前在EC2上是可以称之为开箱即用的。当然这需要客户端和服务端都支持增强的协议才能达成；如果我们不修改协议，能否解决这个问题呢。 放开那协议！我来！ 有些时候，修改协议和实现需要多方协调和很长的时间才能完成。在RFC2428标准化之前，一些FTP实现就已经通过修改实现来适配基本NAT，而非修改协议。 以vsftpd为例，它允许通过配置文件vsftpd.conf中的配置项 pasv_address=54.232.0.1 告知服务端，在PASV被动模式下，应当指示客户端连接到配置项指定的IP（而不是服务端的私有IP）来适配基本NAT。 其他的一些常见应用例如VoIP类应用，也有类似的机制去适配基本NAT；例如引入STUN/TURN/ICE等方式［2］适配各种更加复杂的NAT穿越场景；但是针对部署在EC2上的基本NAT环境，也有通过实现上的简单调整，例如开源VoIP应用Asterisk就支持通过在配置文件/etc/asterisk/sip.conf里指定本机的公网地址和本地网段的方式来适配基本NAT。 nat=yes externaddr=54.223.0.1 localnet=10.0.0.0/16 协议和实现我都不想动！ 作为一枚任性的读者，如果您既不想动协议也不想动实现，这里笔者给读者介绍一种剑走偏锋的方式，读者若有兴趣，可以轻松愉快的在AWS上试一试，看看能否解决你的应用适配基本NAT。下面是一段shell脚本，当然是运行在Linux操作系统上的。           #从EC2 实例元数据服务获取本实例的公网IP(如有)、私网IP           public_ipv4=`curl -s http://169.254.169.254/latest/meta-data/public-ipv4`           local_ipv4=`curl -s http://169.254.169.254/latest/meta-data/local-ipv4`           #配置私网地址段，这里应为EC2实例所在VPC的地址范围           local_net=10.0.0.0/16           if [ […]