When estimating the monthly cost of a per hour service, over the course of a year, you need to know how many hours in a month. For some reason a simple “average hours in a month” Google Search yields unhelpful results.
730.5 AVERAGE HOURS IN A MONTH
There are 365.25 Julian calendar days per year (366 days in a leap year), 24 hours in a day and 12 months.
365.25 days X 24 hours / 12 months = 730.5 hours
So now you can estimate monthly cost for hourly services, such as Cloud Services.
example: $.10/hr * 730.5 = $73.05 average cost per month over a year
I’ve taken the courses, I have practical experience, I paid the exam fee and I past the test. That makes me an “Amazon Web Services (AWS) Certified Solutions Architect – Associate”. Wow what a mouthful, but what does that mean to you?
Per AWS, I have “experience designing distributed applications and systems on the AWS platform”.
Yes, but what does that mean?
AWS has somewhere around 104 different services. These range from simple email to virtualized servers to “serverless” computing to big data processing and everything in between.
As a Solutions Achitect I know how to navigate the roadmap that makes up “AWS town”. When we speak, I strive to understand your existing resources and how they are used or what your requirements may be for a new project. I take that information and convert those requirements into a plan that utilizes AWS services. This could be a “all-in” approach or a mixed on-premise / AWS approach depending upon your needs.
I then implement that plan. I have much experience moving resources to AWS or creating those resources from scratch. If I lack expertise in what you need, I will either utilize my resources to understand how to accomplish what is needed or find another resource that can make it happen. Continue reading
March 2017 rolls around and AWS releases awesome new flexibility with reserved instances (RI). You can now split and merge RI’s as well as be automatically be pro-rated on-demand instance costs if you own a lesser RI. I also watch YouTube videos that also explain how this new flexibility works and how great it is. But in the excitement of it all I don’t realize that this new flexibility only applies to regional Linux/UNIX RIs with shared tenancy within the same instance class.
Here’s a case example:
You run an e-Commerce site that runs an m4.large instance. On January 1st 2017 you reserved a m4.large instance for one year. Come December 1st, traffic is expected to double for the Christmas season, so you scale up your instance to a m4.x-large instance type until January 1st.
If Running Linux:
Your annual savings is 38% over on-demand if you were to use m4.large during the entire 2017 year. However jumping up to m4.x-large will increase your bill by about what a m4.large instance would cost on-demand for the month of December 2017. This pro-rated charge is done automatically. There are a couple Linux OS exceptions and hourly Software charges are not calculated in this example.
If Running Windows:
Your annual savings is 20% over on-demand if you were to use m4.large during the entire 2017 year. However jumping up to a m4.x-large will increase your bill by about what a m4.x-large instance would cost on-demand for the month of December 2017. Essentially your savings now are negative due to the fact that your instance is not pro-rated with your RI. This is due to the fact that you are still paying for your reserved instance of m4.large, but it’s not being used. Then on top of that you’re paying for a m4.x-large. As an example, one year of a reserved m4.large costs $1349.04, a savings of $332.88. One month of m4.large not being used costs on average $140.16. This brings your 20% savings down to around 9%. Hourly Software charges are not calculated in this example.
When running Linux you have fairly minimal risk involved when getting a reserved instance. However your risk goes up quite a bit reserving a Windows instance. There are a number of options to mitigate that risk level down. One option is to get a convertible RI. This allows you to exchange OS, family or tenancy. But keep in mind your big picture. For you this may only be good if you think you’ll need to move from a t2 to a m4 family. Another option is you can sell your unwanted RI on the marketplace at a reduced price. When looking at this option, consider how much savings equates to dollars and how much time you’ll need to calculate the risk, estimated savings reduction and time spent selling when selling an RI. Of course different instance types have different savings levels. In the end, it comes down to either a statistician to calculate risk vs. benefit or theories and experience.
In conclusion, I likely wouldn’t bat an eye getting either a standard or convertible RI for Linux if I largely suspected the RI would be needed for at least a year. But I would likely keep a Windows instance on-demand if there was any chance for instability unless I had enough on-demand instances to off-set the risk if one instance no longer matches an RI for a time period.
A common task on a SQL Server might be to copy a database into a new database. This could be on the same server or a different server.
On Amazon Web Service’s (AWS) Relational Database Service (RDS) this task becomes a little more complex to plan and execute. There are a few reasons for this:
- You don’t have access to the local file system outside of creating a database in the defaulted path.
- You do not have the needed permissions to run “Copy Database Wizard”
- Doing a “native” backup/restore using S3 would create a duplicate “family_guid” which is impossible to restore on your RDS instance without deleting the source database.
If you use MS SQL 2016 you can export/import a “Data-tier Application” which is stored as a “.bacpac” file. This is a schema and data native format package (not human readable). In reality it’s a .zip file, so if you open it in something like 7-Zip you can see the package contents. This package is going to be lacking items such as the physical index (the index configuration is intact) and the transaction logs. Therefore it tends to be smaller than an actual native backup.
Keep in mind all data is transmitted from the source machine (AWS RDS) to your workstation. If this is a larger database, you may wish to consider doing this from an EC2 instance to create a faster connection, provide for a larger drive workspace and potentially save on network costs.
Here are the steps to take to backup and then restore a “.bacpac” file. This example is done using AWS RDS, but the same steps would be taken for about any environment including local.
- Open Microsoft SQL Server Managment Studio (MSSMS) 2016 or better and connect to your database server.
- Right click the source database, go to tasks and “Export Data-tier Application”.
- Press “Next” to go to “Export Settings”. Enter a path on your local workstation to save the package to and press “Next”.
- After you press “Finish”, it will then begin the copy process from the source machine to your local machine.
- If you wish to import the database to another server, connect to it now via the MSSMS.
- Right-click the “Databases” group object and select “Import Data-tier Application”. Press “Next”.
- Specify the path on your local machine to the “.bacpac” file being imported. Then press “Next”.
- Specify a new database name. It can not be the name of an existing database. Press “Next” and then “Finish”.
- The new database will be created and imported.
It appears the “family_guid” issue is no longer an issue. I have not verified it as of yet. See https://aws.amazon.com/about-aws/whats-new/2018/10/amazon-rds-for-sql-server-enhances-backup-and-restore-capabilities/
#aws, #export, #import, #microsoft, #rds, #sql
You purchase a year-long EC2 Reserved Instance (RI) from Amazon Web Services (AWS). You’re now saving 30% on your sparkling EC2 instance cost!
Fast forward three months. Your project tanked and is costing you money instead of making money. You need to kill it and kill it fast.
But then you remember that one-year contract you have with AWS. <doomed>
You then remember that you can sell off your RI to a marketplace. Bank account saved – mostly.
That part is easy to research and follow the steps for success.
Now “Wannabe Joe” is looking for a deal and wants to purchase that discounted RI you’re selling off. Joe goes to the EC2 console and clicks “Reserved Instances”. He then proceeds to “Purchase Reserved Instances”.
He sees a paragraph:
Reserved Instances sold through the Reserved Instance Marketplace are identical to those sold by Amazon Web Services, except they may have different prices and terms. For more information about the Reserved Instance Marketplace, go to the Reserved Instance Marketplace web page.
He remembers about the marketplace selling unwanted instances so he clinks on the provided link. Listing, selling, fee and getting paid. All great for the seller. But how does he purchase one. Click-after-click just provides frustration.
Don’t worry Joe. You overthought the whole process.
- In the AWS Console Home, go to the EC2 console
- Press the “Reserved Instances” link on the left and then press the “Purchase Reserved Instances” button up top.
- Choose your platform, types, zone, term and tenancy.
- Press the “Search” button
- If there are any unwanted instances up for sale, they will be listed under the “Seller” column as “3rd Party”.
- Add to cart and away you go.
Reference and image by: https://aws.amazon.com/blogs/aws/amazon-ec2-reserved-instance-marketplace/
In 2013, the CA/Browser Forum passed an intent to allow a DNS domain name (joeblow.com) holder to specify one or more Certification Authorities (CAs) authorization to issue certificates for their domain. No other CAs would be authorized to issue that domain’s certificate.
This is accomplished by the domain holder adding a “CAA” record to their DNS for their domain. This helps mitigate the problem that the public CA trust system is only as strong as its weakest CA.
Organized in 2005, the CA/Browser Forum is a voluntary group of certification authorities (CAs), vendors of Internet browser software, and suppliers of other applications that use X.509 v.3 digital certificates for SSL/TLS and code signing.
View the full ballot.
On August 21st, 2017, Amazon Web Services (AWS) announced that their DNS service “Route 53” now supports CAA records.
We currently run some magnetic EBS volumes for data storage accessed by EC2 instances. Last month AWS announced the availability of Live Volume Modification with Elastic Volumes on EBS. This would enable a volume to expand while being in-use. Where as before you’d have to schedule downtime.
Live Volume Modification is almost a must-have feature for the web servers we run to be cost efficient and reduce any downtime. I have also noted that EBS Magnetic Volumes are now considered “previous generation” technology. (AKA: silent deprecation, just like reduced redundancy S3)
I attempted to expand a magnetic volume on a m3.large instance but found that the modify link was disabled. After a forum post, and the helpful reply from AWS, I found that previous generation magnetic volumes can not be modified while live.
This feature is too important and we will be moving to a SSD volume type instead to enable this feature. However it remains to be seen what restrictions we may have. Documentation states: “Current generation m3.medium instances fully support volume modification. However, some m3.large, m3.xlarge, and m3.2xlarge instances may not support all volume modification features.”
See more information at “Considerations for Modifying EBS Volumes”
Forum reference: https://forums.aws.amazon.com/message.jspa?messageID=771210