Tag: vpc

AWS 的台北區 (Local Zone) 開了

AWS 總算是宣佈啟用台北 Local Zone 了：「AWS Local Zones Expansion: Taipei and Delhi」，中文的公告在「AWS 宣布在台全新 AWS Local Zone 正式啟用」。

翻了一下先前的預告是六月初的時候，大概是四個月前，當時寫了「AWS 宣佈將在台灣推出 Local Zone」這篇。

看 Jeff Barr 提供的 screenshot 可以看到如同先前了解的，就是掛在東京區下面 (ap-northeast-1)：

比較奇怪的地方是啟用的方式，我是在在 EC2 的 dashboard 上看到這個進去開 (然後是 Service health)，在 VPC 裡面反而沒看到：

然後開了之後要等他幾分鐘啟用，不是幾秒後 refresh 就會出現，我大概等了兩分鐘，跟當初開其他 non-default region 的經驗類似：

然後再回到 VPC 裡面開 subnet，開完後再回到 EC2 上開機器，流程不是很直覺。

另外從「AWS Local Zones features」這邊可以看到目前的服務有限，另外 Jeff Barr 的公告也可以看到目前台北區支援的項目：

After you do this, you can launch Amazon Elastic Compute Cloud (Amazon EC2) instances, create Amazon Elastic Block Store (Amazon EBS) volumes,and make use of other services including Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and Amazon Virtual Private Cloud (Amazon VPC). The new Local Zones include T3, C5, M5, R5, and G4dn instances in select sizes, along with General Purpose SSD (gp2) EBS volumes.

不過這邊有不一致的地方：在 AWS 頁面上是寫 T3 是 upcoming，但 Jeff Barr 的公告則是說可以用 T3，這點晚點來測試看看才知道哪個是對的... 因為我現在連 m5.large 也開不起來：

只要把設定換到東京的 subnet 內就正常，這個錯誤訊息實在是不知道發生什麼事情 (已經設 gp2)，還得繼續摸...

Linode 的 VPC 與 VLAN

看到 Linode 的「Go Private with VLANs and VPCs」這篇，裡面特地提到了 VLAN：

Can a VLAN be used as a VPC on Linode?

The short answer is again, yes, we can use a VLAN as a VPC on Linode.

在「Common Use Cases for Linode's VLAN Service」這篇 (發現是 2021 年就有的資料) 裡面開頭就有提到：

This means that two or more Linodes connected via the VLAN can see each other as if they were directly connected to the same physical Ethernet network. This network supports all the logical Ethernet features like L2 broadcast and L2 multicast.

所以看起來的確是在 Linode 的 SDN 上面支援了 VLAN。記得早期是用 Cisco 的方案 (2013 年的時候有「Linode NextGen: The Network」這篇)，現在不知道是什麼架構...

AWS Global Accelerator 支援 IPv6

AWS 的 Anycast 服務 AWS Global Accelerator 宣佈支援 IPv6：「New for AWS Global Accelerator – Internet Protocol Version 6 (IPv6) Support」。

算是補功能，不過這個功能只對於「純 IPv6 環境」的使用者端有用 (沒有 DNS64 + NAT64 的轉換)，目前商轉給一般使用者用的 IPv6 環境應該都還是有掛 DNS64 + NAT64 才對...

另外使用這個功能會需要 VPC 有 IPv6 能力：

To test this new feature, I need a dual-stack application with an ALB entry point. The application must be deployed in Amazon Virtual Private Cloud (Amazon VPC) and support IPv6 traffic.

然後 IPv4 會進到 IPv4 的服務裡，IPv6 則會進到 IPv6 的服務裡：

Protocol translation is not supported, neither IPv4 to IPv6 nor IPv6 to IPv4. For example, Global Accelerator will not allow me to configure a dual-stack accelerator with an IPv4-only ALB endpoint. Also, for IPv6 ALB endpoints, client IP preservation must be enabled.

短時間還用不太到，但之後應該有機會...

Route 53 支援 DNS64，以及 NAT Gateway 支援 NAT64

AWS 宣佈了一套機制，讓 IPv6-only 的機器可以連到 IPv4-only 的服務：「Let Your IPv6-only Workloads Connect to IPv4 Services」。

首先是 DNS64，針對只有 IPv4-only 的 A record 自動加上 AAAA record (如果已經有 AAAA record 的則不變)，這邊提到的 64:ff9b::/96 是來自 DNS64 標準內的規範：

The DNS resolver first checks if the record contains an IPv6 address (AAAA record). If it does, the IPv6 address is returned. The IPv6 host can connect to the service using just IPv6. When the record only contains an IPv4 address, the Route 53 resolver synthesizes an IPv6 address by prepending the well-known 64:ff9b::/96 prefix to the IPv4 address.

再來就是 NAT Gateway 可以把 64:ff9b::/96 透過 NAT64 轉到 IPv4 network 上：

You may configure subnet routing to send all packets starting with 64:ff9b::/96 to the NAT gateway. The NAT gateway recognizes the IPv6 address prefix, extracts the IPv4 address from it, and initiates an IPv4 connection to the destination. As usual, the source IPv4 address is the IPv4 address of the NAT gateway itself.

由於有些 protocol 會帶 IP address 資訊，所以不能保證 NAT64 一定會動，但大多數的情況應該是可以解決，至少提供了 IPv6-only server 連到 IPv4-only network 上的方法...

AWS App Runner 總算可以存取 VPC 內的資源了

算是上個星期的消息了，App Runner 這個產品剛出來的時候無法連到 VPC 內的資源，不知道要怎麼用，現在總算是把這個功能補上了：「New for App Runner – VPC Support」。

不過還是不看好，旁邊還有 AWS Elastic Beanstalk、AWS Amplify 同質性超高的服務，都是只寫 code 丟上去就能跑：

AWS App Runner is a fully managed service that makes it easy for developers to quickly deploy containerized web applications and APIs, at scale and with no prior infrastructure experience required. Start with your source code or a container image. App Runner builds and deploys the web application automatically, load balances traffic with encryption, scales to meet your traffic needs, and makes it easy for your services to communicate with other AWS services and applications that run in a private Amazon VPC. With App Runner, rather than thinking about servers or scaling, you have more time to focus on your applications.

AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, Go, and Docker on familiar servers such as Apache, Nginx, Passenger, and IIS.

You can simply upload your code and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, auto-scaling to application health monitoring. At the same time, you retain full control over the AWS resources powering your application and can access the underlying resources at any time.

AWS Amplify is a set of purpose-built tools and features that lets frontend web and mobile developers quickly and easily build full-stack applications on AWS, with the flexibility to leverage the breadth of AWS services as your use cases evolve. With Amplify, you can configure a web or mobile app backend, connect your app in minutes, visually build a web frontend UI, and easily manage app content outside the AWS console. Ship faster and scale effortlessly—with no cloud expertise needed.

更不用說旁邊還有 Lambda 類的架構...

Amazon VPC 支援純 IPv6 的網段了

Amazon VPC 支援純 IPv6 的網段了：「Amazon Virtual Private Cloud (VPC) customers can now create IPv6-only subnets and EC2 instances」。

先前機器都還是要設一個 IPv4 位置，所以網段都必須有 IPv4 network space，這次推出使得機器可以跑在 IPv6-only network 上了，不過 Linux 裡面應該還是會有個 lo 與 127.0.0.1...

短時間應該用不到，不過可以先玩看看感覺一下...

AWS 的 VPC 內可以用 IPv6 的 Metadata Service、Time Service 與 DNS Server 了

在「IPv6 endpoints are now available for the Amazon EC2 Instance Metadata Service, Amazon Time Sync Service, and Amazon VPC DNS Server」這邊看到的，AWS 把一些基礎服務補上了 IPv6 interface：

The Amazon EC2 Instance Metadata Service, Amazon Time Sync Service, and Amazon VPC DNS server can now be accessed over IPv6 endpoints by instances built on the Nitro System.

Metadata Service 的部份在「Use IMDSv2」這邊可以看到，在 IPv4 的時候是 169.254.169.254，在 IPv6 時則是 fd00:ec2::254：

The examples in this section use the IPv4 address of the instance metadata service: 169.254.169.254. If you are retrieving instance metadata for EC2 instances over the IPv6 address, ensure that you enable and use the IPv6 address instead: fd00:ec2::254. The IPv6 address of the instance metadata service is compatible with IMDSv2 commands. The IPv6 address is only accessible on Instances built on the Nitro System.

Time Service 的部份可以在「Set the time for your Linux instance」這邊翻到，可以看到 fd00:ec2::123 這個位置：

The Amazon Time Sync Service is available through NTP at the 169.254.169.123 IPv4 address or the fd00:ec2::123 IPv6 address for any instance running in a VPC. The IPv6 address is only accessible on Instances built on the Nitro System.

DNS 的部份則是在「DNS support for your VPC」這邊翻，可以看到 fd00:ec2::253 這個 IPv6 address 的 DNS 服務：

If this attribute is true, queries to the Amazon provided DNS server at the 169.254.169.253 IPv4 address (or the reserved IP address at the base of the VPC IPv4 network range plus two) and the fd00:ec2::253 IPv6 address will succeed. The IPv6 address is only accessible on EC2 instances built on the Nitro System.

算是又補齊了一些基礎建設...

另外 EC2 剛好這三個字都在十六進位表示法的範圍內，就拿來當 IPv6 address 也是讓人好記很多。

另外結尾故意用 ::254、::123、::253 (要注意這是十六進位) 也讓人好記很多，而不是 ::fe 這類 hex。

AWS 宣佈 EC2-Classic 退役的計畫

AWS 宣佈了歷史悠久的 EC2-Classic 的退役計畫：「EC2-Classic is Retiring – Here’s How to Prepare」。

EC2-Classic 是 VPC 出來之前的產物，後來出現 VPC 的設計讓整個網路架構更有彈性，而且後來的新機種也都出在 VPC 上，EC2-Classic 算是歷史產物。

目前宣佈的幾個時間點，首先是 2013 年年底的帳號已經是 VPC-only，除非有另外開 support ticket 要求要有 EC2-Classic：

All AWS accounts created after December 4, 2013 are already VPC-only, unless EC2-Classic was enabled as a result of a support request.

接下來是今年的十月底，如果 AWS 帳號沒有使用 EC2-Classic 就會自動關閉 EC2-Classic 的權限，另外也會停止販售 EC2-Classic 的 RI：

On October 30, 2021 we will disable EC2-Classic in Regions for AWS accounts that have no active EC2-Classic resources in the Region, as listed below. We will also stop selling 1-year and 3-year Reserved Instances for EC2-Classic.

最後會希望在 2022 年八月中的時候全部轉移完：

On August 15, 2022 we expect all migrations to be complete, with no remaining EC2-Classic resources present in any AWS account.

看起來沒用完的 RI 會退錢？

Amazon VPC 允許直接把整個網段配到某台 EC2 Instance 上了

看到「Amazon Virtual Private Cloud (VPC) customers can now assign IP prefixes to their EC2 instances」這邊的消息，VPC 可以把整個網段配到某台 EC2 Instance 上了。

之前也有其他方法可以做到類似的事情：

  • 用 VPC 提供的 Routing Table 把網段指到某台 EC2 的機器上。
  • 把這台 EC2 機器的「Enable Source/Destination Check」關閉。

目前就是用這個方法搞定 VPN server 的：我們希望機器連上 VPN 後拿到 10.x.x.x 的 IP address，而且可以被 VPC 內直接存取，而不要被 NAT 掉。

好像該開張票轉移過去...

AWS 同一區的 VPC Peering 流量不收費了

AWS 在同一個 AZ 裡面的流量是不收費的，但如果是跨帳號的話，還是要當作 inter-AZ 流量 (收 USD$0.01/GB 的費用)，現在則是宣佈不用了：「Amazon VPC Announces Pricing Change for VPC Peering」。

要注意的是不同帳號的 a 不一定相同 (像是 us-east-1a 在不同帳號對應到的實際 AZ 不同)，得透過 AWS 提供的資料確認底層實際的 AZ 是哪個。

回朔到這個月月初生效：

Starting May 1st 2021, all data transfer over a VPC Peering connection that stays within an Availability Zone (AZ) is now free. All data transfer over a VPC Peering connection that crosses Availability Zones will continue to be charged at the standard in-region data transfer rates. You can use the Availability Zone-ID to uniquely and consistently identify an Availability Zone across different AWS accounts.