asked on
AWS Architecture Design
Hi
I have a 3 sets of two on-premise servers: application server and oracle database
Each set represent different environment: DEV, TEST and PROD
I am trying to decide the best environment for AWS migration
1. Create three AWS accounts: one account for each environment for complete separation
2. Create one AWS account, but 2 VPCs: PROD VPC and Non-PROD VPC
3. Create one AWS account, but 3 VPCs: PROD, TEST and DEV
4. Create one AWS account, one VPC, 3 subnet groups in same Availability zone (one for each environment)
5. Create one AWS account, one VPC, 3 subnet groups in different availability zones.
You are correct with respect that the likelihood of a region going down is rear, but we can’t guarantee that a natural event could destroy data center. You can use Ohio and Virginia regions that are on the east coast. The article I was trying to link is called
Establishing your best practice AWS environment
for some reason I can’t paste the right link, so just google that name and you should get the correct link.
In our case we have our dev and test in regions close to our developers and for production we have it on the opposite side of the country.
ASKER
Did you mean this document?
https://aws.amazon.com/organizations/getting-started/best-practices/
For your initial proposal of creating 3 AWS accounts, would you also use that if we want to deploy VMC service (VMware cloud)? That will probably be kind of expensive I would think to setup 3 VMware ESXi servers instead of one because VMC usually has minimum number of hosts and CPUs and RAM and Storage that might exceed what is needed for DEV/TEST.
for the on-premise environments, dont they usually setup one two physical boxes with one VMware ESXI server on each and then create multiple hosts under each. I have actually worked in on-premise environments where DEV and PROD servers are in same location and data center.
yes that's the url I was trying to paste, and like @Mlanda T said it would be best to use the AWS Organizations approach. For the second, part of your question I'm assuming you are running your workload on VMware. So, are you planning on also running the workloads on VMware but in AWS ? Are the workloads dependent on being ran on VMware, or can you run them straight on aws EC2. With regards to the VMware on AWS I'm not sure how the pricing works when it comes to vmware and aws. Looks like you might be able to get a discount if you run VMware on AWS https://www.vmware.com/products/vmc-on-aws.html#pricing . VMware is beyond my expertise, so don't want to give you wrong information, so I would just say to think about the workloads you have and if they can just be ran on AWS EC2 instance.
You can still have the dev and prod in the same environment, but by having the 3 different account and using AWS Organization approach you can still isolate the environments from one another. You will be able to control access better and isolate your production environment.
ASKER
Yes, the plan is to move the VMs from VMware on-premise to VMC on cloud. It takes a few hours and much easier than EC2 setup which can take weeks as you have to reinstall and configure machine unless there is a way to build an AMI from source VM and use that to replicate an EC2 VM on the cloud or use server migration service.
Do you have a link or sample AWS diagram that shows how the three environments are setup using three accounts and how each has its own region, VPC, AZ, subnets, etc?
There are very robust migration tools already which can help you to migrate your instances from on-premises to the cloud. Depending on the communication pathways and interdependencies between your VMWare VMs, you can actually plan a phased migration, where you migrate some workloads to the cloud, check that everything is running smoothly, and migrate the next workload and so on.
There are several migration services you could use on AWS. One is the VMware Cloud on AWS (https://aws.amazon.com/vmware/?c=mt&sec=srv). This will help you automate a lot of your planned migration.
Do you have a link or sample AWS diagram that shows how the three environments are setup using three accounts and how each has its own region, VPC, AZ, subnets, etc?
However, please note that AWS provides a default implementation of the AWS Control Tower best practices. AWS Landing Zone is a solution that can help you quickly set up a secure, multi-account AWS environment based on AWS best practices. This solution can help save time by automating the set-up of an environment for running secure and scalable workloads while implementing an initial security baseline through the creation of core accounts and resources.
The setup of resources within each account follows rudimentary processes on AWS. IMHO the key thing to understand about this is to understand how the security is managed centrally. By assuming and using different IAM Roles and permissions, you can quickly change from one account to the next. A full discussion of this might not be suitable here, but I strongly recommend the Digital Cloud Training videos and hands-on labs for this: https://youtu.be/3-aaw-B1j8Y . Typically, you would implement the Production and Development accounts as OU in your AWS Organisations, and create corresponding accounts for them - this is the walkthrough given by Digital Cloud Training.
(https://www.sufle.io/blog/multi-account-environments-with-aws-control-tower)
https://www.slideshare.net/AmazonWebServices/wrangling-multiple-aws-accounts-with-aws-organizations
ASKER
That is a nice high level chart showing how AWS organizations manage 3 environment accounts.
However, for details, let us say the design is similar to what is shown below, would the Region, VPC, Subnets, AZ be listed under "AWS Resources" in the diagram?
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-concept.workflow.html
https://aws.amazon.com/quickstart/architecture/oracle-database/
https://aws-quickstart.github.io/quickstart-oracle-database/
ASKER
Personally, I dont think DEV/TEST and PROD should be in different regions but PROD and DR maybe be good in case one region goes out.
I think the idea of using 3 AWS accounts for each environment is good to separate resources and better security even though I think you an have multiple IAM users under one AWS account with different roles/Privs so you can have DEV/TEST role and PROD role. The idea is more costly too when using VMware on the cloud because I can subscribe to one VMC and just build different hosts: one for DEV and one for PROD.
Have you seen a sample diagram that shows 3 environments and where app server/ DB server placed in each?
Personally, I dont think DEV/TEST and PROD should be in different regions but PROD and DR maybe be good in case one region goes out.
That's fine. So long as you are aware of, and accept the potential risks of a region going out. Remember that in most cases, even within regions, you still have availability zones (which typically translate to geographically separate facilities within the same region). That already gives you some resilience towards outages.
I think you an have multiple IAM users under one AWS account with different roles/Privs so you can have DEV/TEST role and PROD role.
Roles can achieve what you get by implementing AWS Organizations with Control Tower + Landing Zones and different accounts. However, as your number of AWS accounts grows and the number of resources grows, you will find that the AWS Organizations approach is more capable. For example, using IAM roles, you cannot easily have separate billing per team/workload/business unit/etc - if say, you wanted DEV teams to pay for their own resources out of their own budget. You can use Tags, fine... but, in the long term, AWS Organisations would be the better approach as your environment grows. It gives you a more flexible and less administratively demanding foundation. It's not just about user/group permissions (which is what you get with roles) - it's also about AWS features. So at the end of the day, you can still decide which approach to use. I just hope the discussion here has informed you on what the options are. We cannot ultimately decide for you.
Have you seen a sample diagram that shows 3 environments and where app server/ DB server placed in each?
Most times, you won't see too many concepts packed into a single diagram. It only adds complexity and one witll end up trying to mix otherwise separate concepts into one diagram - confusing. I would approach this as multiple diagrams.
You will also find that diagrams are going to approach things from different perspectives, depending on what we are talking about. Here is a CI/CD Framework in a multi-account setup.
https://www.latentview.com/data-engineering-lp/aws-practical-devops/
ASKER
Another article showing separation a account and VPC level
https://www.split.io/blog/setup-success-aws/
ASKER
Is not that more costly and complex though with 3 different accounts?
If you are in the East Coast why do you have to select different regions and availability zones in west coast? is this in case a region or AZ went down, you can use the other environment. My understanding is that this is extremely rare for a region to go down.
Also, if DEV and TEST are in distant regions far away from developers there will be a LATENcY and network performance issues compared to have it close to developers in east coast for example.