Is the AWS GWLB GENEVE encapsulation overhead always fixed at 68 bytes, or can it vary?

Based on AWS documentation, the GENEVE encapsulation overhead for Gateway Load Balancer is specified as 68 bytes. The documentation states that "The GENEVE encapsulation process adds 68 bytes to the original packet" and recommends that appliances support packets of at least 8,568 bytes to accommodate the 8,500-byte MTU plus this encapsulation overhead.

While you are correct that the GENEVE protocol specification allows for variable-length headers due to optional TLV (Type-Length-Value) fields, AWS documentation presents the 68-byte overhead as the standard encapsulation size used by Gateway Load Balancer. The documentation does not indicate that this overhead varies based on configuration or provide details about whether AWS currently uses optional TLV fields that might affect this size.

Regarding your specific questions:

• The documentation presents 68 bytes as the encapsulation overhead without qualifying it as "typical" or "default," suggesting this is the fixed overhead you should plan for in your current GWLB implementations.

• The documentation does not explicitly address whether this overhead could change in future updates or under different configurations. As with any AWS service, it's possible that future enhancements could modify this behavior, but any such changes would likely be communicated through AWS service updates and documentation revisions.

For production deployments, it would be prudent to design your network with the documented 68-byte overhead in mind, ensuring your appliances support the recommended minimum MTU of 8,568 bytes to handle the maximum packet size safely.
Sources
Gateway Load Balancers - Elastic Load Balancing

I'll add some flavor to the above answer if you're curious about it. You probably want to read the excellent albeit aging blog post at

https://aws.amazon.com/blogs/networking-and-content-delivery/integrate-your-custom-logic-or-appliance-with-aws-gateway-load-balancer/

which goes into details on how the GENEVE protocol is handled on the GWLBs. Specifically:

Outer Geneve Options: AWS Gateway Load Balancer TLVs

TLV 1: GWLBE/VPCE ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Class = 0x0108 (AWS)  |   Type = 1    |R|R|R| Len = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                     64-bit GWLBE/VPCE ID                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TLV 2: Attachment ID (Future/Optional)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Class = 0x0108 (AWS)  |   Type = 2    |R|R|R| Len = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|             64-bit Customer Visible Attachment ID              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TLV 3: Flow Cookie
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Option Class = 0x0108 (AWS)  |   Type = 3    |R|R|R| Len = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      32-bit Flow Cookie                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In summary, the GENEVE header that the GWLB adds looks like this:

The specific set of TLVs that GWLB adds is currently fixed, and no flexibility is needed. Could this change in the future? Of course it theoretically could, but that would by necessity need to be a well-coordinated and -documented change as it would be a breaking change for many implementations.