Limits for AWS Services

AWS has lot of services , as it is cloud base AWS Has various Limits imposed on aws account. Those limits are determined on various factors like region, account etc.

Various limits can be found at https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html

Amazon DynamoDB Limitation :-

1. There is no practical limit on a table’s size. Tables are unconstrained in terms of the number of items or the number of bytes.
   2. For any AWS account, there is an initial limit of 256 tables per AWS Region.
   3.You can define a maximum of 5 local secondary indexes.
   4. There is an initial limit of 20 global secondary indexes per table.
   5. The minimum length of a partition key value is 1 byte. The maximum length is 2048 bytes.
   6.The minimum length of a sort key value is 1 byte. The maximum length is 1024 bytes.
   7.The length of a Binary is constrained by the maximum item size of 400 KB.
   Applications that work with Binary attributes must encode the data in base64 format before sending it to DynamoDB. Upon receipt of the data, DynamoDB decodes it into an unsigned byte array and uses that as the length of the attribute.
   8. The maximum item size in DynamoDB is 400 KB, which includes both attribute name binary length (UTF-8 length) and attribute value lengths (again binary length). The attribute name counts towards the size limit.
   Do not allow more than two processes to read from the same DynamoDB Streams shard at the same time. Exceeding this limit can result in request throttling. you can have up to 50 CreateTable, UpdateTable, and DeleteTable requests running simultaneously.
   9.The result set from a Query is limited to 1 MB per call. You can use the LastEvaluatedKey from the query response to retrieve more results.
2. RDS Limits.

size of a table to a maximum size of 16 TB when using InnoDB file-per-table tablespaces.

Instance store

Instance Store Lifetime

You can specify instance store volumes for an instance only when you launch it. You can’t detach an instance store volume from one instance and attach it to a different instance.

The data in an instance store persists only during the lifetime of its associated instance. If an instance reboots (intentionally or unintentionally), data in the instance store persists. However, data in the instance store is lost under any of the following circumstances:

• The underlying disk drive fails
• The instance stops
• The instance terminates

S3 Limitation

After you have created a bucket, you can’t change its Region.

you can create up to 100 buckets in each of your AWS accounts. If you need additional buckets, you can increase your account bucket limit to a maximum of 1,000 buckets by submitting a service limit increase.

The following are the rules for naming S3 buckets in all AWS Regions:

• Bucket names must be unique across all existing bucket names in Amazon S3.
• Bucket names must comply with DNS naming conventions.
• Bucket names must be at least 3 and no more than 63 characters long.
• Bucket names must not contain uppercase characters or underscores.
• Bucket names must start with a lowercase letter or number.
• Bucket names must be a series of one or more labels. Adjacent labels are separated by a single period (.).
• Bucket names can contain lowercase letters, numbers, and hyphens. Each label must start and end with a lowercase letter or a number.
• Bucket names must not be formatted as an IP address (for example, 192.168.5.4).
• When you use virtual hosted–style buckets with Secure Sockets Layer (SSL), the SSL wildcard certificate only matches buckets that don’t contain periods. To work around this, use HTTP or write your own certificate verification logic. We recommend that you do not use periods (“.”) in bucket names when using virtual hosted–style buckets.

S3 buckets sit outside the VPC and can be accessed from anywhere in the world if bucket policies are not set to deny it.

CloudWatch

CloudWatch Gotchas and Limitations

• Metrics in CloudWatch originate on the hypervisor. The hypervisor doesn’t have access to OS information, so certain metrics (most notably memory utilization) are not available unless pushed to CloudWatch from inside the instance.
• You can not use more than one metric for an alarm.
• Notifications you receive from alarms will not have any contextual detail; they have only the specifics of the threshold, alarm state, and timing.
• By default, CloudWatch metric resolution is 1 minute. If you send multiple values of a metric within the same minute, they will be aggregated into minimum, maximum, average and total (sum) per minute.
• Data about metrics is kept in CloudWatch for 15 months, starting November 2016 (used to be 14 days). Minimum granularity increases after 15 days.

AMI

AMIs are per region, so you must look up AMIs in your region, or copy your AMIs between regions with the AMI Copy feature.

EBS Gotchas and Limitations

• EBS durability is reasonably good for a regular hardware drive (annual failure rate of between 0.1% — 0.2%). On the other hand, that is very poor if you don’t have backups! By contrast, S3 durability is extremely high. If you care about your data, back it up to S3 with snapshots.
• EBS has an SLA with 99.99% uptime. See notes on high availability below.
• EBS volumes have a volume type indicating the physical storage type. The types called “standard” (st1 or sc1) are actually old spinning-platter disks, which deliver only hundreds of IOPS — not what you want unless you’re really trying to cut costs. Modern SSD-based gp2 or io1 are typically the options you want.
• When restoring a snapshot to create an EBS volume, blocks are lazily read from S3 the first time they’re referenced.

EFS is designed to be used as a shared network drive and it can automatically scale up to petabytes of stored data and thousands of instances attached to it.

• EFS can offer higher throughput (multiple gigabytes per second) and better durability and availability than EBS , but with higher latency.
• EFS is priced based on the volume of data stored, and costs much more than EBS
• An EFS file system can be mounted on premises over Direct Connect.
• An EFS file system can NOT be mounted over VPC peering or VPN, even if the VPN is running on top of Direct Connect.
• Using an EFS volume on Windows is not supported.
• When a file is uploaded to EFS, it can take hours for EFS to update the details for billing and burst credit purposes.

CLB,ALB and NLB

CLBs support TCP and HTTP load balancing. ALBs support HTTP load balancing only. NLBs support TCP layer 4 load balancing.

CLBs don’t support complex / rule-based routing. ALBs support a (currently small) set of rule-based routing features. NLBs have most extensive routing options.

• CLBs can only forward traffic to a single globally configured port on destination instances, while ALBs can forward to ports that are configured on a per-instance basis, better supporting routing to services on shared clusters with dynamic port assignment (like ECS or Mesos). NLBs support multiple ports on same IP; registering targets by IP address, including targets outside the VPC for the load balancer; ECS can select unused port for scheduling a task then register a target group using this port.
• CLBs are supported in EC2 Classic as well as in VPCs while ALBs are supported in VPCs only.
• Client IPs: In general, if servers want to know true client IP addresses, load balancers must forward this information somehow. CLBs add the standard X-Forwarded-For header. When using a CLB as an HTTP load balancer, it’s possible to get the client’s IP address from this.

Load Balancer Gotchas and Limitations

• CLBs and ALBs have no fixed external IP .
• Some web clients or reverse proxies cache DNS lookups for a long time, which is problematic for CLBs and ALBs, since they change their IPs. This means after a few minutes, hours, or days, your client will stop working, unless you disable DNS caching.
• It’s not unheard of for IPs to be recycled between customers without a long cool-off period. So as a client, if you cache an IP and are not using SSL (to verify the server), you might get not just errors, but responses from completely different services or companies!
• As an operator of a service behind a CLB or ALB, the latter phenomenon means you can also see puzzling or erroneous requests by clients of other companies. This is most common with clients using back-end APIs (since web browsers typically cache for a limited period).
• CLBs and ALBs take time to scale up, it does not handle sudden spikes in traffic well. Therefore, if you anticipate a spike, you need to “pre-warm” the load balancer by gradually sending an increasing amount of traffic.
• Tune your healthchecks carefully — if you are too aggressive about deciding when to remove an instance and conservative about adding it back into the pool, the service that your load balancer is fronting may become inaccessible for seconds or minutes at a time.
• CLB HTTPS listeners don’t support Server Name Indication (SNI). If you need SNI, you can work around this limitation by either providing a certificate with Subject Alternative Names (SANs) or by using TCP listeners and terminating SSL at your backend.
• There is a limit on the number of ALBs, CLBs and NLBs per region (separately). As of late 2017, the default limit for each is 20 per region. These limits can be easily raised for ALB and CLB, but AWS is quite reluctant to raise the limit on NLBs.
• If using a Network Load Balancer (NLB) then EC2 clients cannot connect to an NLB that resides in another VPC (VPC Peering) or AWS managed VPN unless the EC2 client is a C5, i3.metal or M5 instance type.

ALB Gotchas and Limitations

• ALBs only support HTTP/2 over HTTPS (no plain-text HTTP/2).
• ALBs only support HTTP/2 to external clients and not to internal resources (instances/containers).
• ALBs support HTTP routing but not port-based TCP routing.
• Instances in the ALB’s target groups have to either have a single, fixed healthcheck port (“EC2 instance”-level healthcheck) or the healthcheck port for a target has to be the same as its application port (“Application instance”-level healthcheck) — you can’t configure a per-target healthcheck port that is different than the application port.
• ALBs are VPC-only (they are not available in EC2 Classic)

Elastic Beanstalk Gotchas and Limitations

• Don’t edit [apache|nginx] conf files manually on ec2 instances as they will be re-written on each deployment (use ebextensions instead)
• After creating an EB environment, it’s no longer possible to change the Name tag
• EB will sometimes quarantine instances that cause multiple deployment issues. Despite being quarantined, EB will still deploy to them on subsequent deployments. To prevent this behavior, said instances will need to be terminated (or the underlying issue fixed)
• File uploads are capped at 10MB for most default eb configurations
• If you edit .elasticbeanstalk/saved_configs/, be aware that this is not kept in sync with the EB environment config. You'll need to manually fetch and save for changes to take effect

RDS Gotchas and Limitations

• RDS instances run on EBS volumes (either general-purpose or provisioned IOPS), and hence are constrained by EBS performance.
• DB migration to RDS: While importing your database into RDS ensure you take into consideration the maintenance window settings. If a backup is running at the same time, your import can take a considerably longer time than you would have expected.
• Database sizes are limited to 6TB for all database engines except for SQL Server which has a 4TB limit and Aurora which supports up to 64TB databases.

API Gateway Gotchas and Limitations

• API Gateway only supports encrypted (https) endpoints, and does not support unencrypted HTTP. (This is probably a good thing.)
• API Gateway doesn’t support multi-region deployments for high availability. It is a service that is deployed in a single region but comes with a global endpoint that is served from AWS edge locations (similar to a CloudFront distribution). You cannot have multiple API Gateways with the same hostname in different AWS regions and use Route 53 to distribute the traffic.
• Many changes to API Gateway resources need to be ‘deployed’ via console or API call. Unfortunately, API Gateway is terrible about notifying the user when changes are staged for deployment and what changes require deployment. If you’ve changed something about your API and it’s not taking effect, there’s a decent chance you just need to deploy it.
• API Gateway does not support nested query parameters on method requests.
• API Gateway limits number of resources to 300, as described here. This is something to be considered when you start using API Gateway as a platform where your team/organization deploys to the same API Gateway.

VPC and Network Security Gotchas and Limitations

• VPCs are tied to one Region in one Account. Subnets are tied to one VPC and limited to one Availability Zone.
• Security groups are tied to one VPC. If you are utilizing infrastructure in multiple VPCs you should make sure your configuration/deployment tools take that into account.
• VPC Endpoints are currently only available for S3 and DynamoDB. If you have a security requirement to lockdown outbound traffic from your VPC you may want to use DNS filtering to control outbound traffic to other services.
• Be careful when choosing your VPC IP CIDR block: If you are going to need to make use of ClassicLink, make sure that your private IP range doesn’t overlap with that of EC2 Classic.
• New RDS instances require a subnet group within your VPC. If you’re using the default VPC this isn’t a concern, it will contain a subnet for each availability zone in your region. However, if you’re creating your own VPC and plan on using RDS, make sure you have at least two subnets within the VPC to act as the subnet group.
• Be careful with VPC VPN credentials! If lost or compromised, the VPN endpoint must be deleted and recreated.
• Security Groups and Route Tables apply entries separately for IPv4 and IPv6, so one must ensure they add entries for both protocols accordingly.