How I can reset the quota if API access limited?
Suppose we have API subscribe for 1200 request count for three month plan now quota is exceed and we are looking for increase quota for same API and Plan so how to do that without creating new application, or subscription plan in WSO2 APIM
You can reset a subscription policy via WSO2 APIM's Admin Portal.
Go to Subscription Policies under Rate Limiting Policies menu.
Click on the edit button in front of the custom subscription policy that you have created.
Modify the quota limits as you wish.
Click on save button.
Now you can access the API with the new changes.
Note that you can observe the following log in carbon logs if the policy is deployed correctly:
INFO - EventProcessorDeployer Execution plan is deployed successfully and in active state : <policy_name>
AFAIK you can't extend or reset a throttle decision in the gateway. When an API is throttled out, the Traffic manager sends an event to the gateway with the throttle decision for the throttle key and when this decision will expire. A sample event is mentioned below.
{"event":{"payloadData"{"throttleKey":"1:/pizzashack/1.0.0:1.0.0:5for5mins","isThrottled":true,"expiryTimeStamp":1674491400000}}}
Gateway will update it's throttle data holder with this information.
When gateway receives request from the same application, it will check this data holder, see whether expiry time stamp is exceeded, and throttle out.
This data holder entry will persists in memory until you restart the gateway or expiry time exceeds. Therefore even if you update the throttling tier, if the API is already throttled, you can't reset or extend the quota.
Only option would be upgrading the subscription tier to a higher one. Thottle decision is based on the policy and a different policy will act as an extension.
Related
I have created an alert policy in google cloud platform. I am getting the emails notifications based on the alert policy.
Now I want to configure an external custom monitoring system for this alert. I want to know the REST APIs that this monitoring system can call at after every 10-20 sec and get the status of this alert.
Please help
If you want to use only Cloud Monitoring, and Alerting Policy you won't achieve this.
It is not possible to configure alert policies to notify (repeatedly) while the policy's conditions are met. Alert policies that are created through Google Cloud Console send a notification only when the condition is met. You can also receive a notification when the condition stops being met.
Additional information can be found in Notifications per incident documentation.
In Cloud Monitoring API v3 - Alerting policies, you can find information that only the creation of the incident is sent.
An alerting policy is a configuration resource that describes the criteria for generating incidents and how to notify you when those incidents are created.
In general, if you want to use Notification Channels to send notifications outside you can use Webhooks or PubSub.
Note
Webhooks only support public endpoints. If you need notifications sent to an endpoint that isn't public, then create a Pub/Sub notification channel and configure a subscription to the Pub/Sub topic. For more information, see Webhook notifications fail when configured for a private endpoint.
As you didn't provide more information it's hard to say if you are not using some built-in features in 3rd party software to integrate with GCP Cloud Monitoring. One of the example is Grafana:
Grafana ships with built-in support for Google Cloud Monitoring. Add it as a data source to build dashboards for your Google Cloud Monitoring metrics.
GCP also might use Prometheus features. Maybe this might give you something similar to what you want.
Prometheus is a monitoring tool often used with Kubernetes. If you configure Cloud Operations for GKE and include Prometheus support, then the metrics that are generated by services using the Prometheus exposition format can be exported from the cluster and made visible as external metrics in Cloud Monitoring.
There are some workarounds, however they won't fulfill what you want.
It is possible to create multiple conditions that identify the same issue. Every time a condition is met, a notification will be received.
It is possible to get users notified when a condition is NOT met, however this might cause spam messages.
The last thing I want to mention is that there is already a Feature Request to add multiple notifications until the condition is gone. More details in FR: Repeat Notifications until condition is gone.
Additional Documentation:
Monitoring Alerts in GCP by integrating Cloud Operations with Notification Channels
Conclusion
Alert policies that are created through Google Cloud Console send a notification only when the condition is met. You can also enable notification to get solved notification.
There is Feature Request to add repeatedly notifications - here
To send notifications to other apps/resources you can use Webhooks or PubSub.
We are currently developing a cloud solution that would require 2000+ clients to publish events (1-2 per second) into an Event Hub. We built a prototype that gives each client a Shared access policy (Authorization Rule), and creates a SAS token with a publisher policy as defined here
We thus are able to identify the publisher of each event by inspecting the x-opt-publisher system property, and to revoke access to the Event Hub for each client at any time, without having to resort to token expiry and renewal.
However, we recently learned that the maximum amount of SAPs / Authorization rules is 12, so this solution ultimately will not work.
Is there another solution to this problem? Our goals are:
Avoid having to use token refresh, as this would require adding code to all clients.
Being able to revoke access to the Event Hub instantly in case a client either gets compromised, misbehaves, malfunctions due to a bug, or the associated customer's contract is terminated
Avoid having to use a frontend service authenticating the clients, as we are talking about a substantial additional system load (5000 requests per second)
Avoid having to use IoT hub, as the costs are far higher than with our solution, and we do not need all that functionality
Thanks in advance
You don't need to create a dedicated SAS policy for each device or publisher. Please note that a publisher should only own a token signed for itself and should not be able to access the SAS policy key.
Feel free to check the publisher policy document here for more details.
I'm building a serverless application with AWS Lambda and API Gateway. In order to prevent DDOS attacks doing a large number of requests costing me lots of money, I've set up a usage plan with a request quota (e.g. 10K requests/month). This requires an API key to be passed as header by callers.
This seemingly works well, but I also need to enable CORS for this service. For that I need to allow for an unauthorized OPTIONS request ("CORS preflight" request) as browsers don't support sending any special header there. But then I can't seem to find a way for enforcing a quota and I'm back to square one: an uncontrolled number of those requests could cost an unforeseeable amount of money. Is there any way to exclude this possibility?
To enforce a quota on OPTIONS requests, create a web ACL in AWS WAF & associate it to a stage of your API in API Gateway. Add a rate-based rule in the web ACL that blocks all OPTIONS requests beyond the rate limit you specify. Rules in web ACLs can be configured specifically for this, as shown below:
For a screenshot-guided tutorial of this entire process, see my blog post.
You are not paying for any unauthorized calls to API-Gateway.
AWS is picking up this charge.
You are paying after the request is authorized and only if it does not exceed your usage plan.
So if somebody is doing a DDOS on your API without authentication it is free of charge.
If somebody is doing a DDOS with a valid api key you will only pay until your usage plan is exceeded.
Find more information here.
Requests are not charged for authorization and authentication
failures.
Calls to methods that require API keys are not charged when API keys
are missing or invalid.
API Gateway-throttled requests are not charged when the request rate
or burst rate exceeds the preconfigured limits.
Usage plan-throttled requests are not charged when rate limits or
quota exceed the preconfigured limits.
So make sure to have authentication enabled on your API and a usage plan in place for all the authenticated requests.
I'm using AWS API Gateway with quota and need increase the number of requests made to api only if my backend return response with status code 200. So, responses with status different of 200 not are accounted for quota usage.
It's possible? If not, how i could make this?
Thanks
Recently i faced the same question, my solution is a little workaround.
You create two apis with aws api gateway and also two usage plans. The first api should be the api used by your customer, the second api exists only to increase the quota usage value for an API Key, so it should be a simple POST Endpoint. Now create one free usage plan (only throttling) and one usage plan with quota limitation enabled. Then connect the free plan to your api which is responsible for processing the data and connect the quota plan to the additional quota api.
Finally create an API Key for your customer, add both usage plans. Now you only need to call your quota api with the API Key provided by your customers, when their requests were successfully.
Hope this will work for you aswell.
I have published an API with tier availability as bronze.
When I subscribe to that API as a different user in the store, bronze will be the only available tier to subscribe.After subscription, when I try accessing the API, I am able to hit it many times in a minute without any restriction. Why does it not restrict me for 1 request per minute?
Thanks
Are you using your local install of WSO2 API Manager or API Cloud service? In API Cloud, the tiers are all presetup and work flawlessly as far as I can tell.
For your local API Manager set up the couple things I would look at are:
Check whether the APIs that you set up require authorization - if you set them up as public without authorization key requirement - then I think there is no tier enforcement either because your tier cannot be verified without authorization.
Check your ties.xml to ensure that the throttling level for the tier is properly set up: https://docs.wso2.com/display/AM170/Managing+Throttling+Tiers