Confirming understanding on AWS ASG

Pho3nix

Pho3nix

The Legend
Joined
Jul 31, 2009
Messages
32,875
Reaction score
3,054
Location
On the toilet
Hi guys,

So have an application that can't go down running on EC2 with MSSQL. 2x EBS volumes, 1 with the data for MSSQL and another for the web app. So twice a day it does some batch jobs and works fine, the issue is it costs $200 a month (unless a manual run), and floats the rest of the day for regular traffic. Want to use an Auto-Scaling group to vertically scale because I am assuming horizontal won't work because of the EBS volume/MSSQL situation.

I've already created the AMI assuming it will stop and start the instance but I am worried about keeping the same IP (I'm thinking ENI) and checking that the app and DB are up before the batch job starts moving data. Thoughts?

Took this work over from a friend so not part of my day-to-day for the moment.

TL;DR : Trying to keep costs down by scaling when needed.
 
Pho3nix said:
Hi guys,

So have an application that can't go down running on EC2 with MSSQL. 2x EBS volumes, 1 with the data for MSSQL and another for the web app. So twice a day it does some batch jobs and works fine, the issue is it costs $200 a month (unless a manual run), and floats the rest of the day for regular traffic. Want to use an Auto-Scaling group to vertically scale because I am assuming horizontal won't work because of the EBS volume/MSSQL situation.

I've already created the AMI assuming it will stop and start the instance but I am worried about keeping the same IP (I'm thinking ENI) and checking that the app and DB are up before the batch job starts moving data. Thoughts?

Took this work over from a friend so not part of my day-to-day for the moment.

TL;DR : Trying to keep costs down by scaling when needed.
Click to expand...
The requirement is not very clear, as always..

Why dont you rather trigger the batch on fargate or the like via an event rule? I assume this is compute intensive task and not a DB heavy task? I dont mean to be rude but this is a on-prem mentality when there are many other cloud native services fit for purpose.

Also separate your DB and app.
 
s0lar said:
The requirement is not very clear, as always..

Why dont you rather trigger the batch on fargate or the like via an event rule? I assume this is compute intensive task and not a DB heavy task? I dont mean to be rude but this is a on-prem mentality when there are many other cloud native services fit for purpose.

Also separate your DB and app.
Click to expand...

DB heavy task. I’m trying get them to save money so I can get paid to fix and separate some of these other issues.

Ideally trying not to add additional services to again decrease cost.

What in the requirement isn’t clear?
 
Pho3nix said:
DB heavy task. I’m trying get them to save money so I can get paid to fix and separate some of these other issues.

Ideally trying not to add additional services to again decrease cost.

What in the requirement isn’t clear?
Click to expand...
Wouldn't it be better to use one of the aws provided DB services?
 
Sinbad said:
Wouldn't it be better to use one of the aws provided DB services?
Click to expand...

RDS still pricier because of the perks. Again this landed on my lap and trying to deal with low hanging fruit like cost saving first.
Splitting app to Fargate and other improvements will be a phase 2 and onwards
 
Pho3nix said:
DB heavy task. I’m trying get them to save money so I can get paid to fix and separate some of these other issues.

Ideally trying not to add additional services to again decrease cost.

What in the requirement isn’t clear?
Click to expand...
Then you are going to have a complex solution as you cannot easily scale a DB vertically and most definately not with an ASG. Even if you managed to glue this together with rules and lambda's, you would still get DB downtime during the scale up and down.

Im going to assume this is for analytics or ETL (I am doing a lot of assuming here..), If so I would replicate the tables to s3 and bring up a batch instance of glue with spark transform/ETL the data then push that to a new table or partition in the old small DB.

Or simplest look at horizontal scaling, I don't have much experience in MSSQL but plenty in other enterprise DB's I am pretty sure you can bring up a read replica and it will replicate from scratch. Being a microsoft product I assume there is going to a license hit for a replica instance.

ps. I wouldn't touch this, your pinch pennies they go down. You are responsible. Good luck.
 
s0lar said:
Then you are going to have a complex solution as you cannot easily scale a DB vertically and most definately not with an ASG. Even if you managed to glue this together with rules and lambda's, you would still get DB downtime during the scale up and down.

Im going to assume this is for analytics or ETL (I am doing a lot of assuming here..), If so I would replicate the tables to s3 and bring up a batch instance of glue with spark transform/ETL the data then push that to a new table or partition in the old small DB.

Or simplest look at horizontal scaling, I don't have much experience in MSSQL but plenty in other enterprise DB's I am pretty sure you can bring up a read replica and it will replicate from scratch. Being a microsoft product I assume there is going to a license hit for a replica instance.

ps. I wouldn't touch this, your pinch pennies they go down. You are responsible. Good luck.
Click to expand...

Other way around pulling data into this DB but you’re right it’s a headache and why my friend doesn’t want anything to do with this anymore.

Dankie
 
Is the scaling requirement predictable? Time of day or whatever?
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X