AWS tips

Below are the few AWS tips that I came across while doing my development.

if there are any other specific areas folks are interested in hearing about, feel free to mention that in the replies

#AWSTips

• AWS changes — daily. there are little changes (eg. service X available in region Y, service Z support feature A, service B bumps C limit), there are big changes (eg. AWS launches new region D, AWS launches new service E, AWS fixes cold-starts for lambda), some good resources to follow for AWS updates:
• AWS news blog: https://aws.amazon.com/blogs/aws/
• AWS what’s new: https://aws.amazon.com/about-aws/whats-new/recent/ … #Updates
• No trails like cloud trail. one of my favorite services for compliance as it logs all AWS account activity and delivers them to s3. Use it with KMS to get fine-grained CRUD details (eg. IAM principle A modified record B in service C) every time a resource is accessed. you can also use it in conjunction with cloud watch events to take an action on suspicious events (eg. X permission denied on resource D) .even if you don’t need to satisfy compliance requirements, cloud trail gives you a changelog of everything that happened in your account. this is useful for debugging as well as re-creating console actions via cloud formation.best of all, your first trail in each is free so there’s no reason not to turn it on #Security
• Auto-scaling groups (ASG) is not just for groups. it's worthwhile to an ASG for a single ec2. ASG's can detect if the instance is unhealthy and replace it. it can also shift instances away from AZ’s that are having issues. Another often overlooked feature of ASG is its ability to use multiple instance types. you can launch an ASG with a combination of on-demand, reserved, and spot instances. pick and choose the ratio of each to come up with the optimal availability/price ratio for your use case #Availability
• watch out for zombies. some AWS services will create resources that are left behind after deletion (eg. the default cloud watch log group created by lambda via console is set to never expire and will persist after the lambda has been deleted).other common zombies: EBS volumes, EBS snapshots, rds snapshots, elastic IPs, security groups, and s3 buckets. #Cost
• The cloud = infinite scale until it doesn’t. AWS services have limits. there are soft limits which you can update by cutting a ticket (eg. num read replicas for rds). then there are hard limits which are fixed (eg. 200 nodes per elastic search cluster).its important to know the limits for your key services and setup alarms to notify you when you need to cut a ticket. you can use the aws service quotas service to help keep track of both #Scaling
• Watch out for service availability. Not all services are available in all regions (eg. eks not in northern California). Virginia will be your best bet for full coverage. consult the aws infra page for other regions: https://aws.amazon.com/.../glo.../regional-product-services/ this is especially important if you’re thinking of going multi-region. make sure all your dependencies are available in EVERY region TODAY. lead time for a service launching in a region can vary (api gateway wasn’t available in north. California until 500 days after launch. ) #Availability
• Automate service provisioning using infrastructure as code (IaC). #Devops
• Naming things is still hard. if you use AWS CDK to provision your infra, avoid hardcoding names. any resources that require a replacement will fail and will cause the stack to be in a bad state until that resource is deleted. #Devops
• Did you cache that? the fastest packet is the one not sent. use cloud front to cache at the edge or elastic cache to cache expensive data queries inside your network. some services also come with cache integration (eg. API gateway, dynamo DAX, etc). #Scaling
• You might not need that API (gateway). if you’re using lambda as an API server, consider using alb if you don’t need advanced gateway functions (eg. rate-limiting, API keygen, authentication/authorization, etc) .gateway charges $3.5/million request which can get prohibitively expensive for high volume workloads (eg IoT). if you are using lambda on the backend, consider just invoking it directly which will save you an additional hop and any associated network costs #Serverless