Although the infrastructure maintenance via Cloud is flexible, the transition from physical server components to Cloud involves a lot of hurdles which makes “Get it done right now” difficult. The world already knows that this platform is awesome, so let’s get dirty with some of the tips useful to beginners using AWS.

Multi-Factor Authentication

MFA can be token-based or text message-based which adds on to another layer of security. Use MFA wherever possible for users. But make it a point to standardize MFA for all Master accounts. MFA can be also used to control access to AWS service APIs.  There are several MFA form factors that are compatible with root account and IAM user accounts such as virtual and hardware MFA devices.

Currently, the most popular virtual MFA application is Google Authenticator for Android and iPhone that enables hassle-free yet secure Multifactor authentication. In the case of Hardware Tokens, tamper-evident third-party tokens are also available.

Assign Permission to Groups Not Users

AWS Directory service provides three directory types including Microsoft Active Directory (AD) Enterprise Edition, Simple AD and AD Connector. If you’re using AD Connector, it is designed to allow you to sign in to AWS Applications and join Windows Instances besides mapping AD identities to AWS roles. It is only logical that in terms of access management, to create a group and configure permissions to that group which applies to a set of the user instead of managing permissions to individuals that complicates Identity and Access Management (IAM) in terms of adding or removing roles for several hundred users individually, instead of collectively.

AWS SDK

Even if minimal scaling is required, you could still use AWS despite the higher cost for EC2 because the broad ecosystem of AWS products makes it easier to develop interesting things quickly and efficiently.

If we went with all of our own dedicated hardware, or cheaper instances from a different cloud provider then we’d miss out on ELB, have slower and more expensive communication to and from S3, not to mention that services like Elastic Beanstalk make deploying to EC2 instances very easy compared with rolling your own deployment system. And for those who don’t want to bother with administrating databases and cache machines, RDS and Elasticache are going to be cheapest and fastest if your instances are EC2. So even though EC2 is expensive, the benefits of living fully within the Amazon ecosystem are pretty large.

This is a major reason why if you want to interact with AWS, you better use AWS SDK. The AWS SDKs are well written, handle authentication automatically, handle retry logic, and they’re maintained and iterated on by Amazon. Also, if you use EC2 IAM roles then the SDK will automatically grab the correct credentials for you.

Store Extra Information in Logs

Logs basically store configured parameters in addition to exceptions and timestamps. The reason why Logs are referred to is to help with debugging considerably. You can grab information such as instance-id, region, availability-zone, and staging or prod – environment from instance metadata service which you can also grab from bootstrap scripts. Just make sure that the updates are concurrent every time the instances reboot to avoid repeated data persistence.

No Elastic IPs

The best thing about elastic IPs is that you can always assign one to your account and associate with the instance that you are trying to enable communication with the internet. It’s an optimal solution for instances but when it comes to servers do not give them elastic IPs. The reason is auto-scaling, as we put things behind elastic load balancers which automatically distributes incoming application traffic across multiple instances. There are a few cases where Elastic IPs will probably need to be used, but in order to make the best use of auto-scaling, you’ll want to use a load balancer instead of giving every instance their own unique IP. Also always make sure to associate your elastic IPs to an instance because if you don’t, you still get charged for it.

Cloud trail

So here’s the thing, when you create a bucket in Simple Storage solution (S3), Amazon doesn’t charge you for the bucket, but it charges when you store objects in those buckets. So whenever you perform any action via APIs into the S3 bucket, you need to keep track of the changes you make and potentially track changes made by others. In order to keep track of the version, you need a perfect log which is where Cloudtrail comes into play. Use Cloudtrail to keep an audit log of the version, changes, and history of actions in the bucket.

Granular Billing Alerts

So the best part about using AWS is it provides free service for the first one year and then pay as you go, per usage limit. Set up your allowance limit and set up an alert that notifies you when you exceed it on a weekly or monthly basis. If drill down further, you can set up an alert for every individual service that you use so you get a good look at how much each of the services consumes. This will eventually help you assess the ones you probably want to cut down to linger in the limit that you’d set up. The finer-grained your strategy is, the more granular your alerts can help you.

Bucket names

Security Socket Layer (SSL) certificate mismatch error is more common and installing all intermediates may not always solve your problem. If you ever want to use your bucket over SSL, using a “.” will cause you to get certificate mismatch errors. You can’t change bucket names once you’ve created them, so you’d have to copy everything to a new bucket. So you can use “-” instead to avoid certificate mismatch errors.

So here’s the infographic on some of the useful tips that we compiled from the above list.