April 12, 2017 | Gunanand Nagarkar
Our customer, a global financial services firm, had a robust IT infrastructure which managed sensitive data related to portfolio management for large institutional investors. To test the feasibility of Cloud for their infrastructure, they chose AWS and REAN Cloud, and started with The launching a specific analytics application. Their requirements specifically included responsiveness, local resources, rapid time-to-market, and a secure and compliant IT infrastructure for deploying their application/s.
The network flow diagram and other such architectural diagram where created after detailed analysis, and discussions. Some of those important AWS resource usage decisions along with their reasons are mentioned below. These became the governing factors for the overall architecture and the automation around it for them. The decisions made were from the perspective of a quick POC clearly knowing the impact of those decisions.
Usage of IAM Users and Groups
In this case the Financial Services firm Customer did not want to use wanted to IAM Users and Groups as this would add a layer of complexity to operations support for AWS. However, access to AWS resources can be assigned natively through the use of AWS IAM Users, which in turn can become members of IAM Groups. IAM Groups, like AD Groups, grant permissions to AWS components and services, such as, the ability to create or terminate EC2 instances, but leaving out the permissions to log on to those instances.
The customer set 99.9% as the SLA goal, and also set the requirement of data to remain in US-based regions. Leveraging a single region suffices, as the SLA provided by Amazon is 99.9% uptime. However, 99.99% uptime is achievable by moving to a multi-region design, which the customer understood and was sure about using it for future.
Multiple Availability Zone
In order to obtain the 99.9% SLA referenced above, the customer utilized more than one Availability Zone (AZ) for their production environment.
While Amazon has the offering of multiple VPCs under a single client account that can be linked by VPC-peering, customer had no need to implement such a configuration at that present time. In their case, VPC peering would add complications to networking and support strategies while not offering significant technical capabilities.
Direct Connect vs. VPN Connection to AWS
Initially, the customer chose to implement a VPN connection between their on-premise and VPC environments. Direct Connect, as an option, is a faster network and desirable for large offices and main data center facilities., VPN connections are not as fast but have little lead time for setup and desirable for satellite offices and new facilities.
Route 53 vs. BIND
Route 53 has AWS capabilities that BIND does not have, such as, the ability to map “zone apex” records directly to Elastic Load Balancers. Essentially, Route 53 has the capabilities of BIND plus more AWS specific capabilities, and also no functionality in support of the on premise systems are lost in migrating to Route 53. Transitioning to Route 53 was seamless and transparent to the customer’s systems and their end-customers. Hence a quick decision of going ahead with Route53.
These were a few decision points, among many, in the overall engagement. The flexibility of AWS resources allows one to use them in line with your business needs, and with the detailed infra, security, compliance knowledge that REAN Cloud Architect brings to the table, it makes decision making easy, while keeping in mind the future changes you may need to make. Thus making your infrastructure align to your present needs, and also future ready.
If you are on the cloud and business transformation journey and are looking for an assured success to migrate workloads in a secure and reliable manner, please reach out to us at email@example.com.