Using Amazon Web Services

I am writing a series of posts related to different aspects of Amazon Web Services (AWS) as I increasingly use AWS for new projects. Different projects will need different levels of scalability so different services make sense. In particular the use of geo location to retrive access to the dynamic elements of a website from the nearest datacenter is not important for a local business. While load time is important for most websites and the use a content deliver network (CDN) to host static files such as images near the user of the site the additional effort of a couple of hours may not even be justified for a site with minimal content and little use of the site.

Some serious complexity arrises for sites which have authentication in the form of a login and which need to operate across multiple regions but this in many cases can be handled in a less than perfect manner to reduce the complexity and cost of the implementation. The final stages of segmenting data from different users so as to reduce the volume of data being synchronized across databases is necessary only in situations where the frequently required user related data is greater than 5 GB causing data not to be cacheable in memory. Once over 100GB of database data is needed by the system as a whole it may also be necessary to segment data over multiple databases in order to improve the manageability of the databases.

The series of posts will include:

• Use of online storage (S3)
• Relational Databases (RDS)
• Authentication
• Database Synchronization
• Geo Location by DNS
• Geo Location with Edge Servers
• Data Segmentation with Edge Servers
• Workflow management with SQS

There will also be some pre-requisites such as the installation and configuration of tool sets which also warrant separate posts.