I followed this article to use Lambda and SNS to manage my Security Group for allowing traffic from CloudFront. After setting it up for multiple accounts, I noticed that the number of inbound rules in each account differs, with some having 50+ rules and others having 100+. However, the number of rules doesn't seem to correspond with the IP ranges.
I've already checked that the maximum number of rules per Security Group is 200 and that the Lambda function didn't timeout. Has anyone else encountered this issue, or is it normal to have varying numbers of inbound rules for the same Security Group across different accounts?
Looking at the code for the Lambda function, I would expect them to be the same for every account. I thought they might be different depending on the region, but that doesn't appear to be the case.
HOWEVER, you no longer need to do this! The blog post you are following is from 2020, and as of Feb 2022 Amazon manages this list for you. All you have to do is add the managed prefix list com.amazonaws.global.cloudfront.origin-facing in a single rule in your security group.
Related
I'm trying to enumerate all AWS regions available to me in Python.
AWS documentation suggests the following method for EC2:
ec2 = boto3.client('ec2')
# Retrieves all regions/endpoints that work with EC2
response = ec2.describe_regions()
print('Regions:', response['Regions'])
However running it results in an exception
botocore.exceptions.NoRegionError: You must specify a region.
When I am specifying a region to boto3.client request, I'm getting 11 regions out of 18 available.
Apart from the obvious mistake in AWS documentation, and apart from lack of logic of requiring to provide a region to get a full list of regions, how do I get around this?
The AWS docs are technically correct.
ec2.describe_regions() retrieves all regions that are 'available to you'.
In clearer terms, this means the response will only include regions that are enabled for your account & thus exclude any regions that are disabled within your account.
While not on the same page, the documentation for describe_regions explicitly states this:
Describes the Regions that are enabled for your account, or all Regions.
You most likely have 15 regions disabled within your account, which is why not all 26 regions (excluding 2 GovCloud regions) are being returned.
As you've discovered, setting the AllRegions parameter to True will return all regions regardless of their status within your account but please note that just because the API now returns them all, does not mean you can interact with them.
P.S. I agree that the AWS docs could be improved probably by rewording 'Retrieves all regions/endpoints that work with EC2' to 'Retrieves all enabled regions/endpoints within your account that work with EC2'. This is the source for the page you've linked - feel free to open a pull request suggesting an improvement.
Found it - all that is required is to add AllRegions=True to describe_regions():
response = ec2.describe_regions(AllRegions=True)
Is there a way to deny https://mma.mydomain.com/ main domain and allow the below Web sevices in GCP Cloud armor.
1. https://mma.mydomain.com/v1/teststudio/developer - POST
2. https://mma.mydomain.com/v1/teststudio/developer - GET
3. https://mma.mydomain.com/v1/teststudio/developer - PATCH
4. https://mma.mydomain.com/v1/teststudio/developer/app - POST
5. https://mma.mydomain.com/v1/teststudio/developer/app - GET
I have set the below rules in Google Cloud Armor Network Security services
deny request.path.matches('https://mma.mydomain.com/') Deny access from Internet to https://mma.mydomain.com 28
Allow request.path.matches('/v1/devstudio/developer') Allow access from Internet to /v1/teststudio/developer 31
Allow request.path.matches('/v1/devstudio/developer') Allow access from Internet to /v1/teststudio/developer/app 32
I am referring to https://cloud.google.com/armor/docs/rules-language-reference. Please guide with examples.
Thanks in Advance.
Best Regards,
Kaushal
Assuming your numbers to the right are the rule priorities, Cloud Armor will match the first rule and stop. In your case, it will match the hostname value and deny the request and never consider the other rules. Consider reversing the flow and have the more specific allow rules first and then fire the "default" hostname rule.
consider a rule like this:
request.headers['host'].matches('mma.mydomain.com') && request.path.lower().urlDecode().contains('/v1/devstudio/developer') && request.method == "GET"
And if you want to block other requests, have your request.path.matches('https://mma.mydomain.com/') rule fire after
Does AWS Internet Gateway Id always start with "igw-" or it may be different ?
Similarly I want to know about the Nat Gateway Id and VPC Endpoint Id.
Resource IDs will have a specific naming format for the ID, this will generally stay the same through the entire lifecycle of the product itself.
There are occasions where the format might change, an example of this is when EC2 instances had their suffix lengthened to increase availability. These kinds of changes are communicated months in advance with the choice of opting in early.
I am currently setting up an ALB which will contain 90 rules based on the path pattern.
Since the maximum rules supported by the ALB is 100 and regex expressions are not allowed in the path pattern expression, I need to find a workaround to lower the number of rules setted in the ALB.
My idea was to process the URL received in lambda before sending it to the ALB, which will potentially lower the rules on the ALB side.
Is this a good way to reduce the number of rules in ALB ? I am worried about the number of lambda parallel executions since it's limited to 1000, is there any other option with managed AWS services other than lambda to do this ?
Thanks !
You can do it, but it will affect your performance a lot. You can try to use CloudFront on top of ALB. Also, you can launch multiple ALB's and set them behind CloudFront
I wouldn't be concerned about the lambda executions. 1000 is actually a pretty big number, and it's a soft limit (you can request more). If you have a lambda that executes in 100ms you can run 10K request/second, and that's without bursting (you can exceed the limit for short bursts).
As for the number of rules in the ALB, you might want to consider using an API Gateway instead, if you have that many rules that are path based. As another answer pointed out, you can use CloudFront to increase the number of rules available by having more than one ALB, and sub-routing based on part of the path.
I understand the AWS Lambda is a serverless concept wherein a piece of code can be triggered on some event.
I want to understand how does the Lambda handle scaling?
For eg. if my Lambda function sits inside a VPC subnet as it wants to access VPC resources, and that the subnet has a CIDR of 192.168.1.0/24, which would result in 251 available IPs after subtracting the AWS reserved 5 IPs
Would that mean if my AWS Lambda function gets 252 invocations at the exact same time,Only 251 of the requests would be served and 1 would either timeout or will get executed once one of the 252 functions completes execution?
Does the Subnet size matter for the AWS Lambda scaling?
I am following this reference doc which mentions concurrent execution limits per region,
Can I assume that irrespective of whether an AWS Lambda function is No VPC or if it's inside a VPC subnet, it will scale as per mentioned limits in the doc?
Vladyslav's answer is still technically correct (Subnet size does matter), but things have changed significantly since it was written and subnet size is much less of a consideration. See aws' announcement:
Because the network interfaces are shared across execution environments, typically only a handful of network interfaces are required per function. Every unique security group:subnet combination across functions in your account requires a distinct network interface. If a combination is shared across multiple functions in your account, we reuse the same network interface across functions.
Your function scaling is no longer directly tied to the number of network interfaces and Hyperplane ENIs can scale to support large numbers of concurrent function executions
Yes, you are right. Subnet size definitely does matter, you have to be careful with your CIDR blocks. With that one last invocation (252nd), it depends on the way your lambda is invoked: synchronously (e.g. API Gateway) or asynchronously (e.g. SQS). If it is called synchronously, it'll be just throttled and your API will respond with 429 HTTP status, which stands for "too many requests". If it is asynchronous, it'll be throttled and will be retried within a six hour period window. More detailed description you can find on this page.
Also I recently published a post in my blog, which is related to your question. You may find it useful.