概要
AWS VPCに追加でCIDRブロック範囲を拡張することは、2017年より可能になっています。
作成時に割り当てるCIDRブロックがプライマリCIDR、追加する時に割り当てるCIDRブロックをセカンダリCIDRと呼びます。
しかし、「既存のVPCにセカンダリーCIDRを追加する」場合のCloudformationテンプレート例が公式ドキュメントに見当たらず、また、ネット記事にもなかったのでこちらで紹介します。
Cloudformationテンプレートサンプル
以下がサンプルです。プライマリCIDRとして'10.0.74.0/23'があるとします。
既存のVPCはVpcIdとしてExportされている前提です。
（Exportしていない場合でもID指定で参照させることはできます）
VPCSecondaryCidr:
Type: 'AWS::EC2::VPCCidrBlock'
Properties:
VpcId: !ImportValue VpcId
CidrBlock: '10.0.76.0/23'
上記で実施すれば、セカンダリCIDRとして追加されます。
マネジメントコンソールから確認すると、以下のように追加されていることがわかります。
プライマリCIDRは変更することはできません。
もちろん、セカンダリCIDR追加により、プライマリの方のIDが変わってしまったりとか既存のリソースが再作成されるとか、そういったイベントもありません。
ただし、追加時にいくつか制限（注意点）があります。
注意点
AWSの仕様的な意味では以下がまず制限事項です。
許可されているのは、/28 ネットマスクから /16 ネットマスクの間のブロックサイズです。
CIDR ブロックは、VPC に関連付けられている既存の CIDR ブロックと重複してはいけません。
使用できる IPv4 アドレスの範囲には制限があります。詳細については、「IPv4 CIDR ブロック関連付けの制限」を参照してください。
既存の CIDR ブロックのサイズを増減することはできません。
CIDR ブロックは、VPC ルートテーブルのいずれかのルートの送信先 CIDR 範囲と同じ､またはそれ以上に大きくすることはできません｡ 例えば、プライマリ CIDR ブロックが 10.2.0.0/16 である VPC では、仮想プライベートゲートウェイへの送信先 10.0.0.0/24 を持つルートテーブル内に、既存のルートがあります。10.0.0.0/16 範囲内のセカンダリ CIDR ブロックを関連付けるとします。既存のルートが原因で、10.0.0.0/24 以上の CIDR ブロックを関連付けることはできません。ただし、10.0.0.0/25 以下のセカンダリ CIDR ブロックを関連付けることはできます。
公式ドキュメントより：VPC CIDR ブロック
上記で言えば、10.0.74.0/23は10.0.74.0 - 10.0.75.255がIPアドレス範囲なので、新規に追加する'10.0.76.0/23'は重複しておらず、追加が成功します。
また、当然ですが、新しいCIDRブロックを追加した後は、ルートテーブルや関連付けなど新規に設定する必要があります。サブネットやRouteTable、Routeなども新しく追加している場合はいつも通りのリソースを準備すれば良いですが、そうではない場合はその点も考慮に入れて設計する必要があると思います。
Subnetも一緒に新規テンプレートで定義する場合、Cloudformationでのスタック更新において、という意味でもう一つ注意点を挙げると、先にSubnetが作成されてしまうと生成順序による依存関係エラーになることがあります。つまり、「セカンダリCIDRブロックが作成される前にサブネットが作成されてしまった」場合です。スタックのイベント欄には、正確には依存関係エラーとして表示されるのではなく、「そのCIDRブロックはinvalidだよ」というエラーが出ます。
その時は、DependsOnを使うと良いです（たびたびお世話になります...笑）。
以下のような形で依存関係エラーを解消できます。
PublicSubnet1:
Type: AWS::EC2::Subnet
DependsOn: VPCSecondaryCidr # これを追加
Properties:
CidrBlock: !Ref Public1Cidr
AvailabilityZone: !Ref AzName1
MapPublicIpOnLaunch: false
VpcId: !ImportValue VpcId