I have deployed API Management in EU region and what happens when EU region goes down?
Will API Management automatically switch over to disaster discovery site other regions?
Can we control/specify an EU data recovery center?
You can control it by configuring a Secondary region if you are using the Premium tier.
Please find information about regions here:
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-deploy-multi-region
An API Management gateway component is deployed to every selected Primary and Secondary region. Incoming API requests are automatically directed to the closest region. If a region goes offline, the API requests will be automatically routed around the failed region to the next closest gateway.
Only the gateway component of API Management is deployed to all regions. The service management component and developer portal are hosted in the Primary region only. Therefore, in case of the Primary region outage, access to the developer portal and ability to change configuration (e.g. adding APIs, applying policies) will be impaired until the Primary region comes back online. While the Primary region is offline, available Secondary regions will continue to serve the API traffic using the latest configuration available to them. Optionally enable zone redundancy to improve the availability and resiliency of the Primary or Secondary regions.
Related
Currently, I got a task about integrating ECS openshift with AppDynamics.
Here is my situation, I have Integrated my project with AppDynamics . I can’t see my project on appDynamics Dashboard, but I can see it on the Tier and node. i have checked the router for openshift,it’s not available ，so i want to ask you guys if it is the reason why i can not see my project on the AppDynamics Dashboard ？
If your Nodes are showing under "Tiers & Nodes" this means that the Agents are reporting to the AppDynamics Controller.
If however there is nothing shown in the Application (or Tier, or Node) Dashboards this means that there are no registered Business Transactions relating to that Application (or Tier, or Node).
Dashboards (or flow maps, more accurately) generally show a view of registered Business Transactions (not simply of entities which are known to the Controller).
Have a look at the docs for an explanation of what a Business Transaction is and how these can be configured should none be detected OOTB:
https://docs.appdynamics.com/21.2/en/application-monitoring/configure-instrumentation/transaction-detection-rules
https://docs.appdynamics.com/21.2/en/application-monitoring/business-transactions
I'd like to have a page or a section of information that only is relevant to a specific API. Is that possible in the new portal?
In this case it has to do with information about event data that is sent out (to webhooks) when new items are created and that are then available in operations for the API. If it's not possible to have i an "API-specific" page, where would you put something like this?
I believe in this case you are trying to add some sort of static page or documentation to explain the functionality about a specific API. You may refer to this. As mentioned in the thread, you can try with swagger but in APIM portal it might not work immediately. Microsoft product team has confirmed that they working on improving support for OpenAPIv3. The ETA is about end of September.
However, you may also check the self-hosted gateway feature
The self-hosted gateway feature expands API Management support for hybrid and multi-cloud environments and enables organizations to efficiently and securely manage APIs hosted on-premises and across clouds from a single API Management service in Azure.
Official Documentation
Can Azure API Management fulfill the below requirements or do I need to use Application Gateway as well along with Azure API Management?
Route traffic to various microservices
Cope with traffic demands and scaling
Support API versioning
The microservices are hosted on Azure App services.
Thank you
Whether API Management can do this, depends on what you exactly mean by these requirements.
Route traffic to various microservices
As you mention the microservices are Azure Web Apps, I assume you mean different microservices to route to, based on a different endpoint.
You can route a request based on the contents to a certain endpoint.
Cope with traffic demands and scaling
Azure Web Apps are scalable by default, and the traffic manager takes care of it. APIM can only handle traffic demands and scaling to the platform itself. You can scale up or out, even automated based on rules. However, as scaling might take some time it's recommended to monitor the capacity metric to accomodate for increasing load.
Support API versioning
APIM is 'just' an virtualization layer between the customer and the API. So having API versioning on APIM only makes sense when you actually do versioning on the API. In APIM you can create version sets which specify the versioning strategy for the API, based on header, path or querystring. An API can be deployed in APIM based on the version set, which makes it a versioned API.
What is the official and required process to perform our own independent vulnerability scans against virtual machines in the Google Compute Engine? These will be Penetration tests (our own) that will scan the public IP for open ports and report results back to us.
Microsoft Azure requires authorization and so does Amazon. Does Google?
No, Google does not need to be notified before you run a security scan on your Google Compute Engine projects. You will have to abide by Google Cloud Platform Acceptable Use Policy and the Terms of Service.
Please also be aware of Google's Vulnerability Rewards Program Rules.
By default all incoming traffic from an outside network is blocked. Each customer has the responsibility to create the appropriate rules to allow access to the GCE instances as he considers appropriate:
https://cloud.google.com/compute/docs/networking#firewalls
If you sign up for a trial you can perform that test over your own project. Overall security configuration is up to the owner of the project and does not reside on Google.
In regards to internal infrastructure Google has its own security teams working 24x 7 to assure it keeps on the vanguard in the best security practices. http://googleonlinesecurity.blogspot.ca/
I recently created a GCE instance in the "europe-west" zone.
Its intended to run an application that connects off to an external webservice.
When trying to login to the webservice I get an error about restricted region.
It turns out the webservice does not accept login requests from US regions.
I checked and even though my instance is in the "europe-west" zone, its associated IP is being reported as US.
Is there anything I can do to get a proper region IP or is there any way around this?
May need to abandon GCE if the answer is no...
Thanks
Robert
Reposting the answer from Gary Ling, product manager for external networking:
Thank you for posting the email. We are aware of this issue that
(almost) all Google IP addresses are SWIP'ed to be Mountain View, CA.
And at Google, it's not uncommon to remap a block of IPs from one
location to another, especially given the elasticity of IP addresses
for the Cloud. Too bad that many of external Geo IP services solely
depend on SWIP database. While we are evaluating what we can do to
help our customers, your best bet in my opinion is contacting your
API provider and explore options they may offer now.
To be more explicit, there are several ways that a Geo IP provider might determine the location of an IP address. Most of these probably won't work well with a global cloud provider like GCP.
Associate the IP with the region of the allocating internet authority. In this case, GCE has addresses mostly allocated from ARIN, the American Internet authority. Once allocated to Google, these addresses can be used in any location by managing routing rules on Google's internal network.
Associate the IP with the address of the registering company. In that case, the official address associated with all GCP IPs is the Google Mountain View headquarters, even for addresses used in Europe or Asia.
Use network distance measurements to determine where a subnet is located. This method is more expensive, because it requires sending active pings from multiple locations around the globe; typically the address is associated with the closest measurement node. This is a more accurate method, but requires running many well-connected nodes and sending a lot of internet traffic to, at a minimum, each /24 on the internet.
All IP address from the Google Cloud will always originate to US, particularly Mountain View City, because it is linked to Google HQ which is located there. I would like you to know that all data and hardware for your instance are located on specific data centers across the globe, depending on the location that you have selected. You may refer to this link [1] for reference. However, Google Public DNS uses the anycast routing to direct the packets to the closest DNS server geographically, so if you are assigning an IP address for any instance, Google's network will be aware that the IP address is on that zone, even if the IP address was originally from Mountain View, California. See this link [2] [3] for a detailed explanation. The reason that you see your instance's IP address originate from US is because the entire IP block is owned by Google and the ARIN information lists the address for the entire block to Google's HQ in Mountain View.
[1] https://groups.google.com/forum/#!searchin/gce-discussion/ip$20in$20us%7Csort:relevance/gce-discussion/otD1c6E-wWI/cvEDCUAlBAAJ
[2] Why do Google Cloud Platform static IP addresses list Mountain View, CA in reverse lookup regardless of region assignment?
[3] https://groups.google.com/forum/#!searchin/gce-discussion/us$20ip%7Csort:relevance/gce-discussion/RjzyHRBRujg/Fd21YlmOpzEJ