Amazon Useful Tips

sorce from

Nice to remember

  • If you have to SSH into your servers, then your automation has failed.

Application Development

  • Store no application state on your servers: for logs use syslog, for upload s3, not use filesystem, long process using sqs
  • Store extra information in your logs: add instance-id, region, availability-zone and environment (staging, production
  • If you need to interact with AWS, use the SDK for your langauge
  • Have tools to view application logs: use a syslog centralized and avoid to read logs using ssh
  • Disable SSH access to all servers: This is both the most frightening and yet most useful thing I've learned.
  • Servers are ephemeral, you don't care about them. You only care about the service as a whole: if a server die aws run another instance
  • Don't give servers static/elastic IPs: use balancing , and group security for access to resource
  • Automate everything: bash script, or Chef/Puppet,
  • Everyone gets an IAM account. Never login to the master: every person an account with last privileges. You can either enable multifactor authentication
  • Get your alerts to become notifications: If you've set everyting up correctly, your health checks should automatically destroy bad instances and spawn new ones as everything should be automated.


  • Set up granular billing alerts. You should always have at least one billing alert set up


  • Use EC2 roles, do not give applications an IAM account: If your application has AWS credentials baked into it, you're "doing it wrong". You should replace with AWS SDK for your language is that you can really easily use EC2 IAM roles
  • Assign permissions to groups, not users: you can also use an external active directory integrated with IAM
  • Set up automated security auditing: in this section there are some interesting operations that is possible to do.
  • Use CloudTrail to keep an audit log: track every action done in your s3 by api or web console,


  • Use "-" instead of "." in bucket names for SSL.
  • Avoid filesystem mounts (FUSE, etc). Use the SDK instead
  • You don't have to use CloudFront in front of S3 (but it can help). CloudFront can dramatically speed up access for users around the globe. the cost per request is slightly higher than if you were to access the files from S3 directly , this can also work out slightly cheaper if you deal with very high bandwidth (10TB+) with lower request numbers,
  • Use random strings at the start of your keys. So files with the same prefix might end up on the same hard disk for example


  • Use tags!
  • Use termination protection for non-auto-scaling instances. stop anyone from accidentally deleting the instance
  • Use a VPC. instead of ec2
  • Use reserved instances to save big $$$.
  • Lock down your security groups: if your instances are behind an ELB, you should set your security groups to only allow traffic from the ELBs, rather than from You can do that by entering "amazon-elb/amazon-elb-sg" as the CIDR (it should auto-complete for you). If you need to allow some of your other instances access to certain ports, don't use their IP, but specify their security group identifier instead (just start typing "sg-" and it should auto-complete for you).
  • Don't keep unassociated Elastic IPs.


  • Terminate SSL on the load balancer. his will take the overhead of SSL termination away from your servers which can speed things up
  • Pre-warm your ELBs if you're expecting heavy traffic: It takes time for your ELB to scale up capacity, AWS suggest you contact them instead to prewarm your load balancer.


  • Use the configuration endpoints, instead of individual node endpoints. This point is not so clear


  • Set up event subscriptions for failover.


  • It can become extremely tedious to create alarms using the web console
  • Use the free metrics. you get up to 2 weeks of historical data
  • Use custom metrics. If you want to monitor things not covered by the free metrics, you can send your own metric information to CloudWatch
  • Use detailed monitoring. It's ~$3.50 per instance/month, and well worth the extra cost for the extra detail. 1 minute granularity is much better than 5 minute


  • Scale down on INSUFFICIENT_DATA as well as ALARM. If there's no traffic, you'll get INSUFFIFIENT_DATA instead of ALARM for your low traffic threshold and it won't trigger a scale-down action
  • Use ELB health check instead of EC2 health checks.
  • Only use the availability zones (AZs) your ELB is configured for.
  • Don't use multiple scaling triggers on the same group.


  • Use IAM roles. Don't create users for application, always use IAM roles if you can.
  • Users can have multiple API keys.
  • IAM users can have multi-factor authentication, use it!


Use ALIAS records.

Miscellaneous Tips

  • Scale horizontally. I've found that using lots of smaller machines is generally more reliable than using a smaller number of larger machines.
  • Your application may require changes to work on AWS.
  • Always be redundant across availability zones (AZs).
  • Be aware of AWS service limits before you deploy.
  • Decide on a naming convention early, and stick to it. There's a lot of resources on AWS where you can change the name later, but there's equally a lot where you cannot (security group names, etc).
  • Decide on a key-management strategy from the start. It's easy to modify your authorized-keys file with a bootstrap script of course
  • Make sure AWS is right for your workload. One of the big benefits of AWS is the ability to scale up and down rapidly in response to load, but not everyone needs that feature
Salvo diversa indicazione, il contenuto di questa pagina è sotto licenza Creative Commons Attribution-ShareAlike 3.0 License