Resource Center

Megaport + IaC: Automating Global Networks at DevOps Speed

This webinar shows how to automate Megaport network services using Terraform so that connectivity is built, changed, and removed with the same DevOps workflows you use for cloud infrastructure. It explains Megaport’s Network as a Service (NaaS) model, introduces the Megaport Terraform provider, and walks through a live demo: creating ports, connecting them with a Virtual Cross Connect (VXC), changing bandwidth on the fly, tearing it all down, and importing existing services into Terraform.

The session closes with practical best practices around state management, deletion protection, and where to find up-to-date docs, examples, and FAQs.

What the Webinar Covers

• How Megaport’s private global network works and why it fits Infrastructure as Code.
• What Terraform is and how the Megaport Terraform provider plugs into it.
• How to use the Megaport staging environment to test IaC safely.
• How to:
  • Create ports in different data centres.
  • Connect them with a VXC.
  • Change VXC bandwidth without downtime.
  • Destroy services cleanly.
• How to import an existing Megaport Cloud Router (MCR) into Terraform.
• Practical guidance on API keys, state files, deletion protection, and ongoing operations.

Megaport in Brief: Network as a Service

Megaport is presented as:

• A global private network spanning 26 countries and 1000+ enabled data centers.
• A Network as a Service platform:
  • Services can be spun up for minutes, days, or years.
  • Ideal for migrations, temporary projects, and dynamic workloads.
• A provider of:
  • Data centre ports for physical access.
  • Megaport Cloud Router (MCR) for cloud-to-cloud and virtual routing.
  • Megaport Virtual Edge (MVE) for branch/edge connectivity using virtual appliances.
• Crucially: everything is API-driven and automatable, which is where Terraform comes in.

Terraform and the Megaport Provider

Terraform is introduced as:

• An Infrastructure as Code tool from HashiCorp.
• Using a high-level, human-readable language to describe infrastructure:
  • Network, compute, storage, and more.
• A natural fit for DevOps:
  • Works with standard CI/CD pipelines.
  • Integrates with multiple cloud providers through “providers”.

The Megaport Terraform provider lets you:

• Define Megaport services (ports, VXCs, MCRs, MVEs) alongside your cloud resources.
• Build multi-cloud and hybrid topologies as code.
• Manage the full lifecycle: create, modify, and delete services via Terraform workflows.

Megaport’s documentation and GitHub repo provide:

• End-to-end Terraform guides (from “zero” to multi-cloud designs).
• Example code for common topologies and use cases.

Getting Ready: Prerequisites and Environments

Before deploying anything:

Design your scenario

Decide what you are automating:

• Data centre ↔ data centre.
• Data centre ↔ cloud.
• Cloud ↔ cloud via MCR.
• Branch ↔ cloud / data centre via MVE.

Megaport publishes 13 reference multi-cloud scenarios that you can map directly into Terraform configurations.

Accounts, permissions, and API keys

You’ll need:

• A Megaport account (anyone can sign up).
• A user with Company Admin role to:
  • Create API keys for Terraform.
  • Allow creation, modification, and deletion of services.

Within the portal, you:

• Create an API key and secret.
• Use those credentials in the Terraform provider block so Terraform can call the Megaport API.

Staging vs production

Megaport provides two environments:

• Production
  • Real services, real billing, real impact.
• Staging
  • A fully simulated environment.
  • Production services are mirrored into staging every 24 hours.
  • You can add, change, and delete services without any real-world effect.
  • All changes are reset daily back to the production snapshot.

The staging portal is clearly marked (yellow banner) so you don’t accidentally “test” in production. Think of it as a sandbox you can’t break, or bill.

Tooling and references

• Install Terraform for your OS.
• Use an editor such as Visual Studio Code with the HashiCorp Terraform extension for:
  • Syntax highlighting.
  • Autocomplete.
  • Early error detection.
• Use the Megaport docs and GitHub examples as starting templates rather than writing everything from scratch.

Demo: Building a VXC Between Two Data Centres

The main demo shows Terraform in action:

Files and provider configuration

• A working folder (e.g. webinar/) with:
  • provider.tf — defines required providers and Megaport-specific settings.
  • megaport.tf — defines Megaport resources (ports, VXCs, etc.).
• provider.tf includes:
  • required_providers block referencing the Megaport provider (e.g. version 1.3.8 or higher).
  • provider "megaport" block with:
    • environment = "staging".
    • access_key and secret_key.
    • accept_purchase_terms = true.

Terraform will generate a state file (terraform.tfstate) in this folder to track all managed resources.

Defining ports and VXC

The example builds:

• Two 10 Gbps Megaport ports:
  • Port 1 in Equinix SY1 (Sydney).
  • Port 2 in NextDC S1.
• One VXC between them at 10 Gbps.

Key steps:

1. Find location IDs
   • Call the Megaport /locations API (no authentication required).
   • Filter on "Sydney" / "SY1" / "S1" to find matching locations.
   • Use the returned id values in Terraform as location_id.
2. Create megaport_port resources
   • Set name, speed (e.g. 10000 for 10 Gbps), location_id, contract_term, and optional cost_center.
3. Create a megaport_vxc resource
   • Set description, rate_limit, and contract term.
   • Reference the ports with requested_product_uid values pointing at megaport_port.port1 and megaport_port.port2.
4. Run terraform init
   • Downloads the Megaport provider and prepares the working directory.
5. Run terraform plan
   • Validates syntax.
   • Shows that 2 ports and 1 VXC will be created.
6. Run terraform apply
   • Terraform creates the ports first, then the VXC (it understands the dependencies).

In the staging portal, you can see:

• The ports appearing and transitioning to an “up” state.
• The VXC connecting the two ports and coming online.

Changing Bandwidth Without Outage

To demonstrate lifecycle changes, the VXC’s bandwidth is modified:

• Original rate_limit: 10,000 Mbps (10 Gbps).
• New rate_limit: 1,000 Mbps (1 Gbps).

Workflow:

1. Update the rate_limit value in megaport.tf.
2. Run terraform plan to see that the VXC will be updated in place, not destroyed.
3. Run terraform apply.

Result:

• No downtime; only the bandwidth changes.
• In the portal’s Billing view, you see:
  • The initial 10 Gbps period.
  • The new 1 Gbps period.
  • Charges calculated based on minute-level usage over the month.

This illustrates the NaaS model: bandwidth is elastic, and cost is tied to real consumption rather than static circuits.

Cleaning Up: Destroying Services and Understanding State

The demo then walks through cleanup:

Selective removal

• Commenting out or deleting the VXC block in megaport.tf.
• Running terraform plan shows that the VXC will be destroyed.
• terraform apply removes only the VXC; ports remain.

Full teardown

• terraform destroy is used to remove everything defined in that folder (both ports and VXC).
• A reminder: this is powerful and must be used carefully in production.

After teardown, the staging portal shows no remaining services.

State file inspection

• terraform.tfstate contains the full description of managed resources.
• A backup state file is also created.
• The state file is readable, showing attributes for each resource (e.g. ports and VXCs).
• In real environments, state should be:
  • Stored in a central, reliable backend (not just a laptop).
  • Backed up regularly.

Importing Existing Megaport Services into Terraform

Many customers start by building services in the Megaport portal and only later adopt Terraform. The webinar shows how to bring those existing services under Terraform control via terraform import.

Example: importing a Megaport Cloud Router (MCR)

1. In the portal:

   • Identify the MCR (e.g. name TF demo).
   • Note its speed (e.g. 1 Gbps), data centre (e.g. NextDC S1, ID 10), contract term, and diversity zone (RED).
   • Copy the service UID.

2. In Terraform:

   • Define a megaport_mcr resource with matching attributes (name, speed, location ID, contract term, diversity zone).

3. Run:

   terraform import megaport_mcr.mcr_1 <service-uid>
   

4. Terraform pulls the live configuration into the state file, so future plans and applies treat this MCR as managed IaC.

From there, you can extend the configuration with additional VXCs, cloud connections, and routing policies.

Best Practices and Ongoing Operations

The webinar closes with practical guidance on running this safely:

• Prevent accidental deletion in Terraform
  • Use lifecycle { prevent_destroy = true } inside critical resources.
  • Protects against accidental terraform destroy or destructive changes.
• Lock services in the Megaport portal
  • Use the padlock icon on services to prevent deletion, including via API.
  • A simple guardrail for high-value circuits.
• Treat state as critical infrastructure
  • Don’t leave production state on a single workstation.
  • Use Terraform’s state commands to inspect and manage state safely.
  • Consider remote backends and access controls.
• Use the docs and FAQ
  • Megaport’s Terraform docs include best practices and troubleshooting.
  • The FAQ page is updated based on real customer questions.
• Track provider releases
  • The Megaport engineering team releases updates frequently.
  • Keep an eye on the GitHub release page.
  • Update the required_providers version in provider.tf to pick up new features and fixes.
• Engage with the team
  • Raise issues or questions via the Megaport Terraform provider GitHub page.
  • Reach out to Megaport contacts (such as the presenters) for specific design questions.

Conclusion

This session shows that Megaport’s global network is built to be automated, and Terraform is the mechanism that turns that into repeatable, testable workflows.

By combining Megaport’s staging environment, clear documentation, and a mature Terraform provider, you can design, deploy, modify, and remove connectivity with the same discipline you apply to application and cloud infrastructure.

You can experiment safely, adopt NaaS-style bandwidth and contract flexibility, import existing services into code, and protect production with sensible guardrails on both the Terraform and portal sides. The result is a global network that moves at DevOps speed—without relying on manual portal clicks, change tickets, or long-lived static circuits.