S
srinipadala
Azure API Management is a service that helps developers to expose their APIs to different consumers in a secure and scalable way. It allows developers to create, publish, and manage APIs, as well as to apply policies, transformations, and analytics to them. With the hosted APIs becoming super critical to the daily operations of any organization, it is important to ensure the availability of the infrastructure for continued operations. Though the service provides inbuilt resiliency features like Availability Zones and Locations, it is required to be prepared to create a replica of your API Management instance for various reasons, such as disaster recovery, testing, or migration. In this blog post, I will show you how to copy the data from one API Management instance to another, including the service configuration, the developer portal content, and all the metadata.
Prepare
Though it is ideal to have a replica created in a single click, owing to the multiple components involved, it requires reviewing the limitations of the inbuilt backup and backfill them with separate measures.
As a first step, let us review what is not backedup as a part of the inbuilt APIM backup.
Additionally, there may be settings within and outside the APIM instance that need consideration.
As outlined above, the Developer Portal is not included in the backup and the following considerations need to be made to ensure it is replicated across to the new instance.
Migrate
Once we identify the impacted API management objects and their external dependencies, we can follow the PowerShell or REST approach to backup the old instance and restore it to the new instance. Post restoration, proceed with updating the identified service configurations and external dependencies.
Conclusion
In this blog post, I detailed the API management service configurations that do not include or require updates when restored from a backup. Apart from the service configuration, there will be external dependencies to ensure that the new replica is a true copy of the original.
Continue reading...
Prepare
Though it is ideal to have a replica created in a single click, owing to the multiple components involved, it requires reviewing the limitations of the inbuilt backup and backfill them with separate measures.
As a first step, let us review what is not backedup as a part of the inbuilt APIM backup.
- Usage data used for creating analytics reports isn't included in the backup. Use Azure API Management REST API to periodically retrieve analytics reports for safekeeping. This information can sometimes be used for monetization and cannot be replicated across instances.
- Custom domain TLS/SSL certificates.
- Custom CA certificates, which include intermediate, or root certificates uploaded by the customer.
- Virtual network integration settings.
- Managed identity configuration.
- Azure Monitor diagnostic configuration.
- Protocols and ciphers settings.
- Developer portal content.
Additionally, there may be settings within and outside the APIM instance that need consideration.
- Self Hosted Gateways are restored in the new instance but need to be redeployed with the new configuration endpoint.
- Networking updates to NSGs, Firewalls, DNS are required due to the IP address changes, new subnets and private endpoints. Up and downstream systems may need to be adjusted to account for the IP address of the new resource.
- New units required in other regions would need to be deployed along with subnets, and up and downstream system dependencies.
- If using a System Assigned Identity, RBAC to dependencies should be applied based on the new resource identity.
- Authorizations are instance specific and need to be recreated.
- All external monitoring assets including dashboards, alerts, and automation need to be applied to the new instance.
- External Cache configuration is not included and should be setup.
- Event Subscriptions and Application integrations need to be recreated.
As outlined above, the Developer Portal is not included in the backup and the following considerations need to be made to ensure it is replicated across to the new instance.
- Dev Portal customization Content must first be backed up from the current dev portal and applied to the new dev portal using the V3 Scripts
- Though the OAuth Config for Dev Portal and test console is imported automatically. They need to be reconfigured to use a new app registration with the new redirect URI.
- The identity providers are imported but need to be configured to use a new app registration with the new redirect URI.
- Delegation routines should be updated to reflect the new instance endpoints.
Migrate
Once we identify the impacted API management objects and their external dependencies, we can follow the PowerShell or REST approach to backup the old instance and restore it to the new instance. Post restoration, proceed with updating the identified service configurations and external dependencies.
Conclusion
In this blog post, I detailed the API management service configurations that do not include or require updates when restored from a backup. Apart from the service configuration, there will be external dependencies to ensure that the new replica is a true copy of the original.
Continue reading...