C) WAF has bot identification and remedial tools, so it's CORRECT. A) remember the question : "...block requests from unauthorized users?" -- an api key is involved in a authorization process. It's not the more secure process, but it's better than an totoally anonymous process. If you don't know the key, you can't authenticate. So the bots, at least the first days/weeks could not access the service (at the end they'll do, cos' the key will be spread informally). So it's CORRECT. B) Implement a logic in the Lambda to detect fraudulent ip's is almost impossible, cos' it's a dynamic and changing pattern that you cannot handle easily. D) creating a rol is not going to imply be more protected from unauth. request, because a rol is a "principal", it's not involved in the authorization process.

C) Everyone agrees on C B) Almost impossible cos how do you detect fraudulent IP address from a publicly accessible application D) It's a publicly accessible application, converting the API to a private one defeats the purpose E) IAM role for each user trying to access a publicly accessible API is impossible. It like creating an IAM for each user that tries to use google AUTH for their website A) By implementing API keys and usage plans, you can restrict access to your API to only those users who possess the key, helping to limit fraudulent access.

AC is right answer.

AC for sure

Do the people voting E realize how insane that is? Creating a local IAM user in your account for every user that needs to access the API. No just... no.

B. Integrate logic within the Lambda function to ignore the requests from fraudulent IP addresses. -> you can think about CORS script write on Lambda to prevent fraudulent IP addresses. C. Implement an AWS WAF rule to target malicious requests and trigger actions to filter them out. -> No comment here as it can use to filter traffic

C and D are the perfect answers

Don't use API keys for authentication or authorization to control access to your APIs. If you have multiple APIs in a usage plan, a user with a valid API key for one API in that usage plan can access all APIs in that usage plan. Instead, to control access to your API, use an IAM role, a Lambda authorizer, or an Amazon Cognito user pool.

I'll throw a curveball over here. "C" is a given as WAF rules can target malicious usage. For example: https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/aws-waf-ip-reputation.html "D" Convert existing public API to a private API. This part is same as A. The additional bit over here is to change the DNS record to a new API endpoint which blocks the requests from unauthorised users also. The unauthorised users will not be redirected from public to private API endpoint. I am assuming that the public API endpoint will be used for authorisation and only authorised users will be redirected to private endpoint. This is more robust as the actual API (private endpoint) never gets hit with requests from unauthorised bots and WAF redirects it back to public URL. Happy to be corrected and challenged

The combination of using an API key and implementing an AWS WAF rule provides the most comprehensive and effective way to block requests from unauthorized users and protect the company's serverless application from botnet attacks.

A. Create plans using API keys shared only with real users: While using API keys is a standard way to control access to APIs, using API keys alone may not completely prevent attacks from botnets. Malicious request. B. Incorporate logic in the Lambda function to ignore requests from fraudulent IP addresses: This may be a solution, but filtering that relies more on IP addresses may not be as flexible as using AWS WAF. D. Convert an existing public API to a private API. Update DNS records to redirect users to the new API endpoint: This approach makes the API private, but requires user redirects and may inconvenience existing users.

C) WAF has bot identification and remedial tools, so it's CORRECT. A) remember the question : "...block requests from unauthorized users?" -- an api key is involved in a authorization process. It's not the more secure process, but it's better than an totoally anonymous process. If you don't know the key, you can't authenticate. So the bots, at least the first days/weeks could not access the service (at the end they'll do, cos' the key will be spread informally). So it's CORRECT.

Agree A and C I don't see how E is feasible as its a public API. How would you create an IAM role for each user?

AWS WAF rule to target and filter out malicious requests and API key to authorize users.

The reasons are: An API key with a usage plan limits access to only authorized apps and users. This prevents general public access. WAF rules can identify and block malicious bot traffic through pattern matching and IP reputation lists. Together, the API key and WAF provide preventative and detective controls against unauthorized requests. The other options add complexity or are reactive. IAM roles per user is not feasible for a public API. Ignoring requests in Lambda and changing DNS are response actions after an attack.

AC it's essential to note that while API keys are commonly associated with private APIs, they can also be used in conjunction with public APIs. In some cases, even public APIs may require API keys to control usage and monitor how the API is being utilized. The API provider might enforce usage limits, track API usage, or monitor for potential misuse, all of which can be managed effectively using API keys. In summary, API keys are not exclusive to private APIs and can be used for both private and public APIs, depending on the specific requirements and use case of the API provider.

Why option C) vs option E) - It's simpler - We want to protect general access to the API and not granular method/user access. The API is already public so If a user API key is in several usage plans that is not a problem (The API is currently public). The objective is to protect API from abuse from malicious internet users and to NOT protect granular method/user access from users that are using the API in the correct way.