VM-Series AWS Marketplace Annual Contract – Upgrade Instance Size Mid-Term

Good news on the contract side — this was solved in May 2024 with a feature called annual agreement amendments, and it does most of what you're asking for.

Q1 & Q2: Yes, and it's amended with proration — no cancel-and-rebuy

Amendments let you switch EC2 instance types on an active annual agreement directly from the console. The mechanics:

• You keep your original discount rate
• AWS calculates the prorated cost of the new instance type for the remaining term
• The prorated value of the instance type you're removing is credited against the cost of the new one
• The agreement's original end date carries over, so renewals stay aligned

The one hard constraint: the prorated cost of the change must be greater than zero. You can scale up, but you can't downgrade to reduce the subscription value mid-term. Downsizing has to wait for renewal.

Amendments work on public offers and on private offers that don't use installment plans.

Q3: Effective immediately, but mind the gap

The amendment itself is a console operation. The thing to watch is sequencing.

The annual subscription covers only the instance types you specified at purchase. Launching any other instance type incurs the hourly rate for that type. So if you resize the EC2 instance before amending the agreement, you'll be paying on-demand for the VM-Series software during the gap.

Amend first, then resize.

Q4: Your process works, but there's a simpler path worth testing

The migrate-and-replace sequence you outlined is sound and is the safe option. But for AMI products, the Marketplace product code lives with the root volume — so an in-place resize (stop → change instance type → start) generally preserves licensing without launching anything new.

That would collapse your five steps to: amend the agreement, stop, resize, start. No config export/import, no ENI juggling, no EIP reassociation.

Two things to verify with Palo Alto before relying on it:

• Interface count. VM-Series ENI limits track the instance type. Moving between families can change how many interfaces are supported, and dataplane interface mapping is order-sensitive on VM-Series.
• vCPU licensing. Confirm the target instance's vCPU count is covered by your VM-Series model/licence tier under the PAYG bundle.

If either raises doubts, fall back to your replace-based approach.

Q5: Licensing and downtime

Licensing — the main exposure is the timing gap above. Also worth confirming with your Palo Alto rep: some VM-Series capacity attributes are pinned at first boot, which can affect whether an in-place resize behaves identically to a fresh launch at the larger size.

Downtime — an instance type change requires a stop, so there's unavoidable downtime on that node. For production this argues strongly for an HA pair, upgrading one member at a time with a failover between. If you're deploying a single VM-Series in production, I'd reconsider that independently of the resize question — a single firewall is a single point of failure for everything behind it.

Before you commit

Two things I'd nail down with the seller rather than assume:

1. Confirm Palo Alto's VM-Series listing actually offers annual pricing on the instance types you might grow into. Annual pricing is defined per instance type, and a seller doesn't have to list every size.
2. Ask Palo Alto directly whether they support in-place instance resize for VM-Series on AWS, or require redeploy. That single answer determines whether your Q4 process is necessary or optional.